在开发人员之间分配工作的最佳方法是什么

我和我的团队正在重建我们大约十年前开发的网站，我们希望在敏捷中做到这一点。

因此，在花了很多时间阅读（可能还不够）之后，我遇到了一个问题，即如何在开发人员之间划分工作。

我将更具体地讲，该站点被划分为彼此之间没有太多集成的单独模块。

在开发人员之间划分工作的最佳/最公认的方法是什么？

• 给每个人一个不同的模块进行工作。
• 将所有开发人员分配到同一模块，并按模块的不同部分（UnitTesting，DAL和映射，逻辑，UI）划分工作
• 将所有开发人员分配到同一模块，并按不同的逻辑划分工作（例如，每个开发人员负责一个特定的逻辑（可能是BL中的一个方法），以及UnitTesting，DAL，Mapping和UI ...

也许是完全不同的东西？

我的团队一直在尝试“敏捷”发布几个版本，但是作为大公司的一员并没有使它变得容易。我不会假装自己有答案，但是我可以分享一些观察结果。

• 按模块划分开发人员：

  • 您需要注意，因为如果人们孤立地工作太多，您的团队就不会从技能和知识的共享中受益
  • 如果人们过多地专注于自己的模块并且看不到更大的景象，那么计划会议和日常站立会变得非常沉闷。一旦人们感到无聊，他们就会开始进行检查，您将失去敏捷带来的很多好处
  • 您可能最终会写得非常好一些组件，而其他组件则写得很好...没那么多。如果人们孤立地工作，那么您的高级人员将无法培训初级人员。

• 每个人都同时在同一个模块上工作

  • 我们尝试过一次发布，当管理层决定他们将对整个团队实施敏捷时，这完全是他们的方式。这绝对是火车残骸。我们有一个由9名开发人员组成的团队，在一年内交付通常由1个开发人员完成的工作。（我可能在这里夸大了，但幅度不大）。
  • 没有人觉得这里有呼吸室。那些不关心软件的人会感到宾至如归，因为他们是大包装中的一员，只是被小组成员稀释了。我们当中那些对软件充满热情的人感到绝对窒息，因为没有自由来移动或超越9个人所同意的范围。
  • 所有的会议永远到了我想要开枪的地步。在同一个房间中有太多意见的人被迫使用相同的DLL。惊恐的事件。
• 在上一个版本中，我们决定尝试一些不同的方法
  • 首先，将开发团队分成3-4个开发人员的较小团队。每个团队之间的工作都相对隔离，但是在团队内部，人们之间的协作更加紧密
  • 使用这种方法，站立起来很快，而计划会议需要1-2个小时，而固定会议需要4个小时。
  • 每个人都感到参与，因为每个团队仅讨论该团队的开发人员关心的是什么。
  • 每个团队的技术负责人都会定期与其他技术负责人进行交谈，以确保整个项目步入正轨。
  • 我们没有让人们成为特定模块的所有者，而是为人们分配了专业领域，因此，当我们首次启动该项目时，感觉就像人们拥有自己的模块一样，但是几个月后，开发人员将开始将彼此的代码视为区域开始重叠。
  • 代码审查至关重要。这是我们有严格的代码审查策略的第二个版本，团队中的每个人都喜欢它们。当其他人修改某个代码时，特定领域的专家总是在进行代码审查。
  • 通过代码审查，我们可以进行大量的知识共享，您可以看到我们团队的代码质量的总体提高。同样因为代码经常被审查，所以当人们进入别人的专业领域时，他们至少已经看过几次代码了。
  • 每个团队的大部分人员都参与了设计评审会议，因此，即使他们从未看过代码，每个人都熟悉其团队负责的所有模块的一般流程。
  • 我们已经完成了大约10个月的时间，感觉就像我们从隔离模块方法开始，逐渐演变为每个人在所有事情上所做的工作一样。但与此同时，没有人会感到局促或局限。为了确保他们仍然有一定的权威感，我们将他们留给了区域专家，尽管现在这大部分只是形式上的事情。

