第8节

当中，该如何面对困境？记 住！在这种荒谬的环境中，任何正常人都会失去理智， 而组织中弥漫着不理性的行为，它的未来必定走向不可 理谕，你在这里一点希望都没有，身为惟一头脑清楚的 人，必定会被旁人当成是疯子。也许你可以明哲保身地 在这种自我毁灭的组织中勉强活下去，但你不可能会有 什么像样的作为。但是无论如何总得解决这个问题。所以你在接受不 合理命令的同时，还是要很技巧地提醒你的昏君，这样法则25建拒绝不合理的命令

187做是不对的，无法这样做是因为事实的要求。权力不是 万能的，他们的做法行不通，你得帮助你的昏君明白， 大家都在拼命完成皇上的目标，而不是团体的目标，如 果能够多点参与，情况一定会比较好，人们也会因此而 做得更快，更愉快。开发进度表应该由下而上来拟定，每一个人负责自己 的工作，也负责设定它的时间表，负责准时完成工作。责 任和充分授权是一体的两面，二者兼备才能拟出合理的开 发计划。

法则 26

Now go play把工作当作游戏吧法则26建把工作当作游戏吧

189如果把软件开发当成是一种工作，那实在是一个索 然无趣的职业；从另一个角度来看，我建议你把它当成 游戏。

在布局时期，每件事情都按步就班进行并不是成功的保证。

如果你引用我的法则来建立你的团队，虽然软件还是 同一个，但你会发现他们更自动自发、反应更快、更多幽 默、更容易做出令人欣赏的软件。把竞赛当成游戏，你比 较容易赢。计算机其实是个充满趣味和挑战的玩具，而开 发人员呢？当然是大玩家口罗。在健康的团队中，以游戏的方式来做事是很自然的。 管理者不需要做什么特别的举动，只要避免限制组员的发 挥，和注意大家是否乐在工作又自动自发就行了。鼓励组 员快乐，不要怕他们分心，这可能是创意的泉源。软件开发这场游戏，会自然而然地产生规则，做得好 的人自然会获得奖励，而做得不好的人自然会受到惩罚。 管理者不必操心正义和仲裁，游戏本身的奖惩比你做的奖

惩要更有效果。

用游戏的心情工作并不是罪过法则26建把工作当作游戏吧

191这个游戏能给你什么好处？多玩玩它，练习它，感受 它的趣味，并且喜欢它。如此一来，软件创造本身的趣味 会使僵硬、骄横和严肃都消失，这样最好。在布局时期，每件事情都按步就班进行并不是成功的 保证。本篇的目的是告诉你如何在发挥团队最大潜能之前， 准备好你的团队。本篇并不是成功的公式，而是伟大的先 决条件。如果每件事都能在布局时期就照本书的法则进行， 那么以后仍然会如此进行，协助你的团队成长起来。

Part 第二篇 中程时期

中程时期

195本书为了帮助读者建立清楚的观念，将软件开发过程 划分成四个阶段，然而在实际运作上真的很难这样 做，各个阶段彼此都有重复的部分。在本篇中，我不设章节段落，因为这一部分的内容用各项法则来说明比较清楚。 因此请不要以为我在每个阶段所用的法则仅适用于该阶 段。事实上，我所提出的法则都是观念，适用范围是整个 的软件开发过程，好的开发团队应该随时随地注意每一个 法则是否被实践。而在起始阶段所提的各项法则，如果你 有做到的话，你会发现在孕育阶段更容易实践它们，因为 你已经练习过这些方法。在起始阶段的主要目的是让团队凝聚并建立对团体与 产品的目标，而蕴育阶段则是充满对目标的期望、不确定 和挣扎，所有的事情都是一片混沌，并且充满对可能失败 的恐惧。这时候，毅力是最重要的。暂且不管你的团队是 多成熟，暂且不管你经历过多少次这种场面，或是产品出 炉时会有多伟大，孕育阶段总是可怕而乱糟糟的，你随时 都可能遭遇意外打击或是想象不到的失败，但绝对要坚持 下去。你很可能会有那种心情：但愿有条路让我逃离这一切， 每个项目都会有这种时候。每件事情都无法确定，于是组

