敏捷开发Scrum 学习笔记，适于移动开发
抽空学习了下敏捷开发，觉得跟自己的一些想法不谋而合，如果一个团队能实施ｓｃｒｕｍ，那效率一定非常高，非常适合移动开发，Ａｎｄｒｏｉｄ，ＩＯＳ，ＷＭ等小ｔｅａｍ开发一个ａｐｐ。希望对大家也有帮助，
前期可能会觉得有点别扭，但是坚持下来，效果会非常不一样。你会发现，效果高很多，而且规范。
产品 backlog 是 Scrum 的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序，它里面包含的是客户想要的东西，并用客户的术语加以描述。
包括以下字段：
ID – 统一标识符，自增长
NAME – 简短的、描述性的名称
Importance – 产品负责人评出一个数值，指示这个条目有多重要，比如 10 – 150 ，分数越高越重要。
Initial estimate ( 初始估算 ) – 团队的初步估算该条目的工作日。
How to demo – 简单的测试规范，这段描述可以作为验收测试的伪码表示。
Notes – 相关信息、解释说明和对其它资料的引用等，一般都非常简短。
为了便于产品负责人判断优先级别，我们也会在产品 backlog 中使用一些其它字段
Track ( 类别 ) – 当前故事的大致分类，例如 ” 后台系统 ” 或 ” 优化 ” 。这样产品负责人就可以很容易选出所有的 ” 优化 ” 条目，把他们的级别都设得比较低。类似的操作执行起来都很方便。
Components – 如 “ 数据库，服务器，客户端 ” 。团队或者产品负责人可以在这里进行标识，以明确哪些技术组件在这个条目的实现中会被包含进来。这种做法在多个 Scrum 团队协作的时候很有用 — 比如一个后台系统团队和一个客户端团队 — 他们很容易知道自己应当对哪些需求负责。
Requestor ( 请求者 ) – 产品负责人可能需求记录是哪个客户或相关干系人最先提出了这项需求，在后续开发过程中向他提供反馈。
产品负责人应当理解每个故事的含义（通常需求都是由他来编写的，但是有的时候其他人也会添加一些请求，产品负责人对它们划分先后次序）。他不需要知道每个需求具体是如何实现的，但是他要知道为什么这个需求会在这里。
Sprint 计划会议非常关键，应该算是 Scrum 中最重要的活动。要是它执行的不好，整个 sprint 甚至都会被毁掉。举办 Sprint 计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰的工作，也是为了让产品负责人能对此有充分的信心。
Sprint 计划会议成果：
1． Sprint 目标。
2． 团队成员名单 ( 以及他们的投入程度，如果不是 100% 的话 )
3． Sprint backlog( 即 Sprint 中包括的需求列表 )
4． 确定好 sprint 演示日期
5． 确定好时间地点，供举行每日 scrum 会议
整个团队和产品负责人都必须参加 sprint 计划会议。原因在于，每个需求都含有三个变量，它们两两之间都对彼此有着强烈依赖。
范围 ( Scope ) 和重要性 ( Importance ) 由产品负责人设置。估算 ( estimate ) 由团队设置。在 sprint 计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化。会议启动后，产品负责人一般会先概况一下希望在这个 sprint 中达成的目标，还有他认为最重要的故事，接下来，团队从最重要的故事开始逐一讨论每个故事，一一估算时间。
质量分为内部质量和外部质量
外部质量 是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。
内部质量 指用户开不到的要素，它们对系统的可维护性有深远影响。可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。
一般来说，系统内部质量优秀，外部质量仍有可能很差。而内部质量差的系统，外部质量肯定也不怎么样。牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间，接下来的日子里你就要一直为它付出代价。一旦我们放松要求，允许代码库中暗藏问题，后面就很难恢复质量了。
用生产率计算来估算 ：
1 ．得出估算生产率。
2 ．计算在不超出估算生产率的情况下可以加入多少故事。
生产率是“已完成工作总量”的一个衡量方式，其中每一个需求都是用它的原始估算进行衡量的。
下图中，左边是 sprint 启动时的 估算生产率 ，右边是 sprint 结束时的 实际生产率 。每个矩形都是一个需求，里面的数字表示这个需求的原始估算。
注意，这里的实际生产率建立在每个故事的原始估算基础之上，在 sprint 过程中对需求时间进行的修改都被忽略了。敏捷软件开发和精益制造的要求：把事情完全做完！达到可以交付的状态！事情只做了一半，它的价值就是 0( 也许还会是负数 ) 。
This Sprint’s Estimated velocity:
(Available Man-Days) * (Focus Factor) = (Estimated Velocity)
投入程度 (Focus Factor) 用来估算团队会在 sprint 中投入多少精力。投入程度低，就表示团队估计会受到很大干扰，或者他们觉得自己的时间估算太过理想化。要想得出一个合理的投入程度，最好的办法就是看看上一个 sprint 的值（对前几个 sprint 取平均值自然更好）
Last Sprint’s Focus Factor:
(Focus Factor) = (Actual Velocity) / (Available Man-Days)
生产率计算 ：
1， 直觉反应、
2， 基于昨日天气的生产率计算、
3， 基于可用人 - 天和估算投入程度的生产率计算
在大多数 sprint 计划会议上，大家都会讨论产品 backlog 中的需求细节。对故事进行估算、重定优先级、进一步确认细节、拆分，等等都会在会议上完成。
要想收到好的效果，不妨创建一些 索引卡 ，把他们放到墙上 ( 或一张大桌子上 )
这种用户体验比计算机和投影仪好得多：
大家站起来四处走动 — 他们可以更长时间的保持清醒，并留心会议进展。
他们有更多的个人参与感 ( 而不是只有那个拿着键盘的家伙才有 )
多个故事可以同时编辑。
重新划分优先级变得易如反掌 – 挪动索引卡就行。
会议结束后，索引卡可以拿出会议室，贴在墙上的任务板上。
把需求拆分成任务后，时间估算就变得更容易 ( 也更精确 ) 了
不要让任务拆分出现在产品 backlog 中 ，原因有二：
任务拆分的随机性比较强，在 sprint 进行中，它们常常会发生变化，不断调整，所以保持产品 backlog 的同步很让人头大。
产品负责人不需要关心这种程度的细节。
使用计划纸牌做时间估算
估算是一项团队活动 --- 通常每个成员都会参与所有需求的估算。为啥要每个人都参加？
1， 在计划的时候，我们一般都还不知道到底谁会来实现哪个需求的哪个部分。
2， 每个需求一般有好几个人参与，也包括不同类型的专长 ( 用户界面设计、编程、测试、等 )
3， 团队成员必须要对需求内容有一定的理解才能进行估算。要求每个人都做估算，我们就可以确保他们都理解了每个条目的内容。这样就为大家在 sprint 中相互帮助夯实了基础，也有助于需求中的重要问题被尽早发现。
4， 如果要求每个人都对需求做估算，我们就会常常发现两个人对同一需求的估算结果差异很大。我们应该尽早发现这种问题并就此进行讨论。
每个人都会得到如上图的 13 张卡片。在估算需求的时候，每个人都选出一张卡片来表示他的时间估算 ( 以 man-day 的方式表示 ) ， 并把它正面朝下扣在桌上。所有人都完成以后，桌上的纸牌会被同时揭开。这样每个人都会被迫进行自我思考，而不是依赖于其他人估算的结果。如果在两个估算之 间有着巨大差异，团队就会就辞进行讨论，并试图让大家对需求内容达成共识。他们也许会进行任务分解，之后再重新估算。这样的循环会往复进行，知道时间估算 趋于一致为止，也就是每个人对这个需求的估算都差不多相同。
重要的是，我们必须提醒团队成员，他们要对这个故事中所包含的全部工作进行估算。而不是 ” 他们自己负责 ” 的部分工作。测试人员不能只估算测试工作。
有些卡片比较特殊：
1， 0 = “ 这个故事已经完成了 ” 或者 ” 这个故事根本没啥东西，几分钟就能搞定 ”
2， ？ = “ 我一点概念都没有，没想法。 ”
3， 咖啡杯 = “ 我太累了，先歇会吧 ”
把需求拆分成任务
故事是可以交付的东西，是产品负责人所关心的。任务是不可交付的东西，产品负责人对它也不关心。
需求拆分成更小的需求
需求拆分成任务
1， 新组建的 Scrum 团队不愿意花时间来预先把故事拆分成任务。有些人觉得这像是瀑布式的做法。
2， 有些故事，大家都理解的很清楚，那么预先拆分还是随后拆分都一样简单。
3， 这种类型的拆分常常可以发现一些会导致时间估算增加的工作，最后得出的 sprint 计划会更贴近现实。
4， 这种预先拆分可以给每日例会的效率带来显著提高
5， 及时拆分不够精确，而且一旦开始具体工作，事先的拆分结果也许会发生变化，但我们依然可以得到以上种种好处。
最后界限在哪里
优先级列表：
1， Sprint 目标和演示日期。
2， 经过团队认可、要添加到这个 sprint 中的需求列表。
3， Sprint 中每个需求的估算值。
4， Sprint 中每个需求的 ” 如何演示 ”
5， 生产率和资源计算，用作 sprint 计划的现实核查。包括团队成员的名单及每个人的承诺 ( 不然就没法计算生产率 )
6， 明确每日例会固定举行的时间地点。
7， 把需求拆分成任务。这个拆分也可以在每日例会上做，不过这回稍稍打乱 sprint 的流程。
技术需求：需要完成但又不属于可交付物的东西，跟任何故事都没有直接关联，不会给产品负责人带来直接的价值。如：安装持续构建故武器、编写系统设计概览、重构 DAO 层、
Sprint 信息页
Sprint backlog
燃尽图
让团队坐在一起：
“ 一起 ” 意味着：
1． 互相听到：所有人都可以彼此交谈，不必大声喊，不必离开座位。
2． 互相看到：所有人都可以看到彼此，都能看到任务版
3． 隔离：如果你们整个团队突然站起来，自发形成一个激烈的设计讨论，团队外的任何人都不会打扰到。
产品负责人应该离团队很近，既方便团队成员走过来讨论问题，他也能随时踱到任务版前面去。但是他不应该跟团队坐在一起。为什么？因为这样他就无法控制自己不去关注具体细节，团队也无法 ” 凝结 ” 成整体 ( 即达到关系紧密、自组织、具有超高生产力的状态 )
怎样更新任务版
无论 sprint backlog 是什么形式，都要尽力让整个团队参与到保持 sprint backlog 及时更新的工作中来，我们曾经试过让 Scrum master 自己维护 sprint backlog ，他就不得不每天都去询问大家各自剩余的工作估算时间。这种做法的缺点是：
1． Scrum master 把太多时间用在了管理之类的工作上，而不是为团队提供支持，消除他们的障碍
2． 因为团队成员不再关心 sprint backlog ，所以他们就意识不不到 sprint 的状态，缺少了反馈，团队整体的敏捷度和精力的集中程度都会下降。
如果 sprint backlog 设计得很好，那每个人都应该很容易修改它。
怎样进行 sprint 演示
Sprint 演示是 Scrum 中很重要的一环。一次做的不错的演示，即使看上去很一般，也会带来深远影响。
1． 团队的成果得到认可，他们会感觉很好。
2． 其他人可以了解你的团队在做些什么。
3． 演示可以吸引相关干系人的注意，并得到重要反馈。
4． 演示是一种社会活动，不同的团队可以在这里相互交流，讨论各自的工作。这很有意义。
5． 做演示会迫使团队真正完成一些工作，进行发布 ( 即使是只在测试环境中 ) 。如果没有演示，我们就会总是得到 99% 完成的工作。有了演示以后，也许我们完成的事情会变少，但它们是 真正完成 的。这比得到一堆 貌似完成 的工作要好得多，而且后者还会污染下一个 sprint 。
Sprint 演示检查列表
1． 确保清晰阐述了 Sprint 目标。如果在演示上有些人对产品一无所知，那就花上几分钟来进行描述。
2． 不要花太多时间准备演示，尤其是不要做花里胡哨的演讲，把那些玩意扔一边去，集中精力演示可以实际工作的代码。
3． 节奏要快，也就是说要把准备的经历放在保持演示的快节奏上，而不是让它看上去好看
4． 让演示关注于业务层次，不要管技术细节。注意力放在 ” 我们做了什么 ” ，而不是 ” 我们怎么做的 ”
5． 可能的话，让观众自己试一下产品。
6． 不要演示一大堆细碎的 bug 修复和微不足道的特性，你可以提到一些，但是不要演示，因为他们通常会花很长时间。而且会分散大家的注意力，让他们不能关注更加重要的需求。
Scrum 回顾
回顾是 Scrum 中第二重要的事件 ( 最重要的是 sprint 计划会议 ) ，因为这是你 做改进的最佳时机 。如果没有回顾，团队就会不断重犯同样的错误。
回顾组织：
1． 根据要讨论的内容范围，设定为 1 到 3 小时
2． 参与者：产品负责人，整个团队。
3． 在不受干扰的情况下讨论。
4． 一般不要在团队房间中进行回顾，因为这往往会分散大家的注意力。
5． 制定某人当秘书。
6． Scrum master 向大家展示 sprint backlog ，在团队的帮助下对 sprint 做总结。包括重要事件和决策等。
7． 轮流发言，每个人都有机会在不被人打断的情况下讲出自己的想法，他认为什么是好的，哪些可以做的更好，哪些需要在下个 sprint 中改变。
8． 我们队预估生产率和时机生产率进行比较。如果差异比较大的话，我们会分析原因。
9． 快结束的时候， Scrum master 对具体建议进行总结，得出下个 sprint 需要改进的地方。
我们的回顾会议一般没有太规整的结构，不过潜在的主题都是一样的： ” 我们怎样才能在下个 sprint 中做的更好
Scrum 回顾白板：
图中的三列分别是：
1． Good : 如果我们可以重做同一个 sprint ，哪些做法可以保持。
2． Could have done better: 如果我们可以重做同一个 sprint ，哪些做法需要改变。
3． Improvements: 有关将来如何改进的具体想法。
第一列和第二列是回顾过去，第三列是展望将来。
团队通过头脑风暴得出所有的想法，写在即时贴上，如何用 ” 圆点投票 ” 来决定下一个 sprint 会着重进行哪些改进。每个人都有三块小磁铁，投票决定下个 sprint 所要采取措施的优先级。他们可以随意投票，也可以把全部三票投在一件事情上。根据投票情况，选出几项重点进行过程改进，在下一个回顾中，跟踪这些改进的执行情况。不要想一口吃成个胖子，这一点很重要，每个 sprint 只关注几个改进就够了。
定义你的验收标准
除了普通的产品 backlog 之外，产品负责人还会定义一系列的 验收标准 ，它从合同的角度将产品 backlog 中重要性级别的含义进行了简单分类。
验收标准规则的例子：
1． 所有重要性 >= 100 的条目都必须在 1.0 版中发布，不然我们就会被罚款。
2． 所有重要性在 50-99 之间的条目应该在 1.0 中发布，不过也许我们可以在紧接着的一个快速发布版中完成这些。
3． 重要性在 25-49 之间的条目也都是需要的，不过可以在 1.1 版中发布
4． 重要性 <25 的条目都是不确定的，也许永远不会用到。
对最重要的条目进行时间估算
为了制定发布计划，产品负责人需要进行时间估算，至少是要估算在合同中包含的故事。跟 sprint 计划会议一样，这是产品负责人和团队协作共同完成的 — 团队进行估算，产品负责人描述条目内容，回答问题。
统计一切因素，生成发布计划
有了时间估算和生产率，可以很容易的把产品 backlog 拆到 sprints 中：
3sprints=9 个星期 =2 个月。这是我们要向客户许诺的最后期限么？要视合同情况，范围限制有多严格，等等而定。我们通常都会增加相当多的时间缓冲，以避免糟糕的时间估算、未预期的问题和未预期的特性等造成影响。在这种情况下，我们可能会同意把发布日期定在三个月后，让我们 ” 保留 ” 一个月。我们可以每隔三个星期就给客户演示一些有用的东西，并在过程中邀请他们更改需求。
调整发布计划
每个 sprint 之后，我们都要看一下这个 sprint 的实际生产率。如果实际生产率跟估算生产率差距很大，我们就会给下面的 sprint 调整生产率，更新发布计划。如果这会给我们带来麻烦，产品负责人就会跟客户进行谈判；或者检查一下是否能够在不违反合同的情况下调整范围；或者他跟团队一起找出一些方法，通过消除某些在 sprint 中发现的严重障碍，提高生产率或是投入程度。
组合使用 Scrum 和 XP
Scrum 注重的是管理和组织实践，而 XP 关注的是实际的编程实践。这就是为什么它们可以很好的协同工作 —-- 它们解决的是不同领域的问题，可以互为补充，相得益彰。
结对编程
1． 结对编程可以提高代码质量。
2． 结对编程可以让团队的精力更加集中
3． 结对编程令人精疲力竭，不能全天都这样做。
4． 常常更换结对是有好处的。
5． 结对编程可以增进团队间的知识传播。速度快到令人难以想象。
6． 有些人就是不习惯结对编程。不要因为一个优秀的开发人员不习惯结对编程就把他置之不理。
7． 可以把代码审查座位结对编程的替代方案。
8． “ 领航员 ”( 不用键盘的家伙 ) 应该自己也有一台机器。不是用来开发，而是在需要的时候稍稍做一些探索尝试、当 ” 司机 ”( 使用键盘的家伙 ) 、遇到难题的时候查看文档，等等。
9． 不要强制大家使用结对编程。鼓励他们，提供合适的工具，让他们按照自己的节奏去尝试。
测试驱动开发 (TDD)
测试驱动开发意味着你要先写一个自动测试，然后编写恰好够用的代码，让它通过这个测试，接着对代码进行重构，主要是提高它的可读性和消除重复。整理一下，然后继续。
它会把开发 - 构建 - 测试这三者构成的循环变得奇快无比，同时还可以充当一张安全网，让开发人员有足够的信心频繁重构，伴随着系统的增长，设计依然可以保持整洁和简单。
增量设计
一开始应该保持设计简单化，然后不断进行改进 ; 而不是一开始努力保证它的正确性，然后就冻结它，不再改变。
代码标准
绝大多数程序员都有他们自己特定的编程风格。例如他们如何处理异常，如何注释代码，何时返回 null 等等。有时候这种差异没什么关系，但在某些情况下，系统设计就会因此出现不一致的现象，情况严重，代码也不容易看懂。这时代码标准的用处就会凸显，从造成影响的因素中就可以知道了。
在每个 sprint 中少做工作来提高质量
回到 sprint 计划会议上，简单来说，就是别把太多故事都放到 sprint 里面去！如果碰到了质量问题，或者验收测试周期太长，干脆就每个 sprint 少干点！这会自动带来质量提升、验收测试周期缩短、影响终端用户的 bug 减少，并在短期内得到更高的生产率，因为团队可以始终关注与新的东西，而不是不断修复出现问题的旧功能。相对于构建大量功能，然后不得不在惊慌失措的状态下做热修复来说，少构建一些功能，但是把它弄的稳定点儿，这样做要合算得多。
Sprint 周期 vs. 验收测试周期
解决下一个 sprint 和 bug 的冲突
“ 可以开始构建新东西，但是要给‘将旧功能产品化’分配高优先级 ”
一般我们完成一个 sprint 以后就会开始进行下一个。但是我们会在接下来的 sprint 中花一些时间解决过往 sprint 中留下的 bug 。如果修复 bug 占用了太多时间，从而导致接下来的 sprint 遭到严重破坏，我们就会分析问题产生的原因以及如何提高质量。我们会确保 sprint 的长度，使之足以完成对上个 sprint 中一定数量 bug 的修复。随着时间推移，经过几个月以后，修复上个 sprint 遗留 bug 所有的时间久会减少。而且当 bug 发生以后，所牵扯的人也更少了，所以不会总是干扰整个团队。现在这种做法已经的到了更多人的认可。 在 sprint 计划会议上，考虑到会花时间修复上个 sprint 的 bug ，所以我们会把投入程度设得足够低。
产品层次的 Scrum-of-Scrums
这个会议非常重要。我们一周开一次，有时候频率会更高。在会议上我们会讨论集成问题，团队平衡问题，为下个 sprint 计划会议做准备，等等。
议程安排如下：
1． 每个人围着桌子坐好，描述一下上周各自的团队都完成了什么事情，这周计划完成什么事情，遇到了什么障碍。
2． 其他需要讨论的跨团队的问题，例如集成。
团体层次的 Scrum-of-Scrums
会议的形式为：
1． 开发主管介绍最新情况。例如即将发生的事件信息。
2． 大循环。每个产品组都有一个人汇报他们上周完成的工作，这周计划完成的工作，及碰到的问题。其他人也会作报告。
3． 其他人都可以自由补充任何信息，或者提问问题。
Scrum master 检查列表
Sprint 开始阶段
Sprint 计划会议之后，创建 Sprint 信息页面
1． 在 wiki 上创建从 dashboard 指向所创建页面的链接。
2． 把页面打印出来，贴在通过团队工作区域之外的墙上，让经过的人都可以看到
给每个发邮件，声明新的 sprint 已经启动。邮件中要包括 sprint 目标和指向 sprint 信息页面的链接。
更新 sprint 数据文档。加入估算生产率、团队大小和 sprint 长度等等。
确保每日 Scrum 会议可以按时开始和结束。
为了保证 sprint 可以如期完成，需要适当地增删故事。确保产品负责人了解这些变化
确保团队可以及时得知 Sprint backlog 和燃尽图的最新状况。
确保存在的问题和障碍都能被解决，并报告给产品负责人以及开发主管。
在 sprint 结束时
进行开放式的 Sprint 演示
在演示开始前一两天，就要通知到每个人。
与整个团队以及产品负责人一起开 Sprint 回顾会议。开发主管也应该受邀参加，他可以把你们的经验教训大范围传播开来。
更新 sprint 数据文档。加入实际生产率和回顾会议中总结出的关键点。
过程与工具、面面俱到的文档、合同谈判、遵循计划
个体与交互 胜过 过程与工具
可以工作的软件 胜过 面面俱到的文档
客户协作 胜过 合同谈判
响应变化 胜过 遵循计划
网上有个ＰａｎｇｏＳｃｒｕｍ 现在能支持Ａｎｄｒｏｉｄ了。大家可以去看看，不开代理也能上。 http://androidnewlab.pangoscrum.com/
Own Blog： http://www.stayalways.com/
作者： Leo_wl
出处： http://www.cnblogs.com/Leo_wl/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
版权信息查看更多关于敏捷开发Scrum 学习笔记，适于移动开发的详细内容...