敏捷方法的敏捷开发
敏捷开发是一种全新的理论吗？答案是没有定论的。细心的人可以发现，敏捷开发其实借鉴了很多软件工程中的方法。任何软件工程教科书都会提到的迭代和增量开发，在敏捷开发模式中起着非常重要的作用。回过头来看，还能看到瀑布和快速成型的影子，也许更多。
改进，而不是创新。敏捷开发可以理解为对原有软件开发方法的整合——取其精华，去其糟粕。因此，敏捷开发继承了原有方法的许多优点。“在敏捷软件开发过程中，我们每两周就会得到一个工作软件，”福勒说。“这个非常短的周期使最终客户能够及时快速地看到他们已经花钱构建了什么样的软件。”
也许是因为时间的关系，福勒只提到了其中的一些优势。允许需求在开发过程中改变，通过早期迭代更早地发现风险，使代码重用可行，并减少项目返工...敏捷开发借鉴了许多先进的方法和丰富的经验，似乎已经成为解决软件危机的标准答案。
问题与思考然而，我们不得不面对的现实是，模式和方法的优化并不意味着问题的终结。敏捷开发作为一种开发模式，也需要面对很多挑战。
大项目的拆分意味着更多子项目的出现，这些子项目的同步或异步协调，合理的资源分配会变得更加复杂。此外，在项目和项目团队“扩容”的现状下，遇到的问题也成倍增加。人的重要性被提升到了一个更高的层次，如果没有有效的协调手段，减少人员流动和项目变更对整个项目的影响也将成为一个很大的挑战...新方法带来了许多便利，但也引起了同样多的问题。
自2004年初以来，敏捷开发的概念一直很流行。Bailar非常支持这个理论，他采用敏捷的方式组建团队:Capital One的敏捷团队包括3名业务人员、2名运营人员和5 ~ 7名IT人员，其中包括1名业务信息向导(实际上是业务部门和IT部门之间的翻译人员)；此外，还有一个项目经理团队和至少80名开发人员。这些开发人员都是Bailar派来参加敏捷开发培训，具备相关技能的。
每个团队都有自己的敏捷导师(Bailar雇佣了20名敏捷导师)，他们的工作就是关注过程，提供建议和支持。最初的需求总结成一个目标，一堆记录详细需求的卡片和一些原型和模板供参考。在整个项目阶段，团队成员紧密合作，在9周的开发过程中定期停止开发——3-4次，以评估过程并决定是否有必要更改需求。在Capital One中，一个大型IT项目将被分成多个子项目，并为每个敏捷团队进行安排。这种方法在敏捷开发中被称为群集，所有过程都由一个项目经理控制。
为了测试这个系统的效果，Bailar将项目从旧的瀑布式开发拆分为并行开发，组建了敏捷开发所倡导的精益灵活的开发团队，并将开发阶段划分为30天的周期进行冲刺——每次冲刺都是从启动会开始，在下一次冲刺之前结束。
Bailar将其与传统开发方法进行对比后，非常兴奋——敏捷开发减少了30% ~ 40%的开发时间，有时甚至接近50%，提高了交付产品的质量。然而，有些需求是敏捷开发无法处理的。Bailar承认敏捷开发也有局限性，比如那些优先级不明确的需求，或者那些在更快、更便宜、更好的三角架构中的需求，这些需求不能被优先化。另外，他觉得大型项目或者有特殊要求的项目更适合传统的开发方式。虽然描述需求总是很困难，但是CIO会从痛苦之后的需求处理过程中受益匪浅。
敏捷开发是一些行业专家提出了一些价值观和原则，使软件开发团队具有快速工作和应对变化的能力，并于2001年初成立了敏捷联盟。他们正在通过个人实践，帮助他人实践，揭示更好的软件开发方法。通过这项工作，他们认为个人和交互优于流程和工具，工作软件优于综合文档，客户合作优于合同谈判，应对变化优于遵循计划，并提出以下原则:我们的首要任务是通过尽快和持续地交付有价值的软件来满足客户。即使是开发后期，也欢迎你更改需求。敏捷过程利用变化为客户创造竞争优势。经常交付工作软件，交付间隔可以从几周到几个月不等。分娩间隔越短越好。在整个项目开发期间，业务人员和开发人员每天都要一起工作。围绕有积极性的个人建立项目。给他们提供需要的环境和支持，信任他们完成工作。在团队内部，最有效和高效的信息传递方式是面对面的交谈。工作的软件是进度的主要衡量标准。敏捷过程提倡可持续的开发速度。负责人、开发者和用户都应该能够保持一个长期的、恒定的开发速度。不断关注优秀的技能和好的设计会增强敏捷性。简单是最根本的。最好的架构、需求和设计来自自组织团队。团队会定期反思如何更有效地工作，然后相应地调整他们的行为。首先，敏捷开发方法
(1)说明本文是在阅读阿利斯泰尔·考克伯恩的《敏捷软件开发》和威廉·c·威克的《XP探索》的一些笔记和观点。敏捷软件开发是一套软件开发方法的总称，包括(水晶、极限编程、适应性软件开发等。).敏捷开发方法也称为“轻量级”开发方法。
下面这段话摘自马丁·福勒的一篇文章:
从无到有到敏捷，大部分软件开发仍然是一个令人困惑的活动，也就是典型的“编码和修复”。设计过程充满了短期和即时的决策，没有完整的规划。这种模式对于小型系统的开发其实是非常有用的，但是随着系统变得越来越大越来越复杂，增加新的功能就变得越来越困难。与此同时，错误和故障也越来越多，越来越难以消除。一个典型的标志是，系统功能完成后，有一个漫长的测试阶段，有时甚至有一种没有前途的感觉，严重影响了项目的完成。我们使用这种开发模式已经很久了，但是我们其实还有另外一个选择，就是“方法论”。这些方法对开发过程有严格而详细的规定，以便使软件开发更具可预见性，提高效率。这个想法是基于其他工程领域的实践。这些形式化的方法已经存在了很长时间，但并没有取得显著的成功，甚至没有引起人们的注意。对这些方法最常见的批评是它们官僚而繁琐。如果按照它的要求，要做的事情太多，会耽误整个开发进程。因此，它们通常被认为是“笨重的”方法，或者吉姆·海史密斯所说的“不朽的”方法。作为对这些方法的反叛，一种新的方法在过去几年中出现了。尽管它们没有正式的名称，但通常被称为“敏捷”方法。对许多人来说，这种方法的吸引力在于对繁文缛节和官僚程序的反叛。它们在没有过程和过于复杂的过程中达到一种平衡，使得在几步之内获得满意的结果成为可能。敏捷方法和迟缓方法之间有一些显著的区别。一个明显的区别反映在文件中。敏捷模型不是非常面向文档的，它们通常需要尽可能少的文档来完成一项任务。在很多方面，它们更像是“面向代码的”。事实上，他们认为最根本的文档应该是源代码。但是，我不认为文档的特性是敏捷方法的根本点。文档缩减只是一个表象，其实反映了更深层次的特征:？敏捷方法是“适应性”而不是“预设性”，重方法试图在一个较长的时间跨度内为一个软件开发项目制定一个详细的计划，然后按照计划进行开发。这种方法在计划制定后拒绝改变。敏捷方法欢迎变化。其实他们的目的就是成为一个适应变化的过程，甚至是让自己去改变去适应变化。？敏捷方法是“面向人”的，而不是“面向过程”的。他们试图让软件开发工作符合人性而不是相反。他们强调软件开发应该是一项愉快的活动。我认为以上两个特征很好地概括了敏捷开发方法的核心思想:适应变化和以人为中心。
(二)方法背后的理念
阿利斯泰尔·考克伯恩在《敏捷软件开发》中描述了敏捷开发方法背后的思想。
人对流程的掌握可以分为三个阶段:1遵循一个明确的流程2脱离，知道不同流程的适用范围，在不同的场合使用不同的流程3流利，不在乎是否遵循一个特定的流程，知道在什么情况下采取什么行动。
软件开发是创新和交流的合作游戏。软件开发的首要目标是生产软件，遵循特定的流程和模型只是手段。只要传递足够的信息，手段是次要的。沟通的效果远比沟通的形式重要。一般软件开发有两个目标:1尽快出软件，2为下一个团队或项目做准备。有时候这两个目标是矛盾的，要在两者之间寻求平衡。
在软件开发中，人的因素远远大于过程和技术。人是有缺陷的:1容易出错，所以要在错误扩散之前发现并改正错误。2当你觉得你可能会失去更多的时候，你不愿意冒险。3.你不愿意重建和重用你所拥有的。4.坚持一种习惯是很难的。
个人因素建议:1具体模型比抽象模型更容易理解；2从一个例子开始很容易；3要有足够不受打扰的时间，通过观察别人的成绩来学习；5分配的工作应与个人意图和能力相匹配；6不正确的奖励会产生不好的影响；从长远来看，个人兴趣比奖励更重要。培养工作自豪感:1)工作自豪感，通常会有参与一项重要工作的自豪感；2)完成的骄傲，会长期降低士气；3)以贡献为荣，会为别人做贡献；7)鼓励关心他人的工作和整体工作。
在团队中，沟通是最重要的。实践证明，面对面的实时沟通是最有效的，沟通的延迟会丢失信息。白板是最好的沟通工具，再先进的沟通工具也无法提高沟通效果。文件是用来记录和记忆的，不能通过文件交流。
敏捷开发方法要避免的流程设计的几个常见错误1对所有项目使用相同的流程2缺乏弹性3过于沉重4增加不必要的“应该做”(“应该做”真的是应该？)5未经实践检验
敏捷开发方法流程设计的几个原则:1互动面对面的交流是成本最小，最快捷的信息交流方式2。超出实际需要的过程是浪费。3.大球队需要重量级的方法。4.处理重大问题的项目需要重量级的方法。5.增加反馈和沟通可以减少对中间产品和文档的需求。6.轻量级方式更强调理解、纪律和技巧。重量级方法强调文档。过程和形式理解是指整个团队关于项目的所有知识，包括讨论过程。文档只能记录规程的一部分，这意味着个人主动完成工作。流程是指个人按照指令完成工作。技巧是指技术好的人可以省略中间产品，正规是指工作必须按规定步骤完成。
7确定开发中期的瓶径，提高其效率。瓶径处的工作应尽可能加快，减少重复。(用更熟练的人，用更多的人，用更好的工具，让瓶径处的工作尽可能的稳定。)非瓶径处的工作可以多重复，在输入不确定的情况下也可以尽快开始。
这些原则的几个结论:1一个项目(constly)增加人员的成本很大，因为原有人员和新人员的沟通需要大量的时间。2团队规模经常跳跃式增长。例如，只有四个熟练的程序员，所以增加了不熟练的程序员。结果，团队花了很多时间培训不熟练的程序员，最后增加到20个不熟练的程序员。我们应该专注于提高团队的技能，而不是扩大团队。4.对不同的项目使用不同的流程。5.在适用的条件下，轻量级方法优于重量级方法。6.减少不同项目的流程。
敏捷开发方法的原则是“轻便”。