Advanced Software Engineering, Development Process, Scrum/Sprint
软件开发的流程有很多 (看 各种方法论概述), 我也写过一篇博客 (酒后的敏捷) 谈了谈最近比较时髦的开发流程，
现代软件工程讲义4 Scrum/Sprint
。 今天我们不喝酒, 正襟危坐地说说敏捷这一路 Scrum/Sprint 开发方法.从理论上看, 这个方法真是妙得紧:
[图片来源: http://en. .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 的棒子现在是什么状态, 你做好之后交给谁了，
管理资料
《现代软件工程讲义4 Scrum/Sprint》(https://www.unjs.com)。另一个改进是, 要在每一个任务中记载我们完成这个任务还需要多少时间。
冲刺到一半的时候, 产品负责人突然发现要做马上重要的改动! 或者某个大佬要看某个不在计划中的功能的演示, 怎么办? 这种情况非常考验 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 小时?