查看: 4499|回复: 6

讨论:你的项目为什么不迭代?

[复制链接]
论坛徽章:
62
ITPUB9周年纪念徽章
日期:2010-10-08 09:28:522012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14
发表于 2009-8-18 11:41 | 显示全部楼层 |阅读模式
太极敏捷认为:

迭代是敏捷的基础;

软件开发工艺从瀑布模型转向迭代、递增、演进式模型,是过去 20 多年来所发生的世界软件工程最为重大的一项管理和技术方法变革之一;

如果你的团队一时还做不到敏捷,那么应该先做到迭代。

如今不但 21 世纪的敏捷方法(Scrum、XP、AgileUP、MSF for Agile、FDD、Crystal 等等)普遍采用了迭代方式,就连正宗的 CMM/CMMI 实施典范和过程(敏捷的 TSP)也采用了迭代式开发模型。当我向一些号称实施了 CMM/CMMI 的朋友们提到,CMM/CMMI 过程其实也应该或最好采用迭代式开发时,他们竟然都对此好像一无所知,一脸茫然,感到很诧异。

迭代是如此重要。可是我发现,国内很多软件项目团队至今仍然没有真正地理解和掌握好迭代开发与管理技术,尤其是真正能够做到 time-boxing(时间盒)迭代的团队好像非常少(未经科学统计)。国内的很多 IT/软件项目为什么不迭代?估计可能有许多种原因。

1)不知迭代为何物,不理解为啥要迭代。

当被问到一个软件开发项目分几步做、需要哪几个阶段时,我猜大概国内有一大半的IT/软件专业人士及项目管理人士都会回答:还用问?不就是分为需求阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、部署阶段 ... 等等这几个阶段么,简单得很!

可是,错了!这其实是一种极为常见的惯性瀑布思维。40 年的软件工程科学研究和工程实践表明,瀑布式生命周期是一种过于简单、过于理想化的模型,很难适应当代复杂多变软件项目开发的现实。很多人不了解迭代式生命周期及其重要性,可能与一段时期落后的软件工程教育、舆论环境的影响有关。

我不记得 2000 年之前有哪一本国内的软件工程教材非常深入地介绍和强调了迭代递增式开发的重要性,可能是我的记性差,反正是印象远不如瀑布模型深刻。20 年来国内的软件瀑布式生命周期模型得到广泛加强和应用,大概与这种传统教材和教育的普遍性有关。2000 年之后,情况似乎有所改善,但这方面的宣传,有关软件过程由瀑布式向迭代式这一重要转变的宣传,还是远远不够的,在人们大脑中的印象远不及铺天盖地的 ISO、软件过程改进、CMM、CMMI、软件测试、全面质量管理(TQM)、6sigma、软件项目管理、PMP ... 等等之类的潮流概念和词汇深刻。

迭代的出现比敏捷早得多。这些年,我一直向大家推荐敏捷大师 Craig Larman 和软件工程权威专家 Vic Basili 教授早在 2003 年就发表在 IEEE Computer 杂志上的著名封面文章《迭代与递增式开发简史》。有谁能想到 IID(迭代与递增式开发)竟然有近 40 年的历史?

我对于迭代开发方式的了解是从 1998 年前后读到《微软的秘密》开始的,2000 年之前又从 RUP(Rational 统一过程)中学到了经典的迭代模型。RUP 当时就已经取消了需求阶段、设计阶段、编码阶段和测试阶段的称谓,取而代之的是更为成熟和先进的里程碑阶段划分:起始阶段、细化阶段、构造阶段和移交阶段,在每一个阶段的迭代中都至少有需求、设计、编码和测试这四项活动。

2)没有意识到:大量项目的失败原因其实与误用瀑布式(不迭代)有关。

近 40 年的软件工程实践表明:不迭代的项目风险非常大!

平庸的开发团队往往不能够溯源而上,理清各种因果要素之间的逻辑关系,准确找到导致项目失败的真正原因和根源,因而容易一错再错,屡战屡败。

3)把客观条件不具备作为不迭代的借口。

比如,“客户不接受迭代方式,因此我们无法迭代。”

这句话当然有一点道理,但其实软件开发团队迭代不迭代,与客户懂不懂迭代关系不大。

4)明知问题出在错误地采用了瀑布式,应该转向迭代式,却无力而改变之。

这种情况值得同情。作为研发骨干和一线或中层管理者,不少人意识到了迭代过程的重要性,也尝到了多次项目失败的滋味,深刻体会到瀑布式(或准瀑布、伪瀑布式开发)的种种弊端,可是囿于企业/组织原有的观念、制度、文化、考核等体系根深蒂固,高层领导又缺乏变革的动力和意识,导致这些有识之士无力去改变现状。

找到问题的真正根源,总比工作在自欺欺人的环境中,整日稀里糊涂地混下去要好。我很乐意作为外部第三方尽我的可能帮助这些朋友们。

