我在一些稍微大一些的开发组织经常看到这样的敏捷过程定义，很多时候他们把这个过程称之为敏捷生命周期模型，看起来是下图这样：
在这样的模型下，需求团队需要明确的定义需求，确定需求的范围，交付详细需求文档。开发团队根据需求做设计、拆任务，按照Sprint迭代的方式安排开发计划。开发阶段完成，符合提测标准，集成测试团队集中做测试，之后由业务部门/用户验收，最后验收通过上线。我相信很多人看了这个模型都会感同身受。
在观察团队进行Scrum的时候，你会发现他们也会有每日的站立会议，有Scrum看板，团队每天会更新自己的进展，也会有计划会议、评审会议和回顾会议，形式上看起来都做到了。当我问到，我们现在Scrum实施效果如何，大部分人的反馈是团队氛围比原来好了，有了更多的讨论，但也仅此而已。而当我问到，我们为什么考虑做Scrum时，得到的反馈是：
1.我们交付周期太长、管理层认为开发团队太慢
2.需求变化比较大，很多需求交付了之后，用户反应交付的功能不是他们想要的，返工率比较高。
所以我们期望通过Scrum能够让我们交付的更快一些，更好的响应需求的变化，交付的功能质量好一些。
这个组织实施Scrum的初衷和大多数的组织实施Scrum的初衷大同小异，目标没错，Scrum就是帮助我们解决这些问题的，我们Scrum的各种形式也都执行了，那么为什么却没有效果呢？
这里的核心问题在于，Scrum不只是开发团队的事情。如果仅仅是开发团队的敏捷，我们仍无法做到价值驱动，无法及早的交付，无法缩短反馈的周期，也就达不到缩短开发周期、达不到响应变化的目的。我们需要的是从用户、需求、开发、测试、验收端到端的Scrum。
当进一步了解这些开发组织的时候，你会发现他们比较类似的一些特点，需求团队通常来自业务部门，除了负责项目需求，他们还有很多业务部门的工作要做，他们关注的需求很多时候也仅限于和他工作相关的部分。而开发团队和测试团队往往在不同的部门，甚至有的组织测试团队根本不在研发中心管理下，而是由业务部门分管。在这样的组织结构下面，由于部门的壁垒，团队往往首先考虑的是我们的责任在哪里，出了问题是我们负责还是推给其它部门，其次才是项目的交付。正是这样的壁垒，需求部门要和开发部门划清界线，开发部门要和测试部门划清界线。正是这样的壁垒，需求团队、开发团队和测试团队是一种契约关系，而不是协作的关系。 正是这样的壁垒，我们的开发周期才无法缩短，变成上图那样的四段式模型。所以，只有弱化这样的壁垒或者打破这样的壁垒才有可能带来真正的变化。
为了带来真正的变化，我个人通常有两个建议（这个不是标准答案，我们每个企业都有根据自己的特点进行分析判断，找到合适的实践），当然实施这两个建议的基础都是要自上而下和自下而上相结合来推动敏捷实施。 第一个建议是比较激进一点的建议，围绕产品（平台）组织相对固定的、扁平化团队，通过业务领域定义团队目标和侧重点，团队的优先级取决于业务目标，通过业务（用户）驱动开发团队，团队内包括产品、需求、开发、测试等多种职能，团队可以做到端到端交付。这样的组织下，不再需要职能部门。第二个建议是比较折衷一点的做法：保持原来的职能化部门不变化，但是将Scrum团队横向切分，建立一个强矩阵，Scrum团队围绕围绕产品（平台）来组织，这样相对固定，同样是通过业务领域定义团队目标和侧重点，同样是包括产品、需求、开发、测试等多种职能。如下图所示：
当打破了职能壁垒之后，团队工作由业务价值（业务优先级）直接驱动，每个Sprint团队真正交付价值，通过小步快跑、不断的试错，来确保团队交付正确的功能，客户、用户或者市场真正需要的产品。
本文作者：
廖靖斌 Eric Liao， CSP，CSM，知名敏捷教练、顾问、培训师
