交付驱动方法的情况(软工系列文章之四)

原创 2001年02月10日 08:59:00

交付驱动方法的情况,A Case for a "Deliverables Driven" Approach
  By Russ Finney

(来自软件工程论坛 seforum.yeah.net)
 (翻译yanrj )

   很多系统建造者认为交付证实的项目完全是一种费时的活动。他们给出持这种看法
的原因:
   *为什么建造出来的东西最终会改变并变得过时?
   *编制正规文档将占用真正任务所用的时间:为系统编制代码。
   *我喜欢在这个过程的每个阶段公开放弃我的选择,编制文档首先将使我作错事。
   *如果它不被写下来,我能不对它负责(这里事情到处发生-你不得不掩盖每条可能
发生的事情)
   采取基于可交付方法的原因:
   *它促使决策制定和问题解决。
   *它产生确实的期限。
   *它鼓励信息的完整性。
   *它提供向开发者反馈的机制。
   *及时记录项目的状态。
   *给团队的成员以成就感。
   Tom Demarco在他的书《控制软件项目》中,讨论了基于可交付方法对于一个管理
者的项目计划和控制策略应该产生的影响。作为讨论的一部分,他引用了项目模型的
主要规则:
   *项目的活动由它的可交付性制定。
   *每个可交付有一项活动。
   *这项活动的工作是制造这个可交付系统的工作。
   *当可交付系统交付并被接收后活动完成。
   面向可交付的项目模型可能产出一些极大的活动,至少是一般项目控制系统的任意
的标准。但是进一步的将这些大的活动分解成生产不可辨识产品的构件使将付出投入
到详细设计的构想。
   Fred Brooks在他的名著"The Mythical Man-Month"(davew注:Frederick
P.Brooks,IBM OS/360之父,他的这本书问世近近三十年,至今畅销不已,每次再版
只是附增加Brooks新论文或新观点而已,如大家常常提的No silver bullet,原文
近乎不变。此书兄弟早期只是读了《Datamation》节选的7页,后来弄到原书,苦读n
遍,收获不少,建议大家多看看),对采用基于可交付方法的价值给出了更好的洞察
结果:
   “为什么要有正式的文档?
     首先,将决策写下来是关键的。只有写出后差距才能出现,矛盾才能突出。写的
过程是需求成百上千的小决策的过程,这些的存在将清楚的、准确的政策从模糊的政
策中区分出来。
     其次,文档将会与其它人交流决策。管理者将会不断感到惊奇的是他采取的一般
知识的政策团队有些成员竟全然不知。既然他的基本工作是使每个人在一个方向上前
进,他的主要工作就是交流,而不是决策制定,他的文档能很好的减轻这个负担。
     最后,管理者的文档给他提供了一个数据库和检验表。通过定期回顾他能知道自
己所处的位置,并看到为需要要对重点改变什么或方向作什么变动。”

 

 

A Case for a "Deliverables Driven" Approach
By Russ Finney
 
Many system builders consider formal project deliverables to be a
complete waste of time. They give the following reasons for holding
this opinion:
  * Why produce something which will just eventually change
    and become out-of-date anyway?
  * Producing formal documents takes time away from the really
    important task:  programming the system.
  * I like to leave my options open through each phase of the
    process, and producing a document may commit me to something
    which was wrong in the first  place.
  * If it is not written down, I can't be held accountable for
    it (and the way  things go around here - you have to cover
    yourself every way possible!).
 
Reasons for taking a deliverables based approach:
  * It forces decision making and issue resolution.
  * It creates tangible deadlines.
  * It encourages information completeness.
  * It provides a mechanism for feedback to the developers.
  * It records the state of the project at a moment in time.
  * It gives the team members a sense of accomplishment.
 
Tom Demarco in his book, Controlling Software Projects, discusses the
impact that a deliverables based approach should have on a manager's
project planning and control philosophy. As a part of this discussion
he refers to the Cardinal Rule of Project Modeling:
  * A project activity is defined by its deliverable.
  * There is one activity per deliverable.
  * The only work charged against that activity is work spent producing
    that deliverable.
  * The activity is complete when the deliverable is delivered and accepted.
 
Deliverable-oriented project modeling may yield some overly large activities,
at least by the arbitrary standards of common project control systems. But
further dividing those activities into components that produce no discernible
product is to invest precious effort into an illusion of detailed planning.
 
