如何在2个月内启动移动应用并执行敏捷转型

我将向您介绍一个故事，我的团队如何在短短2个月内启动iOS和Android应用的票务服务，如何轻松完成从Waterfall到Agile的过渡。 首先，我将描述项目的起点，软件开发流程之前的工作方式，并将重点介绍有助于我们取得成功的关键活动。 本文无意取代Jeff Sutherland的《敏捷宣言》或《 The Scrum》。 相反，我将告诉您，我们如何改变工作流程以更快地交付产品，而无需雇用大量敏捷教练和Scrum大师。 对于想开始自己的家庭项目的人们来说，本文也将是有用的。 我将向您展示在特定时间值得关注的重点，而不是重点。 所以，让我们开始🙂

这一切始于大约5年前。 我刚刚加入了一家俄罗斯的大型媒体公司，该公司有很多不同的产品：很少的在线报纸，娱乐服务，体育门户等。此外，我还向您介绍了这项票务服务。 该服务的主要功能是销售在线电影院，剧院，体育赛事的电子机票，使用户无需预定现金平台即可预订最佳座位。

幸运的是，我们已经在运行桌面和移动网站。 服务非常成功。 与往常一样，有一些限制。 不想打扰您的数字，只会说移动网站的表现不如预期。 这样做的主要原因是：

• 过时的UI设计
• 可用性问题
• 无法查看座位图

当然，可以解决第一个和第二个问题，但要提供功能齐全的座位图并进行离线票务存储肯定需要使用移动应用程序。 您应该在这里询问用户如何在不查看移动网站上座位图的情况下购买机票。 这是一个很好的问题。 后端团队的同事开发了一种算法，该算法会自动选择尽可能靠近中心的座位。 有时效果很好，有时效果不佳，有时客户想在最后一个“亲吻”行预订座位，而无法这样做。 但是，将应用程序与网站进行比较的好处是另一篇文章的绝妙主意，因此，在此我要说的是，我们很确定需要启动该应用程序。

除网站外，我们还有一个用于合作伙伴网站的XML API，可让他们获取地点，事件和时间表的列表，并能够在弹出窗口中购买门票。 现在您应该了解我们项目的起点。

如上所述，我们在工作中广泛使用了Waterfall方法。 我们将iOS，Android，设计，质量检查，后端团队和项目经理大军分开了。 因此，当我的项目经理首次与我联系这个令人兴奋的新项目时，我很高兴从头开始在这家公司开始我的第一个产品。 但是初次见面后，我所有的幸福都消失了。 发生了什么？ 这次会议的主要目的是根据我们只有很少的UI设计来估计发布日期。 我们发现

• 用户界面设计不完整，缺少很多屏幕
• 我们获得的用户界面非常复杂，具有许多复杂的手势和动画，用户难以理解和使用，并且难以实施
• 技术要求甚至还没有接近完成
• 后端团队在接下来的几个月里很忙

这就是为什么我们发现我们无法进行估算来为此项目保留移动开发人员的资源。 老实说，我们实际上无法预测发布日期。 当然，我们可以说大约需要6个月的时间。 但是，如果您对如此庞大的应用程序的整体数量和复杂性一无所知，那么您的估计将非常不准确。 对于瀑布队来说，这是很平常的情况。 为了解决这个问题，我建议首先使用我们自己的UI设计并在第一个版本中启动少量重要功能，然后再发布最低价值产品（MVP），其余所有功能都留给我们应用的下一版本。 这个想法看起来很新鲜和令人兴奋，我们决定尝试一下。

技术要求和我们提供的UI设计屏幕中有很多功能。 我们清楚地了解到，我们无法开发出能够保持最高质量的产品。 敏捷来了！

我们写下了所有功能的列表，并问自己：“哪个功能最重要？ 如果没有我们的应用程序的哪些功能，将无法使用？”

以下是为我们的产品定义的关键功能的列表：

• 电影院名单
• 电影清单
• 时间表
• 座位图
• 进行购买
• 购票

