软件估计：最低可行产品

所有想要创建移动初创公司的受启发的企业家，总有想法，在最早阶段就有很多想法，而在开发过程中却有两倍。 构想这些想法至关重要，每个项目都要从确定成本和交付期限开始就很合逻辑。 换句话说，有一个估计。 必须将整个项目分成较小的块，直到每个块都可以理解并可以评估为止。

自然，它看起来很简单。 现在，我们将带您更深入地了解这一过程。 由于我们专注于移动开发，因此我们想讨论最流行的启动解决方案-为iOS应用程序开发MVP（最小可行产品）。

什么是MVP？

MVP是用最少的成本和时间创建的产品，但是它为用户提供了一定的价值和某些功能。 重要的是要记住，MVP并不是未完成的产品。 这意味着用户将获得一个可行的版本，该版本将来会收到更多功能。 MVP可以帮助您解决与常规产品相同的问题，尽管方法更简单。 例如，一个人必须在现实生活中从A点移到B点。 滑板将是一个良好的开端。 当这个人开始赚更多的钱时，他们会购买更好的车辆。

两种估算方法

可以对敏捷或固定开发方法进行估算。

敏捷开发的评估是对项目的近似评估，取决于当前可用的需求。 这不是最终的估计，而是初步的计算。 它有什么优势？

•整个过程或多或少完整时，可以在开发过程中轻松修改需求。

•即使对需求进行了概念描述，也可以给出此估计值。

•它提供迅速，这意味着较早开始开发。

•开始之前不需要深入说明； 每个产品负责人都知道，当这个想法还没有形成时，要想将所有事情都付诸实践是很困难的，而您却想不时地进行改进。

主要缺点是，该估算值可能比最终成本小几倍，因为产品所有者发起的需求变更几乎是不可避免的。

固定开发预算是根据详细要求对项目进行的精确评估。 它有什么优势？

•要求很明确，每个人都知道结果必须是什么。

•因此，期限和成本也是已知的。

缺点是：

•必须在项目启动之前就已形成所有要求。

•要求是固定的。 任何更改都会导致重新估算和基于这些估算的新合同。 换句话说，失去了灵活性。

•此估计需要更多时间。

•如果没有UI / UX设计，验收标准和产品规格，则无法进行此估算。 这会使事情变慢。

应该选择哪种方法？ 这是每个产品所有者的决定。 可以肯定地说一件事：详细的需求意味着更精确的估算，这可以实现最佳的预算计划。 定义的需求越早，实现起来就越简单和便宜。 在分析过程中，更改它们非常容易。 但是随着项目的进行，它变得越来越难。

如何准备估算要求

完美的情况是，当有设计，应用程序图或可单击的原型，并附有包含应用程序一般说明和每个屏幕或功能的文本说明的文档时。

一个示例：典型应用程序中的登录屏幕。 我们将从描述开始：

登录名必须在屏幕顶部包含公司徽标，2个输入字段（“电子邮件”和“密码”），以及“登录”，“ Facebook”，“使用条款/隐私政策”按钮， “注册”和“忘记密码？”。 点击“登录”后，带有帐户数据的请求将发送到服务器，在服务器上执行字段验证，应用程序将根据服务器的响应显示有关此操作成功或失败的消息。 轻按“ Facebook”后，应用程序会要求用户访问其帐户。 如果用户授予了权限，请输入。 如果不是，则必须显示错误消息。 在点击“使用条款/隐私政策”时，应用程序必须显示一个带有相应文本的简单屏幕。 在点击“注册”时，用户被带到注册屏幕。 在点击“忘记密码？”按钮后，用户会收到一条警报，要求您发送电子邮件以发送密码重置链接。

这种带有设计草图的描述已经显示了其中有多少个输入字段和按钮，每个字段和按钮的功能，逻辑是什么，以及将在服务器上处理哪些请求。 然后，我们可以应用敏捷方法来更改屏幕设计，通过Twitter添加登录，在输入过程中检查电子邮件的存在，添加动画和许多其他东西-其余的当然取决于愿望，想法和预算。 如果我们采用固定的开发估算值，那么此阶段必须已经有最终批准的设计，密码验证规则，用于身份验证的社交网络列表等等。 现有需求中的每项变更都需要重新估算。 除此之外，准备需求还有助于了解应用程序中的功能差距。 例如，如果有登录名，则必须进行注册。 这种形成需求的方式是简短且可理解的。 这有助于技术和非技术团队成员彼此清楚地了解。

