基於微信小程序的失物招領系統的Postmortem #

設想和目標##

1.我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
對於我們團隊要解決的問題和實現的功能在項目開始就很明確，在項目過程中也一直沒有改變。有清晰的典型用戶和典型場景描述。

2.是否有充足的時間來做計划?
有時間

3.團隊在計划階段是如何解決同事們對於計划的不同意見的？
因為團隊成員都是第一次上手，很多都是參照網絡上的資料，或者按照隊長的意思。

計划##

1.你原計划的工作是否最后都做完了? 如果有沒做完的，為什么?
沒做完，很重要的對接工作沒完成，遇到問題還沒解決。

2.有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
在微信小程序前端浪費了很多時間

3.是否每一項任務都有清楚定義和衡量的交付件?
沒有，我們很多任務都是靠團隊內演示驗收來交付

4.是否項目的整個過程都按照計划進行?
在對接上花了很多時間導致不能按照計划進行

5.在計划中有沒有留下緩沖區，緩沖區有作用么?
我們在Alpha沖刺最后留了一天的緩沖，但是就算有緩沖區也沒把對接解決好

6.將來的計划會做什么修改？
適當延長緩沖區和加班

資源##

1.我們有足夠的資源來完成各項任務么?
這個項目並沒有需要很多資源。

2.各項任務所需的時間和其他資源是如何估計的，精度如何?
按照以往的一些基礎編程經驗和學長的意見，精度上有一些誤差

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

4.你有沒有感到你做的事情可以讓別人來做（更有效率）?
大家都是第一次做項目，都只有一些基礎編程經驗，所以基本都差不多。剛開始分配任務也是按照個人喜好來。

變更管理

1.每個相關的員工都及時知道了變更的消息?
宿舍和實驗室都相鄰，QQ上也有及時聯系。

2.我們采用了什么辦法決定“推遲”和“必須實現”的功能?
因為對接的問題，我們不得不推遲一些功能。
3.項目的出口條件（Exit Criteria）是否得到清晰的定義?
我們在項目的過程中沒有涉及到這一塊的討論
4.對於可能的變更是否能制定應急計划?
基本沒有
5.員工是否能夠有效地處理意料之外的工作請求？
有的時候因為實驗室的需求，導致要熬夜加班，但是這樣會導致不能集中精力。

設計/實現

1.設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
設計工作在Alpha早期，有兩個小組成員共同完成，在現在看來應該是合適的。

2.設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
按照隊長的意思。

3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？
后端運用了單元測試，在現在看來比較有效。

4.什么功能產生的Bug最多，為什么？
調用數據庫的時候，對數據庫操作方法不是很理解。

5.代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
因為目前后端和前端並沒有出現問題，所以沒進行代碼復審。

測試/發布

1. 團隊是否有一個測試計划？為什么沒有？
有一點簡單的測試計划，在Alpha測試時按照計划進行測試。

2.是否進行了正式的驗收測試？
因為項目還有一部分沒實現，所以還沒進行正式的驗收。

3.團隊是否有測試工具來幫助測試？
有，使用微信小程序開發者工具

4.團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
沒有在alpha階段完成預定計划，故未進行軟件效能的跟蹤。
5.在發布的過程中發現了哪些意外問題？
tomcat第一次上手，沒有修改server.xml文件，以及微信小程序要求的https傳輸協議之前沒有做這個的經驗