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

很多系统建造者认为交付证实的项目完全是一种费时的活动。他们给出持这种看法的原因：

*为什么建造出来的东西最终会改变并变得过时？
*编制正规文档将占用真正任务所用的时间：为系统编制代码。
*我喜欢在这个过程的每个阶段公开放弃我的选择，编制文档首先将使我作错事。
*如果它不被写下来，我能不对它负责（这里事情到处发生-你不得不掩盖每条可能发生的事情）
采取基于可交付方法的原因：
*它促使决策制定和问题解决。
*它产生确实的期限。
*它鼓励信息的完整性。
*它提供向开发者反馈的机制。
*及时记录项目的状态。
*给团队的成员以成就感。

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 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.

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有