目錄

• 設想與目標
• 計劃
• 資源
• 變更管理
• 設計/實現
• 測試/發布
• 團隊的角色，管理，合作
• 總結

設想與目標

1. 軟件要解決的問題
????我們要讓用戶可以在手機上更方便地使用博客園班級的更多功能。在功能規格說明書中對需要解決的問題、典型的用戶和典型的場景有清晰的描述。

2. 是否達到目標
????基本實現了原計劃的Alpha階段的功能，按照原計劃的時間完成了交付，達到了原計劃的用戶數量。

3. 用戶量, 用戶對重要功能的接受程度

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

• 盡早確定可以完整實現的功能，避免中途因技術性問題擱置一些原計劃的功能。
• Alpha最終發布較晚，如果可以將盡早考慮發布和用戶記錄相關事宜，采集更多的反饋為beta做準備。
• 還應找到更多更好的推廣方式，加大力度。

計劃

1. 是否有充足的時間來做計劃?
????用了將近兩周的時間對開發階段做了計劃，並且在開發過程中根據實際的進展對計劃進行了調整。

2. 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
????計劃的產生本身是由全體團隊成員一起討論得出的，成員的意見通常沒有明顯的沖突。對於不同意見，一般會根據進展狀況、人員分工、時間要求等客觀因素進行協調。

3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麽?
????完成了，部分功能在發布之後得到一些意見和bug反饋，本階段繼續接受反饋和進行修復。

4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
????和助教討論了有關換人的問題。

5. 是否每一項任務都有清楚定義和衡量的交付件?
????是。通常要實現一個功能會由三個任務組成：對應API的測試，包裝和界面的搭建、切換、數據的顯示，和對功能的測試，完成以上要求後，認為一個功能基本實現。通過測試人員測試，認為功能比較完整。每個任務完成後能夠看到一定的成果。

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

7. 在計劃中有沒有留下緩沖區，緩沖區有作用麽?
????Alpha階段的計劃中沒有明確的緩沖區。僅在最後發布前一周時間較為充裕，所以應對平臺審核慢和打回時還算比較寬裕。

8. 將來的計劃會做什麽修改？（例如：緩沖區的定義，加班）
????Beta階段一些成員可能有其他的大作業，投入到項目中的時間不能夠保證。會根據成員間的情況及時調整計劃和任務分配，保證進度正常進行。

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

• 盡早確定可以完整實現的功能，避免中途因技術性問題擱置一些原計劃的功能。
• Alpha最終發布較晚，如果可以將盡早考慮發布和用戶記錄相關事宜，采集更多的反饋為beta做準備。
• 還應找到更多更好的推廣方式，加大力度。

資源

1. 我們有足夠的資源來完成各項任務麽?
????Alpha階段有六個人，四個人負責開發，一個人負責測試，在有博客園api的支持下，資源相對比較充足。

2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
????由於不需要後端，只需要對API進行調用。故在對功能是否可實現的估計中基本靠博客園API情況和考慮前端的工作難度，估計結果都比較準確。

3. 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
????Alpha階段測試的時間和人員安排不夠合理，在穩定和發布階段把測試的任務交給了測試員一個人，導致一些測試不夠充分。alpha版本發布後收到了一些bug反饋。
????Alpha對於美工沒有太多地考慮，主要美化的還是UI。將在Beta或Gamma階段考慮如閱讀體驗和字體主題等外觀的優化。

4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
????沒有。（就算有也不能因此劃水。）

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

• 測試進行得較晚，應當盡早進行測試，並將測試工作分配給測試人員和測試功能對應的開發人員，盡量進行更全面的測試，加大力度。

變更管理

1. 每個相關的員工都及時知道了變更的消息?
????變更一般在Scrum Meeting中由大家一致決定或者在群裏進行討論得出，或者由項目經理告知相關人員。

2. 我們采用了什麽辦法決定“推遲”和“必須實現”的功能?
????完全確定計劃之前進行了問卷調查，了解了一些熱門功能，把這些功能作為預期實現的基本功能（“必須實現”），其他進行改進的功能和不常用的功能作為可以推遲的功能。其中有些現階段實現起來比較艱難或有技術性問題缺少支持，將推遲或者放棄。

3. 項目的出口條件（Exit Criteria – 什麽叫“做好了”）有清晰的定義麽?
????兼容市面主流大部分手機，主要功能運行穩定。

4. 對於可能的變更是否能制定應急計劃?
????在多個平臺進行了發布，包括一些審核條件較為寬松的平臺，避免所有平臺的審核都不通過。

5. 員工是否能夠有效地處理意料之外的工作請求？
????Alpha階段的開發過程中基本沒有較大的意外需求。預期的功能及開發時遇到的技術問題基本能夠比較順利的解決。

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

