你的位置:首页 > 软件开发 > ASP.net > 敏捷软件开发:原则、模式与实践——第1章 敏捷实践

敏捷软件开发:原则、模式与实践——第1章 敏捷实践

发布时间:2015-08-25 16:00:10
第1章 敏捷实践敏捷软件开发宣言:人和交互 重于 过程和工具可以工作的软件 重于 面面俱到的文档客户合作 重于 合同谈判随时应对变化 重于 遵循计划虽然右项也有其价值 ...

第1章 敏捷实践

2.可以工作的软件重于面面俱到的文档3.客户合作重于合同谈判4.随时应对变化重于遵循计划  (2)我们欢迎需求的变化,即使到了开发的后期。敏捷过程能够驾驭变化 ,为客户创造竞争优势。这是一个关于态度的声明。敏捷过程的参与者不惧怕变化。他们认为改变需求是好的事情,因为那些改变意味着团队已经学 到了很多如何满足市场需要的知识。  (3)经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。我们交付可以工作的软件,并且尽早地(项目刚开始很少的几周后)、经常性地(此后每隔很少的几周)交付它。我们不赞成交付大量的文档或者计划。我们认为那些不是真正要交付的东西。我们关注的目标是交付满足客户需要的软件。  (5)围绕斗志高昂的人构建项目。给 他们提供所需要的环境和支持,并且信任他们能够完成工作。人是项目取得成功的最重要的因素。所有其他的因素(过程、环境、管理等)都被认为是次要的,并且当它们对于人有负面的影响时,就要对它们进行改变。例如,如果办公环境对团队的工作造成阻碍,就必须对办公环境进行改变。如果某些过程步骤对团队的工作造成阻碍,就必须对那些过程步骤进行改变。  (6)在团队内部,最具有效率也最有效果的信息传达方式,就是面对面的交谈。在敏捷项目中,人们之间相互进行交谈。首要的沟通方式就是交谈。也许会编写文档,但是不会企图在文档中包含所有的项目信息。敏捷团队不需要书面的规范、书面的计划或者书面的设计。团队成员可以去编写文档,如果对于这些文档的需求是迫切并且意义重大的,但是文档不是默认的沟通方式。默认的沟通方式是交谈。  (7)可以工作的软件是首要的进度度量标准。敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度。它们不是根据所处的开发阶段、已经编写的文档的多少或者已经创建的基础结构(infrastructure)代码的数量来度量开发进度的。只有当30%的必须功能可以工作时,才可以确定进度完成了30%。  (8)敏捷过程提倡可持续开发。出资人、开发者和用户应该总是保持稳定的开发速度。敏捷项目不是50 米短跑;而是马拉松长跑。团队不是以全速启动并试图在项目开发期间维持那个速度;相反,他们以快速但是可持续的速度行进。  (9)对卓越技术和良好设计的为断追求有助于提高敏捷性。高的产品质量是获取高的开发速度的关键。保持软件尽可能的简洁、健壮是快速开发软件的途径。因而,所有的敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。他们不会制造混乱然后告诉自己等有更多的时间时再来清理它们。如果他们在今天制造了混乱,他们会在今天把混乱清理干净。  (10)简单--尽量减少工作的的艺术是至关重要的。敏捷团队不会试图去构建那些华而不实的系统,他们总是更愿意采用和目标一致的最简单的方法。他们并不看重对于明天会出现的问题的预测,也不会在今天就对那些问题进行防卫。相反,他们在今天以最高的质量完成最简单的工作,深信如果在明天发生了问题,也会很容易进行处理。  (11)最好的构架、需求和设计都源自自我组织的团队。敏捷团队是自组织的团队。任务不是从外部分配给单个团队成员,而是分配给整个团队,然后再由团队来确定完成任务的最好方法。  (12)每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为。敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整。敏捷团队知道团队所处的环境在不断地变化,并且知道为了保持团队的敏捷性,就必须要随环境一起变化。

 

结论

原标题:敏捷软件开发:原则、模式与实践——第1章 敏捷实践

关键词:

*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们: admin#shaoqun.com (#换成@)。

可能感兴趣文章

我的浏览记录