事后諸葛亮會議:做個有效的項目總結

　　設想和目標

　　我們的軟件要解決什么問題?是否定義得很清楚?是否對典型用戶和典型場景有清晰的描述?

　　我們組負責學霸的UI部分，主要是對Document和QAPair做一個Presentation，功能領域定義的很清楚，典型用戶和典型場景已經在Spec中明確說明。

　　是否有充足的時間來做計劃?

　　由于項目比較簡單，計劃時間不多，但已經足夠。

　　團隊在計劃階段是如何解決同事們對于計劃的不同意見的?

　　在PM的帶領下，大家基本沒有不同意見。

　　如果歷史重來一遍, 我們會做什么改進?

　　各個團隊各自為戰，導致UI這邊各個團隊做的功能有些重合，而且大家的數據結構有差異，給代碼整合帶來很大麻煩，同時，軟件的具體功能沒有定義清楚，比如，對于資源的定義，開始我們UI組并沒有想到還要在線展示爬來的網頁。

　　計劃

　　你原計劃的工作是否最后都做完了? 如果有沒做完的，為什么?

　　原計劃的工作都完成，沒做完的部分，就是沒有與另外兩個UI組和前端的pipeline做到完美整合。但這個主要是因為開始各個團隊沒有協調好，最后我們主動提供了數據添加的API

　　有沒有發現你做了一些事后看來沒必要或沒多大價值的事?

　　有，研究silverlight下的PDF在線閱讀方案，最后才發現有現成的flexpaper

　　是否每一項任務都有清楚定義和衡量的交付件?

　　任務在tfs寫的比較簡略，但由于比較簡單，大家都能明白。

　　是否項目的整個過程都按照計劃進行?

　　PM一直在趕進度，兩位DEV的進度有時候不盡人意

　　在計劃中有沒有留下緩沖區，緩沖區有作用么?

　　沒有

　　將來的計劃會做什么修改?(例如：緩沖區的定義，加班)

　　預留必要的緩沖時間。

　　如果歷史重來一遍, 我們會做什么改進?

　　1. 善用google英文搜索，多了解流行的開源解決方案，少看CSDN(太多不專業)，多讀Documentation

　　2. 預留必要的緩沖時間，留給后期的整合。

　　資源

　　我們有足夠的資源來完成各項任務么?

　　資源(書籍，開源解決方案，服務器，素材)非常充足

　　各項任務所需的時間和其他資源是如何估計的，精度如何?

　　各項任務估計精度不是很好，因為任務是由PM估計的，而由DEV完成，PM不知道DEV對技術的掌握程度如何，有時候估計的任務不是很精確。

　　用戶測試的時間，人力和軟件/硬件資源是否足夠?

　　我們花了兩天半的時間來做測試，相對于工程量而言，已經比較充足。

　　你有沒有感到你做的事情可以讓別人來做(更有效率)?

　　沒有。

　　如果歷史重來一遍, 我們會做什么改進?

　　1. 估計任務所用時間時，需要詢問當事DEV意見

　　2. 留給DEV學習的時間

　　變更管理

　　每個相關的員工都及時知道了變更的消息?

　　變更是由PM短信同時DEV的，DEV能夠及時了解。

　　我們采用了什么辦法決定“推遲”和“必須實現”的功能?

　　根據功能在整個項目中的重要程度，比如anti-spam，放到beta版本中了。

　　項目的出口條件(Exit Criteria – 什么叫“做好了”)有清晰的定義么?

　　所有頁面整合在一起，通過了各項測試，就“做好了”

　　對于可能的變更是否能制定應急計劃?

　　沒有。

　　員工是否能夠有效地處理意料之外的工作請求?

　　兩名DEV由于經驗不足，不能夠有效處理，但是大家在PM的帶領下出色的應對了各項突發情況。但是PM還是會在DEV比較忙的情況下獨自處理各項變化。

　　如果歷史重來一遍, 我們會做什么改進?

　　1. 善用TFS的源代碼管理，少用QQ互傳文件

　　2. 多開碰頭會，少通過短信通知

　　設計/實現

　　設計工作在什么時候，由誰來完成的?是合適的時間，合適的人么?

　　設計工作在Sprint的前三天。由經驗最豐富的PM來完成。

　　設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的?

　　PM做出頁面的草稿，交給UI的DEV具體做，PM做的模棱兩可的地方，DEV都給考慮全面了~

　　團隊是否運用單元測試(unit test)，測試驅動的開發(TDD)、UML, 或者其他工具來幫助設計和實現?這些工具有效么?

　　團隊使用了Visual Studio 2012自帶的web應用程序性能測試工具和Sikuli IDE UI自動測試工具進行測試。我們準備再beta Sprint階段使用更多的技術。

　　什么功能產生的Bug最多，為什么?

　　結果列表功能產生的Bug最多，其實也不多，只不過這個在各個頁面中反復重復，造成了“泥球”，改起來相當麻煩。。。。

　　代碼復審(Code Review)是如何進行的，是否嚴格執行了代碼規范?

　　沒有想這么多。。。

　　如果歷史重來一遍, 我們會做什么改進?

　　將UI的部分組件控件化，方便修改與維護

　　測試/發布

　　團隊是否有一個測試計劃?為什么沒有?

　　團隊有明確的測試計劃。

　　是否進行了正式的驗收測試?

　　沒有。。

　　團隊是否有測試工具來幫助測試?

　　有的，團隊使用了Visual Studio 2012自帶的web應用程序性能測試工具和Sikuli IDE UI自動測試工具進行測試。我們準備再beta Sprint階段使用更多的技術。

　　團隊是如何測量并跟蹤軟件的效能的?從軟件實際運行的結果來看，這些測試工作有用么?應該有哪些改進?

　　我們并不了解效能測試，但是會在beta中考慮，我們使用軟件進行了負載測試，找到了幾個致命的數據庫操作的bug，在前幾篇博文中我們有過總結。

　　在發布的過程中發現了哪些意外問題?

　　TA給的服務器，有各種小問題，如用戶權限不足，Sql server無權限等，這些小問題都是我們團隊第一個發現，并報告給TA的。

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