模板
教程
环境
性能
功能
管理
30年后仍适用的软件项目管理概念
发表于：2007-11-19来源：作者：点击数：
标签：项目管理
在人月神话中，工作完成所需的月数，会因人员的增加而递减，然而由于软件项目是交互关系复杂的工作，需要大量的沟通成本，因此人数的增加，容易因沟通问题，反而无法达到预期的效果。 The Mythical Man-Month 人月神话，探究工时与人力无耗损互换的迷思 人月
在人月神话中，工作完成所需的月数，会因人员的增加而递减，然而由于软件项目是交互关系复杂的工作，需要大量的沟通成本，因此人数的增加，容易因沟通问题，反而无法达到预期的效果。
The Mythical Man-Month
人月神话，探究工时与人力无耗损互换的迷思
人月神话》出版至今已经超过三十年，一直被视为是软件项目管理的圣经。《人月神话》之所以能历久不衰，一方面是作者Frederick P. Brooks, Jr.本身曾担任IBM System/360与OS/360这类大型软件系统项目的项目经理，因此能从实务中提取出具体意见。另一方面，即使IT产业在这三十年中飞快成长，然而《人月神话》对于软件项目提出的看法与建议，至今仍有参考价值。
所谓的人月（man-month）是用来衡量工作量的单位，也就是一个人在一个月内所能完成的工作量，例如有个项目预估需要12个人月，那么如果派了4个人来处理这项项目，理论上只要三个月就能达成。Brooks之所以将这个换算的机制称为神话，是因为软件项目在本质上，人力与工时是无法互换的，换言之，当项目进度落后时，光靠加派人力到该项目中，并不会增加产能，反而有可能让情况更加失控。
Brooks认为，软件项目在本质上是系统性的工作，在过程中必须处理复杂的交互关系，在沟通上必须花费不少的成本。
因此Brooks认为，在项目的人员配置上，最好是有如外科手术团队，利用支持性的角色，协助操刀的外科医师，让开刀过程可以更流畅，而不是让整个开刀床旁围满了一堆外科医师。另外书中也针对软件项目的问题，像是架构与实作的分野、沟通的方式、软案时程预估、预防失败等多种面向，提出理论与实务兼俱的立论，希望藉此让陷入困境的项目能顺利走出焦油坑。
Tar Pit
焦油坑
焦油坑是因石油挥发而成的黏稠沥青，表面会因日照而反射出光亮，而让野兽误以为是水池而走近，最后陷在其中无法逃脱。
Brooks以焦油坑作比喻，形容他观察到的大型系统的软件开发。虽然系统最后总能释出、运作，但是开发团队往往无法达到既定的目标、时程或预算上的要求，因此被种种问题困住的开发团队，就好像跳不出焦油坑的巨兽一样。
Tractable Medium
易操控介质
在论及写程序的乐趣时，Brooks举出数个原因，包含创造的乐趣、有益于他人、可目睹成果动起来、持续学习的乐趣，以及最后的原因便是易于操控的介质。
在介质这一点，Brooks将程序设计师与诗人相提并论，只要动动脑筋，两者就可以创造出美妙的事物，而更甚于诗人的是，程序设计的结果，能具体让人感受到它的运作。一些问题也伴随容易操控的特性而来，软件工程便是在解决这些问题。
Aristocracy
贵族政体、菁英份子
软件系统在设计时，至关重要的一点是保持概念的整体性（conceptual integrity），Brooks认为宁可丢弃某些新奇或更好的特色，以反映出同一组设计理念。
为了达到这样的目的，在设计系统时，必须采用少数人决定的方式，类似于贵族统治的方式，由架构设计师这类角色，决定系统整体的规格。虽然在开发团队中采用民主方式，可以广纳意见与创意，却会破坏概念整体性。
Tower of Babel
巴别塔
巴别塔是圣经上的知名故事，人们想要合作搭建通天的高塔，上帝于是将人类的语言分成多种言语，彼此即无法沟通，高塔的任务即告失败。
Brooks用这个故事来聚焦软件开发过程中沟通的重要性，他指出许多问题都源自左手不知道右手在做什么的情况，因此开发团队成员应该应用各种方式，包含非正式方法、会议与工作手册进行沟通。
Document Hypothesis
文件假说
「在成堆的书面数据中，有一小部分关键性文件记录着任何项目管理的核心工作，而这些文件是身为管理者最重要的工具。」这是Brooks提出的假说，而他透过与其它产业运用文件的情况，验证这个假说的真实性。
纸上作业经常被视为繁琐、无趣，但Brooks认为对管理者而言，文件能让团队的思考与讨论更集中，也能作为监督和预警的机制，因此对软件工程的文件作业和其它产业一样重要。
Silver Bullet
银弹
在传说中，银弹是杀死狼人的致命武器，因此如果将软件项目比喻为狼人，那么能让狼人一枪毙命的银弹会是什么呢？Brooks怀疑这种银弹并不存在，这和软件工程的本质有关。
他认为软件工程的本质是架构许多抽象概念，并进一步制定规格、设计与测试，这造成它的高度复杂性，易变性、隐匿性等特质，因此软件工程，这些难度不会因为软件技术进步（像高级语言、整合开发环境）而带来根本性改变。
Catastrophe
大灾难
软件项目酿成不可收拾的大灾难究竟是如何造成的？Brooks认为大灾难其实就是每天一点一点地的延误中造成的。
因此日常的监控机制便相当重要，像是建立明确描述、可量测的里程碑（milestone），或是利用计划评核图来监控与应变进度状况。
另外，成立计划监控小组，担任进度的守门员，进而提醒团队容易疏忽掉的落后时程，对于项目有相当大的帮助。
Auxiliary Program
辅助程序
开发软件系统，测试与除错是相当重要的一环，因此建立良好的测试方案就至关重要。Brooks介绍了数种测试方案中应该包含的项目，而在介绍建立充份的测试鹰架（scaffolding）这个项目时，他介绍三种鹰架形式：傀儡组件、迷你档案和辅助程序。
辅助程序是用来产生测试数据、打印特定分析结果与分析交互参考的表格的工具程序，提升除错工作的效益。
Surgical Team
外科手术团队
Brooks认为太多人参与项目开发，往往会增加沟通的成本，容易因为传达不清形成不良影响。然而面对大系统，精简的人力又往往增加时间成本。
