隊名：歡迎來懟

項目名稱：博客園Android端APP

小組成員
隊長：田繼平
成員：李圓圓,葛美義,王偉東,姜珊,邵朔,冉華

——————————————————————————————————————————————————

設想和目標

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

　　我們的軟件目標是利用手機APP的便利性，讓大家能夠更加方便地進入博客園去學習和交流技術，不會因為電腦不在身邊而無所適從。對於功能的定義很清楚。對典型用戶和典型場景也有清晰的描述。

2.我們達到目標了麽（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麽？ 原計劃達到的用戶數量達到了麽?)?

　　在Alpha發布階段，我們已經達到了計劃目標。原計劃的“博客園首頁博客列表獲取及精華博客列表的獲取”、“首頁博客查看及精華博客查看”功能已經完成，已按照原計劃的交付時間交付，原計劃的11名用戶也已經達成，並且收集到了他們的反饋。

3. 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致麽? 我們離目標更近了麽?

　　用戶量和用戶對重要功能的接受程度和我們事先的預想是一致的（因為我們在Alpha發布階段對於用戶量和功能實現的預計十分保守），我們離將來的目標更近了一步。

——————————————————————————————————————————————————

計劃

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

　　否，因為這個項目是一款手機Android端APP，對於小組內的大部分人來說是一個從未接觸過的領域，需要耗費額外的時間去學習Android端編程（甚至有些人還要去學習Java語言！），而且小組成員們也來自不同的導師和小組，也有著各自優先級更高的個人任務需要去完成。

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

　　在計劃階段大家的不同意見很少，出現的少量問題是組長親自去找產生分歧的組員面對面地交流以達成共識。

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

　　我們原計劃的工作大部分完成了，但是“博客園用戶登錄”的功能沒有實現。因為博客園網站的變動，用戶登錄出現了一個“防機器人”的篩選功能，導致我們在Alpha發布之前無法完成新的登錄方式，將登錄功能轉而推到後續的版本中去完成。

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

　　沒有，因為我們將任務分割得十分細致並仔細確認了目的，並且準確落實到每個人頭上，因而沒有出現沒有必要或沒有太大價值的任務。

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

　　是的，每一項任務都有清楚定義和衡量的交付件。

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

　　在項目Alpha發布之前，整個項目過程在按照計劃進行，登錄功能的推遲發布也在我們小組的計劃之中，在Alpha發布版本屬於“選做”功能，並沒有影響到Alpha發布的主要完成計劃。

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

　　沒有，由於我們對於項目進程的估計保守，且任務分割細致，因而並沒有在計劃中留下緩沖區。

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

　　Alpha發布的完成，使我們對於項目的進度十分滿意，因此，我們可能會對將來的功能做出更加“大膽”的計劃，因此，可能會在計劃中留下一定的緩沖區以防計劃失控。至於加班問題，因為大家在項目之外還有很多來自導師以及其他課程的作業和任務，暫時沒有加班的打算。

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

　　在Alpha發布完成後，我們在這3周的時間裏感受到了項目任務的細致分割對於大家的效率和積極性有著很大的提升。每日召開Scrum會議上交流各自每日所做的工作也會督促著大家去努力完成各自的任務。因此我們會繼續保持這種做法。

——————————————————————————————————————————————————

資源

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

　　沒有，因為這個項目是一款手機Android端APP，在物質資源上，由於團隊裏有的人使用的是iphone手機，在使用效果上，電腦Android模擬器肯定是比Android手機實體要差一點的。而時間資源上，這個Android端APP項目對於小組內的大部分人來說是一個從未接觸過的領域，需要耗費額外的時間去學習Android端編程，有些人還要去學習Java語言，而且小組成員們也來自不同的導師和小組，也有著各自優先級更高的個人任務需要去完成，時間資源上也十分地匱乏。

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

　　在組隊初始，大家都簡單自我介紹了一下，並且對於各自會哪些技能都有了相互的認識，在各項任務的時間和資源分配上會考慮到每個人的技能和學習能力，時間精度精確至小時。

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

