<<易貨>>項目Postmortem結果

設想和目标

1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
              

一開始想做的事情還是太多，沒有形成整個app的核心功能，浪費了很多時間。

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

有時間，但是大部分人并不知道如何利用這一段時間來做計劃。

3. 團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？

不同的意見一般是少數服從多數。

計劃

1. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
              

很多事情都沒做完，大家認為最後沒做完的事情，都是可有可無的，當然項目前期也有時間浪費的現象。

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

基本上沒有吧。

3. 是否每一項任務都有清楚定義和衡量的傳遞件?

分工類别很大，基本上算是清楚定義。

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

計劃與現實差距還是比較大。

資源

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

很多情況下，花了不少時間來查閱資料，參考代碼。

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

開始精度很粗略，後來随着項目任務的加重，大家隻顧得上幹活，沒時間考慮精度問題。

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

暫時沒有使用者測試，我們隻是開發人員測試。

變更管理

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

大家都知道了自己需要知道的消息。

2. 我們采用了什麼辦法決定“推遲”和“必須實作”的功能?

小組成員讨論。

3. 項目的出口條件（Exit Criteria）是否得到清晰的定義?

大家都不太懂“出口條件”是什麼，經過這一個項目之後，稍稍清楚了一些。但是說實在的，在這個項目裡面我們沒有用到太多。

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

基本沒有，到時候随意抓人頂上。

設計/實作

1. 設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
              

有些界面的設計過早，後來又根據整體UI從新設計。一般是PM設計。

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

很多，大家都不知道如何解決。就看具體執行的人是如何解決的，開發人員會在相對容易的代碼基礎上設計出盡可能接近設計。

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？

運用了單元測試的員工，整體來看Bug不多，沒有用單元測試的員工，後期比較忙。

4. 什麼功能産生的Bug最多，為什麼？

好友交流界面問題比較多，可能是因為伺服器和用戶端互動比較頻繁。

5. 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

剛開始還像那麼回事，後來就變成走走形式。

測試/釋出

1. 團隊是否有一個測試計劃？為什麼沒有？
              

我們一般是寫一個功能測試一個功能。

2. 是否進行了正式的驗收測試？

基本上沒有吧，大家都試用，沒問題就差不多了。

3. 團隊是否有測試工具來幫助測試？

沒有！

此外，還需要回答下面兩個問題：

1. 對比靈活的原則，你覺得你們小組做得最好的是什麼？

   開發人員同時同地開發，及時發現處理問題。

2. 什麼是在下個階段 M2 要改進的地方？越具體越好。

   下拉重新整理；聊天功能完善；交易系統完善；使用者推廣跟進。。。