对建立我们的初创企业MVP的早期见解

这篇文章的最初重点是详细介绍我们在构建Availo iOS App初始版本时采用的过程。 这是一个相当普遍的话题，因此我想将其重点放在我们在较浅的文章中采用的实践。

经验告诉我们，在任何类型的开发项目中进行少量规划都会大有帮助，在开发初始产品版本或MVP时更是如此。 如果一切都按计划进行，那么您的第一个版本将随着功能的增长而发展。 考虑到这一点，重要的是要事先计划-没有人可以安全地押注其产品将在几英里之外的地方，因此，从一开始就考虑这些演变是很重要的。

在Availo，我们的开发团队来自在各种规模的组织中从事多种类型项目的多年经验，以下只是我们用于创建初始版本的过程的一小部分见解。

大辩论

从Availo的角度来看，我们始终会使用IOS进行初始版本发布-我们的创建团队由IOS开发人员组成，众所周知，IOS开发可以在Android和Android中更快地进行开发，这将大大减少我们针对发行版的测试过程。 在最终发布的前3到6个月内，Android才是我们的发展路线，所以请不要担心！

管理期望

就像任何好的项目计划一样，团队的想法也可能是巨大的，路线图很长，并且对潜在用户的期望不断提高，因此，保持一切正常并专注于关键命题功能是根本。 在早期的团队会议中，我们讨论并强调了我们可以看到的关键领域，涉及到各个业务领域，而对于开发方面，向我们展示潜在合作伙伴和投资者的进展非常重要。 这些人对顶级功能和您的路线图感兴趣-他们对早期的细节不感兴趣-可以在MVP之后建立类似的领域。 当您在项目中设置发布的关键日期时，找到功能丰富和无错误之间的平衡非常重要。

设定焦点

对于Availo，我们能够将应用程序划分为两个关键区域，即用户个人资料和消息传递。 即将出现一些重大更新，但这始终是Availo早期的重点-向自由职业者展示并允许用户尽可能轻松，轻松地开始交流。

现在，对于未经训练的人来说，这似乎是一个很小的功能集，在只有2个权利之后？ 但是请稍等…一旦我们中断了用户旅程，我们需要满足许多情况。 这就是发挥敏捷开发方法之美的地方-在sprint中工作并确定关键的用户故事/旅程。 目前，我们还没有一个功能全面的消息传递平台可与WhatsApp和Facebook Messenger等竞争，我们可以在其中发送gif，视频和群聊等，这些都是我们可以轻松传递给将来版本的详细信息。

设置项目

作为项目的唯一开发者有时可能会很棒，尤其是在像我们这样的地方开始的时候，通常它会由一个在每个领域都有专家的小团队组成（例如，设计，管理，开发），但是有时候我们每个人都需要一点在我们的生活中进行互动，并使之尽可能地无痛，这对于灵魂来说是非常重要的。 编码标准，文件夹结构，创作证书和服务器选择都是您进行决策所需要的所有方面。

任何一支优秀的团队，无论大小，都会有一套清晰的编码风格指南（我们都看过“ Spaces or Tabs”辩论情节）。 编码标准使团队知道如何以一种结构来编写其代码，该结构可确保以一致的方式对大型项目进行编码，这种方式更易于理解，还使新开发人员可以看到如何编写代码库。 如果一切按计划进行，那么您的团队将需要发展，没有人喜欢脾气暴躁的开发人员。

依赖管理

在Availo，我们非常喜欢Cocoapods的依赖性管理。 对于尚未签出的任何iOS开发人员，请务必查看。 CocoaPods由EloyDurán在2011年创建，旨在解决依赖关系并下载所需的源代码。 从最高级别的角度来看，这是管理您可能在应用程序中使用的任何第三方库的一种非常快捷简便的方法-从内部管理的角度来看，根据需要轻松添加，删除和更新库它们在提交中没有git子模块的痕迹。

什么……没有情节提要？

经过数年的应用开发，我们的团队对有无故事板的应用构建方式有了很好的了解。 故事板非常适合通过自动布局可视化应用程序的结构和视图的布局。 使用Availo，我们选择使用完全基于代码的界面-没有Storyboard或Xib，都采用手工编码，尽管我们确实使用了第三方软件（例如PaintCode和QuartzCode）来实现复杂的动画和视觉效果。