　　因為是Alpha發布，並且完成的功能很少，因此項目測試的時間、人力和軟/硬件資源是足夠的。對於非編程資源（文案/美工）確實是低估了其難度，分配的精力和時間過少，導致文案、美工、視頻展示還有課堂展示都沒有達到預期的效果，甚至是很糟糕……

有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?

　　任何任務都是重要的，我們對於文案、美工、視頻展示還有課堂展示的輕視導致了Alpha發布成果低於預期。如果歷史重來一遍，我們會對非編程任務也重視起來，做出更加完善的計劃。

——————————————————————————————————————————————————

變更管理

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

　　我們運用微信討論組傳遞消息，要求在收到消息後及時地反饋，並且我們每日都會定時召開Scrum會議，因此每個小組成員都會及時知道變更消息。

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

　　在每日的Scrum會議上會討論大家每日的工作，對於各自的進度、效率和成長都會有著認識，也會根據每日的實際情況來決定“推遲”和“必須實現”的功能。

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

　　有，因為計劃的保守，在Alpha發布階段我們對於項目的出口條件是基本實現即算完成。

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

　　否，因為我們對於任務分割細致，且在Alpha發布階段各自的任務並不是太多，因而並未考慮到應急計劃。

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

　　否，因為任務都是在按照計劃進行，所以也沒有出現意料之外的工作請求。

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

　　在接下來的項目階段，由於計劃會越來越多，可能會出現任務分割及分配不夠細致的問題，因此應急計劃的需求也會隨之產生。

——————————————————————————————————————————————————

設計/實現

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

　　設計工作是大家一起在會議時間內完成的，是屬於合適的時間與合適的人。

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

　　因為是Alpha發布階段，在設計工作中遇到的模棱兩可的情況我們會在討論後選擇是否推遲或者放棄實現。

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麽？ 比較項目開始的 UML 文檔和現在的狀態有什麽區別？這些區別如何產生的？是否要更新 UML 文檔？

　　沒有。因為在Alpha發布階段時間資源不夠充足。

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

　　在獲取首頁博客功能上，由於設計失誤，導致程序每24小時都要更新一次內部代碼才能保證鏈接到首頁。

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

　　代碼是統一由冉華同學進行整理和上傳的。

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

　　對於項目計劃的時間分配要做到更加準確，也要為將來階段做好測試bug的時間預留，代碼復審等也要更加留意。

——————————————————————————————————————————————————

測試/發布

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

　　沒有，在Alpha階段時間分配過於緊湊，後期也由於各自有著文案、美工、視頻展示和課堂展示的準備工作，並沒有測試計劃。

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

　　否，僅僅是有著視頻展示和課堂展示。

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

　　Android系統手機，電腦上的Android模擬器。

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

　　由於在Alpha階段實現的功能過少，且目的也僅僅是為了證明項目能夠“聯網”和“跑起來”，因為並沒有對軟件進行效能測試。

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

　　視頻展示和課堂展示準備過於倉促。

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

　　計劃要充分，準備要完善。非編碼的工作也要認真地計劃並完成。

——————————————————————————————————————————————————

團隊的角色，管理，合作

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

　　在組隊後，我們的第一次會議就是大家對自己做介紹，表明各自的能力，然後大家一起討論分配各自的角色，做到了人盡其才。

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

　　有，我們是一個團隊，大家都很熱情，互相幫助。

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

　　由組長出面，快速地找到問題的源頭，找到涉及人員，面對面地討論解決。

——————————————————————————————————————————————————

總結:

你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?

　　我認為團隊目前處於 磨合 階段，大家各自的能力有著提升的空間。

你覺得團隊在這個裏程碑相比前一個裏程碑有什麽改進?

　　對於計劃要更為完善，這樣對於項目後期完善有著更為充裕的時間和空間。

你覺得目前最需要改進的一個方面是什麽?

　　作為一個APP需要實現更多的功能。我們會收集整理用戶們的反饋結果，完善更多的功能。

——————————————————————————————————————————————————

附：全組照片

【歡迎來懟】事後諸葛亮會議