有关敏捷的若干思考

这段时间的咨询工作大多是围绕需求、分析和设计的，但感觉上都直接或间接地和敏捷相关，于是就将这些思考记录下来：

 

l         敏捷是太极：这段时间下来，感觉敏捷很像太极，两仪生四象，四象生八卦；敏捷的精髓在神而不在形。敏捷的神就包含在下面四条敏捷宣言（Agile Manifesto）中：

n         个人和交互重于方法和工具（Individuals and interactions over processes and tools）；

n         可工作的软件重于完备的文档（Working software over comprehensive documentation）；

n         与客户的协作重于合同谈判（Customer collaboration over contract negotiation）；

n         响应变化重于严格遵照计划（Responding to change over following a plan）；

 

实施敏捷的关键在于掌握这些原则，然后将这些原则与组织的自身实际情况相结合，再制定合理的改进计划，而不是照搬敏捷所有的具体建议。

 

l         敏捷是有国情的：如Ivar所说，敏捷的最重要创新在于它是一项以激励开发人员工作热情为目标的社会工程。敏捷作为一个社会工程，它的许多建议是有社会性的，比如自组织的团队（Self organizing teams）。这一建议就跟欧美的实际情况有关：良好的替代职业发展道路、社会福利体系以及相对扁平的薪酬体系是很多优秀的程序员安心地以程序员为终生职业，程序员比开发经理资深的情况比比皆是。而这一情况在目前中国是显然不存在的。理解了这一背景之后，一个组织就应该仔细去衡量“自组织的团队”在本组织内的可能性如何了。

 

l         敏捷是要破除两个迷信：俗话说，不破不立。要实施敏捷，首先需要做的是打破开发组织中的两个迷信，挣脱枷锁，才能轻装前进。一个迷信是软件开发可以成为生产线，每个岗位的职责可以被明确定义，各个岗位之间接口同样可以被明确定义，大家只要各司其职，高质量的软件就可以被生产出来；生产线是我们的愿望，但不是现实；按照这样的美好愿望去组织软件开发必然付出惨痛的代价。软件开发是一个高度复杂的团队智力活动，如同创作一件雕塑作品一样，在基本的职责框架下，团队内部必须协同合作，才能开发出高质量的软件。画地为牢是行不通的。另一个迷信是软件开发过程可以向建筑一样被准确地预测和计划，这同样是美好愿望而不是现实。敏捷号召的就是在这两个问题上回归现实。

 

l         敏捷不是要回到十年前的程序员无政府状态：回归现实并不意味着将这十年来的过程/质量控制经验全都付之一炬。在我们咨询的过程中，我们发现一个对敏捷的误解是：敏捷=随心所欲；很多刚入行的程序员为此欢欣鼓舞，而大多数领导和质量保证人员则对此忧心仲仲（因为大多数现在的领导恰恰经历过十年前的无政府状态，也深知其中的问题），这种误解对敏捷是非常有害的。

 

l         敏捷是对僵化实施CMMI的反正：敏捷的目标应该是重新审视现有软件开发流程，放弃不切实际的梦想（流水线和准确计划），根据敏捷的基本原则，重新优化现有流程和文档体系，但不是全面推到重来。在这个过程中，需要不断地问各种问题：为什么要写这些文档？给谁看？目的是什么？这个活动的输入输出是什么？由谁负责？由谁辅助？等等。在一个组织当中，很多流程和文档是多年累积的结果，当时设计这些流程和文档的初始条件可能已经不存在了（例如，当年是主做新系统的开发，而现在已经大多数是做现有系统的维护了），因此，需要用敏捷的思想对现有流程进行优化。

 

l         敏捷是分层的：敏捷根据实施的范围应该是分层的，可以分成小组级敏捷、组织级敏捷。小组级敏捷的重点是一个小组（10-20人）如何进行协同工作，这是目前敏捷的热点；而组织级敏捷的重点是如何将一个大型项目分解到小组，如何保证小组能够协同工作，如何保证敏捷的流程与企业现有的管理体系接轨（如IPD，QA，CMMI等），如何优化现有的流程与文档体系，这些才是敏捷真正实施中的难点。