硝烟中的 SCRUM 和 XP

一、如何写产品的BACKLOG

1. ID、NAME、重要性分数、如何演示、初始点数、备注；可选字段：类别（用于快速筛选）、需求提出者（用于开发过程中反馈）、Bug ID（用于与BUG关联）；
2. 始终让BACKLOG只关注于业务层面，而非面向技术的解决方案（技术方案最多做为一项可选的备注）；方法：针对BACKLOG，不断的问产品负责人：这是为什么呢？

二、如何准备Sprint会议

1. 在开会前，必须有产品的BACKLOG；并且给BACKLOG的每个条目打好重要性分数；
2. 只有一个产品BAKCLOG，以及只有一个产品负责人（以免冲突）；
3. 其他人也可以添加BACKLOG故事，但重要性分数由产品负责人填写（特殊权利）；
4. 产品负责人必须明白每一条BACKLOG的含义；（如果他人添加的故事，产品负责人必须弄明白它为什么在这里；

三、怎么制定Sprint计划

1. 要得到的成果：Sprint目标、Sprint的Backlog、参与人名单及投入程度、每日站会的时间与地点、确定好Sprint演示日期；
2. 注意事项：产品负责人必须参加、宁可减少范围不可牺牲质量（不然后续要一直为错误买单）；
3. Sprint的任何事情都要有一个时间盒，所以，Sprint会议也一样；（先尝试4个小时，半天时间）；
4. 会议进程：1）30分钟，产品负责人概括Sprint目标，介绍Backlog，确定演示的时间和地点；2) 90分钟，团队成员估算每条Backlog的时间（点数），必要的情况下，拆分Backlog，产品负责人调整重要性分数；所有重要性高的故事，都需要填写“如何演示”；3）60分钟，团队选择要放入Sprint的故事，计算生产率，用于核算工作安排的基础；4）把故事进一步拆分成任务；5）安排固定的每日例会的时间和地点；
5. Sprint的长度，据说3周让大家比较舒服。但是不管如何，多试验几次找到一个合适的节奏；（短有短的好处，迭代更快，但也有短的压力，比如开会和演示更频繁）
6. 定义“完成”：测试人员说了算，将责任转到测试人员的身上（当然，测试人员要有自己的专业测试清单）；其他几种做法：随时可以上线；已经部署到测试服务器，随时等待测试组进行验收测试；（如果各成员有困惑，则在故事中多增加一个字段叫：何谓完成？
7. 用扑克牌做时间估算：0、0.5、1、2、3、5、8、13、20、40、100；（单个故事尽量控制在2-8个点）；
8. 明确故事内容：注意填写“如何演示”那个字段；好处：可以避免大家对故事的理解有偏差；
9. 故事拆分成任务：如果时间来不及，或者故事很简单，可以不做；但通常如果时间够的话，建议要做，因为这样大家的估算会更加准确，而且也会发现一些潜在的工作；
10. 关于BUG：处理方式有好几种，先尝试简单的一种：即将BUG打印出来，带到sprint会议上，与其他故事一起贴到墙上去；
11. 关于技术故事的几种做法：1）将技术故事变成可以衡量价值的业务故事，方便产品负责人判断优先级；2）将其放入某个故事中作为一个任务；3）如果都不行，单独列出来，找产品负责人好好谈一谈利弊；

四、如何让别人了解我们的Sprint

1. Sprint计划会议结束后，ScrumMaster建一个wiki页面，内容包括：sprint目标，Backlog故事，点数，时间（开始、Demo、每日例会），成员；
2. 给大家发个垃圾邮件，贴上这个页面的链接；
3. 打印这个页面，贴在团队办公室的门口；
4. Sprint的演示来临前，再发个垃圾邮件，欢迎大家来看演示；

五、如何编写Sprint Backlog

1. 找一面墙，2*2平方米，贴上白纸；
2. 分成4列，分别为待完成、进行中、已完成，还有一列燃尽图，加上计划外工作，加上下阶段的Backlog;
3. 故事+Task；故事按顺序来做，不要搞反顺序；

六、如何布置团队房间
让团队做在一起，定义：互相听到、互相看到、与其他团队隔离（屏蔽大多数噪音即可）；
让产品负责人无路可走（不要坐在一起，以免陷入细节，但要随时看到和找到讨论问题）；
让团队经验和教练无路可走；（一开始尽量贴近指导，之后逐渐远离，让团队形成自组织性）；

七、怎样进行每日例会

1. 固定时间、固定地点，汇报昨天做了什么，今天要做什么，碰到什么困难；更新Backlog的时间估算，或者移动它；
2. 让大家参与更新任务板；会议结束时，有人负责算出剩余工作的时间估算之和；
3. 处理老是迟到的人：弄个存钱罐吧，迟到的人投点钱，以后做活动经费；
4. 处理不知道该干嘛的人：给他分配任务、安排他打杂；如果有人老是这样，如果他不重要，那将他挪出团队，如果他很重要，让他跟别人结对，让另外一个人充当他的“牧羊人”，指导他要做什么；（以上都是无可奈何的办法，但多少有点效果）

八、如何做演示
演示有很多好处，其中一条是让大家真正完成一些工作，而不是基本完成；好的演示给人的工作成果带来肯定，坏的演示促使大家真正关注任务本身；
演示只关注于业务层面，即我们做了什么，而不是技术层面的如何做；
不要演示BUG修复和一些不重要的细节，保持快节奏，不需要弄得好看；可能的话，让观众试一下产品；

九、如何做Sprint回顾

1. 回顾的目的，不是为了让自己想到好点子，而是让这个点子出自团队的讨论和思考，让成员接受它更加容易；
2. 时间安排1-3个小时；找一个不受打扰的地方；指定一个人做秘书，写会议记录；ScrumMaster根据Backlog对Sprint做总结，包括重要决策和事项,引导大家回顾发生过的事情及完成的工作；团队每个人不被打断轮流发言，主题是哪些做法好，哪些做法可以改进，哪些需要改变；对比预估与实际生产率的差异，分析原因；Scrum总结大家的具体建议，得出下一个Sprint需要改进的地方；
3. 可以弄个白板，借鉴头脑风暴的做法，将大家的建议写下来贴到白板上面；针对ScrumMaster总结的改进建议，每个人进行投票，每人3票，随便投，全部投给一个建议也可以；
4. 一个好问题：如何时间可以倒流，那你觉得哪些事情你会换一种方式来做？
5. 有些建议不一定真的要去做任何改变，因为它有可能在下一个sprint中就自动消失了；

十、如何在Sprint之间做休整
在回顾和计划之间，至少要有一个不需要考虑Sprint的夜晚，最好能够间隔一个周末；
如果可以的话，弄一个实验日，在这一天，大家不用工作，而是在办公室里，自由安排自己的时间，学习自己想学习的东西；（源自google的做法）如果可能的话，让它处在2个sprint之间；