《硝烟中的Scrum和XP》读书笔记之二

引言：SCRUM不是方法学，它是一个框架。

 

（二）SCRUM实施及注意事项

4.SPRINT演示会议
1）作用：做演示会迫使团队真正完成一些工作；得到相关干系人的重要反馈；团队间相互交流等。
2）sprint演示注意事项：
a.确保清晰阐述了sprint目标。
b.不要花太多时间准备演示。
c.要把准备的精力放在保持 演示的快节奏上。
d.让演示关注于业务层次。
e.可能的话，让观众自己试一下产品。
f.不要演示一大堆细碎的bug修复和微不足道的特性。

 

5.SPRINT回顾会议
1）sprint回顾是scrum中第二重要的事件（最重要的是sprint计划会议），因为这是你做改进的最佳时机。
2）sprint回顾的内容：（主题：我们怎样才能在下个sprint中做得更好）
a.根据讨论内容范围，设定时间为1～3小时；参与者：产品经理、整个团队。
b.在一个不受干扰的地方进行回顾（注：我们一般不会在团队房间里进行回顾，因为这往往会分散大家的注意力）
c.scrum master向大家展示sprint backlog，在团队的帮助下对sprint做总结。
d.每个人会轮流发言。（在不被打断的情况下，讲出自己的想法。他认为什么是好的，哪些可以做的更好，哪些需要在下个sprint中改变。）
e.我们对预估生产率和实际生产率进行比较。并分析原因。
f.快结束时，scrum master对具体建议进行总结，得出下个srpint需改进的地方。
3）回顾的白板。分为三列：做得好的、需改进的、如何改进。如图：p70
4）回顾会议通过“圆点投票”来决定下一个sprint会着重进行哪些改进，选出5项要重点进行的过程改进，并在下个回顾会议上，他们会跟踪这些改进的执行情况。
5）团队间传播经验（参加所有团队的sprint回顾会议的scrum教练充当知识桥梁）
6）回顾会议识别出来的问题及解决措施：
a."太多的外界干扰"---让团队在下一个sprint上减少投入程度；让团队在下个sprint上把干扰因素记录更清楚些；所有干扰因素转给scrum master或产品经理；让团队指定一个人充当“守门员”，所有的干扰都要经由他处理。
b."我们做出过度的承诺，最后只完成了一半"---下一次sprint,团队不会过度承诺。

 

6.SPRINT休整时刻
1）需要sprint休整期的理由是：sprint演示和回顾结束后，团队和产品负责人都有一大堆想法需要消化。如果他们立刻计划下个sprint，那就没人能有机会消化现有的消息或是学到的经验，产品负责人也没有时间在sprint演示后调整优先级。
2）sprint休整时间安排的底线：不在同一天举行sprint回顾和下一个sprint计划会议。
3）每个sprint间安排一个实验日，这样既能得到自然的休息，开发团队也能让自己了解最前沿的知识。

注意：
1）scrum注重的是管理和组织实践，而XP关注的是实际的编程实践。
2）XP实践：旧代码上进行TDD是难上加难，刚开始应想办法提高手工测试的效率，然后再考虑将真正的测试变成自动化执行。
3）XP实践：代码集体所有权：在结对编程中频繁交换结对，会自动把代码集体所有权提到一个很高的级别。
4）XP实践：增量设计、持续集成、充满信息的工作空间、代码标准、可持续的开发速度/精力冲沛的工作。
5）把验收测试阶段缩到最短的做法：其一：提高scrum团队交付的代码质量；其二：提高人工测试工作的效率。
6）提高scrum团队交付代码质量的方法：把测试人员放到scrum团队中；每个sprint少做点工作。
7）实践：验收测试不作为sprint的一部分，因为sprint是有时间盒限制的，而验收测试的时间却很难固定。
8）sprint周期与验收测试周期安排：可开始构建新东西，但要给“旧功能产品化”分配高优先级。
9）注：如果修复bug占用太多时间，从而导致接下来的sprint遭到严重破坏，我们就要分析问题产生的原因及如何提高质量。我们会确保sprint的长度，使之足以完成对上个sprint中一定数量bug的修复。
10）别把最慢一环逼得太紧。（例如：如果最慢一环是只能完成3个故事点，那这个sprint应只安排3个故事点，并用多余时间来攻克这个瓶颈。）
11）多个scrum团队的经验：宁可团队数量少，人数多，也比弄上一大堆总在互相干扰的团队强。要想拆分小团队，必须确保他们彼此间不会产生互相干扰。
12）scrum中，团队分割确实很困难。不要想的太多，先做实验，观察虚拟团队，然后确保在回顾会议上有足够的时间来讨论这种问题。迟早就会发现针对你所在环境的解决方案。需要重视的是，必须要让团队对所处环境感到舒适，而不会常常彼此干扰。
13）最佳的团队尺寸：5～9被公认是“最佳的”团队构成人数。
14）如果多个scrum团队开发同个产品，建议同步多个sprint。这样做的原因：更小管理压力、所有团队可在一个sprint向同个目标努力。
15）团队中分配人手：先集中式控制（即让指定的人来做分配），然后再用分散式优化（让团队自己决定）。
16）“团队凝聚力”是scrum的核心要素之一，如果一个团队合作工作达多个sprint之久，他们就会变得非常紧密，他们会学会如何达成“团队涌流”（group flow）。
17）注意：在scrum团队中含有兼职成员一般都不是什么好主意。----如果确实需要该兼职人员，最好让他有一个主要从属的团队。找出最需要他的团队，把它当作他的“主队”。如果没有其他人把他拖走，那他就得参加这个团队的每日scrum会议、计划会议、回顾会议等。
18）scrum of scrums实际上是一个常规会议，是为了让所有的scrum master聚到一起交流。
19）团队层次的scrum of scrums：每个产品的全部团队成员都参加，由开发主管介绍最新情况，再轮流由每个产品组的代表汇报他们上周完成的工作、这周的计划、及碰到的问题，最后其他人可自由补充任何信息或提问；会议时长：15分钟。
20）多个scrum团队：团队避免在同一时刻进行每日例会。
21）救火团队：有两项工作，其一救火；其二保护scrum团队远离各种干扰，包括挡开那些不知从何而来的、新增的临时特性需求。
22）多团队回顾：在sprint计划会议上（所有团队均会参加），第一件事情就是让每个团队中找出一个发言人，站起来总结他们回顾中得出的关键点。每个团队都有5分钟的时间，然后我们会进行大约10～20分钟的开放讨论。之后稍作休整，再开始真正的sprint计划。
23）scrum master职责：
a.sprint开始阶段：sprint计划会议后，创建sprint信息页（在wiki创建，并把该页面打印贴在你们工作区域之外的墙上）；给公司所有人发邮件，声明sprint已启动（邮件内容包括：sprint目标和sprint信息页）；更新sprint数据文档（加入估算生产率、团队大小和sprint长度）。
b.sprint每一天：确保例会按时开始和结束；为保证sprint可如期完成，需适当增删故事（并确保产品经理了解该变化）；确保团队可及时得知sprint backlog和燃尽图最新状况；确保存在的问题和障碍都能被解决，并报告给产品经理及开发主管。
c.sprint结束时：进行sprint演示；在演示开始前一两天，就要通知到每个人；与整个团队及产品经理一起开sprint回顾会议，开发主管应受邀参加，他可以把你们的经验教训大范围传播开来；更新sprint数据文档（加入实际生产率和回顾会议中总结出的关键点）。