当时拥护及反对“敏捷”的各有人在。很有意思的是，在内部论坛上，我们属于敏捷的坚定支持者，又喜欢说话或者说辩论，所以可谓是当时论坛里的焦点，矛头所向。和大家进行了很多很多的辩论，当然多数都是无疾而终。我认为这些讨论，以及发生在工作场合里的许多讨论，同事间私下的交流都非常好，在变革之际，能够帮助大家去理解这场变革（就算是纯粹的抱怨也并非一无是处）。

　　组织变革的关键还是在于充分沟通，以及切实执行。有不同的声音不要紧，关键是要去澄清和解决他们的疑问，因为没有大家的理解和认同，变革也很难取得实际的效果。

　　浪费

　　加班加点赶进度的情形相信大家并不少见，但如果这么辛苦做出来的东西并没有真正地或是及时地派上用场，恐怕就更加可惜了。该平台部门曾经很辛苦地去兑现某一个重要发布的最后期限，而根据客户提交的缺陷报告来看，其中有一些功能客户并没有在拿到这个重要发布后就去使用，而是在拿到后续的发布后才有使用到这些特定的功能。

　　该平台部门并非是直接面向终端客户，还需要结合上层的网元应用才能真正地产生效果。常规的模式都是网元有一系列客户需求（具有非常大的粒度）中分割出对系统平台的需求后，传递到平台部门的项目进行管理。出现过的情形是，平台部门赶出来递交的功能特性，由于网元应用没能及时开发出来，而无法递交给客户使用。

　　对此，大家有很多疑惑，我们是否在做该做的事情（功能特性），其中到底有多少浪费。Scrum的主张就是对用户需求进行优先级排序，但其中有一些关键的点必须要重视，否则很容易流于形式而无法从中获益，第一，要将需求分割到合适的细粒度，团队才有可能持续地递交高优先级的功能特性，需求粒度不够小，假设Product Backlog里就只有一个条目，那么不管是PO还是销售还是客户都没有办法取舍；第二，要逐渐达到以真正端到端级别的需求为单位进行开发、管理；第三，开发团队和PO（能够和终端客户、用户交流更好）之间有频繁地交流、功能成品展示，从而可以利用反馈来改进、提高后续功能的开发。

　　局部优化

　　有话说“不怕神一样的敌人，就怕猪一样的队友”，其实做软件也是，怕的就是劲不往一处使。但说回来还真不是大家不努力，而是对这个“一处”的看法各有不同。关注于各自目标的达成，并不能保证这些努力叠加起来能够实现那个 “共同的”目标，对局部进行的优化可能会反过来扯集体的后腿。这样的现象，组织各个层面都有。团队内、团队之间、产品线之间，都存在着这样的情况。

　　例如团队内部，由于不习惯转型过程中新的特性团队的工作方式，团队内部也还是颇有些泾渭分明的开发、测试各一拨人，自个选自个的工作，迭代开始的时候，各自就把自己的任务选走，然后整个迭代就盯着自己的一亩三分地拼命干。但问题是，团队需要负责、承诺的是最终可以运作的软件增量，而这样的模式无法保证迭代结束时的交付。

　　团队之间也是如此，为了让自己的团队工作预期更稳定、工作中能更专心，团队也都要求确定他们的工作领域，迭代中则有些简单粗暴的拒绝许多协助进行缺陷分析的请求。结果就是导致缺陷分析、修复的工作变得非常难以开展，而且有很多尚未查明的潜在缺陷被放弃追踪和申报。

　　更大范围内来看，我们完成了传输平台的开发还不够，要能够产生客户价值，还少不了上层的应用软件系统。但我们的系统工程师团队、Scrum团队、系统领域测试团队等，以及上层的开发团队、功能测试团队、版本测试团队、系统测试团队等一干团队，尽管都在努力改进自己的工作绩效，可问题是，这些局部的、片面的优化，在组织层面观察，对终端客户产生的影响微乎其微，甚至是副作用。

　　敏捷、精益的要点正在于此 —— 关注于产生的价值，移除不必要的浪费。不恰当的局部优化也是一种浪费，我们要具备系统思考的能力，从整体上看问题，然后改进绩效。组建特性团队就是开始。

　　软件质量

　　软件质量是很多组织都有的一些共性问题，任何变化都意味着质量降低然后恢复到当初，然后再变得比以前好的循环，在我们组织中还是不可避免经历这样的循环。

　　在敏捷的转型中，如果没有很好的考虑这些质量的风险，那么最终它所带给组织的将是未来很长一段时间的“痛”，背负的“债”需要很大的代价来偿还，所导致的结果将对客户的满意度和信任都会产生很大的影响。