我们一直在做最后一件事，尽管还有很多改进的余地，但总体而言，当我们成为大公司的一员时，我们的整个团队非常高兴。

我们在“敏捷”的前3次犯错的一个重要事情是，每一次都告诉人们如何工作以及如何工作。这是让您的团队对项目完全失去兴趣然后让您真正陷入困境的第一方法。

相反，请尝试相反的操作。告诉团队，他们可以做他们想做的任何事情，而作为经理/领导者（如果您是一个人，如果不让您的经理重复这些话），您的工作就是确保他们尽可能多产且快乐。流程不是一件坏事，但是当流程意识到需要一个流程，而不是相反时，流程应该可以帮助您的团队。

如果您的某些团队成员更喜欢孤立工作，请（一定程度上）让他们。如果他们喜欢成对工作，让他们这样做。确保让您的员工尽可能多地选择自己的作品。

最后，这非常重要，并且始终被忽略。您将无法正确理解（除非您是超人或至少是蝙蝠侠）。定期召开回顾会议非常重要。当我们进行回顾时，回顾工作是由书完成的，感觉就像您还需要经历另一个过程。那不是追溯的目的。它用于倾听您的团队，确定造成最大痛苦的区域并修复它们，以便每个人都可以继续工作。显然，软件工程师通常喜欢交付产品和功能，而回顾会议需要传达的最重要的信息是，这完全是为了他们的利益。您想找出并解决障碍，从最大的障碍（或最简单的障碍开始，

与团队开会，向他们显示待办事项清单，并询问谁想做什么。

不要在模块中思考。考虑功能元素。通过用户故事（或其他方式）描述这些功能元素，并且不要忘记描述接受标准（可能由您当前的应用程序定义并改变业务预期）。将您的功能元素放入积压中。然后，让企业确定必须首先交付哪些功能的优先级（您将逐步进行迭代工作，而优先级将告诉您必须首先实现的功能）。

一旦至少在原始应用程序的一部分中拥有了此功能，便可以进行开发了。接下来会发生什么取决于您选择的敏捷方法。重要的是，每个功能通常可以分为多个任务，团队成员将选择他们想要执行的任务-称为自我组织。当您从敏捷开始时，自我组织可能需要一些帮助，以确保他人将不受欢迎且受欢迎的任务平均分配给团队。一旦团队变得更加成熟，开发人员将毫不犹豫地说出他们对当前自我组织的不同意见，这将在团队内部自动处理。

从头开始思考模块不一定是一个好方法。您由于某种原因正在重写应用程序，也许基于不正确的模块分隔的当前应用程序体系结构是可见问题背后的隐藏原因之一。您还可以发现现有模块中的某些功能将被完全重新定义并移至其他位置。

尽管我确实同意David的回答，但我认为它可以从一些阐述中受益：

• 敏捷意味着，您不会做出这些决定并将其推向团队。没有像这样的项目经理/负责人。只有团队。
• 最了解如何分配工作的人就是团队成员自己。
• 讨论您的待办事项，并找出您想要在下一次迭代/冲刺中实现的目标。
• 使用规划扑克或类似的方法可以大致了解您将要分配的工作量，然后才开始将实际的工作包一起分配。

基本上，底线是：SE上的任何人都无法为您回答该问题，也没有太多意义，因为如果您提出一个团队的答案会更好。

最简单的方法通常是最好的。

我将避免将任务分成诸如test / log / UI / etc之类的组，除非您可以定义一些非常明确的理由。我的理由是，当您允许程序员在他们通常的专业知识之外工作时，它可以使事情变得更加有趣和具有挑战性，并允许他们在自己的领域内发展和成长。如果您确实认为时间限制要求您根据专业知识来划分工作，那么至少要确保仍然需要每个开发人员都进行他们自己的单元测试，并使用代码检查和验收测试来解决问题。编写您自己的测试非常敏捷，而等待测试者有空再浪费很多时间。

面对同样的困境时，我采用了以下方法：

