--作者Mike Griffiths
领域：敏捷
穹隅在建筑学里的定义是能在方形基座上搭建圆形的穹顶。下图中黄色的部分则为穹隅。
在传统项目管理工作设置下，我们经常需要一个敏捷穹隅来把敏捷实践恰当地安放到传统的基座上。当与一个不熟悉敏捷的公司交流讨论此方面的概念时，敏捷穹隅也是很有帮助的。
传统到敏捷
1. 工作分解结构（WBS）– 优先排序列表
当主办方和项目管理办公室问到工作分解结构展示时，他们一般想了解的是项目中可交付的成果的分解。传统项目管理体系建议在产品生命周期的前期，也就是在确定范围和收集完具体要求后，就应该立即创立工作分解结构。
而敏捷项目则明白这个提前完成的结构计划在之后很有可能会改变，所以会有意的放轻对于这类定义活动的关注度。敏捷项目更倾向于把时间花在建立应用程序和通过反馈而达到功能的意见一致上。
2. 详细的甘特图表 – 发布计划
再举一个在进行项目之前就提前策划好各个步骤的例子 – 甘特图表。初始的甘特图表，尽管详细，很有可能在之后会因为各种要求和技术的高度不确定性而被经常改动。并不是说我们不能给敏捷项目制定甘特图表（事实上，我会为一些干系人制定此图表），但是不断改变和更新图表需要很多时间和精力。而这些时间和精力是可以更好地用在为了真正业务要求上达到意见统一等等方面上的。
因此，发布含有迭代的计划以及时间框架代替了在软件项目现实状况中难以生存的、含有详细任务的甘特图表。
3. 增值报告 – 基于迭代速率和故事点的报告
传统的增值报告可以在规定时间段内随时能显示项目在进度和支出两方面的表现 – 是超前还是落后。它也可以用来预测完成的时间周期和成本总额。但是，前提是项目本身要高准确度和高质量。“地图非疆域”这句话想讲述的就是：如果现实与我们的地图或计划不符，那么我们要接受事实并画一张崭新的地图。不幸的是，软件项目的多种不确定因素导致我们初始“地图”有很多错误。“先制定工作的计划再随着计划去工作”这种方法只有当你的计划非常可靠时可以采用，但用在变化度高的项目上就只是失败的口诀。
相同的指标 – 预测完成度、成本、进度等等 – 都可以采用追踪迭代速率（团队每一次迭代所完成故事点的数量）来衡量，同时也能知道交付速度以及总故事点数量。更多内容请查看另一文章（英文原版）
总结
以上这些只是敏捷穹隅的一小部分; 他们就像把敏捷的“圆形”方法安置在传统的“方形”环境里的转换器一样。想要找到更多这样的转换器，我们所要注重的是传统要求背后的意义并清楚了解为何敏捷是不同的。
大多数情况敏捷穹隅的存在是为了解决原有计划的不确定性。对于软件项目来说，在对项目了解极小的情况下制定的计划通常效果都不理想。原因在于，大部分软件解决方案都是独特而无形的，也是难以在没有参考相关进化系统时能描述清楚的。敏捷方法利用从逐步精进所积累的知识来不断改善项目规划。
敏捷穹隅也可以用在我们做决定和预测等方面。并不是说因为软件项目的那些独特特性我们就无法完成项目管理的交付。只不过，也许采用另一种方式出现时，这些特性才能更好的体现出来。