随着应用程序变得越来越复杂，以及视觉效果和交互的要求变得越来越复杂，情节提要很容易变成一团糟的视图和话题，仅提供概述布局的指示。

每个人在职业生涯的某个时候都必须处理情节提要合并冲突，将节或视图拆分为情节提要是与多个开发人员合作时解决此问题的最佳方法，但如果不迅速向开发人员表示赞同，这不是防弹方案。他们正在处理应用程序的哪个区域。

随着iOS 8中的Adaptive Layout和Size类的引入，许多开发人员开始采用Storyboard概念，但感觉就像我们现在返回了完整周期一样。最终，开发人员在编码时可以更有效地工作。 检查深度并在“界面”构建器中查找隐藏的视图，因为有人在可见框上打了勾，这只是其中之一，我们都希望花更少的时间挠头。

这里还有一些其他值得考虑的问题，对不起您的大脑……

•如果您使用它进行编码，则与切换和退出Interface Builder相比，您将更快地学习Swift / Obj-C。

•您无法像在代码中那样“查找并替换”

•如果您只需要学习代码，则将项目移植到Android会容易得多

•代码审查需要更多的工作

讯息传递

Availo最大的领域之一就是消息传递-像任何非消息传递初创公司一样，我们从来没有希望为MVP建立自己的消息传递平台。 我们可能会深入研究此问题，但到目前为止，我们已经采用了可以满足一些基本要求的解决方案

•允许用户查找，发起和与其他用户进行对话

•允许用户管理与其他用户的对话-即存档，删除

•向用户发送有关消息的推送通知

再次，通过我们的开发人员的经验，我们的开发人员在一些消息传递平台上有了经验并做出了决定-我们最终消息传递平台的原因是自己发表，但是通过分解需求和产品路线图，我们能够相对轻松地实现上述功能几天的过程。 在该领域中，有一些大型企业可以通过多种交付方式（例如ip消息传递，语音呼叫，短信）提供出色的解决方案和产品。 做一些功课，然后尝试一些尝试—在小型实现上的代码示例和测试是查看平台是否适合您和您的团队一起使用的好方法😉

单元测试和错误跟踪

在理想的世界中“在代码之前编写测试”……对吗？ 在构建的整个开发阶段，我们一直在进行一些设计，这些设计虽然已获得批准，但仍在不断发展……敏捷之美对吗？ 当我们倒计时到Beta版本时，这些仍将由用户组和我们的创意团队再次进行审查。 能够为构建的每个方面编写单元测试将是很棒的，但是就像任何团队都会经常告诉您的那样，这不仅不会发生。 截止日期仍然需要满足，您有一个测试团队来了解错误，对吗？ 在Availo，我们希望让人们拥有自己部门的所有权，目前我们仍然是一个非常小的团队（不到10岁），随着我们的成长，我们需要建立正确的基础。 这并不是说我们不进行单元测试。

在早期开发的初始阶段之后，我们已完全采用了包括UITests在内的单元测试以及包括超时在内的Restful服务的测试。 我们之所以推迟这一点，只是因为我们正在努力制定时间表，试图在会议和演示之前及时建立我们的MVP。

我想我想说的是，有时候自我解释可能会起很大的作用……从代理商的经验来看，与潜在的开发人员在最初的简报中所听到的相比，在最初的简报中不多提及单元测试是很常见的。 我们从一开始就合并了Fabric-Crashyltics非常擅长让我们发布野外遇到的任何问题-上瘾的莫过于在旅途中，在网络中，在无线网络中进行测试您的应用程序。 Fi-用户可以在现实生活中发现自己在使用您的产品。

向前进

因此，在一个相当宽松的开发周期之后，我们现在应该倒计时了，我们现在可以算作我们的早期版本了-最终修订，新加入的测试人员以及增加的最后几个功能。

我知道这是对我们的开发过程的相当基本的概述-如果您感到我们想念并想问的任何事情-感到自由，承担一个新项目并领导这个不断发展的部门可能是一项艰巨的任务。