自然参与原则

作者：John Brunswick
12/04/2007

摘要

Blog、wiki和其他Web 2.0组件都是在用户Web中产生的强大工具。在这种情形下，越来越多的人开始使用Flickr、del.icio.us和Blogger等工具公开日常生活中的各类信息。当企业软件供应商转向交付类似的企业级工具套件时，各类可行方案也相继出现——它们是进一步增强组织业务分析人员的基础。

本文将介绍如何通过自然参与加强业务分析人员和开发人员之间的协作和交流，从而帮助组织以更加敏捷的方式构建应用程序。

自然参与

组织开始逐渐意识到部署用户Web工具可获得的一些基本价值，如内部知识共享。然而，他们往往忽略了这些工具及协作方式所能提供的更多好处。由于它们具有易用性，组织可以利用这些工具为传统应用程序开发提供自然参与的支持，从而使开发人员和业务分析人员能够共同开发解决方案。

自然参与具有敏捷性、经济性和高效性，还可以使用门户或门户类框架产生的逻辑参与模型——让业务分析人员能够并行设计解决方案的流程、内容、结构和其他元素，并参与传统的软件开发团队。对于一个重视让业务单元参与全面解决方案构建过程的解决方案交付模型，我们可以从它的速度、所有权和维护方面获得巨大的业务价值，并且它不仅仅依靠开发团队来完成预定的目标。可以将自然参与看成是进一步加速全面解决方案交付的“敏捷开发增强”。

那么如何才能将自然参与应用于非技术任务呢？试想，假如多个参与者积极合作，共同在画布上画一幅画。根据自身能力的不同，这些参与者可以通过分工合作将自己的技能发挥到极致。或许，某个团队会着重使用模板画树，这样就将高水平的画家解放出来，致力于画中人物的复杂而独特的细节。画完以后，观众将欣赏到一幅完整的作品，而不知道这是由能力各异的多个人参与创作的。

无论是开发在线抵押应用程序还是B2C网站，都可利用Web 2.0的贡献原则使这种共同参与的方法成为可能并且有效。

僵化且单一的旧模式

过去，部署应用程序的IT团队一直都以瀑布式的开发模式为基础，其结果是一个单一且笨重的解决方案。开发团队控制应用程序的所有元素，包括文本内容、分类法、站点结构、检查、仪表板等。虽然这种方式也构建出了许多出色的解决方案，但不幸地是，它确使得开发团队成为了瓶颈。

下面是传统开发模式的一些缺点：

• 团队对于业务需求的反应迟缓。
• 开发团队成为项目的瓶颈。
• 需要维护更多代码。
• 需要测试更多代码。
• 应用程序更新时需要回归测试。

如果将单独模式发挥到极致，那么在基于Web的应用程序中调整某个简单超链接的目标就可能需要几个星期。如果要修改一项内容或是调整站点结构，则开发团队都需要花费大量的努力，这样便减少了其他项目的可用资源。要确保应用程序在修改之后能够正常运行且不受其影响，可能还需要一系列回归测试。

再说一次，虽然许多出色解决方案都采用这种方式开发，但是我们都知道这种流程并非没有重大缺陷。

传递指挥棒

应用程序开发团队的成员以交付业务解决方案而自豪，这无可厚非。他们通过努力工作，取得了对于复杂系统的深刻理解，并将这些系统编织在一起以满足业务需求。要放弃对应用程序各部分的控制，并转向更重复的自然参与开发模式，不得不面对这些阻力。

说到控制，对于业务分析人员开始进一步参与会带来开发结果的难以控制和不稳定的担忧也是很合理的。为了消除这种担心，企业供应商非常小心，确保没有在新工具中忽略管理和安全控制，同时建立批准流程、适当的访问和可行的审核。

如果IT人员意识到他们的努力将用于高价值的战略性任务，同时能够提高效率并降低成本，则他们对于这种改变的抵触就会消失。