敏捷开发流程简单了解

参考：

1、https://www.zhihu.com/question/19638322

2、http://www.cnblogs.com/feihe/archive/2011/04/16/2017655.html

3、http://www.infoq.com/cn/articles/agile-estimation-techniques

4、http://chuangyiji.com/archives/category/software/page/2

一、为什么要进行敏捷开发：敏捷开发可以快速提交给用户最小可用的产品

前记

       对于敏捷软件开发，听说已久。最近刚刚开始走上敏捷　　的路上，所以记下自己一路上感受和收获。

       为什么我们要采用敏捷软件开发呢？这也许是所有刚开始接触“敏捷”这个概念的第一个问题，那我们就从第一个问题开始我的旅程。通常我们在开发中引入一些新的实践无非就两个原因，要么就是我们现有的开发模式有问题，要么就是这个新的开发模式更有效率。那么我们首先可以回顾一下我们现在被大多数团队采用的瀑布式开发。

       在瀑布式开发中我们有开发过程分为一下几个阶段：分析，设计，实现，测试。其中每一个阶段的产出作为下一个阶段的输入。而这里隐含了两个假设：

• 当我进入设计阶段的时候，我假设我的分析是正确的并且不会再变化。

• 当我进入实现阶段的时候，我假设我的设计是满足需求，并且同时满足第一个假设。

　　所以当我们进入测试阶段，我只需要测试实现。而只有当这些假设成立都成立，瀑布式开发才能真正的工作。然而现实是：     

• 需求是变化的: 因为我们在做定制化软件开发，而当需求发生变化的时候，我们有两种选择： 我们继续遵循我们和用户的合约，然后提交给用户一个并不是他想要的软件；我们重新分析需求，结果是我们走的越远，我们付出的代价越大。

• 无法保证设计一定满足需求:　因为我们的测试阶段输入只是实现阶段的产出，所以当需求或设计在此时发现不正确时我们团队需要付出极大的代价弥补这些。情况好的化就是整个团队不停的加班，否则就是项目失败。

　　那么是不是引入敏捷开发，需求就不会变化了吗？就一定能保证设计满足需求了吗？当然不是，引入敏捷软件开发，需求依然在变化，设计也还是可能不满足需求。那么我们引入敏捷软件开发的意义何在呢？我们可以深入的想想，需求变化和设计不满足需求带来最终的结果是什么呢？

　　就是浪费，而这种浪费在被瀑布式开发这种阶段式的开发表现的极为严重，而敏捷开发的引入是为了最小化这种浪费。要减少浪费，首先我们需要明白浪费的原因是阶段式的开发模式，我们的步子迈的太大了。敏捷要求我们步子尽量小一点，我们小步的前进，这样我们倒回来一步的代价就变小了。

二、如何进行敏捷开发

引言：

       在上一篇中，我聊到了敏捷可以通过小步前进来最大程度的减少浪费。接着我们来聊聊敏捷是如何小步前进的。

       在瀑布式开发中我们的步子迈的太大了，导致我们首先无法快速应对变化，其次我们需要付出很大的代价来应对变化。而敏捷迭代开发则可以让我们小步的往前走，以一种增量式的模式来进行开发。那么敏捷迭代中迭代的是什么呢？我觉得迭代的交付可工作的软件。

 

    　首先，我们看看敏捷迭代大致的流程：

• 首先和用户讨论需求，定义系统的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（Business Analys类似于PM产品经理）会把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之后需求还会变化，但是那时候已经时另外一个用户故事了。

       一个敏捷的迭代往往就是一组用户故事，而在这样迭代之中，我们其实迭代的交付给用户可工作的软件，而这也就是我们在每个迭代为用户交付的价值。

三、用户故事估算技巧和方法

• 用2的幂进行估算

　　开始的时候，我会将故事的规模估算为1点、2点、3点、4点，或是小、中、大、特大。人们总是觉得：中等大小的故事，其工作量是小型故事的两倍；而大型故事是中等大小故事的两倍（诸如此类）。但到后来，发现这样的想法总是很难跟实际规划吻合起来。后来有人推荐我使用2的幂来估算。这一下，业务人员就能理解我们的表达方式了。他们会知道8点的故事要远超过1点的故事。我认为1点、2点、4点、8点这样的规模估算要更加合适。故事越大，其中包含的未知因素和风险也就越多。用2的幂进行估算，可以让人们对于大型故事所关联的风险更加注意。

