陈勇的博客 - Scrum 敏捷开发培训咨询，绩效管理，团队管理，《火星人敏捷开发手册》

这是敏捷开发团队管理系列的第三篇。（之一，之二，之三，之四）测试团队的价值这样看来，敏捷开发的质量保证问题，都被发开团队解决了，测试团队的价值何在？这个可以从第一个项目组后来的发展来分析。在整个程序团队大力保证产品质量的同时，项目组也一点点显露出一些问题。比如每个模块的质量都还不错（有些模块甚至有一些原始的自动单元测试脚本，每次都能对模块进行回归测试），但是整个产品最终集成后，是否能如期完成业务要

这是敏捷开发团队管理系列的第二篇。（之一，之二，之三，之四）之前的各个系列中，已经涉及了很多团队管理相关的内容，比如松结对编程系列中提到过大型团队分拆为微观开发团队的管理，产品管理系列中提到过Product Owner团队的管理，敏捷开发绩效管理系列中提到过“用中医理论管理团队”，敏捷开发般若敏捷系列中提到过借助“无我、无人、无众生”的概念凝聚不同团队的目标于一处，等等。本系列会专门从团队管理的角

这是敏捷开发团队管理系列的第二篇。（之一，之二，之三，之四）几个真实案例这几个团队都是我自己亲身经历的团队，从质量的角度来分析敏捷团队的工作方式。第一个是一个较为大型的团队，约有25～30人，研发一个单一产品。这个团队在一年半的时间里边，从5个人成长为25人，其中有一半人员来自刚毕业不到半年的本科或硕士（在2001年，还很难找到“有10年经验的编程人员”）；在这个团队拥有25名成员的时候，只有1～

这是敏捷开发团队管理系列的第四篇。（之一，之二，之三，之四）整体上有两种测试团队的模型，既然都有存在，自然是各有各的道理。城里城外的人倒不必互相羡慕，只是要观察对面的优点，分析自己的缺点，尝试做点事情补偿一下。所以，下面多说一点各自的坏处。独立的测试团队这个就是著名的与程序团队打架的测试团队。好处独立团队，还是能保证一定的“公正性”的，比如在测试的最终，横竖有人能不屈从于程序团队的要求隐瞒产品质量

本文是团队管理系列的第五篇，也是“松结对编程”系列的第九篇。（团队管理栏目目录，松结对编程栏目目录）抱歉在这次MPD上不知道中间的20分钟茶歇也在3小时内，所以最后有10分钟左右的内容没有讲，这里补充一下。大型团队的切分如果团队大到一定程度，比如40人，那么怎样切分团队最好呢？答案是纵向切分，就是按产品而非按职能切分，也就是事业部化，而非开发-测试-支持这样划分。原因大致如此：1. 纵向切分的团队

这是敏捷开发团队管理系列的第八篇（团队管理栏目目录）。还是敏捷开发一千零一问的第二十八篇（在这里提问，之一，之二，之三，问题总目录）。还是敏捷开发松结对编程系列的第十三篇（松结对编程栏目目录），与之前系列第六篇139团队、第九篇微软TechED上的讲座有密切关系。问题大致问题：若人数在30人左右开发一个产品，里边的子系统数量比较多，每个子系统都有各自的发布计划，而又要协调。如果作为一个团队管理，人