• 从小到大的故事 : CwP项目演进

    2010-11-07

    分类:咨询之道

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/skysw-logs/82636879.html

    收到 CwP项目演进 的 feedback,说写的完全是 “笔记体”,没有类似项目背景的话,根本看不懂;于是重写一篇 “继承” 自 CwP项目演进(这句可以跳过),从人数作为横作标来讨论下项目演进的过程,下文简称 “演进”;话不多说,进入正文;

     

    Evolution:

    10+ people; (这时还未在项目,内容属于道听途说,仅供参考)

    是个 .Net 平台,公司很多 senior 的技术人员投入到了这个项目;

    负责项目启动阶段(Quick start)的几位同事相继离职,别的项目也存在;

    客户很严厉,组里的天天加班,中午到点都没有人去吃饭,经常返工;

    Retro(参见文末 *)没什么人发言,Agile 有些原则被打破(在需求不定情况下开发);

    客户面对陌生的 team,没有安全感,对于团队完全不信任;

    不能划分出高优先级,基础性功能,风险高模块首先开发(没有引导好客户);

    反而纠缠在无关紧要的细节上,团队的很多投入却看不到明显成效;

    “如果没有 direction,就必然被 push”

    于是:

    大家都在再努力;

    rule 层面上,agile development 所要面对的第一个问题;

    参见“演进”中的 1. Stand up Meeting 迟到怎么办?

     

    20+ people;

    Release 1 顺利发布,客户看到了产品,得到了信心,在一些问题上可以 negotiate;

    开始逐渐能够听进去一些建议,一些繁重的不可能完成开发任务被推迟了开发;

    又加人了(我也来了);

    没有任何一个人熟悉系统每个地方的设计,代码;

    当开发过程中存在疑问时候,不知道找谁去讨论;

    分到新的开发任务时,学习成本太高,开发效率低;

    层次化的设计已经开始把系统摊成了一张太大的饼;

    提交代码开始变得混乱,持续集成出现问题没人修复;

    代码质量存在问题,很多诡异的 code 出现;

    于是:

    feature 层面上,划分出了 folder;每个 folder 指定了 owner 和 backup owner;

    参见“演进”中的 5. Feature Folder & Owner:

    code 层面上,开始了 model 切分,通过减少模块间的代码复用,从而降低耦合;

    参见“演进”中的 7. 代码组织结构:

    communication 层面上,从多点到“客户接口”的转变;由少数人负责回复 & 转达;

    rule 层面上,small process 必须要坚持!一些原本靠自觉遵守标准被严格规定下来;

    参见“演进”中的 2. Story 开发过程,3. Check in 过程;4. Code Review,8. Retro;

     

    30+ people;

    在一些列的标准被明确之后,team 的工作又开始找到节奏;

    持续集成工具 Cruise 绿的时候多乐,按部就班的出 package;

    folder owner role out & in,大家通过 session share knowledge;

    完成 核心模块1 的 Redesign,并且 release 2,3 接连完成;

    这时又加人了;

    这一次感觉有什么地方不对劲了!

    我们没有持续信心的来源; -- 不了解有多少任务,完成了多少;

    我们没有纠正错误的机会; -- retro 讨论的和我无关,和我有关的都不讨论;

    我们在讨论和我们无关紧要的问题; -- retro 时候都在讨论永远没有定论的问题;

    我们感觉不到身边的人的改变; -- 散漫,投入不够开始逐渐出现;

    我们身边的人开始变得陌生叫不上名字; -- 早上晨会 stand up,看着眼熟,叫不上来;

    需要完成 核心模块2 的 Redesign;

    需要完成与第三方开发团队的集成工作;

    于是:

    code 层面上,开始分拆 solution;xq 贡献出了分别编译各个工程的 yam “爷们” 脚本;

    参见“演进”中的:6. 工程结构组织;

    organization 层面上,针对各个上线目标划分出了 3 个小组,开始回归小团队;

    参见“演进”中的:11. 划分 Work Stream:

     

    40+ people;

    现在虽然 team 有 40 多号人,虽然基本还是有进无出,但大家又重新回归了小团队;

    同时核心模块2 的 Redesign 开始了,所有人搬到了一张桌子上;

    然后就是计划、开发、验收,一切都在变得有序;

    每个环节都会 Evolve 组内多一些人参与,让大家多一些背景上的了解;

    两次 Retro,踊跃的发言经常是按都按不住(包括老人新人),充分反映了 team 的状态;

    但是 “一旦你消除了你的头号问题,第二号问题就会升级”,新的问题又浮现了;

    并行子项目,彼此之间出现问题,冲突如何去解决?彼此之间的协作,讨论如何更加有效;

    比如轮流提交代码的问题,在团队变成分布式之后,变得突出,一些规则亟待修改;

    于是:

    communication 层面上;

    lunch Session,大团队实在是很少机会能把所有的人聚到一起,这是个不错的机会;

    其实可以考虑的还有 3 work stream share stand up meeting;

     

    50+ people?

    项目还在继续,一切皆有可能!


    团队的由小到大,然后再由大到小;几番起落,几份感触;当大家都在说 “小团队可以,但是一到大团队,人一多,各种实践都很难实施!”,“很多小团队的实践到了大团队就不奏效了!”,“敏捷在大项目、大团队上很难成功” 的时候,可曾想过是背后的根本原因究竟是什么?在 团队理想 篇里,将会和大家讨论;

     

    * Retrospective (Retro) 是 team 在一个 iteration 结束后开的回顾会议;

    分享到: