关闭

是否有最好的软件开发方法?

标签: thoughtworkscrm工作construction敏捷transition
4503人阅读 评论(3) 收藏 举报
分类:

ThoughtWorks的开发方法

传统的说明性方法论采用的是一种由上而下的项目管理途径,来建立一种命令和控制的体系。这些方法论的假设基于,只要有了足够的计划和管理,成果就可以预测,风险就可以避免。

当客户的业务和技术都保持相对稳定的时候,这些方法论很有效。然而,对于那些与日俱增的战略性软件项目来说,说明性的方法都既不能提供企业所需要的灵活性,也不能提供企业所需要的市场进入速度。太多的时候,最终的结果不是高价值的软件,而是一大堆分析结果,只会在某个经理的书架上积满了灰尘。这和在白板和键盘上发生的变化……或者,真正的商业需要来说,相差太远了。

敏捷方法基于非常严谨的过程。实际上许多这些实践都已经有着充分的定义,能够直接纳入开发工具之中。例如,单元测试框架,持续集成工具,带重构的开发环境,就构成了新的一套新开发工具,让人们能够更快更好地创建软件。

很早以来的研究已经证明,唯一能对软件生产力产生重大影响的,是人。然而,奇怪的是,敏捷方法是第一套基于人们实际软件开发特点的软件工程实践。

同时,ThoughtWorks认识到方法论不是万能的。作为采用敏捷方法的几个先驱者之一,我们十分了解这些方法的利和弊。不过,敏捷方法包括了许多近期史上最成功的软件成果中演化而来的有用的实践。极限编程(XP),SCRUM, Crysta等等敏捷方法都推崇脚踏实地,切实可行的各种实践,如持续集成,测试驱动编程,和重构

联合技术开发FTD

一种方案是:美国软件开发组花了一年的时间研发CRM软件。在美国总部试用时没有任何问题,该软件完全能够满足产品生产的需要。软件开发组于是将软件推向中国市场。由于对中国市场缺乏了解,他们花了大量的费用和工作对软件系统进行改进。在经过一年的改进后,终于完善了软件功能。此时中国本地产品也开发出来了。

  第二种方案是:组建两个软件开发组,他们相互独立而又同时开展工作。但是中国软件开发组团队既缺乏技术、又缺少经验。由于公司规定中国是受控国之一,中国软件开发组难以及时获得新产品线的有关信息,致使开发工作进展十分困难。因此,客户关系管理软件CRM软件在中国市场的推广工作非常不理想,致使大量客户十分不满。公司不得不花了两年多的时间,才消除了市场的负面影响。

  假设还有第三种方案:与当地软件开发组采取松散的方式联合工作。美国软件开发组具有的丰富支持产品线的软件开发经验,他们把这些经验快速地传递给中国软件开发组。CRM软件在美国照常按计划投入使用,而在中国的软件开发组继续后面的工作,解决软件系统适应在中国使用的有关问题。CRM软件最多晚三个月,就能够在中国市场顺利投入使用。

  以上三种假定的开发方案中,方案一是高度集中化,方案二是高度分散化,而方案三是最优化。其中第三种软件开发方案,特别适用全球化公司的软件开发,称之为联合开发FTD(federatedtechnologydevelopment:联合技术开发)。应用软件集成仅仅是FTD发挥作用的领域之一。FTD方法不仅适用于信息技术和业务处理,而且适应软硬件开发和产品开发。

  FTD是优化业务产出的方法之一。采取这种方法,一是本地组织可以自主作出决定,不同组织之间是平等关系而不是联盟。二是要有一个中心机构负责工作协调,每一个分支都能够在统一的命令和安排之下开展工作。

 

RUP(Rational Unified Process)

Rational统一过程,定义了一系列的过程元素,如角色,活动和产物,通过适当的组合,能够帮助软件开发组织有效地管理软件过程。RUP的特点体现在它是以用况驱动(use case driven)的,以体系结构为中心(architecture-centric),迭代和增量(iterative process)的。在系统的整个开发生命周期内共有4个阶段:初始(inception)、细化(elaboration)、构造(construction)和移交(transition),随着时间的推移,每个阶段所注重的焦点也不断发生变化,同时这四个阶段也是不断迭代完成的,每一次迭代都有增量的任务完成。

究竟什么样的方法最适合今天的互联网开发?或者如何综合运用?欢迎评论!

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:2287041次
    • 积分:24737
    • 等级:
    • 排名:第267名
    • 原创:202篇
    • 转载:94篇
    • 译文:7篇
    • 评论:2492条
    最新评论