敏捷转型12大难题,谁是你头疼的“深坑”?

首页发布时间:2018-03-28 点击: 41次

如今,在敏捷的大潮下,不少企业的开发部门都已经跃跃欲试,或已经身在其中。其实,当企业做出类似敏捷转型一样,涉及方方面面的较为重大的决策时,无非是希望在产出速度、效率、质量三个方面有所提升,进而实现ROI的最大化。即老话说的“多快好省”。但是,敏捷转型之路大家都走得一帆风顺么?此篇文章即列出了12个神坑,看看敏捷开发转型有哪些避之不及的“陷阱”和解决方式。

难题1:谁适合当Scrum Master

Scrum Master的作用主要是:组织站会,站会的时候要发现问题,又要像水一样透明;要当恶人,能扛住老板的压力。很多时候项目延期或失败在于遇到了一些障碍,这些障碍可能是工作量估算不准,工作中遇到一些问题,或者员工效率不高。

所以Scrum Master要具备较好的自我管理能力,有良好的沟通技能,不是好好先生。在此基础之上,看一看产品经理、QA、程序员谁更符合这个要求?Scrum Master,他不一定是技术最牛逼的,但他一定要能和大家形成很好的沟通,激发团队的能量。

敏捷开发最核心的在于形成自组织团队,团队中的成员能够自己决定往前走,能够自我发现问题,进行自我修复。Scrum Master可以说是一个超级服务员,既要服务于团队中的每个人,又要和团队外的人进行沟通,他要和产品经理一起布置好工作看板。 

难题2:交叉式团队中,研发和美术同时接几个小组的工作,团队不完整,不容易找到合适的Scrum Master,如果把人员集中,又会有大量的时间浪费。

敏捷开发可以有效管理每个人,及每个交叉项目的时间。产品团队在逻辑意义上是完整的,可以把不同小组的站会时间交叉开。比如美工在A组有2天工作量的活,在ta的活干完前要参加A组的会议。

难题3UI设计工作在哪个阶段开始?开发经常要等设计稿。

sprintUI工作要以不影响开发工作为前提。UI设计往往是个持续性工作,整体风格设计等结构性工作不应该放在sprint中,应先做准备出方案,在sprint中做细节功能的实现。

比如现在有sprint1sprint2,有经验的设计师,会在sprint1中完成设计任务后,开始为sprint2的工作做准备。这样设计师不会有大段空闲时间,又能保证sprint2中开发工作不用等待。

难题4:敏捷开发中,测试放在哪个阶段做?

把测试前移,和产品工作一起启动。在product backlog阶段就要确定好测试要点,产品经理在计划会上或会后给出。产品经理、开发人员、QA都要清楚测哪些点,保持理解一致,避免做无用功。

难题5:计划会在实施中,花在产品设计上的时间较多,有时会超过一天。

在敏捷开发中,不追求完美,做出可交付的版本更为重要。大家可以先跑起来再说,在快速迭代中一步步接近完美。另外,最好把产品经理和scrum master进行角色分离。产品经理更像是建筑设计师,他要提前做好准备工作,想清楚目标、理顺方案,在计划会上要经得住大家的提问质疑。

难题6:新员工中有刚毕业的学生,员工水平参差不齐,如何设定工作量?

工作量不容易明确时,可以用“计划扑克”的方法进行估算。“计划扑克”(Planning Poker)是一种标有数字的扑克牌。它的目的是为了在一个尽可能短的时间内,让团队成员更多地了解需要做的工作,同时得到一个可接受的估算结果。

产品负责人为大家挑选一个Story,并简单解释其功能,每个参与者按自己的理解来估计完成时间,选一张合适数字的牌,同时亮牌。参与者各自解释选择这个数字的原因,数字最大和最小的人必须发言。之后根据大家的发言,再重新估计时间。这个办法可以激发成员个人的优势,找到较为合理的工作量。

难题7:每日站会是否要更新任务状态和燃尽图?

站会的结果就是任务更新和燃尽图更新。在看板上一般有这几列:backlogto dodoingdonedelay,按照传统的做法,每天在站会后根据任务状态移动便签纸到不同列,更新燃尽图以实时把握产品进度并做出正确决策。

难题8:公司人员总是不齐,站会不容易开起来。

人员不齐可以开远程站会,要保证团队的有效沟通,站会开总比不开好。 

难题9:评审会中发现问题,甚至发现功能达不到发布要求怎么办?

本冲刺已经结束,可以把问题列入到下个冲刺的backlog中。功能达不到发布要求说明冲刺失败。

难题10:老板对sprint做出干扰怎么办?

可以让老板参与其中,让他说ok,和老板约定好尽量不要改变冲刺,有变化可以放在冲刺结束后去做;如果老板布置的事情很急,只能解散掉当前冲刺,重新安排工作。

Scrum Master要有say no的魄力,宁可砍掉功能也不要养成delay的习惯。一旦规则建立起来,所有人的工作都会变得更顺畅。

难题11:市场反馈多,扛不住压力,有时不得不改变冲刺,打击了员工士气。

要保证sprint力度可控,如果不得不做出调整,可以砍掉一些功能,缩短发版周期。或者一个2周的冲刺,发A+B版,让用户看到功能实现。

往往客户提出的一些临时需求是不稳定的,加班、推迟发版都会影响士气,要学会say no,不紧急的可以和客户约定好交付时间,放在下一个冲刺做,这样既保证了士气,又起到了过滤用户需求的作用。

可以考虑计划会、评审会邀请客户参加,这样工程师可以更加清楚客户需求,客户在冲刺中也不会轻易再改变需求。

难题12:公司计划做数据迁移,设备没能按时运到,这个意外导致项目delay,产品迟迟不能上线。

如果设备运到时间能够确定,可以在这个周期安排做其他事情。在时间不确定的情况下,可以先待命做一些零碎的事情,设备来了后,把当前冲刺做完或者解散掉,开始数据迁移。让团队成员的工作有规律有计划。

 

文章来源:V部落 

如何规避敏捷转型中的坑

从而稳固又靠谱地实现转型?

快来参加敏捷ACP®认证课,获得满满的干货!

报名咨询:http://acp.aura.cn/acp_bj/kc/index.html


敏捷ACP®常见问题