摘要：本文是团队管理系列的第五篇，也是“松结对编程”系列的第九篇。（团队管理栏目目录，松结对编程栏目目录）抱歉在这次MPD上不知道中间的20分钟茶歇也在3小时内，所以最后有10分钟左右的内容没有讲，这里补充一下。大型团队的切分如果团队大到一定程度，比如40人，那么怎样切分团队最好呢？答案是纵向切分，就是按产品而非按职能切分，也就是事业部化，而非开发-测试-支持这样划分。原因大致如此：1. 纵向切分的团队之间不会有直接竞争、对抗关系，避免了各种对抗和办公室斗争。2. 纵向切分的团队内部目标清晰，都是为了事业部的盈利，责任分工、利益分配更容易。当然这会带来一些其它问题，比如：资源共用，新产品线和产品的孵 阅读全文

摘要：这是敏捷开发团队管理系列的第四篇。（之一，之二，之三，之四）整体上有两种测试团队的模型，既然都有存在，自然是各有各的道理。城里城外的人倒不必互相羡慕，只是要观察对面的优点，分析自己的缺点，尝试做点事情补偿一下。所以，下面多说一点各自的坏处。独立的测试团队这个就是著名的与程序团队打架的测试团队。好处独立团队，还是能保证一定的“公正性”的，比如在测试的最终，横竖有人能不屈从于程序团队的要求隐瞒产品质量，而是的确会客观地评价质量。坏处当测试团队完全独立于开发团队的时候，常常有几个误区。1. 程序团队是用来开发功能的，测试团队是用来查找缺陷的有了这个认识，要让两者打架就不难了。2. 更多的测试人员=更 阅读全文

摘要：这是敏捷开发团队管理系列的第三篇。（之一，之二，之三，之四）测试团队的价值这样看来，敏捷开发的质量保证问题，都被发开团队解决了，测试团队的价值何在？这个可以从第一个项目组后来的发展来分析。在整个程序团队大力保证产品质量的同时，项目组也一点点显露出一些问题。比如每个模块的质量都还不错（有些模块甚至有一些原始的自动单元测试脚本，每次都能对模块进行回归测试），但是整个产品最终集成后，是否能如期完成业务要求，却是未知的。因为各个模块的测试都集中在各模块的质量上，对于所有模块凑在一起的工作结果，却无法验证。而且在原来的团队体系下，师徒团队各自负责一个模块，居然没有人为此负责。所以我们很需要一个人来团队里 阅读全文

摘要：这是敏捷开发团队管理系列的第二篇。（之一，之二，之三，之四）几个真实案例这几个团队都是我自己亲身经历的团队，从质量的角度来分析敏捷团队的工作方式。第一个是一个较为大型的团队，约有25～30人，研发一个单一产品。这个团队在一年半的时间里边，从5个人成长为25人，其中有一半人员来自刚毕业不到半年的本科或硕士（在2001年，还很难找到“有10年经验的编程人员”）；在这个团队拥有25名成员的时候，只有1～2个测试人员。按一般的常理而言，这个产品应该面临很大的质量问题，因为这些新来者应该编写大量的缺陷，而测试人员又严重不足，不足以发现这些缺陷。但实际情况是，这个产品是我后来经历的所有大型团队中最好的一个 阅读全文

摘要：这是敏捷开发团队管理系列的第二篇。（之一，之二，之三，之四）之前的各个系列中，已经涉及了很多团队管理相关的内容，比如松结对编程系列中提到过大型团队分拆为微观开发团队的管理，产品管理系列中提到过Product Owner团队的管理，敏捷开发绩效管理系列中提到过“用中医理论管理团队”，敏捷开发般若敏捷系列中提到过借助“无我、无人、无众生”的概念凝聚不同团队的目标于一处，等等。本系列会专门从团队管理的角度，一方面将曾经提到过的内容加以贯穿，另一方面则会提及之外的一些未提及的内容，比如产品团队与开发团队的互动，测试团队与开发团队的关系与工作方式，等等，以供专门从事团队管理的读者借鉴。出发点：结果导向敏 阅读全文