設想和目標
- 我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
答：在校生實習管理問題，清楚，面向圖書館四樓實習生和格微教師
2.是否有充足的時間來做計劃
答：是
3.團隊在計劃階段是如何解決同事們對于計劃的不同意見的？用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
答：圍繞著前后端商討。意見不統一進行組員商討
計劃
- 你原計劃的工作是否最后都做完了? 如果有沒做完的，為什么?
答：做完了
2.有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
答：沒
3.是否每一項任務都有清楚定義和衡量的交付件?
答：任務定義清楚
4.是否項目的整個過程都按照計劃進行，有什么風險是當時沒有估計到的，為什么沒有估計到?
答：并未完全按照計劃，因為有時候換了一種更方便的方法去完成任務
5.在計劃中有沒有留下緩沖區，緩沖區有作用么?
答：沒有
6.將來的計劃會做什么修改？（例如：緩沖區的定義，加班）
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
答：對代碼進行重構簡化，學會了分工合作團隊配合
資源
- 我們有足夠的資源來完成各項任務么?
答：有
2.各項任務所需的時間和其他資源是如何估計的，精度如何?
答：我們每個人之前都完成過與項目類似的功能，大致相同
3.測試的時間，人力和軟件/硬件資源是否足夠? 對于那些不需要編程的資源 (美工設計/文案)是否低估難度?
答：測試時間不足，有部分功能測試的次數較少，可能還有未發現的bug
4.你有沒有感到你做的事情可以讓別人來做（更有效率）?有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
答：沒什么感覺
變更管理
- 每個相關的員工都及時知道了變更的消息?
答：是
2.我們采用了什么辦法決定“推遲”和“必須實現”的功能?
答：開會商討決定
3.項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?
答：沒有
4.對于可能的變更是否能制定應急計劃?
答：沒有
5.員工是否能夠有效地處理意料之外的工作請求？我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
答：可以處理，學到了管理代碼，會改進代碼的完整度
設計 實現
- 設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
答：在剛開始pm設計的，是
2.設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
答：在群里商討，最后決定
3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？
答：是，測試前后臺的數據可用性，有效
4.什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
答：修改時的bug最多，數據交互上不嚴謹
5.代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
答：沒有，會執行代碼規范
測試 發布
- 團隊是否有一個測試計劃？為什么沒有？
答：有，有徐亮和陳德強對項目進行測試
2.是否進行了正式的驗收測試？
答：2組的有3組的沒有
3.團隊是否有測試工具來幫助測試？
答：有
4.團隊是如何測量并跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
答：多次測試出來的，有些還是有用的，應該精簡一些
5.在發布的過程中發現了哪些意外問題？我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
答：遠程到本地的時候有更簡單的方法，會進行git的深入學習
總結:
- 你覺得團隊目前的狀態屬于 CMM/CMMI 中的哪個檔次?
- 答：CMMI一級
- 你覺得團隊目前處于 萌芽/磨合/規范/創造 階段的哪一個階段?
- 答：萌芽
- 你覺得團隊在這個里程碑相比前一個里程碑有什么改進?
- 答：代碼更完整嚴謹
- 你覺得目前最需要改進的一個方面是什么?
- 答：代碼的精簡
感謝：
團隊在出現bug時會認真負責修改進行討論，不會推脫。
浙公網安備 33010602011771號