IBM面向小型设计和开发团队的一个渐进实现方法

了解 IBM CIO Lab Mobile Innovation 团队如何快速开发出一个内部解决方案,让用户可以跨其所有支持的平台进行简单、灵活的文件共享,从而提高用户的生产效率。

IBM 的 CIO Lab Mobile Innovation 团队开发了内部解决方案来帮助 IBM 员工更加高效、安全地使用其移动设备。在 2010 年晚些时候,员工们难以跨其笔记本电脑、移动设备和平板电脑共享文件。从移动设备上对典型内容管理系统或共享文件系统的访问受限且比较麻烦。没有插件的辅助,在转移时某些文件不会渲染或运作。而且文件在台式机和移动设备之间不易移植。

我们团队需要提供给员工一个可移植的解决方案,以便通过支持的设备访问 IBM 内部内容。我们决定开发一个试验解决方案来充当访问其全部数据的窗口,并且提供对便携式数据的小缓存。便携式数据会被转化为可兼容的格式,以帮助用户更好地利用各个平台上的内容。我们调用了 MyMobileHub 项目。由于只有一个小团队和几个月的时间,我们需要随着跨 Android、BlackBerry 和 iOS 平台的启动来展示概念证明。几个月之后,我们会需要在本地进行功能试验。

本文中讨论的、我们在试验中使用的很多快速开发概念在移动开发领域是众所周知的。看一下我们如何将它们组合起来,开发一个多设备、端到端的内部解决方案,并且您可以了解可以多快为您的下一个移动试验或项目做同样的事情。

规划一个快速开发试验

创新试验通常是一个迭代过程:快速开发一个可用的解决方案,与一群关系密切的同事和早期采用者共享该解决方案。然后随用户群扩展功能,以评论和建议作为航标。这是探讨新解决方案的一个常用协议。

为在快速发展的移动领域有一个成功的试验,我们需要有一个全然不同的开发方法。我们探讨了大量可帮助我们的可重用技术。我们选择了将开源技术与 IBM 内部工具结合起来,这符合快速开发、跨平台支持和尖端功能等条件。

在服务器端,我们选择了 Play 框架,一个基于 Ruby on Rails 的 Model-View-Controller (MVC) 概念的 RESTful 无状态 Java 框架。对于客户端开发,我们选择了 PhoneGap、Dojo 和 Dojo Mobile,以便在所有客户端有一个一致的观感和用户体验。

由于我们计划改变的小缓存文件需要被集中起来,我们决定使用一个简单的数据库,而非一个文件系统。我们选择了 Apache CouchDB,一个无模式的面向文档的 NoSQL 数据库,通过基于 MapReduce 的简单快速的视图支持文档存储。

CouchDB 和 Play 有效协同工作,能够让我们快速实现迁移。我们使用了 Apache ActiveMQ 来管理构成文档转换管道的各种消息和任务。最后,一个 Apache HTTP Server 前端提供给我们一些额外控制和负载平衡。同样地,在此试验中,我们探讨解决方案的可行性,并获取对用户需求和使用模式的理解。当准备好生产时,我们可能希望重用的重要部件、概念和设计被轻松迁移到其他平台。

为了跟上不断扩大的移动设备集的发展趋势,我们利用一个内部工具来帮助我们识别 WURFL 项目的移动设备规范,这是一个智能手机功能和屏幕大小等信息随手可得的存储库。该工具帮助我们轻松确认如何最好地显示应用程序内容,以符合设备的功能。

我们从试验中获得的价值不仅仅是总体内部产品(代码)本身,还有对人们如何使用我们的试验品的理解。更重要的是,我们获得了为移动用户和技术娴熟的用户解决问题的经验。我们的早期采用者并不避讳告诉我们是否解决了某个特定的问题,匹配了其工作流,或满足了他们对易用性和生产效率的期望。如果我们没有履行我们的使命、让用户更高效和安全,我们就重新创建解决方案来从一个全新角度解决问题。

MyMobileHub 概要

我们的解决方案提供一种简单的方式来让用户共享文件。与其通过电子邮件发送给自身他们想在移动设备上打开的文件,他们可以使用 MyMobileHub 将文件从其桌面拖放到浏览器。我们通过浏览器将文件上传到我们的服务器上。用户可以从一个移动设备连接到同一台服务器,但是我们提供给他们不同的 UI,其中他们可以查看文件,不管其原始格式如何。我们还利用移动摄像机和语音功能来让用户轻松创建和上传多媒体内容。

时间: 2024-09-29 12:46:21

IBM面向小型设计和开发团队的一个渐进实现方法的相关文章

谷歌收购iOS原型设计工具开发团队RelativeWave

谷歌收购iOS原型设计工具开发团队 RelativeWave 网易科技讯,11月20日消息,据国外媒体报道,iOS原型设计工具Form,for,Mac的开发团队RelativeWave,周三透过官方网站宣布已被谷歌收购.双方交易细节未公布.收购后,RelativeWave旗舰 应用产品将会免费.此外,官方网站上的一段话:"Form的查看工具是否会在iOS以外的平台上提供?让我们拭目以待."--也似乎暗示Android版的原型设计工具也即将来临.(卢鑫)

Google收购iOS原型设计工具开发团队RelativeWave

