Spiga

项目-团队-技术-个人 (团队建设篇)

2011-11-30 08:01 by Virus-BeautyCode, 2379 visits, 收藏, 编辑

可能是工作的时间长了,加上自己也是个有点心的人,最近一年开始思考一些技术周边的事情。

团队建设。

团队如何高效。

如何提高团队成员的水平。

如何让团队保持进取心,保持积极的工作态度,保持他们对于技术的渴望和追求。

如何激励他们,绩效,氛围,以身作则,言谈举止,哪一个更有效。

感觉敏捷、结对、代码审查也许可以解决部分问题。

新人如何快速融入团队,新人如何成长,缩短新人进入团队的磨合期。

如何使工作3-5年的人保持积极的热情,积极的工作态度,唤醒他们对技术的渴望和追求。如何指导他们的下一步发展,如何引导他们的下一步发展,帮助他们确定下一步的发展方向。

1、每天早晨进行站立会议。带头主动发言,说明进度及问题,有无需要协调的资源,有无需要细化的工作。有需要的话,大家再坐下来沟通和讨论。
2、星期五下午,团队组织技术交流。可以是介绍一周自己的进度及工作问题,也可以提出自己的疑问,也可以讲述自己近来的学习成果,新发现。内容限定为技术话题。
3、鼓励工作之余学习各种技术,其他平台,其他语言,参与开源项目,将来有机会发展我们自己的开源项目。可以在周五下午分享学习的成果,学习碰到的问题,大家一起帮助解决。
4、建立对外的开发团队博客。在博客中建立个人简介。每个人都可以发表文章。内容限定为技术博客。学习成果,工作中解决的问题,好的分析解决方案,新的发现,都可以发表。
5、活跃团队气氛,加强交互,形成良性成长环境,加速新人成长,缩短新人期。
6、允许个人选择自己喜欢的工作内容,尽量的安排每个人做自己喜欢的工作,使得每个人对项目的整体进度有更多的了解,可以提升工作效率。
7、引入结对编程。两种组合形式:1、技术相差不多的两个人结对,可以加速成长。2、新人入职之后,先和骨干结对,及时发现新人的问题,编码习惯问题,思维方式问题,命名习惯问题,及时解决,加速新人成长,还可以控制新人犯错的空间。可以定期更换结对,让每个人都了解项目的整体状况,也可以避免长期从事一种工作内容导致的兴趣减低带来的效率降低。
8、代码共享,每个人都可以修订别人的代码,重构自己的代码。逐渐抛弃“你的代码就是你维护,我的代码就是我维护”这样一种不良的想法,项目是大家的,代码也是大家的,大家要对项目负责,不管是谁写得代码,每个人都需要对他负责,而不只是当初编写的人负责。
9、引入单元测试,在重构和修订代码之前,先写好单元测试,保证重构和修订不影响原有代码的功能。通过编写单元测试,增加程序可测试性,改善代码结构。从改善局部设计开始做起,在以后的编码中逐渐形成良好的编码习惯,积累设计经验。
10、严格把控模块之间交互接口的设计,尽量避免不合理的设计对后面模块集成带来的问题。
11、对代码进行审查,从代码中发现不好的习惯,同时也发现好的习惯,从代码入手,减少开发-测试的往复工作,提高编程的愉快度。

【Blog】http://virusswb.cnblogs.com/

【MSN】jorden008@hotmail.com

【说明】转载请标明出处,谢谢

 

反馈文章质量,你可以通过快速通道评论:

Add your comment

12 条回复

  1. #1楼 传说中的弦哥      2011-11-30 09:02
    理论上都是对的

    但有一些条目其实是关乎于价值观和工作生活态度的,并不是每个人都是积极向上,热爱工作的。

    排个顺序 逐步上吧
    一下全上团队成为接受起来有困难,也会给自己徒增烦恼,最后大多不了了之。
     回复 引用 查看   
  2. #2楼 好俊的功夫啊      2011-11-30 09:28
    8,代码共享
    修改别人代码之前是不是要先讨论,说不定原来设计的人思路更可取
     回复 引用 查看   
  3. #3楼 小知了了      2011-11-30 09:52
    第3点,不知道你的团队情况怎样,我带过的团队中很少有人对开源有兴趣,如果在不确定的情况下强推开源会成为一种负担而不是鼓励;
    第8点,可能成为代码混乱之源,发现别人的代码有问题告诉他一声就行了,不声不响的改掉代码只会让人不爽,实际上除非不得已没几个人愿意看别人的代码;
     回复 引用 查看   
  4. #4楼 helloworld2      2011-11-30 10:27
    呵呵,团队水平和团队平均工资成正比
     回复 引用 查看   
  5. #5楼 MeteorSeed      2011-11-30 10:31
    同意3楼的看法
    第1点,有些时候带头发言并不合适,比如群体决策时,有权威的应该最后发表意见,否则会影响下属的意见。
    第9点,我觉得在没有完善的白盒测试流程保证下,无法保证测试用例的覆盖率,也无法有效利用测试结果,应该注重过程改进,并引入缺陷核对表。
    我觉得适当的授权,更能激励员工,也更利于团队建设。
     回复 引用 查看   
  6. #6楼 黑色      2011-11-30 11:13
    你这个想法是在最好的情况下的,不过不现实,实际情况不可能这样
    第一,第二点,会可以开,但是要视情况,每周开会就变成例行公事,到底有多大的意义,可想而知,例会还不如改成有事才开,这样的意义会大些,解决实际问题。

    第三点,你所谓的工作之余,是指上班的时候自己的事做完了有空了呢还是下班后,如果是下班后的话,自己学习的东西,估计没几个人有拿出来分享(国内的),如果是上班时间的话,是否又涉及到工作量的问题呢?你领导会觉得安排的工作少了,他才有空,下次要多安排些工作
     回复 引用 查看   
  7. #7楼[楼主] Virus-BeautyCode      2011-11-30 14:42
    @好俊的功夫啊
    @小知了了
    @helloworld2
    @MeteorSeed
    @黑色
    @传说中的弦哥
    感谢大家的参与。
     回复 引用 查看   
  8. #8楼 C#通用权限管理系统组件      2011-12-01 13:09
    文章不错,支持一下!
     回复 引用 查看   
  9. #9楼 Statmoon      2011-12-01 16:24
    写的不错,但是我对其中几点有其他看法
    第一点,我觉得开会的话在真的有问题需要讨论或者有技术难点需要突破的时候开比较好一点
    第二点很赞同,隔一段时间大家一起交流下,然后分享一下自己的学习成果,不过感觉这个前提得建立在一个非常好的学习型团队的基础之上,不过感觉有很多程序员不愿意告诉别人自己知道的东西
    总的来说,我非常喜欢你上面所提到的团队。
     回复 引用 查看   
  10. #10楼[楼主] Virus-BeautyCode      2011-12-04 20:31
    @Statmoon
    @C#通用权限管理系统组件
    谢谢,团队努力打造中。
     回复 引用 查看   
  11. #11楼 mikelij      2011-12-20 20:45
    呵呵,从linkedin 过来的。写的还不错。
     回复 引用 查看   
  12. #12楼 龙歌网络      2012-01-04 21:36
    我现在虽然刚进公司,但以后进入管理层是必须的,所以现在多看看多学学。

    说得真不错,收藏了,谢谢!
     回复 引用 查看