這是關于一個項目的故事，與其它項目相比，既不非常復雜，也不是很簡單： 一個應用程序與數據庫以及其它兩個系統通信。這在技術和架構角度都是主流，而在管理角度則是標準情況： 所有工作都應該在昨天完成，但還有很多沒有完成的。簡而言之，“這很難！” （這是開發者經常表達的一種情緒，但是誰都不會太大聲地把它喊出來。）

為此我們創建了團隊。雇傭了四十位員工并指定了他們的角色。我們把團隊分為小組，并在不同的小組之間設置了一種契約。每個小組負責應對特定類型的要求。這樣就形成了要求的流程。指定的小組會承受很大壓力，并成為瓶頸： 在上游小組中會創建要求，而下游的小組會等待這些要求。對于那些有壓力的小組中的要求，重要的事情會變為緊急的事情。我們必須在緊急的事情之中做出選擇，以解決最亟待解決的問題。我們經常需要在任務之間切換，最終，這導致流程變得很慢。

然后發布的最終日期臨近了： 就在兩個月之后。用戶接受測試剛剛開始，但是不同組件之間冗長而痛苦的整合過程導致了測試的延遲。可能正是在團隊之間創建的契約讓整合變得如此復雜： 其中缺少一些必須的參數，日期格式不合適，只有部分錯誤代碼能夠得到解釋……

在任何情況下，用戶接受測試都會檢測出很多的bug，而開發團隊來不及解決，這樣就無法對系統進行徹底的測試。

因此我們增加了更多人力。我們設置專門的團隊來解決bug，在另一個地方的團隊會完成開發，還有一個團隊會整合不同的組件。但所有這些團隊共享同樣的代碼，對某些代碼做出的改變會影響其他團隊所做出的修正。

接下來我們可以預測出這樣的做法導致的結果： 開發者通宵加班，周末也要工作；最終日期被一再推遲，最初的工作任務范圍發生了變更（減少了內容）；然而，多虧了計算機科學的奇跡，應用程序最終發布并運行了！

　　這是多年以前的事兒了。我認為這是“要走的路”，并且所有項目都以相同的方式管理。從那開始，我經歷了各種不同的情況，讀了很多資料，并與很多人做過相關的討論。現在我能夠從不同的思想角度來看待這個故事。

　　創建IT系統是一種非常復雜的機制，其中不僅混合了技術、架構技能，還有管理以及與人相關的技能。在這兩個領域有多種文化，但是關于構架系統的管理和人的部分，我認為Tom De Marco是我最喜歡的作者之一。我還記得他出版的兩本書。在第一篇無標題的“軟件工程： 關于誰的時代來臨和消失的想法”中，De Marco討論了對軟件項目的控制（的幻想）。在第二篇“放松（Slack）”中，De Marco研究了管理學中的經典問題，并說明更多的放松能夠如何幫助組織具有更強的適應性，最終獲得更高的效率。

　　但是，帶著這兩篇文章中的想法，讓我們回到故事中，看看如何才能避免很多典型的問題。

　　沒有優先級，或者是著名的“我們全都需要”

　　Tom Demarco向我們展示了一種方法來避免整體上陷入困境，也就是“每項功能都非常重要”的項目：

　　例如，你和團隊的領導說，我時刻記著完成時間，但是我不會與你分享這個信息。當有一天我告訴你項目會在一周內完成時，你需要準備好打包，并把你所得到的東西作為最終產品發布。你的工作就是持續地為項目工作，按照相對值的順序向其中添加內容，并在過程中持續地完成集成、編寫文檔以及驗收測試工作。

　　簡言之： 工作的目的是第二天就可以發布

　　如果不考慮實際的組織和技術上的問題，你需要有意識地對軟件進行持續構建。團隊之間的合同責任很有限，從而無法在技術上或者任務上組織它們，而只能在業務特性上做到這一點。從技術的角度，每個團隊都是這樣，要負責讓完整的功能可以很好地運行。從管理的角度，經理和業務人員需要作出選擇： 什么是必須需要的特性。根據我自己的經驗，你在需要符合交付日期的環境中工作的時間越長，這種特性團隊和組織就會對你起到更大的幫助。

