Scrum 思考

下个月就要离职，所以这个月特别清闲，上班时间都在上网看书，偶然在Startup News的一篇文章（http://blog.devtang.com/blog/2013/06/17/startup-anniversary-note/）中看到一个Scrum这个名词，第一印象以为是某种工具-_-!!!，遂google之，才知道是一种敏捷开发框架，看了两本相关的书，觉得这种方法非常高效，迭代式的增量开发，每次sprint都有产出，开发者非常有成就感，也能及时收到反馈，项目也不会遥遥无期。于是开始思考是否适用于现在的工作环境。

背景：

现有IT部门主要职责是负责维护旧系统（10年历史）以及基于这个系统进行功能扩展。公司是美国公司，技术部门在中国。工作模式就是，美国的客服使用SugarCRM记录客户报告的case和bug，创建后直接指派给相关负责人，负责人再分配给程序员，程序员按照priority按顺序修复。完成后发回给Q/A，Q/A确认没问题，在每周二进行预发布，每周四真正发布到正式服务器。

问题：

    这样的流程已经有一段时间，程序员一般都非常清闲，只要把case和bug完成了就行。系统代码杂乱不堪，只要你能修复客服问题，能实现他们要的功能，美国同事就不理了，代码一直停留在最原始的的状态，程序员在这种环境下变得松散，慵懒。于是我就想，能否通过引入Scrum工作方法，来提升产品质量和性能，同时，对于程序员本身也是一种负责任的态度，毕竟整天没事做很无聊。于是有了下面的设想：

设想：

1. 将每周发布一次的周期改为更长周期，比如两周

2. 第一个周一开全体开发人员例会（相当于sprint计划会议），会前准备需要修复的bug和新增功能， 整理出两个星期内需要紧急完成的任务，一般不需要太多，预留充足时间，以防中途有一些critical的case。同时，全组人员讨论，系统需要优化的项目，每个人发表意见，通过投票挑选出急需优化的1项, 讨论是否能在此次周期中完成，是否需要将该项分割。

3. 确定此次要完成的任务后，大家对所有任务进行评价，按重要程度分配工作

4. 设定“看板”，看板包含四列：To Do, Work in Progress, Q/A , Done。看板的好处直观的了解到每天的进展，保持紧迫感，到最后一天看到所有任务都在Done列，也有一定的成就感。 这个“看板”在《精益创业》这本书也提到过，只是书中提到了verify列，我们很难做到。因为我们不是产品负责人，所以只保留最简单的四项。

5. 程序员完成一个case和bug，还是自行测试，然后assgin给Q/A进一步测试，确认没问题就可以直接发布到预发布服务器进一步测试。

6. 建立wiki页面，记录每次sprint完成的主要内容。

好处：

　这样相对于现在有下面几个好处：

1. 解决程序员有时候无事可做，有时候很忙的情况。

2. 冷却某些高管天马行空，但是对用户根本毫无用处的想法。

3. 每次sprint都能对系统进行小规模优化，稳定性及可靠性不断提升。

4. 所有任务对于团队成员非常透明，方便交流。

5. 每次sprint的产出都具可直观体现。

这是看了两天关于Scrum后的思考，未经实践，有点邯郸学步的感觉。虽然目前情况没能力改变，但是也针对的一些思考，对我未来职业生涯有所帮助。对于即将任职的新公司，是多个项目同时进行公司，每个项目相对独立，但是每个项目成员只要1-2个程序员，人员分配应该如果处理？ 有什么实践中的细节需要处理？希望有实战经验的园友们赐教！

参考书籍及文章：

[硝烟中的 Scrum 和 XP]

[看板和Scrum相得益彰]

http://zh.wikipedia.org/wiki/Scrum