走在敏捷的路上（1）

很就没有写文章了，一看都是半年前了，半年了，敏捷也实施了这么久，现在来回顾一下半年的路程把。

Product Owner多么重要， 很重要，在一个项目里，你必须要有这么一个人知道我们需要做什么，我们需要给客户提供什么，知道什么对于客户最有价值。

Strum Master 呵呵，牧羊犬的角色，保护整个团队不被外人干扰，保证整个团队按照敏捷的思想在开发，需要很多的激情还有自律，以及良好的沟通能力，信任的力量，这个角色是没有权利的角色，但是在做着实际的指导工作。

实施敏捷的时候，前几次迭代周期的时候，我们基本就完全是看书来的，按照书一步一步的走，推广TDD以及结对编程，每天的站立会议都很有意思，呵呵，不过由于对Strum理解的很肤浅，对于用户故事划分不是很仔细，而且同时开始了几个用户故事，造成第一个周期的完成时候手工测试的紧张。

计划会议，首先PO会确定所有的仓库存货，把需求划分为独立的用户故事，，给出每个用户故事的优先级别。
如何更好的划分用户故事，在书中有几个要点，独立，小，可测试，可估计大小等等。
可是划分好的用户故事的确很难，尤其是我们离真正的客户很远的时候，现在还在实践中。

计划会议时候团队来评估每个用户故事的大小，再评估每个用户故事大小的时候我们需要选取一个用户故事基础作为参考点。

这个就是计划游戏，抛去个人强弱，业务熟悉与否的评估游戏，所有的团队成员在互不干扰的情况下给出自己对于用户故事大小的数值，每一次结束最大的和最小的发表自己的意见。

最后当团队达成一致时候确定一个故事的大小

第一个Sprint Backlog选择的用户故事，首先我们得确定每次Sprint的长度，2-4周都是比较合适的，第一次实施的时候我们按照以往的经验选择了3个故事，然后将每个故事拆分成为任务，确保每个任务在1-2天能够完成，当所有的故事都拆分成为故事之后，按照所有任务的时间画出燃尽图。

站立会议，站立会议是每天的确定一个时间集合再一起，每个成员轮流回答三个问题，
1.昨天你做了什么
2.今天你准备做什么
3.再你前进的道路上有什么阻碍。

每个成员会在自己选择的任务上签上自己的名字，以及更新任务现在需要完成的时间。
然后集合所有的时间给出我们现在燃尽图上，还剩余的时间于天数。

由于经验不足，我们在第一次Sprint的时候，三个故事一起开始，导致所有的故事都差不多都要在Sprint要结束的时候完成，有一个故事因为对其中一个任务的理解不清无法按时完成，这个Sprint我们只完成了两个用户故事。

下一步我们准备制定一个规矩就是，不允许同时开始两个以上的故事。