項目完成了，如何做項目的總結會議？(2)

　　小芳：最后要交一個什么樣的文件呢?是不是所有問題的列表就可以了?
　　阿超：列出問題，只是一個部分，重要的是讓所有人了解問題的存在之后，開始討論解決方案，要提出一個解決問題的草案。
　　原來準備開一個小時的會議進行了兩個多小時才結束，食品和酒水的消耗也比原計劃多了兩倍，有人被抬出了河曲大酒店。
　　小芳最后把大家的意見和建議整理之后，發給了全體成員。

移山公司Stone項目Postmortem結果 整理：小芳 設想和目標 我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？ 想做的事情還是太多，導致很長時間不能集中精力。 是否有充足的時間來做計劃? 有時間，但是大部分人并不知道如何利用這一段時間來做計劃。 團隊在計劃階段是如何解決同事們對于計劃的不同意見的？  主要通過喝酒聊天解決，另外阿超有某種“光環”，大家對他有些崇拜，這樣他說的話別人都比較容易接受，不同的意見也沒有特別強烈。     計劃 你原計劃的工作是否最后都做完了? 如果有沒做完的，為什么? 很多事情都沒做完，大家認為最后沒做完的事情，都是可有可無的。 有沒有發現你做了一些事后看來沒必要或沒多大價值的事? 很多，但是大家認為與其不斷地爭論某些事情有沒有必要，不如做了再說。 是否每一項任務都有清楚定義和衡量的交付件? 大部分都沒有，因為我們大家都不知道做到多少才叫“好”。有些情況下，大家對細節過早地進行討論，花了很多時間。不如等到后來再討論。 是否項目的整個過程都按照計劃進行? 基本上，因為阿超的“光環”，大家大部分情況下都聽他的。 在計劃中有沒有留下緩沖區，緩沖區有作用么? 有緩沖區，原來認為沒有必要，后來發現還是有用的。主要是各人進度不一，有些模塊不斷地有一些小問題，花了很長時間才能做好。 將來的計劃會做什么修改？（例如：緩沖區的定義，加班） 應該明確緩沖區的長度。   資源 我們有足夠的資源來完成各項任務么? 很多情況下，花了不少時間來設置機器，以及設置用來測試的數據。 各項任務所需的時間和其他資源是如何估計的，精度如何? 開始精度很粗略，后來隨著項目任務的加重，大家只顧得上干活，沒時間考慮精度問題。 用戶測試的時間，人力和軟件/硬件資源是否足夠? 你有沒有感到你做的事情可以讓別人來做（更有效率）? 比如網頁的CSS設計，最好由美工設計來做，開發人員最后做實現即可。我們要有專職的設計，不要臨時拉人來幫忙。因為臨時幫忙的設計師對整個項目了解不多，事后也找不到他。   變更管理 每個相關的員工都及時知道了變更的消息? 由于大家都坐得比較近，小道消息傳播得比較快。 我們采用了什么辦法決定“推遲”和“必須實現”的功能? 用了“銀彈”，除了導致一場短時間的斗毆之外，還可以。銀彈的目的就是一種威懾。 項目的出口條件（Exit Criteria）是否得到清晰的定義? 大家都不太懂“出口條件”是什么，經過這一個項目之后，稍稍清楚了一些。但是說實在的，在這個項目里面我們沒有用到太多。 對于可能的變更是否能制定應急計劃? 基本沒有，到時候隨意抓人頂上。 員工是否能夠有效地處理意料之外的工作請求？ 規定所有請求都轉到PM那里處理，這樣減輕了開發人員的壓力，讓他們有大部分時間花在自己那一畝三分地上。   設計/實現 設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？ 有些界面的設計過早，大家為了字體的大小，按鈕的尺寸爭論，事實上這些事情不應該由開發人員在項目早期來做。 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？ 很多，大家都不知道如何解決。就看具體執行的人是如何解決的，有的解決得好，大家并不知道出過問題；有的經常拿出來討論，大家都知道問題在哪里，但是沒法達到一致。 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？ 運用了單元測試的員工，整體來看Bug不多，沒有用單元測試的員工，后期比較忙。 TDD 要求PM要清楚地確定功能說明（spec），我們目前還做不到這一點。 一個好處是：大家都追著PM 要spec，弄得PM的壓力很大，以前誰都不搭理PM的spec。 什么功能產生的Bug最多，為什么？ 交易功能由于牽涉的面太多，Bug也最多。 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？ 剛開始還像那么回事，后來就變成走走形式。往往是“小飛，我要check-in 了，reviewer 填你的名字，怎么樣？”其實小飛后來也沒看代碼。   測試/發布 團隊是否有一個測試計劃？為什么沒有？ 我們有測試計劃，而且因為有了計劃，測試人員好像不再像無頭蒼蠅胡亂測試 是否進行了正式的驗收測試？ 有些測試人員最后不敢說驗收測試不成功，似乎是迫于某些開發人員的淫威。 團隊是否有測試工具來幫助測試？ 有。 團隊是如何測量并跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？ TFS 還是很有用的，至于改進，有這樣一些建議： （a）輸入Bug 還是步驟比較多，很多需要手動重復填寫的字段。 （b）不是所有的Bug 或 task 都記錄在TFS中。 在發布的過程中發現了哪些意外問題？ 有些功能在新的機器上不能工作，因為很多設置沒有明確的定義，也沒有記錄。在發布的時候，這些設置沒有能正確地拷貝到發布的機器上去。說明很多關于這個系統的“知識”還沒有形成文字，還是保留在某些人的腦袋中

原文轉自：http://www.kjueaiud.com