程序员继续招;另加讨论如下问题:在团队开发中,如何编出好代码?如何管理程序员?如何作一名好程序员?如何做出好程序? 相信专家和不迷信专家的人都可以进来讨论! (

  • 主题发起人 主题发起人 pyzfl
  • 开始时间 开始时间
P

pyzfl

Unregistered / Unconfirmed
GUEST, unregistred user!
程序员继续招;另加讨论如下问题:在团队开发中,如何编出好代码?如何管理程序员?如何作一名好程序员?如何做出好程序? 相信专家和不迷信专家的人都可以进来讨论! (100分)<br /> 大家好,问题是接着http://delphibbs.com/delphibbs/dispq.asp?lid=1210032来的,
我看贴子太长了,翻起来特别累,就把它结束了。
  现在接着来,欢迎大家发表看法!
 
以前搜集的在大富翁上的
 
软件开发组的团队精神 --- 一个程序员在IBM的开发经验
 
沈宏宇
  总听到大家在讲团队精神,那么团队到底是什么?
  团队就是一小群有互补技能,为了一个共同的目标而相互支持的人。
  对于一个团队来说,最基本的是要有一个清楚的目标。
志同道合
  是什么原因使大家组成一个团队?一个目标。对于球队来说,这个目标是进球得分,从而战胜对方;对于项目组来说,是在限期内完成项目;对于软件开发组来说,是保质保量推出产品。
  这样说似乎很简单,作为一个软件开发组长,事实上你是否非常明了你的团队的目标了?比如说,我们组的目标是:
  在2001年9月30日之前按软件需求书完成 WPX-XP 的开发。
在这个目标里,有没有考虑到软件测试的时间?如果公司预计在十月份进行产品发布,那么明确的目标应该是:
   在2001年9月30日之前按软件需求书完成 WPX-XP 所有的开发与测试。
  作为组长的你已经将这个目标谙熟于心,下一步便是让每一个组员都明确这个目标。这样,整个团队的目标才能统一清晰。
团队发展
  团队发展大致分为形成,不满,解析和行动(Forming,Storming,Norming, Performing)四个阶段。
  在形成阶段,作为组长,你不仅要让每个组员都明确团队目标,而且要让他们明确自己在实现目标中的职责。
  在团队发展的过程中,难免会遇到各种各样的问题。这时候组员相互推卸责任,情绪消极。这就是团队发展中必经的一个过程,不满阶段。只要在适当的时候将组员引导到积极的解决问题上,便能使团队更有作为。
  在团队发展的第三阶段,解析阶段,组员们达成共同的解决方案。团队便进入高效的行动阶段。
  团队发展可能在这四个阶段之间反复。明确的目标,相互信任与支持最终能使团队进入并停留在行动阶段。
因才施教(Situational Leadership)
  任何时间,出于任何原因,个人影响另一个人或团体的行为便是领导。领导的一贯方式形成了领导风格。
  领导的行为有两种:指导和支持。
  指导行为包括:告诉组员做什么,怎么做;定义组员的角色;定义组员间的关系;为组员建立目标;为组员作决定等等。这是一种单向的交流方式。
  支持行为包括:表扬和鼓励组员;打开双向交流的渠道;增加组员的责任范围;增加组员介入设定他们目标的程度等等。这是一种双向的交流方式。
  在我们的团队中,按照态度和能力大致可以分为四类人:
成熟度 技能,能力与知识 主动性与信心
R1 没有 没有
R2 没有 有
R3 有 没有
R4 有 有
  对于这四种成熟度的组员采用相应的领导方式才能最大程度地发挥组员的主观能动性。
  如图所示,根据指导和支持行为的多少,领导风格也可以分为四种:
领导风格 指导行为 支持行为
S1: 教导 多 少
S2: 推销 多 多
S3: 参与 少 多
S4: 委派 少 少
  从图中还可以看出,对于R1->R4的组员,应相对应地采用S1->S4的领导风格。
  当S刚进入公司作第一个Internet项目时,S既不熟悉Servlet, JSP也不熟悉Javascript,S因此毫无信心 (R1)。组长D让S作一些已有样本的程序块的编码,并指导他阅读入门书籍 (S1)。
  一个月后,S对JSP和Javascript有了大致的了解,加上S原有的C++和HTML的经验,S非常有信心能做好编程工作(R2)。组长D看到S的进步,便将独立的功能块交给S去做,并花时间和S讨论具体的作法,并对S的程序定时检查 (Code Review) ,及时发现解决程序中的问题 (S2)。
  经过一段时间的共同努力,S完全掌握了Internet项目前后台编程技巧,有了多个项目的经验,并通过了UML的培训,组长D便让S担任新项目的设计工作。S毫无作好设计的把握(R3),他将自己的设计想法和D讨论,D肯定和支持S的想法,并鼓励S做好设计(S3)。
  S就这样成长为优秀的设计师,为公司承接了多个项目 (R4)。这时的S需要更多授权来开展工作 (S4)。
  在评判一个人的成熟度是R1还是R4时,针对给定的任务是很重要的。我们经常看到优秀的程序员被提拔为开发组长。对于这位程序员来说,他的编程水准是R4,而管理水准可能只有R1。在如何管理组员方面,你便要使用S1来对他进行指导了。
  另一原则是, 如果你不确认组员的成熟度,请先试用上一标准。例如,你不确定S是处在R2还是R3,先试用S3;如果S不能胜任,再改为S2。
循循善诱(Coaching)
  循循善诱的指导方式适用于上述的四种领导风格。指导的目标只有一个,就是将组员培养成R4,从而更好地完成工作。
  以下是循循善诱五步曲:  
1、尽量让组员来确立目标   
发现与建议,让组员来谈问题的背景和他建议的解决方法。
因为你在这方面更有经验,你可能会发现组员的想法没有你的好,甚至很可笑。其实,在你解释组员想法的不可行之处时,你也灌输了自己的思考方式。适当地分享自己的经验会起到很好的效果。   
和组员一起制定行动计划。  
授权组员以完成计划。  
定时和组员一起审查计划的执行情况。
  循循善诱的指导方式的重点在于“问”而不是“答”,“听”而不是“说”,“授权”而不是“指导”。这更多的体现了你的思想方式,而不仅仅是领导技巧。信任他人是领导的根本。
2、小组会议
  在小组会议上,你和你的组员们“传递”信息,意见,问题,解决方案,工作计划等等等等。如果你和你的组员们不能成功和有效地“传递”,团队就没有战斗力。
  在开会前,先要问自己四个问题:  
会议的目标是什么?
通常有五种会议:规划会,传达信息会,解决问题会,决议会,建立关系会(如庆功会)。   
邀请哪些人参加?   
你怎样知道会议是否成功?   
高效会议的基本步骤是什么?
准时开会,回顾会议议程,控制每个议程的时间,控制讨论不要走题,作会议记录,总结结果并分派工作,准时散会。
  我们通常都想避免会议过多的错误,但对于你的开发组来说,会议过少也会影响组内的交流。
  在小组会议上,作为组长的你主要是明确会议目标,控制议程。“听”多于“说”才能打开双向交流的渠道。
  出于各种各样的原因,有些人不愿意在会议或公众场合发言。你可以在会前提醒他,星期五将要在小组会上讨论GUI设计的问题,希望能听到他的方案或想法。
3、团队精神
  真正的团队精神从哪里来?我们通常最欠缺的是下面两点:   
4、尊重与信任
  你是否尊重与信任每一个组员,相信他们的能力,支持他们的做法?
  你的开发组是否使用Visual Source Safe 层层地管理程序,以至于刚入门的小S只能看到他自己的那一小块代码?
  你是否愿意和组员共享你的设计和程序?
  你是否将所有的电脑都面对走廊以便监视组员们是否在玩游戏,看私人Email?
正所谓“用人不疑,疑人不用”,如果没有基本的尊重与信任,哪里来的凝聚力,何谓团队精神?
如果小S能看到其他人的程序,看到你是怎样处理相似的问题,这是他最好的提高自己的方法。小S提高的越快,对团队的贡献就越大。小S如果能和你共享一个目标,不需要你的监视,小S也会尽力为团队的目标多做贡献。   
5、鼓励和支持个人成长
支持组员的自我发展,给他们的发展提供空间,鼓励开放的交流 。只有支持组员的发展,才能得到组员们的支持,才能提高整个团队的能力。
  在介绍了团队的建立的阶段,适应不同人的领导方式,循循善诱的指导方式和高效的小组会议后,我们应该体会到所有的技巧背后,更重要的是你的思想方式,是你对他人的信任与尊重。只有在相互信任之上,才能建立一个为了共同的目标奋力进取的团队。
 
呵呵,UPUP啊~~~~~~~
 
我认为团队开发,像我以前那一个公司规范化管理。
我是瞎说了。
你的问题我考虑过啦。有趣味。
 
我曾在一家有十几年软件开发经验的香港公司工作过,他们的管理确实是国内很多小的软件
公司(100人以上的我没去过)所做不到的。
可惜楼主所在地离我(广州天河)太远了,要不真想去。
 
沈宏宇是谁,是93年沈阳航院毕业的吗,如果是请让他去中国人的校友录
 
看了前贴,楼主很有魄力的说!
 
团队开发,我也正想了解,我一个人从来就孤独惯了
 
呵呵,大家说的都是。。没有办法。
 
我认为最主要的是找准自己的位置,想清自己的作用!
 
To ugvanxk:
大侠,分一分行多好,我只好复制到word里欣赏了。
 
不错有道理,不过我还有我的意见
我喜欢用基类和Public Function控制软件的窗体风格和操作风格,
这部分基类由一个人来写全组使用,那么就可以大致控制好软件的风格问题
另外,我喜欢由专人控制对外加载文件(包括图片,DLL。。。。。。。)
把他们都放在一个对象库里面,
(我喜欢用DataModule比自己定义方便还可以放一些控件)
信息共享也用过TeamSource不过还是觉得自己用共享目录方便,当然不管用TeamSource还是
自己管理都得有专人管理。最好是组长本人。
 
  多谢诸位大侠捧场,很想加入讨论,可惜时间有点紧。
  请大家先赐一点高见如何?
  过两天将又会有一篇啰嗦文章献上?请大家看一看说得有没有理。
 
知道是一回事情,做到是另一回事情。
自荐一旧贴。
http://delphibbs.com/delphibbs/dispq.asp?lid=908338
 
  http://delphibbs.com/delphibbs/dispq.asp?lid=908338
  我看了这个旧贴了,说得很有道理啊。
  各位在较大软件公司工作过的大侠,能不能说一下你们公司是怎么处理这个问题的?
  
 
每个开发组织都有自己的特点。
原创不是中国人,那么中国的软件公司实施起来就比较困难。
原创太重要了,可是计算机的根是成长在美国,我们只能跟着别人的步子起舞,关于
团队开发及其他方面均如此。假洋鬼子与“拿来主义”。今日中国的假洋鬼子太多了,
已经占领阵地了......
 
  听说各大公司都有以下人员:项目负责人、需求分析员、系统分析员、详细分
析员、程序员、测试员......,究竟这样分合不合理?实际中又是怎么做的?按道
理应该很完美了,为什么大家还说“开发程序很艰苦”呢?
  是这样的开发方案本身就不合理呢?
  还是没有认真执行下去?
  还是有什么特别情况?
  没有目标的冲杀、跟潮流、很危险啊。
  真想听一听有经验的人介绍一下。
  要不,houanl说一下。
 
其实,我个人认为,团队开发还是得看这个团队得目标是什么,团队人数有多少。
一个团队就那么20来号人,怎么分工?项目负责人、需求分析员、系统分析员、详细分
析员、程序员、测试员......,那不是一个人就负责一个部分?显然不大可能。而且在
这种情况下,他们之间得协调必须非常好,不然,很难有所作为。
如果一个团队做得东西都是一些小项目,那就更ft了,那只是几个人做,加快一点点时间
而已,其实,那种项目,一个人慢慢做,也许也可以做出来,这个时候,再怎么团队团队得
听着也不大爽。如果项目大了,当然,这也许才是文章得主题 。
在中国,之所以很难搞活团体,那是因为我们这里没有一种良好得氛围,也缺少很好得leader
我听说在印度,他们程序员间很多公用变量,大家都使用一摸一样得名字。这样,软件得转移
能力很强。而在我们中国,很难也,而且政府也不大重视。
当然,我也认为,团队最需要得是:信任和尊重。
 
我曾说“UML也不过如此,作用非常有限。”
是不是我了解不够深入啊?
谁能说一说:UML在这里起了什么作用?能起什么作用?能解决这些问题吗?
 
To pyzfl
帮你再顶顶。
 
后退
顶部