此作業要求：[https://edu.cnblogs.com/campus/nenu/2018fall/homework/2324]

組名：拉格朗日2018

組長：王一可

組員：王碩，趙佳璐，範靖旋，祁玉，範洪達，徐常實，張帥

拉格朗日2018“飛詞”遊戲專案

Postmortem結果

設想和目標

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

答：“飛詞”遊戲主要是為了改變包括小學、中學、大學的學生們枯燥乏味的背單詞模式，旨在通過learning by playing的理念提高學生們的學習興趣。

　　我們軟體的主要功能是通過玩飛機大戰的方式幫助廣大同學快速記憶單詞。

　　張三是一位正在準備英語4級的東北師範大學的大一學生。張三在考前容易出現焦慮、煩躁、自信心不足等悲觀情緒，在這種狀態下，他無法心平氣和的準備即將到來的英語4級考試。而我們的“飛詞”小遊戲恰恰能彌補張三同學在這期間出現的種種負面情緒，並能幫助他有效的記憶英語4級的單詞。

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

答：我們有充足的時間做計劃。我們花費了大量時間設想和決定在哪一個時間段該完成專案的哪些具體部分。比如：一週內完成遊戲中帶有字母的敵機隨機出現。

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

答：對於計劃的不同意見，我們基本通過在立會上和微信討論組裡討論並解決問題。當組員提出計劃的不同意見時，我們會討論並共同思考如何解決提出的問題。多數情況下，我們都能找到解決問題的辦法。

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

答：我們專案的計劃使用者量在10個左右，而且實際上我們的使用者量也達到了目標。我們預想的使用者應該是玩過飛機大戰或者類似的遊戲的，而事實並非如此，又由於我們在飛機大戰的基礎上添加了記憶單詞的功能，有很多使用者一開始並不知道如何進行操作，這些是我們沒想到的。

　　雖然如此，但是我們實現了最初對該專案的基本需求。因此，我們確實離目標更進一步了。

　　提出需求時不要一味的追求想象中的美好功能而不顧我們是否有做過此類專案的經驗，在這一次經歷中，我們發現預想的容易實現的功能需要大費周章才能在計劃的時間內勉強實現。

　　如果歷史重來一遍，我們可能會綜合理想的需求和實際的專案經驗，讓需求變得更切合實際。

計劃

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

答：是的。我們每一項任務都會在leangoo看板上進行明確的劃分，劃分包括時間、人物。

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

 答：整個工程是按照計劃進行的。這主要歸功於團隊裡每個人都樂於溝通，加強了團隊內部的合作。

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

 答：我們在計劃中沒有設定緩衝區。

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

 答：我們打算繼續保持現在的團隊風氣，互相督促。

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

 答：我們學會了按照各自的分工完成任務。如果重來一遍，我們會更加重視團隊合作。

資源

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

答：資源是足夠的。有很多問題可以通過上網百度解決。

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

答：對於之前有過經驗的任務，我們是通過經驗估計任務所需的時間。沒有經驗的任務，我們盡最大可能為該任務分配足夠多的時間。暫時沒考慮時間精度。

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

答：勉強足夠。

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

答：有的時候會因為任務完成的時間問題使計劃延後。如果重來一遍，我們會將時間精度考慮在內。

變更管理

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

答：是的。我們在微信討論組和每日立會上都會及時釋出和彙報每個人的任務程序。

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

答：我們在開會前列舉出所有可能實現的功能，會上進行討論，最後以舉手表決的形式決定哪些是可以“推遲”的功能，哪些是“必須實現”的功能。

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

答：有。我們認為能按順序擊落敵機是我們的出口條件。

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

答：能。

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

答：可以。在時間允許的範圍內，我們大家是可以接受並且有效處理臨時的分工的。

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

答：我們學會了如何在團隊專案上進行有效溝通。如果重來一遍，我們會繼續保持現在的風格。

設計/實現

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

答：設計工作在編寫程式碼前，由具有豐富遊戲經歷的成員來完成。我們認為是合適的時間，是合適的人。

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

答：有模稜兩可的情況。模稜兩可的情況一般是現階段可實現也可不實現的非核心功能，我們可以暫時擱置這樣的情況。如果是核心功能有模稜兩可的情況，我們會通過舉手表決的形式解決。

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

答：我們沒有運用單元測試，測試驅動的開發、UML，或者其他工具。

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

答：有的字母一直不會出現在螢幕上。原因是我們沒有把前面的字母清空。

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

答：我們在變數和函式的命名上嚴格執行了程式碼規範，程式碼的可讀性比較高。

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

答：我們學會了如何在寫程式碼的方面進行團隊合作。如果重來一遍，我們會在測試出問題時，及時告知團隊所有成員，集思廣益應該是最有效的辦法。

測試/釋出

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

答：有測試計劃。我們在阿爾法階段專案完成時，將專案交給不同的人進行測試，這些人大多是在讀的學生或者剛就業的同學。

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

答：是的。我們收集了19個人的遊戲體驗，他們的反饋有很多是在我們意料之外的。

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

答：沒有。

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

答：我們暫時沒有測量軟體的效能。

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

答：釋出的過程中，股東發現程式執行時，會出現cmd控制檯，這是我們的疏忽。

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

答：在軟體釋出的過程中，發生了我們意想不到的問題，我們應該意識到測試的重要性。如果能重來一次，我們會做一個更詳細的測試計劃，儘可能避免意外問題的發生。