管理大师的敏捷之道

转自：http://www.infoq.com/cn/articles/deming-and-agile

领导者是教练，不是裁判”—— W Edward Deming并不是在ScrumMaster课程上说的这句话，但毋庸置疑——这句话能引起每个名副其实的ScrumMaster的共鸣。

QClub北京：云端的Ruby on Rails

Deming是上世纪对现代管理学形成有重大影响的思想领袖之一。他在设计、制造、销售和质量方面的学说对日本经济发展产生了深远影响，他也因此举世闻名。日本比美国更先采用了Deming（一个美国人）的学说，并因此取得了巨大的生产力和质量的提高。他的学说帮助日本公司制造出优秀的产品，占领国际市场，因而饱受赞誉。为了肯定Deming所作的贡献，日本科学技术联盟（JUSE）以他命名了日本的国家质量奖。Deming奖是世界上最早的、 在制造业最有影响力的奖项之一。不久之后，Deming学说也开始在美国被采用。晚年，他致力于帮助福特汽车（Ford Motors）和施乐（Xerox）等公司的高层们改进他们的管理风格。

Deming学说要怎么和敏捷软件开发相结合呢？毕竟，他的学说关注的是制造业的效率——而传统瀑布软件开发方法论的一些缺点，就是因为尝试采用传统工程流程来构建软件而导致的直接恶果。作为敏捷方法的实践者——我们当然想要认清软件项目的不同特质，从而避免用传统方法中的弊端。然而这些学说中的管理理念其实超越了特定的工程学科。其中丰富的智慧如若善加利用，将能帮助提高敏捷实践的有效性。

Deming学说最著名的部分是他于1986年发表的《摆脱危机》（“Out of the Crisis”）一书中的管理建议集。也就是著名的“Deming学说十四要点”（“Deming’s 14 Points”）。这十四点和敏捷实践的相关性不容小觑。随着敏捷过程日渐成熟，作为实践者的我们要忠于敏捷宣言的精神，而不要被敏捷方法诸多变种所定义的形形色色的任务牵着鼻子走，就显得至关重要。这么做的一个可靠途径就是在做项目时用Deming学说十四要点来检视我们的判断。我们可以用这些要点作为隐性的指南来驱动项目。接下来的部分，本文将逐个探讨要点的相关性，并阐述它们在敏捷项目中是怎样充当指南的。

要点一：树立改进产品和服务的长久使命，以使企业保持竞争力，确保企业的生存和发展并能够向人们提供工作机会。

很多组织的软件开发人员认为他们自己和商业战略方向没有什么关系。只做表面功夫的敏捷实践常常会助长这种认识。在实践短期迭代并且短周期发布的过程中，团队常常犯无视当前迭代以外的——或者充其量，当前项目以外的任何东西这一类错误。

Deming学说不仅倡导经营要关注它的目的，对软件团队而言，它也强调一个经常被忽视的最佳实践——理解你们项目的真正目的，并忠于它。

开发软件产品是为了实现一些特定的商业目标。这些目标来源于公司的战略方向。公司战略又以市场战略为依托，通过产品组合计划来贯彻执行。在实现众多项目中的单个小故事点过程中，时刻不忘整体战略视图（图1）显得尤为重要。

为了有效地开发一个产品，项目团队需要理解公司的整体战略，以及必要的、与项目相关的市场和产品战略。一个具体的迭代可能有3或4个用户故事点要开发，而在开发这些故事点时，关键要谨记整体总是大于局部之和。如果我们仅仅关注单个故事点，而没有考虑这些故事点对产品其它部分以及系列产品的影响，我们很可能没办法使这个故事点物尽其用。

举个很简单的例子——迭代中有个故事点要开发一个从外部捕获数据源的web service。故事点可能对所捕获数据的用途只字未提。在这种情况下，除非开发人员知道这些数据在下游产品中的用途，否则他不可能很好地为这些数据设计出持久性策略。如果这些数据需要进一步的转换，它就需要经过某种处理——而如果它只是以报告为目的的，可能就要用另一种完全不同的方法了。

这个层面的认知只能通过花时间来学习产品战略方向、预期用途、目标用户和使用期限。

图一：故事点的战略性视图

Deming的这个要点还强调了有效沟通的必要性。通常商业利害关系人并不花时间来讲解产品的用途，而工程师们也懒得弄清楚这些。因此团队常常无休止地纠缠于纷繁的目标之间无法自拔，最终只能以低质量的、不满足公司真正需求的产品来收场。