Fred Brooks in his classic book, The Mythical Man-Month(davew注:Frederick P.
Brooks,IBM OS/360之父,他的这本书问世近近三十年,至今畅销不已,每次再版只是附增
加Brooks新论文或新观点而已,如大家常常提的No silver bullet,原文近乎不变。此书兄
弟早期只是读了《Datamation》节选的7页,后来弄到原书,苦读n遍,收获不少,建议大家多
看看), gives even greater insight into the value of taking a deliverables based
approach:
 
"Why Have Formal Documents?
 
First, writing the decisions down is essential. Only when one writes do the
gaps appear and the inconsistencies protrude. The act of writing turns out to
require hundreds of mini-decisions, and it is the existence of these that
distinguishes clear, exact policies from fuzzy ones.
 
Second, the documents will communicate the decisions to others. The manager will
be continually amazed that policies he took for common knowledge are totally
unknown by some member of his team. Since his fundamental job is to keep everybody
going in the same direction, his chief daily task will be communication, not
decision-making, and his documents will immensely lighten this load.
 
Finally, a manager's documents give him a data base and checklist. By reviewing
them periodically he sees where he is, and he sees what changes of emphasis or
shifts in direction are needed."

版权声明:本文为博主原创文章,未经博主允许不得转载。

量化杂谈

转载 【量化杂谈之基础篇1】获取所有股票的代码和名字——一个爬虫的简单例子 http://bbs.pinggu.org/thread-4145710-1-1.html 【量化杂谈之基础篇2】回测的那些...
  • xf_87
  • xf_87
  • 2017年04月15日 14:35
  • 198

软工之管理

软工管理
  • u012704843
  • u012704843
  • 2014年09月28日 19:44
  • 863

Google 黑板报 -- 数学之美 系列

Google 黑板报 -- 数学之美 系列Google 黑板报 -- 数学之美 系列一 -- 统计语言模型 Google 黑板报 -- 数学之美 系列二 -- 谈谈中文分词 Google 黑板报 --...
  • lyflower
  • lyflower
  • 2006年12月21日 15:07
  • 3091

以人为本 | 如何保证高质量的软件交付

软件团队想要保证高质量的软件交付,一般情况下会想到以下几点: - 多的测试人员 - 高薪资、福利 - 各种质量管理工具和手法 - etc… 我们有大量的实际经验表明,这些方法往往没有达到预期...
  • u011938906
  • u011938906
  • 2015年11月09日 13:44
  • 537

如何保证项目按期交付

如何提高项目的生产率,保证项目按期交付是每个软件开发项目经理都需要面对的难题。关于这方面的研究,在《人月神话》、《人件》等书籍都有很详细的论述。研究表明,不同程序员之间的生产率最高差别在40倍以上。虽...
  • zhou699
  • zhou699
  • 2012年02月10日 10:57
  • 2300

什么才是合格的系统交付-交付内容说明

现在随着互联网+,大数据,云计算等新兴技术的兴起,越来越多的企业参与进来,想通过新的手段来促进企业在市场中更好的发展。所以企业就需要通过信息化来逐步改变传统的办公方式,将线下办公转变为线上办公。所以就...
  • u013560667
  • u013560667
  • 2017年01月13日 15:15
  • 895

openjudge 9286:盒子与小球之四 (dp)

9286:盒子与小球之四 总时间限制: 1000ms 内存限制: 131072kB 描述 给定N个各不相同的小球,和M个不同的BOX,有多少种不同的放球方法,使得...
  • clover_hxy
  • clover_hxy
  • 2016年10月26日 16:40
  • 575

数据结构实验之查找四:二分查找

数据结构实验之查找四:二分查找 Time Limit: 20ms   Memory limit: 65536K  有疑问?点这里^_^ 题目描述 在一个给定的无重复元素的递增...
  • guoqingshuang
  • guoqingshuang
  • 2015年12月04日 09:51
  • 967

SDUT 3401 数据结构实验之排序四:寻找大富翁 堆排序

题目链接: http://acm.sdut.edu.cn/sdutoj/problem.php?action=showproblem&problemid=3401 数据结构实验之排序四:寻找大富...
  • Autii
  • Autii
  • 2016年05月05日 22:22
  • 967

白盒测试中的逻辑覆盖

逻辑覆盖属于白盒测试,是以程序内部的逻辑结构为基础的设计测试用例的技术。         它分为语句覆盖,判定覆盖,条件覆盖,判定-条件覆盖,条件组合覆盖,路径覆盖六种 其中,前三种覆盖程度较低,在不...
  • u010066934
  • u010066934
  • 2013年10月29日 22:51
  • 1595
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:交付驱动方法的情况(软工系列文章之四)
举报原因:
原因补充:

(最多只允许输入30个字)