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

組名：楊老師粉絲群

組長：喬靜玉

組員：吳奕瑤、公冶令鑫、楊磊、楊金銘、劉佳瑞、盧帝同、張宇

楊老師粉絲群“彈球學成語”專案

Postmortem結果

設想和目標

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

答：首先我們的軟體的名字叫彈球學成語，顧名思義，是基於PC端關於成語學習的一款趣味學習軟體。這款軟體所提倡的就是趣味遊戲與學習知識相結合，打破傳統的，枯燥的死記硬背的模式，構建一種全新的趣味學習模式，玩中有樂，樂中有玩。

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

答：有充足的時間，我們的小組從確定選題之前就已經開展了對這個專案的分析與調研，並在確定選題之後小組討論定義了典型場景、遊戲各個關卡等內容，並且初步把整個專案分配為各個功能模組，分工明確，團隊的每個人有各自擅長的強項，每個人對於專案的貢獻都為之重要，我們團結一心會把專案做的更好。

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

答：首先一週的計劃是事先確定好的，在每日的立會中我們會把事先分配好當日的任務進行討論，並且對於計劃，每個人都可以表達自己的觀點，對於一個即將確定的計劃，每個人必須都要有觀點表達，每個人都要表達出自己對於這個問題的意見與想法，然後我們通過討論來加深每個人心中確定的觀點，最後通過組長組織投票來確定問題的最終方案。我們在討論中相互認知彼此的觀點，多方面考慮問題，使我們進步，並且在討論中我們會產生更好的想法，這種想法最後也被採納。

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

答：我們本次專案的Alpha階段實現了小球在與擋板結合會跳轉成語的功能，它也是我們產品的重要功能之一，是我們產品的學習模式，因為它不需要你的識別，你只需要去接小球。我們的產品在Alpha階段共有30名使用者，他們通過使用我們的產品掌握了一些成語，並給我們專案組提出了寶貴的意見，比如球比較大，成語的難易程度等，這些意見也使我們的產品更進一步，通過與使用者的交流，我們可以及時的改善使用者的需求，使用者對於我們這個產品很看好，對當前的功能也很滿意，並且期待我們的檢驗功能。這個結果與初期的設想相比，也比較理想。

我們離目標確實更近了，目前已經實現了成語的學習功能，後續會繼續完善並開發成語檢驗功能。 

經驗教訓是團隊開發中要選擇大家都比較熟悉的語言，我們這次用python去實現我們的專案，雖然python用起來簡單方便，但對於我們來說是一門嶄新的語言，需要大量時間去學習這門語言，並且我們組在本科期間程式設計經歷都不是很多，所以大家要花大量時間在專案上下功夫。

在設計方面球體的體型偏大，導致遊戲難度降低，我們初始覺得這樣做是為了方便使用者能更清晰的學習成語，但大多數玩家追求的是遊戲難度，這也是我們在產品的開發中忽略的地方。

如果重來一遍， 我們會更全面的去了解客戶的心理，並且在學習python的時候我們走了很多彎路，摳得太細，我們系統的學習這門語音而不是對於工程來說用到什麼去學什麼。 

計劃

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

答：原計劃的工作已經完成，並且我們已經做了部分Beta階段的工作。

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

答：沒有，所有做的事情對於專案都很有意義，也在我們的專案開發中經得起檢驗。 

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

答：是。我們對於專案的分配非常詳細，我們會在會議上通過討論來確定專案的分配，並在leangoo看板上具體制定了各項任務的負責人、截止時間、任務描述。組員每天都要彙報自己的工作進度，面對問題時我們也積極的通過討論確定思路，組長負責監督每個人的工作進度。

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

答： 是的，我們通過對於問題的解剖，把專案分為各個模組，每個人去完成相應的模組，我們的計劃不變，到目前為止也完成的很好。

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

答：我們的專案預留了緩衝區。因為我們小組是按模組劃分任務的，最後要留一個緩衝區測試一下各模組是否都能實現相應的功能，以及對已實現的動能進行討論修改。

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

答：每週的任務是看我們的完成情況制定的，在分配上也比較合理，將來的計劃有可能會變動，比如比較困難的模組要多分配組員進來共同克服去解決，並且要多安排測試階段的時間，預先對問題進行自我檢測。

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

答：我們學會了如何採納別人的觀點，正視別人的觀點，如何在討論中總結問題的核心，學會了人員和按照顆粒度分析任務，學會了如何根據組員能力劃分相應擅長的任務。

資源

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

答： 網路上有關於Python的教學文件，從整體上講，資源比較豐富。

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

答：任務是根據每個人的能力去分配的，在分配時也給出了時間的度量，時間的把握上首先做這個東西需要對問題的度量（比如需要什麼知識，需要新學習什麼，需要完成度是多少），對問題估算後會有完成的時間，目前為止我們小組每個階段的完成任務的情況都優秀，這也是我們每日互相監督與討論的成果。

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

答：足夠。 

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