这么简单 只有6个屏幕。 我们试图尽可能减少屏幕的数量，以使购买过程更简单，更快捷，最后，我们将其减少到仅4个步骤：拾取电影院或电影，从时间表屏幕中选择合适的时间，然后选择座位图上的座位并进行购买。 没有这些功能，我们的应用程序将无法运行。 没有精美的动画，没有复杂的手势，没有自定义控件。 相反，系统提供的基于选项卡的导航是带有最少自定义项的标准UI控件。 我们致力于为客户提供内容而不是界面 。 这就是我们实际上如何构建一个出色的用户界面的方法，该界面在WWDC UI设计实验室会议上获得了A +分 。

在与团队合作期间，我们还讨论了许多其他很棒的想法，例如，我们非常确定存储用户的信用卡数据以备将来购买时会大大提高转换率。 但是，这将花费大量的开发时间，PCI DSS认证过程并不容易。 相反，我们决定使用WebView进行付款，与我们网站上的WebView相同。 因此，这是将来发行版应积压的许多功能之一。

为了估算要完成的工作总量并跟踪我们的进度，我们创建了一个屏幕地图 。 这是一个巨大的图像文件，其中包含应用程序的所有屏幕，这些屏幕由代表屏幕到屏幕过渡的箭头连接。 屏幕地图是构建移动应用程序甚至台式机网站的便捷工具。

专注于定义产品的关键功能。 并把其他所有待发行的产品都积压下来。 请记住，您要为客户提供内容而不是界面。

现在，当我们得到一个屏幕地图时，我们就能够了解我们需要什么API。 但是后端团队非常忙，我们这里遇到了瓶颈。 幸运的是，我们能够估计需要完成的工作量，[这里发生了奇迹]，我们安排了4周的后端开发人员时间。

我们之前是如何与其他团队合作的？ 当您需要其他团队来做某事时，您应该询问您的项目经理，他或她去带那个任务的那个团队的经理。 当我们只有4周的时间时，完成任务的路就太长了。 因此，相反，我们仅为该项目创建了一个新的小型团队，并将其放入我们的开发人员中。 我们在JIRA中拥有自己的项目，没有积压，并且不接受来自其他项目的任何传入任务以完全专注于我们的应用程序。 我们的团队包括：

• 我是经理，负责创建任务，在团队成员之间提供沟通并推动所有开发过程
• 2位iOS开发人员
• 2位Android开发人员
• 后端开发人员
• 设计师

现在，当我们拥有一个团队并且知道我们需要开发的基本功能时，我们需要确保我们都在执行正确的任务。 但是正确的任务是什么？ 它是一种以最短的方式为我们的客户提供功能的工具。 UI设计就是一个很好的例子。 我要求我们的设计师创建尽可能接近本机的UI，因为它对用户很熟悉并且易于开发人员实现。 因此， 我们为设计师举办了一个简短的研讨会，告诉他们我们拥有哪些标准UI控件和动画以及如何自定义它 。 我们启动了“设计审查”流程，在该流程中，我们与团队内部一起讨论了每个屏幕：设计师试图使其外观更好，开发人员也更容易实现。 我们能够在团队内部开发和维护此沟通过程，这使我们取得了成功。 我们几乎完成了相同的开发API：后端和移动开发人员正在查看UI屏幕，并编写了双方都方便的API协议。

让您的队友互相交流，讨论实现任务的最佳方法。 这将帮助他们更快地提供更好的解决方案。

成功的另一个关键因素是让我们的团队独立做出决策，而无需花费数小时的会议来减少沟通链。 在上一段中，我提到在应用程序开发过程中，您应该专注于关键功能，尝试尽快提供它们，然后再转移到另一个功能。 在这里，我将向您展示一些我们在主要功能开发过程中制作的小型功能的示例。 这些不是计划中的，但是易于实施，因此我们决定将它们包含在我们的第一个版本中。 所有这些都极大地改善了用户体验和转换率。

