15.3.0 案例分析
可以看看這兩個學生專案的例子，推斷出這些團隊的血型：
STG遊戲的跳票（為了完美，推遲了7天，但是7天之後也沒有釋出……） [i]
英語學習軟體（說了“明早釋出”，但是明早一直沒到）[ii]
15.3.1 反動分子阿超
在最後的穩定階段，阿超不斷地把事情推到下一個版本，二柱和果凍都不耐煩了——為什麼不拼一下，把所有事情在第一版搞定？
阿超： 有兩種做法——
1. 根據事情的輕重緩急，安排大部分事情在下一個版本做。正因為我們對專案、團隊、商業模式有信心，才會把很多事情安排在以後的版本中。
2. 拼一下，把所有事情搞定，後果是大家都累得夠嗆，[leal2] 然後人也走了，沒有人有興趣做下一個版本。
二柱： 我記得當年我們公社組織修水利的時候，大家都拼了老命，有幾個前輩都犧牲了，才把水庫修好……難道這些不是有價值的麼？
果凍： 對！我記得山坡上還用巨石刻了一些標語，有兩個前輩就是犧牲在炸開巨石刻字的時候。
阿超： 是啊，現在看起來，那些刻在山上的標語是屬於可“cut”的功能。至少我們可以把它推遲到下一個版本。到今天，我們大家都意識到刻巨大的“人定勝天”標語不是特別重要的“功能”，對麼？這樣豈不更好？當年我們的叔叔伯伯們的確沒有必要“誓死完成”所有的任務。
二柱： 要在以前，你就是反動分子。
阿超： 我們寫商業軟體，是要賺錢養家，如果自己都做得疲憊不堪，精神不振，那拿錢來養啥？如果還要刻字，我建議在山坡上刻“以人為本”幾個大字。
15.3.2 銀彈之戰
銀彈：為了避免專案的成員為了一些問題爭執不休，移山公司發明了銀彈（Silver Bullet）這一工具。簡而言之，就是每個角色的代表（Dev/Test/PM）在專案過程中可以使用有限次的“停止爭論，按我說的辦”的武器 – 銀彈。銀彈一出，大家就要聽話。當然，銀彈用一個少一個，下次有爭論的時候，別人就更有機會使用這個手段了。
討論 - 銀彈真的有用麼？
15.3.3 扁鵲三兄弟
果凍： 我聽說了蘿蔔和白菜的故事，其實類似的事兒古代早已有之，請看一段關於“扁鵲三兄弟”的古文：
王獨不聞魏文王之問扁鵲耶？曰：‘子昆弟三人其孰最善為醫？’扁鵲曰：‘長兄最善，中兄次之，扁鵲最為下。’魏文侯曰：‘可得聞邪？’扁鵲曰：‘長兄於病視神，未有形而除之，故名不出於家。中兄治病，其在毫毛，故名不出於閭。若扁鵲者，鑱血脈，投毒藥，副肌膚，閒而名出聞於諸侯。（《鶡冠子·卷下·世賢第十六》）[leal5]
扁鵲是這麼說的：“俺大哥治病是看病人的神色，病還沒有表現出來他就把病給治了，所以他的名聲不出家門。俺二哥治病是在病人稍有不適的時候，就把他們搞定，所以他的名聲不出巷子。而我扁鵲看病用的是疏通血脈的針、有毒副作用的湯汁、埋入肌膚之內的草藥。所以我的名聲反倒傳遍了各個諸侯國。”
二柱： 這個跟王屋河的防洪是一個道理，上游搞得好，不發洪水沒人知道，下游要決堤了，一堆人上去堵，死傷幾個，就出名了。我們最善於搞末端治理。
在軟體開發上，如果專案早期就發現並解決了問題，除了“家裡人”，沒人知道；專案中期發現問題並解決，專案的許多相關人員“公司”都知道了；專案後期出了問題，我們要加班，重寫程式碼，hack原來的設計，開一些後門來解決問題（下一些副作用很大的猛藥），總算把專案給救活了，這時候全公司的人都知道了。
阿超： 我記得小學六年級學過“曲突徙薪”的故事，也講了類似的道理。我們往往獎勵末端治理的英雄，但是最初提建議的人未必得到獎勵，移山公司會不會也是這樣？
15.3.5 一個Postmortem 的例項
移山公司 Stone 專案 Postmortem 結果
1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和 典型場景有清晰的描述？ 想做的事情還是太多，導致很長時間不能集中精力。
2. 是否有充足的時間來做計劃？ 有時間，但是大部分人並不知道如何利用這一段時間來做計劃。
3. 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？ 主要通過喝酒聊天解決，另外阿超有某種“光環”，大家對他有些崇拜， 這樣他說的話別人都比較容易接受，也沒有特別強烈的不同意見。
計劃
1. 你原計劃的工作是否最後都做完了？如果有沒做完的，為什麼？ 很多事情都沒做完，大家認為最後沒做完的事情，都是可有可無的。
2. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事？ 很多，但是大家認為與其不斷地爭論某些事情有沒有必要，不如做了 再說。
3. 是否每一項任務都有清楚定義和衡量的交付件？ 大部分都沒有，因為我們大家都不知道做到多少才叫“好”。有些情況下， 大家對細節過早地進行討論，花了很多時間。不如等到後來再討論。
4. 是否專案的整個過程都按照計劃進行？ 基本上，因為阿超的“光環”，大家大部分情況下都聽他的。
5. 在計劃中有沒有留下緩衝區，緩衝區有作用麼？ 有緩衝區，原來認為沒有必要，後來發現還是有用的。主要是各人進 度不一，有些模組不斷地有一些小問題，花了很長時間才能做好。
6. 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班。） 應該明確緩衝區的長度。
資源
1. 我們有足夠的資源來完成各項任務麼？ 很多情況下，花了不少時間來設定機器，以及設定用來測試的資料。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何？ 開始精度很粗略，後來隨著專案任務的加重，大家只顧得上幹活，沒 時間考慮精度問題。
3. 使用者測試的時間，人力和軟體 / 硬體資源是否足夠？
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）？
比如網頁的 CSS 設計，最好由美工設計來做，開發人員最後做實現即 可。我們要有專職的設計，不要臨時拉人來幫忙。因為臨時幫忙的設 計師對整個專案瞭解不多，事後也找不到他。
變更管理
1. 每個相關的員工都及時知道了變更的訊息嗎？ 由於大家都坐得比較近，小道訊息傳播得比較快。
2. 我們採用了什麼辦法決定“推遲”和“必須實現”的功能？ 用了“銀彈”，除了導致一場短時間的鬥毆之外，還可以。銀彈的目 的就是一種威懾。
3. 專案的出口條件（Exit Criteria）是否得到清晰的定義？ 大家都不太懂“出口條件”是什麼，經過這一個專案之後，稍稍清楚了一些。但是說實在的，在這個專案裡面我們沒有用到太多。
4. 對於可能的變更是否能制定應急計劃？
基本沒有，到時候隨意抓人頂上。
5. 員工是否能夠有效地處理意料之外的工作請求？
規定所有請求都轉到 PM 那裡處理，這樣減輕了開發人員的壓力，讓 他們有大部分時間花在自己那一畝三分地上。
設計 / 實現
1. 設計工作在什麼時候，由誰來完成？是合適的時間，合適的人麼？ 有些介面的設計過早，大家為了字型的大小、按鈕的尺寸爭論，事實 上這些事情不應該由開發人員在專案早期來做。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？ 很多，大家都不知道如何解決。就看具體執行的人是如何解決的，有 的解決得好，大家並不知道出過問題；有的經常拿出來討論，大家都 知道問題在哪裡，但是沒法達成一致。
3. 團隊是否運用單元測試（Unit Test）、測試驅動的開發（TDD）、 UML 或者其他工具來幫助設計和實現？這些工具有效麼？ 運用了單元測試的員工，整體來看 Bug 不多，沒有用單元測試的員工， 後期比較忙。
TDD 要求 PM 要清楚地確定功能說明（Spec），我們目前還做不到 這一點。
一個好處是：大家都追著 PM 要 Spec，弄得 PM 的壓力很大，以前 誰都不搭理 PM 的 Spec。
4. 什麼功能產生的 Bug 最多，為什麼？ 交易功能由於牽涉的面太多，Bug 也最多。
5. 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？ 剛開始還像那麼回事，後來就變成走走形式。往往是“小飛，我要提 交程式碼了，稽核人填你的名字，怎麼樣？”其實小飛後來也沒看程式碼。
測試 / 釋出
1. 團隊有沒有測試計劃？為什麼沒有？ 我們有測試計劃，而且因為有了計劃，測試人員好像不再像無頭蒼蠅 一樣胡亂測試。
2. 有沒有做過正式的驗收測試？
有些測試人員最後不敢說驗收測試不成功，似乎是迫於某些開發人員 的“淫威”。
3. 團隊是否有測試工具來幫助測試？ 有。
4. 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看， 這些測試工作有用麼？應該有哪些改進？
TFS 還是很有用的，至於改進，有這樣一些建議：
1）輸入 Bug 還是步驟比較多，有很多需要手動重複填寫的欄位。
2）不是所有的 Bug 或 Task 都記錄在 TFS 中。
5. 在釋出的過程中發現了哪些意外問題？ 有些功能在新的機器上不能工作，因為很多設定沒有明確的定義，也 沒有記錄。軟體釋出時，這些設定沒有能正確地拷貝到釋出的機器上去。 這說明很多關於這個系統的“知識”還沒有形成文字，還是保留在某 些人的腦袋中。
6. 我們學到了什麼？如果歷史重來一遍，我們會做什麼改進？
【略】
15.3.6 維護和運營
維護和運營一個大型網站有技術含量麼？ 值得鑽研麼？ 下面是一個事例：
【出生在德國的霍爾斯對工作的質量要求極高，他發現當一個網站伺服器數量多到一定程度後，永遠有一些伺服器會處於當機狀態，雖然可以將使用者請求轉到別的伺服器上，但如果銜接得不好，使用者體驗就不好。而伺服器之間、資料中心之間的服務請求如何轉移，裡面大有學問。以前的網際網路公司不管多麼大，都沒有重視這個問題，因為工程師們覺得這不是一個技術活。霍爾斯讓他的一個學生來解決這個問題，要求做到從監控到流量的轉移完全自動化。他的那個學生開始也覺得這個工作太沒有技術含量不願意做，霍爾斯指出這不僅很有意義，而且很有研究價值，這個問題一旦解決，就說明可以用廉價、質量稍差的伺服器（比如PC）提供和那些昂貴的高穩定性的伺服器（比如IBM和太陽公司製造的大型伺服器）同樣可靠的服務。霍爾斯最終說服了他的這位學生接受這項工作，後者不負眾望解決了問題。霍爾斯和他的學生解決的這個看似細小而又沒有技術含量的問題，實際上恰恰是其他公司難以提供和Google同樣穩定的服務的原因。更重要的是，它使得Google可以使用最廉價的伺服器，運營成本就比行業的其他公司低很多。】——《浪潮之巔》