《scrum要素》读书笔记&工作总结

1、关于超负荷工作 

曾几何时，Brad也想过试着给团队施压让他们多承诺些，后来他发现，团队的速率，即每个Sprint能够玩的的故事点，是不会撒谎的。更搞笑的是，Brad发现，公司承诺维持可持续的速度并削减了疯狂时间之后，团队的生产力不降反升。

施压团队接受“挑战性目标”所有的成果就是增长的缺陷数目，这都是归因于更多的压力和更长的工作时间。

心得：领导或客户要求在某一天（或者提前）必须上线，往往要付出更多的代价：

① 往往还是会再“拖上”一两天延迟交付，这不仅让团队成员疲惫不堪，同时严重打击团队成员的信心；

② 赶鸭子上架，上线后出现一系列bug,导致产品用户体验差，这隐性的成本远比提前上线来带的收益高得多；

③ 长期下来，开发团队获得或少会抵制管理者，至少内心会有所抵触，在这样的心态下的工作效率可想而知。

---

2、瀑布开发模式

报告指出，以传统方式运作的企业级软件项目中，只有16%可以按时按预算交付，31%的项目被取消，还有53%的项目预算超标189%。当他们被问及这些项目为何失败得如此惨烈如此频繁的时候，IT经理们提到的首要原因就是“用户参与少”，第二位的是“需求不完整”，二者相距甚远。

心得：传统的瀑布模式，往往是在最后一公里时候（验收阶段）暴露出种种问题，需求不符合预期，功能缺陷太多。即使给产品经理和开发团队在开发前期花在需求上的时间再多，他们也很难再需求阶段真正地分析和挖掘出所有需求。有些需求注定会在设计实现或在用户使用过程中才逐渐出现。所以需求必然是渐进明细，不断纠正的过程。

---

3、敏捷开发模式

所有种类的敏捷流程都有一个共同点：它们拥抱变化，视变化为成长的良机、而非障碍。

敏捷开发和瀑布开发之间差别在于：瀑布开发必须先完成当前步骤之后才能头也不回地向下一步骤。而敏捷团队会做一点点需求收集，一点点设计、编码和测试，最后交付一点点价值给客户。接着团队再重复此过程.....周而复始，工作推进过程中不断改善、调整流程，一直到项目完成为止。

心得：