• 使用4个数值

　　我参与过一个项目，他们用1、2、4、8作为估算值。前两次估算会议结束后，不到5%的故事只有1点，大约30%的故事是2点。项目经理决定去掉“1”这个估算值，因为他觉得这样做太容易了。此后的每次估算会议中，有趣的事情发生了：突然只有5%的故事变成了2点，相当多的故事变成了4点。开发人员改变他们的估算规模，我认为这不是有意的，只是开发人员总是会想得多一些。没几个开发人员愿意确定表明：用户故事非常简单，估算允许的最小数值就是它的工作量。在多次项目过程中见过类似行为后，我选择估算的最小数值为4点。不过我觉得用4点作为最大估算数值也不错。无论如何，这只不过就是估算而已。如果放太多精力在估算的准确度上，到后来就得负责说明为什么没能按照估算完成任务。估算的目的是要对项目规模和工作量有一个大致的概念，而不是要得到一个需要严格遵循的工作计划。

• 不能取平均数，不能使用不在估算取值范围中的数字

　　使用数字4，可以让你得到一个粗略的估算，而不必在精确程度上花费太多时间。有的故事感觉比2点大一点，但是又比4点小一点。这样的故事不能估算为3点。也没有理由使用3点进行估算。类似的故事隐含的风险或是未知因素让人觉得它不是2点，因此，它很有可能是一个4点的故事。如果使用平均数、或是不在估算取值范围中的数字，有可能给团队成员或是项目干系人造成暂时的（也是不必要的）困惑。同时，从项目整体的角度来看，偶尔不太确定的估算也不会影响大局。要保持简单，坚持使用取值范围中的数字。

• 独立投票

　　受他人影响是人的本性。如果一个技术leader说一个故事大小是两点，很可能其他团队成员都会随声附和。因此，在我负责的估算过程中，我会让每个团队成员独立做出自己的选择。要想达到这样的目的，可以为每个成员发一张纸，让他们在上面写上自己的估算，等到每个人都写好之后，大家可以一起展示各自的估算。另外一种方式，也是我喜欢的方式，是用“石头-剪子-布”（译注：英文名rock-paper-scissors，简称RPS）进行估算。在估算会议上，我们会一直讨论某个故事，直到大家都准备好估算为止，然后我们会一起“抛出”自己的估算，就像是同时伸手出石头、剪子、布一样。我所说的“抛出估算”就是：伸出一个手指头表示1点，两个手指头表示2点，四个手指头就是4点。要是表示8点，那就得双手并用了。

• 选取最大的估算值

　　即使反复提醒过了，开发人员们还是很难估算，因为他们仍会受到团队的影响。如果某个开发人员认为可以在一天内做完某个故事，他会伸出一个手指头。然而，这个故事也许不由该开发人员负责，另外的团队成员会接手，可是他可能会认为这个故事应该是2点甚至是4点。我总是选择团队成员给出的最大估算数值。也许有人认为这是小题大做，可实际上每个团队成员对于风险的认知不同，也许给出最大估算的成员想到的风险要比其他人更完备。选择最大的估算值还有其他好处。如果必须要同意一个较低的估算，那么做出最大估算的团队成员就得说明原因。对于团队中不那么资深的成员来说，这样的讨论可能让他觉得窘迫。对开发语言和工具相关经验的匮乏，他们可能不知道怎么样快速完成某项工作。他们的担心是由自己的技能水平决定的。如果因为不想讨论为什么估算值那么高而不愿意给出自己真正的估算，这对团队可无甚裨益。

　　对于取值高低的讨论，有可能使得整个团队提升估算值，或是让开发人员不甚情愿地降低自己的估值。不管怎样，你都要花更多时间来讨论，而这些讨论可能一无所获。到最后，最重要的还是保持一致。通过跟踪团队开发速度（注），团队在一个迭代中可以完成多少故事，这总是可以知道的。因此，即使估算有所“膨胀”，速度也会随之变化，对于规划来说没有影响。

　　最后，选取最大的估算值可以节省估算会议的时间。如果团队中有人认为一个故事应该是8点，在讨论这个故事时，他可以大声说出来，宣称自己将抛出8点这个估算值。除非有人认为在团队成员的估算之间有很大差距，既然这个故事必将成为8点，那就没有必要再针对它讨论下去了

