敏捷开发之道

1.做事。指责不会修复BUG。把矛头对准问题的解决办法，而不是人。这是真正有用处的正面效应。把重点放到解决问题上，而不是指责犯错者，或者去抱怨。“为了解决或缓解这个问题，我能够做什么？”、“你出现了什么问题，我能提供什么样的帮助？”。

    2.欲速则不达。不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。如果时间紧迫，可以简单修复，但是简单修复之后要明其理，时间充裕时，要修改。必须理解一块代码是如何工作的，不要急于修复一段没能真正理解的代码。不要孤立地编码，同时也要理解协作成员的代码。使用单元测试可以更深入的理解、运行和使用代码。

    3.对事不对人。在团队协作中，礼貌对待他人，有益于整个团队关注真正有价值的问题。负面的评论和态度会扼杀创新。设定最终期限，可以让人在为难的时候果断作出决策。逆向思维，先积极的看到他的正面，然后再努力地从反面去认识。设立没有利益关系的仲裁人。支持已经作出的决定，一旦确立，通力合作实现之。让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。“我想知道，如果XXX会发生什么情况？”。

    4.排除万难，奋勇前进。要诚实，要有勇气去说出实情。有时，这样做很困难，所以我们要有足够的勇气。“我现在知道了，我过去使用的方法不对。我想到了一些办法，可以解决这个问题——如果你有更好的想法，我也很乐意听一听——但可能会花多些时间。”重写糟糕的代码，降低维护成本。“别管他妈的什么鱼雷，全速前进”。

    5.跟踪变化。你不需要精通所有技术，但需要清除知道行业的动向，从而规划你的项目和职业生涯。迭代和增量式的学习，每天计划用一段时间来学习新技术。了解最新行情，学习优秀的技术博客。参加本地的用户组活动。参加研讨会议。如饥似渴地阅读，软件开发和非技术主题的好书。

    6.对团队投资。提供你和团队学习的更好平台。通过午餐会议可以增进每个人的知识和技能，并帮助大家聚集在一起进行沟通交流。唤起人们对技术和技巧的激情，将会对项目大有裨益。

    7. 懂得丢弃。学习新的东西，丢弃旧的东西。在学习一门新技术的时候，要丢弃会阻止你前进的就习惯。毕竟，汽车要比马车车厢强得多。变化是永恒的，首先要意识到你使用的方法是过时的，果断丢弃就习惯。新技术会让人感到有一点恐惧。你确实需要学习很多东西。已有的技能和习惯为你打下了很好的基础，但不能依赖他们。

    8.打破砂锅问到底。为了解决问题你需要很好的了解系统的全局。要问至少5个为什么。为什么会问呢？因为我不知道。不停的问为什么。不能只满足于别人告诉你的表面现象。要不停的问直到你明白问题的根源。

    9.把握开发节奏。设定一个短时的期限，为任务设定不能延长的最终期限。你可以改变功能但是不能改变时间。项目开发需要有一致和稳定的节奏。编辑，运行测试，代码复审，一致的迭代，然后发布。如果知道什么时候开始下一个节拍，跳舞就会更加容易。

    10.让客户做决定。开发者、经理或业务分析师不应该做业务方面的决定。用业务负责人能理解的语言，向他们详细解释遇到的问题，并让他们做决定。当和客户讨论问题的时候，准备几种可选择的方案。不是从技术的角度，而是从业务的角度，介绍每种方案的优缺点，以及潜在的成本和利益。和他们讨论每个选择对时间和预算的影响以及如何权衡。

    11.让设计指导而不是操纵开发。设计满足现实即可，不必过于详细。好的设计是一张地图，它也会进化。设计指引你向正确的方向前进，它不是殖民地，它不应该标识具体的路线。你不要被设计操纵。在没有经过真正的代码验证之前，不要陷入太多的设计任务。设计是没有价值的，但设计的过程是必不可少的。深入理解需求后进行战略设计，但不要深入到具体的细节。

    12.合理地使用技术。首先需要对你使用的技术进行一下几方面的评估：这可技术框架是否真能解决这个问题；是否会被这个技术拴住；维护的成本是多少。所选择的技术一定是真正适合你的项目的，不要被它零碎的功能所吸引。不要开发你能下载到的东西。因为你的代码写得越少，需要维护的东西就越少。根据需要来选择技术。新技术就应该像是新的工具，可以帮助你更好的工作，它自己不应该成为你的工作。

    13.保持可以发布。在团队里工作，修改一些东西的时候必须很谨慎。你要时刻警惕，每次改动都会影响系统的状态和整个团队的工作效率。在本地运行测试，先保证你完成的代码可以编译，并且能通过所有的单元测试，接着确保系统中的其他测试都可以通过。检出最新的代码，从版本控制系统中更新代码到最新的版本，再编译运行和测试。提交代码。保持你的项目时刻可以发布。保证你的系统随时可以编译、运行、测试并立即部署。你的项目应该一直处于可以运行的稳定状态。

    14.提早集成，频繁集成。提早集成可以更容易的发现系统的风险。集成和独立不是相互矛盾的，可以一边集成一边进行独立开发。代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律地进行集成。绝不要做大爆炸式的集成。

    15.提早实现自动化部署。能用一种可重复和可靠的方式，在目标机器上部署你的应用。质量保证人员应该测试部署过程。提早实现自动化部署，既可以测试应用，又可以测试安装过程。一开始就实现自动化部署应用。使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试依赖的问题。质量保证人员要像测试应用一样测试部署。

    16.使用演示获得频繁反馈。在项目开始之前你是无法得到可靠和明确的需求，需求是时刻变化的。软件开发的成功就在于最后你离客户的期望有多近。频繁的演示可以使你付出很少的代价，就可以避免灾难。需要项目术语表，可以减少团队成员之间和客户之间的歧义。清晰可见的开发。在开发的时候要保持应用可见。每隔一周或者两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。还要建立项目跟踪日志，包括：修正、建议、变更要求、功能增强和bug修复等。做到这些，首先要注重客户的时间，其次缺少功能和稳定性的时候，不应该拿来演示，那只能让人生气。

    17.使用短迭代，增量发布。统一过程和敏捷方法都使用迭代和增量开发。每一次开发都是基于前一次的功能。迭代开发是，在小且重复的周期里，你完成各种开发任务：分析、设计、实现、测试和获得反馈，所以叫做迭代。对付大项目，最理想的办法就是小步前进，这也是敏捷方法的核心。大步跳跃大大的增加了风险，小步前进才可以帮助你很好地把握平衡。使用短迭代和增量开发，可以让开发者更加专注于自己的工作。增量开发。发布带有最小可用功能块的产品。每个增量开发中，使用1-4周左右迭代周期。短迭代让人感觉非常专注且具有效率。你能看到一个实际并且确切的目标。严格的最终期限迫使你做出一些艰难的决策，没有遗留下长期悬而未决的问题。

    18.固定的价格就意味着背叛承诺。主动提议先构建系统最初的、小的、和有用的部分，足够一次交付，并能让用户真正使用。第一个迭代结束时客户有两个选择：可以选择一些列新的功能，继续进入下一个迭代；或者取消合同，仅需支付第一个迭代的费用。如果继续，预测下一个迭代的工作，给他们同样的选择机会。对客户的好处是：项目不可能会死亡，很早的看到工作进度或不足之处，总是可以控制项目，可以随时停止，不需缴纳任何违约金。可以控制先完成哪些功能，并精确地知道需要花费哪些资金。客户承担的风险会很低。

    19.守护天使。编写能产生反馈的代码。确保测试是可重复的，测试你的边界条件，不要放过任何一个失败的测试。单元测试的作用：单元测试能及时提供反馈；单元测试让你的代码更加健壮；单元测试是有用的设计工具；单元测试是让你自信的后台；单元测试是解决问题时的探测器；单元测试是可信的文档；单元测试是学习的工具。使用自动化的单元测试。好的单元测试能够为你的代码问题提供及时的报警。如果没有到位的单元测试，不要进行任何设计和代码修改。

    20.先用它再实现它。使用TDD（测试驱动开发）的技术，在编程之前，先写测试。就会使你站在用户的角度来思考，而不仅仅单纯是一个实现者。因为你自己要使用它们，所以能设计一个更有用、更一致的接口。先写测试有助于消除过度复杂的设计，让你专注于真正需要完成的工作。TDD有机会让你编写代码之前，可以让你深思熟虑将如何用它。迫使你思考它的有用性和便利性，并让你更加注重实效。设计不是在开始编码的时候就结束了。你需要在它的生命周期中持续地添加测试，添加代码，并重新设计代码。

    21.不同环境就有不同问题。我们需要更加面向开发者的测试办法。除了单元测试、测试用例外，我们所要做的就是在各种支持的平台和环境中运行这些测试用例。不同环境就有不同问题。使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极地寻找问题，而不是等问题来找你。

    22.自动验收测试。要使验收测试不同于单元测试。应该让用户在不必学习编码的情况下，根据自己的需要进行添加、更新和修改数据。如果领域的专家提供了业务的算法、运算或者方程式，为他们实现一套可以独立运行的测试。要让这些测试都成为测试套件的一部分，不会在项目生命周期中确保持续为它们提供正确的答案。为核心的业务逻辑创建测试。让你的客户单独验证这些测试，要让它们像一般的测试一样可以自动运行。

    23.度量真实的进度。判断工作的进度最好是看实际花费的时间而不是估计的时间。我们不应该去计算工作量的百分比，而应该测定还剩下多少工作量没有完成。在你最后真正完成一项任务时，要清除知道完成这个任务真正花费的时间。作为下一次的参考，使评估与事实接近，对任务所花费的时间有更清楚的认识。为了使下一步工作是可见的，使用办事项（backlog）。添加新任务要考虑优先级。清楚项目的真实进度，是一项强大的技术。度量剩下的工作量。不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。关注功能而不是日程表。

    24.倾听用户的声音。不管它是否是产品的bug，还是文档的bug，或者是对用户社区理解的bug，它都是团队的问题，而不是用户的问题。我们花费了很大的精力从单元测试之类的代码中获得反馈，但却容易忽略最终用户的反馈。你不仅需要和真实的用户交谈，还需要耐心地倾听。对客户的那些抱怨，既不要轻视，也不要生气。你应该查看一下，找出背后真正的问题。

    25.代码要清晰地表达意图。开发代码时，应该更注重可读性。实际上，从衡量标准上来看，代码清晰程度的优先级应该排在执行效率之前。在改动代码以修复bug或者添加新功能时，首先应该理解代码做了什么，它是如何做的。接下来，搞清楚将要改变哪些部分，然后着手修改并进行测试。同时也应该注意，注释有时是为了帮写的不好的代码修补漏洞。好的编码规范可以让代码变的易于理解，同时减少不必要的注释和文档。

    26.用代码沟通。不要用注释来包裹你的代码。源代码被读懂，不是因为其中的注释，而应该是由于它本身优雅而清晰——变量名运用正确、空格使用得当、逻辑分析清晰，以及表达式非常简洁。代码被阅读的次数要远超过被编写的次数，所以在编程时多付出一点努力来做好文档，会让你在将来受益匪浅。使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码。

    27.动态评估取舍。动态评估权衡。考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了，就将注意力放在其它因素上。不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。提升千分之一的性能远不及节约成本和时间，尽早上市更有意义。

    28.增量式编程。增量式编程可以精炼并结构化你的代码。在重构的原则指导下，可以做出许多细微改善。在很短的编辑/构建/测试循环中编写代码。这要比花费长时间仅仅做编写代码的工作好很多。可以创建更加清晰、简单、易于维护的代码。

    29.保持简单。开发人员更应该为自己能够创建出一个简单并且可用的设计而骄傲。简单并不意味着简陋、业余或者是能力不足。优雅的代码第一眼看上去，就知道它的用处，而且很简洁。但是这样的解决方案不是那么容易想出来的。这就是说，优雅是易于理解和辨识的，但是要想创建出来就困难多了。简单、可读性强才是好的代码。

    30.编写内聚的代码。内聚性用来评估一个组件中成员的相关性。内聚程度高，表明各个成员共同完成了一个功能或者是一组功能特性。内聚性会影响一个组件的可重用性。让类的功能尽量集中，让组件尽量小。要避免创建很大的类或者组件，也不要创建无所不包的大杂烩类。每个类和组件只做一件事。

    31.告知，不要询问。面向过程的代码取得信息，然后做出决策。面向对象的代码让别的对象去做事情。与告知，不要询问相关的一个很有用的计数是：命令与查询相分离的模式，就是将功能和方法分为“命令”和“查询”两类。一个常规的“命令”可能会改变对象的状态，而且有可能返回一些有用的值，以方便使用。一个“查询”仅仅提供给开发人员对象的指针状态，并不会对其外部的可见状态进行修改。告知，不要询问感觉起来就像你在发送消息，而不是调用函数。

    32.根据契约进行替换。

    33.记录问题解决日志。包含以下条目：问题发生日期；问题简述；解决方案详细描述；引用文章或网址，以提供更多细节或者相关信息；任何代码片段、设置或对话框的截屏，只要他们是解决方案的一部分，或者可以帮助更深入地理解相关细节。