老袁讲敏捷

November 9, 2024

敏捷的短板，用 shape up 给补上：再讲一次 Shape up 方法

November 9, 2024

需求下滑时，组织如何自处？【老袁讲敏捷】

October 31, 2024

需求就是很复杂啊，怎么搞呢？

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