敏捷实践的七个方面
我们俩来自于诺基亚西门子网络杭州3G研发中心，本文内容来源于诺西一个通信产品研发部门所进行的敏捷转变，它是典型的多站点开发的研发组织，在芬兰、印度、中国等都有研发团队，总计超过600人。我们免去在文中冗述各种功绩和所得，只在这里和大家分享我们所经历的那些误区、陷阱，当然还有那些应对的措施。
本文仅代表徐毅和王献的看法，如此大的组织转变，我们作为不到1%的人口代表，看到的、经历的难免会有误差，恐怕不能概括事件的全貌，如有出入，请见谅。我们认为经历的误区和陷阱大致可以分成如下七个方面：特性团队、人、浪费、局部优化、软件质量、测试自动化、流程。
特性团队(Feature Team)
在组织中想要达到真正的Feature Team是一个很漫长的过程，当在组织中实现局部的端到端的组的时候，更大的端到端的组的演变要求会出现，因为这时组织中新的瓶颈会展现出来，这也是为什么敏捷虽不能解决问题，但却使问题更显现地表现出来的原因之一。
在组织的转型中，产品有非常庞大的老代码：
1. 通常早期的Feature Team所包括的功能性测试不完全，外部的测试对于这些Feature Team所起到的保护作用还是相当重要的;
随着时间的推移，Feature Team对于自己feature自动化测试加强以及测试能力的提高，发布给外部的产品质量会大大提高;
2. 对于外部其他组的依赖接口会很多，特别是组在不同的时候，沟通、交接和等待的浪费会很大;
3. 当产品中开发部门和开发部门的依赖减少后，开发和测试的瓶颈会更突出;
4. 当产品中各个功能部门的依赖减少的时候，产品和产品间的瓶颈会凸显。
想象一下从客户提需求到终提交功能需要经过多少个过程，特别是大型组织中的产品，端到端意味着几十个过程甚至更多，Feature Team中能容纳多少个这样的过程意味着这个Feature Team的灵活度有多高，本质上敏捷是为了减少相互的依赖、等待和传递所带来的消耗。
一个组织是一个庞大的系统，Feature Team的转变过程意味着减少整个系统中的Limitation。
在向Feature Team演变的过程，在相对比较短的时间把原先十几或者几十Component Team打破组成新的Feature Team，这中间的风险在于：
1. 组的成熟度：成熟度需要时间，也需要一些错误的代价;
2. 组的长期成长和短期项目计划：由于为了项目的进度而把对某领域很熟悉的组移出去做不熟悉的领域;
3. 组织的产出效率：怎样合理的利用现有的有经验人员和新人，建立新结构所需要的基础会使组织整体的产出效率减低;
4. 不可控和无序：怎样让这些组高质量的发布产品在转变过程变的不可控。
理想和现实中的平衡是Feature Team所面对一个问题，剧烈的变动意味着剧烈的阵痛。
人
我们的转变是基于Scrum+XP的方式，转变的影响巨大，之前存在的许多职位、头衔都会面临变化甚至消失的可能。例如将不再会有项目经理来集中处理项目管理的工作，对于产品需求研发顺序的管理也由以往的项目经理手中转为产品负责人来负责。算是基层的开发人员和测试人员，他们的日常工作方式以及职责范围也面临着极大变化。这也意味着转变可能会遇到非常大的阻力，人天性会抗拒未知的变化。
某平台部门的转变尤其特殊，研发的老大意志坚定，在初期Pilot成功后，大刀阔斧地进行组织架构改革，仿佛一夜之间所有的项目经理全部消失。而以往围绕功能模块所组建的分散的测试团队以及开发团队也被重组，每一个Scrum团队都拥有好几名来自不同功能模块领域的开发和测试人员，从某种角度来看，这是我们所倡导的跨功能特性团队的雏形。
各种形式的人员流失造成很大的困难，有人因为个人或家庭的原因离开公司，也有人在新成立的产品线谋得职位，也有人被提升。但这一切都造成原来位置上的熟手损失殆尽，尤其是测试相关人员的流动，曾是很大的隐患。在以往的研发模式中，测试被严格划分为多个层级，由不同的测试部门执行，彼此之间通过高级别工程师以及文档和流程体系来沟通，确保各个层级的测试得到执行。新的组织架构中，除了Scrum团队后，是系统测试团队，而Scrum团队测试和系统测试之间的衔接则出现了灰色地带，原因是彼此对对方的职责各有不同假设，却未能发现及解决。
当时拥护及反对“敏捷”的各有人在。很有意思的是，在内部论坛上，我们属于敏捷的坚定支持者，又喜欢说话或者说辩论，所以可谓是当时论坛里的焦点，矛头所向。和大家进行了很多很多的辩论，当然多数都是无疾而终。我认为这些讨论，以及发生在工作场合里的许多讨论，同事间私下的交流都非常好，在变革之际，能够帮助大家去理解这场变革(算是纯粹的抱怨也并非一无是处)。
组织变革的关键还是在于充分沟通，以及切实执行。有不同的声音不要紧，关键是要去澄清和解决他们的疑问，因为没有大家的理解和认同，变革也很难取得实际的效果。
浪费
加班加点赶进度的情形相信大家并不少见，但如果这么辛苦做出来的东西并没有真正地或是及时地派上用场，恐怕更加可惜了。该平台部门曾经很辛苦地去兑现某一个重要发布的后期限，而根据客户提交的缺陷报告来看，其中有一些功能客户并没有在拿到这个重要发布后去使用，而是在拿到后续的发布后才有使用到这些特定的功能。
该平台部门并非是直接面向终端客户，还需要结合上层的网元应用才能真正地产生效果。常规的模式都是网元有一系列客户需求(具有非常大的粒度)中分割出对系统平台的需求后，传递到平台部门的项目进行管理。出现过的情形是，平台部门赶出来递交的功能特性，由于网元应用没能及时开发出来，而无法递交给客户使用。
对此，大家有很多疑惑，我们是否在做该做的事情(功能特性)，其中到底有多少浪费。Scrum的主张是对用户需求进行优先级排序，但其中有一些关键的点必须要重视，否则很容易流于形式而无法从中获益，第一，要将需求分割到合适的细粒度，团队才有可能持续地递交高优先级的功能特性，需求粒度不够小，假设Product Backlog里只有一个条目，那么不管是PO还是销售还是客户都没有办法取舍;第二，要逐渐达到以真正端到端级别的需求为单位进行开发、管理;第三，开发团队和PO(能够和终端客户、用户交流更好)之间有频繁地交流、功能成品展示，从而可以利用反馈来改进、提高后续功能的开发。
局部优化
有话说“不怕神一样的敌人，怕猪一样的队友”，其实做软件也是，怕的是劲不往一处使。但说回来还真不是大家不努力，而是对这个“一处”的看法各有不同。关注于各自目标的达成，并不能保证这些努力叠加起来能够实现那个 “共同的”目标，对局部进行的优化可能会反过来扯集体的后腿。这样的现象，组织各个层面都有。团队内、团队之间、产品线之间，都存在着这样的情况。
例如团队内部，由于不习惯转型过程中新的特性团队的工作方式，团队内部也还是颇有些泾渭分明的开发、测试各一拨人，自个选自个的工作，迭代开始的时候，各自把自己的任务选走，然后整个迭代盯着自己的一亩三分地拼命干。但问题是，团队需要负责、承诺的是终可以运作的软件增量，而这样的模式无法保证迭代结束时的交付。
团队之间也是如此，为了让自己的团队工作预期更稳定、工作中能更专心，团队也都要求确定他们的工作领域，迭代中则有些简单粗暴的拒绝许多协助进行缺陷分析的请求。结果是导致缺陷分析、修复的工作变得非常难以开展，而且有很多尚未查明的潜在缺陷被放弃追踪和申报。
更大范围内来看，我们完成了传输平台的开发还不够，要能够产生客户价值，还少不了上层的应用软件系统。但我们的系统工程师团队、Scrum团队、系统领域测试团队等，以及上层的开发团队、功能测试团队、版本测试团队、系统测试团队等一干团队，尽管都在努力改进自己的工作绩效，可问题是，这些局部的、片面的优化，在组织层面观察，对终端客户产生的影响微乎其微，甚至是副作用。
敏捷、精益的要点正在于此 ?? 关注于产生的价值，移除不必要的浪费。不恰当的局部优化也是一种浪费，我们要具备系统思考的能力，从整体上看问题，然后改进绩效。组建特性团队是开始。
软件质量
软件质量是很多组织都有的一些共性问题，任何变化都意味着质量降低然后恢复到当初，然后再变得比以前好的循环，在我们组织中还是不可避免经历这样的循环。
在敏捷的转型中，如果没有很好的考虑这些质量的风险，那么终它所带给组织的将是未来很长一段时间的“痛”，背负的“债”需要很大的代价来偿还，所导致的结果将对客户的满意度和信任都会产生很大的影响。
质量问题中，通常我们认为会有三种类型的问题：老代码的问题，新功能开发的问题和改问题引入的新问题
老代码的遗留质量问题所占的比重通常是比较大。庞大的系统，任何的改动都有可能影响老代码的问题，或者老代码不能满足当前的需求所需要做的调整，往往是这些改动或者新需求会影响那些地方通常是比较难界定出来，对于老代码的测试自动化保护是关键。
新功能开发所带来的问题通常会由于对于进度压力的妥协，在匆忙完成当前迭代周期的内容或者需要延迟当前迭代周期去做更多的测试之间矛盾。敏捷的开发模式使得原先长周期的项目进度和项目质量矛盾会在更短的周期里(4周)显现出来。
在敏捷实践中，大的一个优势在于快速的质量反馈。由于持续集成，持续回归测试，质量的反馈会在2~3天甚至3~4小时之内反馈到代码提交的软件人员。
当然这样的快速反馈是基于持续集成所达到的层次，完美的情况肯定是整个产品所有的测试都被放入到持续集成，那么对于整体软件将会有一个非常全面的质量考量。
自动化测试
测试自动化被许多人看做是敏捷的基石之一，众多的敏捷实践依赖于自动化的程度，例如持续集成。而能够实现增量式开发也需要能够快速、全面地进行回归测试，确认已存在的功能特性没有受到新特性开发的影响。在大张旗鼓地进行敏捷转变之前，我们的产品线已经开始尝试过测试自动化。一个专门的测试自动化小组在半年多时间内，操作芬兰专家开发的自动化测试工具，将那些执行频率很高的回归测试用例集实现自动化执行。基于由此项目得来的成功经验，测试自动化的概念被广为传播，而且这个实践也开始作为一个基本要求附加给测试团队，自动化测试用例占所有测试用例的比例作为一个指标被上层主管密切关注。
开始进行敏捷转变时，围绕着测试自动化有很多的争论，主要的焦点在于是否要追求的测试自动化。反对方和支持方都各有理由，难分高下，不同理念都有追随者在实践。支持者认为自动化测试可以节省执行时间，而且可以在夜间及进行测试执行。反对者认为实现自动化用例耗用了测试人员的绝大部分时间，来自于基层的部分意见反映他们都没有时间去真正的测试系统，而且还有一些用例非常难实现自动化，或者说成本非常高。而新的一个情况是，在一个新的版本发布计划中，测试自动化的开销总计以万小时计算，那么是否有必要一定要实现测试自动化?
我个人认为，其中很重要的一点是测试自动化以及其比例被作为硬性指标施压给团队，导致团队无暇顾及测试自动化的质量高低。而测试自动化的质量恰恰会影响到：执行时间的长短、维护自动化脚本的开销、实现测试目的的准确性等。另一个原因是，了解、专长于测试自动化，具备大范围应用测试自动化经验的专家太少，还常常疲于应付实现具体的测试自动化用例，无暇去传授、辅导及培养其他同事的测试自动化技能。
流程
敏捷的转型过程中，如果认为流程可以被抛弃，可以按照自己的想法去做开发测试，这样的观念将是很大的一个误区。
流程之所以为流程是因为它所承载的是一个组织长时间积累的经验与教训，它被实践所证明有效的方式，怎样使做某件事情的效果与效率达到优，并在多年的实践中被不断的补充。
比如同行评审，我们的误区在于认为人们会自动自发的组织好同行评审，可以使用开发组所自己的方式。老的同行评审的传统并没有很好的沿袭，特别在组织大规模扩招的时候。导致的结果是我们的需求，设计代码的问题比以往任何时候都要多。
比如测试，组织大规模的调整，但是相对应的测试在新组织里的怎样的计划，新开发组里测试以怎样的方式进行，怎样是有效率的进行测试，开发组的测试和外部测试之间的区别和协调，测试在端到端的整个开发过程中的布局与充分性。我们的误区是对这些问题在相当长的时间以后才逐渐意识到这方面的缺乏，然后逐渐提出改进。
