2010年11月29日
10:07
一个人写软件可以仅仅面对屏幕，奋力敲入代码就好。而团队开发模式下需要方法论指导大家的协作，以便达到共同的产品目标。方法论是必要的。
一个项目经理在推进团队“更快的解决Bug”过程中有些经验。他说：“我们在采用一种叫做‘青蛙王子’的方法来推动大家积极的解决Bug。方法是把一段时间捉虫最多最好的程序员叫做青蛙王子，并且给予奖励”。
在谈及“青蛙王子”的时候，这位项目经理一直在强调“特定时期，特定目标”。就是说，它能够解决问题，但是针对性很强。推动“青蛙王子”之前，组员觉得Bug是改不完，也不愿意改。通过这样的方法，让大家改变心态，积极修改Bug，并且通过定期的公布总Bug数量，剩余Bug数量、项目经理的评价的方式，让每一个在这段时间内集中精力做好一件事。现在的Bug少了，这个方法也就很久没有用过了。
在差不多同一时期，我们也出现了很多这样的小型方法，专注于解决特定时期的问题，它们都有一定的成效，但是缺点也比较明显——只能解决特定问题。和这些我们自己的方法论相比，Scrum可以在任何一个项目的完整周期中使用，并提供比较全面的过程指导。
Scrum可以促进大家的沟通，让开发更有乐趣。我们的一个老板曾经说，程序员都是些没有多少感觉的家伙。他为此举例，“本来大家都是面对面的，一句话就可以把问题讲清楚了，但是很多人会通过即时通讯工具发消息，而不是直接沟通”。程序员的工作一天到晚的对着电脑，编写没有人看得懂的代码，也显得毫无乐趣可言。而Scrum过程要求大家做更多例行的沟通，包括每日演示、设计讨论、提出问题和找到帮助者、定期总结，从而促进大家的沟通、快速的解决问题。
Scrum可以帮助每个成员把握项目的进度。以前分配了任务，程序员就分头做自己的工作，可能两周甚至一月才集成一次，而当真正集成的时候必然产生一堆问题，比如重复编码，做了不该做的。这样的进度管理是比较粗放的。而关于Scrum的做法则是每天集成，不管什么问题，都会很快的表现出来，而不会等到做了一堆无用功后在去返工。Scrum的每日集成，让问题更加容易被发现，把风险分担到每天内，而不是等到问题积累到很严重后再去解决。
和重型的软件方法论相比，Scrum可以是拿来就用的。它对工具要求都是很基础的，不外乎是白板、即时贴（我们另外一个项目用了墙上卡片）、简单的Scrum工具（比如 ScrumWorks）。不需要看很多书、不需要太多的实施指导、也不需要咨询公司的支持。