一个团队进行设计，另一个团队进行编码

我将参与一个项目，该项目的所有软件设计均由本地团队进行，然后将这些设计发送给离岸团队进行编码。

这是我第一次面对具有这种特征的项目，这对我来说有点奇怪：经理们希望我们制定非常详细的设计文件，因此离岸团队没有错误的余地。从我的角度来看，它们使我们可以在纸上进行编码，而我们可以在IDE中进行编码。

所以，我的问题是这种方法是好的还是正确的？我们的软件流程要在项目中取得成功，必须考虑哪些主要考虑因素？

我的意见：

如果您要给离岸人员提供的仅仅是文件和图表，那么您将有很多沟通不畅和失望的地方。

我的建议

• 不要给他们太多文档，而是给它们接口和抽象类，以便将它们束缚到您的设计目标中。

• 要求他们使用已知的命名标准。

• 要求他们使用单元测试。

• 将您的设计师/建筑师之一派到他们的办公场所进行监督，这仍然比内部编码便宜，但是您将获得更好的结果。

它被称为Big Design Upfront，又名瀑布。它没有被广泛认为是一种非常成功的方法。但是我已经看到了它的工作原理，当它工作时，效果很好。正确的做法非常昂贵。

这也是您的雇主要求您做的。

离岸团队不像岸上团队那样工作。您必须对想要的东西非常非常具体，否则您将无法获得想要的东西。

我的最后一个项目是软件设计师。所有开发都在海上进行。我们成功了。因此，此过程可以正常工作。

我确实制作了很多文档，但是它绝不是全面的，也不是逐步的说明，也不是详细的类名，函数名等。例如，我制作了序列图，用例，工作流，系统和集成。图，以及所需的更详细的设计文档。

这实际上取决于您对离岸开发的信任程度。我相信我的离岸团队能够胜任开发。就是说，我提供了总体指导，但给了他们留出余地来实施，这使海上团队感到满意。过去，它们是由微观管理的。在某些情况下，我会根据需要使用设计模式指导他们。我还定期对他们编写的代码进行代码审查和分析，并建议重构或清理工作。另外，由于一些团队在使用休闲车时发生了意外，因此我最终在实施过程中编写了一些故事，因为我们最终缺少了一些资源。

此外，我认为此过程实际上仅凭您项目中的技术主管以及业务，设计师，主管和开发人员之间的沟通才能成功。我们确实花了很多时间讨论每个功能和故事，并确保离岸线索/资源对要求有足够的了解。如果他们在功能/故事复审过程中没有提出问题，则可能会遇到一些问题。在获得业务批准之前，工作还没有完成。这使每个人都承担责任，因为在管理敏捷开发的工具中跟踪了所有内容。

正如已经提到的其他答案之一一样，开发过程包括命名标准（内置了“ shaperper”规则），测试用例覆盖率（它使用了TDD，Mocking等），因此，如果有适当的编码过程和程序，它将增加您获得成功项目的机会。

离岸开发的主要成本是通讯。文档是一种交流方式，但是，文档通常无法涵盖所有​​详细信息和潜在更改。

不确定您的项目有多大。我认为这很大，否则使用离岸开发团队就没有价值。因此，我的经验是

1. 定义框架代码，公共接口，服务接口等，并一起查看
2. 与另一方定义验收测试
3. 将大文档拆分为小故事，然后根据小故事进行工作。大文件只是整个系统的全景
4. 设置故事的检查点，一两个星期

1和2实际上是关于开发的，以确保另一方很好地理解需求，并且双方都使用相同的模式。3和4是敏捷开发方法论的一部分，但是对于离岸开发，很难使用完整的敏捷过程。

我认为在某种程度上我们大家都那样工作。某人在某处进行设计，然后我们对系统中的一部分进行编码或与该系统一起工作。例如，基于框架构建应用程序，例如移动设备上的非游戏应用程序。构造框架的人员的设计团队已做出许多UI决定。他们控制着从学习编写应用到销售应用的所有过程。如果要查看此模型成功的原因，只需查看一些供应商提供的文档和工具数量。

另一个示例是Web应用程序，其中许多尝试实现REST样式。尽管有关于如何使用HTTP的规范，但这一章并没有真正说明如何实现某些内容。无论如何，有一些规范和指导原则可以遵循。如果您看到关于在堆栈交换或工作场所上实现REST的大量讨论，就好像有一位架构师告诉人们以某些方式实现某些事情。我认为它仍然是成功的模型，有很多人效仿这种风格。

从这两个例子中，您可以看到设计是如何传播的，有的是纸质规格，有的是书籍，工具和实例。您可以看到人们如何（在数量上）询问，如何根据他们要遵循的标准/设计不同程度地正确理解。只需转到stackoverflow并观察;）

如果您给我您的规格，我会问。如果您给我单元测试，我将进行编码和测试。