提到敏捷，很多人会直接想到如下的框架，太简单了，335吗，3个角色，3个工件，5个会议，还有人加了5个价值（个人认为应该是敏捷团队需要具备的5种性格）。
单单就事论事，这3355还是有很大的遗漏，至少漏了一个2和一个3。
2是发布计划和迭代计划两个计划；3是迭代前、迭代中和迭代后三个阶段，既然提到3个角色之间的分工协同，不也应该提一下工序之间的配合协同吗？
这样看敏捷太简单了，通过迭代小步快跑，中间把这些3355的做好，万事大吉，项目一改往日各种进度和质量不理想，获得巨大成功。
事实果真如此吗？谁做谁知道，敏捷也没那么容易。
开始觉得很简单，做出来的效果确合适差强人意。开发觉得产品没有把需求提前梳理清楚，到了版本要发布还在变；产品觉得开发动作太慢，无法响应快速变化，于是研发只好牺牲质量赶进度；测试更惨，根据需求写好的用例，忽然就失效了，产品的开发质量因为赶进度被牺牲，测试就成了产品上市前的最后一道安全网，压力可想而知。
是不是似曾相识？可能大部分的敏捷团队目前还是这样的状态。正是面临这样的痛点，才有机会深入思考现象背后的原因，直到看到这张图才恍然大悟。
看看图上出现的做多的单词是什么？Value，Value，还是Value。要想敏捷顺畅起来，必须价值第一。
仅仅模仿敏捷过程和活动，只是徒有其表，本质上还是奉行瀑布思维那一套，或者可以叫“敏捷瀑布流”。虽然把版本开发划分成了多个迭代，其实在整个项目/版本范围内还是按照瀑布方式操作的，迭代时间到了就算迭代结束，只有项目结束/版本发布的里程碑才真正交付有完整用户价值的产品。这是典型的瀑布思维，并没有真正按照敏捷要求，每个迭代交付用户价值。
价值是敏捷的原始推动力，及早的交付价值是敏捷的精神内核。“敏捷瀑布流”不仅没有使项目更成功，很可能使团队造成我们正在应对变化的假象，而失去了对目标/价值的专注。每个迭代都要交付可上线的产品（至少绝大部分时间），不要妥协，如果做不到，一定是管理出了问题。
价值的诠释应该是多维度立体化的，比如：如何评价产品应该交付何种价值？开发应该交付何种价值？测试应该交付何种价值？运维应该包括何种价值？这些价值应该在何时被定义？应该在何时被交付？应该在何时被检查？应该由谁来检查？
不同项目的不同阶段，其价值的具体定义可能会非常不同，管理的作用就是要抓住其最根本的相对静态的东西，形成诠释和评估价值的基本原则，来指导价值第一这一理念的实质落地。
敏捷价值总结正在梳理中，会单独发出来，敬请期待。
181
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
