ant*_*res 24 collaboration project-management communication
我在一个项目中的一个小团队(4-5名开发人员)工作.我们团队的每个成员都在开发我们项目的不同功能,他们是高度独立的.事实上,一些成员使用其他成员不了解的技术.它仍然是一个单一项目,其中有许多常见的业务逻辑.
此外,大多数成员完全不知道其他人在做什么以及如何做.不知何故,我们设法避免代码复制(我们团队领导的信用,但即使他不完全清楚发生了什么).我想知道,让整个团队保持正常运转状态的良好做法是什么.例如,如果团队中的某个人退出或者在应该进行重要修复时丢失 - 其他人很难处理.
我们有一个政策,用于进行代码审查,但只有团队领导和团队的一名成员参与其中.那里的其他"常规"成员不参加.
此外,我们有一个"新闻列表",用于我们的成员在源代码控制中提交的checkin-s,但这似乎太无聊了,看起来没有人花时间阅读其他人刚刚提交的内容(并且它没有效果,公平起见).
所以,我想知道这件事的好习惯是什么.你有什么经历？有解决方案吗？
编辑:让我澄清一下.我们的团队工作了2年多,该项目已有近5年的历史.所以,我们不能开始敏捷开发,虽然我们可以为你提供一些敏捷实践(比如站立式会议,我觉得它非常有用).
此外,我们的团队是大公司的一部分,因此我们建立了团队建设实践.而且,我们不恨对方 :) -我们是朋友,谈社会生活和活动.专业会谈是我们所缺少的.
Pat*_*her 17
每天站立的会议(简短地说)与在场的每个人一起帮助每个人了解彼此在做什么.这也有助于管理者完成一些管理,帮助防止颠簸,并且在没有经理必须这样做的情况下对每个人施加一点压力.(你想要完成一些事情,这样你明天早上就会在同龄人面前表现得很好).像Scrum这样的一些方法正式化了这一点.
与不同的团队成员进行代码审查.非经理团队成员之一是否更有经验？让这个人与他人进行代码审查会很好; 他/她将分享他们的经验并成为其他人(除了经理),他们知道发生了什么.在同行评审中没有法律规定,一个人必须比另一个人更高级,并且是宣称代码是对还是错的人.我认为,如果两个"同行"正在进行代码审查,他们应该开始配对编程.
如果您正在尝试编写一些高质量的代码,那么某些代码可能会使自己成对编程.XP的人说你应该一直这样做,但我相信它有时候和其他时候会更有帮助.例如,当一个开发人员比另一个更有经验时,这有助于指导.此外,当有特定区域您希望知识传播时.(只有一个人理解系统的一部分;下次需要修改时,让那个人与其他人打字一起做.)此外,有时系统的一部分非常重要,正确制作它更为重要比每分钟的代码行数.这是一个有两个问题的好地方,最后两个人对这个关键代码有了深入的了解,而不是一个.
像是每周一次,有人在午餐时间谈论他们正在做的有趣事情.这可以产生很好的讨论,增强信心和相互尊重,但我们在这里感兴趣的是它提升了意识.
重视,支持并相信良好的代码.一些商店(主要是经理)并不真正相信好的代码,这导致人们只是破坏(糟糕的)代码,即使开发人员可以制作出色的代码.如果开发人员对他们正在制作的代码感到满意,如果你不时地实施一些新技术,以及质量工作是否有助于你的职业生涯,那么关于代码的沟通就会变得容易得多.
更多关于结对编程.对于这个讨论,结对编程的关键部分是pair-progrmaming促进了共享代码和交叉知识.我之所以提到结对编程特别有用的具体位置的原因是因为" 我们要进行结对编程 " 的策略在大约10%的时间内成功.其他90%的人,当一位大经理问道:"为什么所有这些人坐在同一张桌子上？"时,这种做法的支持者无法给出足够好的答案.结对编程的优势必须比只有一个程序员的200%以上,因为你使用的是两个人.在正确的时间完成,结对编程可以提高您的解决方案/降压比; 在错误的时间,它可以减少它.
敏捷技术,如结对编程和每日站立会议,是进行沟通的良好正式方式.
但听起来你真正需要做的只是让人们互相交谈.开发人员往往是内向的,所以你必须在这方面工作.一起吃午饭.看看彼此的肩膀.寻求彼此的建议(即使你不需要).互相询问那些并非每个人都能理解的奇怪技术.收集集成测试.