完成概念的证明；如何计划/预测/估计剩余的工作？

Question

我们有一个实现晴天场景的概念的工作证明，但是我们需要开始处理异常路径。我们是承包商，在续签合同之前，我们需要收集详细的预算，以便与客户讨论下一阶段的问题。

详细信息

我们花了10-20个月的时间在JavaScript中实现了概念库的证明。它涉及浏览器API，第三方库，并连接到我们客户的专有服务器软件，为双向实时通信。目前，这个库运行在客户端编写的HTML+JavaScript UI后面。在不久的将来，他们也将以sdk的形式发布这个库。

到目前为止，我们主要集中在晴天场景上，把概念的证据放在一起。现在已经完成了，我们需要在库的不同区域实现库的成熟，并支持雨天场景，包括：

• sdk用户通过API提供的坏数据
• 代码中的错误路径
• 浏览器API和第三方库的合法错误响应
• 网络问题(抖动、带宽限制、临时断开等)

问题:我们可以遵循什么样的过程来生成一个合理的任务列表，列出我们不应该支持的雨天场景。换句话说:如何在(1)我对概念应用程序的证明和(2)一个假设的、成熟的、健壮的、实现相同特性的应用程序(

)之间找出缺少什么？

我也感兴趣的回溯类型建议，我们可以做什么，同时实现概念的证明，使它更容易逐项这项工作。

我会在真空中做什么

如果没有任何更好的建议，我将对我编写的代码、第三方库和浏览器apis的规范进行静态分析，并确定可能的错误案例。从整体开始，我会把它划分为组件、子组件等等。当我达到足够的粒度时，我会执行静态分析或分析规范，并逐项列出它可能失败的方式(合法错误输出、合理的异常案例等等)。然后，我会将每个子组件、然后组件的这些故障模式聚合到一起，然后返回到整体上，我将有一个我需要支持的雨天场景列表。

与此有关的问题：

1. 我怎么才能避免错过一些重要的东西？
2. 有没有办法避免逐行分析代码和规范？
3. 我们需要优先考虑这些不时之需--我们如何将列表划分为更重要和不太重要的部分？(可能会发生？)
4. 如何将特定方法/apis的特定错误案例列表聚合到足够高的级别，以使项目能够决定什么/多少/什么时候？(这与最后一个关于优先次序的问题密切相关)

更新:我做了一个失效模式影响分析( FMEA )，它有助于分析系统边界--与网络、公共API的使用者以及第三方api层(在较小程度上)的错误有关的雨天场景。FMEA流程建议使用不同的团队来生成可能的故障列表，这将有助于解决我的问题#1 (如何避免遗漏一些重要的内容)。它还处理#3 (如何确定优先级)，根据故障的严重程度、发生的可能性和被检测到的可能性，给出优先级度量。它没有帮助我(在这一点上)为我们编写的代码提供一个紧急场景列表，它也没有解决我的问题#2和#4。

Answer 1

我通常建议不要开发这样的程序。获取一个原型，并“销售它”作为良好的工作，一旦所有的路径是固定的，通常是移交给一个投资回报率的每一个小错误。在不久的将来，你会听到一件事，那就是“有多少用户会看到这一点，不，我不会付钱来修复的。”

然而，我的返程机器目前在商店，所以我们继续前进。首先，不要说“产品是做的，除了.”。再说一次，你花了15个月开发这个产品。从现在开始，你想做的每一件事都是“值得吗？”如果你说“需要加指甲油”或“只是需要一些圆角”之类的话，你会在一个更好的地方。这很容易解释，房子是建的，但仍然需要油漆，然后它是看一所房子已经建成，并试图解释它还没有建成。

要明白，首先使用这个原型方法构建的是一个糟糕的产品。很管用，你刚刚说是的。只是效果不太好，这就是你未来的奋斗方向。作为一个承包商，如果你不小心，你甚至可能工作到一个地方，你的饮食收费时间。

再考虑一栋房子。你建了一座。你付钱。现在你去旅游，它看起来很好，不是很棒，但很好。稍后，当你开始仔细观察时，你会注意到其中一堵墙比它应该要短。你提出来了，但是建设者说：“我们知道，我们说过还有一些事情还没有完成，这将是另一个$X。”你会怎么回应。

