某技术平台产品团队，服务于公司各大产品线（300万装机量）。团队成员包括产品经理1人，开发7人，异地测试1人。

l 团队工作特点：

1. 发版节奏不确定：需要跟随公司各个产品的发版节奏；

2. 需求不确定性高：产品需求来源于各产品线，需求来源广，来源频次不固定，要求及时响应；

3. 质量风险影响高：产品主要提供公共技术服务，万一出现差错影响面太大。

l 团队敏捷转型之前面临的问题：

1. 被产品线的各种需求牵着鼻子走，产品规划缺失；

2. 费劲做了很多新功能，不是不符合用户预期就是没人用；

3. 开发与测试任务串行，开发全部完成后测试才开始工作；

4. 发版时版本质量心里没底，曾经酿成大事故，版本质量靠天吃饭；

5. 疲惫的团队对产品的未来感到迷茫，缺乏成就感。

l 团队敏捷转型之前的研发现状：

1. 团队走2周的迭代，有计划、每日站会、回顾会；

2. 团队认为自己在践行SCRUM, 已经在做“敏捷开发”。

二、 Feature Team改进后效果

l 团队改进历程

敏捷转型历时6个月后，团队完成用户故事、版本规划、SCRUM的导入和实践，团队的敏捷研发规则能够独立运转。

l 团队阶段改进成效

1. 发版周期由3个月缩短为1个月；

2. 产品质量提升10倍（装机崩溃量）；

3. 迭代计划完成率平均95%以上，团队形成稳定的交付能力。

三、 改进感受

上述的实战案例中，在笔者没有开始进行教练团队前，团队一直较严格的按照SCRUM框架，在走2周的迭代。但是，为什么还遇到好多严重的问题呢。一句话，团队踏入了“伪敏捷”的怪圈而不能自拔。什么是“伪敏捷“？“伪敏捷“是指团队因为对敏捷的核心价值观、原则理解的不到位，导致只是照本宣科的推行了敏捷实践的形式，表面上看起来好像“敏捷”起来了，但是没有什么改进效果，久而久之，团队就会陷入迷茫，最后就会得出“敏捷无用论”--“敏捷呀，我们也在搞，但是没什么用，不适合我们团队”。当然我们必须承认，敏捷不是万能的银弹，它只能在自己适用的场景下发挥它的作用，给团队带来价值。但是，很多得出“敏捷无用论”的团队其实是在践行敏捷开发的过程中出现了问题，不是敏捷开发这个“经“不好，是被歪嘴和尚念“歪”了。

SCRUM作为当下精益敏捷开发中最流行的框架，始于产品Backlog梳理，止于迭代交付，很好的解决了团队迭代过程敏捷化的问题。虽然产品Backlog中提倡使用用户故事，但是纵观整个SCRUM框架，还是将敏捷化的重点集中于迭代开发的过程。也许有人会认为，SCRUM因为定位是一个框架，所以其保持了精简程度，在这里我们不猜度，但是从落地化的角度来看，尤其是对一个刚开始自发进行敏捷转型的团队来说，可能会误认为践行了SCRUM，就实现了团队的敏捷转型，其实这是不够的。从产品实现周期的角度来看，我们不但要实现开发过程的敏捷化，也要实现产品需求的敏捷化，只有产品需求和迭代过程都实现了敏捷化，才能两条腿走路，才能实现团队较完整的敏捷转型。

那么怎样实现团队敏捷转型的两条腿走路呢？第一条腿是要实现产品需求的敏捷化。

GIGO原则（Garbage In Garbage Out）说的是如果输入的是垃圾，那么输出的必然也是垃圾。在产品需求敏捷化里面，我们可以借用两层含义。其一：对一个研发团队而言，如果输入的产品需求是没有价值的，那么团队再怎么努力的快速交付，交付出来的也是没有价值的，团队也是在做无用功。其二：团队开发过程要想实现真正的敏捷化，必然要求团队的输入--产品需求也实现敏捷化，否则，就会大大影响团队的价值产出。那么，不敏捷化的产品需求会有哪些体现呢？

1. 需求以单一功能点或者模块方式描述输入迭代，即使迭代通过了开发测试，用户也无法进行直接的验证反馈。

