从瀑布开发模式到敏捷开发模式（scrum）的思路转换

部门推广scrum敏捷开发已经小半年了、团队也从不适应、慢慢地开始变的习惯。之前领导安排我作为我们组的scrum master、因为从来没有做过leader、然后直接之前也没有接触过scrum、更是非常别扭、很吃力、因为不仅要做master的工作、还要承担100%的开发工作、开始的时候非常吃力。现在随着大家都开始慢慢习惯scrum的工作模式、我才开始慢慢地从每天1/3的时间、降到每天只要半个多小时花在scrum的管理上面。

如果要我总结中间的模式转换的话、我觉得最关键的有两点、一是大家对于敏捷的认知要深刻、要让全体成员都自我改造成敏捷开发者、二是要做好对product backlog的管理。

自我驱动

虽然我们号称敏捷了、也每天开早会、也有了自己的sprint看板、每个sprint也要开总结回顾会议、但是我觉得这些更多的都是敏捷的行、而不是敏捷的神、那么什么是神呢？我个人觉得是作为团队成员来说、神就是从被驱动、改变为自我驱动，这两者简直是两种思路。

最开始的时候、我会每个sprint之前、为组员整理好人力分配图、其实就是帮每个人安排每天的任务、然后在接口出问题的时候、也要我去催、接口卡在哪里了、有哪些解决方法。我非常累、大小事情都要操心、组员遇到问题了、也会问”master、这个出问题了“，然后就等我帮忙解决。后来领导开会、一起聊、发现其他的组也是有这个问题、每个组的scrum master都是身心俱疲、这时候、领导也说、我们其实只是组织大家在一起协作、而不是所谓的”项目经理“。

在这之后、我就有意思的从具体的事物中脱离出来、把原来的什么都管、转换为专注为大家提供一个更流畅的合作上来。我不再帮每个人分配要做哪些、而是大家自己去分配、去协调、我不再去管具体的接口的发布日期、而是让做这个story的人、自己去商量。慢慢地、大家就知道了、这个story是我的、那么、所有关于它的事物、我都要关心、story不是产品经理、也不是master的、所以大家有责任去把它做好、这样反而极大地提高了我们的开发效率、从中央处理式、变成了分布式处理、每个人都很关心当前的story、大家也有了更高的目标、不再是“我要把这个功能完成”，而是“我要为用户创造价值”。

product backlog管理

第二个非常重要的、我觉得是backlog的管理、我觉得一定要有一定数量的backlog、不仅让整个团队时刻有目标感、知道我这个阶段要做哪些事情、而且能帮助产品负责人理清自己的思路。可能很多人会觉得、作为产品负责人、肯定是接下来半年做的、都在心里了、我觉得未必、我就遇到过完全没有思路、甚至需要我一起帮理清产品思路的人。因为公司的业务非常多、任务也比较重、导致很多需求的质量不高、下个sprint都要开始了、UI的设计风格还没定、 这种事情就发生在身边！

从一个开发的角度来讲、我当时是希望需求早就定了下来、并且永远都不会变、但我知道、这个是妄想、但是我觉得、提到开发面前的需求、至少要是经过产品深思熟虑、考虑了很多不同的方式、最终觉得的一个比较好的方式、这样、即使有变化、也不会是大的变化。开发的角度就是、很不喜欢大的变化、尤其不喜欢不确定的东西、写了if、总要写个else吧、如果sprint过程中不断的变化需求、那感觉就像、正打着LOL、不停地断电、时间都白白浪费了、我觉得烂需求就是在扼杀开发的生命、就是在浪费团队的资源！一定不要让这种事情频繁发生。

我的经验是、最好下个sprint开始之前的两三天、就可以和产品要具体点需求、master先大致看下、没有什么致命的漏洞、也近来难过保证UI之类的都是完整的、会把后面可能的变动降低很多。另外需求的变更一定要有记录、这样几个sprint下来、就可以拿着记录去和产品负责人谈这些问题。

从普通的开发流程、到敏捷开发、是会有很多的痛苦、但我觉得、适应了之后、成果会让你觉得、都是值得的！