• 范围项目。给自己一个想法，了解自己所要从事的工作，并通过将项目分解为一系列任务来开发功能列表。

• 优先考虑功能。确定哪些功能必须尽早完成，哪些功能将立即为您的客户提供价值。如果您的开发人员最终使用相同的模块，请不要担心，但请确保您拥有管理代码合并的良好流程和工具。

• 让您的团队参与进来，并请您的开发人员帮助您将功能分解为更易于管理的任务列表。分组查看并根据需要调整任务，以便可以更轻松地估算它们。

• 要求每个开发人员从优先级队列的顶部选择要实施的任务或一组任务，具体取决于您的迭代的运行方式。

• 在完成从优先级队列顶部选择下一个项目之前，让每个开发人员仅完成一件事情，直到完成为止。您可能很想让您的人员偶尔更改任务，但是这会浪费开发人员的时间。如果发现自己遇到依赖瓶颈，则需要调整任务优先级并最大程度地减少浪费。

• 不要害怕让开发人员使用重叠的迭代来运行，并相应地管理您的发布。这将有助于最大程度地减少发布之间等待任务完成的时间。

最终，成为敏捷就是要找到一种对您的团队，公司和客户都适用的解决方案。您可以通过找到最适合自己的实践平衡来调整流程。在更大的过程中，如何划分任务将是非常重要的一部分，但应尽可能地简化，以鼓励愿意的参与，并避免以后解决与过程相关的问题带来的困难。

如果不提及Fred Brooks博士的手术团队，那么开发人员团队的组织讨论将是不完整的。

基本公式是：每个工作单元一个手术团队

定义一个手术团队

手术团队的概念基于两个基本概念：

1. 更少的开发人员在单位工作中更好，因为串扰会降低生产力。
2. 高产出的开发人员要胜过低产出的开发人员（据布鲁克斯所说，没有中等产出的开发人员），因此您最好给他们最重要的工作，并限制他们的注意力。

一个外科团队由3至10名开发人员组成：

1. 首席程序员。高产出的开发人员，负责大部分实际编程。
2. 副驾驶。另一个高产出的开发人员，他不仅要进行编程，还要执行一些管理任务，例如参加会议和收集需求。
3. 1-8个助理。 Brooks将这些人描述为负责文档，代码清理，研究，编写工具/算法，测试等工作的开发人员。早在60年代，Brooks就提出了8种角色，但是使用现代工具，您可能只需要1或2个角色；应该根据项目的需求进行分配。

定义工作单元

因此，既然我们可以组成一个团队，我们应该给他们分配什么？

• 如果项目很小，这很容易。您将一个外科团队分配给整个项目。
• 否则，您将需要从负责整个项目架构的人员或团队入手。他们的工作是适当地模块化软件，以便可以在其他子团队中分配工作。架构团队也可以进行其他工作，以免开发人员过于分散。

您应该看到三种基本的可接受模式：

1. 每层各1个小组（UI，DAL等）
2. 每个模块恰好有1个子团队（主页，支持站点，商店）
3. 两者的结合（低级框架团队和每个模块的UI团队）

根据开发人员和模块的数量（以及时间范围），我通常让我的开发人员选择一个（对他们而言）有趣的模块和一个具有挑战性的模块（最好是他们没有做过的事情），然后其余的我按照技能水平进行划分，时间限制。我发现这为我的开发人员提供了他们想要从事的工作和推动他们的工作。

当然，这并不总是可行的...

这是我会做的：

如果所有模块都很小，那么您可以为每个模块工作。否则，请执行以下操作：

1. 定义每个模块的大小，复杂度和所需的技能。
2. 定义每个团队成员的技能。
3. 定义哪些人可以很好地合作，哪些人不能与他人很好地合作。
4. 根据模块技能要求和团队技能，将大型模块分配给可以协同工作的团队。
5. 根据模块技能要求和团队技能，将剩余的模块分配给不能与其他人很好地协作的人员。

如果不喜欢与他人一起工作的人是最熟练的人，那么上述方法将不起作用，这是常见的情况，因此请相应地将4和5排除在外