項目完成了,如何做項目的總結會議?

發表于:2012-12-05來源:博客園作者:SoftwareTeacher點擊數: 標簽:項目總結
項目完成了,如何做項目的總結會議?一個里程碑結束了, 下面怎么辦? 團隊有什么經驗教訓? 產品怎么才能做得更好? 我們常說 “軟件的生命周期”- 這個軟件開發的周期結束了, 生命也結束了
  一個里程碑結束了, 下面怎么辦? 團隊有什么經驗教訓? 產品怎么才能做得更好? 我們常說 “軟件的生命周期”- 這個軟件開發的周期結束了, 生命也結束了。 我們能不能像醫學的尸體解剖一樣, 把這個軟件開發的流程解剖一下? 解剖的過程可以叫: Postmortem, Retrospective, Review, 事后諸葛亮會議, 等等... 大多數學校里的軟件工程項目結束后大家一哄而散, 一些諾言像 "我一定會補上文檔的", “我們還會繼續開發的”... 成了撤退時的疑兵之計, 等煙塵散去, 同學們早跑沒影了。
  (下面的人物來自 移山之道)
  產品發布了,大家松了一口氣。阿超建議大家開一個總結會議,就是事后諸葛亮會議。會議請公司的秘書小芳主持并作記錄。為了讓大家能暢所欲言,阿超和大牛沒有參加會議。為了活躍氣氛,小芳還買了零食、飲料、河曲啤酒等。
  阿超給小芳一個討論的模板,同時也囑咐小芳不一定要拘泥于模板,要見機行事,根據會議的進展靈活地變動計劃。要牢記會議的核心問題是“如果你可以重新來過,什么方面可以做得更好?" 另外, 在問 “為什么” 的時候, 要多問幾次, 層層推進, 找到問題的根源。
  例如: 軟件發布后用戶報告了一個大問題。 ”為什么?"
  因為程序沒有考慮某種邊界條件. "為什么在測試階段沒有測試出來?"
  因為這個代碼是測試的最后階段才加進去的。 “為什么不通知PM/Test?”
  因為dev 認為沒有問題的, 很簡單的修改。 "為什么不通知別人?"
  因為dev 認為那些都是軟件工程無聊的規定... dev 是大牛人, 不必遵守的。
  問到這個層次,就把問題根源暴露出來了。
現代軟件工程 項目Postmortem 模板
鄒欣
現代軟件工程 課件
2011
 
設想和目標
1. 我們的軟件要解決什么問題?是否定義得很清楚?是否對典型用戶和典型場景有清晰的描述?
2. 是否有充足的時間來做計劃?
3. 團隊在計劃階段是如何解決同事們對于計劃的不同意見的?
如果歷史重來一遍, 我們會做什么改進?
 
計劃
1. 你原計劃的工作是否最后都做完了? 如果有沒做完的,為什么?
2. 有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
3. 是否每一項任務都有清楚定義和衡量的交付件?
4. 是否項目的整個過程都按照計劃進行?
5. 在計劃中有沒有留下緩沖區,緩沖區有作用么?
6. 將來的計劃會做什么修改?(例如:緩沖區的定義,加班)
如果歷史重來一遍, 我們會做什么改進?
 
資源
1. 我們有足夠的資源來完成各項任務么?
2. 各項任務所需的時間和其他資源是如何估計的,精度如何?
3. 用戶測試的時間,人力和軟件/硬件資源是否足夠?
4. 你有沒有感到你做的事情可以讓別人來做(更有效率)?
 
如果歷史重來一遍, 我們會做什么改進?
 
變更管理
1. 每個相關的員工都及時知道了變更的消息?
2. 我們采用了什么辦法決定“推遲”和“必須實現”的功能?
3. 項目的出口條件(Exit Criteria – 什么叫“做好了”)有清晰的定義么?
4. 對于可能的變更是否能制定應急計劃?
5. 員工是否能夠有效地處理意料之外的工作請求?
 
如果歷史重來一遍, 我們會做什么改進?
 
設計/實現
1. 設計工作在什么時候,由誰來完成的?是合適的時間,合適的人么?
 
2. 設計工作有沒有碰到模棱兩可的情況,團隊是如何解決的?
3. 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其他工具來幫助設計和實現?這些工具有效么?
4. 什么功能產生的Bug最多,為什么?
5. 代碼復審(Code Review)是如何進行的,是否嚴格執行了代碼規范?
 
如果歷史重來一遍, 我們會做什么改進?
 
測試/發布
1. 團隊是否有一個測試計劃?為什么沒有?
2. 是否進行了正式的驗收測試?
3. 團隊是否有測試工具來幫助測試?
4. 團隊是如何測量并跟蹤軟件的效能的?從軟件實際運行的結果來看,這些測試工作有用么?應該有哪些改進?
5. 在發布的過程中發現了哪些意外問題?
如果歷史重來一遍, 我們會做什么改進?
 
  怎么開好一個 Postmortem 會議:
  保持會議輕松愉快的氛圍, 可以考慮換一個開會的環境, 有飲料, 零食, 音樂的幫助更好
  當 [大官] 的最好不要出現, 讓大家暢所欲言。 (即使出現, 也要夾著尾巴, 不要為自己以前的行為辯護, 作好聽眾)
  堅持對事不對人的原創, 強調 - 如果再有一次機會, 會如何改進? 而不是挖歷史舊帳.
  照顧到模板提及的各個領域, 可以深入團隊最感興趣的部分。
  讓所有人都有充分發言的機會。
  有人記錄發言要點, 最后列出所有改進意見
  最后大家可以投票, 如果我只有三票, 投給哪些改進意見
  大官們保證要采取行動, 執行票數最高的一些改進意見。

原文轉自:http://www.anti-gravitydesign.com

国产97人人超碰caoprom_尤物国产在线一区手机播放_精品国产一区二区三_色天使久久综合给合久久97