24

我在一个小团队（4-5 名开发人员）中工作一个项目。我们团队的每个成员都在开发与我们项目不同的功能，并且他们是高度独立的。事实上，一些成员使用其他成员不知道的技术。它仍然是一个单一的项目，其中有很多通用的业务逻辑。

此外，大多数成员完全不知道其他人在做什么和如何做。不知何故，我们设法避免了代码复制（我们的团队负责人的功劳，但即使他也不完全知道发生了什么）。我想知道，有什么好的做法可以让整个团队保持在正在发生的事情的轨道上。例如，如果团队中的某个人在应该进行重要修复时退出或失踪 - 其他人很难处理。

我们有一个进行代码审查的政策，但只有团队领导和团队的一名成员参与其中。其他“常规”成员不参加，那里。

此外，我们有一个“新闻列表”，用于记录我们的成员在源代码控制中提交的签入，但这似乎太无聊了，而且看起来没有人花时间阅读其他人刚刚提交的内容（而且它没有效果，公平起见）。

所以，我想知道在这个问题上什么是好的做法。你有什么经验？有解决办法吗？

编辑：让我澄清一下。我们的团队已经工作了 2 年多，这个项目已经快 5 年了。所以，我们不能开始敏捷开发，尽管我们可以给你一些敏捷实践（比如站立会议，我觉得它确实很有用）。

另外，我们的团队是大公司的一部分，所以我们建立了团队建设实践。而且我们并不讨厌彼此:) - 我们是朋友，谈论社交生活和活动。专业的演讲是我们所缺少的。

4

8 回答 8

17

  • 每天与在场的每个人举行站立会议（保持简短），帮助每个人了解彼此在做什么。这也有助于经理摆脱一些管理，有助于防止颠簸，并在经理不必这样做的情况下对每个人施加一点压力。（你想完成一些事情，以便明天早上在你的同龄人面前看起来很好）。像Scrum这样的一些方法将这一点正式化。

  • 与不同的团队成员进行代码审查。非经理团队成员之一是否更有经验？让这个人与其他人一起进行代码审查会很好；他/她将分享他们的经验，并成为了解大部分情况的其他人（除了经理）。没有法律规定在同行评审中，一个人必须比另一个人更资深，并且是宣布代码正确或错误的人。我认为，如果两个“同行”正在做代码审查，他们应该从结对编程开始。

  • 如果您正在尝试编写一些高质量的代码，那么某些代码可能适合结对编程。XP 的人说你应该一直这样做，但我相信它有时会更有帮助。例如，当一位开发人员比另一位开发人员更有经验时，这有助于指导。此外，当您希望在特定区域传播知识时。（只有一个人了解系统的一部分；下次需要修改时，让那个人与其他人一起打字。）此外，有时系统的一部分非常重要，正确地设计它更为重要比每分钟的代码行数。这是一个在问题上有两个头脑的好地方，最后是两个人对这个关键代码有深入的了解，而不是一个。

  • 比如每周一次，让某人在午餐时就他们正在做的有趣的事情进行简短的谈话。这可以引起很好的讨论，促进信心和相互尊重，但我们在这里感兴趣的是它促进了意识。

  • 重视、支持和相信好的代码。一些商店（主要是经理）并不真正相信好的代码，这导致人们只是破坏（蹩脚的）代码，即使开发人员可以制作出很棒的代码。如果开发人员对他们正在编写的代码感到满意，如果您时不时地实施一些新技术，并且如果高质量的工作有助于您的职业生涯，那么关于代码的交流会容易得多。

还有更多关于结对编程的信息。本次讨论的结对编程的关键部分是结对编程促进共享代码和交叉知识。我提到结对编程特别有用的特定地方的原因是因为“我们将进行结对编程”的策略大约有 10% 的时间会成功。当大经理问“为什么所有这些人坐在同一张桌子上？”时，其他 90% 的实践支持者无法给出足够好的答案。结对编程的优势必须比一个程序员做 200% 以上，因为你使用的是两个人。在正确的时间完成，结对编程可以提高您的解决方案/降压比；在错误的时间它可以减少它。

于 2010-02-23T20:48:16.570 回答
8

结对编程和每日站立会议等敏捷技术是进行沟通的良好正式方式。

但听起来你真正需要做的就是让人们互相交谈。开发人员往往是内向的，所以你必须在这方面工作。一起吃午饭。看着彼此的肩膀。寻求彼此的建议（即使你不需要）。互相询问那些不是每个人都能理解的奇怪技术。收集集成测试。

于 2010-02-23T20:48:13.377 回答
3