2. 需求条目颗粒度很大，团队在一个迭代内完成不了几个，导致团队的迭代交付率偏低。

3. 需求条目之间耦合紧，无法进行单一条目的独立交付。

4. 需求一旦在迭代前确定下来，迭代过程中的变更调整要经过较长的变更审批流程，导致迭代内无法完成变更后的需求条目。

5. 产品经理只是指令式的向团队传达讲解需求，产品、设计、开发、测试只是表面上对需求的理解达成了一致。

6. 团队只知道指令式的进行需求的开发实现，不了解需求对用户的真正价值，也不关心。

7. 迭代开始时，团队无法对待完成的产品需求进行有效计划，计划拍脑袋，完成靠运气。

8. 需求条目的完成与否不清晰，很多时候，产品、开发、测试都要扯皮，最后糊涂“完成”。

正是因为产品需求的不敏捷，导致了上述现象或者问题的发生，最后会导致团队的迭代过程即使能够很好的实践了SCRUM，也产生不了好的期望效果。那么怎样实现产品需求的敏捷化呢？第一步，也是基础的一步，团队应该使用“用户故事”这个敏捷实践。用户故事具有“INVEST”特点，INVEST是用户故事的特点缩写，即用户故事的独立性、可协商性、有价值、可估算、小的、可测试。一个团队，只有较好的实践了用户故事，才能实现产品需求的初步敏捷化。关于用户故事的使用，在这里不多赘述，另文与大家分享探讨。

团队敏捷转型的第二条腿是要实现迭代过程的敏捷化。

之前讲过，很多团队在实践SCRUM，但是在实践SCRUM的过程中，也出现了一些问题，比如：

1. 团队的迭代周期经常打破，本来说好两周，到了最后，开发说再给2天我就都开发完了，那好吧，迭代就再延2天吧，诸如此类延迟，经常发生。

2. 以一个迭代周期2周为例，往往是到了迭代的最后2、3天，开发才把完成的工作一股脑推给测试，结果呢，测试只能加班加点。

3. 迭代计划会时间长，有的会议要开一小天；没有迭代回顾会，或者草草结束迭代。

4. 迭代过程中经常有临时的工作插入，导致每次迭代计划都完不成，迭代计划做了好像也没什么用。

5. 迭代中，产品、开发、测试的信息经常不同步。

6. 需求条目最后带着BUG交付“完成”。

对于一个团队来说，其敏捷转型的过程一般要分为“守、破、离”几个阶段。“守”的阶段是指遵守规则的阶段。个人认为，其实往往是这个看似最简单的阶段实际上是团队敏捷转型最难的阶段。难在哪里？其一，万事开头难。团队从原有的工作习惯改变到新的工作习惯，需要很大的勇气、决心和执行力。其二，暴露问题多。团队开始践行敏捷开发，使用新的工作方法，会暴露出来很多问题，团队会产生疑问：“为什么用了敏捷还有这么多问题？”。其实不是使用敏捷产生了问题，而是敏捷像一把手术刀，它把团队进行了深层次的解构，所以问题暴露出来了，这个时候如果团队没有好的教练作指导，大家就会觉得是做敏捷做出了问题。其三，见效甚微。由于是敏捷转型的初始阶段，团队要花很大精力和时间与旧有的工作习惯和思维做斗争，在这个阶段，SCRUM的实践能运转起来就不错了，不可能有什么好的见效，一般也得3个月左右团队才能形成初步的敏捷工作习惯，所以在这个阶段，教练的心态不能着急，也不能对团队要求更高。但是，教练输入的指导内容必须遵从敏捷的价值观和原则，只有这样，才能潜移默化、身体力行的指导和影响团队。比如上述提到的几种问题，明显是团队对敏捷开发的时间盒、快速交付、会议活动的价值、适应性计划调整、开放交互、DOD标准认识的不到位所导致。

综上所述，对于采用SCRUM进行转型的Feature Team，如果想做好转型，必须要同步实践“用户故事”，否则就会变成一条腿走路，而一条腿，是完成不了团队的敏捷转型。

附注：本文基于文前实际案例，所以只分享了用户故事+SCRUM的敏捷转型应用，对于精益看板开发等其他精益敏捷方法，另文分享探讨。