移动互联网行业是个快速发展的行业，需求不断变化，产品更新快。基于移动互联网的以上特点，在开发产品的过程中，我们放弃了传统的瀑布流开发模型，引入了精益的理念和scrum这个敏捷开发框架，下面谈谈实施过程中的一些经验。

scrum简介：Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。
Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。

我们的Sprint backlog是大概4周的时间，其中包括2天的sprint计划会议,2.5周的开发，每日例会穿插在开发时间里，1周的测试改bug，1天的sprint评审会议和sprint回顾会议。

（1）sprint计划会议

在开sprint计划会议前，产品经理必须所要实现的产品需求（产品Backlog）以用户故事的形式确定下来，并画好原型图，UI应该要出设计稿（在sprint计划会议前出设计稿很重要，因为设计对估算时间影响非常大）。产品经理同时确定各个产品需求的优先级。

开sprint计划会议期间（一般是2天），开发团队的成员不应该做任何的开发工作，把全部精力都放在把产品需求变为一个个开发任务，并对开发任务估算时间。

估算时间有几点注意：

1. 对于需要使用的新技术，要估算学习和调研的时间。

2. 根据统计，每个程序员每天的有效工作时间是5个小时左右，其他时间都被沟通，喝水，休息，上洗手间等占据，所以如果某个任务估算超过5个小时，那就代表了这个任务完成需要超过一天的时间。

3. 对于开发任务，估算尽可能的细，一般来说，每个任务的估算不应该超过5个小时，如果超过5个小时，就应该再把这个任务细分。只有尽可能细的估算任务，总的时间是大概精确地，因为估算时间是一个正态分布，有的任务估算的时间偏大了，有的时间任务估算的时间偏小了，估算越细，总体下来估算还是准确了。

最后，根据产品经理的优先级和开发人员的估算时间，确定最终的开发任务和优先级，即完成Sprint backlog。

（2）日常开发

在每个Sprint backlog，后台和app的交互都是通过api，所以由后台先写好相关的api并编写假数据，先让app端可以顺利开展工作。

先编写api和假数据，有两个好处：

1. 能对整个开发计划有个总体的规范。

2. 相当于是TDD（测试驱动开发）。

遇到问题的时候，必须要及时找相关的人员沟通。但这样有个问题，如果开发人员正在开发，被打扰可能会被决定很不爽，为了保证沟通的效果，可以：

1. 如果真的不是非常紧急，可以等相关的人员休息的时候再沟通。

2. 解决一个问题，先梳理情绪，再梳理人际关系，最后才是问题本身。多微笑，别苦着脸，平时待人以善，说好话，存好事，做好事，沟通的时候只针对问题，不针对别人的不良情绪。

3. 可以试一下番茄工作法。但根据我们自身的实践经验，效果不理想。

在创业开发团队中，scrum master一般是由技术总监担任的。团队外部的沟通，必须统一通过scrum master。即如果市场部，运营部对开发团队有任何要求，必须要经scrum
master同意后由scrum master传递进开发团队内部。团队内部的沟通，由团队成员自己解决，如果有重大的决策，必须经scrum master同意。通过scrum master遮蔽外部对开发团队的影响。

在团队建设中，定期的团体活动是个很好的主意，我们一般是周四下午集体去打羽毛球。

通过团体活动，不但能加强团队的凝聚力，而且运动后，整个人沉闷的感觉都消失了，变得神清气爽，活力十足。

在一个Sprint backlog中，需求不能变更，UI确定后原则上只能做小修改。

（3）每日的例会

在每天的例会前，每个团队成员应该更新自己的任务列表，包括：

1. 昨天完成了哪些任务，每个任务使用了多少时间，没完成的任务估算还需要多少时间

2. 更新总的剩余开发时间

例会一般是产品经理和开发团队的成员都要参加，如果可以的话，让运营人员和市场人员也参加，这样可以使每个成员都公司的产品有个整体的了解。

每个人在例会上说下面3方面的事情：

1. 昨天做了哪些工作。

2. 今天准备做哪些工作。

3. 有什么工作需要其他同事配合。

注意，避免在会议上讨论问题，如果真的需要讨论，请在会议后和同事讨论，不要浪费整个团队的时间。

（4）测试和修bug

开发完成，就进入测试和修bug的阶段。如果人手不足，可以使用交叉测试的方式，即android开发人员测试iphone的app，iphone开发人员测试android的app，后台，运营，UI等人员看情况分配测试任务。

针对每个bug，应该有3部分：

1. 问题描述和重现步骤

2. 测试人员

3. 负责解决这个bug的人员（这个人员一般由技术总监指定）

（5）sprint评审会议

一般是全体人员都参加，在测试和修bug后。

iphone的演示有个收费的工具，可以把iphone的屏幕通过电脑放到投影仪，android上没有哪个好用的工具！当时我们的方法是android演示的时候，用iphone的摄像头对着android机，通过iphone的收费工具在投影仪上看。

（6）sprint回顾会议

每个成员都要参加，每个成员都要提两点：

1. 在这轮sprint中值得表扬的点

2. 在这轮sprint中做得不好的地方

这个过程走两轮，即每个成员都要说2次。

注意，当一个成员提出自己的意见时，其它成员不作任何的批评。

（7）及时反馈

在精益的理念中，很重要的两点是快速反馈和快速迭代。快速迭代是通过scrum这个敏捷开发框架实现了，但快速反馈呢？产品投入到市场后，怎么快速收集用户的反馈呢？

我们采用的方法：

1.建立相关的qq群，收集意见。

2. 在app中，有个意见反馈的功能，能把反馈的意见发送到服务器。

3. 后台中，有个系统的账号。每个用户一注册就和这个系统账号自动加为好友，可以随时通过聊天功能向这个系统账号提问题。一般我们的产品经理会经常登录这个系统账号和用户真正交流的。

app后端系列文章总目录

如果您觉得这系列的文章对你有所帮助，欢迎打赏。

支付宝账号：190678908@qq.com 收款人：曾健生

[文章作者]曾健生

[作者邮箱]h6k65@126.com

[作者QQ]190678908

[新浪微博] @newjueqi

[博客]http://blog.csdn.net/newjueqi

http://blog.sina.com.cn/h6k65