Mike Cohn专栏

从两方面保护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

敏捷估算-区分估算和承诺

在许多企业中,把估算和承诺等价看待是普遍现象。开发团队(无论是否是敏捷团队)根据可用的资源和期望交付的功能,做了一个估算,估算得出需要花费7个月。团队向他们的管理者提供了这个估算,管理者又将这些估算传递给他们的副总,副总又将这些告诉客户。在一些情况下,估算在这个过程中被削减了,留给团队的是一个“拔高了的目标”。这里的问题不在于团队的7个月的估算是对还是错。问题的关键是估算被转变成了承诺。 “我们估计这将需要7个月”被转变成了“我们承诺在7个月完成”。估算与承诺都很重要,但它们应该被视为不同的活动。 Read more

敏捷设计-主动设计而又是涌现式的设计

Scrum的项目没有一个前期的分析和设计阶段,所有工作发生在迭代的Sprint周期内。然而,这并不意味着,在一个Scrum项目中没有主动的设计。在一个主动的设计过程中,设计是通过深思熟虑的和清醒的决策来指引的。 Scrum项目上的差异不是扔掉主动的设计,而是通过增量的方式来完成,像Scrum项目中的其他做法一样。 Scrum团队承认,尽可能在前期做出所有的设计决策会很好,但这是不可能完全做到的。这意味着,在一个Scrum项目中,设计即是主动的又是涌现式的设计。涌现式设计是因为没有前期设计阶段(即使在每个Sprint中都有设计的活动);要主动设计,是因为慎重地选择产品Backlog的条目,有一双眼睛去推动设计在不同的时期朝着不同的方向。 Read more

在预见性和适应性之间找到平衡

企业向敏捷转型的一个重要方面是在预见性和适应性之间找到一个合理的平衡(Highsmith 2002)。
图1显示了这种平衡,以及伴随的影响这种平衡的各种活动和事物。在做前期分析和设计的时候,我们试图去预见用户的需求。因为我们不能完全预见到这些,我们会犯一些错误,有些工作需要返工。而当我们放弃分析和设计,立即跳到去做编码和测试时,没有任何的预测,我们尽力去适应用户的需求。行业中的所有项目都将被定位于介于预见性和适应性之间的位置,根据他们自己特有的特性,没有任何的实际应用会完全到一个极端。一个事关生命的医疗安全应用程序可能会在预见性方面多一些;而由一家3人创业公司建立的信息网站,其上面放一些皮艇比赛的信息,可能会大大偏向适应性一方。 Read more

敏捷实施 过程中的4种类型的抵触者

人们抵触Scrum转型有很多不同的原因。有些人抵制可能是他们安于现在的工作和同事。他们花了很多年才达到了企业中现在的地位,在这个的团队中,为现在的经理工作,或是确切地知道每天该如何做自己的工作。其他人抵制Scrum转型的原因可能是对未知的恐惧。 “你认识的魔鬼比你不认识的魔鬼要好”是他们的口头禅。还有些人抵制可能是因为对Scrum方法的不喜欢或不信任。他们可能认为缺乏大规模前期设计的迭代开发方式用于复杂产品时将会导致灾难。 Read more