下文的构思源于我们在4月21日「PM Open Day」上的主题分享。之所以组织这个活动，是希望搭建一个学习和分享的平台，将更多从事项目管理或有兴趣了解项目管理的同学连接起来，一起学习项目管理经验、交流敏捷精益思想。
在3个小时的时间里，我们从「走进敏捷」讲起，以「敏捷团队的管理艺术」为领跑，期望带领大家了解「敏捷项目中的Inception」，以及如何做好「敏捷项目可视化」，从而帮助项目成功交付。限于时长，还有很多未尽之意。期待和大家的进一步交流！
正文
作为项目经理，在每次接手项目之前会有什么样的想象？我猜想大多数的项目经理在迈入下一个项目之前的心情通常是愉悦的。有如这张图片：对自己充满了期望、对未来充满了想象。
然而事实确是如此吗？网上有句很有趣的话：理想是丰满的，现实是骨感的。
的确，项目经理会面临重重困难：
第一，团队里的每个人都不好管，而且每个人都认为自己不需要被管理。团队之间总会有各种协同和沟通的问题，而且这些问题会在团队发展的生命周期中不断“演进”。——《敏捷团队的管理艺术》
第二，敏捷软件开发已经被越来越多的人了解并熟知，然而在如何在项目管理中更好地运用各种敏捷实践、并迅速推动项目进入正轨的问题上，似乎没有标准的办法。——《敏捷项目可视化》
第三，市场的需求瞬息万变，往往留给项目经理的时间非常有限，他们需要学习大量项目相关的上下文，比如说业务、人员关系等，以便面对更快的变化。——《敏捷项目中的Inception》
我发现一个有意思的现象，在经历了黑暗、看见了朝阳之后，我们就会对未来充满希望和想象，但是不知道的是，黑暗还会到来。
就像我，我每天下班回家的路上，都会想象，我儿子可以30分钟完成今天的作业，然后我们可以进入愉快的亲情玩耍时间。然而事实呢，我每天都会和我儿子斗智斗勇。如果把完成作业比作项目交付，我们会发现每天计划的交付时间都会延长，更别提交付质量。
我会降低标准，在我儿子的作业本上签上我的名字、然后洗澡睡觉。一觉醒来，虽然想着前一天的交付情况，有很大可能会被请家长，但是对新一天的渴望会降低我和儿子对请家长的恐惧，我们又会无比快乐的开始新一天的生活。
直到晚上我们回家重新开始新一轮的迭代。
怎么办呢？作为项目经理的我们，不断地经历一个又一个的项目，一次次地面对相同的问题。如果不从中总结和提炼，我们就会反复地徘徊在丰满的理想和骨感的现实中。我想这也是我们今天齐聚于此的初心。
走进敏捷——敏捷解决什么样的问题
欲知其然，先知其所以然。我们首先需要知道“敏捷”在解决什么样的问题。Cynefin框架能帮助我们厘清思路。
Cynefin框架最早是1999年由威尔士学者Dave Snowden在知识管理与组织战略中提出的。这个框架用于描述问题、环境与系统。说明什么环境，适合使用什么样的解决方案。Cynefin框架有如下四个域：
简单：该域中的因果关系显而易见，方法是感知——分类——响应（Sense - Categorise - Respond），我们能够应用最佳实践。简单的问题很容易解决，它的目标是明确的，达成路径也是明确的，只要依照步骤就一定能达成目标。
繁杂：该域中的因果关系需要分析，或者需要一些其他形式的调查和专业知识的应用。方法是感知——分析——响应（Sense - Analyze - Respond ），我们能够找到并应用好的实践。
复杂：该域中的因果关系仅能够从探索中感应，方法是探索——感知——响应（Probe - Sense - Respond ），我们能够感知涌现实践（emergent practice）。对于复杂的问题，目标和路径都是不清晰的。在推进的时候需要不断根据遇到的情况进行决策，没有现成的经验可以借鉴。
混乱：该域中没有系统级别的因果关系，方法是行动——感知——响应（Act - Sense - Respond ），我们能够发现新颖的实践（novel practice）。
举个例子，我们也许有一个“绝佳”的产品创意，自认为这是一个足以改变市场模式的颠覆性想法；或者我们有一个能让我们领先于竞争对手的全新尝试。然而，在继续之前，我们会面对如下的风险：
目标用户不存在：想到了一个解决方案就直接想要做出来，顾不上做用户调研，不了解设想的目标用户是否真的存在、用户群有多大、生活的状态是怎样的。
目标用户没有这个需求：思考从解决方案出发，想到或看到一个功能，觉得不错就想做。没有去验证目标用户是否真的有这样的需求，是不是早就有了足够好的产品解决了这个需求。
解决方案毫无亮点：想到一个还可以的解决方案就不再继续探索了，一些创新的点子觉得它不可能就直接放弃了。没有掌握做创新的有效方法。
一开始就想做大做全：想做精品，想要做精致的用户体验，想到什么功能不错就往产品上加，想要一下就做的很完美。但如果一开始方向就错了，再精致的产品，价值也是零。
这无疑是一个复杂的问题，我们需要探索、感知和响应。“敏捷”用以解决这样的复杂问题，它是在问题本身或问题解决能力不能确定的情况下取得尽可能好的结果的问题解决方式。
最小化可行产品（Minimum Viable Product, MVP）是敏捷的实例化展现：不断开发出可用的产品，通过测试并收集用户的反馈，快速迭代，不断修正产品，最终适应市场的需求。
走进敏捷——敏捷团队的守、破、离
在了解敏捷解决什么样的问题之后，我们再来思考如何在项目管理中更好地运用敏捷实践。
我们可以从“功夫”中总结出一套可以掌握所有事情的规范模式。练功的学徒需要经历三个阶段：守、破、离（守即服从规则，破即打破规则，离即创造规则）。
敏捷团队处处都能看到规则的踪影。比如15分钟左右的站会，不管发生了什么，都按照预定时间开始和结束，而且每个成员只回答三个问题。这样将规则安插到团队工作的每个环节的过程为“守”。
当团队开始学会隐藏在这些实践背后的原则，理解更深层面的意义的时候，他们开始打破规则，然后用敏捷开发的“检查并调整”机制来告诉他们这些规则是否是正面和有用的。这个过程为“破”。
对于“离”阶段的敏捷团队，他们也许会决定用其他形式彻底地替换掉站会，这种新形式必须符合站会的原则，甚至具备更深层的意义和作用。
希望越来越多的项目管理者能够带领团队达到更高的阶段。这是我们在项目管理中不变的追求。
后记
从敏捷的理论、敏捷的实践、敏捷的价值观，到敏捷的创新方法，再到企业层面的敏捷性，构建了敏捷的知识体系。在今后的分享中，我们还会和大家一起探讨敏捷转型的话题。期待大家的参与！
希望武汉的技术社区越来越好！祝大家周末愉快！
本文作者万学凡，ThoughtWorks首席咨询师，武汉。作者保留本文一切权利，未经许可请勿转载。