答：沒有。我們組在任務分配時就已經根據每個人的長處來最大化發揮自己對團隊的貢獻，所以每個人做的事情都是自己較為擅長的任務。

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

答：經驗教訓是儘早討論合理的安排各個任務，以確保能更快的投入工作，並且在自己絞盡腦汁之時要多於小組溝通，大家會根據問題討論出辦法，這也是團隊的力量。

如果重來一遍的話在Alpha階段開始前就應該對於問題進行分割，並且迅速分配各個任務，在開始之前一定要多溝通，瞭解每個人的優點，儘早的投入專案的研發。

變更管理

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

答：是的。

每次會議大家都會彙報自己的工作進度，並且晚上會對問題進行討論。

面對問題時，儘早積極的與大家討論，每個人在團多都最大化發揮自身的潛能。

程式碼方面每位同學在checkin之後會都在微信群裡通知大家。

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

答：

一個產品，吸引人的地方往往是它帶來的對問題的解決方式，往往體現在它處理使用者關心的問題的功能，所以核心功能絕不能推遲，我們如果造一輛汽車，初步想象的不是多麼華麗的外殼，而是即使是隻有兩個輪子，也要讓它跑起來。

每週釋出的小組成員的任務都是必須實現的，當一項任務可以推遲的話我們會優先完成必須要完成的任務，指的是時間序列，它在這一週是可以推遲的，但下一週它會發布任務變為必須實現，所以具體的劃分都是通過釋出任務，每週的任務都是必須實現。

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

我們對於“專案做好了”的定義是：完成了預先設想的三個模式，以及遊戲釋出之後，使用者可以正常使用，不存在無法執行、顯示錯誤等bug。

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

答：能。根據緊急情況會通過電話的方式緊急通知到各個人，根據任務的緊急情況來確定是開會還是線上討論，並制定應急措施，這種措施往往都是立即執行的。

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

答：是的。任務都是根據組內成員不同的長處來分配的，所以大家都會比較熟練，組內的氣氛特別融洽。

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

答：永遠不要強制別人，一定要換位思考，當一個問題你持自己的觀點的時候是否也調查了這個觀點在各個人群中的適應情況。

討論，是一種互相進步昇華的過程。

執行力與適應力是影響工作完成進度的標準，這方面的能力一定要訓練好。

如果歷史重來一遍，我們會更加積極的交流，遇到難題的時候大家討論，在修改之後一定要及時通知大家，這是對專案的責任。 

設計/實現

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

答：在設計方面，因為針對於小學生的產品，所以UI更傾向於卡通，炫酷的風格，這個任務的分配首先要了解組員的設計方面的經歷，然後根據能力去分配適合的人物，結果也比較理想。

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

答：有，但不多。在功能方面上初於對技術上的把握與遊戲效能的平衡，我們對遊戲模式的猶豫不決，無法確切的確定怎麼最大化的影響使用者，通過對市場的調研與演練，並且團隊的討論，投票，最終確定了合理的產品方向。

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

答：沒有采用上述工具。但是運用了燃盡圖以及版本控制等來輔助研發過程。測試的時候是小組內成員通過不斷地試玩，提出改進意見的。通過這種方法，發現了很多問題，比較有效。

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

答：就目前來說，彈球學成語專案中練習模式的小球回彈的角度存在差異，我們在定義時的函式存在了一個問題，後來經過測試與更改修改了這個Bug。

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

答：專案剛開始我們確定了語言，並且按照這個語言的特點定製了相應的程式碼規範，這也對我們閱讀起來有極大的方便，雖然有的習慣一時半會無法糾正，但是還是很嚴格的遵守我們的程式碼規範。

至於程式碼複審，由於開發迭代週期短，所以並沒有進行。

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

答：產品的設計上不是你覺得好就是好，而是適配對應的使用人群，是否有做過調研，使用者想體會的功能，場景，環境是什麼？如何去引導使用者的使用體會。

  一個產品的迭代週期需要一個可持續的相容框架，產品的設計需要可行性，可靠性。

如果重來一遍，我們會在設計的階段更貼合用戶的心理，並且更加重視單元測試，嚴格的執行程式碼規範。 

測試/釋出

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

答：有測試計劃，但是因為時間不夠充分，所以測試不全面。

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

答：沒有。開發時間佔用了大部分時間，還沒有來得及做這項工作。

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

答：沒有。

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

答：在PC端可以進行效能測試。從軟體實際執行情況來看，這些測試工作給我們帶來了很多收穫，幫助我們改進完善軟體。但是目前更多的時間放在開發上了，後續計劃多留出一些時間進行測試。

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

答：在釋出的過程中我們在打包的時候遇到了很大的問題，當程式執行時就會出現閃退的場景，後來我們通過對程式碼的測試輸出列印，發現問題並解決了問題。

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

答：經驗是要事先確定好一個完整的測試計劃，這樣產品的正式釋出才會更完善，由於開發階段的時間週期比較長，所以導致測試計劃也不是很完善。

如果重來的話，我們會制定一個完整的測試計劃，單元測試，效能分析等，來保證我們產品的質量。