BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

产品线工程:团队迭代及其问题

| 作者 周爱民(Aimingoo) 关注 0 他的粉丝 发布于 2007年4月9日. 估计阅读时间: 15 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

问题

项目到了末期,总是长期、持续的维护。这种维护的工作甚至占到了整个周期的三分之二以上。而维护工作过程中会发生什么,是少有人讨论的,因为对于多数工程专家来说,这是在“项目结束之后”的事件。

在我看来,维护周期的产出有一种可能:后续版本。这种情况大多数会出现在自主研发的产品上;源于客户需求,也会出现在一些面向客户的项目中。此外,基于客户项目的产品化,也是可能的输出。

这些输出的共同点是:没有改变项目的实质,而是对项目的延续或者完善。因此,客户项目的产品化也可以视为新版本,产品从技术研发到市场化也可以视为新版本。总之,项目的阶段性结束和持续维护,并不等于走向死亡,而可能是新版本的开始。这种过程如下图所示



该图很明显的表达了一种工程观点:V2与V1在两个不同的项目阶段中。这看起来很合理,甚至在实践中也常常这样做。但上图中潜在的问题是:如果维护工作的周期延长,则V2与维护存在资源争用。下图进一步描述这种可能性:



当出现这种资源争用的局面时,公司比较明智的做法,当然是强化维护工作,而延缓V2开发的启动。因为如果不维护,则会导致客户不满而流失既有市场,或因产品功能不完备而导致市场化受阻。

