Beta階段復審

事後諸葛亮分析
設想和目標

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

編寫的app主要解決了個人學習提醒的功能，讓使用者提前設置好學習計劃安排，等到特定的時候提醒用戶。促使用戶合理地計劃時間，養成良好的學習習慣增加學習的效率。也可以在網絡上借鑒其他人的學習計劃，取其精華去其糟粕，從而形成適合自己的學習計劃。

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

大家的目標都有一個共同的目標出現分歧時，我們會及時討論取得一個大家都認可的計劃，在能力範圍內讓每個人發揮自己實力的最大化。

3. 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致麽? 我們離目標更近了麽?有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?

用於對於產品的接受程度與我們的事先預想的不太一致，如果歷史重來一遍，我們會將界面修改的更加美觀，增加一項統計每天工作學習休息的時間比例。認真思考一下我們的產品與市面上功能相近的app之間的差異在哪裏。

計劃

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

有，我們用了將近一周的時間，設想app的架構功能和app的制作方向，在進一步完善計劃中的各種功能。

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

沒有，有一部分的優化沒有實現。在設計和實現的過程中學習app的開發用的時間稍微有點長，美化界面的經驗不足。

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

有，在做出不同的功能的時候發現，有的功能近乎相似，然後就又重新設計新的功能。

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

雖然每一項任務都有清楚的定義，但是有時候預想的功能在使用代碼實現的時候會有些出入，一個較簡單的功能在編寫的時候又是也可能出現一些差錯導致任務時間的拖延。

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

並沒有想象中那麽順利，在制定計劃的把編寫代碼想的過於簡單，導致經常出現一些bug讓軟件崩潰，主要是大家編程的能力有限，經常需要現場學習才行。

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

預留緩沖區為了應對出現的突發狀況，或者想到新的想法可以直接添加進去。

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

我們學到了在項目中盡量為日後可能出現的變故留出時間空間。學到了計劃並不能完美地執行，過程中可能會遇到許多的問題需要重新討論解決，如果重來一遍，我們不會過分地註重計劃， 而是註重過程。

資源

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

有，通過發達的網絡資源可以找到絕大多數我們需要的資源。

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

時間上基本都是按照計劃表來安排的，基本上都是在課余或者晚上的時間完成任務

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

a. 測試時間：基本足夠，所有的軟件功能都通過了測試

b. 人力資源：小組成員都有明確的分工，每個人都各盡其責完成各項指標。

的確，編程初期對美工這一方面就是以為隨便添加一些圖片之類的，但在實際操作的時候發現美工需要註意很多地方。

變更管理

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

同學直接每天都有見面的機會，一旦有變更的消息會立即開展站立式會議通知到每一個成員。

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

在設定項目計劃的時候我們設定了每個功能的優先級所以優先級低的功能可能會被推遲，

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

完成了用戶使用狀況的反饋後最初相應的調整，修改對應代碼後。

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

每個人有明確的分工，來應對緊急的計劃

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

經過統一的討論後，基本都可以解決。

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

一個項目的消息變更是多麽的重要，一定要在第一時間通知項目的所有組員，保證所有組員了解最新的消息。

設計/實現

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

再設計工作之前小組內沒有一個人做過項目的經理沒有設計的經驗，所以在想法都是通過小組成員之間意見的碰撞產生的。

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

沒有

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

小組成員的每個人都是通過單元測試的方法測試自己負責的部分，在通過討論在合並到一起。測試工具倒是沒有嘗試過。

4. 什麽功能產生的Bug最多，為什麽？在發布之後發現了什麽重要的bug? 為什麽我們在設計/開發的時候沒有想到這些情況?

在軟件運行的各部分功能切換的時候會出現bug，有時會卡著不動，編寫的時候經常出現各種各樣的問題在查找解決方案的時候會加入一些其他的代碼。本以為沒有什麽bug但是在實際運行的時候居然有這麽多。

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

我們都有嚴格的遵守代碼規範。

測試/發布

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

有，在設計的時候就制訂了測試計劃

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

正式進行了每個模塊的測試，整體的測試在app完成後用虛擬機測試

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

用的是Eclipse中的安卓虛擬機。

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

還是蠻有用的至少讓我們發現了許許多多的問題

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

無

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

團隊的角色，管理，合作

1. 團隊的每個角色是如何確定的，是不是人盡其才？

每個人都是項目負責的部分，都是靠競爭上崗。

2. 團隊成員之間有互相幫助麽？

當然有在編程出現瓶頸的時候會一起討論下一步應該如何進行。

3.當出現項目管理、合作方面的問題時，團隊成員是如何解決問題的？

當如果遇到有不同意見的地方，我們會采用每個人認真的闡述自己的觀點並指出為何別人的觀點不適宜於我們的項目，而自己的觀點高明在哪裏。在所有人闡述完以後我們再舉行民主投票，采用支持者最多的觀點的方法。如果有不可調和的地方，最終一般是由組長來決定。

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

一個人的能力始終是有限的只有大家擰成一股繩一起努力才能更快更有效的完成一件事情

對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

1.項目經理每天都有督促、鼓勵開發人員的進程。

2.每個人都犧牲了自己本來應該休息的時間去學習關於安卓開發的知識。

3.團隊直接沒有任何一點不和諧的因素，讓團隊的溝通變得十分的順利

博客要附上全組討論的照片

2.團隊成員在Beta階段的角色和具體貢獻：

項目復審與事後分析