2016年终总结会议，我正在回顾一年来敏捷推广工作，刚分享完一个辅导案例，在座的参会人员像炸了锅似的，纷纷举手提问：
- “什么？一个月的工作只需要一个星期就完成了？而且还是可发布的？！”
- “是啊，人还是那些人”
- “是不是天天加班啊？”
“这是个特例还是普遍现象？如何做到的呢？”
“…….”
- “OK，待我给你们娓娓道来~”
背景&问题
XX团队是某集团公司研发中心下属的一个业务开发团队，于2015年组建，产品研发和项目交付交替进行，团队成员新老参半，平均工作年限7年。由于团队相对较新，大家对产品、业务和需求理解不是很深，加之项目交付工作存在很大的不确定性，导致团队经常加班赶工，项目质量问题频频爆发，产品研发受到很大牵连，一直在延期，进展缓慢。
刚刚受邀辅导这个团队的时候，研发中心负责人召集了各个业务线负责人，想让我充分了解他们的业务、发展和存在的问题，正如你想的那样，这个会议很快演变为吐槽大会，大家都想从我这里了解一些提升团队效率的方法和解决方案，足以体现出大家对现状的不满以及改变现状的迫切心情。
观察
“问题其实就是你期望的东西和你的体验之间的差别。如果某人能解决这个问题，而他本人却并不会遇到这个问题，那首先就需要让他感受这个问题” 。[1]
谁的问题？问题是什么？问题是目前暴露出来的这些现象？还是有更深层次的本质？要回答这些问题，就需要我们教练和顾问加入到团队中间，与他们一起工作，观察他们的行为。经过一番讨论，我们决定拿XX团队作为试点。
进入团队的第一天，正巧赶上每月一次的工作总结会，团队负责人打开月初制定的当月计划，按顺序询问目前的进展情况，只有问到自己或者与自己相关的任务时，团队成员才会抬起头来解释任务目前的状态以及遇到的问题，特别是一些需要相互协作的任务，成员之间的沟通通常需要团队负责人介入并协调。会议时间并不长，有不少任务延期或者“差不多”做完了，团队负责人在会议结束前，宣布了下个月要完成的任务，有几个人询问了一下任务的内容以及外部依赖的情况。会议结束了，大家回到了各自的座位上，也许是感受到了上层对整体进度的压力，也许是习惯了这样的计划和总结形式，气氛有点压抑，大家并没有立即进入工作状态，也没有过多的交流。
- “这个需求是XX总提的，10月1日必须上线。”
- “XX项目现场刚才给我打电话，XX功能不好用了。”
- ”那天我发了一个版本给XX，他们着急，测试没时间...”
- “这个功能我做完了，但需要XX给我提供接口，我不知道什么时候能给我。”
…...
在接下来的几天里，通过参与团队的各项活动 - 项目问题分析、需求沟通、不同角色间沟通、测试等等 - 观察大家日常的工作状态和行为方式和方法，让我对这个团队有了更深的了解。
定义
“不要把问题的解决方法误认为是问题的定义，特别是在你使用自己的解决方法时”。[2]
毕竟我与团队相处的时间有限，当我罗列出我定义的问题后，与团队及相关管理者一起进行了讨论和确认，还好，大部分大家都意识到了。
问题和需求来源众多，遗漏情况时有发生
问题和需求优先级不明确，临时性任务总是打断正常工作
工作状态没有及时反馈
多角色之间沟通依赖团队负责人，团队负责人总是很忙
很多版本未经测试就发布，项目质量问题严重，缺陷众多
…...
透明化
“问题的根源往往都是在我们自己身上”。[3]
第一步：工作透明化
跟大家确认清楚问题后，我们决定从研发团队入手，接下来做的第一件事，就是在距离团队最近的墙面上贴了3张大白纸，分别写上“TO DO、DOING、DONE”。在大家疑惑又充满期待的眼神的注视下，我拿出来2种便利贴，让大家写下目前正在做的需求以及每个人在其中承担的工作，很快，我们便有了第一张可视化的板子。
看到这块板子，大家都感觉良好，工作及状态一目了然，参与感和好奇心高涨，于是，我们约定之后召开一个会议，把原来一个月的工作，按照这种形式进行拆分，让它们能够被所有人清楚的看到。
第二步：需求透明化
问题来了，我们缺少一个需求列表！以前需求都写的比较简单，可能是一句话，也可能是一个邮件，当需求分配下去的时候，也只有团队负责人和被分配者了解这个需求，有时候这两个人还有理解上的偏差呢！
这样下去可不行，我们必须明确一个需求负责人，以他为入口，对需求进行统一的整理和确认，避免遗漏，减少临时插入。团队负责人很痛快地接下了需求负责人的工作，我们一起对需求进行了描述和整理，于是有了下面的简化需求列表：
每一个需求都经过了整合或者拆分，只保留了那些对客户/用户有价值的内容，并以用户故事的形式进行了描述，按优先级的顺序形成了列表。
这里还有一个小插曲，需求负责人在描述第一个用户故事的验收条件的时候，几乎囊括了他想到的技术解决方案的每一个分支，当我提醒他，他的解决方案不一定是最适合的，如此详细有可能限制业务实现者的思路时，他在备注中进行了说明，用以提醒自己要从业务实现的角度来描述，而非技术角度。
第三步：目标、计划透明化
第三天一早，经过简单的介绍和演示之后，团队的第一个计划会议开始了，习惯于等待分配任务的团队成员依旧热情不高。当听到不再分配任务，将按需求优先级顺序自领任务时，所有人都抬起了头，从他们的眼神里，看到的更多的是惊讶和困惑。先不管那么多了，好在大家的注意力目前还集中在讲解中的需求列表上。
当需求讲解接近尾声的时候，我向团队抛出了问题：“这些需求完成之后，能为客户/用户提供一项或多项完整的能力或价值么？列表中的哪些需求对这些能力或价值没有贡献？”，经过几轮讨论，终于总结出两项价值，找到了两个贡献很小的需求，我在价值前面加了四个字：迭代目标，在那两个需求的备注中标识上：暂缓。
很快，新的问题出现在用户故事的拆分的过程中，开发人员还是不能习惯从业务流程的角度来拆分用户故事，那就先从操作角度来拆，CRUD、基本信息、详细信息、信息列表…渐渐地向业务拆分过渡。
最热闹的莫过于估算环节了，我们给了大家足够的沟通时间，希望充分发挥大家解决问题的能力。那些资历尚浅的团队成员还是不太敢于发表自己的意见，他们担心业务和技术上的差距会拖长讨论时间，从教练的角度，我们更多的是引导他们发言，没有解决问题的思路？那可以把你希望找到答案的问题抛出来，也会引发其他人的思考，很多时候还真的对解决方案形成了一种补充。
所有要做的需求都拆分并估算完成了。原本一个月的工作，按照现有人员的规模，变成了一周多一点的工作量。这就非常尴尬了，明明这些工作以前一个月也不一定完成得了啊？是不是估算的太乐观了？要不然再调整一下？“既然是大家讨论得出的结果，让我们先试一试吧。” 团队还是决定按照这次计划会议的结果来展开工作。
现在，我们的可视化的板子上已经贴满了需求和拆分出来的用户故事，所有内容都呈现在每个人的面前！
TIPS. 工作量是怎么减少的？
当需求或解决方案只存在几个人的脑袋里的时候，会受到每个人思维模式和边界的限制，要不夸大要不缩小，特别是在外部压力较大的时候。将需求和解决方案都透明出来，一方面每个人都能清晰的掌握需求和解决方案是什么，消除沟通上的浪费；另一方面，解决方案是大家沟通得出的结果，每个人都可以执行，执行状态全部可见，消除开发上的浪费。因此，这个工作量不是“减少”了，而是体现了它本来的价值。
自组织团队
“不管一开始看起来什么样，它永远是人的问题。” [4]
计划会议结束前，每个团队成员都按优先级顺序领取任务，不管是按操作角度拆分，还是按业务拆分，每个人手里都有了一个对迭代目标产生影响的任务。这里需要强调的是，当前团队中只包含两种角色，开发和测试。虽然团队中以往是按开发过程（架构、设计、开发）有分工侧重的，但在我们的引导下，大家还是勇敢的选择去拓展自己的能力。
刚运行了两天，团队成员小W在每日站会上领取完当天的任务后，就开始了抱怨：”我擅长完成后端业务逻辑的工作，可按照优先级，我不得不做一些前端页面的开发，这严重影响了我的效率！”，这个问题在我们以往辅导过程中特别常见，一般都出现在开始阶段，由于大家都是在适应这种完整业务价值交付的形式，个人效率常常受到影响。那怎么解决呢？答案就是自组织团队！
自组织团队不但是不分配任务，还包括相互协作，充分发挥团队整体效率。如果每个人都选择自己擅长的工作，那很有可能每一个需求的实现都是不完整的，迭代结束的时候无法交付任何价值。
每日站会结束后，我们立即引导团队自己寻找可行的解决方案。很快，一个擅长前端页面开发的小伙伴小L与小W相互协作，帮助对方进入自己擅长的领域！
“一旦你干掉了头号问题，二号问题就升级了。”[5]
过了几天，测试人员小G找我抱怨道：“我们根本就没办法投入测试，哪些移到Done一栏的任务，太多低级缺陷了，他们自己根本就没自测！”，好吧，我承认这是我预先埋下的陷阱。说服开发人员编写测试代码，对自己完成工作进行自测，是一件很不容易的事情，最好的方法就是让他们认识到这个问题的严重性，自己提出解决方案。
于是，我决定利用下班前的半个小时，听听团队对这件事情如何看待。当小G把问题描述完之后，开发人员小C也深有同感：“跟我有接口关系的任务，每次我调试的时候都很难调通，不是这有问题就是那有问题，这个问题不解决，我们没办法交付啊。”，很感谢小C，他帮助这个问题升级了！由于开发人员自测不足，不但导致测试人员无法正常开展测试工作，连开发的内部协作也变得困难万分。“你曾经说过有一个完成的标准？”小K好像记起来点什么，“对，完成标准，Definition of Done，我们一起来看看我们的DoD应该是什么样的，好吗？”，小伙伴们七嘴八舌的开始贡献，很快，一个有团队自己定义并承诺的DoD出炉了：代码检查通过，Unit Test通过，集成测试通过...于是我们把它贴到了Done的上面
迭代结束了，原来需要一个月才能完成的需求，一个星期就搞定了，而且缺陷减少了90%以上，自组织团队的协作方式发挥出了它的威力！
TIPS. 引导并激发他人的自我改变要比试图去改变他人，有效得多
回顾与改进
第一个迭代中遇到的问题远比上面描述的多得多，为了让后面的工作更有成效，在新的迭代的计划会议召开之前，我们围在白板前，对第一个迭代进行了一次三十分钟的回顾，每个人都要回答下面两个问题：
上一个迭代我们那里做得好？
上一个迭代我们那里可以做得更好？
经过票选，“可以做的更好”的第一名被我们贴到了白板的旁边这。这样，下次回顾的时候，我们会讨论一下改进的效果。
现在
距离进入团队已经将近两个多月了，尽管还有一些问题不断的出现，但也不断得到解决，团队已经进入一个良性循环，对比引入改变之前，交付周期缩短了75%，权限数量减少了90%，客户满意度大幅提升，团队正向着比好更好的方向前行！
写在后面的话
这是一个非常普通的传统软件开发团队的真实故事，它绝不是特例，如果你也想作出改变，请联系我们，我们期待跟您一起经历这个旅程！
在这个团队的影响下，其他团队也开始改变，不但有研发团队，还有交付团队：
原创作者
孟繁强 Fred Meng
CSP/CSM/CSPO/PMP/资深过程改善顾问，互联网+产品创新实战派，敏捷/精益创业布道者，10 多年软件开发、项目管理、过程管理、产品研发管理与敏捷实践经验，专注于精益创业与产品创新、精益/敏捷组织转型、研发效率提升，长期致力于精益/敏捷思想、产品创新、项目管理、引导技术和教练技术等的实践与推广。精益/敏捷思想倡导者和践行者、敏捷社区志愿者、沈阳敏捷社区发起人、沈阳敏捷之旅组织者、东软敏捷之旅创办者。
[1][2][3].《你的灯还亮着吗?:发现问题的真正所在》高斯&温伯格
[4][5].《咨询的奥秘:寻求和提出建议的智慧》温伯格（本资讯于2017-02-17首次发布）
