|
|
交付驱动方法的情况
A Case for a "Deliverables Driven" Approach By Russ Finney
（来自软件工程论坛 seforum.yeah.net） (翻译yanrj )
很多系统建造者认为交付证实的项目完全是一种费时的活动。他们给出持这种看法 的原因：
*为什么建造出来的东西最终会改变并变得过时？
*编制正规文档将占用真正任务所用的时间：为系统编制代码。
*我喜欢在这个过程的每个阶段公开放弃我的选择，编制文档首先将使我作错事。
*如果它不被写下来，我能不对它负责（这里事情到处发生-你不得不掩盖每条可能 发生的事情） 采取基于可交付方法的原因：
*它促使决策制定和问题解决。
*它产生确实的期限。
*它鼓励信息的完整性。
*它提供向开发者反馈的机制。
*及时记录项目的状态。
*给团队的成员以成就感。
Tom Demarco在他的书《控制软件项目》中，讨论了基于可交付方法对于一个管理 者的项目计划和控制策略应该产生的影响。作为讨论的一部分，他引用了项目模型的 主要规则：
*项目的活动由它的可交付性制定。
*每个可交付有一项活动。
*这项活动的工作是制造这个可交付系统的工作。
*当可交付系统交付并被接收后活动完成。 面向可交付的项目模型可能产出一些极大的活动，至少是一般项目控制系统的任意 的标准。但是进一步的将这些大的活动分解成生产不可辨识产品的构件使将付出投入 到详细设计的构想。 对采用基于可交付方法的价值给出了更好的洞察 结果： “为什么要有正式的文档？ 首先，将决策写下来是关键的。只有写出后差距才能出现，矛盾才能突出。写的 过程是需求成百上千的小决策的过程，这些的存在将清楚的、准确的政策从模糊的政 策中区分出来。 其次，文档将会与其它人交流决策。管理者将会不断感到惊奇的是他采取的一般 知识的政策团队有些成员竟全然不知。既然他的基本工作是使每个人在一个方向上前 进，他的主要工作就是交流，而不是决策制定，他的文档能很好的减轻这个负担。 最后，管理者的文档给他提供了一个数据库和检验表。通过定期回顾他能知道自 己所处的位置，并看到为需要要对重点改变什么或方向作什么变动。”
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. 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."
[ 本帖最后由 流浪开心果 于 2008-10-14 09:31 编辑 ]
上一篇：软件工程系列翻译文章（之三）
下一篇：常见测试术语--基础篇 |
|
[复制链接]
service@step365.com
0571-87357690
狗仔卡
发表于 2008-10-14 09:29:14
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
转播
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
