敏捷实践的七个方面

敏捷实践的七个方面

royals 发表于2012-02-18 10:48

作者来自于诺基亚西门子网络杭州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。

• 最新讨论

写好啦，发布评论

小贴士：
1. 类似"顶"、"沙发"之类没有营养的文字，对勤劳贡献的楼主来说是令人沮丧的反馈信息。
2. 提问之前请再仔细看一遍楼主的说明，或许是您遗漏了。