敏捷开发|烦恼的诞生以及如何解决

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

敏捷开发

Scrum敏捷开发,带来的不仅仅是敏捷,还有理不清的烦恼。

最近公司开展的Scrum敏捷开发,几个Sprint下来,碰到了很多烦恼。

比如说:碰到有改交互原型图,改视觉设计稿,改代码的情况,因为Sprint Planning Meeting(周期计划会议),就没有考虑到交互原型图和视觉设计稿需要改几次,bug需要修几次,所以碰到这种情况,一般需要加班或者放到下个sprint再做计划。

又比如:本来1天可以完成的工作,但是需要计划成2-3天去安排,因为在某一个sprint之内,在项目的某一环节上,确实是没有什么事情可以安排的。总不能在计划上写:“1天上班,2天自由活动。”另外,在Daily Scrum Meeting(每日站立会议)上,要求每个团队成员,都需要口头说一说自己昨天的工作进度,今天的工作计划。这个时候,有些同事,只能编造一些无关紧要的事情,或者把1天可以完成的事情,分成2-3天来汇报,因为他这个环节,这几天本来就没什么事做嘛。

再比如:临时有加急事情,需要下单的时候,同事之间就用Sprint Backlog(周期工作列表)来拒绝工作。“这个sprint计划里面没有这个任务啊。”所以,本来需要加急的任务就这样被拒绝了。这时候,只好放到下个sprint再弄,或者自己加班做。其实,本来只需要在1天的工作时间里,挤挤时间,这个急单,就可以完成了。

下面先介绍一下Scrum敏捷开发的流程,然后再针对上面的这些烦恼,提出我个人的改进方案。

什么是Sprint?

Sprint是短距离赛跑的意思,这里面指的是一次迭代,而一次迭代的周期是1个月时间(即4个星期),也就是我们要把一次迭代的开发内容以最快的速度完成它,这个过程我们称它为Sprint。

如何进行Scrum开发?

  1. 我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;
  2. Scrum Team根据Product Backlog列表,做工作量的预估和安排;
  3. 有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;
  4. Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);
  5. 在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);
  6. 做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;
  7. 当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);
  8. 最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中。

针对本文开篇提到的烦恼,我在这里总结了3个针对性的方案。

1. 在计划会议的时候,需要给交互设计师预留改原型的时间,给Ui设计师预留改视觉稿的时间,给开发工程师预留修bug的时间。比如:Ui设计师,平均改稿次数,为3次左右。一次就能定稿的情况,几乎不存在。

根据【Ui中国】发布的《UIweek6》杂志上的一份《上海Ui设计师工作现状调查》显示:一般从产品初期到产品上线所需要修改次数的比例为:改稿4-6次的情况占41%,改稿1-3次的情况占40%,改稿7-9次的情况占7%,改稿10次的情况占12%。为了避免后期要求Ui设计师改设计稿的时候,Ui设计师因为怕加班而不改,或随便修改应付了事的情况,我建议需要在计划会议的时候,把修改的时间,预留到计划里面。这样,Ui设计师就可以大大方方的改。

2. 当临时有急事,需要布置加急任务的时候,一般就拖到下个Sprint去了。为了避免这种情况,我建议在计划sprint会议的时候,预留出2/10的时间,作为临时任务的预留时间。这样,有任务需要加急的话,就可以大大方方的给出时间嘛。

3. 关于Sprint Star的评选,一般情况,优先被选中的是,谁加班多,谁在这个sprint我接触比较多,谁被选中的机会就大。这个标准,我建议改成:谁可以在完成这个Sprint任务之外,多做一些Sprint计划之外的事情,就尽量选谁。

以上是我最近在敏捷开发的实施过程中,碰到的一些烦恼和推荐的方案。具体实施过程中,需要综合这4种(瀑布式开发,迭代式开发,螺旋开发,敏捷开发)开发方式的优缺点,来运用到具体的项目当中。这样,敏捷开发就可以做到取长补短的效果。

 

本文由人人都是产品经理专栏作家 @张云钱(微信号:944352559) 原创发布于人人都是产品经理 。未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 4

登录后参与评论
  1. 感觉蛮虚的,虽然看起来是刚刚成长的样子。但是还是表示鼓励。希望你的努力越来越有成绩!

    回复
    1. 回复

      :mrgreen: 在工作中,学习;在工作中,总结;在工作中,分享;在工作中,进步。

  2. :mrgreen: 以上是我的工作中总结的一些心得,分享一下。

    回复
  3. 菜鸟练了2天就来谈经验了,too young too simple

    回复
加载中