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