我曾经问过几个同僚：现在你要带三个小兄弟开始开发一个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。