在讲需求的事情之前，先说一个事 今天早上过早，我和娃去吃面。后面来了一个女的，声音嘛就很严肃像班主任吵架似的。 老板说吃点什么啊？ 她就开始跟老板说需求了，“两碗粉，一碗要那种长的宽的，一碗要那个粗的圆的，粗的圆的那碗要多煮一会，煮软一点，多煮个半分钟。然后长的宽的那碗，要一勺半的辣，圆的粗的那碗要半勺辣……” 大概叨叨叨了有一两分钟，粉都已经好了。 老板往桌上一放， “我们这里的调料是自己加的，在调料台上。辣椒，葱花香菜都有，自己加。” 我当时在旁边听的时候就感觉，我是绝对记不住需求的，卖粉的大姐记性也不好，不像能记住的样子。 有这么一个段子：一个人去吃牛肉面，跟老板说“我要一碗牛肉面，细面，肉多点，面少点，面要煮得软一些，少辣椒，别放醋，汤多一点”，老板说好的，回头给后厨喊“一个牛肉面！” 职场的话，场景应该是这样的。 产品经理说了一大堆要求之后。 程序员回答：你写个详细的需求文档过来，我们照着做。不用跟我在这说了。 结果就是，没有个体和互动，全是流程和工具。其实这样也不符合程序员的利益，我读一万多字也是成本呐。干点有意义的事情不好么。 老魏说，也不是这类人故意使坏，而是收到的培训/工作环境告诉他： 产品/设计/开发/测试是严格瀑布的，每个阶段要产出“高质量”的本阶段交付物。而且倾向的协作方式也不是交互，而是你产出我验证和使用。 兰斯说，绝对不要也不行，讨论有些是没想好的，落笔更确定一些 老邓就是理性的科学派，不用说那么多，就是你是否认可：可工作的软件重于面面俱到的文档 这个价值观。 我们都知道软件开发，很多时候，需求就是很复杂，就是需要讲半天，并不是一句话能说得清楚，如果写文档，也不一定写得清楚，又搞得文档一大堆。 那么这种复杂需求的情况下，到底该如何处理呢？ 我来使用解构的方法，看看都有哪些模式，我们团队可以选择适合自己的模式来处理。 解构需求沟通： 所以，当需求本身就非常复杂的时候， 模式一：我要当面仔仔细细地给你说清楚，你得记好，我可是跟你说过的呀！ 模式二：别说了，详细的文档写过来。我们按文档的做。文档错了就是你的锅，没按文档是我的锅。 模式三：分层细化 模式四：使用工具：建模、ER 图、架构图、用户故事地图等 模式五：边做边改 模式六：来来来，你这么会说，你来做！ 模式七：这个需求太复杂了，不做 模式八：我们先做个简单的，告诉我能不能用 模式九：来来来，你坐在我旁边，我们结对一起做。 这么多种模式，总有一种适合你的团队。 但我们往往不是只采用一种模式，有的时候经历是这样的： 需求来了， 首先是 7 ，能不能不做呢？回答说不得不做。好吧，你讲讲 然后 1，等等我已经被说晕了，要不写个文档吧？ 然后 2，文档太复杂了……这么多 然后 3，先说说最核心是干啥 然后 4，我们用工具试试分析一下，画个图。 然后 5，好大概懂了，我们边做变改哈 然后 6，没耐心了，你这 tm 成天改，你这么会改你来做 然后 7，这么复杂，要不算了吧 然后 8，不能算，要不做个丐版的？万一可以呢？ 然后 9，最后几天了！没时间了！要死人啦！你别跑，我们一起搞！要死一起死 虽然是玩笑和段子，但也是经常发生的。 老方说：我们总想以一种完备的状态完成工作。敏捷告诉我们要实时反馈与调整。但是落实的时候，又因为一些主观、客观因素导致协作失败。最终就开始自我保护模式。 其实的确，敏捷所说的，个体和交互大于流程和工具。原则上是非常正确的，落地的时候需要打补丁，也就是通过很多实践来纠偏。 其实很多敏捷教练就应该做这些打补丁的活，但是很多敏捷教练不认为敏捷需要打补丁，或者说很多敏捷教练没有能力打补丁，导致了很多敏捷团队交付的问题。 风诰说，所以敏捷教练 = 补锅匠么？ 我说，敏捷教练就是那个把窟窿抠大的那个人，然后你就不得不去认真补这个窟窿了。

现在每天写点东西，有空的话就录视频发出来。 敏捷教练、团队教练、个人陪跑教练【老袁讲敏捷】

我开始记录一些个人陪跑教练过程中的对话和思考。 敏捷教练、团队教练、个人陪跑教练——【老袁讲敏捷】

从中世纪英国郡县长官说到 accountability 敏捷教练、团队教练、个人陪跑教练【老袁讲敏捷】

行尸走肉里面的瑞克三问，瑞克考验是否能够加入团队的三个问题。 1. 你杀过丧尸么？ 2. 你sa 过人么？ 3. 为什么？ 可以用来思考一下：我是谁？

个人陪跑教练的半年回顾记录