持续改进-《高效程序员的45个习惯》读后感
原书标题为《Practices of An Agile Developer》。中文名为《高效程序员的45个习惯-敏捷开发修炼之道》。敏捷这个词已经烂大街了，关于敏捷的书籍俯拾皆是。很多人是敏捷的狂热粉丝，而另一些人却讨厌敏捷，认为只是个噱头。我觉得很可能的原因之一是敏捷这个名字没起好。它的原名为“轻量型软件开发过程”（”lightweight process”），但后来阴差阳错成了agile(敏捷)。
既然书名是敏捷开发者的实践，那么就必须认识敏捷。只有深入的理解了这些实践的来源和目的，才能更好的践行甚至改进实践。
敏捷可以用一句话来概括：敏捷开发就是在一个高度协作的环境中，不断的使用反馈进行自我调整和完善，最终交付用户想要的软件。
从这句话中可以得出很多东西。
首先，项目适不适合敏捷有两个先决条件：
项目是以价值为导向的。也就是整个团队有一个总体一致的目标，那就是产出高质量、高价值、符合用户需求的软件。以价值为导向，看似简单，实则很难，甚至某些时候要要求公司的组织架构做出一定的调整。试想在一个等级森严、官僚化严重、各种无谓的考评泛滥的公司，有多少人能静下心来好好的搞开发，搞产品？只有打造一个相对扁平的组织，给予充分的信任和自由度，才有利于敏捷的实施。这反过来又要求团队中的每个人有高度的自律性。
团队能够达到高度协作。必须能够保证团队中的成员能够流畅的交流。如果在团队中大搞一言堂，信息不透明，很容易打击团队人员工作的积极性，致使团队分崩离析。另外，客户也属于团队中的一员。我们做出的产品最终是给客户看的，如果客户不能保证与团队紧密的合作，那么很容易使产品偏离客户的期望，最终交付失败。
再次，可以看到敏捷的基础：反馈。
一旦你意识到走错了路方向，就要立即做出决策。举个例子，办公室另个团队给我们分享了这样一个故事。在项目刚开始时他们设计了叫做CoreService的类来封装所有的服务。随着项目的进行，CoreService类由于需要处理的服务越来越多，导致类越来越庞大。每个人在修改这个类时，写单元测试要建立对N个服务的mock，苦不堪言。问题在于，没人及时的提出这个bad smell，导致了人们花费了大量的时间来维护它。
这说明了及时反馈的重要性。反馈包含提出反馈和接受反馈。
提出反馈需要勇气和时机。要勇敢的提出自己的想法，这既需要自身具有对项目负责的精神，还要团队提供安全的环境。要及时的指出项目中不好的地方，千里之堤，毁于蚁穴。大灾难是逐步演化而来的，项目中切忌温水煮青蛙。
接受反馈需要气度和行动。这就要求团队成员做事要有专业的态度，对事不对人，重结果轻过程。同时要拿出具体的行动，否则很容易打击积极性。
其次，可以看到敏捷的精髓：拥抱变化。
软件开发行业是一个不停发展和永远变化的领域。现在没有将来也不会有一个人能够了解你的项目的方方面面。
变化无处不在，这就要求我们不断的学习。而迭代和增量式的学习则不失为一个好办法。一个学习型的团队才是较好的团队。当然，在学习的同时，你也要懂得丢弃。打破旧习惯很难，更难的是自己还没意识到这个问题。丢弃的第一步，首先是意识到你还在使用过时的方法，这也是最难的部分。
同时，变化意味着我们要主动应对。德国陆军元帅Helmuth von Moltke说过一句话“没有任何计划在遇敌后还能继续执行。”在软件开发中，我们可以这样理解，任何设计在开发中只是一个起点，它如何你的代码一样，会不停地进一步发展和提炼。
最后，敏捷的目的：交付用户想要的软件。
试想客户将需求交付给你，要你几年后交付系统。然后，你基于这些需求构建了系统并按时交付。客户看了软件以后连声称赞。从此你多了一个忠实客户，接着开心的投入到下个项目中。请问这样的事情在你的项目中发生过吗？
通常情况是客户看到后暴跳如雷，这根本不是我想要的。这是因为用户的需要、技术和我们对需求的理解，都会随着时间的推移而变化。
那么，如何解决这个问题那？方法之一就是采用敏捷的迭代式开发。每个迭代至少有两个活动不可或缺。一个是展示会议（show case），向客户展示目前的项目进展，已完成的功能，从而收集客户的反馈，即时对产品的方向做出调整。另一个是回顾会议（retro)。回顾会议则是提出反馈的一个好时机。通过回顾会议分析出这个迭代中的做的好的地方和不好的地方，并提出具体的改进行动。
要将团队带入新的领域，必须首先要以身作则。我们需要的是领导者，而不是管理者。无论你目前的项目是否是敏捷项目，这本书中你都可以找到能够借鉴和提高的地方。敏捷中的持续改进不仅局限于项目开发，其实更适合于个人。通过持续改进自己的习惯、处事方法，保持一颗好奇心，勇敢的尝试未知领域，只要自己能力提高了，何惧其他？
改变从自身做起，不能自暴自弃，而要奋起直追。
