敏捷转型的12大难题及解决方法

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

1、谁适合当Scrum Master

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

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

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

2、交叉式团队中，团队不完整

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

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

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

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

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

4、敏捷开发中，测试该放在哪个阶段做

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

5、计划会在实施中，花在产品设计上的时间较多，有时会超过一天

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

6、员工水平参差不齐，如何设定工作量

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

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

7、每日站会是否要更新任务状态和燃尽图

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

8、公司人员总是不齐，站会不容易开起来

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

9、评审会中发现问题，甚至发现功能达不到发布要求怎么办

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

10、老板对sprint做出干扰怎么办

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

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

11、市场反馈多，扛不住压力，有时不得不改变冲刺，打击了员工士气

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

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

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

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

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