当最终目标是在移动设备上创造出尽可能最高品质的用户体验时，那么说事实上只有原生应用开发一条路可走，这一点应该没有人质疑。但是在一个自带设备（BYOD）的世界里，面对至少四个主流的自有平台，每一个都有自己特定的开发工具包和API,组织如何才能有效地交付移动应用，既能针对每一个特定的平台又不会彻底花光IT预算呢？

    移动开发的错误方法

    全力以赴，为每个平台投入一支团队的做法是错误的，但令人沮丧的是，许多组织正是这样做的。最后的结果是不可避免的-每支团队单独开发相同的服务和功能，所有东西都是并行开发。

    “许多组织通过设置独立团队来实现移动化，”Giles Alexander说：“你的Android团队是外包的，iOS团队是内部的，然后你还得跟一整支外部团队签约进行BlackBerry或Windows Phone开发。这些团队基本上提供的都是相同的功能，但完全都是各搞各的。”Giles Alexander是ThoughtWorks专门从事移动应用架构和策略的首席开发员兼顾问。

    干IT的都知道任何一个应用开发项目都很有可能会失败。四个项目同时进行，那么项目的失败几率就会提高到4倍。还有就是，四个不同项目支撑四个不同的平台，随着时间的推移，错误修改和功能增强会变得愈发难以为继。幸运的是，还有一个更好的方法，得到了越来越多组织的采纳。

    移动开发的新趋势

    在一个已经成为成功的趋势下，前瞻性组织正在摒弃平台碎片移动开发流程，转而采用强调普遍性的基于功能的办法。平台之间的区别和差异最终只会集中体现为UI开发问题。

    这种演进方案又被成为Y型开发法，因为跟一堆各自为政的独立式开发相比，其开发流看起来更像字母Y.“Y型交付方法与你的团队而非平台相适应，” ThoughtWorks的Giles Alexander说：“团队可以不受限制，不必只开发移动前端，也可以在整个组织范围内针对功能进行调整。”

    最后的结果是一支团队有效地开发出一个端到端的功能，而不是让四个团队重复工作。相比于革命性创意，这听起来更像是常识，但有时候在急匆匆把移动产品推向市场的狂潮中常识就是会被晾到一边。

    Y方法论初识

    考虑到这一方法论的敏感性，如何让有兴趣涉足移动开发领域的组织采纳这种特别的方法？“也许你必须在后端有范围地选择来开始，”Giles说：“比方说你有一组服务是把对产品至关重要的数据暴露出来的，你希望围绕着这个做出一项新的移动功能来。你应该能够把一支可以摆弄这些服务的团队凑在一起，然后让他们以适合于移动的方式把服务开放出来。然后让同样一支团队做UI,再把这些功能做到Android、iOS、黑莓或移动web上去-你认为哪个最适合支持就做哪个。”

    当然，你不能完全无视现实，这三个市场上最流行的移动平台是存在独特差别的。此外，给定团队的特定成员的技能更适合于Android、iOS或Windows Phone中的某一个也是不可避免的。任何一项好的开发策略都需要考虑这些实际情况。这就是基于线性、功能驱动的开发方法要做一点分支，弄出个Y型开发方法论来。

    “团队的前端可能需要分割一下。相对于iOS,有的人可能更适合做Android开发者，所以你最后在顶部的位置略微需要分隔开来-Y预示就出来了，”Giles说。

    采取这种略新一点的移动应用开发法可以省钱省时，并使得应用的功能改进和长期维护更加可管理。组织应该开始考虑打破独立式的开发方法，采用更加流水化、基于功能的精益移动开发法。“这关乎专注功能、交付功能以及从功能交付中学习。”
 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。