作業要求【https://edu.cnblogs.com/campus/nenu/2018fall/homework/2324】

組名:二次元夢之隊

組長：劉瑩瑩

組員：潘世維、周昊、王玉潘、孫韋男、祝瑋琦、朱珅瑩、趙美增

二次元夢之隊小組“I Do”專案

Postmortem結果

設想和目標

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

答：I Do遊戲是一款結合了簡單C語言知識的休閒解密益智小遊戲；開發團隊將產品清晰的定位為休閒益智遊戲，而不是學習軟體；將產品的使用者群體定位為軟體和計算機專業的低年級學生或者是對計算機語言有興趣的非本專業人士或者單純無聊尋求娛樂的，我們並不期待通過此款軟體可以給使用者帶來豐富的計算機語言知識，只是讓本領域的使用者鞏固知識，讓非本領域的使用者在使用此款遊戲休閒娛樂的同時激發可能存在的對計算機領域的興趣。

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

答：有充足的時間，在專案未進入正式流程之前，我們已經討論決定了全組大團隊在各個階段要做的內容，需要完成的目標和這個軟體需要達到的完善程度；並且根據個人的強項和興趣點進行了任務的細分，比如潘世維同學負責對程式碼的整體把控，孫韋男同學主要負責美工的部分等。

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

   答：首先在每個階段的開始之前本階段需要完成的大目標計劃是在其實的一到兩次立會討論決定好的。在每次的每日立會中，是在每日master的主持下討論今日的任務以及成員所分配任務的進度彙報，包括遇到的困難，遇到個人或者小團隊解決不了的困難，會有其他隊員提供臨時幫助，比如視訊製作時的配音工作。

在團隊討論決定時遵循民主的原則，每個人都有權力發表對團隊整體工作或他人工作的看法，包括成果是否需要改進，進度是否需要加快等等；當然在決策時，遵循適當的集中制，在團隊大方向的問題決策時，實行少數服從多數。

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

答：在Alpha階段釋出初始版本以後，我們實現了除本組人員外的9名使用者，由於我們的關卡沒有實現完整，只實現了預計全部60關的前20關，鑑於軟體的完善程度依然需要很多提高，所以這個使用者量是可以接受的。我們在設計之初，重視的功能點是劇情走向，但是在使用者的使用中更注重的是每關的程式，這與我們的設想有一定差別，分析原因可能是目前使用者群體多為本領域內人員。

我們離目標更近了，程式的大體框架已經實現，風格也已成型，後續會繼續新增關卡和故事情節。

經驗教訓就是，前期的調查研究一定要做的更加充分；在目標設定時不僅要對內容上有要求，也需要強調時間的限制，不至於在作業快要截至時才勉強完成，造成影響工作質量的潛在威脅。

如果重來一遍，我們會更加註重前期對於潛在使用者的調查研究，找到真正能大幅提高軟體質量和使用者體驗的著力點；其次就是在實際那的把控上也要更加的嚴格。

計劃

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

答：是，在一個階段開始前會有數次站立會議討論整體目標和具體細節實現以及人員分工。

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

答：是，上一個階段的任務均已完成，且正計劃Beta階段的任務。

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

答：存在，在某些對整體價值不大的微末細節上過多的討論浪費了一些時間，並且對整體的工作意義甚微。

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

答：是。在專案開始的時候就已經藉助leangoo看板工具對具體的任務進行了明確。並且在每日提交的博文中也有所體現。

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

答：是，在起始階段專案的各個目標以及人員的分工已經明確，只要按部就班的完成就可以。當然，在某個人實現的過程中也遇到了一些困難，但是每日立會上成員可以提出自己的困難，會有其他的小組成員予以協助，這也正是團隊合作的意義吧，所以在完備的計劃和團隊的通力合作下，專案的整個過程基本都在按照計劃進行。

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

答：沒有。緩衝區的作用應該是讓盡全力而不能按時完成的任務有所緩衝並且不知於影響其他或者後續工作。

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

答：學習設定緩衝區，使每次作業在提交時不至於太緊張；在各個任務階段的時間分配上也要更加合理，比如視訊和美工需要更多的時間。

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

答：學會了傾聽別人的困難和需要的幫助，在組長的協調下根據各人的時間充裕程度和興趣點相互幫助。如果重來，會更加註重時間的把控。

