Put-Me-Down項目Postmortem2

一.設想和目標
二.計劃
三.資源
四.變更管理
五.設計/實現
六.測試/發布
總結

一.設想和目標

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

我們的軟件要幫助低頭族控制使用手機時間。功能很明確，對典型用戶和典型場景有清晰的描述，在需求規格說明書中。

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

有，但是因為對開發不熟悉，計劃是一步一步摸索出來的。

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

成員脾氣好，商討接納合理的意見。

有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?

首先應明確整個開發過程大體要做哪些事，將較大的模塊落實到個人負責，如文檔由某成員專門負責。

二.計劃

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

沒有，大部分做完了，我們原本想將數據備份到數據庫，后來因為申請的原因、我們的APP在Alpha階段實現功能可以不需要服務器、安卓方面功能較多、服務器方面不熟悉，所以程序重心放在安卓；

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

基本沒有。美工有時候越用心會適得其反，走到極端。

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

沒有每項，代碼提交是明顯的可衡量交付件。但是成員在學習過程中沒有設定交付件，導致學習效率不高。

4. 是否項目的整個過程都按照計劃進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?

沒有完全按原計劃，計劃在整個過程中有變動，項目有計劃地進行。初始計劃我們是想將程序方面分為安卓和后臺，主要是程序方面的工作。我們對項目的認識是模糊的。經過alpha階段前2天的摸索，基本上知道整個完成這個APP要做什么。將程序重心放在安卓；后來意識到界面的重要，以及原本負責服務器后臺的人員會PS，所以我們在界面設計方面加入了自己制作的符合我們APP主題的圖標；
博客的內容有助于每個成員把握自己的時間，清楚整個項目，把握到整個項目的過程，以及記錄每個人在這一階段的成長（困難、總結），所以博客內容的收集、整理是很重要，我們有2個人可以負責文檔。一開始對博客的內容提綱不清楚，摸清提綱后一個人負責就可以了，另一個人可以負責其他事務。

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

有考慮到緩沖區，緩沖區有作用，可以應付緊急情況，如bug修復。

6. 將來的計劃會做什么修改？

會留出更多緩沖區，不將時間按事務排滿。

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

應該明確整個項目的事務，清楚定義每個任務，包括學習任務，設定衡量的交付件，提高學習效率。寫出代碼框架，大家坐在一起打代碼。

三.資源

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

有資源，但沒有足夠的資源，我們最好的資源是有一位開發安卓經驗的組長，他寫了整個代碼的結構；擁有PS技能的人員；文檔編寫人員；缺少的資源是測試經驗、界面設計知識；但我們有學習資源，卻沒有安排好學習任務以及學習衡量交付件。

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

我們將任務切分，基本是一天完成幾個任務，沒有具體到小時，精度不高。

3. 測試的時間，人力和軟件/硬件資源是否足夠? 對于那些不需要編程的資源 (美工設計/文案)是否低估難度?

測試是薄弱的一塊，我們是手動測試，用例測試，測試方面花的時間少。對于美工設計和文案我們有重視，也認識到美工是一大重點以及弱項。

4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?

有，我們有2個人可以寫文檔，后來讓一個人做，另一個人做其他事，充分利用人力，提高效率。

有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?

我們會多面對面交流，坐在一起學習，制定學習驗收計劃，提高效率。

四.變更管理

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

知道，通過博客的任務安排知道。

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

主體功能實現，如將服務器推遲到下個版本，計時以及記錄、結束時強制手動停止必須實現。

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

有，組長很注重細節，結合用戶場景來考量項目是否做好了。

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

項目變更可能性小，沒有考慮到變更，如果有變更都是積極地想辦法解決。

5. 成員是否能夠有效地處理意料之外的任務請求？

能。有時候臨時出現新的事物，如界面整合需要修改，大家都積極配合。

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

原本對項目的認識不夠，所以出現了變更。組長都是根據每個人意愿讓大家自主選擇，大家不知道自己想做什么，具體角色是做什么，如果重來一次讓組長明確每個角色要做什么，再結合成員志愿及組長考量，將角色及責任落實到個人。

五.設計/實現

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

項目的整體結構則由李坤隆先僧完成，李先僧之前有參與過開發，相比其他成員更熟悉開發的套路，所以由他來完成項目的架構是合適的。

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

因為其他小組成員剛開始學習開發，不懂套路，所以代碼結構的設計是由李先僧一人完成的。小組項目最終采用mvp模式，根據李先僧的描述，這也是他第一次使用這個模式，對這個模式并不熟悉，和其他成員一樣也是摸著石頭過河。一開始對代碼的分包是像傳統的‘activities’，‘adapter’這樣根據每個文件的所屬類別分包，還是像google官方的mvp例子那樣根據模塊分包猶豫不決。最終看了一篇博文按照應用功能來封裝，而非所屬類別決定按模塊分包。（只是把文件按模塊分了下包，實際分工的時候是按m-v-p來分的，并不是某個人把某個功能模塊的mvp三層全包了。mvp三層間依賴于接口而非具體的實現類，只要接口在一開始的時候商定好，三個層之間完全可以異步并行開發，不是很懂棟哥評測那天說的“偽按層分工”是什么意思）

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