設想和目标
1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
- 我們的軟體要解決為使用者提供一個供一個可以傾吐和記錄點滴的地方，無社交無廣告，隻有自己的平台，同類産品充斥着滿屏的廣告與喧鬧的社交而使使用者無法靜心的問題。
- 定義清楚，主要功能是要能實作發一篇日記收到一篇别人的日記，有收藏、标簽功能，基于市場普遍存在的日記應用的拓展。
- 對典型使用者和典型場景有清晰的描述，切合問卷調查與使用者場景分析來進行開發。
2.是否有充足的時間來做計劃?
- 我們有充足的時間來做計劃，可以說Alpha沖刺持續了一個月的時間，如果重需求分析開始算起，目前已花了兩個月的時間。顯然我們的計劃不夠具體，大部分人沒有做好計劃，沒有好好利用這一段時間，實作的過程很多細節也要重新構想。
3.團隊在計劃階段是如何解決大家對于計劃的不同意見的？
- 主要通過開會或使用QQ群内讨論，對于提出的不同意見，我們采取每個人都說說自己的想法，最後擇取多數人共同的部分，并聽從多數人的意見，或是接受有過相關經驗經曆的人的想法，此外若是關于實作問題，也将在讨論時附上一個簡易的模型。
有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
- 理想很美好，顯示很骨感。剛開始我們計劃要完成“多少多少”，有激情，而這份激情被時間一點一點的磨蝕掉。高估了自己，對可能遇到的困難沒有一個清晰的概念，現實情況中困難重重，理想與現實的懸殊太大。
- 如果曆史重來一遍，我們會先交流好每個人最擅長的部分，接着制定計劃時，會根據這一點出發。執行計劃的過程中也會去互相監督。
計劃
1.你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼？
- 在伺服器與資料庫部分，資料庫已完工，而伺服器已實作大部分功能。但是他關于安卓與伺服器互動的部分（安卓背景）隻完成了少數。原因便在于計劃不夠完善，在最後的沖刺時間選擇把時間集中投入于界面與界面互動。
- 安卓方面很多事情都沒做完。完成了大部分界面，但是時光軸的實作在多天嘗試後仍失敗，由于計劃不周與執行計劃不夠自覺導緻的時間問題，隻能把它放到beta完善。碎片嵌套也沒能實作，原因在于原本的代碼結構不好，也沒能及時對代碼進行重構。
2.有沒有發現你做了一些事後看來沒必要或沒多大價值的事？
- 對界面的控件進行重新命名，修改原本設定好的控件布局，為達到盡量美觀。結果，重新命名沒有特别大的作用，重新寫布局也沒有變得更好看很多。
- 對于代碼規範在事前已經定好了，但是在具體實作時代碼規範被幾乎擱置，而且缺乏注釋。導緻于後面在一起解決安卓的界面和界面互動時出現了需要一人解釋的情況，這無疑中又浪費了些許時間。
3.是否每一項任務都有清楚定義和衡量的傳遞件？
- 大部分都沒有，是以一方在接收時往往不能确定是否合格，在後續的開發中可能又進行修改和完善。并且到最後我們沒有完成預期目标。
4.是否項目的整個過程都按照計劃進行？
- 一開始有按照計劃進行，但是後來随着執行計劃的自覺性降低并且難度增大，時間越花越多，出現了“滾雪球”現象，就沒能及時完成任務。
5.在計劃中有沒有留下緩沖區，緩沖區有作用麼？
- 一開始就對預測可能遇到難度的闆塊預留了緩沖區，而這個緩沖區由于計劃的執行不夠也減少了其長度。緩沖區确實有發揮作用，雖然我們并沒有完成預期目标，但依舊減少了成員的不少壓力。
6.将來的計劃會做什麼修改？
- 對任務進行更為明确的時間安排，制定每個時間點需要完成什麼目标。
- 吸取本次Alpha沖刺的教訓，在執行計劃上，每一天都應該分享今日完成的進度，團隊成員互相監督，對在執行計劃中遇到的難點說出來一起解決。
- 預留更為符合實際的緩沖區長度。
- 計劃很美好，實際上最後離要計劃的目标相距太大。問題不完全在于制定計劃上，更多的在于執行上。
- 如果曆史重來，要關注每天的進度，防止停滞狀态出現。
資源
1.我們有足夠的資源來完成各項任務麼？
- 如果排除金工實習兩周，時間資源相對來說還是充裕的。
- 但是對于人力資源而言，由于大家都缺乏一定的項目開發經驗，是以對于項目的進度的把控存在不足。
- 在開發過程中，有許多有經驗的人士可以咨詢，老師、助教、IT人士（實際上隻找了助教）。網絡資源上，表面上百度很豐富，實際上幾乎都是有問題的資源，這一點很是頭疼。
2.各項任務所需的時間和其他資源是如何估計的，精度如何？
- 在任務的時間估計方面，主要是規劃好每天的任務，任務精度級算是精确到每天。在計劃安排中，考慮實際執行可能出現的各類情況以及剛開始成員經驗較少，是以前期的任務時間安排較長，後期縮短，這更符合實際情況。
- 對于每個成員配置設定的工作量以要實作的功能子產品劃分，精确到每個具體子產品。
3.使用者測試的時間，人力和軟體/硬體資源是否足夠？
- 由于開發項目過程中對于Android studio不夠熟悉，隊員中多次出現了各種問題（Android studio3.0版本發生較多改動，出現了很多不能完全說是代碼問題的問題），導緻花費額外的時間解決開發用的軟體問題。
- 測試的時間較趕，硬體資源足夠。想要用真機來測試時随便有，妥妥的~
4.你有沒有感到你做的事情可以讓别人來做（更有效率）？
- 在項目後期，前端的設計遇到了瓶頸，負責後端開發的隊友臨時投入到前端的開發中，但是由于對前端開發的經驗不足，并沒有很好的解決存在的所有問題。
- 每個人都有自己擅長的部分，在任務配置設定時對這一點不清楚，在實際進行中這一點就突出了出來。
- 要更為客觀實際的配置設定好資源。
變更管理
1.每個相關的員工都及時知道了變更的消息?
- 有建立讨論組，在項目進度更新的時候會在組裡進行通知，并進行必要的讨論，確定每個人都能能知道變更的消息。每個人收到消息時也都會進行回複。
2.我們采用了什麼辦法決定“推遲”和“必須實作”的功能？
- 在開始十天沖刺之前，通過小組站立式會議讨論，确定了本次沖刺要完成的部分核心功能。核心功能中容易實作的必須在 alpha 版本實作（必須實作），而核心功能中有技術難點的推遲到 beta 版本實作（推遲）。
3.項目的出口條件（Exit Criteria）是否得到清晰的定義？
- 對于項目的出口條件并不能清晰的定義，是以Alpha版本隻實作了部分的核心功能。
4.對于可能的變更是否能制定應急計劃？
- 項目的資料庫或者重要的伺服器代碼在進行改動時會備份到群裡儲存，防止突發的資料丢失對于項目進度的影響。
- 在團隊中的個别成員在沖刺期間有考試時，适當減少該成員的工作量（最後發現竟然5個人在輪流考試中，而且還挺難的），并經過讨論合理調整任務計劃。
5.員工是否能夠有效地處理意料之外的工作請求？
- 對于意料之外的工作請求，在進行讨論後，後端開發人員臨時加入到前端的設計開發中，隻能盡最大的努力完成任務（結果後端根本那前端的技術相當不得力啊，然後又想回去做後端了），這并不是有效的處理辦法。
- 遇到瓶頸導緻停滞出現時，團隊沒有一個好的解決方案，處理起來沒有效率。
- 在事前要制定好應急方案。
設計/實作
1.設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
- 設計工作在我們團隊第一次讨論的時候就開始了，在進行需求分析的時候完成的，是由團隊所有成員一起讨論完成的，當然做需求分析的同學和做界面原型設計的同學給出的建議更多。
- 至于設計工作完成的時間我覺得是大緻合适的，不過我們在實際開發中也有改動一開始的設計，是以也沒有一直按照最開始的設計進行開發。完成設計是大家一起，然後做需求的同學和做頁面的同學給出更多的idea也是相對比較合理的。
2.設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
- 有的，比如在一開始定功能和需求的時候，大家的意見就無法統一。我們一般采用少數服從多數的原則來解決。
3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？
- 有使用UML來幫助設計和實作，這使得我們對項目有了更深刻的認識，友善了後續的開發。
4.什麼功能産生的Bug最多，為什麼？
- 随機收到日記功能産生的bug最多，因為動态收到日記的實作比較複雜。
5.代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
- 在寫過代碼後會有一個人專門看代碼以及命名規範，同時在寫的過程中每個人都按照代碼規範來寫代碼。但是在實際開發過程中還是會産生沒有按照規範的問題，然後寫好了代碼後面也很難去調整了。
- 制定的代碼規範不能隻停留在看的層面上，要去落實。
測試/釋出
1.團隊是否有一個測試計劃？為什麼沒有？
- 有一個測試計劃的雛形。由于時間上原因，沒有對它進行下一步操作。
2.是否進行了正式的驗收測試？
- 沒有
3.團隊是否有測試工具來幫助測試？
- 沒有，隻停留在自己寫代碼去測試代碼的層面。
4.團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
- 使用最原始的手動代碼操作測試。将遇到的BUG記錄在文本中。
雖然原始，但還是有它的作用。要做出的改進，有如下：
- 對每個功能寫一個代碼測試很耗時間。要改進方法。
- 記錄的BUG很淩亂，需要分類。
5.在釋出的過程中發現了哪些意外問題？
- 有些功能在不同的機器上工作的效果不一樣。有些設定操作停留在某些人的腦袋中，導緻在機器上運作時出現了一堆錯誤。
總結
1.你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
- CMM
2.你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
- 磨合
3.你覺得目前最需要改進的一個方面是什麼?
- 分工要更加細緻明确，計劃制定要更為考慮到實際問題。執行要保持激情。
最後附上成員本次開會照片