现代软件工程讲义4 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 会议的时候, 大家的发言是:
我昨天掰棒子
我今天继续掰棒子
我没碰到困难
这样的会议有用么? 也许昨天掰的棒子没处理, 今天就掰另一个棒子去了, 明天又来一个新棒子…
一群狗熊级的程序员会这么说:
我昨天写代码
我今天继续写
我没碰到困难
每天这么写代码, 我们离完冲刺的终点线到底是更近了, 还是更远了?
一个改进是, 定义好任务究竟是什么? 任务的完成 (done) 到底意味着什么? 每个人的任务必须是明确定义的, 狗熊们不能笼统地说, 我在掰棒子, 而是要说明标号为123 的棒子现在是什么状态, 你做好之后交给谁了。
另一个改进是, 要在每一个任务中记载我们完成这个任务还需要多少时间。
冲刺到一半的时候, 产品负责人突然发现要做马上重要的改动! 或者某个大佬要看某个不在计划中的功能的演示, 怎么办? 这种情况非常考验 SCRUM MASTER. 如果一个运动员在跑一百米冲刺, 但是跑到一半的时候，领导突然想看一百一十米栏的比赛, 前面马上会摆起栏架, 大家要准备8步上栏! 怎么办?
一个有正常头脑的运动员和教练员会说: 去你的， 要改主意, 也要等到老子冲刺完了再说啊!
关于每日立会 - 如果团队成员不在同一个地方, 怎么开会呢? 我听到一些敏捷的专家说, 一个团队的成员必须面对面开会, 才有效果。 但是现在有很多跨地区的合作, 怎么办? 他们就不能敏捷了?
燃尽图, 如果燃尽图只是列出了任务的数目, 一个缺点是它无法展现项目的拖延, 一个任务有大有小, 它们在图表中都是一个点, 一个16小时的任务需要3 天完成, 一个2小时的任务处于种种原因也花了3天时间, 他们在图表中的表现是一样的。 在实践中, 我个人认为以时间为度量的燃尽图更有效果.
下面是一个实际项目的燃尽图, 有三个每天跟踪的时间值:
实际剩余时间/remaining hour: 每个团队成员所有任务的 remaining hour 的总和
预估剩余时间/projected remaining hour: 根据每个人每天的理论进度推算的剩余时间
实际花费时间/completed hour:
注解1: sprint 从8/22 到 9/28, 中间9/15 - 9/18 整个团队外出开整个部门的年会。
注解2: 开始预计所有工作量为340 小时， 每个工作日能减少 (burn) 17 小时。
注解3: 开发人员有 5.5 名, 绝大多数第一次接触正式商业项目和 SCRUM的团队开发模式。 最终完成的工作量为524 小时, 是预计的 1.5 倍。（这暴露了什么问题呢?）
注解4: 有 0.5 名UX 设计人员, 0.5 名PM, 和 2 名测试人员。
注解5: sprint 结束后, 各个任务宣告完成, 并且没有P1 (最严重的) bug，但是P2 及以下的bug 有80 多个, 加上前一个版本遗留下来的70个bug, 总共还有150 个bug 要解决, 才能发布。
注解6: sprint 结束后, 有两个原来的设计发现很有问题, 团队决定在sprint 结束之后进行重新设计，或者叫 Design Change Request (DCR)。
第三步半:
做过项目的人都知道, 当你说“任务都完成了”的时候, 那只是说, 开发人员认为该写的代码都写完了, 还有很多事情没做完. 例如写一个Windows 客户端的功能， 显示一个新闻图片加上和与它相匹配的文字 (假设这些图片/文字都可以从互联网上拿到) , 做完之后, 还有下面的事情:
验证这个功能显示在WinXP, vista, win7, win2008 server R2, win2012 server 都显示正确。 (开发人员表示自己的机器是win2008 server, UI 看起来不错, 其它平台想必也不错!)
验证这个功能的显示布局和字体在100% 到150% 的DPI 上都显示正确, 在各种色彩配置中都显示正确。
验证文字无论是中文, 英文, 阿拉伯文都能正确显示
验证程序效能上没有问题
验证程序在长期使用, 没有内存和资源泄露
验证这个功能和其它功能有较好的集成
谁来做这第三步半呢? 程序员写完功能的时候, 我们感觉好像项目完成了 80%, 后面的20% 往往要花费80% 的时间, Sprint/Scrum 没有明确表明到底 何人/何时/何种优先级 来完成这个20% 的任务。
软件团队中还有一个重要的角色 - 测试。 测试人员在一个冲刺中怎么工作呢?
第四步:
得到了一个增量的软件发布, 当然好, 但是谁来验证这个增量满足了事先的计划呢? 如果程序员们在冲刺的过程中发现了新问题, 改进了原来的计划, 这是好事呢还是坏事?
每一次冲刺结束后, 大家要放松一下, 总结上一次的经验教训，争取下一次做得更好。 这个博客记录了微软学术搜索项目组 10 次冲刺的过程。
总结:
Sprint/Scrum 对项目的众多需求采取分而治之的办法, 能让相关人员集中精力, 在一定期限内解决问题。
它有好些办法让不同团队的不同角色在不同阶段各司其职, 避免不必要的互相干扰。
它不是 “银弹”，不能解决软件开发的所有问题，至于具体项目进度如何跟踪, 如何扩展到覆盖测试工作，还要靠战斗在一线的团队成员见招拆招，想出合适的办法。
思考题:
在一个冲刺中, 团队预计每天的进度为 30 小时。当项目完成了一半的工作量的时候, 大家发现实际的进度为15小时/天, 问: 在余下的时间中, 团队的进度要到多少, 才能在项目结束时让整个项目的平均进度恢复到每天30 小时?
TAG:
