标签：
从理论上看, 这个方法真是妙得紧:
[图片来源: http://en.wikipedia.org/w/index.php?title=File:Scrum_process.svg&page=1]
微软 MSDN 也有类似的流程介绍，看起来真是太容易了: 
第一步: 找出完成产品需要做的事情 – Product Backlog, Backlog 翻译成“积压的工作”, “待解决的问题”, “产品订单”都可以。
产品负责人主导大家对于这个Backlog 进行 增/删/改 的工作。每一项的时间估计的单位为 “天”.
第二步: 决定当前的冲刺需要解决的事情 – Sprint Backlog.
任务被进一步细化了，被分解为以小时为单位。如果一个任务的估计时间太长 (例如 超过16个小时)，那么它就应该被进一步分解。 冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。 团队成员能主导任务的估计和分配, 他们的能动性得到较大的发挥。
第三步: 冲刺 (Sprint). 在冲刺阶段, 外部人士不能直接打扰团队成员。 一切对交流只能通过SCRUM MASTER 来完成。 这一措施较好地平衡了 “交流”和 “集中注意力”的矛盾。 有任何需求的改变都留待冲刺结束后再讨论。
冲刺期间, 每天要开一个每日例会 (SCRUM Meeting), 团队成员大多站着开会, 所以又称每日立会. 大家依次报告:
我昨天做了啥
我今天要做啥
我碰到了哪些问题
每日立会强迫每个人向同伴报告进度, 迫使大家把问题摆在明面上。同时启动每日构建, 让大家每天都能看到一个逐渐完善的版本。
用简明的图表展现整个项目的进度, 这个图最好放在大家工作的环境中, 或者每天传达给各个成员:
图表可以是燃尽图 Burn Down Chart (想象我们把一堆 Backlog 的木头给烧光)。
也可以是简单的看板图 Kanban: （把一堆任务从最初的 “待定”推动到“工作中”等各个状态, 直至“完成”）
这里有几个 现代软件工程 学生小组的 daily scrum 的过程:
冲刺阶段是时间驱动的 (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]
如果项目的所有人都坐在一起, 连工位的矮墙都没有, 那的确很爽, 但是在很多公司中那是不可能的，有些团队成员甚至在不同的时区工作，怎么办? 他们就不能敏捷了?这时候我们的确需要文档和其它辅助手段来沟通。
燃尽图, 有些燃尽图只是列出了任务的数目, 这种图无法展现项目的拖延, 一个任务有大有小, 它们在图表中都是一个点, 一个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% 的任务。
长期任务: 软件项目中常常有一些比较艰难和底层的任务, 完成这些任务需要超过sprint 所计划的时间, 这时候我们怎么安排呢? 在我的经验中, 这些任务往往在短周期的迭代中得不到应有的重视, 一直拖着。
软件团队中还有一个重要的角色 - 测试。 测试人员在一个冲刺中怎么工作呢? 有敏捷专家建议测试人员可以担负起 Product Owner 的部分责任，同时掌握 Acceptance Test 流程, 对产品的最终质量负责。 但是测试人员的开发技术能力在团队中并不占优 (在有些中国公司中甚至是最弱的一环)，他们在大家都要 “烧光”所有任务的压力下，能担当起 Product Owner 这一责任么?
这一篇博客讲了 第三步半要做什么事情, 它的流程图可以作为Scrum/Sprint 的补充:
第四步:
得到了一个增量的软件发布, 当然好, 但是谁来验证这个增量满足了事先的计划呢? 如果程序员们在冲刺的过程中发现了新问题, 改进了原来的计划, 这是好事呢还是坏事?
每一次冲刺结束后, 大家要放松一下, 总结上一次的经验教训，争取下一次做得更好。 这个博客记录了微软学术搜索项目组 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 流程, 那团队要做下么的改变:
如果你的团队很弱, 那么强行把Scrum （或者其它高级方法）套在上面也没有用, 也许还会适得其反，往往需要多次Sprint 才能让Scrum 走上正轨。换句话说, 如果你的团队已经是这么厉害 （self-managing, self-organizing, cross-functional）的一帮人, 那么用不用Scrum 都能写好软件!
经验:
这里有一些实践者的经验教训:
总结:
Sprint/Scrum 对项目的众多需求采取分而治之的办法, 能让相关人员集中精力, 在一定期限内解决部分问题。
它强调短时间的迭代 (iteration)， 在多次迭代中不断总结, 改进团队的流程和产品功能。
它明确地指出不同人在一个项目中的投入和责任的不同 (猪和鸡), 并坚持让全身心投入的“猪”来主导项目。
它通过 daily scrum, ScrumMaster 等方法和角色，鼓励团队内部交流并优化团队和其他人员的交流方式。
它对团队成员提出了很高的要求, self-managing， self-organizing， cross-functional。 一般人不能马上做到这一点。
它不是 “银弹”，不能解决软件开发的所有问题，至于具体项目进度如何跟踪, 如何管理测试工作， 如何管理复杂项目, 还要靠战斗在一线的团队成员见招拆招，想出合适的办法。
Scrum工具：leangoo 国内专注于敏捷团队协作的免费、可视化、轻量级工具 leangoo.com
文章来源：http://www.cnblogs.com/xinz/archive/2012/10/05/2712602.html
标签：
原文地址：http://www.cnblogs.com/leangoo/p/4566627.html