　　管理壓力和恐懼文化

　　我們在這里還要看看De Marco關于恐懼文化和它的特征是怎么說的：

　　“……在具有恐懼文化的組織中，會具有如下特征：

• 說特定的問題是不安全的（例如，我很懷疑是否能夠達到這個限額）。
• 目標設定得非常高，看起來沒有完成的可能。
• 允許權利超越一般的常識……”

　　當我想到恐懼管理的時候，就會想象到一種專橫的身體語言，他會在位置上對協作者大喊大叫，會用拳頭敲桌子……這是非常具有諷刺意義的樣子。這看起來像是在背后說人壞話，但是我們不得不承認，人們經常會處于這樣的壓力之下，難于提出警告，設定截止日期而不考慮團隊是否能夠承受，最終，團隊會處于經理根據他們自己的地位所做出的提交壓力之下。

　　當然，了解問題只是第一步。我們怎么才能解決呢？ 當經理不了解風險所在，并且拒絕接受那些不可規避的風險，我們應該怎么辦呢： 你需要選擇，按優先級排序，并協商范圍，以確保截止期限，或者把它延后。

　　這個任務絕對不是個簡單的任務，我現在所能夠給出的最佳答案就是backlog和燃盡圖的組合。依我所見，在以下各種情況下，這會有些好處：

1. 把所有任務集合在一起（技術上的、功能上的任務等等）。當然，我們可以通過用例或者特性來組織和統一這些任務。
2. 把任務與所有項目參與者共享。換句話說，讓更多人知道哪些工作是必須要完成的。
3. 顯示出信心，并制定切實可行的截止日期，從而讓項目經理可以有效地排定任務的優先級。
4. 顯示所有添加的任務，那可能會推遲最初制定的截止日期。

　　在上線前的幾周，當前組織的壓力比較大，因此我們決定要增加人手

　　Brook在1975（我還沒有出生）年聲明了一條規則：

　　“向已經延遲了的軟件項目中添加人手，只會使其延遲更嚴重。”

　　我們都已經對此深有體會。但是我們不得不承認，一般我們還是想要通過增加人力來保證在截止日期之前發布，而不是改變最初定義的范圍，并保持最優化和合適的團隊規模。Brooks對他的規則做出解釋，其中有兩個主要的觀點。 第一點關注于新的團隊成員，我們需要對他們進行培訓，那會耗費現有人員的工作時間。第二點是一個“神話”，讓我們相信開發任務可以任意分解，而不需要考慮工作中很多部分都需要智慧，并且還需要所有開發者之間必要的溝通。此外，我們還能發現更多與組織開發相關的困難，并且需要在所有開發人員之間共享同樣的代碼。這么多的細節會降低團隊的生產力。

　　Tom de Marco為我們做出了他對Brooks的規則的理解，他稱之為“人浮于事（overstaffing）”。

　　“按時完成并非是最重要的。重要的是看起來你已經做出最大的努力來按時完成。在這個“吃得少跑得快”的時候，對于你來說，使用少數（優化的）人員來運轉項目是很不安全的。”

　　請再次讀一下，這次慢一些。你不認為這是一種很有趣的觀點嗎？ De Marco所建議的，或者說我的理解是，我們之所以不增加人力，是因為我們認為那會更快更好地完成工作。我們添加人力只是作為一旦失敗時的借口。就像小孩子喜歡說的：“ 那不是我的錯，我已經盡力了。”

　　這是多么自然的反應啊！ 想要改變這種行為，首先需要改變我們的教育方式（并學著從失敗和錯誤中吸取教訓），并且組建一些組織，讓失敗成為其中的一種選擇（當然不要太多）……

　　“一切都一直在失敗”。你為什么不積極處理，而只是忽略它呢？

