有道李勤飞:敏捷不是快速,更多的是灵活

有人说,实践敏捷的根本不在于敏捷本身,而在于理解敏捷背后拥抱变化的基因。确实,使用敏捷,那么你就应该知道为何敏捷。

当你从某个行业去领悟衍生出这种方式,毕竟那是成熟行业成功的经验映射。在实际的操作中,分配,转型,时间,技能等等都需要严格谨慎的执行。

就在前段时间,网易有道云笔记负责人蒋炜航在微博上分享了一篇名为《敏捷开发的实战经验》的文章,讲解了团队如何实践scrum的一些经验得到了网友很高的评价。网易有道云笔记从事敏捷开发积累了丰富的经验,因此,51CTO的记者基于敏捷开发为主题,采访了网易有道研发经理李勤飞。

有道李勤飞:敏捷不是快速,更多的是灵活

李勤飞目前是网易有道研发经理,有道云笔记技术负责人。曾参与过有道词典的开发,具有多年的团队管理经验。是有道云笔记引入和实践敏捷开发方式的主要负责人。

以下是李勤飞给网友们分享的敏捷开发管理经验:

一、敏捷团队

1)在敏捷开发中团队的拆分

在敏捷开发中,组织团队方式是按照项目组织,而不是行政划分。拆分团队只有一个理由,就是能提高团队效率。根据经验,小团队的效率更高。当团队人数大于9个时,计划会和站会,成员的参与感会下降,效率会降低,沟通成本也会加大,这时候需要拆分团队。

2)在敏捷开发中团队的管理

敏捷开发只适用于小规模的团队的这种说法是错误的,敏捷开发跟团队的数量没有直接关系,只要大于3人的团队都可以实行敏捷开发。

但是,小团队更容易敏捷。团队人数的增加必然会提升沟通协作的成本,可以通过拆分团队的方式来提升效率。把一个大团队拆分成几个小团队,团队之间的协作也走敏捷开发的流程,就是我们常说的Scrum of Scrums。

3)在敏捷开发中团队的转型

想要做到敏捷开发,每个团队都要经历一个转型期,那么在转型期还需要每个团队根据自身的不同,找出合理有效的解决方法。

对于有道云笔记的团队是逐步推行敏捷开发的,没有遭遇明显的转型期,但推行过程中确实也遇到一些问题。比如产品经理开始并不认同根据固定时间的sprint来划分版本,最后用已有团队整体产出提升的经验说服了他。还有比如产品已经上线,sprint进行中间会有一些线上的问题插进来,我们通过线上值日,以及根据经验数据来预留时间等方式来解决这个问题。

二、敏捷方式

1)编码方式

很多人为了编写易变更的代码,在采用敏捷时,抛弃许多习惯用法,这是一个误解。敏捷开发推崇涌现式设计,通过不断的重构来实现更好的架构。指的设计而不是编码,对于编码方式,不需要发生变化,除了需要遵守公司和团队的编码规范外,用自己熟悉的方式即可。

2)极限编程(XP)

极限编程有很多争议,我们的方式是选择性接受,比如把两位工程师组成一对,相互review代码,并且要求编码测试代码等。但是暂时不会采用两人一起编程的方式。

3)指标衡量

每个sprint的总结非常重要,会记录每个任务(task)的预估时间和完成时间。并且定义了完成度(任务的完成情况),希望sprint的完成度在80%以上。如果完成度低,就需要总结原因并改进,团队成员的绩效也会受影响。当然,除了项目进度以外,有道公司还有另一套评价体系,跟业务无关,而是由专业的技术委员会对程序员个人能力的评估。这两套评估结合在一起,就可以很好的衡量程序员的工作。总的来说就是,按进度完成项目的同事,个人能力也需要不断提升。

4)scrum会议

Sprint会议是实践scrum中最重要的事件,这更是团队做改进的最佳时机。有道云笔记团队的Sprint以一个月为期,四种会议:需求梳理会,Sprint计划会,Scrum例会,Sprint回顾会议。

  1. 需求梳理会在Sprint计划会的前1-3天开,参加的人员是产品经理和开发人员,由产品经理称述需求,开发人员讨论设计与实现。
  2. Sprint计划会是Sprint开始第一天开,参加的人员有产品、开发和测试,由产品经理讲需求,开发人员把需求分解成任务。
  3. Scrum例会每周两次,周二和周四,主要沟通任务的完成情况,和下一个两天做什么。
  4. Sprint回顾会议在Sprint结束时做,主要总结这个Sprint的经验教训,并且达成一些团队共识,比如例会迟到如何惩罚等。

相关推荐