Scrum一瞥印象

Scrum不新鲜！也许你目前实践的软件过程到处都有Scrum的影子。没错，Scrum把过去软件过程中那些有效地组织和管理的实践都纳入到自己的名头下（有点卑鄙，不是么:)

我曾经问过几个同僚：现在你要带三个小兄弟开始开发一个Web2.0网站了，需要准备哪些协作环境？
结果我几乎得异口同声的回答：Subverison, Bug Tracker足矣。(在我的“熏陶”下，很多人都在使用那个简单得不能再简单的 Mantis作为项目的Bug跟踪工具。) 如果非要我再丰富点什么工具的话，我会加一个Docuwiki记录和共享项目相关知识。

最下意识的回答往往最能体现最本质的需求，不是吗？ 我发现很多软件项目在使用了合适的工具之后，往往就为成功修好了基础的路。你不信？ 当你使用subversion，你的代码就被控制住了；你在使用bug tracker的过程中不断修正自己的软件过程知识，用好一个规范的bug tracker就像交了一个好朋友，熟练软件的同时也规范和加深了你对软件过程理的理解。

从实践角度看，一开始过于强调使用工具来理解不同的软件过程不失为一个好方法。我参加一个团队使用 Trac来跟踪管理项目包括Bug,我有如下的脑海印象：

当我学习Scrum时，我找到了一个叫 Agilo的软件，它是基于Trac实现的，引入了Scrum管理，经过试用，我得到了如下的脑海印象：

对比两图主要差异：
1. 角色描述对比
  我不觉得Project Manager到Scrum Master的转变是质，甚至根本没有什么不同
2. 下图黑色圆角框是引入Scrum的新名词
  我痛恨新名词，新名词让世界更混乱。我的看法：Sprint不过是比里程碑更小的迭代。

Scrum是敏捷开发的一种实践，他们都共有敏捷方法的特质：
迭代开发是敏捷宣言的基本原则 —— 在早期频繁的交付可工作的软件
从而我想不难理解为什么Scrum有了这个Sprint

谁要是以为一本<<Scrum实践>>,一篇演讲或者博客你就完全理解了Scrum"剽窃"（从传统软件方法中总结）的所有概念，那就错了。你必须实践，每一个细节运用不到位，都可能让成员怨声载道。不过上图勾勒出来的图景应该是一个实践Scrum好的开端。你吃饭走路都应该默诵： 交付Sprint1,交付Sprint2,交付Sprint3.......他们都在我的Trac上...

从工具角度看，SCRUM的引入除了在传统Bug Track上增加更大的迭代支持，另外还有一个Sprint会议纪要，每个Sprint（你可以叫他更小的迭代，或直接说冲刺）会议之后，形成如下纪要稿：

剩下Scrum描述的每个Sprint活动就围绕这这个会议纪要及Sprint所包含的tickets进行讨论、会议、开发、测试了。

好了，暂时这么多。 我理解Scrum不是推翻性而是改革性的软件方法，现在就可以去实践，团队日渐Scrum。