员的心情开始恶劣，冷嘲热讽、消极抵抗都来了，几个月 下来不见天日的辛勤工作，使得组员好似得了坏血病。这 场灾难似乎永无休止，可怕啊！

深呼吸一下，进入孕育阶段吧！

中程时期下载

法则 27

Be like the doctors用医生的方法

当病人已经药石罔效时，医生通常会对病情有所保留， 避免病人太过悲观或恐惧，并且尽量鼓励病人保持希望， 最好能让病人有个期望完成的目标。软件开发在这方面也 很像医学，它不是完全能用科学来解决一切。只是很不幸， 到目前为止，一般人还不了解软件开发是一门艺术─是 必须具有技术专长的艺术。现在，你得学着用医生的方法。医生绝对不会斩钉截 铁地断言什么医疗行为一定会有什么样的结果，反而是以 一种自在且充满信心的口吻说：“试试看吧，一切都还没 有确定呢。”反观软件项目经理人，常常在还不确定是否 可行时，就率尔对团队保证产品的特色、时间等等。更糟 的是，医生往往是在整体系统大都健全的情况下，对其中 的一部分功能做医疗；而软件开发则常常得面对全新的、 从来没有运作过的系统，不确定性更高。

当然，任何情况都是有可能的，即使是再简单的医疗行为，都可能有风险。

另外一件应该向医生学习的事情是，即使是再小再简法则27建用医生的方法

199单的医疗行为，都带着几分风险，所以医生会说：“当然， 任何情况都是有可能的，治愈率再高我都不能跟你说百分 之百没问题。”如果这样说都还不能让组员明白任何未来 的事都有不确定性、都有风险，那我也只好束手无策。我们必须记住，面对软件开发的不确定性，总会有方 法可以试试看。就像医生会试着让病人了解任何医疗行为 都有风险一般，管理者也应该让组员了解，任何项目都有 不确定性和风险。

“一切都还没有确定呢。”

法则 28

Remember the triangle: features, resources, times 软件开发金三角：特 色、资源和时间法则28建软件开发金三角：特色、资源和时间

201作为一位软件开发的领导人，你得集中注意力在三件 事情：资源（人和钱）、特色（产品与其品质）和时间。 这三件事是软件开发的核心，其他的都是外围。资源、特 色和时间是三角形的三个边，任何一边的变化，都会影响 到另外一边或两边。所以如果时间落后了，去看你的三角 形，看看对特色和资源的影响；当有人谈到可以增加什么 功能特色时，你得立刻谈起时间和资源，以显得你思虑周 详反应敏捷。所以，管理者的第一要务是把这个三角形放 在心里，随时利用这个模式来思考问题，你会发现答案都 在这个三角形内。“好吧，我的时间落后了，我得利用另 外两个边来弥补，或是三边都得调整，我可以少一点特色， 我也可以加一点资源，或是修改一下时间。”由于人、时 间和特色都是你最关心的，所以你对这个三角形有具体的 概念，很快地，你就会发现这个三角形对你的思考帮助非 常大。

软件开发的金三角法则28建软件开发金三角：特色、资源和时间

203还有一点要记得，时间落后时，你只有四种选择：增 加时间、减少特色、增加资源或三者同时进行。但人是不 可以随便增加的。

不可加派人手？

你是否听说过，加派人手是个错误的决策？在 佛莱德·布鲁克有关软件开发的经典著作《人力资源 之钥》（The Mythical Man-Month）中，用了很大的篇 幅来阐述他的论点：在软件开发项目中不当地增加人 手，反而会使工作进行更慢。布鲁克的观点被证明是 非常正确的，但我们应该了解的是，布鲁克是在写一 本书，而不是写一部适用的律法。然而，传统的教育使得人们用太过单纯的理解 方式，使得布鲁克真正的睿智多少被曲解─绝对不 要在进行到一半的开发团队增加人手，重点是“进行 中的团队”。虽然布鲁克十之八九是对的，但却成了 太多管理者的借口，理直气壮地决定不加派人手。是 的，增加人手是很难管理（人员应该在项目开始前就 规划妥当），通常也不是个好办法，只有在非不得已 时才考虑，但不是被禁止的。

法则 29