读《SCRUM与极限编程》笔记1

按照时间顺序：
1、Backlog条目或者故事包含元素：ID、名称、重要性、How to demo、估算、备注，这些是主要的，一般必须会有，还可以按照需要增加例如：类别、组件、请求者、bug关联ID等。
2、产品backlog只停留在业务层面上，不包括技术术语，如果有技术术语，就要向产品负责人一直提问，直到询问出真正原因。
3、Sprint plan前的准备：
（1）产品backlog必须存在；且按照优先级排序；只有一个产品backlog和一个产品负责人；产品负责人了解每个backlog需求。
当然这些例如backlog条目、优先级都是可以调整的。
（2）Sprint plan会议举行：最好事先定义时间盒，避免无休止的讨论。
（3）产品负责人必须参加，如不能参加，指派代表或者延期举行会议；团队也全员参加；（原因：范围、重要性、估算三个重要制约因素中，范围和重要性有产品负责人掌握，而估算由团队掌握，三个元素经过协作讨论达到平衡。另外还有质量这个制约因素，包括外部质量和内部质量，外部质量例如用户界面友好性、性能，内部质量例如可维护性，外部质量可以通过与产品负责人沟通将优先级调到下个sprint或者牺牲部分范围达到，而内部质量是团队不能放弃的）
（4）团队有大概的sprint的周期时间，例如3个星期
（5）了解团队的生产率，一个sprint可以完成的故事点数
4、Sprint plan会议目的：
（1）Sprint整体目标，这个目标是业务层面的，外部团队也可以理解的目标
（2）团队成员名单
（3）Sprint backlog（将产品backlog–》sprint backlog）
（4）确定好sprint演示日期
（5）确定好scrum时间地点
（6）确定sprint长度
5、执行sprint plan会议：
（1）产品负责人如何控制将哪些未放入sprint backlog放入到sprint backlog中呢？
调整backlog条目优先级、将一个大的backlog条目拆分成多个小backlog条目、调整某条backlog范围将其变小；
（2）团队？
根据本能直觉，也就是以往经验判断
用生产率估算：了解团队生产率、根据生产率计算可以完成的故事
团队生产率是经过历时数据得出的，如果是初次进行，可以大概，但要记录与分析作为后续参考数据，经历的sprint多了自然就会越来越准确。
团队生产率：一个sprint可以完成的总计故事点数。故事点是一种相对估算方法，首先团队估算出作为参照的一个故事点的生产率，例如一人天可以完成的需求。后续以此作为参照。
（3）如何在会议上实现估算、拆分、优先级调整呢？步骤：

• 使用backlog索引：而不是通过一个人操作电脑讲解，其他人看投影的形式，通过物理索引，提高大家参与度和精神集中程度，提高效率。
• 团队分成不同的组分别拆分不同的故事，将即时贴访日每个不同的故事下边。通过拆分，可以更准确的进行估算。故事的大小：一般一个故事2-8个人天。一个sprint完成5-15个故事。一个团队的生产率大约是40-60.原则：保证每个故事可以交付价值。
• 为每个故事定义完成标准，产品负责人与团队沟通一致。
• 以上两个做好后，团队可以开始估算了，估算需要团队全员参与，可以使用纸牌估算方法，全员的意义是每个成员不是只针对自己负责的部分，而是整个故事（不同角色：测试、开发、页面等等）进行估算。全员参与如果结果差异大可以提前发现问题，规避风险；此时，团队不知道谁进行哪项任务；全员参与那么全员都了解需求，这样利于后续互相帮助和规避风险。
  （4） 将故事拆分成任务：故事是产品负责人关注的，任务是开发团队关注的；故事是可交付的，任务是不可以交付的。可以在计划会上做也可以会后团队自己做。
  （5）定下Scrum每日例会的会议地点和时间
  
  （6）、sprint plan会议事项优先级：
  优先级一：sprint目标和演示日期
  优先级二：经过团队认可，要添加到这个sprint的故事列表
  优先级三：sprint中每个故事的估算值
  优先级四：故事如何演示
  优先级五：生产率和资源计算，用作sprint计划的现实核查，包括团队成员的名单及每个人的承诺（不然就没法计算生产率）
  优先级六：明确每日例会的时间地点
  优先级七：将故事拆分成任务，也可以不在这个会议上作，在每日站会上做。

？？我没有理解将故事拆分成任务的意义？
为了更好的估算，提前发现问题，规避风险。
例如一个故事故被拆分成10个任务，任务是不可以再分的颗粒度了吗？每个任务的故事点可以估算出来，将所有任务的故事点汇总就是一个故事的总体故事点。
领取任务时，可以按照任务领取。
这个任务最好在sprint plan中做，也可以在每日站会上做，但是会打乱sprint的节奏。

？？有一些技术任务是否放到用户故事中？
1、可以将技术故事变成普通故事，放到代办列表
2、单独存放
3、po不同意，可以通过预估生产率和投入程度来沟通
（7）如何处理bug与产品backlog？
-将bug加入到jira管理；

• bug列表由PO带到plan会议上，将重要bug的优先级标识，与其他故事一起贴到墙上；
• 创建指向bug的故事；
• 将bug作为一项任务，调整投入度，用最低的投入度比如说50%，保证bug被修改；

6、sprint plan终于结束了！敏捷的其中一个原则就是“透明”，那么我们如何让大家都知道我们的状态呢？
（1）、建立sprint信息板，贴出来