• 讨论大估算差

　　对于估算，经常会有误解，以为整个团队都同意某个故事的大小。如前所述，我会选择更大的值来解决估算不一致的问题。然而，有时很大的估算差距意味着存在某些误解。因此，如果有两个估算的值差距大于2，总是会引发讨论（比如，如果一个成员抛出1点，而另一个认为是4点，大家就得澄清一下了）。讨论这些大的差距，还可以减少给出最大估算的人被轻视的机会。

• 提防信息不足

　　有时会发生估算会议结束时还有故事未被估算的状况。与其匆忙给出一个让人不舒服的估算，不如去征询更多信息。估算为8点，暗示着这是一个很大的故事，但也意味着你觉得它会占用两倍于4点故事所用的时间。因此，不要随便将不清楚的故事估算成8点。估算会议的目标不是要得到所有故事的估算值，而是要为提供了足够信息的故事给出估算。

• 必要的投入

　　没人喜欢参加估算会议（好吧，就我所知的都不喜欢）。在我经历过的项目中，语速快的人负责将故事大声念出来，开发人员会问领域专家各种问题，然后他们会进行估算。当没人向领域专家发问时，他们会在自己的笔记本上做其他的事情。一开始，我觉得这是利用时间的好方法，但是他们却会因此而错过一些东西。后来我参加了这样一个项目，经理要求每个人轮流念一个故事。这样领域专家就参与进来了，因为他们害怕轮到自己念时看起来很愚蠢。由于每个人的全情投入，整个会议也变得更有价值了。

• 猪和鸡

　　在供应火腿和鸡蛋的餐馆里面，猪是全身心投入，而鸡只是参与而已。

我经常听到这样的话：业务人员不应该干扰开发人员的估算，因为开发人员属于“猪”的角色，而业务人员都是“鸡”。我真觉得这个类比很不好。一个坏的产品出来，更有可能被解雇的是业务团队，而不是技术团队。然而，让业务人员干扰估算是会引发利益冲突的。

这个问题也很容易解决。业务人员想知道他们在下个迭代后能得到哪些功能，他们需要估算。由于业务人员不写代码，他们的估算都不大准确。在实际的估算过程中，业务人员参与得越多，由此而对开发人员产生影响，也就有可能使业务人员得到的估算越不准确。在会议上，最好的领域专家只回答问题，而不会去干扰故事开发过程的一丝一毫。

• 估算小组人数

　　团队的大小各有不同。在小于等于6个人的小型团队中，我建议整个团队都参与估算会议。不同的观点有助于夯实项目远景，并对估算产生正面效果。不过，我相信是存在收益递减效应的。如果是大团队，就不一定全都参与针对每个故事的估算了。再说，这就是一个估算，6个人跟15个人的准确性不会有太大差别。如果你的团队多于6个人，我建议分成不同的估算小组。一般来说，我希望最少能有3个人参与故事估算，但是不要超过6个人。

• 新故事

　　新故事的出现有两种形式：新功能需求和既有故事的切分。一般我会根据新故事的优先级考虑何时进行估算。如果一个故事要在下个迭代中完成，那就得对它马上估算。不过，要是新故事在接下来几个迭代中都不会出现，再等等也无妨，直到有了足够的故事来证明召开估算会议的必要性。我发现估算会议上得到的估算值更为可靠，因为在那个环境中，大家都将精力放在估算之上。通过切分得到的故事有其复杂性：它们可能已经估算过了。我强烈建议在估算新故事时，不要考虑之前的估算值。如果一个故事因为其风险或不确定性需要切分，很有可能之前的故事是不靠谱的——忽略原先的估算吧。

• 不要用笔记本电脑

　　至少不要给开发人员提供笔记本电脑。把故事列表打印出来分发给大家，或者用投影仪投放在屏幕上，但是不要让开发者从自己的笔记本上读故事列表。笔记本总是从某些方面吸引开发人员的注意力，因此使得他们偏离会议的目标：得到有价值的估算。

• 必要的参与

　　这个建议非常重要。理论上说，除团队之外的开发人员都不能参与估算会议。也就是说参与会议的每个程序员都有可能要去开发被估算的故事。如果一个开发人员不喜欢估算某个故事，那我就不希望他们开发这个故事。当然，凡事有例外。对于新成员来说，我会给他们一周的时间来适应，之后再参与估算会议。不过，一般来说，拒绝参加估算会议的开发人员应该说明：有什么样更严重的问题等着他解决。

• 过时的估算

　　团队会改变，项目会变化，天有不测风云。不管是什么原因，估算都有可能过时。过时的估算毫无用处。要跟上过时估算，开发团队会有压力，而业务人员根据之前了解的进度，希望故事可以及时完成。估算过时与否并不重要，重要之处在于估算不再可行了，由之产生的计划也不再可靠。我参加过的项目中，所有的估算在 12-24周内都会过时。承认估算过时，而不要用不准确的信息安排计划。因此，我建议重新过一遍已经过了12周的故事估算。虽然这些估算可能没有问题，但是开发人员有机会提供新的信息，这对于整个业务来说肯定有所裨益。

• 小恩小惠

　　这个建议最容易做到了。为估算会议购买各种好吃的零食。科学证明：甜食会让人产生幸福感，而幸福感会带来协作。想让估算会议按照既有方向进行，这是最简单、最便宜的方式。不过要注意：好吃是关键。如果拿出来的零食在团队房间中已经存在，那就索然无味了。在最近参与的项目中，一想起来要开会了，我就会去面包店买刚出炉的什锦饼干。

阅读英文原文：User Story Estimation Techniques

---

*速度：当项目的生命周期通过迭代组织时，用来计算一个迭代能够完成的工作的点数。比如：如果你在5个迭代中完成了20点，你的速度就是4。只要故事的估算之和是4点，你就可以在一个迭代之内完成这些故事（比如，一个估算为4点的故事，2个估算为2点的故事，4个估算为1点的故事等等）。

四、故事点到底是什么东西？

　　“故事点表示模糊的时间单元”，或者“故事点是Scrum团队使用的一种随机度量方式，用来度量实现一个故事需要付出的工作量”，还可能是“故事点数的估算混合了对于开发特性所要付出的努力、开发复杂度、个中风险以及类似东西”【引自Mike Cohn的《敏捷估算与规划》】。

　　Michael接下来记录了故事点的使用方式：“说实话，速度是度量生产力的一种方式”，以及与之相对的“使用故事点数或理想人天来度量生产力是坏主意，因为这会促使团队不断膨胀一个点数的内涵……”

　　面对这些迷惑，Michael开始思考故事点数到底是什么？你要怎么向新接触敏捷和Scrum的人介绍这个概念呢？

　　Dan Rawsthorne的回复是：

1. 团队常常希望速度成为成产力的度量指标，这样就能跟外界其他人说自己的“速度有多快”。
2. 如果故事点数在项目生命周期中能保持常量，速度才是有意义的度量指标。想做到这一点，团队必须找到一两个标准的故事，它们的大小在整个项目生命周期中都得保持不变。
3. 如果“基线故事不仅在一个团队内部保持大小不变，而且在各团队之间也是如此，那么速度不仅可以用来度量生产力，还能用做不同团队工作效率的有效对比，并因此而成为组织内部的添加剂。”多说一句，这篇文章的作者非常反馈这个实践：速度在敏捷项目中的错误使用。
4. 一旦团队有了稳定的故事点数，它们就能被用在未来的发布规划中，用以得到即将成功完成的工作的大致估算。

　　一、以故事点的形式进行估算

　　故事点估算可以很好的满足上面的特点的估算方法。团队可以自定义合适的故事点，我们组内偏好把一个完美工作日作为一个故事点进行故事估算。

　　完美工作日就是理想工作日，一天8个小时内一直在编码没有任何其他的情况。当然现实情况可能不太相同.所以一个完美工作日!=一天

　　二、以团队估算

　　故事点应该是由整个团队进行估算，团队中的大部分成员都要参与故事的故事点估算，每个人都把自己的估算结果说出来，最后大家再定一个所有人都认可的故事点

　　三、如何进行估算

　　1、所有参与的客户和开发人员聚在一起

　　2、从第一个故事开始，详细讲解故事直到所有的人都清楚了解这个故事

　　3、每个开发人员都先写下自己估算的值，一故事点为单位 ，例如 2完美工作日(2天)

　　4、大家都展现自己的估算，然后每个人都说一下为什么估算出这个值

　　5、最后经过论证团队估算出一个所有人都认可的值

　　6、继续下一个故事的估算

五、名词解释

 

• Scrum和Sprint

