此作業要求參見：https://edu.cnblogs.com/campus/nenu/2018fall/homework/2449

組名：可以低頭，但沒必要

組長：付佳

組員：張俊餘  李文濤  孫賽佳  田良  於洋  劉欣  段曉睿

可以低頭，但沒必要小組“取件幫”專案Postmortem結果

整理：張俊餘

設想和目標

1.在Beta階段的軟體質量提高了嗎？是在哪裡體現出來的？

答：取件幫在beta階段的質量取得了顯著的提高，具體表現在以下幾個方面：（1）軟體在原有的基礎上在釋出快遞資訊模組上完善了功能，具體表現在對輸入是否為空進行判斷，若關鍵資訊填寫為空，則會提示重新輸入完整資訊；（2）在“幫取”按鈕上做了優化，具體表現在如果幫取自己的快遞則會顯示“不能幫取自己的快遞”提示並拒絕幫取請求，幫取別人快遞的時候彈出提示，讓幫取者再次確認資訊後方可幫取，增加了安全性；（3）加入了個人中心功能，個人中心裡可以看到幫取或者釋出的快遞資訊，可以提交使用者使用反饋，檢視關於我們資訊；

2.在Beta階段軟體工程的質量提高了嗎？具體表現在那些方面？

答：Beta階段軟體工程的質量也得到了提高。主要表現在一下幾個方面：（1）提交程式碼時commit資訊規範化，要求使用標準英文，詞義和語法讓人能正常閱讀；（2）程式碼編寫更加規範，根據制定的程式碼規範嚴格遵守；

3.使用者量、使用者對重要功能的接受程度和我們事先的設想一致嗎？我們離目標更近了嗎？有什麼經驗教訓？如果歷史重來一遍，我們會做什麼改進？

答：本專案Beta階段共有15名使用者，和預想一致。使用者在使用小程式的時候開始關注頁面設計和頁面展示效果是我們之前沒想到的；

我們離目標確實更近了，專案完成度已達90%，只剩收貨地址管理這一項功能待開發；

經驗教訓是團隊開發的時候版本控制一定要做的細緻，提交記錄和提交資訊一定要完整，否則在迴歸測試上會出現不協調的問題；

如果重來一遍，我們依舊會選擇做微信小程式。但是會減少原型設計的時間，本次開發原型共設計兩次，墨刀和PS頁面各一次，浪費了很多時間，耽誤了後續學習小程式開發的時間。原因在於第一次設計的原型頁面不美觀，遭到了組員的反對，經驗是分工要合理，原型設計分配給更加熟悉設計的人員。

計劃

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

答：原計劃的工作全部完成，專案整體完成度已達90%，並且使用者有比預期增速更快的趨勢；

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

答：沒有，所有的事情在後續工作中經過檢驗都是值得的。

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

答：是。教師規定的任務顆粒度，我們組在leangoo看板上具體制定了各項任務的負責人、截止時間、任務描述。此外組長會對每一個有不一意見的任務進行解釋，因此每一項任務都有清楚定義和衡量的交付件。

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

答：基本上。因為小組每天都會召開立會總結昨日工作，如果該項工作完成會繼續制訂今日計劃；如果未完成，小組成員集體討論未完成原因，確認是否該項任務有一定難度，會重新制訂執行計劃和執行方式。故，該專案在Beta階段大方向始終按照計劃執行。

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

答：一般會設定緩衝區。例如一般會給任務設定一個較早的deadline，以方便組長檢查修改。緩衝區為整個專案的按計劃完成增加了保障。

6.將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）

答：每個階段初始分析任務、安排任務比較瑣碎，需要組長更加了解本組人員；功能測試時間要安排的長一點；單元測試要更加全面；迴歸測試要更加細緻；

7.我們學到了什麼？如果歷史重來一遍，我們會做什麼改進？

答：學會了按照顆粒度分析任務，劃分任務。如果重來一遍，應該將任務劃分的更加細緻。

資源

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

答：多數情況下是有的。騰訊提供開發教程，版本控制參考廖雪峰部落格，資料庫使用知曉雲。最大的資源限制是時間，由於不熟悉小程式開發，因此有時候開發時間不夠。

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

答：大部分任務截止時間是組長根據之前開發經驗制訂。例如一個靜態頁面的時間，一個查詢功能的時間，多數情況下按照功能來制訂。其他資源只是比較粗糙的制定一個deadline，具體看執行人自由發揮，沒有考慮精度問題。

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

