目錄：
##一、設想和目标
1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
我們的軟體要解決的問題是學院、社團在釋出活動通知和進行簽到統計時過程繁瑣的問題。定義得也比較清楚，包括具體的通知活動的釋出、學生參與活動的報名、統計和簽到。在需求說明書中有對通知釋出者、活動釋出者、活動參與者的典型場景進行描述。
2.是否有充足的時間來做計劃?
有充足的時間，但時間利用得并不充分。
3.團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
通過小組一起協商讨論來解決意見沖突。
4.使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
Alpha版本的使用者目前隻有我們小組的成員，基本功能還是如期實作了，但是一些額外的功能尚未實作。
當然離目标更近了！
5.有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
最開始的時候，我們預期的alpha版本的功能更複雜，但是随着項目進行，砍掉了很多與核心功能沒關系的“花瓶”功能，專心寫主要的功能。。。重來一邊的話，我們将一開始就抓住重點，進行開發。
二、計劃
1.你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
并沒有完成，還有一個“釋出者”的簽到功能，尚未實作。
因為前端一直在美化其他界面，沒來得及做這個界面，是以後端功能實作了也沒法添加進去。項目進行到最後亂了陣腳。
2.有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
黃志明（PM）：在大家尚未會使用github的時候上傳了源項目檔案。後來使用 git的時候，已經換掉了倉庫。
李嚴（V）： 去找了droiddraw軟體來做控件布局，本來想是一個友善使用的工具，然而= =還不如直接在Android studio上敲代碼來的效率高
格格（V）： 糾結于按鈕大小，背景圖等一些元素！
橙汁（V）：調試虛拟機，太費時間，直接真機
志興（M）:一開始對一些雲服務提供方給的函數進行了封裝，但也許是因為基礎上的不足或了解錯誤，寫出的代碼有問題，在測試時有一些不明的bug，後來照官方文檔直接調用函數就正常了。
牛姐（V）：就是對界面的調整吧，感覺棟哥對我們的界面的設計很無語的感覺。
佳恺（M）：我認為在項目中我因為糾結于封裝與資料庫資料互動的查詢方法而浪費了大量的時間
3.是否每一項任務都有清楚定義和衡量的傳遞件?
嗯。。。定義還是比較模糊的。主要是界面中，該有的都有，功能中，能使用的都能用。就可以了，具體到什麼樣的界面叫“好看”沒有詳細定義、什麼樣的功能算“完整”，也沒有定義。
4.是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
并沒有。最開始的配置設定釋出者界面的橙汁，去參加ICPC，是以釋出者的界面拖到了後面才勉強完成。然後就是突如其來的兩場期末考，大家得找時間複習。。。複習之餘還得寫代碼（毫無經驗），還是比較痛苦的。
因為估計這種東西是很玄乎的，把任務布置下去，大家之前都沒做過相關的工作，說自己一兩天能完成，完全是扯淡。
5.在計劃中有沒有留下緩沖區，緩沖區有作用麼?
沒留什麼緩沖區，因為計劃趕不上變化。
6.将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
将來将設定時間點，定時定點檢查假面以及功能。
7.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
如果曆史重來一遍，一定嚴格按照計劃，不要拖拖拉拉！
三、資源
1.我們有足夠的資源來完成各項任務麼?
我們用的是Android Studio來寫程式，AS和虛拟機在電腦上太占記憶體，每次一調試都要等上半天，最後我們改用用真機測試來節省時間。資料庫方面我們直接用網上的，花時間學習了下對資料庫伺服器的操作。
2.各項任務所需的時間和其他資源是如何估計的，精度如何?
開始時估計界面排版會寫的很快，于是配置設定先寫界面，剩下的熟悉邏輯功能，等界面完成後接着寫。但後來發現并不是這樣，界面寫了好幾天才完成，熬夜寫完了邏輯功能。
3.測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
簡單的進行了模拟使用者測試，測試了各個界面的功能，基本完善，但還沒進行真實使用者測試。
4.你有沒有感到你做的事情可以讓别人來做（更有效率）?
黃志明（PM）：我可以把釋出者界面給牛姐做，這樣風格更統一而且美觀。。。最後看她一直在改我的界面改到快吐血，感覺挺尴尬的。。。
李嚴（V）： Android studio 的安裝與配置，= =向來編譯軟體都沒有很順利地安裝好過，這次也不例外。當有了問題，各種百度無果後，必要時一定要向隊友求助！！！硬生生搞了兩天後，無果，結果把電腦給隊友，一晚上就好了
格格（V）：我覺得工作完成的還算及時把！效率的話，有經驗的人自然更有效率了，一樣的基礎的話，應該差不多！
橙汁（V）：寫界面排版的人可以繼續寫相應界面的邏輯功能，自己寫的界面自己更熟悉，寫起來也友善，但由于都是初學者，學的不全面，隻能分開寫。
志興（M）：有，在寫代碼這件事上，主要是由于自己基礎不行，加上注意力不集中，遇上問題要很久才能解決，而隊友比較專注，做得比較快。
牛姐（V）：我沒感到自己做的事要别人來做，倒是覺得分給其他人的側滑應該交給我來做，這樣就不會太引起後面的麻煩。
佳恺（M）：我認為自己的工作可以交給其他人來做，但效率并不會得到提升，并且我認為我遵守了《軟體需求分析報告》的代碼命名規範，使得我負責部分的代碼可讀性較高
我們将重新配置設定下任務，讓大家做各自熟悉的工作
四、變更管理
1.每個相關的員工都及時知道了變更的消息?
團隊大部分在一起程式設計，消息傳播很快
其他還是通過我們項目的qq群來傳遞變更的消息的，每天晚上還有站立式會議。
但是有一點要自我批評，拖延症狀，不經常Pull最新代碼，部分組員的工程檔案落後于最新的版本。但所有push的更新都會在工作組中提及。
2.我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
從使用者的角度出發，決定哪些功能是必備的，哪些是附加功能，哪些是可有可無的，排出優先級。
根據我們項目的具體情況，我們首相要實作項目的基礎功能。我們的項目最主要的功能大概有以下幾點，活動的檢視、活動釋出與編輯、人員報名參加活動以及相關的注冊登入。
完成了這些功能就已經有了一個活動管理平台的樣子了，這些是我們“必須實作”的功能，其餘的相關的功能，就可以在beta階段逐漸的添加進來。
3.項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
Alpha的出口條件簡單粗暴，即沒有導緻crash的大bug，預期功能健全完善。隻有一個移動端的平台，是以“做好了”的直接效果就是安裝我們的APP各個功能以及排版都能夠實作其應有的功能，這也是比較好測試的。頁面整合後，能夠通過各項的測試，這樣就算是“做好了”。
4.對于可能的變更是否能制定應急計劃?
基本沒有，出現的幾次應急情況都是我們的成員熬夜補救的。
5.員工是否能夠有效地處理意料之外的工作請求？
可以處理，PM給定工作請求時會配置設定給較為積極的組員和比較有經驗的組員，大家做事都很積極，基本上都是搶着做，雖然在處理問題上的處理問題的能力有待提高，但是針對具體問題有着具體的解決方案，執行起來也很快。
6.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
用Git，用Git，用Git，重要的事情說三遍，大家開始使用git有點遲了。出現了多人修改完之後導緻覆寫的問題，這些部分都不太多，是以還沒有造成較大的影響，不過這種現狀确實是要改改了！！
五、設計/實作
1.設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
界面原型設計在早期就已經由橙汁完成了，真實際界面的設計與原型還是有一定的差别比如按鈕大小，字型大小，背景等等！因為找不到原來的背景圖了。後期也考慮是否修改原型，因為設計出的界面無法适應所有分辨率的手機，控件都會有所偏差！
2.設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
有的。就比如之前有過關于釋出者身份是否與參與者的身份合并，是放在同一界面，還是分開作為不同身份，分開登陸。最終少數服從多數采用分開登陸的方式。
3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？
有運用單元測試，基本都是每個人測試自己的子產品，在遇到實在不懂得問題，大家一起讨論，在測試結果符合後再合并到一起。測試過程沒有采用工具，基本是手工測試，遇到問題就修改
4.什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
因為每個人測試自己的子產品，是以有些人的不是很了解。就登陸界面來說，在登陸的時候會出現第一次正确密碼可以登入，以後再次登陸就會失敗。後來修複了。其他的還有就是側滑框的實作不是很理想
5.代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
一開始，制定了代碼規範。然後就沒有然後了，各自采用各自的命名⋯⋯嗚嗚！等合并的所有的界面的時候就遭報應了
貫徹落實代碼規範
六、測試/釋出
1.團隊是否有一個測試計劃？為什麼沒有？
有，但是沒有依照計劃進行
原因：alpha版本的時候團隊進度比較小，以至于deathline還有在修改代碼，留給我們的測試時間就大大減少了，導緻測試計劃沒有如期進行
2.是否進行了正式的驗收測試？
說起正式驗收測試，并沒有。但是說起非正式驗收測試，一大堆。
3.團隊是否有測試工具來幫助測試？
有，在網上有百度到J是一個很好的測評軟體，但是後來由于功能的太多欠缺，以及不太懂測評
4.團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
手動調試來跟蹤軟體的效能；測試工作有用，能夠測試出bug，但是很難找到bug存在的準确位置和真正原因，正就是所需要改進的地方。
5.在釋出的過程中發現了哪些意外問題？
由于測試和完善做的不是很全面，導緻我們組在7點鐘還在活動室裡調試，尋找bug，登入注冊使用者= =在此之前一直都沒出過問題，誰知在彙報前期，竟然⋯⋯ 這很尴尬啊，還好最後找到了原因，釋出才能夠順利進行
用git及時整合，及時測試。
七、總結:
1.你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
1. 在Alpha沖刺之前，我們團隊有針對我們的項目做過需求分析以及項目計劃
2. 在Alpha沖刺階段，盡管我們小組一開始沒有通過github進行項目管理，但是每天會向組長彙報自己的工作量以及工作進度
3. 在Alpha沖刺之後，團隊有了類似項目的開發經驗，一定程度上可重複類似項目的軟體開發
4. 小組有測試人員，通過案例測試充分保證了軟體Alpha版本的核心功能的使用以及品質地保障
2.你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
1. 在Alpha沖刺之前，我們團隊每個人都沒有項目開發的經驗，雖然每個人都有一定的JAVA語言基礎，但是并不知道自己适合于MVC架構中的哪一部分
2. 在Alpha沖刺階段，組長根據MVC架構以及每個人在Android學習的進展程度來配置設定任務，UI界面設計交給了Android語言學習進展較快的隊友來做，偏向JAVA語言方向的Model和Control就交給剩餘的人
3. 在Alpha沖刺之後，團隊的每個人并不能展現出自己的強項和自己的代碼能力，是以在項目開發過程當中任務的配置設定還是沒有一個具體的名額，就是這個任務交給誰來做都可以，是以團隊還處于磨合階段
3.你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
1. 有真正地項目開發的經驗，對一個軟體開發的過程不會像當初那麼迷茫
2. 團隊有了一個一起開發軟體的經曆，營造了團隊組員之間融洽的氣氛和難以割舍的感情
4.你覺得目前最需要改進的一個方面是什麼?
項目管理以及項目進度的把控。在Alpha沖刺階段，每個組員的任務安排下去之後，組長沒有對項目的整個程序進行把控，組員也沒有每天向github上面送出代碼，盡管這是組長每天吩咐的事情，但在組員那邊沒有得到落實，大家在自己電腦上的項目進行代碼開發，造成最後項目的整合時class檔案命名的沖突，界面風格的不統一，以及對邏輯功能的實作造成了一定的困擾。 ![Daily Scrum Meeting 彙總[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)