敏捷软件开发之Scrum/Sprint

　　Advanced Software Engineering, Development Process, Scrum/Sprint

　　软件开发的流程有很多 (看 各种方法论概述), 我也写过一篇博客 (酒后的敏捷) 谈了谈最近比较时髦的开发流程。 今天我们不喝酒, 正襟危坐地说说敏捷这一路 Scrum/Sprint 开发方法.

　　从理论上看, 这个方法真是妙得紧:

　　[图片来源: http://en.wikipedia.org/w/index.php?title=File:Scrum_process.svg&page=1]

　　第一步: 找出完成产品需要做的事情 – Product Backlog, Backlog 翻译成“积压的工作”, “待解决的问题”, “产品订单”都可以。

　　产品负责人主导大家对于这个Backlog 进行 增/删/改 的工作。每一项的时间估计的单位为 “天”.

　　第二步: 决定当前的冲刺需要解决的事情 – Sprint Backlog.

　　任务被进一步细化了，被分解为以小时为单位。如果一个任务的估计时间太长 (例如 超过16个小时)，那么它就应该被进一步分解。 冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。 团队成员能主导任务的估计和分配, 他们的能动性得到较大的发挥。

　　第三步: 冲刺 (Sprint). 在冲刺阶段, 外部人士不能直接打扰团队成员。 一切对交流只能通过SCRUM MASTER 来完成。 这一措施较好地平衡了 “交流”和 “集中注意力”的矛盾。 有任何需求的改变都留待冲刺结束后再讨论。

　　冲刺期间, 每天要开一个每日例会 (SCRUM Meeting), 团队成员大多站着开会, 所以又称每日立会. 大家依次报告:

　　我昨天做了啥

　　我今天要做啥

　　我碰到了哪些问题

　　每日立会强迫每个人向同伴报告进度, 迫使大家把问题摆在明面上。同时启动每日构建, 让大家每天都能看到一个逐渐完善的版本。

　　用简明的图表展现整个项目的进度, 这个图最好放在大家工作的环境中, 或者每天传达给各个成员:

　　图表可以是燃尽图 Burn Down Chart (想象我们把一堆 Backlog 的木头给烧光)。

　　也可以是简单的看板图 Kanban: (把一堆任务从最初的 “待定”推动到“工作中”等各个状态, 直至“完成”)

　　这里有几个 现代软件工程 学生小组的 daily scrum 的过程:

　　2010 年学生，2011年学生项目，2012年学生项目

　　冲刺阶段是时间驱动的 (time-boxed), 时间一到，就结束。这个特点看似不起眼, 其实它有效地给各种延期的想法断了后路，很高明。

　　第四步: 得到软件的一个增量版本，然后在此基础上又进一步计划增量的新功能和改进。

　　美妙的理论在实践中都会碰到这样那样的问题, 下面是一些例子:

　　第一步:

　　各个需求和任务之间是有种种复杂的依赖关系的，除了优先级之外, 我们还要考虑相互的依赖关系。怎样在计划中表现依赖关系呢?

　　第二步:

　　如果团队成员对某个任务不感兴趣, 都不认领这个任务怎么办?

　　有些成员的认领的任务很多, 有些成员认领的任务很少, 忙闲不均, 怎么办?

　　第三步:

　　每日例会 (SCRUM Meeting)看起来很爽:

　　我昨天做了啥

　　我今天要做啥

　　我碰到了哪些问题

　　爽了之后, 也许会流于形式。 我们想象一帮狗熊开Scrum 会议的时候, 大家的发言是:

　　我昨天掰棒子

　　我今天继续掰棒子

　　我没碰到困难

　　这样的会议有用么? 也许昨天掰的棒子没处理, 今天就掰另一个棒子去了, 明天又来一个新棒子…

　　一群狗熊级的程序员会这么说:

　　我昨天写代码

　　我今天继续写

　　我没碰到困难

　　每天这么写代码, 我们离完冲刺的终点线到底是更近了, 还是更远了? 如果流于形式, 无论多么敏捷的Scrum 每日立会也会被忽悠, 请看学生们的一个忽悠例子.

　　一个改进是, 定义好任务究竟是什么? 任务的完成 (done) 到底意味着什么? 每个人的任务必须是明确定义的, 狗熊们不能笼统地说, 我在掰棒子, 而是要说明标号为123 的棒子现在是什么状态, 你做好之后交给谁了。

　　另一个改进是, 要在每一个任务中记载我们完成这个任务还需要多少时间。已经花了多少时间虽然重要, 但是不是关键 (那是沉没成本)，关键是要看我们离最后目标有多远。 就像某部门展览“反腐成果”， 给群众看 “已经抓出来N 个腐败分子”固然解恨, 但关键还是 ”还剩多少在台上“，这个问题不说明, 再抓20个, 30个都不解决问题。

　　冲刺到一半的时候, 产品负责人突然发现要做马上重要的改动! 或者某个大佬要看某个不在计划中的功能的演示, 怎么办? 这种情况非常考验 SCRUM MASTER. 如果一个运动员在跑一百米冲刺, 但是跑到一半的时候，领导突然想看一百一十米栏的比赛, 前面马上会摆起栏架, 大家要准备8步上栏! 怎么办?

　　一个有正常头脑的运动员和教练员会说: 去你的， 要改主意, 也要等到老子冲刺完了再说啊!

　　关于每日立会 - 如果团队成员不在同一个地方, 怎么开会呢? 我听到一些敏捷的专家说, 一个团队的成员必须面对面开会, 才有效果。

　　Ken Schwaber 说: I also recommended eliminating all of the development artifacts – like design documents… Scrum relies on high-bandwidth, face-to-face communication and teamwork; cubicles and unneeded artifacts promote isolation and misunderstandings. [Agile Project Management With Scrum, Page 103]

原文转自：http://www.ltesting.net