敏捷产品开发过程模型不应该只是照搬硬套

　　你必须把精力集中在那些你必须要做的事情上，不要只盯着模型。
　　统计界有句老话：
　　所有模型都是错误的，但有些是有用的。
　　一直以来，这句话都引起了我的共鸣。虽然概念模型从来都是不完美的，但我发现它是解释重要概念的一个特别有力的工具。但人们过于随便地接受概念模型，或者在模型中进行过多的规划，并将其解释为一个约定俗成的过程是有风险存在的。这种风险偶尔会发生在分析连续的产品识别和交付过程中。
　　我很早就使用了概念模型来表示这两个并行的活动：
　　这个概念模型实际上有许多名称。事实上，我认为这正好表明了该模型的构造能够代表事实情况，以至于很多人用不同的术语来引用这个模型。我见过这个模型被称为＂正确产品/产品正确模型＂，＂预假设模型＂等等。现在很多人引用这个模型为＂双轨敏捷开发＂或通称＂双轨产品开发＂。
　　Jeff Patton最近发表了一篇很好的文章，涵盖了＂双轨＂短语的起源（文章链接见文末）。在他的文章中，您可以看到Jeff是如何努力在概念模型中捕捉更多产品挖掘和实施过程的。我们能看出这个简单的概念模型是如何演变成复杂的流程图的。
　　应用敏捷思维和产品思维在同一过程中
　　这些年来，很多人鼓励我扩充简单概念模型，以突出此类问题：
　　基本产品规划和/或用户研究工作，这些工作通常要在更多的战术发现工作之前完成。
　　描述在交付过程中要完成的工作活动
　　Scrum与看板交付过程的差异（文末有相关资料）
　　在生产和发现学习中出现的反馈回路
　　我拒绝了这些建议，不是因为其中哪一个都是错误的，而是因为人们总是希望能轻易从一个简单的概念模型转到一个更详细的具体产品开发中，如文章开始所述，这样容易出现差错。更重要的是，我比较喜欢这个简单的模型，因为它不是面向过程的。有许多不同的识别过程和技术，正如会有许多不同的交付过程和技术。
　　对我来说更高阶的问题是：
　　产品识别和交付活动是平行进行的，它们并不是＂阶段＂。
　　在产品识别中，团队正面临着巨大的风险——价值、可用性、可行性和可存活性。
　　在识别中，产品团队正在协作解决的问题——产品管理、产品设计和工程。
　　产品团队要对业务结果进行度量，而不仅仅是输送功能。
　　这就是一个产品团队对产品识别和交付的责任（显然，产品经理和设计师将大部分时间花在探索活动上，而工程师则把大部分时间花在交付活动上）。
　　我一直对产品人强调，没有孤立的产品开发过程，也没有孤立的产品识别/交付过程。照搬硬套，只能是依葫芦画瓢。许多不同的产品识别过程，都是针对不同的情况。此外，重要的是要认识到这并不只是个过程。它更重要的是投入必要的文化理念，并在关键技术上训练你的团队。
　　在最近的（必读）股东信件中（《亚马逊CEO Jeff Bezo：如何让团队保持活力？》），Jeff Bezos谈到了一些同样的问题：＂良好的过程为你服务，这样您就可以为客户服务。＂。但如果你不注意，这个过程就会成为一个东西。这在大型组织中经常发生。过程成为了结果的代替品。你不看结果，只是确保你在正确地执行这个过程。
　　如果你要在前面解决风险、真正地与工程和设计结合，并提出好的解决方案；如果你要确保正在解决潜在的业务和客户问题，而不仅仅是在输送功能，那么你就得把精力集中在那些你必须要做的事情上，不要只盯着模型。
　　拓展阅读
　　双轨产品开发的始末
　　http://jpattonassociates.com/dual-track-development/
　　Scrum简介
　　把组织细分成小組、跨功能、自我组织团队。
　　把工作细分成细小、实在的交付成果，交排人员负责需求清单以及跟据重要性排优先级别，由团队估算每个项目相对工量。
　　把整个开发时间分成固定时长的短迭代（通常于一至四星期），在每个迭代后演示新增可发布功能。
　　优化发布以及跟客户一起更新优先级别，基于每个迭代后发布的观察。
　　优化过程，在每个迭代之后进行回顾
　　看板开发方式简介
　　看板开发方式是近年引起很多讨论和注目的一种敏捷开发实施。
　　工作流程形象化
　　把工作细分成任务，写在卡纸上，贴在墙上
　　把栏命名好，來显示任务在工作流程中的狀況
　　限制＂在制品＂（work in progress，简称 WIP） – 明确设定限制在每个状态下同一时间能有多少工作任务。只有当前的某项工作被交付，或是有了来自于下游的拉动，新的工作才能开始。
　　度量生产周期（即完成一个任务的平均时间），优化开发过程，缩短开发周期和使它更易于预测。
　　翻译：盯裆猫