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