浅谈敏捷开发及Scrum(二)实施与难点

上一篇浅谈敏捷开发及Scrum(一)概念与理解写了一些关于敏捷开发和Scrum的相关概念及个人理解,这里来说说实施与遇到的一些困难。

Scrum.itlao5.com

如何实施

敏捷开发的实施,我们是用的Scrum迭代开发,关于Scrum的一些介绍上一篇已经说了,这里说一下实施流程及其关键点。

一个Scrum迭代一般建议2-3周,具体视团队情况而定,一般团队中有一个PO,一个SM,以及5-7个团队人员(开发及测试,而且这里面最好有1-2个以上的多面手)。

迭代的管理,我们用的是leangoo,bug管理是用的禅道,下面是迭代流程:

Scrum迭代

1、Scrum开发中,所有的需求都需要进入到PO的Project Backlog;
2、在迭代启动前,由PO将里面的代办需求进行优先级排序,并整理成能执行的有价值的Story,移入Spring Backlog中(注意:这些Story是可执行的,PO一般应清楚需求的验收点,并对该Story有一个预估的时间点);
3、在迭代周期内的第一天,这一天主要是进行项目启动会(需求评审、时间评估、实现思路及细节讨论、故事拆分、时间安排等),PO会对Spring Backlog中的Story进行描述,团队成员进行细节询问后,会进行一轮开发点评估(按团队成员进行一个增删改查业务为一个点来评估Story需要几个点进行开发或测试);第一轮评估后,会由团队成员阐述评估时间点的原因,之后再进行1~2轮时间点评估。团队成员之间评估相近,且PO认为合理,取最终评估点最大值(注意:开发评开发时间,测试评测试时间);如果最终评估点过大(我们一般取3以下的点,超过3则认为过大),需要进行Stroy拆分,拆分后继续评估;
4、所有Story评估完毕后,由团队成员自主领取任务,每个成员能完成的任务量参考之前迭代的任务量(一般是几个迭代后,才能比较准确的得到一个迭代团队和个人能顺利完成的任务点数);
5、评估完毕后,当天,所有成员需要进行故事拆分,拆分为每天或者每半天能完成的任务,并给每个任务定一个时间点,一般是开发先定完时间点后,在开发的时间点基础上,测试再加上相对应的测试时间;
6、一般第二天或者第三天,会进行测试用例评审,这个主要是PO和测试参与,有需要时可让对应Story的开发人员参与;
7、每日站会,在迭代中,每天成员开始工作应该是先根据leangoo梳理每日的工作,然后在每日站会上叙述昨天完成的内容,今天计划做的以及面临的困难,是否需要支持(这个会议时间不宜过长,原则上是仅叙述,不实际解决问题,最重要的一点是PO闭嘴,因为PO一旦说话,肯定会聊到详细内容,然后整个团队的时间就浪费了。所以问题在会后解决,当然,更加提倡的时开发时候碰到问题立即解决,而不是等待每日站会)
8、项目验收会,在迭代的最后一天上午,我们一般会对项目进行验收,由测试展示给PO,由PO最终决定每一个Story是否达标,迭代是否顺利完成,这是PO的验收会,也是整个团队的成果展示会。
9、在最后一天下午,一般会进行迭代总结会,会评选出迭代之星,迭代中的优缺点,以及缺点的解决方案,并将解决方案分配到负责人,下个迭代努力去改进。
10、一般,在迭代中途,我们会有一些代码ReView,可以在成员的每次提交代码前进行update时看看别人的代码,并建议每周花一两个小时进行团队的代码ReView。

ps: 以上是一个迭代的主要流程(写得仓促,但愿没遗漏)。

