移动互联网行业是个快速发展的行业,需求不断变化,产品更新快。基于移动互联网的以上特点,在开发产品的过程中,我们放弃了传统的瀑布流开发模型,引入了精益的理念和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. 后台中,有个系统的账号。每个用户一注册就和这个系统账号自动加为好友,可以随时通过聊天功能向这个系统账号提问题。一般我们的产品经理会经常登录这个系统账号和用户真正交流的。