（2）、发送sprint即将开始的通知邮件
（3）、在wiki上公布sprint开始的消息
这样就没有人不知道团队的状态了。
7、scrum master创建sprint backlog，这个任务在plan会议后，在每日站立会前，找到墙：

8、按照计划召开每日站会，几天后sprint backlog会变成这样：

9、将目光投向燃尽图
燃尽图可以不将休息日放入，否则会出现横线，看起来像是出现问题。以下几种出现警戒的燃尽图：
（1）
（2）

10、怎样布置团队的房间

（1）设计墙：重要文档、设计图纸等
（2）团队尽量坐在一起
（3）PO坐在距离团队很近的位置，方便双方互相沟通，但不要坐在一起，否则会影响PO判断哪些是他该关心的，哪些是他不该关心的。
（4）如果出现master和经理是一个人，那么为了团队能实现自管理，那么尽可能贴近团队，过一段时间就离开。参加时看看有什么改进之处在回顾会上进行改善。可以让团队自由发挥，除了sprint演示外。
11、我们怎样进行每日站会？
（1）、更新任务板，master可以在开会的时候就做了，或者在开会前做，只要定好规则就可以：
根据完成情况移动任务板上的即时贴
如果更新了时间估算，那么将旧的划掉，加上新的
为经计划的任务，新加一个即时贴
（2）、建立规则，处理迟到的人员：例如放一个存钱罐，迟到的人每次放入固定数额的钱
（3）、会后有人算出剩余工作的时间估算，（例如人.天，也就是故事点）将燃尽图更新。（故事点单位也可以是人.时，但是要估量下是否需要那么细粒度的管理）。
12、我们怎么进行sprint演示
（1）演示的必要性:
演示可以让团队有成就感
演示让其他团队了解他们在做什么
演示吸引相关干系人，得到反馈
演示可以让不同的团队互相交流
演示会迫使团队必须完成一些功能
（2）演示注意事项：
确保清晰阐述sprint目标，如果有人不了解情况，可以画上些时间简单介绍下
不要花太多时间准备演示
演示的节奏要快，将重点放在快节奏上，而不是好看上
演示业务层面，不需要技术层面的演示
可以的话，让观众自己试一下产品
不要花精力演示细碎的bug修复和微不足道的特性
13、怎么做sprint回顾
scrum中第二重要的会议就是回顾会议，第一重要的是plan会议。
回顾会的必要性：
如果个人产生的改善建议直接提给团队，大家会接受吗？而如果是团队集体讨论和决定的点子，大家就容易接受得多。
回顾会的举行：
（1）、根据讨论的范围，将时间设定在1到3个小时
（2）、参与者包括团队、PO、、scrum master
（3）场所可以不是在办公室，可以是休息间等等，只要保证不被打扰
（4）、指定秘书
（5）、master根据sprint backlog给大家做总结，可以在团队的帮助下，包括重要事件和决策。
（6）、大家轮流发言，每个人都有机会在不被打扰的情况下说出自己的想法，包括之前做的好的部分、哪些可以做的更好、哪些需要再下个sprint中改变
（7）对预估生产率和实际生产率做比较，如果差距比较大，分析原因
（8）master对会议进行总结，总结出下个sprint要做改进的地方
总结来说，回顾会就是：我们怎么能在下个sprint中做的更好。
回顾会也可以用白板:

白板包括几个条目：
1、good做的好的部分
2、could have been better可以做的更好的部分
3、improvement待改善部分
第1和第2是回顾过去，第3是展望未来。团队头脑风暴将所有想法整理为即时贴，然后贴到墙上，所有人有5票权利，选出投票最多的5个建议，不要想着一口吃成一个胖子，要有重点的进行改善。
注意：有些小问题或者小牢骚，可以不用变，寄希望于自己改变或者自己变好。否则只要提出问题就变，那么团队的代价是很大的，并且后续大家针对小问题都不提了。
14、sprints间的修正时刻：
每个sprint之间要有几天的休整日：
（1）、po、master整理思路，将之前的工作整理
（2）、团队按照自己的意愿整理资料、开发自己的项目、学习等等
15、怎么处理发布计划，处理固定价合同
（1）、产品负责人：定义验收标准，例如哪些故事必须发布，哪些可以延后发布等，例如：

（2）产品负责人和团队：产品负责人负责将团队聚到一个房间，他将所有故事讲一遍，团队再进行工作，产品负责人在旁边提供必要的帮助。估算的原则是团队参与、不要让他们花太多的时间、确保他们只是粗略的估算不用承诺。会议不能花太多时间，否则会影响团队此次的sprint，团队也要保证PO了解此情况。
（3）、下面是一个估算的例子，用的是故事点：

（4）、估算生产率
假设投入程度是50%，sprint的长度是3个星期（15天），团队是6个人，那么每个sprint是90人天，乘50%，就是45个人天，也就是45个故事点。（假设一个故事点是一个人天）。
如果每个故事的估算都是5个故事点，俺么一个sprint可以完成9个故事。
（5）、统计一切因素，生成发布计划：

三个sprint，9个星期，两个月，再根据合同情况增加缓冲时间，一个月。避免风险。
我们可以每隔三个星期就给客户演示一次，也可以欢迎他们修改需要，当然要根据合同情况而定。
（6）、调整发布计划：
如果实际生产率低于估算生产率，可以调整生产率，更新发布计划。这样PO就需要与客户重新确定上线时间，可以将某个功能延后发布，或者延长时间，与客户确认。对于客户来说可能是坏消息，但是至少我们是诚实 的。尽早给客户提供了选择：是准时发布重要的功能、还是延迟发布所有的功能。