1、关于超负荷工作
曾几何时,Brad也想过试着给团队施压让他们多承诺些,后来他发现,团队的速率,即每个Sprint能够玩的的故事点,是不会撒谎的。更搞笑的是,Brad发现,公司承诺维持可持续的速度并削减了疯狂时间之后,团队的生产力不降反升。
施压团队接受“挑战性目标”所有的成果就是增长的缺陷数目,这都是归因于更多的压力和更长的工作时间。
心得:领导或客户要求在某一天(或者提前)必须上线,往往要付出更多的代价:
① 往往还是会再“拖上”一两天延迟交付,这不仅让团队成员疲惫不堪,同时严重打击团队成员的信心;
② 赶鸭子上架,上线后出现一系列bug,导致产品用户体验差,这隐性的成本远比提前上线来带的收益高得多;
③ 长期下来,开发团队获得或少会抵制管理者,至少内心会有所抵触,在这样的心态下的工作效率可想而知。
2、瀑布开发模式
报告指出,以传统方式运作的企业级软件项目中,只有16%可以按时按预算交付,31%的项目被取消,还有53%的项目预算超标189%。当他们被问及这些项目为何失败得如此惨烈如此频繁的时候,IT经理们提到的首要原因就是“用户参与少”,第二位的是“需求不完整”,二者相距甚远。
心得:传统的瀑布模式,往往是在最后一公里时候(验收阶段)暴露出种种问题,需求不符合预期,功能缺陷太多。即使给产品经理和开发团队在开发前期花在需求上的时间再多,他们也很难再需求阶段真正地分析和挖掘出所有需求。有些需求注定会在设计实现或在用户使用过程中才逐渐出现。所以需求必然是渐进明细,不断纠正的过程。
3、敏捷开发模式
所有种类的敏捷流程都有一个共同点:它们拥抱变化,视变化为成长的良机、而非障碍。
敏捷开发和瀑布开发之间差别在于:瀑布开发必须先完成当前步骤之后才能头也不回地向下一步骤。而敏捷团队会做一点点需求收集,一点点设计、编码和测试,最后交付一点点价值给客户。接着团队再重复此过程.....周而复始,工作推进过程中不断改善、调整流程,一直到项目完成为止。
心得: