敏捷团队需要测量其Sprint速率，以帮助团队计划并跟踪其进度，同时也为产品所有者规划产品发布提供洞见。那么当团队想要改进自身的时候，是否也可以使用速率数据？若干作者围绕速率撰文，并针对测量速率以改进团队生产力分享了各自的关注点。Catia Oliveira在Scrum联盟网站上发表了一篇文章：如何计算并使用速率，以帮助我们的团队和项目。她总结了测量速率对团队的帮助如下：如果了解了团队的速率，那么
对于初涉敏捷的测试工程师来说，如果定位自己的角色和职责、如何从传统开发模式成功迁移到敏捷模式、如何跟上短迭代的节奏等等问题都迫切地想要找到答案。 资深敏捷实践者Lisa Crispin和Janet Gregory在《敏捷软件测试：测试人员与敏捷团队的实践指南》一书中，列举了敏捷测试工程师的十条法则，对读者或许有借鉴意义。提供持续反馈(Provide Continuous Feedback)既然是测
敏捷社区的一些成员强调了反馈循环对于提高敏捷开发流程效力方面的重要性。“反馈循环”是什么呢?简单来说，如果某个流程的执行结果可以影响到此流程未来的运作方式，那么它就存在反馈循环。在敏捷开发流程中存在哪些类型的反馈循环呢?在Henrik Kniberg和Mattias Skarin的著作《看板与Scrum：把两者发挥到极致》(Kanban and Scrum: Making the Most of
实施敏捷方法和设计企业架构之间总是存在某种冲突。敏捷开发强调随着对业务领域的深入理解，逐步调整设计和计划。架构设计则要求建立起技术架构(technology stack)。它可以满足质量属性(quality attributes)，也可以向感兴趣的利益关系人进行展示，作为一种英文原文：Agile and Architecture Conflict实施敏捷方法和设计企业架构之间总是存在某种冲突。敏捷
英文原文：Implementing Automated Governance for Coding Standards作者：Mark Figley 译者：罗小平多数大型开发组织都有一套自己的编码和实践规范。但是对这些团队而言，光是将这些规范文档化，并保证实时更新，就是一个巨大的挑战。此外，在工作中长期、忠实地执行这些规范和标准，难度就更大。我们团队在这些方面做了积极探索，在整个构建过程(build
关于精益的定义有许多，但其中最令我感到鼓舞的是精益企业研究所主席John Shooke在它的著作《管理精益》中所描述的一段话：精益通过提高员工的水平来保证产品开发。在这个定义的基础上，这篇论文接下来解释了精益是怎样提高人员的水平的：方法就是解决问题。这一定义揭示了以下管理实践的美妙之处：仔细设计你的工作，让你能够清晰地看见所发生的问题（以及同时出现的学习机会），并在问题出现后以科学的方式解决。在与
在把用户故事切分成小块，从而更好地利用敏捷技术时，很多新组建的敏捷团队都会遇到困难。 敏捷社区的成员在多篇文章中为如何有效地切分用户故事提供了指导。 当把庞大的用户故事切分成小块时，是否有一些一般的准则供我们遵循呢？Rachel Davies建议对每个用户故事都要进行切分，从而让产出的软件：能够工作交付价值能有效地得到用户的反馈Richard Lawrence提供了以下技术，他认为在切分大型用户
英文原文：How To: Live and Learn with Retrospectives 软件开发不是孤独的追击，它需要同其他开发者和其他部门协作。大多数组织建立的软件生命周期没有涉及到如何进行这些交互。现实是许多团队的过程 并不符合他们的要求或没有得到一贯地遵循。当发生这种情况时，很容易让人产生抱怨情绪，如果你已经有了改进的想法却又无从下手，也会让人感到沮丧。本文提 供了一个工具，可
从团队成员大姐大的博客中转载而来。
“编程的摩羯男”，实际就是ATIP团外号“团长”的那个家伙。《敏捷开发实践总结》的这几篇，是他首发在他个人技术博客中的内容。归档到项目组博客中。
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
