硝烟中的scrum和xp 第一次读书笔记

硝烟中的 Scrum 和 XP

scrum的关键之一是时间盒，scrum关注生产率

scrum的理论和框架其实很简单，我们更多的关注是如何进行scrum的实践，每种实践的方法和方式。

本书名字的定语“硝烟中的”，这个非常贴切，我这短短一两个月的敏捷导入充分体现到了“战争”无处不在。理念的灌输，工程实践的落地，在制品的限制，DoD的规则没有任何一点能够很顺利进行的。

还好我自己深信敏捷的理念，我相信能够带来一定的价值，否则是真的做不下去了。

书中对scrum和xp的定义，scrum更多的是管理和组织实践，而xp更多的关注的是工程实践（编程实践）。

scrum仅仅定义了我们要做哪些事，以及如何开展和实施，但具体质量如何达到内建的效果主要是通过编程实践。

下面是书中介绍的scrum各主要的活动实践方法：

我们怎样编写产品 backlog

PS：我们的不足，产品的backlog编写的很不完善，尤其是演示标准，其实也就是验收标准没有被细化，我们会有具体的请求者以及上线后的验证环节。

注意：产品负责人之外的人也可以向产品 backlog 中添加故事，但 是他们不能说这个故事有多重要，这是产品负责人独有的权利。他 们也不能添加时间估算，这是开发团队独有的权利。

PS：虽然看板不明确规要对故事进行估算，但还是推荐进行基本的估算，估算的方式有很多种，后面有介绍

我们怎样制定 sprint 计划

� sprint 目标。

� 团队成员名单（以及他们的投入程度，如果不是 100%的 话）。

� sprint backlog（即 sprint 中包括的故事列表）。

� 确定好 sprint 演示日期。

� 确定好时间地点，供举行每日 scrum 会议

PS：对于Scrum来说，迭代会议非常重要，团队要能够明确此次迭代的目标，对迭代故事有清晰的了解和估算，在前期可能会出现会议时间不好把控，方式方法不太准确，所以tw的需求梳理会有一定的必要，并且两个会议之间要留一点点空窗期，使得大家对故事背景场景以及故事基本设计方式能够稍微有一点思考，使得计划会议更加有效。

PS：敏捷我们说不要再质量上让步，我非常赞同这个观点。不过还有一点，对于用户来说什么是质量，质量体现在什么方面；不同的产品看待质量的方式不同，我们投入的侧重点应该也不同。对于一个SNS它的事务的强一致性要求不高，但是对交互体现要求很高。对于我们boss系统和银行的系统和钱相关，事务强一致性是第一要求，所以ui和ux上的质量妥协也是正常范围。

Scrum有一个很重要的活动规则是，节奏。节奏对于工作和生活都是这样，稳定的节奏使得人工踏实，更利于稳定的输出产能。所以迭代长度一定要尽量稳定。同时要保持相对较短的迭代周期。更短的迭代周期管控风险，快速交付获得反馈等等好处，也能够消除“潜规则”下的遗忘。

指定scrum的计划是要根据历史产能（生产率），并留出一部分富余时间，要给团队和个人思考和改进的时间。

定义完成非常重要，2:8原则，没有清楚的定义会使得估算和计划没有意义。

时间估算的方法：

纸牌估算（团队相互备份非常的）

资深和普通开发者一起近似取平均（团队中绝大多数还是以专人专模块负责方式运作的，看板推荐的方法，现阶段我也比较认同）

故事拆分和故事拆分为任务：

对于故事的拆分我们团队订的规则是，如果可以拆分为可交付的单元那么拆，否则不予拆分。任务呢，尽量拆一下，否则时间估算和风险预警都不好做，如果团队内还有明确的测试和开发环节，如果不进行基本的拆分会导致迭代前期测试“无事可做”，后期挤压。当然别的工程实践可以解决此类问题如XDD，测试前移等。

技术故事：