Scrum&Kanban在移动开发团队的实践 （一）

现在大多数团队都在谈敏捷开发，似乎觉得敏捷是软件开发的银弹。只需要实践下一些敏捷开发的模式就能如何如何，其实我觉得不论是敏捷开发还是传统的瀑布流开发都是有他们的市场的，取决于团队人员构成，取决你的产品的属性，所在市场的竞争环境。最终希望达到的目的都是一个：以最快的方式、最高的质量，实现所需的需求。

我最近所在的两个团队都是移动研发团队，一个是在相对大型的外企内部面向企业级软件，一个是创业型团队面向消费级应用。第一个团队我们是从传统的瀑布流开发模式向Scrum转变而来的，第二个团队我主导整个研发团队，结合了Scrum以及Kanban的，采用的是混合型的开发模式。

Scrum实践

Scrum的基本概念我就不赘述了，希望快速了解的人可以一步到此。

我谈下我们是如何操作的：

1. team角色的分配：产品，研发，Program Manager。产品提供业务的需求描述，MockUI。研发包括Scrum Master, Developer, QA，负责软件的研发测试。Program Manager负责整个项目的进度控制以及对外team的沟通协调等等。

2. 使用的工具：VersionOne用于整个Scrum开发的项目管理，后期我们换成了Jira Agile，主要是因为我们也用Jira来做bug Track，分散在不同系统管理也是挺复杂的。代码管理Github，文档管理Confluence，测试用例TestLink。

3. 流程：

我们以一个月作为一个release周期，每个月的15号到下个月15号，发布一般在下个月15号的那个周五。一个月分为3个dev sprint, 1个release sprint。

Release Planning阶段

Release kickoff meeting: 周期开始阶段，产品team负责解释未来一个release要做的功能。通常产品team是维护Epic，并且将Epic分解成backlog（具体需求），并排好backlog优先级。

Engineer backlog discuss meeting: 拿到backlog，研发团队就需要对backlog进行分析，理解需求，并能分解成Task (任务)，并对每个task的工作量进行估计。这时会有两种方式进行工作量的估计，传统的人天，或者用Poker Points。

人天的方式比较容易操作，大家熟悉也比较好理解，但这种方式是没有办法去衡量一个团队的生产力变化情况。对于一个固定人数的团队，在固定时间内可以产出的人天数是固定的。

Poker Point的做法是选定一个task作为基准，比如1分，然后评估其他任务的时候始终以这个基准作为参考给出相应的分数。这个时候其实需要注意避免一言堂，所以很多时候是通过出扑克牌的方式来达成整个团队的一致的，可以通过多轮的出牌，一定要整个团队都对这个分数表示同意为止。使用Point的评估方法相对难操作，但好处也是显而易见的，通过每个release point的数量可以非常明晰的了解团队生产力的变化。

这个阶段通常需要在1~2天完成，一个好的planning对于整个release的成功与否至关重要！好的开始以为着成功了一半！

Plan结束后我们会在VersionOne/Jira Agile系统中填入所有数据：

Epic	Backlog	Task	Effort	Developer
EP1	feature1	taskA	1	MemberA
		taskB	3	MemberB
	feature2	taskC	8	MemberA
EP	feature3	taskD	5	MemberB
	feature4	taskE	3	MemberA

Development Sprint

Daily Scrum Meeting: 很多团队都是使用这个，每天的scrum站立会议，通常是每个成员介绍自己昨天的工作，今天的计划以及碰到了什么问题。这个会议一定要强调效率，15分钟内解决，所以超过10人的团队建议拆分分别开这个会议。Scrum Master在这个会议需要起到一个计时的工作，保证控制会议的节奏，如果碰到复杂问题一定要会后再讨论，不要陷入无休止的讨论中。

每人都要及时记录自己做的任务的情况，做了多少，还剩多少。这样可以产生一个非常有用的图表，Burndown Chart。这个图表可以很容易看到项目进展的情况。

在整个Dev Sprint里面，测试团队是和开发团队紧密合作的，测试应该是在整个开发周期最开始就介入，一起讨论需求，一起评估，同时写测试用例，不断进行新功能的测试以及迭代测试。理想状态下3个星期的开发周期内，开发和测试一直是同步的，3周内开发完成，新功能测试也基本能完成。

Release Sprint

这个阶段是为了稳定产品质量，为发布做准备。我们采用标准的Git flow来管理代码库。

在Release sprint开始的时候，我们会从develop分支checkout出Release分支。在Release分支只接受bug fix的commit，在develop分支依旧可以提交新功能，不过这时提交的新功能是要到下个发布周期才会发布的。

发布的标准：

1. 没有高优先级的问题

2. 没有regression的问题，就是以前版本是好的，新版本导致

发布时，将release分支的代码同时merge到develop和master分支，并在master分支上打上标签。

每个release结束后还需要retrospective meeting, 大家可以总结，并进行不断的改进。

Scrum是个相对完善的项目开发模式，各种工具也非常完善。我觉得需要注意几点：

1. 固定的发布周期：这样可以培养良好的开发迭代的周期性，同时也容易可以评估每个周期的效率。

2. 产品团队和研发团队的时间是不一样的，一般产品团队工作要提前1~2个星期，保证研发团队不会因为需求的不明确而影响效率。

3. 避免需求的变更，无论何种开发模式，需求的变更总是不可避免，所以最好是将周期缩短，可以让产品团队可以忍受延迟些时间来实现这些变更的需求。

4. 要预留一定的buffer，毕竟程序员也是人，也会有不能出活的时候，也需要学习分享知识，所以不要把时间完全填满，留给大家时间调剂。