Mike Cohn专栏

Scrum的推广模式

/分类： /编辑：

本文探讨 Scrum的推广模式 。

Scrum入门是一回事，把它推广到整个企业是另外一回事。 除非你选择全面转型，否则你需要将上述成功建立在几个试点团队上，然后推广到其他团队。在试点完成之后，你可以使用三种通常的模式推广Scrum。 前两种模式是让一个团队开始使用Scrum并取得成功，然后让这个团队的成员作为新团队的种子队员。第三种模式使用一个不同的方式，需要使用内部教练来推广Scrum。 Read more →

高度专门化时代下的敏捷开发

/分类： /编辑：

本文我们一起来谈谈高度专门化时代下的 敏捷开发 。

自从18世纪的工业革命开始，专门化的程度一直处于上升的趋势。工人们逐渐开始只生产产品的小部件，而不是像以前那样涉足到整个产品生产的所有环节。 Read more →

从两方面保护Scrum团队

/分类： /编辑：

保护Scrum团队是Scrum Master的其中一个职责已经是总所周知的事情。一个经常被提及的例子就是Scrum Master保护团队免受激进的Product Owner的压力。这个例子本身并没有什么问题，因为很多团队都需要Scrum Master的保护，否则Product Owner就很有可能会迫使团队放弃一些质量来完成更多功能特性。然而，一个好的Scrum Master同时也需要保护团队避免其遭受“自满”的侵害。 Read more →

妥协的艺术: Scrum与项目监管

/分类： /编辑：

敏捷的概念与项目监管并不是从根本上相对立的。他们都是改善产品的手段。Scrum通过紧密的协作和固定长度的Sprint中实现短周期的 “检测与调整”来达到这个目的。而项目监管则是希望通过设置所谓“检测及批准（拒绝）”的检查点来确保项目或者产品能达成一些可比较的参数目标。 Read more →

应该为bug修复的故事安排故事点吗

/分类： /编辑：

在把一个产品从传统方法向敏捷方法的迁移过程中，团队通常带着一大堆bug前行。这通常是缺泛持续的高质量要求的自然结果。导入敏捷后不用多久，很多团队（及他们的产品负责人）会决定激进去清除这些Bug的backlog。 通常的做这件事的方法都是在每个Sprint中计划修复掉X个bug，或者是每个Sprint中计划花Y小时用在修复bug上。有时团队会为这样的活动写一个用户故事如“作为一个用户，我希望至少有15个bug被修复”或者“作为一个用户，我希望你这个Sprint中花大约50个小时去修复bug，使得应用系统逐渐的变得质量更高”。即使团队并没有明确的写一个这样的用户故事，他们也通常会在他们的任务板中加这么一行，以便于bug修复的工作是可见并且可以跟踪的。 Read more →

什么样的项目最适合于敏捷开发

/分类： /编辑：

我最近被问到关于什么样的项目才是最适合于敏捷方法，在此关于这方面进行一个探讨。在我看来，最适合敏捷方法的项目是那些有着激进的时间期限限制，那些有着高度的复杂程度，以及那些有着高度新颖性（独特性）的项目。 Read more →

非功能性需求的用户故事

/分类： /编辑：

写用户故事的挑战之一是如何表达非功能性需求。有些需求是与具体的需求无关的，它不像“作为一个文档处理者，我想要在一个文档中插入一个表格”这样的功能描述，而是关于系统的一个属性或者特征的描述。比如说可靠性，有效性，可移动性，可放大性，可用性，可维护性等。在这样的例子中，非功能性需求通常是指“某某性”或者“某某能力”。当然，并不是所有的非功能性需求都是在说“某某性”，还包括像安全机制，性能，自动化能力等等。 Read more →