为了创建良好的需求，决定覆盖的平台和技术很重要。 它可以是本机或跨平台开发。 本机开发产生了可以使用选定操作系统的所有功能的高响应性应用程序。 对于重视视觉部分的不同群体的大多数用户而言，本地开发是最佳的。 跨平台开发带来了为两个或多个平台开发应用程序的优势。 这最适合必须尽快启动且费用最低且可在多个平台上使用的产品。

选择平台

根据App Annie的说法，iOS是最赚钱的操作系统，因此产品所有者往往从那里开始。

当前最好的解决方案是支持最新的两个OS版本。 展望未来并定义与产品发布相关的支持的操作系统版本非常重要。 评估对尚不存在的OS版本的支持是不可能的，但是可以避免支持在发布之时就已经过时的OS版本。

最适合第一个版本仅支持iPhone的纵向方向。 该应用仍将与iPad兼容。

稍后可以添加对iPad的全面支持，但对于我们的MVP，iPhone版本已足够。

逻辑单位

您的需求应构成将分别评估的逻辑单元。 相互依赖的任务应以单元形式加入。 例如，在我们的MVP应用程序中，必须使用电子邮件和密码以及Facebook登录。 分别评估它们是合理的。 通常，每个屏幕都是一个逻辑单元，但是有时您可以将其进一步细分为几个单元。

如果估算超出预算，则分析将有助于排除最不重要的功能。 例如，可以在下一个版本的Twitter上保留登录名。 这样一来，我们就可以在不进行其他估算的情况下简化需求，并且可以做到这一点，直到获得与预算相称的估算为止。 但是，在某些情况下，削减功能毫无意义，因为不可能获得所需的MVP。 相反，可以简化应用程序中的导航，设计和动画。 创建应用程序的第一个版本时，只需使用系统动画，系统控件以及对颜色，背景，字体等进行少量自定义即可。这是在很短的时间内创建美观应用程序的一种非常简单的方法。

这些屏幕取自MobiDev的名为WhereFortune和Inspiration Quotes的应用程序，主要由带有一些自定义元素的标准控件组成。 背景和图像使应用程序变得面目全非。

有时，最好使事情变得简单，并在市场上快速推出产品，而不是等待竞争对手占领您的利基市场。

优化实施，更快地交付

测试和管理与开发并行进行。 正如实践所示，对移动应用程序的平均测试花费了大约总开发时间的30％，而管理大约花费了10％的开发和测试时间。

设计和开发也可以并行进行。 这种方法可以减少时间，但会增加成本。 开发可能会更早开始，但是会花费更多时间，因为在设计就绪之前，开发人员将必须根据可用的文本描述和个人经验来草绘界面。 设计就绪后，导航，结构等将发生变化。这需要更多时间。

我们可以说测试和管理增加了工作范围，并因此增加了成本，但是并没有增加持续时间。 换句话说，开发的持续时间基本上等于开发人员所花费的时间。

在许多情况下，后端要花费大量时间和精力，因为在那里执行最复杂的业务逻辑。 显然，带有后端的应用程序不能比后端本身更早完成。 在这种情况下，更早开始开发后端是合理的-只需通过从后端估算中减去应用估算即可计算出差异，并计划同时完成。

例如，如果后端估计要花费600个小时，而应用程序520，则应在80小时（2周）后开始应用程序的工作，这大约是设计平均所需的时间。 这是项目的完美开始：我们从设计和后端开发开始，在设计就绪之后，我们将使用已经在后端实现的一些基本功能来开始开发。 截止日期必须匹配。 当设计准备就绪时，前端开发人员将已经具有后端的设计和基本功能，从而可以轻松进行开发。 这种方法在开发成本和开发持续时间之间实现了最佳平衡。 该项目计划在下面以甘特图显示。

