现代软件工程讲义 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. 團隊是如何測量并跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？ 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, 有時候還請團隊外的顧問人員來主持, 以保證質量。
?
總結
以上是生活随笔為你收集整理的现代软件工程讲义 11 项目管理 - 事后诸葛亮会议的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： sqlserver sa
- 下一篇： 文件夹和文件的名称变成蓝色