需要注意的是:1、在迭代中,SM需要保证团队不收到外界干扰,所有的外界骚扰都先经过SM或PO,不能直接进入团队。2、PO需要在迭代前花费较多的时间来梳理清楚用户需求,才能让迭代更顺畅,不让等进入迭代遇到问题再去梳理用户需求。3、PO工作任务很大,责任也是最重的,必须保证一个迭代的任务是不轻易变化的,不得已非要变化时,需要进行Story替换。4、对于有线上维护任务的团队,视情况预留线上支持的任务点。5、如果有团队成员需要休假,最好在迭代启动会提出,并预留时间。6、团队的稳定性非常重要,团队稳定了,才能准确预估一个迭代能完成的点数,才能保证一个迭代顺利完成。7、迭代启动会对需求的讨论越详细越好,这样在开发中才能少进行错误的或者重复的工作。8、开发中有问题及时沟通,主张面对面沟通,不建议问题留到开会时解决,主张主动、积极。9、迭代总结会是很重要的,能让一个团队清除自己的长处和短处,而更重要的是持续迭代中对于短处的改进,这些将会让团队战斗力越来越强,迭代越来越轻松。11、迭代是为了更轻松更合理更及时的完成用户需求,所以强制给成员分配工作、频繁的需求变更等都不应该存在,这些会让迭代变得更沉重,让成员觉得迭代开发毫无生趣。

大项目实施

然而,一个大项目往往需要很多个迭代才能完成,那么,在大项目研发中,如何进行迭代呢?
这就需要将一个大的开发周期(几个月)拆分为一个个小的开发周期(2-3周),然后进行一轮轮的迭代;可以考虑在2-3个常规开发迭代后插入一个强化迭代(进行代码调整、问题修复、性能优化等),确保前几个迭代完成的任务能保质保量;在完成所有开发迭代后,再进行2-3个强化迭代(不断测试及修复问题、优化性能、优化用户体验等);当然,最后还最好有一个发布迭代(用于整体回归测试、发布准备等)。
于是这个大项目的开发可能是这样的:
常规迭代–>常规迭代–>常规迭代–>强化迭代–>常规迭代–>常规迭代–>常规迭代–>强化迭代……….–>强化迭代–>强化迭代–>强化迭代–>发布迭代

Scrum.itlao.com

遇到的困难

在迭代中,遇到一些困难时难免的,重要的是想着怎么去解决它,去保证迭代的正常进行,这样,迭代才会越来越顺利,任务进度才能有保障,成员才会越来越轻松。

1. 会议混乱,偏离主题

会议偏离主题,这个是我们团队迭代中存在了很长时间的问题,往往讨论一个问题,或者每日站会进行汇报时,随着一个成员的介入,主题越来越分散,最后甚至变成框架不支持、之前代码太混乱一类的抱怨。

  • 针对这一问题,我们这样改进:
    1.团队应该清楚任何讨论都是为了解决问题;2. SM应该把控好每一个问题讨论的范围,适当中止并引导回到主题;3. 在每日站会,PO绝对不允许发表任何看法,任何成员不能打断别人的叙述,有其他意见,站会后讨论;
2. 线上问题过多,干扰正常迭代

因为我们项目已经上线,而且主要是预约和缴费,所以线上有问题大多需要及时解决(毕竟对于用户及公司来说,涉及到钱的问题就是大问题),于是,刚开始的几个迭代我们做得很累,同时迭代也往往是以失败结束。

  • 针对这一问题,我们这样改进:
    1.根据上个迭代的经验,预留足够的任务点来作为线上支持;2. 所有线上问题先经过PO或SM过滤,保证开发人员不能被打断;3. 一些常规问题尽量让运维解决;4. 解决真正紧急且耗时不多的问题,其他问题留到下个迭代;
3. 外部原因导致迭代任务无法正常完成

因为我们有很多第三方的依赖,包括接口、资源申请等,往往在迭代中,我们完成任务,但第三方未能及时提供,导致不能联调甚至我们自己开发的一些步骤无法进行下去。

  • 针对这一问题,我们这样改进:
    1.在迭代开发前由PO确定好第三方能提供接口或资仅源的时间,降低任务的不确定性;2. 使用工具进行接口模拟,降低开发对第三方接口的依赖;3. 在迭代故事中,区分第三方的任务和我们自己的任务,将开发与联调分离;4. 当缺少第三方支持和资源时,主动及时提出,并找对方协商;
4. 测试无法融入团队的问题

在开发完成任务后,测试

5. 线上问题的管理
6.

简书:ThinkinLiu 博客: IT老五

关于敏捷开发,还在学习、实践及总结中,后续也会在这里记录新的问题和感想;如果有什么意见,欢迎共同探讨。

相关内容:
浅谈敏捷开发及Scrum(一)概念与理解
浅谈敏捷开发及Scrum(二)实施与难点
浅谈敏捷开发及Scrum(三)工具leangoo
浅谈敏捷开发及Scrum(四)工具zentao



发表评论

必填项已用*标注