本文已挪至 http://www./blog/2593.html ------------------------------------------ 上篇敏捷开发之 4句敏捷宣言中讲了敏捷开发的价值观, 从这些价值观中可以引出下面的12条原则,它们是敏捷实践区别于重型过程的特征所在。在Agile Software Development - Principles,Patterns,and Practices(中文书名: 敏捷软件开发-原则、模式与实践)中对这12条原则分别进行了阐述,这里我就不重复解释书本的内容了,将从我个人的理解去讲解这些原则,希望大家多多补充独到见解。 1。我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意 规划迭代故事时必须按照优先级安排,为客户先提供最有价值的功能。通过频繁迭代能与客户形成早期的良好合作,及时反馈提高产品质量。敏捷小组关注完成和交付具有用户价值的功能,而不是孤立的任务。以前我们都用需求规格说明书或者用例来编写详细的需求,敏捷使用用户故事来罗列需求。用户故事是一种表示需求的轻量级技术,它没有固定的形式和强制性的语法。但是有一些固定的形式可以用来参考还是比较有益的。敏捷估算中使用了这个模板:“作为【用户的类型】,我希望可以【能力】以便【业务价值】“。使用基于用户故事的需求分析方法时,仍可能需要原型和编写文档,只是工作重点更多的转移到了口头交流。
2。即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3。经常性的交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。
4。在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
5。围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持,并且信任他们能够完成工作。
6。在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。
工作的软件是首要进度度量标准。 8。敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 9。不断地关注优秀的技能和好的设计会增强敏捷能力。
10。简单----使未完成的工作最大化的艺术----是根本的。
11。最好的构架、需求和设计出自与自组织的团队。 敏捷中有很多种实践,大家都知道,迭代式开发是主要的实践方法,而自组织团队也是主要的实践之一。在自组织团队中,管理者不再发号施令,而是让团队自身寻找最佳的工作方式来完成工作。要形成一个自组织团队其实比较难。CSDN采访Mishkin Berteig中说到 自组织团队的第一个要素就是必须有一个团队,而不仅仅是一群人。一群人是一帮在一起工作的人,他们彼此之间并没有太多的沟通,他们也并不视彼此为一体。项目一开始,我们就会组建“团队”,但很多时候由构架师、需求人员、开发人员和测试人员组成的是一群人而已。他还认为,团队的形成必须经历几个时期。在经历了初期的磨合后,成员才会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩,而且这些规矩是不言而喻的。比如,每个人都知道上午九点来上班,都会主动询问别人是否需要帮助,也都会去主动和别人探讨问题。如果团队成员之间能够达成这样的默契,那么这个团队将成为一个真正高效的工作团队。在这样的团队中,成员之间相互理解,工作效率非常高。在自组织团队中,团队成员不需要遵从别人的详细指令。他们需要更高层次的指导,这种指导更像是一个目标,一个致力于开发出更好的软件的目标。总之,自组织团队是一个自动自发、有着共同目标和工作文化的团队,这样的团队总是在向它的组织做出承诺。但是,实现这些承诺对于自组织团队来说非常重要。否则,一旦出现问题,团队成员之间就会出现信任危机。 12。每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
推荐:你可能需要的在线电子书 敏捷个人sina围裙:http://q.t.sina.com.cn/135484 欢迎转载,转载请注明:转载自敏捷个人网站 |
|
来自: ThinkfunQd > 《管理研究》