資源

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

答：資源是有的，但是有時需要大量的時間來收集和學習。

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

答：在任務的分配時，成員選擇自己叫熟悉的任務，所以自己會有一個時間訴求，然後經過全體成員的統籌分析討論確定一個既能讓成員完成，又不影響他人和整體進度的時間。精度會根據每天課餘時間的多少有所不同，一般精確到天。

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

答：足夠

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

答：沒有，成員的任務分配時根據個人的興趣和能力進行的，也是充分尊重了個人的選擇，任務交換或許也可以完成，但是效果會打折扣。

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

答：資源的手機利用上要投入更多，不要想當然。在資源的使用上，很多資源或許容易找到，但是在使用到專案上是也需要很多的修改會耗費很多的時間，比如視訊製作是的特效加入。改進，更加合理的分配人員給此類需要大量時間的工作。

變更管理

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

答：能，每日立會可以很好的進行交流，在其他時間還有微信群隨時交流資訊。

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

答：根據功能的重要程度和難易程度，如果是關係到後續工作或者其他同學工作的核心功能必須按時實現，以免拖慢整體進度。對於工作量很大但是並不影響其他工作和後續進行的可以適當推遲。這些功能的確定由小組討論決定。

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

答：認為是專案實現了預期功能，本專案的預期就是先期實現20關的程式碼，情節，配圖，選關，設定。

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

答：能，很多工都是分兩人或三人小組進行合作，並且由於良好的平時溝通，彼此間的工作也都較為熟悉，在必要時可以緊急易人完成。

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

答：能，首先大家在組內合作，關係融洽願意江湖救急出手相助，其次大家的工作彼此也有所瞭解，在能力上也可以勝任。

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

答：良好的團隊氣氛對於專案的完成是十分重要的，讓每個人在團隊中都體現自己的價值，得到別人的認可；多多益善的交流，不僅有利於增進成員友誼，更加會增進對彼此工作的瞭解，在關鍵時刻可以頂上去，把任務拿下來。

設計/實現

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

答：由本科學習過設計的同學提出構思再由主要負責程式碼的同學討論實現的可行性，最後團隊討論確定。在現實的工作中證明，是合適的時間和人。

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

答：有，根據問題的性質，對於涉及到的軟體核心問題，會有團隊充分討論後投票決定；對於他人對成員個人任務提出的異議，會充分尊重任務實現者本人的意見，充分討論，結合最終對於整體的影響程度，據定應本人自行決定修改還是團隊投票規定任務方向。

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

答：沒有，在開發過程中更多的是組內人員不斷的試玩來確定改進。

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

答：在背景圖片的插入與螢幕適配上遇到了一些問題，在作圖以及適配方式上都做了很多的修改。原因是圖片格式不同意以及程式碼實現者對於適配方式不熟悉。

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

答：因為需要程式碼的共享，所以開始制定了簡單的程式碼規範，但是在開發程序中難度的增加，大家對規範都進入了置之不理的態度。

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

答：一個好的產品開發並不是多多益善的功能堆積，而是需要在出事階段進行的整體規劃，這樣才不至於在開發過程中程式碼龐大複雜、系統冗餘。

如果歷史重來遍，我們會在程式碼的編寫上更加註重整體規劃和細節的簡潔實現。

 測試/釋出

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

答：有測試計劃，在專案的進行過程中，全體小組成員都是及時的跟進試用，並提出改進意見，在第一階段定型後，所有人都進行了完整的對於各個功能的全流程測試。

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

答：是，專案在專案釋出後，我們收到了使用者提出的很多寶貴意見，會是我們下一階段努力的方向。

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

答：沒有。

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

答：目前沒有進行正式效能測試，但是在開發和組內試用中也發現了一些問題，比如個別題目結果不正確；軟體過大，比較佔手機記憶體。

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

答：因為是安卓端的應用程式，股東要求在手機上實操，但是展示時準備的時在開發環境的模擬器上展示功能。

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

答：在測試上顯然是要花費更多的精力，才能更貼近真實的開發過程，當然還要可行的計劃。

在釋出展示上，要充分考慮到各位股東的訴求，儘量準備更符合他們習慣的展示手段；在陳述中重講解功能，重展示，而不是講解程式碼。