社会协作开发环境使得新思路和开发更易于在不同利益相关者和技术贡献者之间共享。从捕获创意和结构那一刻开始,云应用程序开发环境的直观、可视、基于浏览器的性质均可允许任何许可权限的用户访问、评估和促成这些创意。
当执行应用程序成形后,充许任何人对其进行访问和体验,并提供一种即时手段来获取用户对该应用程序的认可和反馈。一个真正的社会协作云环境不需要部署应用程序来提供测试反馈,它会一直处于可用状态,并且能够不断得到更新。
甚至应用程序的技术方面都得益于协作式的云性质。所有应用程序开发工具都可以通过云予以访问,因此技术资源从任何区域和时区都可以提供帮助,而不太可能出 现误解情况或在转化过程中丢失的风险。将应用程序开发的一部分分配给远程资源,执行技术审查,具有吸引力的远程协助,这一切都归因于环境的云性质。
拥有一个共同的应用程序开发环境非常有助于远程协作和支持。开发人员、主题专家、业务和行业专家能够随时随地工作,让团队跨州进行协作。
开发人员花费在处理偶然复杂性的时间远远超过以用来处理有待解决业务问题的复杂性的时间。一个先进的虚拟开发环境要负责处理偶然的复杂性,而让开发人员专注于正在实施的创意。这样可极大地加快了创造价值的进程,提供给开发人员更令人满意的工作并降低项目风险。
单纯的云应用程序开发要求在本地浏览器上运行所有工具和支持;这不同于历史的方法:工具安装在桌面上,而应用程序部署到云中。
这里与基于浏览器的工具的重要区别在于,协作和问题解决得到简化,因为不必在每个设备上正确地配置工具,且环境没有在活动中,从而在解决让环境和配置正确匹配的相关问题所需的时间内消除影响生产力的问题。
通过从平台上得到应用程序,现在可以随意在任何提供商之间移动完整的环境(不管是在内部还是外部),同时仍然维持一个一致的开发环境。
环境的虚拟性是指可以随意创建、移动和扩展它。为了应对新客户或新应用程序,必须在较短的时间内配置完一个环境,以让 IT 具有高度的响应能力。由于可以轻松移动这些环境中的应用程序,我们可以添加、删除和聚合虚拟系统,而无需更改虚拟系统上运行的应用程序。这就履行了云计算 的实用承诺,但不是在上层、最得益的层。
将这三个愿景结合起来,就为我们提供了下一代软件开发原则和系统的一个全景。这个系统旨在更好地服务于用户需求、利用创造力,并促进社会协作。这些系统会弥补业务与 IT 之间、用户与数据之间、现代个人、移动和社会计算与企业计算之间的差距。
一个云环境的所有方面在这里都适用。任何环境(包括开发、测试或生产)都可以立即得到配置、从任何地方加以访问、随需求的增加予以扩展,且可应用 “即用即付” 成本模式。环境可以在一个内部环境或外部环境中。可以在无任何修改的情况下在环境之间迁移应用程序。
应用程序平台是以用户为中心的,这意味着它迎合用户的思考方式。用户的创意成为新应用程序的构想中的一等公民。在需要任何以数据为中心的组件之前,环境首先侧重于应用程序对用户的表现方式。构想的应用程序行为元素可以被自动转换为一个运作的应用程序,以获得即时反馈。
其社会协作性质意味着任何人都可以随时审查或促成创意或运行中的应用程序,包括专家、团队成员和远程专家。可以在运行过程中修改应用程序,这样一来,无需 一个构建/发布周期就可以吸收反馈。应用程序开发环境是基于浏览器的,允许开发人员从多个位置进行协作,如有需要,一天内要进行多次反复协作。
现在我想向您介绍一个真实的系统,展示如何实现以用户为中心的协作式虚拟云应用程序开发的目标:Aviarc 和 Aviarc DrawingBoard。我要讨论系统如何在之前介绍的思考/链接/构造模式内工作。首先,我要介绍我用于说明的案例研究。
Aviarc 案例研究:Property Brokers 营销应用
背景:Property Brokers 是一个大型省级房地产组织,在新西兰中部占据主导地位。它在 28 个地区提供全面的房地产服务。其服务组合包括农场、出租物业、小区住宅、迎合顾客生活品味的地产,和商业/工业投资与企业不动产。
挑战:Property Brokers 有一个老化的信息系统支持房地产活动的各个方面。这一集中式的庞大应用程序系统远远不能满足公司的信息需求。其流程是手动的,且需要多次重复的数据录入步 骤。公司因系统滞后而导致的大量非增值文书工作,一直受到外地代理的抱怨。在看到一个竞争对手推出的智能 iPad 应用程序之后,Property Brokers 意识到其系统可能不再具有吸引力,甚至可能因其竞争对手的 “炒作” 而失去好的销售代理。
方向:Property Brokers 评估了各种解决方案选项,选择了 Aviarc 和 Aviarc DrawingBoard 作为解决方案。该公司了解到 Aviarc 的价值在于能够设计一个以用户为中心的 Web 解决方案,该解决方案将重点放在用户体验需求上。该公司的任务是在较短的时间内完成构想,以展示产品并从所有销售代理那里获得补进。
DrawingBoard 和 Aviarc 架构改变了当前软件范式的基本原理;它们帮助管理复杂性并推进创新型思维。
第一步是从业务和用户友好的全景角度捕获整个构想阶段演化的创意。讨论始于广泛抽象的概念,该概念逐渐变得更有条理。
对于 Property Brokers,Aviarc DrawingBoard 用于捕获利益相关者和用户的创意。图 1 显示初步思考后的 DrawingBoard。
图 1. 初步思考的结果
由于 DrawingBoard 是基于 Web 的,用户可以在正式会议室和论坛的范围之外审查和促成思考和共享。此阶段始于用户创建初始的 Aviarc DrawingBoard;同事间的社会协作确保 Aviarc DrawingBoard 捕获最广泛的需求。每个用户可以使用最适合他们的技能、方法和技术;例如,集思广益或组件业务建模。没有必要学习新的复杂工具或处理阻碍创新的刚性流程。 在一些阶段,业务用户可能要邀请 IT 专业人士或某种形式的顾问来进行协助或调解,进而帮助业务用户充实其思维。
用户能够开展一个或多个研讨会或仅仅在 Web 上通过 Aviarc DrawingBoard 工作。这一阶段的输出被一些人看作等同于敏捷的特性驱动的方法,但是 Aviarc DrawingBoard 允许业务用户更多地反复参与,不受线性流程或技术要求的约束。这个流程可由企业执行任意长的时间,直至他们确定已经准备好转向流程的第二部分。
打个比方,有一个项目是要建房,在该阶段您需要定义房间号码和类型、灯具的总体质量、楼层数,等等。这些都可以在 Aviarc DrawingBoard 内捕获到。创意可视地呈现为便笺,就像使用便条一样简单;如果出于某种原因用户认为这有助于思考过程,那么可以将这些连在一起。可以通过激增和骤减便笺组 来轻松处理规模和复杂性。
Aviarc DrawingBoard 还用于将有关计划进展的重要消息传达给管理层和其他利益相关者,甚至是在地球另一端的项目经理。DrawingBoard 还提供项目计划和进展更新。图 2 显示用于阐明有关项目进展的重要消息以及获取用户组反馈的仪表板。
图 2. 用于项目管理的初始仪表板
有关素材可通过专门的元素作为思考过程的一部分附加到 Aviarc DrawingBoard:便笺、文档、视频、音频、人、型材、角色、实时网站、素描、其他 Aviarc DrawingBoards,等等。对于可以从视觉和功能上纳入设计的元素的类型基本没有任何限制;可以创作并添加新元素到调色板。可以添加其他元素,比 如聊天室、表决数据库和提醒有关变更的表,来使上述素材具有交互特征。
添加并连接元素所在的 “桌面” 可以由描绘思维工具的任何 JPG 图片替代,比方说一个 SWOT 网格、泳道或 CBM 布局。通过这种方式,几乎任何咨询或思维工具都可用于捕获和组织思维,而无需学习新技术。
另外,Aviarc DrawingBoard 上发生的任何事情可以在特定时间点捕获到,因此在项目生命周期的任何时间,对思维和设计的每一次添加或变更都可以归结到精确设计的情景中。这样一来,就可以调整好范围、正直、思维的演变,且永不丢失。
在该阶段,可以选定一个深思熟虑并且双方一致同意的范围(传统上是通过一个签署的工作说明书)。通常对于设置完成项目其余阶段所需的固定成本很实用。然而,稍后想要但在本阶段不包含在内的功能可以通过权衡或双方商定的范围变更来添加。
捕获到思维之后,业务分析师使用 DrawingBoard 来阐明分析的结果。流程图、业务事实的抽象、应用程序主题设计、应用程序组件等分析输出都提炼在 DrawingBoard 中。图 3 显示分析阶段的一个输出。
图 3. 分析过程流程图和草图
顾名思义,该阶段通常引入业务分析师或其他专门资源到项目中,促进和调解业务用户发展 Aviarc DrawingBoard 的持续社会协作。在分析进行过程中,体验化设计工作开始。对于 iPad 应用程序,体验化需求不同于正常的基于 PC 的浏览器体验。范围内涵盖的所有项目都被扩展,以便用户完全理解将通过 “体验” 构造的一切内容。
这是一个高度重复且可追溯的阶段,其中支持工具允许各种社会协作交互发生。一些示例包括:
- 使用交互式的上下文应用技术(比如 Aviarc Pins)来澄清细节和注释演化的应用程序的各个方面。
- 使用允许用户阐明各种事情的基于 Aviarc DrawingBoard 的用户工具,比如绘图工具,来修改外观。
- 使用在线 Aviarc DrawingBoards、会议或研讨会来探究更大的领域或澄清事情。同样,这由用户在 Aviarc DrawingBoard 上以交互方式商定同意捕获/记录且确认。
构想阶段可能是围绕应用程序的性能和其他非可视化(或体验化)需求捕获需求的一个机会。这些需求也可以使用 Aviarc DrawingBoard 进行捕获/记录。
在构想阶段,起推动作用的分析师将能够获取 Aviarc Marketplace 中现有工件;当他还创建工件接口时,这些工件就被选择性地加载到 Marketplace,这样就可以共享或与他人共同创建潜在工件。
在构想阶段,可通过避免结构(或工程)方面来提高速度和效率。换言之,房子看上去真实,但还不真实,因此一些东西改变起来就很简单快捷。房子(应用程序)仅可视地(或凭体验)构建,因此可以创建新的房间。
界面是在此阶段设计的,此过程中用户可以利用 Aviarc 内一个用户友好的简化版的演播室设备。其他用户可以注释、固定便笺到界面,并就界面设计展开社会协作。
所有实体都由用户开发,用户添加任何相关数据或约束这些实体,比如预期数据类型的示例或用例。由此,Aviarc 能够推导出大部分的应用程序逻辑并在悄悄将应用程序流程和逻辑拼在一起时进行自我测试,推断哪些元素会成功地协同工作以及应用程序流程如何。参见图 4。
图 4. 使用 DrawingBoard 的界面和业务逻辑以及模拟数据
当每个元素、连接、界面和逻辑元素都成功完成并连接起来时,应用程序开始活跃起来;它的外观和行为开始变得与生产应用程序完全一样。实际上可以看到 Aviarc 可扩展的 XML 代码在 Aviarc DrawingBoard 的背景下自动变化和发展。参见图 5。
图 5. 营销活动调度界面
通过 Aviarc DrawingBoard 使用社会协作,此刻没有转化、解译或创建传统的二维规范。完成和捕获的一切事物都成为 Aviarc 应用程序不可分割的一部分;用户社区仍然积极参与,与当下不断演化的项目进行交互。
在本阶段后期,进行工程保证很有用,可以确保虚拟示例中的一切都得到构建,而没有隐藏含义。在有些情况下,工程保证需要改变用户已经构思且 “体验” 的东西。
在虚拟现实示例中,假设工程无法运行厨房管道;它必须想出一些解决方法,并将其提交给客户供其验收。
现在该是时候让 Aviarc 自动组装项目了:这是一个自动化过程,可根据需要加以重复。该过程组装在思考和链接构思阶段创建和运行的所有可自动组装的可扩展 XML。这通常发生在整个项目有 40% 到 80% 可供部署时(取决于项目类型)。
可以在一个地方由一个人使用一个自动组装软件密钥进行自动组装。该任务的完成表示:
- 构想阶段结束,不过用户与应用程序的可视和上下文交互会继续。
- 转入一个更受认可的领域,即由技能娴熟的团队成员编写应用程序的其余元素。
迄今为止的体验表明,组织应当期望构想过程(思考和链接)通过最佳实践敏捷工具、技术和实践工作者,在大约一周的时间内完成之前需要一个月完成的工作。
在构造阶段,在构想期间指定的没有被自动组装的任何元素(这包括任何工程保证过程需要的变更)都已完成。在构想阶段创建的应用程序 XML 将所有(要构造的)组件绑定在一起以完成应用程序。换言之,应用程序的外观和行为现在总是和构想期间所体验的一样。
使用 Aviarc 开发平台,实践工作者可以快速构造任何剩余的复杂逻辑和数据处理元素。Aviarc DrawingBoard 对这些元素的精确设计和构造提供非常具体的指导。
运作的应用程序还提供一个清晰的上下文来容纳这些手动构造的元素。开发人员可以为了产品用途的适用性随时测试这些元素,而且它们也要与应用程序其余部分一 致。通常这些元素已经存在于 Aviarc Marketplace、标准的元素库中,或者您甚至可以重用本区域先前工作中的元素。
当您确实需要手动开发一个逻辑元素时,DrawingBoard 可以使这个过程变得简单而快捷。
本阶段所做的工作非常适合外包给专家,仍然能够让您的团队与外部程序员高效合作。
部署新 Aviarc 应用程序的最后一步是,用户接受根据先期构思所构造的东西。最好的测试:用户应该在预期(在早期的模拟阶段所体验的)和实际结果之间没发现任何区别。
最近,云计算本身被视为一个新兴技术(如果不是再现技术的话)。如今出现这样的一个问题:如何使用运用云环境等尖端技术的一个以用户为中心的协作式虚拟方法,如何承诺改变(如果不是彻底变革)完成应用程序开发的方式。
在一个竞争日益激烈的应用程序市场中,开发时间成为一个重要方面。这一时间不仅包括应用程序的逻辑基础、程序编码,而且包含应用程序的用户交互行为。您不 仅需要减少正确编码所需的时间和精力,而且得构造用户想要的应用程序,且从一开始就要预想正确。围绕编程的代码重用和模块化已经出现一段时间了;使用我提 出的以用户为中心的协作式虚拟方法,您还可以减少生产用户需要的应用程序所需的时间和精力。
云的结构是进行这一切的完美环境。
在我提出的环境中,用户社区能够随意直观、可视化地就概念和设计过程的每一个方面以及实际运行的应用程序彼此交互(虽然您想做出界定)。我看到过用户在意识到他们对参数所做的变更出现在虚拟应用程序时所产生的自我怀疑。
该方法的一些效果是什么?一小部分预期不到效果开始显现:
- 更多持怀疑态度的人开始相信 IT 有能力通过非常合适的体验和成果来满足业务用户迅速变化的迫切需要。
- 通过与以数据为中心的系统的紧密集成,我们看到有更多人更充分地利用这些传统系统,以及 SOA、ESB 和逐渐进入新的以用户为中心的系统中的其他最佳实践。
下面是我对以用户为中心的开发系统的未来的预见:
- 通过某种自动组装实现应用程序完成率的稳步增长,不断交付快速上市的应用程序(并使组织越来越具有自适应性和创新性)。
- 社会协作开发体验连同工具的快速发展;用户和 IT 专业人员的更加 “游戏化” 或直观的参与。
- 构建大量有销路的 IP。
最后,我想我们会从云计算技术中获得比目前为止看到的更巨大的获益。最终内部技术堆栈和工具与云技术堆栈和工具之间的界限会变得模糊起来,因为开发成为一个协作式行业。
文章出处:IBM developerWorks