拉塞尔·威斯布鲁克
再次您好，通过阅读标题，您可能会以为我会解释一些算法/工具，但是对于更改，让我们来谈谈项目管理以及在特定时间向项目中添加新人员可能会带来危险，以及避免。 让我们直接进入布鲁克定律的话题。
这是根据维基百科的定义。
布鲁克斯定律是对软件项目管理的一种观察，根据该定律 ， “为一个较晚的软件项目增加人手会使它变得更晚”。
根据Brooks的说法，有一个增量人员，将其添加到项目中后，可以增加而不是减少时间。
- 添加到项目中的人员需要一些时间才能变得富有成效- 准备时间
- 通信开销随着人数的增加而增加。
- 任务的可分割性有限可能会引起更多混乱。布鲁克定律
您可能是许多认为没有意义的人之一。 这是否意味着我们不应该在项目中增加人员？ 你一定在开玩笑…
冷静。 我们不要得出任何结论。 首先，我们将了解法律的适用性并找到解决方案;）
布鲁克斯法则仅适用于已经迟到的项目。 该项目的时间表原本过于乐观，还必须考虑加入该项目的人员的数量，质量和角色。
让我们考虑一个实际情况，看看它如何影响。
假设我们是一个由6人组成的团队，为客户X做一个项目。我们有一个计划，在10个月内完成该项目。 但是，在5个月之后，除了商定的需求之外，几乎没有其他事情添加到待办事项中。 但是，我们仍然致力于按时交付。
因此，项目经理决定在团队中再增加2名开发人员和1名质量检查人员，希望这一更改可以提高生产率并在截止日期之前做好一切准备。
但是团队可交付成果有所下降。 步伐越来越慢。 然后，项目经理决定进行回顾以了解情况。
项目经理：我们的团队还有3个人，乳清是可交付成果，速度很慢。
团队：？？？
您认为是什么原因？
是。 你是对的。 这是因为有新成员（不是字面上的意思）。 使新成员了解该项目并进入生产阶段需要花费时间。
你现在做什么？ 再增加几个人？ 不用了 相反，让我们重新考虑时间轴，首先找出造成延迟的原因。
因此，这就是布鲁克定律。 让我们看看如何避免这个问题。
首先，对截止日期感到悲观。 有一个缓冲总是好的，要有适当的工程标准。 持续的集成 ， 测试驱动的开发和迭代式开发显着减少了开发人员之间的通信开销，从而实现了更好的可伸缩性。单个成员的专业知识将对可交付成果产生重大影响。
布鲁克定律从来没有说过不应该增加人手。 只是说你会被耽搁。 如果您让高素质的人加入团队（或者团队更容易适应变化），那就可以了。 时间不是唯一的成功标准。 如果您要添加的人员在团队中扮演重要角色，那么成为后来者可能比没有价值。
结论：
更好地了解需求并对目标感到悲观，了解您的团队优势将有助于按时计划和交付任务。 经常进行回顾以了解团队的速度是必要的。
感谢您的阅读。 再见，直到下一次。
代码 = CO ffee + 德 veloper
参考资料
- 应用布鲁克定律
拉塞尔·威斯布鲁克
扫一扫
2525
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
