有道李勤飞：敏捷不是快速，更多的是灵活
有人说，实践敏捷的根本不在于敏捷本身，而在于理解敏捷背后拥抱变化的基因。确实，使用敏捷，那么你就应该知道为何敏捷。
当你从某个行业去领悟衍生出这种方式，毕竟那是成熟行业成功的经验映射。在实际的操作中，分配，转型，时间，技能等等都需要严格谨慎的执行。
就在前段时间，网易有道云笔记负责人蒋炜航在微博上分享了一篇名为《敏捷开发的实战经验》的文章，讲解了团队如何实践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回顾会议。
- 需求梳理会在Sprint计划会的前1-3天开，参加的人员是产品经理和开发人员，由产品经理称述需求，开发人员讨论设计与实现。
- Sprint计划会是Sprint开始第一天开，参加的人员有产品、开发和测试，由产品经理讲需求，开发人员把需求分解成任务。
- Scrum例会每周两次，周二和周四，主要沟通任务的完成情况，和下一个两天做什么。
- Sprint回顾会议在Sprint结束时做，主要总结这个Sprint的经验教训，并且达成一些团队共识，比如例会迟到如何惩罚等。