答：不富裕但足夠。

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

答：沒有。我們組成員之間隨著不斷地熟悉在制訂任務分配時有非常細緻的分工，完全依據個人精力和能力來分配任務。

5.有什麼經驗教訓？如果歷史重來一遍，我們會做什麼改進？

答：經驗是在充分了解現階段任務的基礎上基於對本組成員的瞭解分配任務，這一點我們做的越來越好。教訓是任務分配要儘早，給開發留出比較充足的時間。如果重來一遍，我們會在Beta階段開始的前半天就制定出任務分配。

變更管理

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

答：是的。每次立會的時候每個人都會彙報一下自己的進度。每位同學在checkin之後會在微信群裡通知大家。

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

答：根據需求分析時制訂的要求，核心功能（幫取與釋出資訊）必須實現。具體到問題細節，實現方法A較為困難則尋找實現方法B，若均困難且距離deadline有一定時間則務必實現，不可推遲。否則推遲。比如資料庫存快遞狀態不可以存文字必須存狀態程式碼，原則是必須的，實現方法不限。

3.專案的出口條件（ExitCriteria）有清晰的定義嗎?

答：出口條件理解為“做好了”，能實現核心功能，且實現核心功能的方法符合邏輯，使用者體驗較好。

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

答：能。按照緊急程度有不用應對措施比如立會討論，微信群討論，電話聯絡等。

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

答：是的。大家相處的很融洽，一般額外工作也只會分配給當前有能力有時間的人來完成，所以都會欣然接受。

6.我們學到了什麼？如果歷史重來一遍，我們會做什麼改進？

答：學會了精益求精和與人溝通。在實現的基礎上反覆修改是為了精益求精，修改之後及時告知夥伴以便對方及時更新程式碼，也是對專案的一種負責。如果重來一遍，我們還會按照現在的形式進行，改進應該會是在checkin時對操作描述的更加清晰。

設計/實現

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

答：本專案先由程式碼組前端成員設計出簡單的頁面，然後進行功能實現。功能實現後前端成員再進行檢查與美化完成詳細UI。是合適的時間，合適的人選。

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

答：有，但不多。功能性和美觀性抉擇時，選擇功能性。功能實現後再根據時間和能力進行美觀性的改進。

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

答：沒有運用單元測試（unit test），測試驅動的開發（TDD）、UML工具。運用了 leangoo看板、燃盡圖、todolist、版本控制來幫助設計和實現。測試時選擇開發IDE預覽和手機端測試，感覺都挺有效的。

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

答：個人中心按鈕出現不相容的情況，在某些手機上出現了序列等現象；

5.程式碼複審（CodeReview）是如何進行的，是否嚴格執行了程式碼規範？

答：專案開始大家按照口頭約定的程式碼規範進行執行，後來程式越來越複雜就開始按照自己的程式設計風格寫程式碼了。至於程式碼複審，由於開發迭代週期短，所以並沒有進行。

6.我們學到了什麼？如果歷史重來一遍，我們會做什麼改進？

答：我們學會了團隊開發時的版本控制。如果重來一遍，我們將會制訂書面版的程式碼規範並嚴格執行，且每次更新程式碼都要檢查衝突並解決。

測試/釋出

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

答：有測試計劃，但是測試周期制訂的比較短，而且大家已經過於熟悉本專案了所以反饋不多。

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

答：沒有。時間比較緊張因此未進行。

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

答：沒有。

4.團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？

答：在手機端可以進行效能測試。從實際看這些測試有用，方便後續的debug和測試。目前對效能測試不多，改進是後續將加大對效能測試分析的力度。

5.在釋出的過程中發現了哪些意外問題？

答：釋出的時候因為小程式稽核需要一定的時間，所以只能對使用者進行單獨的授權才可以使用，但是現在經過前期鋪墊之後稽核速度有一定加快。不過還是應該在稽核這一部分留取更多的時間從而方便接入新使用者；

6.我們學到了什麼？如果歷史重來一遍，我們會做什麼改進？

答：經驗是要有一個詳細的測試計劃，此次開發測試周期短，最後導致幾個遺留問題解決時間較長。如果重來一次，我們會制訂一個比較好的測試計劃，進行單元測試、功能測試、效能分析等。