• 會盡早進行發布和測試的相關工作，熟悉操作流程和需求。

設計/實現

1. 設計工作在什麽時候，由誰來完成的？是合適的時間，合適的人麽？
????設計工作在正式開發之前由項目經理完成，事先收集一些潛在用戶的需求並進行初步設計。這段時間其他成員需要進行環境的配置和新技術的學習，然後所有成員討論、修改，得出進一步的計劃；再後來結合實際情況進行調整。比較合適。

2. 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
????少數功能的設計方面有不確定的地方，在後續的開發過程中由所有成員討論給出一些預期的方案，討論可行性並得出最合適的。

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麽？ 比較項目開始的 UML 文檔和現在的狀態有什麽區別？這些區別如何產生的？是否要更新 UML 文檔？
????運用了單元測試，issues管理進度，友盟的U-App幫助功能實現，MindManager繪制記錄bug樹，Chrome的測試插件BlazeMeter與jmeter幫助測試。都比較有效。
????沒有UML文檔。開發過程中決定實現的功能、采用的架構上與最初的設想並不相同，根據實際的進展和必要性進行了修改。

4. 什麽功能產生的Bug最多，為什麽？在發布之後發現了什麽重要的bug? 為什麽我們在設計/開發的時候沒有想到這些情況?
????作業相關功能。作業下的子功能多涉及網絡請求，在同步刷新上容易出現問題；作業內容可能為富文本，還存在兼容問題。它們的出現並不意外，現在也基本都已經解決。

5. 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
????開發同學在拉取代碼後會閱讀簽入的新代碼，沒有專門安排負責代碼復審的人員。
????執行了約定的代碼規範。

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

• 設計時預期功能的劃分做的不夠好。導致了開發階段最終的一個功能只能以部分實現的狀態出現在App中。應當劃分得更科學，盡量實現完整的功能。

測試/發布

1. 團隊是否有一個測試計劃？為什麽沒有？
????測試人員在正式的開發工作開始之前制定了測試計劃

2. 是否進行了正式的驗收測試？
????進行了場景測試、壓力測試、集成測試、兼容性測試。

3. 團隊是否有測試工具來幫助測試？
????使用騰訊的WeTest平臺，對主流的50款手機進行了兼容性測試。

4. 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用麽？應該有哪些改進？
????采用appium+python腳本的策略進行自動化測試，主要測試軟件的特定功能。
????采用Chrome的測試插件BlazeMeter與jmeter工具進行壓力測試。

5. 在發布的過程中發現了哪些意外問題？
????一些平臺審核嚴格，將初版打回；一些平臺壓根沒打算和大學生玩（對開發者資質和版權證明要求嚴苛）。

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

• 應該對測試工作更加重視，更早地進行全面的測試。對於獲取數據過程中出現的問題，也應該進行一些處理，保證程序的穩定運行，避免意外的直接退出。

團隊的角色，管理，合作

1. 角色確定
????團隊確定的第一天大家主動選擇自己擅長的角色，發揮自己的長處：開發人員學習能力強、編碼實力強；測試人員思維嚴謹縝密，測試全面；項目經理負責文書工作，監督進度，各方溝通。

2. 互相幫助
????一個功能通常會分解成2-3個任務，在開發過程中遇到問題時通常會在群內討論，不能解決會留在例會進行討論分析，或當面檢查代碼中的問題。

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

• 明確每個人的分工，在分配任務時多參考開發成員的意見，給予自主選擇和管理的空間。

總結

1. 你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
????第二級（管理級），在項目開發中能夠遵守既定的計劃與流程，有資源準備，對任務分配到個人，對整個流程有監測與控制。

2. 你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
????磨合階段。團隊成員能夠較好的進行合作，項目推進穩定；但是職責定義不夠明確，基本按照目標功能進行劃分。

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

• 可用的軟件是衡量項目進展的主要指標：任務劃分基本以完整的功能為單位，每次叠代盡量完或者在新的功能取得進展，保證軟件始終可用。
• 保持簡明 - 盡可能簡化工作量的技藝 - 極為重要：直男分配，每次專註於一個功能或任務；精力集中於完成一項任務後再分配新的任務。
• 時時總結如何提高團隊效率, 並付諸行動：面對面的交流不可少，召開多次例會交流進度，調整任務；有問題和看法即刻在群內溝通。

下一階段改進：

• 更加重視測試工作，在整個beta階段都要跟進測試任務，對應功能的開發人員配合測試人員進行更全面的測試。
• 增加風險管理，對開發環節可能出現的問題準備備選方案，避免影響開發進度。
• 增加緩沖區，避免意外情況出現時手忙腳亂。

全組討論照片：

Alpha階段事後分析