转型敏捷 123

小团队转型敏捷要怎么做呢？研发团队各有各的特色，僵硬地照搬敏捷框架显然行不通，实际工作中，一个十人以下的团队，如何在敏捷教练的指导下走上转型敏捷的道路呢？本篇来和大家分享一些关键实践和要点。

1.角色定位：

明确团队内的角色分工，有利于工作任务的分配，在一个敏捷团队中，重要角色包括：

PO（product　owner）——产品所有者，即对产品能够主导规划的人，可以投资决策产品的走向，在实际团队中，部分产品经理担任此角色

DEV——顾名思义，开发团队，真正做开发的人员，不同的是这里的开发也会承接测试的工作，在结合一些好的测试工具使用的场景下，敏捷团队的开发既做编码也做测试，也称为开发测试一体化

Scrum master——敏捷教练，关注团队交付，及时识别过程中风险并为团队扫除障碍，为顺畅交付产品价值保驾护航，在实际团队中，多数项目经理承担此角色

2.愿景与目标

团队作为一个整体，应该共同维护产品的愿景与目标。PO 可以制定产品的愿景和目标，但是其余成员也应该充分理解愿景和目标，对产品的定位和演进有充分理解，而不是只作为“螺丝钉”完成其中一部分工作。敏捷团队的特点之一，则是打破部门墙，撬开竖井，让信息最大化透明。定好了愿景与目标后，可以用大白纸张贴在全体成员能看到的地方，不断地提醒大家，共同服务于一个目标。

3.高质量需求输入

敏捷开发的需求描述，采用了用户故事，是一种以交互性比较强的故事描述方法，讲清楚用户需要什么。用户故事的描述是三段式方式：<作为>角色,<我想要>....功能，<以便于>实现...价值。用户故事描述了对用户、系统或软件购买者有价值的功能。好的用户故事的书写非一蹴而就，需要客户能够站在使用者的视角，挖掘自己要通过系统功能实现商业价值的需求。好的用户故事具备以下特点，也就是常说的 INVEST 原则：

独立的（Independent）— 要尽量避免故事间的相互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致工作量估算变得更加困难。通常我们可以通过两种方法来减少依赖性：1.将相互依赖的故事合并成一个大的、独立的故事（具备一个较为完整的场景）；2.用一个不同的方式去分割故事。

可协商的（Negotiable）— 故事卡是功能的简短描述，故事卡的作用是提醒开发人员和客户进行关于需求的对话，通过反复沟通确认故事细节。

对用户或客户有价值的（Valuable）— 用户故事应该很清晰地体现对用户或客户的价值，软件开发中做没有价值的事情就是一种浪费。

可估算的（Estimable）—故事大小应该是可以量化的，团队自己寻找到量化的参照，对每个故事进行大小的估算，有利于优先级排序和迭代计划。

小的（Small）— 过大的用户故事承载了太多内容，不利于沟通和描述，而且过大的故事在排期交付方面也会有较大负担，容易使开发团队士气低落。

可测试的（Testable）— 故事必须是可测试的。故事的 AC（验收标准）也体现了这一点，故事分析过程中要可以梳理测试案例覆盖的场景，对需求的澄清越清晰，越利于开发团队一次做对事。

4.迭代计划

在得到有优先级排序的故事清单后，合理的挑选故事纳入迭代也是门学问，迭代的容量要合理，避免出现这个迭代故事爆棚，下个迭代又无事可做，团队在磨合 3-5 个迭代后，能够完成的容量应该是基本稳定的。

5.演示验收

敏捷的小步快跑优势之一是能够及时让 PO 验收可工作的产品，PO 的高频次验收能够减少不必要的返工浪费，对产品的需求理解有偏差可以及时纠正，甚至有时候 PO 也没有想清楚到底产品的演进规划，需要产品当前的状态给反馈和输入的参考。

6.定期回顾

每个迭代结束后，都应该有一次集体的回顾，回顾本迭代完成的内容，每位成员的成长与问题，长期的回顾和改进能够改善团队的氛围和文化，营造持续改进的良好氛围。

7.工作可视化

工具加持能够让团队的敏捷落地更高效有质量，这里必须要强调看板的使用，将工作可视化呈现，价值流的流动一目了然，风险问题及时暴露，团队对整体的工作进度心中有数，避免了口口相传带来的沟通壁垒。系统性的使用看板，可以学习《看板方法》,作者是看板方法的创始人 David，书中详尽介绍了看板的理论和应用。为敏捷团队提供高效支持。

以上就是我结合实际工作，对敏捷 scrum 研发框架的实操性总结，仅供急于转型或者试水的团队参考了解，如果要培养更专业的敏捷团队，还是建议大家能够接受系统性的培训指导，掌握理论技巧，才能对实践应用有更深刻独到的理解。