如何迅速打造敏捷团队

Denniss

       这个话题有点应试之嫌，但作为团队的敏捷教练，常常会有成员问我到底怎么才算敏捷，是不是使用了tfs(或 jira)，上了devops，开了四会就是敏捷了。

       一年前我确实会这么想，有总比没有强。但参加了公司级AMM评估，看过更敏捷的团队后，我发现敏捷没这么简单，这是价值观、技术和管理的融合。

    这里分享的是我们团队在本次AMM评估中做的改进，走过的弯路，自己对评估模型的理解，其中可能会有一些应试的成分在里面，但现在看来只要坚持下去，是能看到效果的。

1.敏捷价值观导入

       非常重要的步骤。七个核心价值观，除此之外团队还有可能形成具有自己特色的价值观，比如在开发测试融合的团队，开发和测试必须合作。这步的目标就是“达成一致”。

     价值观会润物细无声的成为团队的精神力量，想仅凭几次培训、讲解不一能引起共鸣。而且研发团队成员大多是做具体开发测试任务的人，长期的工作思维让我们更偏好一些立即就能用的东西，比如学一门语言，比如掌握一个算法。而很少会停下来，思考这些“空”的东西。这步的目标是“引起思考”。

    为了快速让团队感受、理解、思考价值观，我们团队做了这几件事：

    1）集中会议宣传

在AMM评估前，将项目组成员集中半天，由项目负责人向项目组成员做汇报，介绍敏捷方面的进展，项目运作的改进等，会上自由提问、讨论。这样既让项目组成员了解到敏捷知识，更感受到通畅的沟通、平等的交流。

     2）持续、密集、小团队内宣传

         团队在导入阶段，晨会开始前请一个成员说说敏捷价值观。我们的教育背景让我们接受这样一种观点：理解思考是建立在记忆的基础上。

     3）晨会上增删任务

需求变化是常态，我们要拥抱变化，晨会上PO可以随时插入新需求，确定责任人，同时调整优先级。

    4）重视回顾会

       团队运作一开始，会有成员对运作方式提出疑问，比如对个人技能要求提高了，一专多能让工作变复杂了，专业知识不进反退了，等等。此时如果是故障复盘，则抛开问责，刨根究底的找出故障发生的客观和主观因素。如果是吐槽，则引导团队成员抛开个人情绪，认识到问题的真正的症结。

    5）集中办公

    我们是一个特性团队，团队负责完整版本的端到端交付。我们有一个优势是可以集中办公，在机房协调一块能容纳20多人的地方，整合各类调试和测试资源，测试团队和开发团队坐在一起，对开发人员来说，测试可以充当部分“用户”，对测试来说，开发是他们的产品特性的资料库，无障碍快速的沟通反馈。

    除此之外，在AMM评估时我们也看到有些团队将价值观打印出来贴在墙上，大家抬眼既得，这也是可以的。

2.坚持Scrum的几个会议

    敏捷最直接的感受就是每天都有会。这是SCRUM框架内推荐的，每种会议都起着各自的作用。计划会团队内澄清需求、认领任务，晨会上各方了解进展，展示会及时反馈和知识传递，回顾会促进持续改进。

    在推行之初团队成员的感受是会议很多，每天不是在开会就是在开会的路上，特别是SM，只有下班后才能写上几行代码。时间久了，往往会遇到抵触情绪，或者会议变得鸡肋。这时要关注“价值”，坚持下去。

    我们团队的做法是：

    1）整合会议

    我们发现展示会基本上半小时就可以完成，没必要单独召开打乱研发人员节奏，所以将展示会和回顾会合并。又比如我们发现需求实例化和MFQ对团队很有价值，就特地多召开了需求实例化和测试用例评审会。为提高会议效率，不是全部成员都到场，以需求条目为单位，相关人员碰头开会。

    2）坚持就会看到成果

     AMM模型里说到团队里需求能相互澄清，自主认领，及时沟通与反馈，其实召开这几个会议就可以做到。在评估过程中，访谈到团队成员时，遇到团队成员反映四会是意义大于形式，还是形式大于意义。我建议团队是请先坚持下去，坚持下去会看到效果，而教练和SM要客观的分析团队成员的意见，依据团队情况适时的变通改进。

3.工具

配置管理工具是敏捷的硬通货，是团队效率最大的保障。打造自动化、可视化、快速反馈的配置管理工具链是有价值的。

     而另一方面这项工作在开展之初需要较多资源。tfs、wiki、jira、jenkins, gerrit，制品库，自动化测试云环境等等。每一样都需要人员熟练使用。对于人员充足或交付压力不大的项目来说也许可以花人力在这方面，但对于就只有几人的小团队，玩转这一套就不容易了。

    我们是个二十几人的团队，每月要出少则十几，多则几十个版本。如果没有这套流水线很难想象能支撑的住这么快的交付速率，而将全人力要投入到工具链的建设中也是不现实的。

    1）利用好外资源

  公司有DevOps维护团队，提供云上的基础设施，建议团队加入公司MOA的DevOps小组，随时了解动态，人力资源丰富的项目可以为DevOps创新做贡献，小团队可以做到跟上脚步。

   2）主动要资源

    我们这里是分中心成立devops推进小组，统一规划，技能共享。比如开发统一脚本，鼓励跨项目、部门分享，以此支撑各个团队快速部署配置管理的需求。

4.设计

    简单设计这是技术实践中最有价值的，也是最能提效的因素。编程规范，cleancode，抽象，tdd, ddd，ut，ft。到底什么才能称的上是高质量的代码？这考验教练的软件开发功底，是长期积累沉淀的结果，速成不易，但可以建立一套运作机制，让大家关注设计能力的提高。

    1）必要的培训

     外部技术大会，公司内部技术大会是交流学习的机会，团队可以关注这些会议。最好有一个技术雷达，最怕的是你不知道你不知道。可以申请部门间学习，公司级教练的指导。

   2）实践

        可以有侧重点的代码走查，并将检查规则加入代码静态检查工具链中。

        我们团队做了一段时间的针对cleancode的代码走查，每周挑一个需求的一段代码，全体成员一起走查，不是为了找业务逻辑上的漏洞，而是针对抽象，重复，命名规范做重构。这样坚持一段时间做全体成员对cleancode就有了大致的概念。

5.总结

    站在团队的角度讲能通过AMM l3认证实属不易，期间有创新，有弯路，也在认证过程中开拓了眼界，发现了不足。

    站在技术教练的角度讲，敏捷思想，配置管理工具，简单设计，等等，还有很多需要学习，在前进的道路上，止于至善。

3 U" R$ s5 k0 K# ?- ]! j& s

指穷为薪

学习了！@#￥%……&*