1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
單個系統的部分功能 是 是
2. 我們達到目標了麼（原計畫的功能做到了幾個？ 按照原計畫交付時間交付了麼？ 原計畫達到的使用者數量達到了麼?)
完成原計畫第一部分的需求
3. 和上乙個階段相比，團隊軟體工程的質量提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？
沒，都在忙其他事，沒心思在完成下一階段（關鍵功能沒能實現）
4. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
還沒正式上線，原系統未發布，在小範圍內部測試
選個自己的題目，從頭做起，才好做下去。
1. 是否有充足的時間來做計畫?
有2. 團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
統一管理，各自完成
3. 你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
原定第一階段完成，後續都沒心思做了（原系統不是自己的，下階段需要的功能技術為實現，都忙自己的事去了）
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
在部分功能實現方式多樣的情況下，沒有就簡單實用完成。考慮太多（或許）
5. 是否每一項任務都有清楚定義和衡量的交付件?
否6. 是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
整個流程還是找預定計畫完成的。在完成乙個階段的任務後。後續的任務都定義為可有可無的狀態
7. 在計畫中有沒有留下緩衝區，緩衝區有作用麼?
有 有
8. 將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
技術人員有意向繼續，那就繼續
1. 我們有足夠的資源來完成各項任務麼?
沒2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
按任務點估計，不計時
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
是 否
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
沒
變更管理
1. 每個相關的員工都及時知道了變更的訊息?
是2. 我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
pm一言而定
3. 專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
有4. 對於可能的變更是否能制定應急計畫?
是5. 員工是否能夠有效地處理意料之外的工作請求？
否1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
三人分工，設計由pm完成 時間夠，人選屬於矮個子裡挑高的
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
有 能完成就好，那個快選哪個
3. 團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？ 比較專案開始的 uml 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 uml 文件？
有 簡單的uml圖能夠快速反映功能點的劃分 沒怎麼變化（第一階段）
4. 什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
js指令碼 瀏覽器版本相容 沒
5. **複審（code review）是如何進行的，是否嚴格執行了**規範？
pm進行 算是
1. 團隊是否有乙個測試計畫？為什麼沒有？
沒 沒有實際意義上的函式 無法進行單元測試
2. 是否進行了正式的驗收測試？
是3. 團隊是否有測試工具來幫助測試？
否4. 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
沒進行5. 在發布的過程中發現了哪些意外問題？
未發布1. 團隊的每個角色是如何確定的，是不是人盡其才？
不算，本團隊沒有前端人員
2. 團隊成員之間有互相幫助麼？
有3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
pm統一解決
每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的部落格裡）：
你覺得團隊目前的狀態屬於 cmm/cmmi 中的哪個檔次?
初始級你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段?
萌芽你覺得團隊在這個里程碑相比前乙個里程碑有什麼改進?
沒有你覺得目前最需要改進的乙個方面是什麼?
執行力對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
沒有部落格要附上全組討論的**。
團隊成員在beta階段的角色和具體貢獻：
姓名角色
貢獻值%
吳吉鍵pm
45孫勁林
後端39
魏修祺前端
16
團隊作業9 事後分析（Beta版本）
設想和目標 能監聽手機的來電事件，同時對歌詞檔案的獲取時常會不顯示這個功能未能完善。只按照原計畫交了乙個比較完善的版本。因為這個專案對我們組來說是屬於學習的階段，所以還達不到上線的程度，自然，原計畫的使用者數量沒有達到。跟上乙個階段相比，團隊的開發效率明顯 提高了，分工也更明確了。出錯，因為第二階段...
團隊作業10 複審與事後分析（Beta版本）
2017 6 13 22 00pm，以部落格發表日期為準 晚交 0分 遲交一周以上 倒扣本次作業分數 抄襲 倒扣本次作業分數 以每個班級為單位，每個複審人看本班級其餘團隊的總結展示部落格，以及 質量，實際測試結果，決定名次 沒有並列 說明專案的優點和缺點分析 不少於 140 字 複審人看什麼 複審怎...
團隊作業6 事後分析
每個人都會遇到大大小小的問題，解決這些問題只有當面交流，現場除錯修改的效率才是最高的。我們五個人都是第一次做這種專案類的挑戰，我們明顯覺得單打獨鬥是沒有用的，團結就是力量，每個人的鼓勵都是這個外賣軟體前進的每一步。計畫是否有充足的時間來做計畫?不太夠，後面遇到一些，例如後台管理評價系統有些不太懂，又...