艾伟也谈项目管理,技术领导的疑难:如何掌控其他成员的开发

  如何将项目的开发掌控好是技术领导(Team Leader)必须做好的。何为掌控项目的开发,即开发的进度和质量在计划内,不在期限快到时慌手慌脚,也不需交期到时天天加班,更不能删减测试时间。总而言之,就是开发工作有节奏,按部就班到达预期目标。

  理想总是好的,可现实总是残酷的。你有过每个周六都加班,每晚都加班的经历没?你有项目完不成,接二连三申请延期发布的经历没?你有过遇见过你委以重任,但他却误了你事的同僚没?如果你工作了一段时间,又恰好又有带过小队伍的经历。我想你应该也遇到过这些问题中的一个或几个吧。

  我当然也遇到过,一回是将一个很重要的功能组件重写的任务分派给一个新的团队成员,给予了我能给的最多资源,并将其他任何任务,可能的干扰源我都给挡了。但结果呢,开始我还满怀希望,因为他非常自信,也不断的给我好消息,比计划更快更好。但时间过去一半也就是约两个月后,痛苦开始来了,他创建了一个新的分支,因为接口变了,无法和其他组件集成构建,而这一切我之前竟然不知道。但离版本发布已经只有2个月时间了。这还包括测试。而该模块功能上都还只完成一半的样子,而且完全抛弃了原有做法。更惨痛的是两个星期后他离职了,面对不能集成,功能不全的半成品真是欲哭无泪。最后版本发布时,此过程中代码仅作参考,而使用旧代码修改版本,预期的一些功能没有,预期的效率提升没有,还加班一段时间。这也是我的软件开发历程中最大的遗憾。

  事后,我总结了该次技术事故的教训,但没有及时发贴。现在做一下简单的总结,如何避免此类事故的发生。

  一、认识问题

  在将较大的模块分配之前,必须确保模块主人明确了需求,了解了问题。很多程序员有一拿到问题立马动手的冲动,此时你至少应保证他看到了所有的问题。此步绝对不能省略,你不能假设他自己会去找需求,他能找到需求。你也应该将你对需求的认识,你从全局上的观点传递给他。

  二、搭架子

  在甩手出去的工作,尤其是较重要的模块给一个不了解的人的时候。必要的模块架构设计是不能少的,这个时候你可以了解他的思路;讨论中提升设计的质量;更重要的是可以从整体的角度评判设计是否合理,是否可以和其它模块较好的工作。同时还可以减少模块开发人员的困惑,减少独自摸索的时间。

  三、分解工作

  在架构设计的基础上,将工作分解开来,独立出来一段一段做。分解时最好和开发人员讨论,他在细节上可能会比你更清楚。

  a. 工作项的大小。从经历来看每个工作项1-2周比较妥当,时间太长不利于管理时间,也较难准确预估。太短又太细,而且有些事情又没那么容易做完做好,此外还可能涉及其他方面的修改。很多人习惯做完任务就不管了,也没有足够的时间测试,调整。

  b. 工作项的独立性。必须保证每个工作项的独立性,可以单独开发,单独集成。每一到两周将代码集成编译并做简单的集成测试(保证主体不受影响,新增功能有效)。

  四、及时跟踪设计,时间,代码

  先说设计上的跟踪,在新成员刚参与时。可以要求必要的设计文档,如类图,核心部分的序列图。再就设计与程序员讨论我们现有的设计样式,使设计与已有设计有一定的相似性。并可借此机会培养新成员的设计水平和设计方法。此讨论可以多讨论一些OO,设计模式什么的。不一定要用,但要有用的准备和用于不用的判断。

  时间上的跟踪,主要是每周的周会,周会上可以依照总的时间安排和工作进度一起简要讨论,让大家心中有底。此外还有每周的工作安排和回顾,新成员可以要求写细点,每周要有两到三个检查点,及时跟踪。出现问题可以及时发现。

  代码上的跟踪,主要是要求在最新代码上开发,保证有交互的组件可以正确编译。此外新成员要在开始一段时间对代码进行Review,保证编码符合规范。模式和已有代码一致。

  另外就已有组件的修改,可以要求逐步改进,使用桥接或其他方式逐个替换进新的模块。

  很晚了,先就想到这了,欢迎大家提出好的想法。到时我再抽时间补充完整。

时间: 2024-07-30 09:59:40

艾伟也谈项目管理,技术领导的疑难:如何掌控其他成员的开发的相关文章

艾伟也谈项目管理,利用简单的一元线性回归分析估计软件项目开发时间

引言       前两天一个朋友给我打电话,问我如何估计项目开发时间.对此我很诧异,问他以前他们是怎么估计的,他说以前基本都是大家开个会,大约都说说自己意见,最后负责人一拍脑袋,给出一个时间.不过这次遇到一个非常认真的客户,要求不但要估计出项目开发时间,还要明确说明具体的依据和估算方法,这下我这朋友有点犯难,才询问我.后来我翻阅了一些数理统计和项目估算方面的资料,告诉了他利用一元线性回归分析估计软件项目开发时间的方法.想到这种估算需要在一些开发团队很常见,所以在这里整理成文. 问题的定义及数学模

艾伟也谈项目管理,克服在企业中应用敏捷方法的技术挑战