　　和通常情況一樣，批評很容易，而藝術地處理則很難。那樣，我們會注意到相同的錯誤一次又一次發生，而很少試一下其他方法（當然，這些方法也會存在其他限制）。“風險管理是為失敗做計劃的方法”（Slack, Tom de Marco)，并且這可能正是我們擅長之處。Werner Vogels說過：“一切都一直在失敗”。

　　他們所要表述的是： 我們很難避免失敗。就像往山上滾石頭的人一樣，如果想要爬得更高，走得更遠，就必須接受石頭會落下的事實，那是通往成功的必經之路。所以擁抱它、處理它，并從中學習吧。

　　Tom De Marco告訴我們，想要管理風險，首先需要把它們識別出來，然后對其進行監控，設置指示器，當失敗發生的時候會為我們提出警告。有時，我們需要找到其他方法。有些人需要培訓。我們會開發軟件的并行版本，這樣，在做決定的最后時刻，我們就能夠選擇最適合的解決方案（精益管理把這叫做“基于設計設置（set based design）”原則）。

　　但是風險管理不僅僅是計劃。從架構的角度來看，風險管理當然還意味著可依賴性的管理： 從災難中恢復……但這種風險管理的方法意味著要為我們的系統制定架構——與業務部門的人員緊密合作——從而管理并擁抱所有這些錯誤。換句話說，就是盡可能地預測我們架構中可能發生的錯誤情況：

• 如何管理一種降級的模式，從而在整個系統的某個部分不可用，或者訪問者的數量超出預期時讓系統仍然可用？
• 在發生錯誤的時候，需要執行哪些過程（如果需要手工過程的話）來終止業務處理？
• 想要完成業務處理，需要哪些命令信息？
• 警告機制是什么樣的，從而可以根據最終用戶的需要提前激活，通知他發生了錯誤，并幫助他恰當地終止正在處理的工作。
• …

　　在現存的系統中，我們需要讓它發展（而不是變革），從而確保這些已經檢測出來的錯誤情況都被徹底修正。

　　但讓我們現實一些。如果你是成本驅動的，那么你會發現所有非業務的需求都沒有用。但是，最終我們對于應用程序的信心不正是就它管理錯誤的能力（彈性和可靠性）嗎？絕對不是其它標準嗎。

　　結論： 那又怎么樣呢？

　　還有另外一個故事，屬于另一個項目，既不非常復雜，也不是很簡單。和其它所有項目的情況一樣，其中有很多需要做的工作。開始時，IT和市場團隊一起定義了清晰的路線圖。

• “我們希望在四個月內發布新平臺，其中會實現最簡化的市場特性。對于訪問量，我們期望每小時會有3000次，而80%的訪問者會使用新特性。”這是市場團隊所說的。
• “OK。”CTO說。“我們需要添加一些非功能性的特性來限制對平臺的訪問，以防我們的預測出現錯誤。在這些額外的特性中也會有一些技術風險，我們需要盡快確認。可能我們需要在下一次發布中看是否能夠完成這些內容。”
• “沒問題。盡快告訴我們關于這些風險的信息。在接下來的月份中，我們就會需要這些新特性……”
• - …

　　隨著特性團隊負責實現完整的用戶故事、修正bug并部署他們的代碼，平臺變得越來越大。

　　當然，IT也遇到了技術問題。業務和IT部門需要一起來對路線圖進行修正。最后期限已經到了，而有些特性被推遲實現了。那些都是優先級最低的特性。

　　當然，市場預測也不怎么好。CTO向平臺添加的非功能特性（例如，記錄所有用戶行為的日志，或者當達到已知平臺限制的時候限制訪問）在發布平臺的過程中非常有用，幫助市場團隊改進了預測。用戶愿意使用這個新平臺，并且信任它。

　　在開放的空間中，墻上也充滿了信息。燃盡圖和累計流程圖顯示了團隊的速度和問題，以及下次發布的目標……

　　在這個項目中，還雇傭了一位技術專家： 那是CTO不想放過的機會。

　　不管怎樣，項目進行良好，并且還在運行中。技術人員們對自己所做的工作感到自豪……

　　查看英文原文：The Story of a Project