敏捷在路上(二）迭代开发和用户故事
引言：在上一篇中，我聊到了敏捷可以通过小步前进来最大程度的减少浪费。接着我们来聊聊敏捷是如何小步前进的。
在瀑布式开发中我们的步子迈的太大了，导致我们首先无法快速应对变化，其次我们需要付出很大的代价来应对变化。而敏捷迭代开发则可以让我们小步的往前走，以一种增量式的模式来进行开发。那么敏捷迭代中迭代的是什么呢？我觉得迭代的交付可工作的软件。
首先，我们看看敏捷迭代大致的流程：
- 首先和用户讨论需求，定义系统的personas，并将用户需求划分成一个个的用户故事
- 和用户一起将所有的用户故事按照关联和优先级划分到一个个的迭代之中
- 保证在每个迭代都可以交付给用户可工作的软件
接着我们展开每个过程。而在第一个过程中的personas就是我们系统的用户类型，比如我们会有administrator，member，user等等，而另外一个非常重要的的产出物就是
用户故事
用户故事必须满足INVEST原则：
- Independence：一个和其他用户故事紧密关联的用户故事会给我们的开发带来很大的麻烦，使我们在开发中不得不考虑相关联的用户故事。
- Negotiable：用户故事应该是我们可以和用户协商的，因为完成任何一件事情往往都很多不同的途径。
- Valuable：用户故事必须是有价值的，如果这个用户故事对于用户而言没有任何价值，我们的开发也就没有任何意义。
- Estimate：如果一个用户故事的开发时间不可估计，那么对于我们迭代将是非常大的风险。
- Small：足够小的用户故事可以让我的步子迈的小一点，这样当需求变了我们我们的浪费也就相对小。
- Testable：如果一个用户故事不可测试，那么我们如何知道这个用户故事我们是否完成了呢？
As a stakeholder
I want to do ...
So that I can ...
我们可以以这样模式去看我们的需求，来获得一个个用户故事。对于一个用户故事通常会有三个元素：title，narrative，acceptance criteria。title很简单大家都明白，而narriative就是我上面那样的句子。BA会把title和narrative写在一个小小的故事卡上。那么acceptance criteria呢？别急，当我们的Dev拿到一个故事卡后，他只能大概知道要做什么，所以他就不得不主动的去和BA讨论（因为在敏捷中，我们非常强调人与人的沟通和交互），讨论的结果作为acceptance criteria写在故事卡的背面。这个dev找BA讨论用户故事产生acceptance criteria的过程我们称之为用户故事的Kick Off。Kick Off之后，一对dev就开始以TDD的方式来实现这个用户故事（TDD我会在后面单独来聊）。当然在实现过程中，任何时候有需要不清楚dev都会应该主动找BA确认，将结果作为一个新的acceptance criteria补充在故事卡的背面。当dev实现完成用户故事，一般会找来QA做一个mini showcase。QA测试完成不能算用户故事结束，用户故事的完成的标志是一个迭代结束时，我们需要给用户showcase来我们这个迭代里面的所有用户故事，只有用户点头了，这时这个用户故事才是Sign Off了。这里有一个要强调的就是，如果dev完成的用户故事被QA发现问题来了，算是用户故事的push back，不能算defect。只有在Sign Off之后发现问题才叫defect（原因是，一个迭代内我们QA将用户故事的push back当做defect，往往会给客户一种非常感觉“你们这个迭代都在干什么呢？都在修defect吗？”）。Sign Off对用户故事非常非常重要，如果在一个迭代结束的时候客户对你的用户故事大部分不sign off这就造成我们无法进行下一步。因为我们需要一步一步的小步向前，也许sign off之后需求还会变化，但是那时候已经时另外一个用户故事了。
一个敏捷的迭代往往就是一组用户故事，而在这样迭代之中，我们其实迭代的交付给用户可工作的软件，而这也就是我们在每个迭代为用户交付的价值。
