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