如何把敏捷思想融入到瀑布式开发环境中(3)

　　神话1：敏捷关注人/传统的项目管理是命令和控制式的。

　　从事越来越复杂的咨询和系统设计项目工作6年后，我发现自己管理别人做技术工作的时间多于我自己做设计网络工作的时间。2000年，Cisco公司的一位销售代表告诉我，我在做的事情实际上应该算是项目管理。我在2001年通过了PMP考试，现在成了“正式的”项目经理。

　　在接下来的几年里，我使用顺序式的方法，管理了大大小小很多个项目。正如古语所说，“当你只有锤子时，你就会看什么都像是钉子”。幸运的是，我这些项目都很适合顺序式的模型。我经常负责在华盛顿西雅图的Fred Hutchinson肿瘤研究中心新建筑项目中的IT工作。这些建筑物不仅要安装重要的网络基础设施和服务器，也要安装高度敏捷的技术医疗设备，在设备安装时往往并不需要我的帮助。这些项目工作是由建筑物的施工进度驱动的，是一个非常有序的过程。

　　在2005年，建筑项目放缓了，我开始做更多的软件项目。与建筑项目不同，软件基本上是无形的。传统的项目管理有一个未阐明的假设，它假设你一直可以看到一些东西，如地面上的大坑挖好了、地基打好了、钢筋也铺好了。软件项目却不是这样。如果按顺序的方法管理，软件项目直到项目结束才能看到东西。当项目结束时，你指望所有的事情都做好了软件就能运行。但是你用这种方式管理过软件项目的话，你就知道这是行不通的。

　　经历过一次特别沮丧的项目失败后，我对软件项目的发展趋势作了广泛的研究，我觉得Scrum Master课程对我会有比较大的帮助。碰巧Ken Schwaber(Schwaber，Scrum.org，2010)当时在西雅图授课。在Scrum Master课程中，我学到了与结构化的软件项目完全不同的管理方式，这种方式使人们能接受变更，并能随时清楚地显示项目进展，即使像软件这种无形的产品也不例外。并且我发现，它潜在的哲学更有趣。

　　图 3

　　我一直采用服务型领导的方式管理项目。我是技术人员，但我也知道，致力于具体的数据库、网络、程序语言的研发人员，对技术领域的了解远胜过我，他们知道怎样才能把工作做好。作为项目经理，我的工作是帮他们把工作需要的知识组织起来，使之可管理并能汇报给老板和管理层，消除障碍，识别可能发生的风险，让他们能消除或减轻风险。我总是竭尽所能来帮助项目中的技术人员，让他们可以自由地去做自己最擅长的事情，而不用被虽有必要但却会打扰工作的项目预算、报告项目状态等其他事情干扰。Scrum也分享了这个观点。像“鸡”和“猪”(Schwaber & Sutherland，2010)，由被激励的个体来建设团队，并相信他们可以做好工作、可以自组织、以平衡的速率工作，这些都表明了对人的持续的关注。

　　神话2：项目不是敏捷模式就是瀑布模式，没有中间地带。

　　既然我们已经解开了管理风格和交付方式的谜团，接下来我们再讲一下关于二元决策方法的神话。Robert K. Wysocki定义了项目交付物的五种离散的模型(Wysocki，2009)。Chri Ward和Leonardo Legorreta对Wysocki的模型进行了改进(Legorreta，2009)。

　　Wysocki和Legorreta定义的项目管理的五种类型是：

　　瀑布式

　　迭代式

　　增量式

　　自适应式

　　探索式

　　根据我的经验，自适应式和探索式的方法大致相同。大多自适应的方法都允许范围变更(随时可以向backlog增加故事卡片)，区别仅仅是理论在现实生活中的一些不同。所以在此次讨论里，我把这两个模型合为一个，称为敏捷。

　　顺序式——顺序式模型是用于中小型项目交付物的传统方法。项目工作可以按此顺序进行：明确项目目标、确定项目范围、做总体的项目计划、开发、测试、部署。这个模型适用于：小型或中型的、工作成果可以一次性有效地交付、需求非常清楚、不产生变更(如来自政府或行业法规要求的需求)的项目。

　　增量式——增量式模型是一种特殊的顺序式模型，只是它能够按阶段或者以迭加的方式交付成果。就像顺序式模型，增量式模型先确定了项目范围并提前做好计划，因此它最适合需求明确而且不易发生变更的项目。在每个增量中，团队可以选择怎样工作来满足交付要求，但不会讨论“做什么”和“为什么做”。

　　迭代式——迭代式模型与“提前做好计划”的顺序式模型、增量式模型相反。大多迭代模型实际上是迭代和增量。在迭代式模型中，随着项目的进展，项目计划也按迭代逐步细化。项目初期会为整个项目做高层次的计划，但是计划的粒度比较粗且常会变更。人们只对即将要做的工作做详细的计划。通常只对1周到1月内的短期工作做详细计划，其它的工作以后才会做详细计划。迭代式模型采用了增量式模型中延期规划的方法，并且从精益概念中借用了尽快交付的概念：尽可能晚做决定、根据流程工作(Womak & Jones，1996)。在增量式敏捷的工作中，团队从项目发起人和/或客户那里获取工作内容。在每次迭代中，团队既可以选择如何工作来满足交付需求，也会询问发起人或者客户要做什么事情。我们可以根据发起人和/或客户的输入来调整工作的优先级，完成更重要的功能特性，满足客户的交付要求。不过所有要求的特性(由于监管或遵从)最终都将被交付。

　　敏捷式——敏捷式模型允许在每次迭代开始时添加或移除工作范围。在敏捷项目中，需要客户经常反馈，以确保功能特性是按照对客户具有最高价值、对客户最有益的顺序交付的。此外，来自产品负责人或客户的任何新的想法都可以加入到backlog中。经常展示可运行的软件，其作用就如同 Heisenberg的“测不准原理”——测量的结果会影响测量(Cassidy，2002)，所以，看到的可运行的软件也会影响客户的需求，让客户产生新的更好的想法(Barry Boehm有一个首字母缩略词：IKIWISI-虽然我不知道我要什么，但是“当我看到了我就知道了”)。有的项目问题很复杂，甚至早期对问题都还没完全理解，这时去理解解决方案就更难了，因此对这类项目需要采用敏捷灵活的流程。

原文转自：http://www.ltesting.net