在实践中，我们经常遇到这样的事实，即项目经理想要加快开发过程-他对交付新功能的速度不满意。 通常，此类客户需要复杂的产品，例如医院管理系统，交易所交易系统，银行系统和银行服务。
在这种情况下，您可以连接新的专家团队，在现有的专家团队中建立流程，或将两者结合起来。 考虑每种方法的利弊。 立即保留对本文讨论大型和复杂项目（超过10,000小时）的开发的保留。
为什么您不能立即联系新专家
通常，提高开发速度最简单，最明显的选择就是联系新专家或团队。 在项目经理看来，这可以加快向最终用户交付业务价值的速度。 实际上，情况并非总是如此，特别是当项目中的流程需要处理时。 我们从实践中举一个例子。
有必要将两个团队连接到现有的开发项目。 该项目已经开发了4年多，包含大量子系统（超过20个），它们具有共同的机制和服务。 完整的回归需要5-7名质量检查工程师的参与和大约4-6个工作日的时间。 当进入项目并使团队达到要求的问题解决水平时，他们遇到以下困难：
- 系统源代码的一部分在svn版本控制系统的控制下，另一部分在git的控制下。 SVN以前很受欢迎，但是，对于大型团队项目和频繁的并发更改，它不适合。 因此，在切换到git之前，一部分时间花在了合并，编辑冲突以及与svn中的分支相关的其他操作上。
- 有关部署环境的指令已经过时，因此团队收集了该系统的各种陷阱，并且只能在3-4天后开始执行第一个任务。
- 主要分析师和技术专家正在忙于准备发布，因此无法快速获得有关新任务的澄清信息。 任务设置非常顶层。 这大大减慢了任务的执行速度。
- 任务的工作流程很困难，起初，团队“迷迷糊糊”如何在整个生命周期中处理任务。
- 刚开始，客户只想通过其QA工程师的努力来解决问题，但由于工作量很大，他们未能设法全面，迅速地检查连接的开发团队的新功能。 因此，我不得不加班工作。
- 根据项目建立的原则和标准进行了代码审查。 该标准尚未记录。 因此，花费了更多的时间来更正注释。
以上细微差别的结果是：
- 用于解决业务问题的额外时间成本
- 整个系统发展缓慢
- 或加班。
考虑如何避免这种情况。
工艺分析
在联系新专家之前，有必要弄清楚团队的工作安排是如何的-有必要找到并消除瓶颈。 通常，由于PM负责该项目，因此PM会处理此问题，并且他希望在跟踪流程上花费更少的精力。
消除瓶颈将使项目向前发展。 例如，减少了进入新专家或专家团队所需的时间，增加了团队在项目中的参与，由于第一次正确执行任务而减少了一个小时的成本。 如果消除了所有瓶颈，则项目经理将获得当前实践和项目环境所允许的如此快速的发展速度。 总的来说，这对所有人都有好处。
可以从两个方面分析瓶颈：高层管理人员/专家以及团队。 我们将分别分析每个选项。
外部专家。 用这种方法，可以由外部专家的外部团队或项目经理与团队负责人一起分析工作过程。 对于后者，事实并非如此，重要的是他们必须丢弃项目的所有细微差别，否则分析将毫无意义。
一个重要条件是支持项目管理和准备更改。
因此，专家会投入到项目中并详细分析文档，源代码，数据库结构，生产过程（从分析到发布）。 分阶段工作如下所示：
- 从头到尾都将考虑项目的整个工作链。 测量每个过程的时间。
- 将建立一个甘特图。 专家检查哪些进程正在并行运行，哪些又并行运行。
- 专家认为如何使每个过程更高效，更省钱。 通常，专家会直观地了解最大的困难出现在哪里，并开始将它们分解以进行可能的现代化。
这种方法的优点：
- 这项工作由不参与项目的人员进行分析。 他对流程有直接的了解，因此，他可以发现团队成员看不到的那些问题。
- 作为权威，专家可以说服团队接受流程的变化。 长期从事项目工作的团队不会寻求创新。 对于他们来说，这是很大的压力，因为他们将不得不重新学习。 而且，这种反应甚至适用于那些有助于更有效地工作的更改。
- 快速实施解决方案-2-15天。 这一切都取决于组织内部的全球变化和官僚主义。
- 项目团队吸收了第三方专家的经验。 将来，这将有助于独立配置流程。
缺点：
- 专家需要花费大量时间来了解复杂性。 团队可以一天内研究项目的历史，而专家至少需要一个半星期的时间。
该怎么做 ：与项目经理/团队负责人一起设定分析目标。 给专家所有“入门”项目，不要隐藏细节。
如果客户非常忠诚，以至于他准备迭代分析项目，那么您需要利用机会并同意这种条件。 随后，将有可能在每次迭代之后调整分析方向，仅关注所需的方向。 - 一些团队成员可能不同意该决定。 随后，他们可以破坏项目，无法很好地执行协议，这会影响团队的整体情绪。
该怎么做 ：与团队讨论每个决定，而不要把决定摆在事实面前。
理想的选择：专家独立分析过程，然后与项目中的关键人员进行讨论。 如果有矛盾，他们会讨论。 这会积聚许多忠于变化的人，这些变化会影响其他团队成员。 可以说服最热心的怀疑论者。
来自团队 。 这种方法可以称为追溯，它是Scrum不可或缺的一部分。 该过程如下所示：
- 整个项目团队将
- 一名参与者承担了促进者 （scrum-master）的角色。 他确保对话以建设性的方式进行。
- 团队讨论他们的工作方法。 考虑所有方面：流程，编码，设定目标等。 然后突出显示了利弊。
- 在一般表决中，他们同意进行更改：需要固定优点，删除缺点。
- 3-4周后，重复此过程。 团队会查看结果，如果每个人都满意，那么工作将会继续。
重要条款：
- 管理层对任何变更和创新的支持。
- 团队凝聚力，专注于改进。
如果公司的文化不鼓励主动，创新，那么追溯并不是重新设计流程的最佳方法。 团队成员将不会超出他们的“沼泽”。
该方法的优点：
- 每个参与者参与项目讨论。
- 识别项目所有积极方面的能力，并在必要时将它们形成某种模型（最佳实践）。
- 团队成员彼此分享经验。
- 逐步解决问题，从最大程度降低团队和项目速度的问题开始，以小幅改进结束。
缺点：
- 有可能仅解决一些小问题，而所有关键问题将保持不变。
该怎么办 ：项目经理，团队负责人和主持人应通过权威影响他们对团队的看法。 他们的任务是在讨论阶段引起人们对重要问题的关注。 - 对于需要大量工作的重大变更，需要额外的时间与管理层进行协调。 但是，管理层同意这些创新并不是事实。
该怎么办 ：在领导层之前捍卫您的观点是唯一的解决方案。 - 如果团队没有进行中的培训（会议，经验交流，培训），则很可能达成的决策将过时且效果不佳。
该怎么办 ：不断交流经验。 参加相关的会议，会议，内部培训。 如果我们谈论的是一家大公司，那么一个不错的选择就是演示日。 在这样的事件中，团队展示他们在工作中取得了什么成果。
在大多数情况下，可以通过调整和改进上述过程来获得帮助。 即使最初很明显只有通过吸引新的专家/团队才有可能按时完成项目，但我们强烈建议您尝试上述步骤。
如果消除瓶颈后，项目经理认为容量尚未达到所需的水平，则可以联系新团队。
为新团队准备基础架构
在这一阶段，值得进行准备工作，以减少开发的时间和成本，帮助节省开发人员的神经细胞。 让我们考虑应该满足哪些条件：
- 新团队的任务应详细说明。 您无需等待即可启动它们中的每一个-无需依赖当前或将来的任务。 概述了每个团队的职责范围。
如果不是这种情况 ，那么大多数新团队将处于闲置状态或从事对产品价值影响最小的次要任务。 - 该项目的架构是“正确的”，即 分为模块，子系统，通用组件。
如果这没有发生 ，则连接新命令将失败。 开发人员将在当前团队负责人的控制下工作，但一个人最多只能管理7-9个人。 蒂姆利德（Timlid）将被撕裂，一些团队成员将闲置，直到被赋予任务为止。
如果不可能隔离项目代码的隔离部分，但是您需要继续前进，那么可以尝试绕过此限制。 有必要通过重构将项目分为几个部分。
另一种选择-在将两个或三个人投入到项目中之后，赋予新团队越来越多的大型业务职能。 因此，团队将彼此隔离地开发项目，并且由于新的团队负责人（沉浸在微妙的环境中）将减轻主团队负责人的负担。 - 详细描述了项目中的工作过程。 例如，有一个工作流任务，该任务显示为在版本控制系统中执行（实践表明并非每个人都具有标准的GitFlow），描述了项目参与者之间的交互。
如果这没有发生 ，那么将在项目上造成混乱。 在这种情况下，项目经理将仅处理“手动”应急管理。 - 通用组件和模块具有相关的，易于理解的文档。 主要部分有单元测试和集成测试。 对整个项目的架构，通用机制以及如何应用它们的说明都有清晰的描述。 如果上述条件尚不存在，则有必要向技术债务池添加类似任务以纠正这种情况。
如果不是这种情况 ，那么增加做双重工作的风险。 将会写入不良或重复的源代码。 将来，这将导致更昂贵的项目支持。 通常，连接一个新团队意味着可能再连接几个团队。 因此，时间成本将按团队数量的倍数进行缩放。 - 有固定的代码编写规则-约定代码，用于更新数据库结构的脚本-迁移，强制性代码审查的一般原则。 尽管有很强的相似性，但可以肯定的是每个项目都有自己的特点。
如果不是这种情况 ，那么进一步支持该项目的复杂性和成本将增加很多倍。
以上条件使您可以最有效地联系新团队。 团队进入项目所需的时间显着减少。 支持和开发项目的人工成本也会发生同样的事情。
我们如何将其他团队联系到项目
我们有一个案例，说明该项目迫切需要加快开发过程。 还剩下2-3个月，直到下一个主要版本投入商业运营。 该项目本身是一个复杂的系统，由一个团队开发了3-4年。
首先，我们陷入了项目本身的环境中。 结果是该项目瓶颈的以下图片：
- 没有关于如何实现功能的准确信息。 任务，错误，改进的列表已过时。
- 没有持续的集成，开发在两个分支中进行。
- 产品测试过程未调试。 例如，质量检查工程师可以发现已经修复的错误，这会导致额外的人工成本。
- 测试用例的基础还处于初期。 各个质量检查工程师开始为自己编写案例。 因此，没有人可以在发布新版本时对产品的质量以及可能的风险做出某种评估。
- 从生产到客户认可的工作过程均未记录在案。 无法预测释放功能的确切组成以及其他不太重要的点。
经过分析，我们制定了消除以上几点的计划。 当然，团队并没有立即同意这些变更，但是在领导层的支持和明确的截止日期的制定下，我们能够说服团队中的每个成员。
我们与项目的主要人员协调行动：项目经理，团队负责人，首席分析师。 这三个人共同构成一个客户管理团队中心。 他们进一步推广解决方案并在实践中监控其实施。 没有这样的管理团队，就不可能协调三个以上团队的行动。
结果，以下过程得到了实施\优化：
- 我们在产品团队的所有成员之间建立了沟通-开发人员，分析师和测试专家。
- 他们记录了关键和复杂的功能，以实现更透明的测试，消除缺陷，解决争端以及后续工作计划。
- 优化的开发流程。 由WorkFlow和GitFlow项目采用。 他们帮助配置了持续集成并以自动模式运行自动测试。
- 我们将测试台的组装速度提高了一倍。
- 组织了适当的测试过程。 在每次迭代结束时实施回归测试。
- 介绍了迭代计划过程。
- 进行了负载测试。
根据第一次迭代的结果，我们准备了连接新团队的基础架构。 与此同时，我们的两名开发人员加入了当前的团队，以深入研究代码库。 然后其中一个成为新团队的团队负责人。 在第二次迭代中，两个团队获得了以下结果：
- 3个月后调试。
- 修复了70％的错误
- 实施了四个重要功能
- 优化并提高了部分页面加载速度的8倍
- 收到有关整个产品质量的准确信息
- 内置的路线图迭代
我相信该项目最重要的成就之一就是客户的喜悦。 他随时透明地表示项目的状态，并且按时充分履行了对企业的义务。
结论
有两种主要方法可以提高项目开发速度：消除瓶颈并提高生产能力。 在第一种情况下，开发速度可以提高30-40％，在第二种情况下可以提高70-80％。 附加命令不会使生产率双倍提高，因为会花费更多时间在多个团队之间进行交互。
扩大开发团队的关键成功因素是：
- 准备工作
- 建立的过程
- 负责促进和监督团队活动的项目团队的负责人或成员，
- 单指挥控制中心。
目前有3个团队在进行我们先前描述的项目（一个是旧的，两个是新的）。 执行的任务数量增加了
1.9倍 。