設想和目标
1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
幫助解決福大學生遇到的各種疑問，定義的算是清楚，有
2. 我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)?
并沒有達到目标，原計劃的功能大概完成了百分之七八十左右，現在還隻是Alpha階段，還沒有傳遞時間。
3. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
現在完成的内容和預想還有所偏差，主要功能實作還有問題，當然離目标更近了。
有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
設想的很美好，現實很骨感，在我們設想的初期想了很多可以加的内容，剛開始想的時候比較有激情，高估了自己，想到什麼功能都一直往上加，然後後面在完成的過程中，發現實力跟想法相差懸殊，很多都舍棄了，沒有開發經驗，太天真。
如果曆史重來一遍，會根據自己的實際能力去設想一些功能，不要是太複雜的那種，否則既耗時耗力了，又沒有什麼成效，這樣對項目進度有很大的影響。
計劃
1. 是否有充足的時間來做計劃?
時間肯定不會充足，沒有人會覺得時間太多。在平時還有其他的課程要上，也不能把所有的時間都投入給軟工實踐，加上是第一次進行項目開發，是以我們的計劃就不是很細緻也不完善。
2. 團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
對于計劃的不同意見，有進行相關的讨論分析，如果有反對意見會再進行商量，然後看情況整改。
3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
沒有。
一開始的分工沒有特别明确，沒有将功能子產品配置設定到個人，每個人都集中在同一個子產品，導緻項目卡殼的時候每個人都沒有什麼新的進展了，沒有經驗，要花費的時間太多，一邊學習一邊做，一直有問題的時候激情就少了很多，進展就慢了，使很多原計劃的工作沒時間可以完成。
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
現在暫時沒有吧。
5. 是否每一項任務都有清楚定義和衡量的傳遞件?
定義的不是很清楚，一開始劃分的任務都是一整個子產品的大任務，沒有細化到小版塊，而每個人負責的也比較模糊，通常都是在完成的過程中才進行配置設定。
6. 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
沒有按照計劃進行，計劃的完成時間和實際的完成時間不一緻，導緻很多原定計劃不得不推遲或者舍棄。andriod的頁面跳轉有點問題。風險現在還暫時沒發現。
7. 在計劃中有沒有留下緩沖區，緩沖區有作用麼?
沒有，課業太多，一般的時間都是在晚上，也沒有其他空餘時間可以擠出來了。
緩沖區可以在一些意外發生的時候減少對實際進度的影響。
8. 将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
可以增設計劃緩沖區，然後将計劃的分工内容細緻一下。
我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
一個良好的項目計劃是很重要的，這樣項目的執行過程也會更加有條不紊，有效率。
如果曆史重來一遍，将對計劃表做更詳細的規劃，配置設定好每一個環節，以及每個人負責的子產品，每個人完成自己的子產品後再進行整合改進，就不會出現一個環節停滞，所有人都一起停滞的現象了。
資源
1. 我們有足夠的資源來完成各項任務麼?
現在任務量還比較小，資源還是夠用的。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
按照任務的分類來估計，如果是同一個子產品相似内容用時就估計少一點，但是由于我們是Learning by doing，在某些任務上就經常會遇到瓶頸卡殼了，一開始是估計每天平均完成三四個任務這樣的，但是現實卻是有些任務花費了兩三天研究才解決，或者還未解決，是以在各項任務時間的估計上精度不是大。
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
現在還沒有進行測試，感覺人力上還是不夠的，沒有更加專業的人員，大家都是從起點開始一邊學習一邊完成的，力量還不是特别大。還好吧。
4. 你有沒有感到你做的事情可以讓别人來做（更有效率）?
團隊成員現在擁有的能力還是不夠的，如果讓能力更強的人來做，當然會更有效率。
合理配置設定好每個人力資源。
變更管理
1. 每個相關的員工都及時知道了變更的消息?
有團隊的群聊，消息傳送很友善，如果是重大的變更，會讨論研究讓每個相關人員都知道，如果隻是一些細小的，隻有負責該子產品的人知道。
2. 我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
看功能的複雜程度，按照項目的計劃安排，一般從使用app的習慣順序來進行功能實作的排序，決定必須實作的功能，如果是一些比較複雜的子產品，這個階段感覺來不及完成的，就推遲了。
3. 項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
emmmm，沒有清晰的定義，覺得實作的功能和預想的差不多，然後在測試環節沒有什麼出錯，就感覺做好了吧。
4. 對于可能的變更是否能制定應急計劃?
盡自己所能制定。
5. 員工是否能夠有效地處理意料之外的工作請求？
經驗不足，不能有效處理，耗費的時間較多。
在項目的完成過程中，肯定會發生一些意外，不得不對項目某些子產品進行變更，但是處理卻不夠有效率。會先預想有什麼可能發生的變更，制定相應的應急計劃。
設計/實作
1. 設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
在項目開始的初期，由團隊成員分工共同完成，要先設計再實作功能，是以時間應該合适吧，因為都是新手，是以合不合适還需要時間磨合。
2. 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
沒有遇到什麼比較模棱兩可的情況
3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？ 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
還沒有運用單元測試和測試驅動的開發。有利用UML幫助設計，将設計都梳理了一遍，但是在開發的過程中也很少利用它了，通過安排表完成任務更加清晰一些。UML文檔沒有什麼變化。
4. 什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
現在功能内容還比較少，産生的bug主要是資料顯示上有問題，代碼方面有問題，在研究中。
5. 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
現階段還沒有進行代碼複審，代碼規範上每個人都有自己的編碼習慣，沒有在一開始就制定嚴格的代碼規範。
在實作的一開始就要制定嚴格的代碼規範，在之後的整合過程中才能避免出現更多問題。
測試/釋出
1. 團隊是否有一個測試計劃？為什麼沒有？
現在還沒有測試計劃，因為項目還沒有開發完全，就沒有去想測試的事情。
2. 是否進行了正式的驗收測試？
沒有
團隊的角色，管理，合作
1. 團隊的每個角色是如何确定的，是不是人盡其才？
是在項目開發過程中慢慢确定的，邊學邊做，談不上每個人有什麼特别的才。
2. 團隊成員之間有互相幫助麼？
有的
3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
分析問題，然後進行讨論，看問題出現的原因，商議後共同解決問題。
配置設定好每個團隊成員的角色，對每個人的任務有清晰的定義，讓項目的分工更加明确，才能更好的進行，加強溝通和交流。
總結:
你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
CMM
你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
磨合
你覺得目前最需要改進的一個方面是
團隊每個成員的分工需要更加細緻一些。
對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
1、以有進取心的人為項目核心，充分支援并信任他們
我們的組長非常有進取心，我們非常支援信任她，組長經常用她的進取心來感染我們，鼓勵我們繼續前行！
2、無論團隊内外，面對面的交流始終是最有效的溝通方式
在項目的開發過程中，我們每一天都有進行面對面的溝通交流，了解每一個成員所遇到的問題，并一起解決。
