如何迅速打造敏捷团队

  这个话题有点应试之嫌,但作为团队的敏捷教练,常常会有成员问我到底怎么才算敏捷,是不是使用了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认证实属不易,期间有创新,有弯路,也在认证过程中开拓了眼界,发现了不足。

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

作者:玲玲总总 链接:https://www.jianshu.com/p/5d5eef3b39b9 來源:简书 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
阅读更多
个人分类: DevOps相关
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