《硝烟中的SCRUM和XP》读后感
2013-10-16
半年前同事极力推荐了这本书而且谢了一篇对他来说茅塞顿开的读后感。春节期间看完了这本仅仅有着100多页的书，这也是今年看完的第一本书。看完给我的感觉就是“这是一个令我不是完全明白的好方法”。书中很多观点和方法对于产品开发都是很好的，不过正如作者所说，这种方法目前也是还在不断尝试和改进中，至于是不是最好的方法，当然取决于各个公司的“国情”。
依稀记得2011年公司曾经采用过类似的产品开发模式：评估项目工作量、确定开发进度和交付日期，采用白板更新进度等等。后来因为各种执行上的困难和弊端不了了之了。看完这本书结合公司之前的失败经验，我做一些关于产品开发管理和敏捷开发的个人认识和总结，希望能与大家一起探讨好的开发进度和管理模式。
1、产品开发/项目开发就像个人的职业规划和工作计划一样，必须有长线和短线。长线规划公司产品的未来发展及主要节点；短线要具体分解每一步具体要执行的步骤及模块，甚至要细分到每一周，每一天的工作安排。只有让所有人明白了项目的目标和需要做的事情，大家才能拧成一股绳一起去努力。我所理解的每一个sprint（我理解为“发布周期”）流程为：
理清工作思路→确定工作量（全体会议）→确定交付日期（全体会议）→分配工作内容（技术团队内部会议）→公布工作量及目标（对外公布）→及时更新工作进度（对外公布）
这样做的好处：
可以让团队都清楚大家接下来一段时间的目标是什么，拧成一股绳。
可以让每个人都清楚别人每天都在干什么，这样才会在内部形成竞争力。
可以让公司的领导及其他部门都知道团队都在干什么并且知道每天都完成了哪些内容减少了不必要的谈话，会议和质疑。
对项目的把控性增强了，知道什么时候需要催一催进度，什么时候可以让大家稍微放松。
难点：如何准确预估（评估）工作量，如何避免过多预估工作量导致产品失去竞争力？
2、合理使用“燃尽图”。它能够帮助团队及时判断项目进展是否在计划之中，避免产品开发进度过快或者过慢。
3、多做有用的事。去掉花里胡哨的东西。也不要把时间花在会议PPT的美化上，传达出报表大的信息即可。
4、下一个sprint中如何做得更好，需要总结上一个sprint中存在的问题和需要改进的地方。
5、制定一个大的产品发布规划大plan（plan1,plan2···）包括大致的发布日期。这中间牵扯到版本发布计划，除了正在进行的sprint需要确定精确的发布日期和发布内容外，后面的都可以根据实际需求的变更做出灵活调整。
6、上一个sprint和下一个sprint之间设立一个“缓冲日”，用于给团队成员调整状态。
7、我的疑惑：
拆分功能点（模块）的方法。
测试bug的修复安排是否占用下一个sprint时间，如果占用，如何来保证下一个sprint进度？
有一点是我在读书过程中发现的：书中一些自己经历过的事情读起来会很有味道，也很能揣测一些当时存在的不足和经验。而还有一些自己不是很熟悉的部分则比较拗口难懂，一扫而过有一个印象即可，随着经历也会慢慢深入并得到启发。