第一个功能是脱机搜索。 我们在网站上有一个搜索字段，但它是全文搜索，可提供所有类别的所有结果（即，一个电影和地点搜索字段）。 我们在第二个版本的待办事项列表中拥有此功能，但我的团队向我抱怨说，在电影院列表中找到测试实体花费的时间太长。 这实际上减慢了所有开发速度。 我们讨论了这个问题，发现我们的应用程序中已经有了所有电影的列表，现在可以轻松地在列表顶部添加系统提供的搜索栏。 每个平台花了大约2个小时，而后端没有任何变化，从而极大地提高了应用程序的可用性。

第二个功能再次源自我队友的想法。 有时，售票系统可能要花费一分钟才能提供实际的座位图。 这给尝试测试自己所做工作的开发人员带来了很多痛苦。 根据电影院的不同，票务系统会在电影开始前的某个时间停止出售门票，否则可能没有剩余的可用座位。 用户必须等待座位图加载才能获取此信息。 我们找到了一个简单的解决方案：在后端添加一个检查并在计划中的每个时间向API标记是否可以购买。 时间表屏幕上的价格标签是另一个好主意。 最初，我们还没有考虑过。 但是有些人喜欢在不同的时间买到价格更便宜的门票，这是现实生活中的洞察力。 如果用户可以在日程安排屏幕上看到价格，那么他或她就不必在高峰时段加载座位图时等待，可以直接购买便宜的机票。 通过实现这些功能，我们不仅提高了可用性，还减少了对后端的请求数量。 因此，这是一个双赢。

另一个快速的胜利是在座位图上的圆形座位。 最初，我们的设计师绘制了带有圆角的方形座位图标，看起来非常不错。 但是有一天，我的一个家伙发现了一家电影院，座位图上有几排圆形的电影院。 看起来很糟糕，非常糟糕。 因此，我们尝试创建一些复杂的方程式，以根据行舍入的半径计算座椅旋转角度。 最终，我发现我们可以将座位变成圆形而不是正方形，并且因为它是圆形的，所以我们不需要旋转圆形座位。

您的团队是产品的非常重要的焦点小组。 他们实际上是新功能的第一批用户。 听他们讲，给他们做决定的自由，他们会带给您很多聪明的主意！

在下一个版本的待办事项中，我们有很多功能，而且很难找出我们应该首先实现的功能。 我们决定开始研究用户的行为。 我们应用程序的全部目的是帮助客户购买机票。 因此，第二版的主要目标是向我们提供有关客户如何寻找机票的见解：

• 他们是从看电影还是看电影开始？
• 我们的客户在特定屏幕上花费多少时间？
• 用户为什么关闭付款屏幕？

收集了一些数据之后，我们就可以对积压工作进行优先排序。 例如，我们的第三个版本选择了预告片，特色电影和经常光顾的电影院。 主要是因为这些功能估计的开发时间短，并且对转化率有一些积极的影响。 当然，存储信用卡数据将对转换产生更大的影响，但是上述三个功能均在一周内完成，而花了2个月多的时间才获得了存储卡数据所需的PCI DSS认证。 我不是说您应该只做较小的任务。 取而代之的是，在快速获胜和保证长期利益的重大任务之间找到平衡始终是更好的选择。

我建议从最初的发行版开始研究用户的行为，以确保您的团队朝着正确的方向发展。 然后根据从数据中获得的见解调整待办事项[优先级]。

最后，我们启动了该应用程序。 仅仅两个月。 与其他产品相比，这是非常短的时间。 是的，它没有像利益相关者所希望的那样完全发挥作用，但这只是第一步。

我们的新方法并不太接近Scrum，更像是看板，当您需要在短时间内推出新产品时，这非常有用。 从Waterfall的过渡丝毫不费吹灰之力，实际上，我们享受了新的合作方式，影响了我们构建的应用程序并每周获得新结果。

感谢您的阅读！