文档介绍：敏捷开发之 12 条敏捷原则敏捷开发中有 12 条原则,它们是敏捷实践区别于重型过程的特征所在。在《 Agile Software Development - Principles,Patterns,and Practices 》( 中文书名:《敏捷软件开发——原则、模式与实践》) 中对这 12 条原则分别进行了阐述,这里我就不重复解释书本的内容了, 将从我个人的理解去讲解这些原则, 希望大家多多补充独到见解。 1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。规划迭代故事时必须按照优先级安排,为客户先提供最有价值的功能。通过频繁迭代能与客户形成早期的良好合作, 及时反馈提高产品质量。敏捷小组关注完成和交付具有用户价值的功能, 而不是孤立的任务。以前我们都用需求规格说明书或者用例来编写详细的需求,敏捷使用用户故事来罗列需求。用户故事是一种表示需求的轻量级技术, 它没有固定的形式和强制性的语法。但是有一些固定的形式可以用来参考还是比较有益的。敏捷估算中使用了这个模板:“作为【用户的类型】, 我希望可以【能力】以便【业务价值】“。使用基于用户故事的需求分析方法时, 仍可能需要原型和编写文档, 只是工作重点更多的转移到了口头交流。 2. 即使到了开发的后期, 也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。敏捷过程参与者不怕变化, 他们认为改变需求是好事情, 因为这些改变意味着我们更了解市场需求。 3. 经常性的交付可以工作的软件,交付的间隔可以从几周到几个月, 交付的时间间隔越短越好。迭代是受实践框限制的, 意味着即使放弃一些功能也必须按时结束迭代。只要我们可以保证交付的软件可以很好的工作, 那么交付时间越短, 我们和客户协作就越紧密, 对产品质量就更有益。虽然我们多次迭代, 但并不是每次迭代的结果都需要交付给用户, 敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些功能, 增加的每个功能都是经过编码、测试, 达到了可发布的质量标准的。另外敏捷开发项目中对开发阶段没有什么重要的分割, 没有先期的需求阶段, 然后是分析阶段, 架构设计阶段, 编码测试阶段等, 在项目真正开始后,每次迭代中都会同时进行所有的上述阶段工作。 4. 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。软件项目不会依照之前设定的计划原路执行,中间对业务的理解、软件的解决方案肯定会存在偏差, 所以客户、需求人员、开发人员以及涉众之间必须进行有意义的、频繁的交互,这样就可以在早期及时的发现并解决问题。 5. 围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持,并且信任他们能够完成工作。业务和技术是引起不确定的二个主要方面, 人是第三个方面。而业务和技术又必须由人来执行, 所以能够激励人来解决这些问题是解决不确定性的关键。只要个人的目标和团队的目标一致, 我们就需要鼓舞起每个人的积极性, 以个人为中心构建项目, 提供所需的环境、支持与信任。 6. 在团队内部, 最具有效果并且富有效率的传递信息的方法, 就是面对面的交谈。在十几或者二十几个人组成的大团队中, 文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人( 大团队实施敏捷时也会分成多个小的敏捷团队), 所以大量的文档交流其实并不是很经济的做法。此时面对