Scrum实践总结

公司执行agile过程也快有一年的时间了，各个小组都将agile过程应用到自己的项目开发中。我参与了其中一个项目的整个过程。经过了这快一年的项目体验，我逐步对agile的实践有了一个感性的认识。我们组执行的是Scrum的方法。以四周为一个迭代周期，内部称为sprint，以backlog来代替文档化的需求说明，用story point来衡量每个开发人员的工作量。组内有scrum master，有QA，有developer，product master在美国所以基本上需求都是隔天才能获得消息。整个项目进行的倒是有条不紊，但是我却没有体验到agile给开发人员带来了多大的好处。或许是我们对scrum认识和用法的不足，从而导致的开发人员疲于奔命。Scrum的优点和理论我就不说了，很多公司在用，证明这是一个好的方式。下面我列举一下我所认识的scrum和组内实际使用的差异。

• 人员不够精炼，整个小组15个开发人员还有5个美国员工，5个本地QA和2个印度QA，一个scrum master和一个product master。这样的团队对于scrum的过程来说过于庞大，以至于每次stand up meeting都要花掉半个多小时。并且也没有什么信息交流，大家都是例行公式的报告一下自己的进度而已。我仔细计算了一下在这上面浪费的时间20*0.5*5*4=200个人时。这是什么概念？一个人一天工作8小时，一个月需要240人时。也就是说我们每个迭代光开会所花的时间就浪费掉了将近一个员工的时间。
• 燃尽图从来也没有看到触底过。昨天看了一个关于scrum里面注意点的视频，里面那个讲师就提到开发节奏的重要性。我仔细想了一下，确实开发节奏很重要。我现在的项目就是没有开发节奏，所以搞定大家都疲于奔命。不断的有新的feature往里加，你可以看到开发列表排的很长很长。而且每一回开会都会加入一些新的feature。这些feature也没有什么优先级和重要性，就是顺序的往下做。回头想想都觉得恐怖。你想你的任务从6月一直排到12月，全满而且还有可能会加入新的开发内容，这会是什么感觉。所以，燃尽图那条红线从来就没触底过。
• 没有规范的迭代评审，scrum里面很重要的概念就是在迭代周期结束时，要把已有的内容release给客户。虽然我们不面对真正的客户，但是也不至于不去评审build。因为没有规范的迭代评审和自动化测试的支持，从第一build开始，几乎没有一次在迭代结束时有一个功能稳定的build。作为开发人员，我都没法拿到一个工作良好的build来verify我自己的功能。这种情况就是对迭代周期执行不彻底的结果。因此，QA大多数时间都不能很好的去测试，bug从这个build传递到下个build，又传递到下下个build。
• 对小组开发人员技术能力了解不够，做领导的通常不会去关心下面的人你会什么，不会什么。他关心的是你的任务完成了没有。我们小组大多数人都来自c/c++/c#项目，现在要开始做Java项目，没有时间学。只能一边学一边用，所以可想而知写出来的代码质量如何，整个项目也就3个人是做过多年的Java开发，整个框架也是他们在搭建。因为一开始对没有UT要求，所以很多c/c++开发人员都不写UT，因此bug也就很多。
• 任务分配的不合理，很多人有一堆的任务同时在做，而且还要fix bug （这个不算在工作时间里面，好奇怪），还有的人跨了好几个项目在工作，一天要参加3-4个stand up meeting。我们很笑称xxx党会多，原来agile的会也很多。任务也没有什么优先级，还有一个很有趣的现象是，比如你有三个任务，一个需要1天，一个需要2天，一个需要3天。所以，完成这三个任务需要6天时间，而我们的scrum master在统计的时候统计成3天时间，也就是说你需要在3天内完成3个任务。好奇怪的算法。
• 工具太烂，我们一直都在用excel在进行backlog管理，我记得我在2007年参加微软的TechED时就听微软的人说，他们最早就是用excel进行项目管理，后来是邮件，再后来是VSS，现在是Team Foundation server。看来我们还很原始啊！用excel唯一一点不好就是没法进行任务队列的优先级调整，和根据时间总量排队。这也是为什么会把6天的任务算成3天的原因。还有就是公司的代码管理工具不好用，不仅慢而且Java代码树管理的很差。正如一个人，你想跑不把你绑在脚上的绳子卸掉，你能跑的起来吗？所谓欲善其工，先利其器。由于多个工程的Java代码相互引用，结果每次check out代码到本地后，就得花上半天的时间去编译。真是快疯了。

就我的理解，想要解决以上这些缺点并不十分困难。 首先，根据agile的指南将小组拆分的更小一些，同时使用在线的agile工具来管理backlog和daily task update，这样就可以节省很多时间。每次stand up meeting，每个人只要回答：做了什么？正在做什么？有什么困难？即可，3个问题5个developer最多15分钟搞定。不要在会上讨论细节，因为不是所有人都需要知道细节，会下讨论更好。对于feature按优先级排序并加以数量的控制，这需要一个好的工具。设立明确的迭代评审机制，这样有利于明确和控制本次迭代的开发内容，并保证build的质量。同时也可以建立一个比较好的开发节奏和员工士气。至少让员工不会产生因为发现开发任务做不完而逃去休假的想法。给团队成员更多的技术培训，这个对于都是新手的团队来说非常重要，毕竟再牛的人对新技术也需要一段时间的学习。让所有人更好的掌握开发技能，代码质量就更高，项目进度就会更快。虽然agile不强调工具，但是好的工具真的很重要。