[原]敏捷开发团队管理系列之七：大型研发管理团队的切分（二）
- - 陈勇的博客 - Scrum 敏捷开发培训咨询，绩效管理，团队管理，《火星人敏捷开发手册》这是敏捷开发团队管理系列的第八篇（ 团队管理栏目目录）. 还是敏捷开发一千零一问的第二十八篇（ 在这里提问， 之一， 之二， 之三， 问题总目录）. 还是敏捷开发松结对编程系列的第十三篇（ 松结对编程栏目目录），与之前系列 第六篇139团队、 第九篇微软TechED上的讲座有密切关系.
[原]敏捷开发团队管理系列之七：大型研发管理团队的切分（二）
标签：
| 发表时间：2012-11-20 12:10 | 作者：cheny_com
出处：http://blog.csdn.net/cheny_com
这是敏捷开发团队管理系列的第八篇（ 团队管理栏目目录）。
还是敏捷开发一千零一问的第二十八篇（ 在这里提问， 之一， 之二， 之三， 问题总目录）。
还是敏捷开发松结对编程系列的第十三篇（ 松结对编程栏目目录），与之前系列 第六篇139团队、 第九篇微软TechED上的讲座有密切关系。
问题
大致问题：若人数在30人左右开发一个产品，里边的子系统数量比较多，每个子系统都有各自的发布计划，而又要协调。
如果作为一个团队管理，人数会太多；分解为多个项目，协调又麻烦，如何处理？
分析与方案
这个问题很难有普遍适应的方法来处理，我结合之前自己做过的项目来说说。
由于大型团队很难见到太成功复制的，所以不要尝试简单对号入座，请理解背后的管理理念。
1. 不要做太大型的单一团队
这个坏处好理解，不多说了。
实际上，即使在10人左右的团队，若组长仍然自己要做技术工作的，都可能形成无人管理的团队。
由于缺少沟通、互助，外加人员工作量分配很难均衡，常常因为个体的进度和质量耽误整体的进度和质量。
2. 不要行政性地分解团队
这个很容易让小组形成自己的“利益”，比如如果大组想临时抽调一些人出来，小组长会不同意。日后工作会越来越难以开展。
比较好的做法是技术和小组管理上让小组长负责起来，但大组长仍然要保留对小组关于的权利，且要习惯性地让某些程序员临时调动一下工作。
大家一定看得出来，1和2很难操作，很难把握“度”，但我们当年的确做到过。
实际上当年我们最容易互相“临时调动”的，居然是小组长，就是临时让小组长帮别的组做点事情。
一方面，由于这些人都是高手，别的组一般都特别欢迎；另一方面，各小组长对自己的工作内容一般都有点“厌倦”了，他们对别的小组的工作兴趣大于普通的组员。
这些经常能帮助其他组的人在整个团队中的地位很高，即使发给他们很高的薪水，别人也不会嫉妒（因为他们也从帮助中受益了）。
这算是一种很强的激励和绩效管理方法，也会吸引别的小组长加入。
3. 核心会议
大组长+小组长要经常协调开会，我们当年是25～32个人的组，每周一次会议。
最开始只有4个人参加，后来扩展到8个人，包括了2个非小组长但也是研发骨干的。
其实这种会议经常是“扩大会议”，取决于最近在干什么。
4. 开放办公室
千万不要因为小组分好了，还有核心会议可以沟通，就可以让大家分开坐了！
虽然我们从来没有尝试过把大团队从坐在一起改为分开坐，看看会发生什么（因为不敢，呵呵），但我们尝试过让大团队坐在一个开放空间（即使有隔断，也要宽松点，不要搞院墙），还尝试过把分开的团队改为坐在一起。后两者的效果都很好。
一个意外的收获是，坐在一起的团队关系会很好维护，在提供或寻求帮助的时候，人们更愿意与一些天天在一起工作、吃饭的人交流，而不愿意仅仅因为技术或业务的需要与陌生人合作。
不过，无论如何，大型团队的管理都很困难，虽然有些方法相当有效（比如上面介绍的方法，我都亲眼见证其效果），但做起来又很难。
别人的经验距离自己的实践总是很有距离，这个距离中间还阻挡着很多障碍。在真正尝试前，这些困难常常显得不可跨越。
不过正是因为如此，管理才是一个值得探讨的话题，成功的管理者也才变成受人尊敬和推崇的人。
所以，不要被现在看到的难题吓倒。
如果您有任何补充问题，请在下面评论中补充，我会重新编辑或增加要点。谢谢参与。
作者：cheny_com 发表于2012-11-20 12:10:25 原文链接
阅读：891 评论：0 查看评论
相关 [敏捷开发 团队管理 系列] 推荐：
团队管理101招
- 狂之想 - C++博客-牵着老婆满街逛转载自：http://www.iteer.net/modules/doc/article.php?storyid=1402. 无论你是新手还是资深管理人，对你而言，管理好团队都是重要且具激励性的挑战. 切记：每位成员都能为团队作出一些贡献. 谨慎地设定团队目标，且认真严肃地对待它们. 尽早决定何种形态的团队适合你的目标.
敏捷开发——Programmers（27）
- plidezus - 西乔的九卦载于《程序员》杂志2011年第7期. 从这一期起，开始在杂志上登出整P的大幅漫画，需要看大图的同学们，讯猛点击下图. 这个系列的漫画讲述程序员——这种神秘人类的囧事，故事多来源于我身边的程序员朋友,且以互联网开发背景为主. 如果你有什么可乐的关于程序员的故事、对话、代码，愿意通过漫画的形式分享，请给我发邮件.
漫谈敏捷开发
- scotty - ITeye论坛最新讨论软件开发是一种非零和博弈，意思是某一方的获得不是建立在另一方的损失之上，所以软件开发必须实现双赢，帮助客户成功的同时帮助自己成功. 如：通过软件帮助客户把手上的5块钱变成50块钱，然后从客户那里拿5块钱. 通过软件帮助客户节约50块钱，然后从客户那里拿5块钱. 传统的汽车制造是以计划驱动，如根据往年的经验判断今年应该生产多少汽车，但是这样带来的问题是有可能等汽车生产出来，市场已经不需要了，而这就是一种极大的浪费.
[趣图]敏捷开发:Programmers
- FPb - 草根网载于《程序员》杂志2011年第7期. 从这一期起，开始在杂志上登出整P的大幅漫画，需要看大图的同学们，讯猛点击下图. 这个系列的漫画讲述程序员——这种神秘人类的囧事，故事多来源于我身边的程序员朋友,且以互联网开发背景为主. 如果你有什么可乐的关于程序员的故事、对话、代码，愿意通过漫画的形式分享，请给我发邮件.
关于敏捷开发（Scrum）
- - 前端攻城师-攻城记敏捷开发的话题已经由来已久，但是我们如何实施敏捷开发一直成为争结. 很多团队协作性差，产品、技术、测试、运营脱节，我们如何解决这些问题，成为了很多团队面临的问题. 有幸接触到Scrum项目管理，我想如果我们真的把Scrum实施起来，协作一定会上一个层次. 1.一切从产品出发 我一直信奉一个出色的产品经理不应该因为种种原因降低产品质量，不要因为技术难度大，不要因为项目时间紧，不要因为人员不足，领导压力，其实产品要说的就是：“喔.
Android敏捷开发指南
- - 互联网的那点事本文紧密结合移动开发方法与技术，围绕Android平台的开发探讨提供更高质量移动产品的解决方案. 作者中分析了移动开发中常见的问题，从两方面阐述了ThoughtWorks使用的测试开发方案和相应的架构方法与常用工具应用，并进一步阐述了为移动开发流程所提供的持续发布方案. 随着云计算、移动互联等一系列新技术概念的崛起，新一轮的IT经济正在不断扩大发展.
Scrum敏捷开发简介
- - CSDN博客编程语言推荐文章 Scrum是一种灵活的敏捷软件开发管理过程. Scrum方法由Ken Schwaber和 Jeff Sutherland 提出，它将软件开发团队比作橄榄球队，全队有明确的最高目标：发布产品的重要性高于一切. 团队高度自治，队员们熟悉开发过程中涉及到的各种技术，紧密合作，确保每个迭代都朝着最高目标推进.
敏捷开发 Scrum 总结
- - 行业应用 - ITeye博客 最近把之前学习 Scrum 的资料整理为一篇文档，在接下来的团队和项目开发中，根据项目的情况引入 Scrum 的一些实践，提高团队成员之间的协作能力和项目的交付质量. 参考资料：. 《轻松Scrum之旅—敏捷开发故事》、《敏捷无敌》. Scrum 工具.
小团队管理与大团队管理
- -如有好文章投稿，请点击 → 这里了解详情. 我们公司和大部分传统软件公司一样，随着业务的发展和新领域的开拓，公司的管理风格越来越像华为，这是不是最佳的演进路线，我觉得值得探讨，以下是我的思考，希望跟大家讨论. 前段时间跟一个创业的朋友聊天，说起他们最近在做的一个项目，这是一个教育行业的管理系统，业务非常复杂，牵涉到的决策人，需要对接的系统也非常多，最后问到他们做了多久完成这个项目，朋友告诉我2个多月，6个人，其中还括一个美工，一个项目经理；剩下的都是开发人员，没有测试，没有前端开发；朋友问我，如果这个项目给你们做，你们需要做多久；我想了想说，这个项目如果交给我们做，顺利的话，至少要半年.