敏捷项目管理中如何定义障碍并解决它？

如何定义障碍？

让我们先从Scrum中的障碍的定义开始：

任何阻碍开发人员完成他在Sprint容量内所认领任务的事情。

形形色色的障碍：

障碍的种类繁多，大小更是不同。下面列举几个需要警惕的额障碍（他们包含运营性的和系统性的）：

大型会议：Scrum项目想在不需要这种来自外部的、冗长的会议。所以如果这些会议冒出来，通常都是由其他业务或意外出发的。        

病假：俗话说，病来如山倒。谁都无能为力。不过我强烈建议避免“带病出勤，坚持不下火线”的企业文化。这样的期望其实很愚蠢。工作质量下降了；病菌在Scrum屯对的工作区域迅速传染，最后影响到所有人。

不成功的构建：没有成功的构建，开发是没法继续的。如果构建失败，恢复构建就一定是每个团队的首要任务。

开发工具问题：不论是硬件故障，软件问题，还是网络连接问题，所有与工作环境相关的问题都会严重妨碍进展并引起极大地挫折感。

产品列表未细化：在产品负责人确切知道哪些需求应该放入Sprint列表之前，不应该开始当前的Sprint。具体而言，这些需求应该包括足够多的细节，以便开发团队能够全身心投入。如果这些需求没有准备好，当前Sprint根本无法顺利开始。

产品负责人缺席或没有权限做重要决定：在整个Sprint中，产品负责人应该随时可以联系并且可以在现场解答Sprint列表的具体问题。如果他经常不再活着老是做不了主，得再请他人批准，开发团队可能就会因为不确定性而人心涣散。

关注个人的激励方案：很多组织保持着完全基于个人绩效的考核制度。希望你已经完全接受Scrum团队的“忘我”原则。除非绩效考核也在很大程度桑关注团队协作，否则组织回味团队成员传递矛盾的信息。

五步控制障碍法：

下面我给大家介绍一下五步控制障碍法（ConTROL）：确认Confirm，诊断Triage，去除Remove，告知Outline，学习Learn。

确认：我们有必要确认障碍到底是什么。通常我们会在每日站会上提出都遇到了什么障碍，但紧急障碍应该立刻提出而不是等留到站会上说。Sprint回顾会可以用来发现Sprint中溜过的障碍。所有的障碍都应该跟踪，直至解决为止。

诊断：如果同时受累于多个障碍的轰炸，那么除非超人，否则只能同时解决一两个问题。根据影响的大小和问题的紧迫性来判断从哪里入手。

去除：在理想情况下，Scrum团队可以排除所有拦路虎。但常见的情形是，理想很丰满，现实很骨感。为了避免项目延期，还必须知道择机寻求其他团队的帮助及时回到正轨，这一点也很重要。

告知：在遇到障碍时，得让Scrum团队和干系人之情。特别在项目必须选择撤退方案时，尽量先给产品负责人和项目发起人打个预防针，不要让他们觉得很突然，让他们能有足够的时间消除可能带来的一系列负面影响。

学习：Sprint回顾是分析和研究障碍的主要战场。从问题中吸取经验教训，避免再犯错，掌握解决之道，这样一来，即使问题复现，也不会有太严重的影响。