你肯定遇到过这样的场景： 老板交代了你一个任务，这个任务听起来简单，但是推敲起来又很复杂，老板又无法在一时之间把任务细则描述清楚，稍微一聊又感觉老板想做的事其实很多，又不是一两天就能做完的。。。
通常情况下，我们都希望老板，或者客户，或者甲方能把想做的事一下子说清楚，能把功能范围定的特别清晰。这样我们才能根据手头上的人力资源进行任务拆分，耗时估算，任务追踪，进度汇报，风险管理。但是现实哪会总这么如意如意，随你心意。更多的情况下，我们都会遇到如下三种情况：
-甲方对于他想要的东西，只是一个大概其的幻想，根本不清楚他真正想要的；
-甲方知道他想要的，但是他传达给我们（乙方）之后，信息在传递过程中产生了衰减，双方的理解产生了不一致；
-甲方知道自己想要的，双方传递完美对接，但是过两天，甲方的想法变了，方的想法变了，的想法变了，想法变了，法变了，变了，了。。。
所以，遇到类似这种情况，我首先想到的就是用Scrum框架。来看看我真正遇到的一个任务吧。
任务描述
任务描述：我们要在全公司范围内宣传敏捷，目的是让办公室内尽可能多的员工了解敏捷基础知识和公司敏捷转型的状态。、
任务分析：乍一看任务难度好像不大，貌似也没有多少事做，无非是发表写文章，举办些training培训，让大家多读多看多参加就好。不过稍稍再一琢磨，这里面其实有如下几个open questions需要考虑。
需要发什么文章，做什么活动谁来定？
哪些是可以碰的，哪些是我们不能碰的谁来定？
先做什么，后做什么谁来定？
需要多少人来组成核心团队？
谁来组织团队的各种会议，保证任务进展？
会议频率如何定既不过分打扰团队，又能保证沟通效果？
如何保证团队做的工作符合领导期望？
如何激励团队保持工作热情？
如何保证我们的工作方法可以持续迭代提升？
用什么工具来管理任务？
... ...
你可能会问，至于要考虑这么多事吗，我跟你说，真至于的。而且你会发现，其实无论任务怎么变，要考虑的问题也都差不多就是这些。
Scrum框架精髓
这里不去赘述Scrum的3355框架。我总结了这个框架里的几点精髓之处。你可以不完全懂Scrum，但是这些精髓之处你总会用到。
3个角色可以解决Do the right thing和Do the thing right的问题
Backlog的DEEP特性能教我们更好的管理需求优先级，粒度，状态
Sprint时间盒可以保证团队以一个稳定的工作节奏输出价值（也许能让团队紧张，但也能让团队卓越）
5个仪式能告诉我什么时间该干什么事
接下来我们看一下，这些精髓之处是否能帮助我们解决实际问题。
任务分析与Scrum框架一一对应
运行效果
这里分几点说明一下我用Scrum框架做这个任务的实际效果。
甲方满意度。我们定了两周时长的Sprint，没两周的周三我们会给甲方演示发出去的文章，举办的活动和反馈，并且梳理下一个sprint要做的事。甲方对这种模式很满意，因为可以很快看到进展并且还能适当调整未来需求。灵活性极高。
开会频率与时长。我们没有完全按照5大仪式来开会，我们定每周一下午的30分钟时间大家同步一下各自的进展和遇到的问题，每两周的周三演示成果，梳理和接受新需求。没一个月的周一在原来30分钟的基础上再加30分钟做回顾，用来提升工作方法。
工具使用。我们选择Trello作为主要得需求管理工具，trello的种种优点就不多说了。反正用起来就感觉一个字-棒。
总结
有人说，简单的问题用瀑布，复杂的问题用敏捷。我个人觉得，像Scrum这种轻量级又极高效的敏捷实践框架，无所谓你的问题是简单还是复杂，都可以用起来。
况且，在当今大环境下，还真没有简单问题。你说呢？
————————————————
版权声明：本文为CSDN博主「zbl_learn」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u012452561/article/details/105764087