敏捷原则_敏捷原则添加-CSDN博客

本文链接：https://blog.csdn.net/xiaohaige/article/details/4482270

为了解决软件研发的工程问题，十多年来，特别是2000年后，各种现代软件研发模式应运而生。比如阶段式发布（Staged Delivery）、极限编程（eXtreme Programming）、统一过程（Unified Process）以及Scrum。每一种软件研发模式都有一大批追随者和实践者。经过大规模应用，这些现代软件研发模式相对于传统的瀑布模型的优势越来越被广泛认同。《人月神话》说面对软件研发的工程问题，过去、现在、将来都没有银弹（Sliver Bullet）。这些现代软件研发模式或许也还不是真正的银弹，因为毕竟软件研发在其本质上是创新性的工作，整个过程充满风险，充满失败的可能。但是这些现代软件研发模式的出现，给人们看到了解决软件研发工程问题的曙光，并且已经领略到了其巨大的威力和生命力。

既然现代软件研发模式这么好，那我们就赶紧用上吧。

可问题来了，林林种种的关于软件研发模式的书充斥书店，对于这个领域的初学者，似乎较难入门。毕竟这些模型方法论出现时间还不长，还没有单本进行系统化总结的书，或许这个领域本身还处在一个不断发展的阶段，各种新观点新实践还在不断涌现。除了书太多，人们也发现限于现实工作环境，很难在日常工作中找到一个完美的环境去尝试、去实践这些方法论。在我的职业生涯，我也经历了若干种软件研发模式。从最初微小公司的没有开发过程，到一些“大公司”的臃肿开发流程，我也时时困惑于哪里有“适合天才生长的土壤”。毕竟绝大多数开发人员不是老板，必须要遵守公司所谓的制度。

面对琳琅满目的书籍，形形色色的“最佳实践”，以及现实的工作环境，我们怎么才能把这些现代软件研发模式有效地应用于我们日常研发工作中，从而真正为我们解决问题，提高生产力呢？毕竟研发工作是开发人员一定要做的，以最快的速度，最高的质量完成分配给你的研发任务，究其根本还是于我们自己有利，至少使你不必整天担心最后期限，担心无止境的加班。我的经验是首先学习各种方法论中最经典的书，先站在巨人肩膀上，然后思考隐藏在各种方法论背后本质的原则，最后在日常工作中在自己最大可控范围内以应用这些原则为根本，找到最简单最易操作并能持久的实践方法，最终形成自己的“最佳实践”。我们不一定能改变环境，但是经过努力，我们一定可以改变自己。

在后面章节，我会跟大家讨论我亲自运用过的、切实提高了我的软件研发生产力的实践方法。不过在进入那些话题之前，让我们首先探讨隐藏在现代软件研发模式后面普适的道理和原则。毕竟人类是理性的动物，在真正认清事物的本质之后，我们才会自觉自愿地运用，也才能保证我们使用的方法不会貌合神离地偏离原来的初衷。

前面谈到，现在有很多不同称谓的现代软件研发模式，如果要穷举，估计要用尽你的十指。那么用“敏捷（Agile）”来称呼他们吧。其实敏捷本身就是这些方法论最大的一个特点。因为软件研发本质上是个创造性的工作，唯有用敏捷灵活的态度来认识它、安排它，才有可能达到最佳的开发效果。

敏捷把整个软件研发生命周期划分为多个短迭代周期。

针对软件研发质量和进度较难控制和跟踪的特点，敏捷用多个短迭代周期来组织整个软件研发。每一次迭代就是对软件研发质量和进度进行一次最真实有效的检验，从而让我们得到最真实可信的结论。即便这些结论告诉我们软件项目进展的比最初预期的慢，比最初人们想象的有更多困难，我们也可以更早的做相应安排，避免最后一分钟意外。

敏捷提倡及时的沟通。

在软件研发过程中，程序员多数工作时间是一个人安静地跟电脑打交道，这种特殊的工作形态比较容易造成项目成员之间信息交流不及时、不准确。敏捷倡导及时有效的沟通，通过每日站会和平时及时的口头交流，让每个项目成员获得最真实、最及时的信息。

敏捷鼓励最终用户或用户代表介入整个研发过程。

针对软件需求较难搜集和需求经常变更的特点，敏捷提倡以多种形式让用户更早更长介入整个研发过程，以最大可能保证最终软件符合用户需求，让用户满意。

敏捷注重有效的评审。

人是容易犯错误的。敏捷针对这一特点，对每个研发环节的输出结果，都进行有效的评审。文档、代码、测试用例都需要进行严格的评审，避免“木桶效应”决定软件的质量和进度。

敏捷认为测试贯穿整个研发过程。

敏捷不相信个人主观的假定。任何模块、任何功能的完成情况必须经过让人信服的检验。敏捷认为避免Bug的第一任务人是程序员自己。任何模块在宣布完成或者提交代码库供别人使用前，必须进行充分的单元测试。

敏捷鼓励做真正增加价值的工作。

敏捷提倡以辩证的态度来对待软件研发过程中“必须”要做的任务。“只做”那些真正有利于加强沟通，提高软件质量和进度的事。

敏捷认为代码质量高于一切，要求无情的重构。

软件最终的质量取决于代码，因此软件研发周期的大部分时间和程序员大部分精力应该理所应当的用在提高代码质量上。敏捷还认为，第一遍完成的软件代码不一定是最优的，而是需要经历一定的演化周期、多次重构才能剔除瑕疵、达到完美。