Mike Cohn专栏

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

在许多企业中,把估算和承诺等价看待是普遍现象。开发团队(无论是否是敏捷团队)根据可用的资源和期望交付的功能,做了一个估算,估算得出需要花费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

优秀的 Scrum Master 应该具备哪些特质?

如今的外科医生是受过高级训练和技能娴熟的人,他们经过多年的正规教育,然后又做过广泛的实习。早期的情况并不总是这样的,Pete Moore写道“首批外科医生不懂解剖知识,但之所以能开展他们的业务,是因为他们有锋利的器械和强壮的胳膊。他们在当地的工作是理发师或者铁匠,经常在业余时间做手术。”(2005,143) Read more

ScrumMaster – 指派还是团队选择?

一个新Scrum团队对ScrumMaster的选择会影响到团队Scrum实施的成败。选错了人,团队就会一方面试图变得自组织、另一面却又受制于命令控制型的经理,从而进退两难。选对了人,他符合新ScrumMaster的技能、满足团队初期需求,则团队在实施Scrum上有了一个梦幻般的开端。 Read more

使用敏捷燃尽图管理敏捷项目风险

风险管理是传统项目管理中的重要部分,也是项目管理协会(PMI)知识结构体中的知识领域。在我的很多课程中,参加培训的人会问在Scrum和敏捷项目中如何定位风险管理。一部分人顾虑Scrum或者敏捷项目中会完全忽略项目管理。让我们来看看为什么会这么理解。 Read more

是否可以轮流做 Scrum Master ?

有些团队在为如何挑选最好的 Scrum Master 而挣扎,然后最后决定让所有团队成员轮流充当Scrum Master的角色。出于对这个角色的挑战和重要性的考虑,我并不推荐这么做。举个例子:在我的家里,我们轮流擦桌子和洗碗,因为谁都可以胜任这些工作。但是,我们不会轮流做饭。因为我们都知道,我的妻子是家中最出色的厨师,而且比其他任何人都要好很多。我们都希望能吃到最好的饭菜,所以我们不会轮换厨师的角色。同样,如果你希望你的团队能够变得尽可能好,我不推荐使用轮换的Scrum Master。
Read more

当你忘了sprint计划会议的目的…

Sondra Ashmore 和 Kristin Runyan合著的一本敏捷方面的新书即将出版, 在最近一次对其采访中,他们问到了敏捷开发和scrum好几个方面的问题。 在最近的2篇blog里,我就曾探讨过产品backlog和估算。 现在,再来分享一下我对计划会议以及下面这个问题的观点: sprint计划会议中最常见的错误是什么? 毫无疑问,最常见的错误是误解了计划会议的目的。 计划会议应该有2个产出物: 1.sprint的目标 2.sprint backlog

因为sprint backlog是计划会议的一个工件,所以会有许多团队过分强调要得到一个完美的sprint backlog。 这些团队试图去确定每个新任务,并且为每个新任务贴上非常精确的估算值。

sprint计划会议

团队这样做的一个典型的原因是迫于管理层的压力,尤其当团队刚实施scrum的时候。 他们想通过对任务的精确估算,把管理层的估算做的完美无缺。 但是,那不是计划会议中制作sprint backlog的目的。

sprint计划会议的目的是从产品backlog中为当前sprint挑选一组正确的任务, 并且要让团队感觉到每个任务都是被充分讨论过了,他们已经做好准备可以完成这些任务了。

在任务和任务的估算上关注太多会让团队在sprint计划会议中消耗太多时间。 因此,这时就需要scrum master这个角色来保证sprint计划会议不要偏离它的原本目的太远。  对团队理解他们交付物来说,任务和估算是必要的,而且最好把它们作为一个工具来决定当前sprint要选择哪些条目。

 

作者:Mike Cohn

原文地址:http://www.mountaingoatsoftware.com/blog/when-you-miss-the-point-of-sprint-planning-meetings