论scrum成败

平时公司管理结构

                   

                           

做项目时候管理体系

    简单说下，做项目的时候，4人中会有一个leader,但是这个leader只领到一般一个月，然后换下一个人。例如 2012年5月，甲是项目领导，2012年6月就变为低调哥是这个项目的领导，2012年7月就变为实力哥为领到，依次轮流。

优点:

   所谓的民主，人人都有做领导的机会，人人都有把控全局的机会，对公司来说，任何人都成为螺丝钉，上图中的任何一个人离职，对项目构不成绝对打击，不会因为一个人的离职，项目瘫痪。

缺点：

   假如项目失败，没有问责制度，所有人都当过领导。责任没有落实到具体人。

工作方式:

一套围绕scrum为中心的工作方式，scrum中的任务产生于上图中的老板，然后下面的几个人一起讨论具体工作，细化到天，然后有当时scrum的领导(假如是2012年5月就是甲，按时间依次乱流当领导)，分配人物给具体的人。

问题:具体任务细化到天？ 工作方式对不对？ 时间如何决定？

答：具体任务细化到天，工作方式对。时间是由小组所有人共同决定，然后取得平均值。这种方式，之前我也觉得很合适，当具体实施的时候就存在问题了。

问题如下：

假如是做大网站，涉及前端，后端，数据库，服务器配置，自动测试，单元测试，继续集成

但是上面项目组的4个人

甲       后端强于前端,前端弱于低调哥。不熟悉服务器配置，继续集成。主要工作后端开发

低调哥   熟悉前端(html css javascript jquery dojo)，后端不太熟悉，交给的人物能积极完成。

主要工作前端。

实力哥   后端强于前端,前端弱于甲。熟悉服务器配置，继续集成，平时工作主要是后端开发。（是大项中一个模块，跟甲不的模块）

  

嘲讽男   熟悉服务器配置，持续集成，后端开发，但是其他人提出的意见他基本都反对。平时主要工作配置服务器，继承集成。

   当出现前端的时候，肯定是低调哥做，当后端的时候肯定是甲做，当服务器配置的时候肯定是嘲讽男，实力哥肯定做他那个模块和帮助嘲讽男一起配置服务器，搞持续继承。

  因为这里任务没分给具体人之前，其实都已经分配给具体人了，因为UI肯定是低调哥做，所以估时间就失去意思了。只有低调哥真正了解项目需要多少时间，所以经常出现的情况是，大家估计的时候短，最后做具体事的当事人说，时间太短，不够，然后就延长任务时间。

出现这种情况的时候，所有围绕scrum为中心，其实已经失去意思了。

   

  总结：scrum敏捷开发适合于团队成员个个都很全面的情况，熟悉前后端，熟悉服务器配置，熟悉单元，压力并发测试。熟悉程序的部署。简单说就是项目中的任何一个事情都可以做，从无到有，到上线，但是大公司的人很少有全面的，全面的人也不好招。所以scrum很有可能要失败。

  仅供娱乐，请勿对号入座。