摘要: iOS应用设计工具开发商RelativeWave刚刚被谷歌收购,而原先售价80美元的Form for Mac设计工具也将免费对用户开放. RelativeWave在官网声明中表示他们将继续在Google内部开发Form,可能会推出 iOS应用设计工具开发商RelativeWave刚刚被谷歌收购,而原先售价80美元的Form for Mac设计工具也将免费对用户开放. RelativeWave在官网声明中表示他们将继续在Google内部开发Form,可能会推出Android版--目前它只支

小型软件项目开发流程探讨

一.导言 国内很多项目都是小型项目,参与人员少(两到五个人),要快速交付(一两个月) . 要成功完成这种项目,除了使用成熟且被团队成员熟练使用的技术之外,有一个良好的开发流程,也是很必要的. 二.小型软件项目开发流程 下图是我对小型软件项目开发流程的一个设想: 需求分析的重要性想必大家都应该清楚,对于项目来说,满足用户的需求是第一位的. 因为时间紧,系统设计经常被忽略. 这会留下很大的隐患,国内很多项目的需求通常是很简略的,还需要在系统设计阶段把一些需求进一步的明确. 不然会出现因为前期一些需求

《软件工程(第4版?修订版)》—第1章1.7节开发团队的成员

1.7 开发团队的成员软件工程(第4版•修订版)在本章的前面,我们看到客户.用户和开发人员在新产品的定义和创建中发挥着重要的作用.开发人员是软件工程师,但是,每一位工程师可能都只擅长于软件开发的某一特定方面.因此,我们在此更深入.详细地讨论开发团队成员的角色. 任何开发过程的第一步都是找出客户想要什么,并且将需求文档化.正如我们已经看到的,分析就是把事物分解成其组成部分的过程,以便我们能够更好地理解它们.因此,开发团队包含一个或多个需求分析员跟客户一起工作,并且把客户想要的分解为离散的需求. 一

Google 极客谈软件开发团队的不良行为

开发团队是一个整体,稳定的.沟通无碍的团队文化非常重要.好的文化氛围应该包括基于共识决策的开发模式.高质量的代码.代码审查,以及能让人放心尝试新事物或者快速失败的环境.Brian和Ben是Google的两位开发主管,他们在"极客与团队"中列举了软件开发团队的典型不良行为,提醒开发者时刻保持警惕,并提出了一些实际的解决办法. Brian和Ben指出,团队的注意力和专注力是最容易受到威胁的.团队规模越大,编写软件和解决有趣问题的能力就越强-不过这种能力毕竟是有极限 的.要是你不去主动保护它

《产品设计与开发(原书第5版)》——1.5 本书思路

1.5 本书思路 我们关注企业核心职能部门涉及的产品开发活动,这里,企业的核心职能界定为:市场营销.设计和制造.我们认为团队成员在一个或多个特定的学科领域(如机械工程.电子工程.工业设计.市场调研或制造运营)已拥有相应的知识,因此,我们不讨论类似如何进行应力分析或怎样开展联合调查之类的问题,这些是开发团队的成员应具有的学科技能.本书提出的集成方法旨在帮助拥有不同学科视角的人共同解决问题.做出决策.1.5.1 结构化方法本书由完成开发活动所需的方法组成.这些方法是结构化的,这意味着我们会提供一个循

《产品设计与开发(原书第5版)》——2.6 产品开发组织

2.6 产品开发组织 除了精心编制一个有效的开发流程,成功的企业还必须组织其产品开发人员,有效地实施流程计划.在本节中,我们将介绍几种用于产品开发的组织,并为如何选择提供指引.2.6.1 通过建立个人之间的联系形成组织产品开发组织是一个将单个设计者和开发者联系起来成为团队的体系.个体之间的联系可以是正式的或非正式的,包括以下类型:报告关系:报告关系产生了传统的上下级关系,这是组织结构图上最常见的正式联系.财务安排:个体通过成为同一个财务实体的一部分联系在一起,如一个商业单元或公司的一个部门.物理

建立软件开发团队时要避免的7个问题

建立和维护一个高性能的软件开发团队是一个持续努力的过程.挑战范围包括从竞争激烈的市场中吸引优秀人才到提供有趣和富有挑战性的工作,以及组建团队结构和促进人员成长. 我们很幸运地工作在一些致力于提升交付质量和频率的软件开发团队,并且我们发现了一些非常的常见阻碍团队快速地推出优质软件的结构和做法: 1:"DevOps"孤岛 特别是随着一个团队的成长,或者可能是为了填补当前团队技能集中存在的差距,我们会被诱惑着在团队中或团队周围建立单独的功能以执行特定的工作岗位. 我们看到的最常见的表现是操作

领域驱动设计和开发实战(转)

背景 领域驱动设计(DDD)的中心内容是如何将业务领域概念映射到软件工件中.大部分关于此主题的著作和文章都以Eric Evans的书<领域驱动设计>为基础,主要从概念和设计的角度探讨领域建模和设计情况.这些著作讨论实体.值对象.服务等DDD的主要内容,或者谈论通用语言.界定的上下文(Bounded Context)和防护层(Anti-Corruption Layer)这些的概念. 本文旨在从实践的角度探讨领域建模和设计,涉及如何着手处理领域模型并实际地实现它.我们将着眼于技术主管和架构师在实现