5)认为迭代在技术上不可行。

一种经典的误解认为,由于逻辑的紧密相关性,必须要在完成全面而详尽的项目计划、需求分析、系统设计,作出周密的思考之后,才能开始编程(瀑布式),这样可以避免项目后期的程序修改,而迭代会导致程序的不断修改,是不可取的。

6)因为人手不够,所以不能迭代。

...

为什么不迭代?读者朋友,您认为还有其他什么原因吗?

[ 本帖最后由 张恂 于 2009-8-18 15:11 编辑 ]
论坛徽章:
62
ITPUB9周年纪念徽章
日期:2010-10-08 09:28:522012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14
 楼主| 发表于 2009-8-18 14:33 | 显示全部楼层

因为要全盘分析,所以迭代不可行?

网友 dearChloe:

说我手头一个项目,我做好一大块业务逻辑的需求、设计。但我觉得还不能开始开发,因为还有后面一小块的逻辑没有搞清楚。所以我要等所有的逻辑搞清楚了,需求、设计做好了,才开始开发

我相信这是完全不符合敏捷的思想。但我必须这样做。为什么呢?

因为前后逻辑有很强的关系。我可以开始小阶段的开发;但是,到了一定程度后,如果整个逻辑没有分析清楚,到开发后期,就会产生问题需要回过头去修改前面的程序

我已经把项目分成几个阶段,如果够人,是可以做到并行进行。但现在不够人手,所以全盘分析后再开始比较安全

作者的话可以概括为:

我们必须要在完成全部的需求定义和系统设计之后才能开始编程(瀑布式),这是因为所有的业务逻辑都是紧密相关的(很强的关系),如果事先没有通过需求和设计把所有的业务逻辑都搞清楚,那么以后一旦出现问题,就可能要回头修改程序。

乍看之下,这些理由似乎很有道理,但其实这是一个关于为什么只能瀑布不能迭代的经典误解,这种顾虑是没有必要的。

演进式设计是关键

由于作者没有给出实际的业务逻辑的例子,这里我根据一般的情况进行分析。

企业信息系统开发是一个非常典型的敏捷、迭代应用领域,大多数的业务逻辑分析、需求和设计都可以采用迭代、递增和演进式的开发方法。其中,演进式的需求分析和系统设计是两个关键的技术。

所有的软件都是一个方法、一个方法,一个类、一个类地开发出来的,这是一个递增的过程。我们总是可以从看似一团乱麻的用户需求中,找出一些稳定、明确的需求,设计出一些类,编码,测试,获得一些反馈和经验;然后再找到另一些稳定、明确的需求,设计出一些新的类和方法,对已有的类和方法作些修改,编程,测试,再获得一些新的经验和反馈,如此一步一步地循环往复 ... 这就是一个 evolutionary design/programming 的过程。

作者所采用的全盘分析方法,在软件工程中有一个专门的术语,叫 Big Up-Front Design(BUFD),这正是敏捷方法所反对,主张抛弃的。我怀疑作者的判断,她的项目只能瀑布不能迭代,很可能是错误的。到底能不能用迭代和演进式设计,起码应该试一试。

关于如何做面向对象的迭代、演进式设计,有一本很好的教材,Craig Larman 的《UML 和模式应用》,推荐不熟悉该项技术的朋友们阅读。

为什么要用迭代取代预先全盘分析,我给出了以下 4 点理由。

在大多数软件开发项目中:

* 业务逻辑不是铁板一块,可以根据不同需求项的优先级,分块依次实现和验证;

* 没有通过实际编程和测试获得反馈与验证的“全盘分析”是不可靠的,容易造成浪费;

* 绞尽脑汁的“全盘分析”无法避免后期程序的修改;

* 项目后期少量、局部的程序修改是正常的,并不可怕。

显然,对于复杂的软件开发项目,迭代、演进式开发方法是比瀑布式方法更为科学、更为先进和更为成熟的方法。

[ 本帖最后由 张恂 于 2009-8-18 15:10 编辑 ]

使用道具 举报

回复
论坛徽章:
62
ITPUB9周年纪念徽章
日期:2010-10-08 09:28:522012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14
 楼主| 发表于 2009-8-18 14:46 | 显示全部楼层

未经过验证的全盘需求和设计是不可靠的

预先全盘分析的一个显著缺点是,没有反馈和验证。你怎么知道你对业务逻辑的分析,做出来的需求和设计是对的、高质量的呢?

有的人可能会回答:凭我的经验,只要在我脑子过一遍,我认为它是对的,它就是对的。这显然是不科学的。科学的做法是,用实验来验证你的设计。

获得反馈,检验软件设计的正确性和有效性,软件工程中有几种常用的办法:测试(包括人工测试和自动测试),评审以及用户使用等等。敏捷方法非常强调软件自动测试和评审这两种手段,后面我们还会对此作详细讨论。

