在涉及大量工作的软件过程中，有一种普遍的管理人员的方法，以确保每个人都能获得适合其才能、知识、技能和经验的任务。
对于软件产品的给定功能或修改，高级技术人员将制定出可能成功并适合业务架构的设计。然后，这位大师将工作划分为需要由个人完成的任务。
通常，优秀的技术大师会考虑他们团队的技能，并根据个人技能线划分工作。有些人会沿着组件线划分工作，然后根据他们最了解的组件考虑将给哪个团队成员分配哪个部分来工作。
分配工作，然后团队成员在完成当前任务列表时执行新工作，根据需要向高级人员提问，并希望（在许多但不是所有组织中）独立测试他们的作品。
这项工作在版本控制系统（例如git）的各个分支中完成，并在票证系统（例如Jira）中进行跟踪。
当所有的部分都完成并且代码都经过审查后，然后将这些部分集成并合并到一个共同的开发分支中。在一起测试这些部分之后，它们被合并到一个主（主干）分支或一个发布分支。
换句话说，
- 软件作品首先被分成若干块
- 那些散落在各个团队成员的碎片
- 一旦所有的碎片都完成了，它们就会被收集起来
- 这些软件被合并/集成
- 组合代码经过测试
- 当组合解决方案工作时，它被部署
我们称这种工作方式为分散-聚集开发Scatter-Gather。
它有什么吸引力？
吸引人们的原因有以下几个：
- 个人可以独立工作（大多数情况下），他们之间几乎没有闲聊或协调。
- 理想情况下，大部分工作是并行完成的。
- 工作产品被分配给具有专业知识水平的个人，从而有效地利用资源
- 个人对他们的工作负责和负责，这使得为了绩效管理目的，更容易分辨每个人的技能水平和优势（或劣势）。
理想情况下，我们应该看到工作以最大并行度快速完成，因为每个任务都交给最能及时完成的人，如果变更设计良好且任务被很好地理解，那么在以下时间组装变更结束不应该太困难或不合时宜。
缺点问题
有几个值得注意的问题需要指出：
- 时间分布：工作通常不是并行完成的，因为每个人都有一个与各种故事相关的任务列表。任务列表的长度和顺序可能因人而异。完成工作可能需要更长的时间，因为工作分散在待办事项列表中。
- 筒仓形式：每个人都倾向于在他们熟悉的给定空间中工作。个人倾向于收集系统有限片段的非常具体和深入的知识。工作往往需要排队等候专家，延迟完成。
- 砖块制作（基于赫芬顿邮报文章中提到的一个古老寓言）：开发人员参与制作代码片段，而不是端到端集成和频繁发布。
- 不鼓励协作：个性化、个性化的任务不太有利于集成编程。此外，由于每个开发人员都有自己的工作要做，他们无法在不将自己的任务置于未完成风险的情况下加入其他人的任务。出于这个原因，单个任务的分配称为解组。
- 预设计师的负担：领导者不仅必须提前（通常单独）进行设计工作，而且他们还必须了解如何最好地将这项工作分配给团队成员。随着故事的进展，他们还负责回答有关实施、集成和业务案例的任何问题。
- 后期测试：在每个部分完成之前，该功能不作为完整的端到端流程存在，因此端到端测试必然会延迟。
- 失去机会：团队成员不会同时看到整体设计，因此他们发现缺陷或机会的能力受到阻碍。
- 迟到的惊喜：原始设计中的任何缺陷或工人对设计的解释都会在集成过程中迟到出现。如果问题需要返工，返工将破坏必须修复缺陷的个人的任务列表。
- 模糊状态：任何整个工作的进度都是分布式和孤立的。所有的部分什么时候开始？所有部件什么时候完成以便我们可以集成它们？在日历时间内，我们什么时候可以在生产中看到此功能？
预测很难，而且越来越难
软件领域的公司试图通过更精确的估计来管理可预测性和质量问题，但这是徒劳的。导致可预测性问题的并不是低质量的估计。
可预测性的最大问题是意外地内置在分散 - 收集系统中。
考虑到他们将在不同时间处理任何给定的故事，他们中的任何一个都可能被迟到的问题或紧急情况以及任何集成问题打乱，因此参与完成该功能的所有开发人员预计会累积多少进度延误直到所有的部分都完成后才会被发现？
详细点击标题