第1章 欢迎学习快速开发
本章主题
什么是快速开发
实现快速开发
相关主题
本书适用对象:参阅“前言”
本书主要特色:参阅“前言”
为何编写本书:参阅“前言”
快速开发策略:参阅第2章
快速开发要点:参阅第6章
某产品经理告诉我,为改变现状,他想建立一套产品开发权限控制体系,该体系要更注重产品质量、防止功能蔓延、控制项目进度,并能够按计划交付产品。
但是,当���际运作项目时,他又不由自主地把将产品迅速推向市场放在了*优先的级别上。如何保证产品的可用性?我们没有足够的时间。如何保证产品的性能指标?可以等等再说。如何保证产品的可维护性?下一个项目再说。如何进行产品测试?我们的用户现在就要产品,马上送货。 这个产品经理并非只是某个特定的产品经理,他几乎是我为之工作的所有产品经理的化身。这种情形在整个软件业日复一日地重复着。开发时间已经变成头等重要的问题,以致忽略了其他应考虑的因素,甚至那些*终会影响开发时间的因素。
1.1 什么是快速开发
对有些人而言,快速开发是通过使用一个得力的工具或方法实现的;对黑客而言,快速开发可能意味着36个小时连续不断地编码;对信息工程师而言,快速开发就是RAD——CASE(计算机辅助软件工程)工具、积极的用户参与和紧凑的时限(timebox)的集合;对纵向市场的程序员而言,快速开发就是利用微软的*新版本的Visual Basic或Delphi快速建立原型的过程;对项目经理而言,无论*近一期商业周刊发布的实践亮点是什么,快速开发就是拚命缩短项目周期。
每种工具或方法都可能在特定的场合**运行,并有助于提高开发速度,但要完全发挥它们的功效,则必须将它们作为周密完整策略的一部分合理编排。没有任何一种快速开发工具或方法适合所有快速开发场合,即使对只有一定速度要求的非快速开发实践,也没有任何一种快速开发工具或方法就肯定能满足它在速度方面的要求。
就本书而言,并不是要介绍具体的方法或工具,“快速软件”开发只是一个相对于“慢速和典型开发”的描述性说法。它并不是有注册商标的快速开发方法——一个不可思议的短语或行话。本书所说的“快速开发”是个普通的术语,与“快捷开发”或“更短的开发周期”具有相同的意义,它意味着能够以比你目前更快的速度开发软件。
总之,一个快速开发项目就是任何一个需要强调开发速度的项目,以今天的业界环境,可以说很多项目都是快速开发项目。
1.2 实现快速开发
本书的目的是为你进行快速开发提供一条捷径,虽然切换到这条捷径似乎存在着风险,但采用目前的开发方法则会导致成本增加、项目计划时间拖延、质量低下、项目失败、大量反复,造成项目经理、开发人员和用户的冲突,并出现其他我们本可以避免的问题。
如果你是在采用常规开发模式的组织中工作,则采用本书中的实践做法,你能够将开发时间大大缩减,可能多达50%,并能大大提高劳动生产率,而不会危及产品质量、性能、可维护性和项目投入。但这种改变不会因你采用了某种新的工具或方法而立刻实现,也不会因你采用某种封装软件而立刻奏效,实现快速开发需要时间与努力。
我们都幻想能有一个简单的方案可以解决开发速度问题,但简单的方案只能解决简单的问题,软件开发并不是一个简单问题,快速软件开发更不是一个简单问题。
如图1-1所示,所有可能的软件实践集合是巨大的,在这样的集合中,有效实践这一子集中的实践数量也是相当大的,在某个特定项目中,你可能只用到这些实践中的一小部分。从总的执行层面看,快速开发的成功取决于两个要素:
选择有效的实践而不是无效实践
选择有利于完成项目进度目标的实践
你可能认为这是显而易见的,但就像第3章所解释的那样,各组织机构往往选择的是无效实践,他们选择的实践已经证明是失败的或者是失败多于成功。当他们需要确保项目进度时间时,他们选择的是那些其实降低了达成计划目标机会的高风险实践。当他们需要降低成本时,他们选择的是那些反而导致成本上升的基于速度的实践。这些组织改善开发速度的**步是管理好他们选定的无效实践,然后开始选择有效的实践。
……