《敏捷软件开发》第一章敏捷实践

人与人之间的交互是复杂的，并且其效果从来都难以预期，但却是工作中最为重要的方面。
-Tom DeMacro 和Timothy Lister

1.1敏捷联盟
2001年初，由于看到许多公司的软件团队陷入了不断增长的过程的泥潭，一批业界专家聚集在起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观(value) 和原则。他们称自己为敏捷(Agile) 联盟。在随后的几个月中，他们创建出了一一份价值观声明。也就是敏捷联盟宣言(The Manifestoofthe AgileAlliance).

敏捷联盟宣言:
敏捷软件开发宣言
我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为:

个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划

1.个体和交互胜过过程和工具
答：我个人认为作者是想表达一个有高水平的程序员组成的团队但不会交流不如一个中水平程序员团队但会相互勾通组成的团队更高效。

2.可以工作的软件胜过面面俱到的文档
答：作者表达了如果一个软件做的文档太多太大，那软件的变动会代表具大的付出。如果必须有文档，建议使用短小明了文档。传播主要靠人。我同意作者第一个观点，但我不能同意他的第二个观点。

3.客户合作胜过合同谈判
答：作者讲述了一个故事，说软件不能像日用品一样，用一份关于软件的描述，以固定的时间，固定的价格开发它。

4.响应变化胜过遵循计划
答：响应变化的能力常常决定着一个软件项目的成败，当我们构建计划时，应该确保计划是灵活的，并且易于适应商务和技术方面的变化。 计划不能考虑太远，因为一旦客户发生需求变更，会代来具大的时间来变化。

1.2原则
1.我们最优先要做的是过飞翔早的、持续的交付有价值的软件来使客户满意。
答：初其交付的系统中所包含的功能越少，最终交付的系统的质量就越高。交付的越频繁，最终产品的质量就越高。

2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竟争优势。
答：作者表示不惧怕变化，认为改变需求是好的事情，因为意味着团队学到了很多如何满足市场需要的知识。并且保持灵活性。

3.经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
答：作者讲述交付用的时间短，可以做出更有效的软件，如果时间过长就会有大量的文档或者计划。

4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
答：作者认为业务人员或是需求是一个软件的“导航”，会不断的做出正确的引导。

5.围绕被激励起来的个人来构建项目，给他们提供所需要的环和支持，并且信任他们能够完成工作。
答：在敏捷开发中，人是项目取得成功的最重要因素。基他因素为过程、环境、管理等。只要是对人有负面影响的都要进行改变。

6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
答：在敏捷项目中，人与人直接交谈比文档、规范、书面计划、设计要有更好的效果。

7.工作的软件是首要的进度度量标准。
答：在敏捷开发中，代码进度的30%不是真正的进度，只有当功能的30%完成时才是项目的进度。

8.敏捷过程提介可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
答：作者表示，跑的快会导致团队精力耗尽、出现短期行为以致于崩溃。要了解自己的速度，不允许自己过于疲惫。让整个项目开发间保持最高质量的标准的速度。

9.不断地关注优秀的技术和好的设计会增强敏捷能力
答：保证高质量的开发速度、保持软件简洁并且健壮。有混乱的代码要及明清理。

10.简单--使未完成的工作最早大化的艺术--是根本的
答：敏捷团队不会试图去构建华而不实的系统，如果发生问题，也可以很容易进行处理。

11.最好的构架、需求和设计出自于自组织的团队
答：任务不是从外部分配团队成员，而是分配给整个团队，然后再由团队来确定完成任务的最好方法。任务是由整个团队共同完成。

12.每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应的对自己的行为进行调整。
答：团队会不断进行组织方式、规则、规范进行调整。环境在不断地变化，保持团队的敏捷性，就必须要随环境一起变化。

  

转载于:https://www.cnblogs.com/FKdelphi/p/8685890.html