Scrum、Kanban、精益开发、Lean Startup、DSDM、FDD—这就是字母汤。这些在项目管理中又是如何建设的呢？这其中有没有贵公司拿来就可用的？抑或你需要定制化出自己的方案？

　　不要陷进品牌和商标里面。要盯住贵公司的目标不放。要想取得长期成功，目标需要具备有可能最好的质量，这样产品才可以愉悦客户，同时还能让技术债务保持在可管理的水平上。

　　怎样才能知道你的团队何时是敏捷的？我推荐Elisabeth Hendrickson的敏捷酸性测试（Agile Acid Test）：敏捷团队以可持续的节奏带来持续价值的同时适应业务的变更需求。此处的关键是“可持续的节奏。”我们必须每两周、每一周、每天多次地交付生产就绪的代码，我们不需要疯狂工作和实现每一个新功能都要花越来越长的时间。

　　自然地，我们转向已有流程寻找答案。Scrum和Kanban均提供项目管理框架。不仅仅是软件团队，整个组织内部都在采用精益开发。极限编程（XP）提供了核心开发实践，这适合于任何项目管理框架。有的公司则想出自己的方式去开发产品，但仍然通过了“敏捷酸性测试。”

　　提出合适的问题

　　“敏捷”并不意味着“跑得更快。”正如前面所述，向敏捷的成功转变需要预先有巨大的时间、学习及训练上的投入，但这些投入从长期来看也会带来巨大的回报。

　　通过让你的软件组织的每个人一起提出好问题来开启你的敏捷之旅，最大的问题是什么，是不是清除这个障碍你的团队就会前进一大步？这有可能是技能的缺失、软硬件基础设施的不足，项目不能按期交付，交付的产品不符合客户需求等任何潜在的问题。识别出你最大的障碍，战役就算是打完了一半了。每次迭代都至少回顾一次是最有价值的敏捷实践。

　　一旦识别出最大的障碍，考虑进行小型实验让这个问题变小一点，或者规避此问题一段时间。选择小规模实验可以得到快速反馈，供下一次迭代进行调整。比方说，你的最大问题是每天都有好几次编译失败。你可以试着用彩灯在团队所在区域来显示持续建造进程的状态。

　　在你下一次回顾的时候，看看那个最大的障碍是不是变小了一点。如果没有，考虑尝试另一种小型试验方法。你也许会发现真正的问题出在别处。或者也许你的试验把障碍规模削减了25%，使得它不再成为你最大的障碍。这种情况下，你就得转移到现在的最大障碍然后重复这一过程。

　　用替代方案教育自己

　　现在，你已经专注通过尝试小型试验、检查和适配来削除自己的最大障碍。你仍然需要一些框架来管理你的产品开发和项目进程。你还需要核心开发实践来保持技术债务在一个可管理的水平上。哪一种敏捷“风味”最适合你的情况呢？

　　在评估不同敏捷实践、过程、框架及工具时，敏捷宣言及其原则是你最好的指南。有许多优秀的书解释了敏捷原则、特定的敏捷项目管理框架，如Scrum和Kanban，以及像（测试驱动开发）TDD和持续集成这样的敏捷实践。

　　加入在线和本地的敏捷用户团体来获得好书、好博客等出版物的推荐，这可以帮助你量身打造自己的敏捷开发方案。请教更多有经验的敏捷实践者，请他们推荐培训课程、会议等其他你可以学到更多东西的资源。

　　回想起2000年当我启动自己的首个XP团队的时候，我加入了Yahoo极限编程组，在那里我得到了许多帮助和指南。不久我们就组建了Yahoo敏捷测试组，把有关测试的讨论范围缩小。我还跟本地区的其他实践者一道组建了XP Denver（之后改名为Agile Denver）用户组。过去几年，我已经从我跟踪的许多人的Twitter那里学会了很多东西。

　　带你的团队进行实地考察，拜访其他更加成熟的敏捷团队。我自己的团队就是通过观察别的团队来获得某些我们自己最好的创意的。

　　一旦理解各种敏捷项目管理框架和方案之后，就可以选择一个加以尝试，不过要确保有适当的人选来帮助你开始。

　　获得帮助

　　实现一个像Scrum一样简单、直接的项目管理框架，一个晚上就可以弄完。然而，要想以组织运作的方式产生有意义的变化则需要底层企业文化的改变。这是一项困难、棘手的工作，有可能会失败，因为人们不喜欢改变，而公司的官僚政治会带来许多的障碍。有一位已经成功经历过敏捷转变的人会是一笔巨大的资产。如果可能的话，雇用一位或多位曾在成功（且真正敏捷的）团队工作过的开发者、测试员、分析师、Scrum Masters、教练及/或具备其他技能的人。

　　最起码也要有一位熟悉如何成功改变公司文化的有经验的敏捷教练。找一位愿意跟团队一起长期实践的人，哪怕一个月只有几天的时间，也要让他帮助团队成员学习如何自我组织团队、如何解决自身问题。确保每一个人每一个角色都得到支持、培训和学习所需的时间。要想到人人都会犯错误，帮助他们从错误中学习。现在进行花大血本好过数年后“停线”，要“修理”一切东西。

　　通过实验来客户化

　　一旦选择敏捷方案或过程进行尝试，最好还是从“书本”开始。随着你的团队有了经验，就可以开始找出问题然后尝试小规模实验进行处理。也许你还可以尝试拿来主义，试一下你实地考察过的团队采取的前述的其他敏捷项目管理方案或技术。通过回顾来评估实验效果，然后再想出新的点子。

　　我现在这个团队2003年开始从瀑布式（Waterfall）转到Scrum。包括我在内，有敏捷经验的团队成员都是引进的。我们在产品订单中判断用户故事，进行计划冲刺和回顾，学会了让Scrum发挥作用的核心要素：如何成为一个自我组织的团队。为了兑现我们尽可能开发出最好质量软件的承诺，我们不久就采纳了XP实践。第一年的时候，因为需要时间去学习新的实践以及还清数年的技术债务，我们每一次冲刺都只交付少量的新功能，一旦我们有了经过测试的更整洁的代码作为雄厚的基础，并且学会了如何与利益攸关者协作来获得案例来推动开发，我们的速度也在稳步提高。

　　多年来，我们已经放弃了一些不能为我们增加价值的Scrum实践，并从精益开发和Kanban吸收了技术和原则。如果你参观过我们的团队，也许看不出我们实践的敏捷“方法论”是什么。重要的是我们能够在适应业务需求快速变化的同时保持一个稳定的速度。我们持续研究新方法来对我们的工作进行计划和管理，并带来更多的价值。

　　从来没有过一个项目的成功是由于特定方法论的功劳。项目成功要归功于有合适的人能够做出最好的工作。确保你有合适的人选，清除你前进的障碍。专注于提供质量尽可能好的软件。花大量时间进行学习和实验，在专家帮助下找到并实施最适合你的情况的流程和实践。让敏捷宣言及其原则指引你找到尽快为业务交付价值的办法，同时还能让自己保持一个可持续的步伐。