[原]敏捷开发团队管理系列之七:大型研发管理团队的切分(二)

标签: | 发表时间: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 查看评论

相关 [敏捷开发 团队管理 系列] 推荐:

[原]敏捷开发团队管理系列之七:大型研发管理团队的切分(二)

- - 陈勇的博客 - Scrum 敏捷开发培训咨询,绩效管理,团队管理,《火星人敏捷开发手册》
这是敏捷开发团队管理系列的第八篇( 团队管理栏目目录). 还是敏捷开发一千零一问的第二十八篇( 在这里提问, 之一, 之二, 之三, 问题总目录). 还是敏捷开发松结对编程系列的第十三篇( 松结对编程栏目目录),与之前系列 第六篇139团队、 第九篇微软TechED上的讲座有密切关系.

团队管理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个人,其中还括一个美工,一个项目经理;剩下的都是开发人员,没有测试,没有前端开发;朋友问我,如果这个项目给你们做,你们需要做多久;我想了想说,这个项目如果交给我们做,顺利的话,至少要半年.