敏捷软件开发之Scrum/Sprint(2)

　　如果项目的所有人都坐在一起, 连工位的矮墙都没有, 那的确很爽, 但是在很多公司中那是不可能的，有些团队成员甚至在不同的时区工作，怎么办? 他们就不能敏捷了?这时候我们的确需要文档和其它辅助手段来沟通。

　　燃尽图, 有些燃尽图只是列出了任务的数目, 这种图无法展现项目的拖延, 一个任务有大有小, 它们在图表中都是一个点, 一个16小时的任务需要3 天完成, 一个2小时的任务处于种种原因也花了3天时间, 他们在图表中的表现是一样的。 在实践中, 我个人认为以时间为度量的燃尽图更有效果.

　　下面是一个实际项目的燃尽图, 有三个每天跟踪的时间值:

　　实际剩余时间/remaining hour: 每个团队成员所有任务的 remaining hour 的总和

　　预估剩余时间/projected remaining hour: 根据每个人每天的理论进度推算的剩余时间

　　实际花费时间/completed hour:

(Sprint 进行中) (sprint 最后)

　　注解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% 的任务。

　　软件团队中还有一个重要的角色 - 测试。 测试人员在一个冲刺中怎么工作呢? 有敏捷专家建议测试人员可以担负起 Product Owner 的部分责任，同时掌握 Acceptance Test 流程, 对产品的最终质量负责。 但是测试人员的开发技术能力在团队中并不占优 (在有些中国公司中甚至是最弱的一环)，他们在大家都要 “烧光”所有任务的压力下，能担当起 Product Owner 这一责任么?

　　第四步:

　　得到了一个增量的软件发布, 当然好, 但是谁来验证这个增量满足了事先的计划呢? 如果程序员们在冲刺的过程中发现了新问题, 改进了原来的计划, 这是好事呢还是坏事?

　　每一次冲刺结束后, 大家要放松一下, 总结上一次的经验教训，争取下一次做得更好。 这个博客记录了微软学术搜索项目组 10 次冲刺的过程。

　　软件开发流程有好多种, 我们怎么衡量一个开发流程是否对当前的项目/团队合适? 我觉得Scrum/Sprint 能成功实施的关键在于 ScrumMaster。我听到有些团队也实施Scrum, 但是他们随机挑一个成员来做 ScrumMaster, 好像 ScrumMaster就是招呼大家开开会, 记录每个人的进度而已。这种方法失败的可能性很大。 一个好的ScrumMaster 能在两种语境 (描述软件项目的商业语境，描述实现细节的技术语境) 自如地翻译和切换，事实上是一个强有力的PM，如果团队还要求她做全职的开发工作，这样的人就更难找了。

　　Scrum 很特别么?

　　我个人认为它和质量控制理论的模型， 例如 经典的戴明环 PDCA Plan-Do-Check-Act/Adjust 没什么太大区别. 正如 Ken Schwaber 在描述Scrum 的核心特点的时候说:

　　在迭代开始时, 团队审视摆在他们面前的任务，选择他们认为可以在迭代期间完成的那些 (Plan)。然后团队独立地尽最大努力完成这些任务 (Do)。在迭代结束时, 团队给利益关系人展示他们的成果 (Check)，并对开发流程进行调整 (Act/Adjust).

　　在 6西格玛理论中 ( Six Sigma) ，我们也可以看到相似的流程, 只不过它变成了 "Define, Measure, Analyze, Improve, Control" (DMAIC). 此模型不强调迭代的重要性。

　　Scrum 和 渐进交付的流程 (Evolutionary Delivery) 也很相似:

图片来源: Rapid Development (1996), Chapter 7, “Lifecycle Planning” (p. 133)

　　Scrum 的团队

　　Scrum对团队的要求很简单：self-managing， self-organizing， cross-functional， 但是这很难做到。软件项目的团队各式各样 (各种团队类型的介绍)， 假设一个团队做得还不错，现在要变成 Scrum 流程, 那团队要做下么的改变:

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