在企业中应用敏捷方法是一项具有挑战性的任务.实现敏捷不像安装软件那样能在一天内完成.而是需要适应企业环境,其中包括:文化.技术和组织方面.本文将探讨面临的一些挑战,这些挑战与建立开发环境.自动化测试.持续集成相关,并且同在企业环境中明确完成的定义(DoD)相关. 建立开发环境 每位技术负责人和开发经理都想缩减团队成员建立开发环境的时间.然而,为了在项目中获得较高的产出,开发人员要持续投入许多精力,让事情变得有条不紊.缺乏文档,是建立开发环境时间过长的关键原因.第二个关键原因是建立过程中包含多少手

艾伟也谈项目管理,敏捷的坏态度

虽然所有软件开发的专业人士都会对这篇文章感兴趣,但是经理.CIO以及软件架构师会对它最感兴趣.这个话题可能会引起许多争议,但我写这篇文章是为了让你了解在敏捷运动中看起来正在日益增长的问题. 你为什么在这?敏捷不需要经理. 以前听过这种说法吗? 想象一下,如果你听到开发人员认为你这个职位根本就不应该存在,你会感到多么震惊,就好像是你特意为自己搞出经理这么个职位似的.这个话最常应用在项目经理第一次与将要和他一起工作的开发团队碰面的时候.的确,最初的敏捷宣言绝对没有提到项目管理,并且后来的敏捷理论家更

艾伟也谈项目管理,产品版本改造中的项目管理

近段时间,一直在负责一个产品版本改造(C/S系统进行B/S改造)的研发项目管理,在任务紧.时间短.团队成员又没有相关技术(Silverlight)背景的恶劣情况下,我带领包含我在内只有6个人员(5个研发人员,1个产品经理,产品经理在系统版本改造中主要精力投入到辅助市场部进行产品推广去了)的超小型项目团队,终于在公司给定的时间范围内完成了整个产品的版本改造.这其中经历了需求变更.技术风险.人员变动等诸多问题,项目任然取得了成功,这种使用新技术的试验项目能够取得成功不得不说有几分侥幸,更多的还是团队

艾伟也谈项目管理,对项目管理的几点认识

自2007年参加工作以来,参与的项目也有好几个了,但都是以项目成员的角色参与,从来没有以项目经理的角色参与项目.中国有句古话叫"旁观者清",同一个问题站的角度不同,可能会形成不同的结论.下面我就以一个普通项目成员的角度谈一下对项目管理的几个看法,希望大家给予指正. 1. 团队成员选择 人员选择要谨慎,要尽量选择合适的人员,在选择团队成员时要重点考虑其团队合作能力.编码可读性.能力和项目的匹配度等因素. 2. 项目远景的确定 项目初期项目经理需要和高层以及客户协商,定下项目的远景目标(即

艾伟也谈项目管理,假如我是一个项目总监/经理

就国内中小民营企业而言,项目总监/经理的角色最为尴尬.项目总监/经理不是一个行政上的title,所以没有行政.财务.人力上的权力:项目总监/经理也很少有项目提成或项目奖金:项目总监/经理更多的被视为因政治因素而临时授命的一个暂时性的英雄人物,一个能够带领一群初级工程师完成某项任务的高级技术工程师.简而言之,只有义务而缺乏权利. 在绝大多数中小民营企业中,抛开强烈的政治斗争不说,还缺乏完善的公司管理制度,缺乏正规的项目管理流程,缺乏足够的技术储备力量.所以身处民营企业这个漩涡中,需要考虑的不仅仅是

艾伟也谈项目管理,DevOps,不是一个传说!

DevOps最近成了热词,望文生义,你也能猜个八九不离十,它就是在说"研发团队"与"运维团队"之间的那点事儿.那么,到底什么是"DevOps"呢? WikiPedia上说:"DevOps是软件开发.运维和质量保证三个部门之间的沟通.协作和集成所采用的流程.方法和体系的一个集合.它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发与运维之间相互依存关系的一种新的理解."这恰好体现了精益管理中的客户价值原则,即:以客户的

艾伟也谈项目管理,五年Skype架构师之路的感言

简介 作为架构师和设计者,我们常把手头的事情作为工作焦点,很少反思过去如何.我们应该温故而知新.我从作为skype架构组领导的55 个月经历中总结了6个经验.其中一些是技术性的,另外一些是架构师较为软性的观点.首先介绍一下Skype的背景资料. Skype背景 Skype是让用户可以进行音频视频通话的软件,也可以拨打普通电话以及发送短消息.公司成立于2003年,从成立以后就有令人难以置信的成长曲线.公司现在有超过五亿两千万注册用户,大约650名员工.这些用户同时产生平均21万个通话,其中大约三分

艾伟也谈项目管理,《播客》项目总结——项目管理方面

引言:如果标题改成<被管理总结>的话,我可以滔滔不绝的说上个半天,但是如果是管理项目的话,我实在肚里的货有限,因为到至今做过的最高职位不过是个"班长"而已. 但是这次<播客>项目在管理方面的确出了问题,而且是满严重的问题,以至于到后来项目差点失控,而且最终的交付作品质量的确让人汗颜.如何避免下面程序员很累,但效率却很低:上面不停的催,产品却一个bug接一个bug,完全没法交付:项目经理累的要死,项目却仍然处于失控状态这样的问题和局面?在一个差点失控的项目刚刚结束