　　Scrum是一种敏捷开发框架，是一个增量迭代的开发过程。在Scrum中包括了若干个小的迭代周期（有的也叫冲刺），称为Sprint。大的项目会有若干个Scrum，每个Scrum中我认为至少有2个Sprint。

　　Scrum强调迭代，简单的可以理解一个Sprint就是一次迭代或者一次升级发布。

　　从逻辑上大致可以这么理解：Project-Scrum-Sprint-Epic-User Story，Project就是项目，Epic和User Stroy后面再说。

• User Story

　　Sprint是一个目标，所以下面的User Story可以认为是具体的需求点，一个Sprint可能有十几个到几十个User Story。敏捷开发被很多互联网公司使用，因为这些互联网产品都是面对用户，并且用户需求从产品角度是不断变化的，所以这里需求点叫做User Story。但是我们现在其实还是会涉及到一些并不直接和用户打交道的功能点，不过为了统一也叫User Story了。（Jira系统中User Story和非敏捷方式的Feature，以及测试的Defect、bug都是一个级别，也就是Issue，所以User Story等可以理解为是Feature套了一件外衣。）

　　User Story(aka Feature)到底拆到多细，在我们执行敏捷的时候一直有争论。比较简单的来说，这要根据不同项目的情况来区分，web项目可以是一个页面，但是一个页面上有很多按钮的话，那么User Story也可以到一个按钮的功能。同时兼顾时间，一般一个User Story在3小时左右。如果程序员素质很高的话，还可以到代码行数，比如50行代码。颗粒度太粗，不能控制项目进度，太细也没有必要。

　　测试一部分是根据User Story来进行，也就是说既然都说要实现的功能点，自然要测试一下，但测试还不光是测试功能点，还会有专门的案例测试、压力测试等。产品和需求方根据User Story来进行生产验收测试，是够的。

　　我们在敏捷中，因为把需求、Sprint拆成了很多User Story，所以测试是可以提前介入的，但是会增加很多回归测试的工作量，对于交付时间来说是划算的。但对测试本身的工作量和要求来说，也提高了，这也是为什么说敏捷对于人员要求高的另一个原因。

　　测试的结果会有Defect或者Bug，这个测试包括开发测试和生产验收测试，比如在Firefox下打开页面菜单栏有5个像素移位，这是Defect，比如在Firefox下打开登陆页面后登陆浏览器报错，这是Bug。Bug基本是一定要解决的。Defect不一定，特别是在敏捷中，是可以区分优先级后放到之后的Sprint中的，这个取决于产品经理、项目经理、开发、测试等共同商量。

　　一个User Story从建立到开发到测试完成，也就close了。我们就是根据这个来查看、判断进度，做需求和资源调整。

• Epic

　　Epic类似于传统的里程碑，在一些大的项目中需要。如果Sprint周期在2-3周，Epic意义不大。

• Issue

　　项目开发管理中Issue的状态有已经建立、在开发、在测试、完成。

　　每一个Issue都是有估计时间的，最小单位30分钟，最多一般不超过3小时，和建立User Story的原则一致。

• Stand up

　　Scrum每天有一个Stand up站会的要求，我们目前把站会简化成review上一日存在问题和提出目前问题，同时因为考虑到有时候开发在晚上有工作量，因此站会有两个，分别为晨站会和暮站会（很有诗意的名字），站会后邮件给到大家。(Jira的敏捷插件做的非常好，包含了几乎所有敏捷管理需要的工具和功能，但是站会没有看到小结的电子化工具，因此这部分用邮件)，站会邮件中的问题列表是有日期编号的，提醒产品经理、项目经理、Scrum Master关注多日未解决问题。并且这样的话，比起纯粹站会或者邮件多了一个可追朔。每个问题都会有提出人、解决人、解决时间等。

　　对于Story Point，我个人认为意义不大，因为每一个Issue的Story Point的估计和时间估计是重复的，虽然说Story Point可以更加客观的评估，但是我认为项目管理是为了结果而不是为了评估，同时通过时间和一些后期设定也是可以完成项目评估的。要敏捷的话，该省的地方就一定要省。

　　敏捷开发中，对于项目开发的相关文档是另一个有争议的话题，我们这里一般瀑布管理的开发流程大约一个项目30-40个文档，那么敏捷是否可以减少文档的数量呢，在减少的同时怎么保证知识共享和知识传递呢？