敏捷项目管理在各个公司实施当中会遇到各种各样的问题，经常会出现失败的情况，导致敏捷不能落地，从而不能更好的完成项目。在此总结了敏捷项目实施过程中十种简单的方法来帮助大家在公司实施敏捷。
一、找一块真正的白板
成功实施敏捷的团队与没能完成敏捷实施的团队之间最简单最大的区别就在于，他们使用了一块真正的实体白板。
我明白有些团队觉得搞一块真正的白板很难做到，我也明白有些团队分散在不同地方以至于无法共用实体白板，我也明白可以通过电子白板来实现白板功能，但我仍然坚持我的观点。如果你能搞来一块真正的白板，让大多数但不一定全部团队成员都能看到，那你就会接近成功。你必须去亲自尝试它，体会它。当抽象的、理论的软件世界遇见真正白板和卡片时会发生奇妙的事情。
让你的工作具体化仅仅是个开始，学会如何看懂白板上的内容并根据这些开始工作则更为重要。
二、启动项目数据收集并使用统计数据
开发速率、燃尽图、发现的Bug、记录的Bug等等。在软件开发的很多情况下，度量数据的名声都不好，但这是由于人们并未很好地选择合适的度量数据，或者收集与使用的不当所造成，并不能代表度量数据是无用的。你至少需要度量你的开发速率并创建一个燃尽图或一个累计流量图。敏捷的优雅之处在于你只需去度量它的一些简单的度量数据。一旦度量太过复杂以至于人们无法理解，那就无法从中受益了。
三、请一位敏捷教练或顾问
敏捷实施教练和敏捷实施顾问，一般来说他们有能力完成以下各项：
观察、检验、询问并质疑你所正在进行的活动的想法
对选择何种实践和流程并对如何更好地实施它们提供建议
提供他们所见的成功或失败案例，以及其他团队是如何解决类似的问题
你可能需要和不同的顾问一起工作，因为很少有人可以了解所有的流程、实践、技术、产品及战略基准。你并不需要聘用一个全职顾问对敏捷模式进行教导但建议把这项工作做成可持续性的。
四、别光说不练
请别光说不练，行动永远比空谈有效，你无法预见将发生的所有困难与问题直到你真正开始去做敏捷模式。你花在空谈如何去做却从不开始的时间越长，越可能建立起不切实际的期望，最终使之变成又一个噱头。
你可以无时无刻地谈论它，并为之做计划，但除了亲身投入进去并开始进行敏捷模式别无他法。边做边学习边改善，使用一些度量手段去了解正在发生的事情。切勿浪费大好时间去寻找成功案例，而应该自己去完成一个成功案例。特别不要花时间困扰究竟是做极限编程（XP）还是Scrum，精益（Lean）还是特性驱动开发（FDD），动态系统开发方式（DSDM）还是看板（Kanban）。这些几乎都大同小异，最终你不得不创建一种属于自己的混合模式。
五、为每个人提供培训并进行小组讨论
团队并不会因为管理层认为“这就应该是敏捷”而变得敏捷起来，但很不幸，现实中这还是会发生。有些团队成员会阅读相关书籍，但大多数人不会，或者看后就忘记。
花点时间告诉人们什么是敏捷模式很值得 ——或者至少告诉他们敏捷模式对你们的组织意味着什么。现今大多数技术人员对“敏捷模式”都不陌生，但他们能记住多少，结果是好是坏却是天差地别的，团队必须开始形成共识。
但千万不要仅限于此，花点时间让人们说说敏捷模式对他们而言意味着什么，什么是他们喜欢的，什么是他们不喜欢的，什么是他们会做的，而什么是他们不会去做的。敏捷模式是一项团体项目，除非他们形成共识，不然他们只会各顾各地做。
六、要激励、要引导、不要生拉硬拽
任何一名在公司工作过几年的员工总能不幸地见证管理层自上而下地硬拽最新的变更方案：业务流程重组、ISO 9000、Sig Sigma、CRM等等。某些人拍脑瓜想到某些点子，然后开动变更机器将点子推行下去。
就一条简单原则：要引导、不要生拉硬拽。
尝试去寻找一种方法激励每个员工和团队，让他们反过来向你建议采用敏捷模式，这远比强调变更自上而下要好得多。管理者必须首先培养并点燃人们的好奇心，然后等着人们主动来问问题并寻求帮助，最后创建出自下而上的变更方案并给予支持。
想办法点燃人们对于敏捷模式的好奇心，当他们来问的时候，给予帮助，并提供他们所需的东西：同意书本花费的支出，对讲师、培训师和教练提供预算，对会议说“是”。总之一句话，支持，全力地去支持！别置身事外，即使你都了解，你也需要去学习，当团队在形成共识时你需要在场。并且你也需要改变，学着改变你自身的行为去适应它。
七、实施敏捷模式的动机
抛开你在敏捷体系中属于哪个阶层，工程师，测试，项目经理还是主管，问一问自己，你想要敏捷模式为你解决什么问题？搞清楚为何你想要改变并且明确你从中期望获得什么。
不要因为赶时髦而去实施敏捷模式，让敏捷模式帮你实现更重要的东西。去理解每个成员想要从敏捷模式中获得什么，以至于让他们的生活变得更美好。理解组织下想要从敏捷模式得到什么 ——是创新？是可靠的日程表？还是更少的Bug数？
问问你的团队，问问你的老板，问一问“你认为你的老板想要获得什么？”如果每个人都能从中受益，那每个人都愿意帮助实施敏捷模式。反过来，当人们看不到利益，变更将变得异常困难。
当你的敏捷模式进行实施的时候，你需要依靠这些问题的答案来选择你的工具，优化你的流程并衡量你的成败。
八、流程与技术，兼而有之
千万别认为你只要改变下流程，所有情况都会变得好起来。你必须同时考虑技术层面，你必须改进质量，并支持你的工程师，测试人员以及其他进行编码实施工作的人。
我曾遇到过那些认为忽视技术层面的大公司：他们的态度似乎是“那只是技术”如果你是这样的态度，那你必将失败。
跟工程师们谈话，实施测试驱动的开发模式，实施重构，避免大规模的前端设计架构，学着接受粗略设计和演化架构，这些才是真正的反馈循环。
九、使需求更清晰、更干净
敏捷模式要解决的不仅仅是编程方面的问题，还包括需求分析的改进。特别是在有业务分析人员的产品负责人或者产品经理，与开发团队之间保持通畅的途径。更深层次的谈判将首先发生在“什么”上，然后再是“何时”上。必须有人有与需求相关业务的授权，能够拍板儿。
太多公司没能对此引起足够重视，敏捷模式使需求理解更刻不容缓，需求上的瓶颈将对之后的开发产生连锁反应。
自己跟自己做个智力测试吧：如果敏捷模式将开发人员的生产率提高一倍将发生什么？答案是你将需要在需求分析上花两倍多的精力。首先你可能会干掉一个长长的backlog，但你这样做之后，你的余额价值也将减少。
十、结构变更——功能组
以功能组的方式，将所负责工作不同的员工构建成不同的团队——例如：将数据库开发和用户界面开发分成独立的团队。这仅仅是你所要做的结构变更的第一步。但如果你在这里失败了，你就不可能再做一次了。但带来的问题是团队之间请求特殊技能支持或所需的授权将受到影响，因为其他组有另外的优先级。尽量减少这些，因为这将会拖整个团队的后腿，影响团队士气，让你的敏捷实施更为困难。