在没有有效测试、评审的情况下,脱离实际程序运行、缺乏反馈信息验证支持的全盘分析做得越多,花得时间越长,需求和设计可靠性越差、产生更多错误、造成更多浪费的可能性就越大。

使用道具 举报

回复
论坛徽章:
62
ITPUB9周年纪念徽章
日期:2010-10-08 09:28:522012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14
 楼主| 发表于 2009-8-18 14:47 | 显示全部楼层

预先全盘分析就能避免后期程序修改?

No,没有反馈的预先全盘计划、分析和设计,实质上是一种臆测和揣测,很难避免后期程序的修改。原因正是前面我们已经论证过的,未经过验证的全盘需求和设计是不可靠的。

按照作者设想的做法,在实际编码之前就把所有的业务逻辑、需求和设计都分析清楚(瀑布式),真的可以避免后期产生任何的问题,不用修改程序,可以一步到位、一遍通过了?事实上,在实践中,企业信息系统的开发中,我们发现这往往很难做到。

作者:“如果整个逻辑没有分析清楚,到开发后期,就会产生问题需要回过头去修改前面的程序”。

作者没有说到开发后期,会产生什么样的问题,是大问题,还是小问题。实际上,根据一般的经验,即使所有的一大块业务逻辑事先都分析清楚了,到了开发后期,仍然无法完全避免产生问题以及程序的修改。

数十年软件工程的实践以及大量的统计数据和案例表明,软件项目中的变化是一种常态,而瀑布式的做法恰恰很难适应变化,它非但不能通过预先大规模的计划、分析和设计,减少变化,反而是导致大量程序修改从而形成返工和浪费的祸首之一。

为了避免后期程序的修改,需要我们拼命地绞尽脑汁,显著地(一倍甚至两倍)延长计划、分析和设计的时间,这么做非但不能消除、避免变化和程序的修改,反而会造成更多的浪费。

使用道具 举报

回复
论坛徽章:
62
ITPUB9周年纪念徽章
日期:2010-10-08 09:28:522012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14
 楼主| 发表于 2009-8-18 14:48 | 显示全部楼层
项目后期的程序修改是否可怕?

可以分为两种情况:可怕与不可怕,正常与不正常。

可怕的修改是指项目后期发生重大的修改和返工,这种修改往往是架构级和全局的,容易导致项目的延期或失败,因此这种修改属于重大风险,应该避免。恰恰是缺少系统验证的瀑布式开发(全盘分析)容易导致这种可怕的程序修改。

风险驱动的迭代、演进式开发可以最大程度上避免这种可怕程序修改的发生。首先要求对系统的架构部分(风险最大的部分)进行设计、编码和验证,通过试探、检查和验证的方式在项目的前中期尽早稳定系统的需求和架构。这样到了项目的中后期,一般不大可能发生严重的架构级变更。即便出现了作者所说的“产生了问题需要回头修改”的情况,这种改变也是局部和少量的。

举个例子,你已经实现了 6 个需求,完成了 30 个类的设计和编写。如果你每次添加一个新的需求,或者修改原有 6 个需求当中一个已有的需求,或者修改已有全部 30 个类当中的某个类,就需要对所有的 30 个类及其方法都修改一遍?事实上在优良的采用了设计模式的 OOD 设计中,这种情况一般不大可能发生,需要修改(变化)的类和程序会被限定在一个较小的范围之内。如果发生了大范围的变化和返工,往往说明这是一个非常糟糕的设计(高耦合)。

目前在企业信息系统开发中,采用 OOAD 和 UML 建模技术比较普遍。优良的 OOA 和 OOD 可以做到高内聚、低耦合、具有高灵活性和可扩展性、架构稳定的软件。系统的业务逻辑层通常可以做到比较稳定,即便到开发后期,产生了问题需要修改,也是少量的,不会对系统架构造成严重的影响。

少量和局部的程序修改,哪怕发生在项目后期,也是正常的。

使用道具 举报

回复
论坛徽章:
1
ITPUB十周年纪念徽章
日期:2011-11-01 16:26:59
发表于 2011-9-15 17:29 | 显示全部楼层
跨年度的企业系统开发整体上是迭代,而具体到每一期的部分机能:(50个画面左右的子系统)就是瀑布了,目前为止所从事的项目基本上都瀑布。

一般内部项目和技术性研发性较强的项目采用迭代较多。
  不得不迭代的理由基本上是客户不能确认的情况下,采取做做看,一点一点 来的方针。

国内的情况是企业对信息系统了解不多,所以对自己需要什么没有整体概念,
所以导致最初定义的东西到后期来看不是所需要的。
但是对于日美等发达国家,企业系统都是运行多年,对需求能有一定把握,基本通过需求定义来明确自己的需求。多数情况下,客户能确认大体需求,具体细节没有考虑,这样通盘考虑还是必需的,特别是数据加工链较长的业务需求。

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表