在这点上有两个最佳实践能帮上忙：

• 预先制定一份较粗的、涵盖整个项目的计划——这可能看起来和敏捷理论有些背道而驰，但实际上并不。敏捷原则只建议不要预先做细分到任务层面的计划——但它并不是劝阻任何层面的计划。能展示里程碑并列出产品所有主要特性的、较粗的计划有助于为单个故事点提供必要的上下文环境。
• 将产品愿景写成文档，并经常和所有的利害关系人沟通确认。愿景文档不需要很详细——但它应该包括足够的信息，能够清楚地解释产品背后的战略、预期用途和发起者的期望。随后团队要特别重视在项目过程中定期地回顾一下愿景文档，并做一些必要的航向修正以保持与愿景同步。

要点二：接受新的理念。在一个新的经济时代，西方管理者必须意识到自己的责任，直面挑战，领导变革。

Deming学说在这里主要关注的是领导层。他希望敦促管理者们接受改革并将其融入到组织生活中去。Deming这里所指的改革源于全面质量管理的实践。它要求管理者作为表率，带领工人们一起，让组织在不断变化的经济环境中朝着它的竞争目标勇往直前。

组织改革跟实施敏捷再亲不过了。敏捷理念的醉翁之意本就不止于开发团队的变革。成功的敏捷实施要求行政大佬以及各方利害关系人都进场，做组织架构的调整——只有高层支持，这一切才能得以实现。许多敏捷团队的失败正是由于缺乏高层支持，最终不得不重回瀑布式开发。

敏捷为技术项目引入了一个新思路——它要求采取全新的产品市场策略，改革产品发布方式和预算机制，与此同时，也要对客户服务和销售的运营方式做相应调整。 敏捷开发能使各方精英汇聚一堂，齐放异彩——然而如果产品计划不能随团队增量开发而与时俱进，或者营销信息没有根据增量发布做相应调整，最终结果还是不会 尽如人意。只有能够打破部门界限的高效跨职能团队，以及足够的高层支持，才能实现统一步调，成就大业。

不论你喜欢不喜欢，这一过程都需要时间和耐心。这可能是在组织中实施变革的最大难题。但无论如何，它都是达到成功的关键要素，非做不可。

有一个加速此过程的途径，就是在组织里设一个敏捷传道士的角色。这个角色要让一个娴熟的敏捷主义者担当，这样既可以和管理高层保持有效良好的沟通，又可以对形形色色的利害关系人进行淳淳善诱。

要点三：不要将质量依赖于检验。要从一开始就将质量渗透或融入产品之中，从而消除检验的必要性。

对大多数软件项目而言，质量是马后炮。这像是给开发过程狗尾续貂，而且大家都觉得这仅仅是测试组的职责所在。

敏捷则用一个彻底不同的方法实现高质量——这一方法其实就是Deming的要点本身。高质量是不能通过测试人员检验开发人员完成的工作来实现的。 高质量只能通过开发人员、需求分析员、架构师和测试人员同心协力，把质量检测作为每个人工作的一部分来完成，才能得以实现。测试人员需要关注的是测试在商业需求方面产品的表现如何。他们不应该测试某个代码单元的实现正确与否。每个开发人员要致力于产出高质量的代码；这些代码则要达到设计的预期。

敏捷方法有一些很棒的实践就是针对打造高质量产品的。测试驱动开发的实践——加上持续集成，如果实施得当，就能大大减少低质量产品流入测试阶段的机会。实施这些过程有时看起来像空中楼阁，并不是所有的开发团队都有足够的设施以及资源来完全实现它们。

但将质量意识根植到每项要做的任务中是一个对任何团队都有益的目标。

另外一个直接影响高质量的关键因素是所有利害关系人的紧密参与。敏捷的一个核心原则就是“业务人员和开发人员必须通力协作，且贯穿项目过程的每一天

那些不能获得业务专家、用户群、市场营销、销售以及其它商业相关人员积极参与度的项目，通常就会在前期失去了构建高质量的先机。随后这些项目只好依赖事后检验，还以低质量产品而告终。

如在前面部分的三点讨论中我们所看到的，Deming学说和敏捷项目原则显示了惊人的一致。无论是敏捷新人，还是有经验的敏捷实践者们都可以把这些要点当做一套简要指南来帮助他们实现敏捷。在接下来的期刊中，我们将继续讨论剩下的十一个要点以及他们和敏捷世界的关系。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14639675/viewspace-625564/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14639675/viewspace-625564/