我知道这似乎是我挑选，但这是非常重要的是，正确的框架，以避免尽可能多的问题。

现在，谈技术问题。你有两个目标。首先，“油漆作业”的总成本必须低于发展的总成本。其次，你需要确保图书馆正常工作。

因此，实施一个参考项目。使用类似于https://github.com/lord/slate的内容，并记录如何使用库。确保每种方法都有积极和消极的反应。foo(1)会这样做，但是调用foo("sting")会抛出一个错误。在构建参考项目时，您可以识别和修复库中的问题，而不必在许多情况下直接对该项目进行成本处理。这使您可以避免“油漆作业必须降低成本”的问题，同时仍然给您的地方，以账单，如果您需要。

大多数人更愿意为一个示例项目和文档付费。大多数人都愿意接受好的文档是有代价的。大多数人甚至会明白，在文档过程中，错误会被发现并修复。因此，您将获得一个新的存储桶，并在库中找到最关键的问题。

接受它不会找到一切的事实。但那是你把项目放进去的地方。现在你玩ROI游戏早于你该做的事。这将发现最关键的问题。

至于估计你的时间，我可以说是你的项目时间的两倍。您在库上花费了15个月，在参考项目和文档上花费了30个月。它是完美的，不是，但它很容易理解，并给你一个地方开始。

Answer 2

这可能是一个可怕而艰巨的任务，如果您设计的东西不是着眼于可扩展性。如果你是的话，这不应该太糟。

您的第一项任务是确定代码的边界--哪些是可公开使用的和可更改的，哪些是可公开可见的但不能公开修改的，哪些是您的层的完全内部的。

从这里开始，您需要考虑两个主要问题：

• 确保私事实际上是私密的。在允许您这样做的语言中，这意味着私有字段实际上被标记为私有；在JS/ES中，您将不得不依赖命名约定(例如，您可能会决定所有“私有”变量都以"__“为前缀，并在适当的情况下具有不以这种方式前缀的getter和/或setter)。
• 确保以某种方式对所有用例进行解释。您希望确保人们能够访问他们在您的层之外所需的内容。

您可能希望围绕这两件事编写显式测试。

一旦解决了这些问题，您可能希望尝试作为您层的使用者来实现一些东西。这将有助于确保您的习语在其他生态系统中运行良好，并将有助于查找任何无法访问但应该使用的内容。

与所有这些并行的是，如果您还没有测试，则应该添加它们。至少您需要单元测试，但理想情况下，您已经获得了这些测试--但是，听起来您可能没有太多涵盖失败案例的测试。现在是添加这些内容的好时机:如果传入格式不正确的日期会发生什么？负数？小数？包含一些SQL的字符串？

现在也是开始添加集成测试的非常合适的时候。这些集成测试将是尝试解释网络问题的好地方。

那么，你是如何向你的客户展示这个的呢？这将取决于你与他们的关系以及你目前的发展准则。如果您一直在sprint中工作，我建议您致力于一项探索，它的输出将是一个更详细的列表，列出哪些领域需要工作，哪些领域目前看起来很好。

如果客户希望在什么日期之前完成工作的详细记录.这可能是一个问题，因为您需要开始做一些工作，以估计这一点。但是，所有的希望都没有失去--你仍然可以估计一些日期，用于“初步分析”、“编写失败的测试”、“修复失败的案例”，以及可能的一轮验收测试。多长时间将取决于您的应用程序的大小和复杂性，但请记住，您总是希望估计的值比您实际需要的要高。如果他们拒绝，看看你是否能达成协议--也许“好吧，我会分配一周时间(而不是要求的两个月)来完成这个任务，但只给这个子系统。完成之后，我们将用修改后的估计重新审视其他系统，允许我们在处理这个子系统时使用我们所学到的知识。”这给了你一些回旋余地-你可能会找到一些更大努力的好捷径，你可能会发现最初要求的两个月有点夸大了。另一方面，如果遇到具体的问题，这意味着您肯定需要整整两个月的时间，您可以为客户提供一个具体的说明，说明那个阻止程序是什么(而不是一般的“好吧，我很确定这会很难”)。