敏捷开发的过程和理解

敏捷开发的价值观是价值交付，而非是完成任务。

  强调对于软件质量的关注。通过不断的沟通，不断的迭代，可以从容面对各种需求变化，开发出更加适合用户的产品，因此对于初始需求不明确，整个团队对业务不是很了解，在开发的过程中需要对业务进行大量调整的项目，更加适合敏捷开发。下面是敏捷开发与瀑布开发的应用环境对比：

瀑布开发

  1.专业用户

  2.专业需求描述

  3.需求可预见

  4.有计划的交付周期

  5.专业开发团队

敏捷开发

  1.大众

  2.模糊需求

  3.变化频繁

  4.越早越好

  5.非专业的开发团队

  在敏捷开发中，初期对于用户的需求并不明确，我们只能得到用户一个比较粗略的价值取向。比如工厂需要开发一个MES系统，最初他的描述可能只是，我想了解我生产的每一个细节。在敏捷开发中，这个价值取向称为用户故事。故事是由用户+功能+价值组成。因此刚才的价值取向转化成为敏捷开发中的用户故事就变成  工厂管理层（用户）想使用MES系统来了解生产的每一个细节（功能），从而可以指导我实现工厂的精益生产（价值）。

  然而这个故事太粗糙，需要对这个故事不断切分，直到形成一个单独的功能。

  用户故事不等于用户需求，用户需求是更细致的东西，包括界面如何设计，功能如何运行，用户故事更侧重阐述功能如何定位，带来什么价值。

  接下来进行用户建模，即识别有哪些用户，特别关注关键用户,从用户的角度去编写故事。编写故事的过程，直观的感受是产生文档的过程。然而根据敏捷中的精益理念，在建模过程中，应尽量减少文档。个人感觉，在软件开发过程中，文档最重要的作用不是在开发功能时，因为这时，如果有新的需求，直接通过面谈沟通能够让开发者快速明确需求逻辑，因此没有文档，工作也可以开展，而且更高效;在开发完成以后，功能变更中，文档便于重新回忆当初的开发逻辑，识别修改的影响，特别是功能变更不是由最初的开发者修改的情况。对于需求文档，在开发以后，起到的作用就很小了，而功能设计会详细说明功能的运行逻辑，在开发完成后仍然比较有价值。因此个人感觉应该保留一份详细功能设计，并且随代码持续更新。其它文档能通过面谈解决的，可以尽量少产生。

  故事编好以后，参考是否用于关键用户，价值大小，进行优先级排序。在以后面对任何需求变化，需要随时更新（Product Backlog）

接下来进行迭代开发，首先是开迭代计划会，目的是让开发者理解需求，并形成完善的功能逻辑。由PO（Product Owner）讲解故事，以及故事的优先级和完成标准。而听众需要对故事中不理解的地方提出质疑，通过所有人的讨论，形成一个明确的需求。并且对这个需求的开发时间进行估算（有一个估算扑克的游戏）。

在开发的过程中，每天要开一个立会，讨论任务进度及工作难点。时时修正。

  对于迭代期内的变更，安排开发优先级。可能在跌代期内完成，可能在跌代期外完成。

  敏捷开发的优点，项目中所有的需求讨论，时间安排等工作是由所有人参与，开发中，开发者之间会相互Review代码， 能显著提高代码的开发质量，而且可以保证代码质量稳定，不会造成同一个系统里,因为开发者能力的差异，造成质量差别很大。而且因为所有的人都参与故事讨论，每个人都对系统有充分了解，便于调配任务。

  迭代的理解：所谓迭代，简单来说就是不断修改，不要在工作之初就给自己制定一个完美的开发模型，因为最初进行完美设定，可能要考虑各种需求的变化，但是变化无止境，所以为了很多以后可能发生的事，会分散太多的精力。我们只需要按当前的理解，开发出一个初版，然后让用户提意见，在这个过程中，会发现很多意想不到的问题，然后再改进，通过多次迭代，从而达到完美。但是我觉得不能过分依赖迭代，因为我们每次迭代时总会想，不尽力去发现新的需求和问题也没关系，或许下次迭代我们会发现。这样会导致迭代次数太多，而总让人觉得不完美。

  敏捷生态系统：一个敏捷开发的整体架构图。从客户/团队，计划，跟踪，效果，目标5个层级进行控制，是理解敏捷开发的关键。

  燃烧图：直线的效率是最完美的，有些偏差很正常。