感想：采用Scrum能达到降低成本的目的吗？

如何降低成本，是很多组织关注的问题。需求变更不可避免地导致已经开始的工作半途而废，不得不返工，造成浪费。然而，在不确定的开发环境里，需求变更是常态。在瀑布开发方式中，变更来的越晚，浪费越大。这是因为，时间越晚，为开发特性所投入的成本就越多，此时变更到来，浪费的就越多。在成本-变更曲线图中可以看到，随着时间的推移，成本曲线上扬很快。如何降低变更发生时间与浪费成本之间的关联关系，打破变更来的越晚，浪费越大的魔咒？Scrum通过管理WIP的数量，并促进WIP顺畅流动，达到尽可能使成本-变更曲线平缓的目的。通过将产品待办项按照优先级排序，每个冲刺只做最重要的几项，我们就能够控制WIP的数量，使其不会太多。无论变更来的多晚，对那些没有进入冲刺的产品待办项来说，都没有浪费，因为这些待办项还没有开始呢。这样就减少了不必要的劳动，降低了浪费的成本。通过使用时间盒和看板，我们可以观察WIP是否流动顺畅，是否能在短迭代周期中完成计划的工作，促使开发工作稳步向前发展。所以Scrum是小步快跑的灵活的开发方式，特别适合应用在变更多的环境里。与瀑布相比，变更越多，变更到来的越晚，Scrum越能展现出其优越于瀑布的特点。

感想：关注闲置工作更重要，与Scrum原则相见恨晚！

有句话很幽默：总有人没事做，总有事没人做。两种现象都不好，但哪个更糟？在Scrum中，我们深信闲置工作比闲置人员更浪费。闲置工作指的是，有些工作我们想做却由于其他事情的阻碍而无法做。闲置人员指的是，有些人有能力做更多的工作，但当前没有100%投入。很多软件开发组织更关注如何消除闲置人员所造成的浪费，而不太关注闲置工作所造成的浪费。Ken Rubin举了一个生动的例子：我们把“让人100%忙碌”这个策略应用于奥运会4*100米接力赛。我出钱让人跑，结果他们只有1/4的时间在跑，剩下的时间干嘛呢？站着等。呃，这可不行！我付的是100%的薪水，所以他们理当100%的时间都在跑。在没有拿到接力棒时，让他们原地跑或者在旁边的跑道跑另一场比赛呗！这样的话，他们就100%的时间都在跑啦！当然，让队员100%连轴转并不能赢得金牌。只有让接力棒第一个冲过终点，才能赢得金牌。

所以终点是“看好接力棒，而不是队员”。然而为什么很多软件开发组织犯同样的错误呢？因为障碍有时是隐形的，消除障碍需要超出自己的职权范围去协调工作，比如跨部门沟通，甚至赢得高层领导的支持。而人员闲置现象是显而易见的，简单的查看一下周报和加班记录，管理层就可以知道一个团队是否忙碌。与消除阻挡工作进展的障碍，推动工作顺利进行相比，让闲置人员忙碌更容易。面对部门墙，面对只会给压力不能提供支持的高层经理，安排自己团队的员工忙碌甚至加班，不仅容易，还可以给管理层留下“非常努力”的好印象。既然问题很难解决，就退而求其次，争取态度好吧。

采用更好的开发方法，对人的要求，特别是对管理者的要求也更高了。在管理策略上，需要以更加积极的心态去创造性的解决问题，关注闲置工作才能真正推动工作继续进行。

感想：敏捷转型，独立测试团队的末日？

计划驱动的开发流程中，测试团队常常被认为是产品质量的最终负责人。在Scrum中，质量并不是测试团队在最后阶段“测”进去的，而是由跨职能Scrum团队负责，并持续内建与每个冲刺中。

在敏捷转型成功以后，一个组织是否不再需要独立的测试团队了？独立的测试部门作为资源部门，也许仍然存在，也许也不存在了。可以期待，测试者加入Scrum团队，和开发者每天工作在一起，构成一个跨职能团队。测试活动仍然存在，测试者可以不再由固定的人担当，可以有开发者轮流负责测试，或者像结对编程一样结对测试。这样改变的好处是，促进开发者和测试者的沟通，缺陷早发现，早解决。

Scrum会不会因为取消独立的测试团队而忽视测试工作呢？Scrum有完成的定义解决这个问题。一个特性完成，表示必要的测试活动都已经结束。