現代軟件工程講義 11 項目管理 - 事后諸葛亮會議
一個里程碑結束了, 下面怎么辦? 團隊有什么經驗教訓? 產品怎么才能做得更好? 我們常說 “軟件的生命周期”- 這個軟件開發的周期結束了, 生命也結束了。 我們能不能像醫學的尸體解剖一樣, 把這個軟件開發的流程解剖一下? 解剖的過程可以叫: Postmortem, Retrospective, Review, 事后諸葛亮會議， 等等... 大多數學校里的軟件工程項目結束后大家一哄而散, 一些諾言像 "我一定會補上文檔的"， “我們還會繼續開發的”... 成了撤退時的疑兵之計, 等煙塵散去, 同學們早跑沒影了。
（下面的人物來自 構建之法）
產品發布了，大家松了一口氣。阿超建議大家開一個總結會議，就是事后諸葛亮會議。會議請公司的秘書小芳主持并作記錄。為了讓大家能暢所欲言，阿超和大牛沒有參加會議。為了活躍氣氛，小芳還買了零食、飲料、河曲啤酒等。
阿超給小芳一個討論的模板，同時也囑咐小芳不一定要拘泥于模板，要見機行事，根據會議的進展靈活地變動計劃。要牢記會議的核心問題是“如果你可以重新來過，什么方面可以做得更好？" 另外, 在問 “為什么” 的時候, 要多問幾次, 層層推進, 找到問題的根源。
例如: 軟件發布后用戶報告了一個大問題。 ”為什么?"
因為程序沒有考慮某種邊界條件. "為什么在測試階段沒有測試出來?"
因為這個代碼是測試的最后階段才加進去的。 “為什么不通知PM/Test?”
因為dev 認為沒有問題的, 很簡單的修改。 "為什么不通知別人?"
因為dev 認為那些都是軟件工程無聊的規定... dev 是大牛人, 不必遵守的。 “為什么？！”
軟件工程課的目的，主要是讓大家通過做項目，學到軟件工程的知識，而不是低水平重復， 有些團隊在 alpha 階段用比較低水平的方法做了幾個功能， beta 階段還是用比較低水平的辦法，又做幾個功能， 感覺這些同學失去了學習的機會。 寧可少做一些功能， 也要把 單元測試，架構，代碼規范，等提高。 我們說
軟件 = 程序+ 軟件工程
軟件的質量 = 程序的質量 + 軟件工程的質量
我們可以問自己，在beta 階段， 程序的質量提高了么？ 軟件工程的質量提高了么？ 在哪里體現出來了？具體有什么改進？
問到這個層次，就把問題根源暴露出來了。
|
現代軟件工程 項目Postmortem 模板
設想和目標 1. 我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？ 2. 我們達到目標了么（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了么？ 原計劃達到的用戶數量達到了么?) 3. 和上一個階段相比，團隊軟件工程的質量提高了么？ 在什么地方有提高，具體提高了多少，如何衡量的？ 4. 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?
有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
計劃 1. 是否有充足的時間來做計劃? 2. 團隊在計劃階段是如何解決同事們對于計劃的不同意見的？ 3. 你原計劃的工作是否最后都做完了? 如果有沒做完的，為什么? 4. 有沒有發現你做了一些事后看來沒必要或沒多大價值的事? 5. 是否每一項任務都有清楚定義和衡量的交付件? 6. 是否項目的整個過程都按照計劃進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到? 7. 在計劃中有沒有留下緩沖區，緩沖區有作用么? 8. 將來的計劃會做什么修改？（例如：緩沖區的定義，加班）
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
資源 1. 我們有足夠的資源來完成各項任務么? 2. 各項任務所需的時間和其他資源是如何估計的，精度如何? 3. 測試的時間，人力和軟件/硬件資源是否足夠? 對于那些不需要編程的資源 (美工設計/文案)是否低估難度? 4. 你有沒有感到你做的事情可以讓別人來做（更有效率）? 有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
變更管理 1. 每個相關的員工都及時知道了變更的消息? 2. 我們采用了什么辦法決定“推遲”和“必須實現”的功能? 3. 項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么? 4. 對于可能的變更是否能制定應急計劃? 5. 員工是否能夠有效地處理意料之外的工作請求？
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
設計/實現 1. 設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？ 2. 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？ 3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？ 比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？ 4. 什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況? 5. 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
測試/發布 1. 團隊是否有一個測試計劃？為什么沒有？ 2. 是否進行了正式的驗收測試？ 3. 團隊是否有測試工具來幫助測試？ 很多團隊用大量低效率的手動測試，請提出改進計劃：至少一個方面的測試要用自動化的測試工具，自動化的測試結果報告，比較測試結果的差異，等等。 4. 團隊是如何測量并跟蹤軟件的效能（Performance）的？壓力測試（Stress Test）呢？ 從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？ 5. 在發布的過程中發現了哪些意外問題？
我們學到了什么? 如果重來一遍, 我們會做什么改進?
團隊的角色，管理，合作 1. 團隊的每個角色是如何確定的，是不是人盡其才？ 2. 團隊成員之間有互相幫助么？ 3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？ 每個成員明確公開地表示對成員幫助的感謝 （并且寫在各自的博客里）： 我感謝 _______<姓名>______對我的幫助， 因為某個具體的事情: _____________________。
總結: 你覺得團隊目前的狀態屬于 CMM/CMMI 中的哪個檔次? 對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。 正如我們前面提到的， 軟件的質量 = 程序的質量 + 軟件工程的質量，那團隊在下一階段應該如何提高軟件工程的質量呢？ 1. 代碼管理的質量具體應該如何提高？ 代碼復審和代碼規范的質量應該如何提高？ 2. 整個程序的架構如何具體提高？ 如何通過重構等方法提高質量，如何衡量質量的提高？ 3. 其它軟件工具的應用，應該如何提高？ 4. 項目管理有哪些具體的提高？ 5. 項目跟蹤用戶數據方面，計劃要提高什么地方？例如你們是如何知道每日/周活躍用戶等數據的？ 6. 項目文檔的質量如何提高？ 7. 對于人的領導和管理， 有什么具體可以改進的地方？ 請看《構建之法》關于PM、績效考核的章節， 或者 《人件》等參考書 8. 對于軟件工程的理論，規律有什么心得體會或不同意見？ 請看閱讀作業。 (這個作業的期中閱讀)
發布博客時，要附上全組討論的照片。
|
怎么開好一個 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）是如何進行的，是否嚴格執行了代碼規范？ 剛開始還像那么回事，后來就變成走走形式。往往是“小飛，我要check-in 了，reviewer 填你的名字，怎么樣？”其實小飛后來也沒看代碼。
測試/發布 1. 團隊是否有一個測試計劃？為什么沒有？ 我們有測試計劃，而且因為有了計劃，測試人員好像不再像無頭蒼蠅胡亂測試 2. 是否進行了正式的驗收測試？ 有些測試人員最后不敢說驗收測試不成功，似乎是迫于某些開發人員的淫威。 3. 團隊是否有測試工具來幫助測試？ 有。 4. 團隊是如何測量并跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？ TFS 還是很有用的，至于改進，有這樣一些建議： （a）輸入Bug 還是步驟比較多，很多需要手動重復填寫的字段。 （b）不是所有的Bug 或 task 都記錄在TFS中。 5. 在發布的過程中發現了哪些意外問題？ 有些功能在新的機器上不能工作，因為很多設置沒有明確的定義，也沒有記錄。在發布的時候，這些設置沒有能正確地拷貝到發布的機器上去。說明很多關于這個系統的“知識”還沒有形成文字，還是保留在某些人的腦袋中。 |
微軟公司的每個項目結束后, 都要做 Postmortem, 有時候還請團隊外的顧問人員來主持, 以保證質量。
浙公網安備 33010602011771號