必须注意截止日期。 他们不应该被严重削减，因为产品的质量可能会受到影响。 一方面，不应对产品进行不断的改进以求达到无法达到的完美。 另一方面，截止日期不能总是准确地确定。 评估软件本身并不容易，但是还有许多外部因素使得无法预见一切。

风险性

这是产品所有者和开发团队面临的风险。

•存在可预测特征的周期性风险。 例如，我们知道Apple每年六月都会推出新的iOS版本，并且每年9月都会推出新一代iPhone。 每个人都知道它什么时候发生，但没人知道确切地期望什么。 因此，很难说需要对应用程序代码进行多少调整，以及使该应用程序支持新一代OS和设备需要花费多少时间。

•还存在定期风险。 例如，Facebook定期更新其iOS SDK，但没人知道它在开发过程中是否会发生，如果发生，后果将是什么。 通常，第三方库或API会带来周期性风险，因为您永远不知道下一次更新的时间。 但是人们不应该害怕更新，因为它们的缺失可能会带来更多的麻烦。

•存在随机风险。 例如，开发开始，突然有一个竞争对手出现在同一产品上。 创建模仿者不是解决方案，因此您必须考虑一些新事物，以使您的产品在竞争中处于领先地位。 您知道这是无法预料的。

风险也可以是内部的或外部的。 外部风险包括软件公司以外的所有内容：第三方库的更新，新的OS版本，市场上的新设备，竞争产品，需求变化，外部服务和服务器故障。 内部风险包括软件公司中发生的所有事情：休假，员工辞职，对团队成员的要求的误解，项目估计中的错误。

通常，所有上述风险都不是估计值，而是要考虑的-您需要了解它们并牢记它们。 对这些风险的任何估计都不过是一种猜测。 估计必须仅基于实际进行。

一个项目需要多少开发人员？

根据项目的大小，其他开发人员的参与可以加快产品开发的速度，但会增加完成任务所需的总时间。

每个后续开发人员的百分比都会增加。

让我们举个例子：项目工期为3个月 ：即480小时。 成本和持续时间成正比。 这是一个“最多500个小时”的项目，因此以后的每个开发人员都能获得+ 35％的收益。

对于2个开发人员 （当前开发人员的 +1），将有480 *（1 + 0,35 * 1）= 648小时—总计，这意味着成本增加了35％，持续时间（648/2 = 324小时）减少了1.48倍。

对于3个开发人员 （当前开发人员 +2），这是480 *（1 + 0,35 * 2）= 816小时。 持续时间为816/3 = 272小时-减少了1.79倍。

同样重要的是要理解，单独的任务不能更快地执行，相反，它们会花费时间，因为开发人员之间会进行交流，就体系结构达成共识，将代码合并到GIT中等等。您可以通过并行化任务来加快开发速度，但是其中一些只能连续完成。

让我们看一个图表，该图表显示了如何通过多个开发人员的参与来加快开发速度，以及成本如何相应地增长。 一个需要一个开发人员和3个月（480小时）的项目便可以说明这一点。

不难看出，超过3个开发人员对该项目来说是多余的。

让我们看一个耗时2500小时的项目：

参与这个项目的开发人员不得超过5个。

请注意，过多的开发人员参与较小的项目并不会带来良好的结果-他们的“空间”将太少。 对于小型初创公司和MVP，每个平台或方向一个开发人员（在极少数情况下只有两个）就足够了。 重要的是要理解， 这些计算在每个平台或方向（而不是整个项目）的多个开发人员的参与下是有效的。 在不同平台/方向上工作的开发人员不会增加开发时间。

结论

可以说，软件产品的开发需要仔细地设计其功能。 要求必须正确形成。 必须明确定义目标。 可以根据目标选择发展方式。 该应用程序的第一个版本不应功能过高。 如果预算不能满足所有需求，则某些功能可能会推迟到下一个版本，并且应定义这些功能。 产品所有者应通过使用标准UI元素或专家可能建议的其他方式来接受开发人员的建议，以节省时间。 密切注意风险并为风险做好准备至关重要。 避免仓促为一个小项目招募大团队也是一件好事。