但是,我们不能直接通过持续维护的旧版本来产生新版本——后者应该是一个完整的、有独立性的产品。当资源争用出现时,公司的短期行为与产品的长期策略就不可避免的存在冲突。就我所知的,冲突的结果往往是:
  • 旧版本得以维护,客户被短期满足;然后,  
  • 新版本的启动受阻,因此研发周期延后;然后,  
  • 同类产品竞争力加强,客户流失;然后,  
  • 新版本匆忙发布,功能与稳定性受到影响,客户流失加剧;然后,  
  • 产品线收益下降,团队萎缩,新旧版本都陷于维护,失去了更新版本的研发能力。
  • 这种局面下,整个产品线便已经死亡了。而其根源,正是在于面临强大的市场压力时,旧版本交付与新版本启动过程占用了较多的时间,导致战略推进受阻。

    如果一个公司有充足的资源,这可能不成其为问题。例如新、旧版本一旦可以用同等或渐增的规模来运作,或新版本不需要依赖于旧版本的资源(如人力和代码分支)。但大多数公司不会拥有这样充备、甚至是冗余的资源。
    此外,在一些存在准入制度的,或者垄断的市场中,这也不成为问题。因为客户与开发商都是确定的,客户甚至愿意提供更多时间来保障旧版本的上线和投入实用。

    除了上述情况,大多数时候我们都会为“下一个版本如何启动”的问题所困扰。而传统的工程模型中,并不讨论这个问题——产品的延续性会在项目可行性分析和公司战略层被讨论,但在“一个项目”被实施的过程中并不会被考虑。

    本文假设需要两个团队来完成新、旧版本的更迭,并基于基本的工程原理,尝试通过组织方法与管理艺术来最小化这个过程的开销。并简单地说明“团队迭代”这种工程模式的原理、优势与问题。

    项目基本过程的分解

    RUP统一过程很好地解释了单个项目的各个阶段中,在客观上需要的资源投入情况。下面我们从设计者与实现者的两个角度来分析一下它:



    对于业务建模、需求、分析与设计工作来说,在项目的先启与精化阶段,需要设计者(包括分析、设计和架构等)的大量参与;在构建阶段开始后,需求被(相对地)固化,而设计的调整也渐趋减少,而开发资源逐渐增加。直到后来,开发团队必然发现设计师、架构师和需求(用户)对他们指手划脚的时间越来越少,而测试团队却更深地影响着他们的开发计划——实施过程、测试过程等在不停的迭代,但计划与设计基本不变化。

    一般来说,我们的大多数团队的人力资源用在“实现(编码)”,并以相对独立的团队来完成“设计”与“测试”。而这些团队的工作周期用工作量并不是一致的。以致于《人月神话》的作者会问:“在等待时,实现人员应该做什么?”

    《人月神话》假设了一个“10个设计师、150人的开发团队”规模的项目。在这个项目中,程序经理提出了一个问题:体系结构团队需要10个月完成计划与设计,而他的150人却因此“只能坐在那儿干等10个月”。

    Brooks提出的解决之道是“在(设计)说明完成的时候,才雇用编程实现人员”。当然,这是在三十年前的说法,大概会因此有人说这是“瀑布”的遗迹。但通过我们上面的分析,我们也应发现在客观事实上,先启、精化阶段与构建阶段所需要的人力资源的配比并不相同。以本例中的开发团队来说,在最初的10个月中,大概只需要8~20个开发人员参与到实现过程即可。

    因此问题的本质并没有发生变化:在等待时,(剩下的130个)实现人员应该做什么?

    然而接下来你也会发现,这个问题换个环境依然成立:在实现时,设计人员应该做什么?因为在构建阶段中,大多数的项目资源被消耗在实现和测试的循环里面,而构架、设计和需求存在(在项目周期中的)一致性,因此这些相关的设计、分析人员便处于“等待”状态。

    基本定义

    “10个设计师、150人的开发团队”,在总长度为3年的时间内,总是存在资源被空耗。Brooks对此的建议被推而广的结果是:在前期雇一批设计师,并在后期解散他们;对编程实现人员则反之。

    我们应该认识到:这样反覆的组织结构,在一个公司来说是难于成为现实的。但是,对于以“职责分配”作为组织建构的基本原则的软件公司来说,我们可以给出一个简单的“AB团队模型”,并象下面这样看待问题:
  • A团队以实现为主,在初期需要“设计工作”的引导并确定方向;
  • B团队以设计为主,在设计的后期逐渐引入“实现工作”。
  • 可见这两个团队对人力和时间的需求都将出现交叉。这种交叉会带来一种微妙的平衡。如下图所示:



    这就是所谓的“团队迭代”。他讨论的不是A或B团队的具体工程方法,而是A和B团队出现重叠的这段时间里的工程方法。准确地说,就是这张图中B线和V2线所界定的时间区间中的工程方法。这两条线的基本定义是指:
  • B线:B团队发起并从A团队开始争用富余资源的时间;
  • V2线:B团队与A团队结束资源争用的时间。
  • 组织的基本原则

    我们现将面临一个问题,这个问题首先是与上面的这个“V2线”的名称有关。因为我们需要确定A、B两个团队的关系与组织模式。

    之所以叫“V2线”,是因为我们必须确定B团队与A团队的工作目标,是在同一产品方面上的不同阶段。也就是说,B团队是在为A团队的后续版本而工作。如果没有这个前提,那么A、B的资源争用就是纯粹的战略方向之争,并不是工程方法所能解决的问题。

    对于A、B两个团队的规模来说,A团队是当前目标的实现团队,因此所占用的资源(包括人力和管理资源)较多;B团队是将来目标的设计团队,因此所占用的资源较少且不紧急。从这两个团队的自身特点来说,A团队适合于用强化管理并使用里程碑方式来固化阶段成果,而B团队则适合以技术方式来领导。
    这如同Brooks在《人月神话》中所设定的两种组织模型:产品负责人(项目经理)作为总指挥,技术主管充当其左右手;或反之。第一种模型是职权型的项目经理,这适合于大型和以产品为目标的团队(例如A团队);而第二种模型则是辅助型的项目经理,由于是技术主管引导整个团队,因此更适合于以计划、分析和设计为主的团队(例如B团队)。

    因此,在A、B团队中的组织与分工都是不同。虽然同样要求管理艺术,但A团队严谨些,B团队则更富有创意与激情。正是由于AB团队模型内部是互补的,而且在管理职责上,是同一产品上的自然延续,因此可以有效地避免管理和组织冲突。

    T线

    组织结构中不存在职权冲突,并不等于不存在矛盾。AB团队模型与生俱来的问题就是“资源争用”。

    在初起阶段,B线开始时,A团队中正好有部分人员(例如架构师)只需要投入较少的工作量,而他们正好在B团队所需的主要成员。在这时创建B团队,并不会感到太明显的资源争用。

    然而B团队不可能总在“不停的计划和分析”,它必然要从A团队汲取资源,来完成设计阶段的实现、测试等工作。这个过程中发生的主要事件是“人力置换”,我们把它的起点位置称为“T线”。如下图所示:



    由于A、B团队是同一项目的后续版本,因此当B团队出现的人力需求,是可以由A团队的富余人力来弥补的。——事实上正是如此,当B团队需要引入设计人员来组建时,A团队正好设计人员过剩;当B团队开始需要开发人员来实现时,A团队正好进入维护周期,开发人员会出现过剩。B团队从设计过程向实施过程完成过渡的同时,也就完成了从A团队吸纳人力的过程。

    因此当B团队结束(开发型)项目团队的建设(或称为转变)的过程时,A团队也将进入项目的最终维护期。这个时候,最空闲的人力将是项目经理(事实A团队已经没剩下多少开发力量)。而B团队正好缺乏一个有实施经验的项目经理来驱动下一个阶段的工作。——换而言之,A团队的经理正好是B团队所需要的那个。

    现在,对于A团队的经理来说,他在事实上持续地领导了相同项目前后两个版本的开发。而且开发人员在较大的程度上也是一致的。——可能由于项目的扩大,B团队还需要对外吸纳更多的人员,但骨干一定还是从A团队中迁移过来的部分。

    优势

    很明显,B团队快速地启动了V2项目,为产品的后续版本的开发活动赢得了充分的时间。在T线到V2线的时间里,将会有良好的分析、设计和团队组织与培训。由于人员基础上来自A团队,他们也会乐于提出问题,并在新版本中解决这些旧问题。

    接下来,我们利用了人力。无论在哪个时间段内,人力都得到最充分的利用,A团队所富余的,正是B团队立时所需的。

    最后,我们解决了Brooks的问题:在等待时,实现人员应该做什么?其实这个问题的根本于“等待”而不是“做什么”。我们应该问:为什么会有等待?显然,如果没有等待,那么我们的开发人员自然知道他该做什么。

    团队迭代模式通过争用来消除了等待,使“等待时做什么”的问题变成了“如何平衡资源争用”。对于Brooks的原始问题,Brooks的答案是对的,但同时要付出“项目周期”的代价。而对于新的“平衡资源”的问题,我们在工程过程对资源的客观需求中找到了平衡点。通过在B线、T线和V2线之间合理地调配资源、分配管理职权和设定阶段目标,我们能够用灵活的管理技术和组织模式,来换得了更好的构架一致性、产品(线)延续性、团队的稳定性和(最重要的)更短的迭代周期。

    冲突及其平衡

    如果我们真的有两个团队或更大规模的团队资源,那么基于项目的迭代是不必须的。事实上,在一些公司里采用多个团队竞争的法则,从而得到新的版本或团队。但这些是以充备的资源为前提的,而且也无法避开向下兼容的问题。

    而本文中的AB团队模型是强调合作的,两个团队一定是围绕相同的目标和设计在工作(因此必须一再提醒的是,如同《人月神话》中强调的一样:要保持设计的一致性)。如果这个前提不能被保证,那么AB团队模型无法消减其内部的冲突。

    综合地来考虑,下列的因素是对团队迭代有害的:团队竞争、组织臃肿和不明确的产品线计划。

    除了上述这些先期的可控因素之外,在项目过程中,我们还必须面临一些其它问题。
    首先需要找到最好的切入点:B线。太早的话,A团队会因为受到太大的伤害而溃败;太晚则又牺牲了更多的时间,从而可能失去团队迭代的价值。

    接下来,对于A团队的经理,从B线开始他将面临两种考验。第一个考验是立即到来的:他的团队可能变得有些混乱,因为部分人员开始面临两个项目的问题,一些人员会开小差,不知所措,另一些人员可能已经打好了铺盖卷。而从T线开始,A团队的经理迎来另一个考验:他必须要在人员逐渐流失的情况下控制好整个的团队。这个考验是最严峻的,因为A团队的经理如果控制不好团队的运作,那么项目可能不能保证市场化或满足用户需求。

    最后的,也是最关键的问题:工程人员的素质。无论是现在,还是将来,应用“基于项目的迭代”这样的模型,都要求:
  • 两个团队的负责人有良好的素质,他们围绕相同的目标在同共努力,而不是当前的具体工作,或阶段性的利益而争夺;
  • 需要认识到在于B线-T线和T线-V2线这两个阶段中,所置换的人员的特性是不一样的。前者偏向设计与分析,后者着重实现能力;
  • 两个团队的成员有良好的工程态度(不一定是经验),能理解团队结构变化的目的,以及乐于接受改变,接受新的工作。

  • 作者简介

    周爱民(aimingoo)是国内软件开发界中资深的软件工程师,自1997年以来,历任部门负责人、软件部经理、区域总经理等职,在软件开发、软件工程、团队建设以及部门管理方面经验丰富。关注于软件工程、体系架构和项目团队的模式和实施。周爱民先生是Borland Delphi产品技术专家,也是Qomo开源项目(JavaScript)的发起者,现任上海盛大网络任平台架构师,是《程序员》杂志的特约专家顾问。曾被Borland公司授予“Borland Delphi产品专家”和“论坛特别贡献奖”称号。另外他还是《Delphi源码分析》《大道至简——软件工程实践者的思想》的作者。他的博客是http://blog.csdn.net/aimingoo,可以通过aim AT 263.net和他联系。

    评价本文

    专业度
    风格

    您好,朋友!

    您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

    获得来自InfoQ的更多体验。

    告诉我们您的想法

    允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

    当有人回复此评论时请E-mail通知我
    社区评论

    允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

    当有人回复此评论时请E-mail通知我

    允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

    当有人回复此评论时请E-mail通知我

    讨论

    登陆InfoQ,与你最关心的话题互动。


    找回密码....

    Follow

    关注你最喜爱的话题和作者

    快速浏览网站内你所感兴趣话题的精选内容。

    Like

    内容自由定制

    选择想要阅读的主题和喜爱的作者定制自己的新闻源。

    Notifications

    获取更新

    设置通知机制以获取内容更新对您而言是否重要

    BT