我在工作场所也有类似的情况。就像你说的，团队的一些成员是高度独立的，不会与团队的其他成员分享任何见解或实践。我发现这非常不专业，并且对团队整体造成伤害。

当然，有一些成员比其他成员更精通是不可避免的，而且，在编程世界中，一些成员将难以摆脱他们的自尊心。最好的办法是安排每个人都参与的会议和代码审查。拥有一个中央文档站点，人们可以在其中发布他们使用的某些技术。如果您发现您认为对团队其他成员有用的东西，请将其上传到网站并发送电子邮件告知所有人。沟通是关键。

于 2010-02-23T20:50:45.533 回答
3

可以帮助您的是每日站会（来自敏捷开发）。只需几分钟，基本上所有成员都会向其他人展示他们的工作状态，他们处理的问题和明天的计划。

我认为站起来对你来说是一个好的开始。您可以在 Martin Fowler 找到更多信息- 不仅仅是站起来：每日站立会议的模式

于 2010-02-23T20:52:41.590 回答
3

在我们的团队中，我们每周都会召开进度会议。这允许发现其他人在做什么以及每个人在大局中的位置。

有时，当我们分享自制蛋糕时，会举行一次小型社交活动。下次送蛋糕的人的名字写在进度会议纪要上。

于 2010-02-23T20:53:24.053 回答
3

团队建设

一起去烧烤，玩桌上足球，在工作之余找点大家都喜欢的团队活动。这将教会人们相互信任而不是“独立”，并将其他所有有用的团队实践（如 scrum 会议或结对编程）的效果乘以 10。

于 2010-02-23T20:56:44.533 回答
3

以下是我的一些想法（小公司，三个程序员；曾经在一个大约 20 人的团队中工作）。

  • 某种进度报告，以便每个人都可以看到其他人在做什么。“我一直在做的事情”会议对某些人有用，但我不是他们的粉丝 - 他们过于严格，为此目的的静坐会议通常会浪费时间和/或者容易消失在老鼠洞里。在我目前的工作中，我们有一个 cron 工作，它提醒我们发送每周进度电子邮件：在这些电子邮件中，我们应该说明我们已经取得的成就、待办事项列表中接下来的几项（在适当的情况下进行估计）、我们遇到的任何问题遇到过。
  • 选择性提交通知。很少有人对公司范围内的提交邮件（即使在我的小团队中）付出更多的代价——但如果你可以授权每个开发人员只监控他们正在工作的领域，他们可能可以跟踪它。（无论如何，你不应该有太多人同时处理同一段代码。太多的厨师等等。）
  • 某种提供待办事项列表的票务系统可能会有所帮助。但是，您需要非常清楚这是如何管理的 - 特别是您的发起和关闭工单的流程。
  • 内部文件。这是一个难题；有些开发者讨厌它，有些写得太多，有些写得刚刚好。至少一半的问题在于索引和表示；如果你需要的信息被埋在一份名为“提防豹”的难以理解的文件中的五层深处，那就不好了。为此目的，我非常喜欢 wiki，因为它们非常易于使用。
  • 超过一定规模的团队，您可能会发现有人管理您的文档成为一项全职工作。在以前的工作场所，我们把钱花在了搜索引擎设备上，不断地爬取我们的内部网站，这真是太棒了。
于 2010-02-23T21:30:28.633 回答
1

我们处于类似的情况（一个长期的项目并且都是朋友），并且遇到了类似的问题。以下实践使我们能够改进很多：

  • 每日站立会议是必须的。以我的经验，进行良好的每日站立会议是鼓励团队之间交流的最佳方式。每个人都知道所有团队成员在做什么，并且可以帮助解决任何问题。
  • 维基也是必不可少的。您可以提出团队内部使用的标准实践和技术。为了让每个人都积极参与，领导者为所有团队成员分配了一些东西来编写和维护 wiki。当每个人都写他们特别喜欢或感兴趣的东西时，它特别有效。
  • Try to have the whole team present, or all the members that are available, in meetings where requirements/features are analyzed, priorized, etc. It doesn't matter if some of members of the team are not specificaly working in that area of the project. This will give context to everybody and a broader vision of the project. It will allow (and encourage) them to participate in this discussions of the project as a whole, and not solely concentrate on the part that they are working on. This practice will motivate a lot of discussion, all of us when given a chance and knowledge (it only takes a very small amount) have an opinion and like to comment on all everything within the project.
  • 激发大量“商店”谈话的最后一个做法是，每两周，一些成员就一些技术或技巧进行一次小型演示。一般来说，它包括实践练习，以及时间讨论和提问。
于 2012-02-09T19:29:49.563 回答