适度的scrum(宜信scrum培训征文)

适度的scrum

      自从那天scrum培训，史文林老师为我们引进了一条通向卓有成效的项目管理之路后，我们技术部便开始酝酿实施scrum，如今已在紧锣密鼓地进行之中，各大项目组纷纷启动。君不见，办公室scrum白板的领地陆续被占领，便签纸越贴越密，正是忽如一夜春风来，千板万板便签开啊！

      说是春风，scrum必是为我们的项目开展带来许多的好处。它作为迭代式的过程模型之一，首要的优点是敏捷，客户的需求能很快地得到实现，及早沟通，避免了最后产品与需求驴唇不对马嘴的后果；scrum在需求管理上遵循“柏拉图原则”，强调需求的优先级排序，它提倡好产品通常是简单的产品，一般来说，软件只有20%的功能是经常使用的，而其他功能可能实现复杂却不经常使用，或几乎不使用，scrum在每个迭代中都优先实现这20%的功能，那么在项目结束的时候，即使不能完成计划内所有功能，也保证了重要的、优先级高的功能点的交付，这样大大降低了项目以失败告终的概率；再者，scrum信息共享开放、透明，组员各自任务的实际完成情况会在每天15分钟的站立会议上陈述，任务人对任务的完成作出承诺，提出按时完成任务的障碍，项目风险能够及早地暴露出来并得到处理。

     无可质疑，scrum提升了我们团队的总体战斗力，项目运转规范、管理有章可循，一切看起来都是那么美好。但是在实际工作中scrum某些要求却与我们传统的项目管理模式有所出入，很多时候我们又不得不向客观环境屈服，原汁原味的scrum往往不能被真正地执行，群众里边也已经有了一些质疑的声音。但其实，scrum不能当做一种制度、一个过程模型那样放到一个框子里去执行，正如史文林老师所说，scrum应该是一种思想。因此执行scrum不必拘泥于某些条款，可以结合传统的项目管理模式给出一个适当的解决方案，实施适度的scrum。

     按照scrum的实施细则，团队是自组织的，组员之间的关系是平等的，开发团队内不存在项目经理这样一个领导者，这点与当前中国软件业的现状大相庭径。传统软件开发项目里，项目经理是最重要的一个角色，而且很可能是个技术中坚，基本上能胜任项目组内任何一个人的工作，职责是调用现有的资源解决项目开展过程中遇到的一切问题。当然，不懂技术却能解决问题的项目经理也有，但是比较少见。长久以来，项目经理在团队中就树立了一个光辉的形象，项目经理之于团队就相当于将军之于一群士兵。难道因为实施scrum就把他免职了吗？不是的，也许在scrum团队里他换了一个头衔，叫scrum master，一只勇敢的牧羊犬，不论如何，他还是作为一个拥有极大团队影响力的人存在。另一方面，scrum提倡团队成员之间的平等性，却利于人员积极性发挥，原来等待将军发号施令的士兵也开始主动思考作战方针了。

     关于度量，scrum的一个迭代sprint有一个严格的时间箱，若原计划两周完成的事情用了两周零一天，那么这个sprint是失败的。问题是，我们应该如何看待sprint失败这个事情呢？我们需要因为它而否定我们的辛勤劳动吗，还是做计划的时候以保守起见高估工作量？两周内完成的功能点多代表产能高，否则就代表效率底下吗？软件产品每个功能点需要用多少时间完成，项目能在多长时间内完成，是毫无开发经验的人士拿着计算器能算出来的吗？当然，我们还得做计划、按计划办事，只是计划不如变化快，时间线太严格就显得苛刻了，由于经验不足风险预估不全面种种原因实际完成情况与计划不一致的事情是常用的，sprint失败不代表项目的失败，计划本身不重要，持续做计划才是最重要的。

     scrum取名自橄榄球比赛的本意是scrum团体在项目开展的每个阶段基本都是全员参与的，任务得到最大程度地并发，它要求研发团队的成员最好是全职的，组员可以认领任何一项任务。这种理想情况往往难以实现，俗话说得好，“闻道有先后，术业有专攻”，全才式工程师还是比较少见的，项目经理可能比较全才，但是DBA、美工和架构师的工作还不是经过短时间的传授能够胜任的，不过我们可以朝这个目标去发展，为公司培养最优秀的程序员。

     前面说到了scrum迭代式开发的优点，它在功能完成上是纵向开发的，每个迭代都有可交付的功能点，能够及早地与需求方沟通，降低需求风险，而传统横向的分层式开发见效慢，需要到项目中后期才能交付产品。但是纵向开发的项目容易忽略人员任务的轮换，通常一个功能点从底层到外层都是一个人在开发和维护，若期间发生人员流动，后期工作交接会比较麻烦。另外，切块式的纵向开发也需要以整体架构规划为基础，所以项目研发的前期可能交付的功能点会少些，总体规划、底层架构和基础服务的搭建也是不可少的。

 

    以上只是本人关于scrum实施的一些浅薄的看法，若有不正确之处，请海涵！