組成部分 | 檢查項 | 分數 | 編号 |
設想和目标 | 我們的軟體要解決什麼問題?是否定義得很清楚?是否對典型使用者和典型場景有清晰的描述? | 0.6 | 1 |
和上一個階段相比,團隊軟體工程的品質提高了麼? 在什麼地方有提高?具體提高了多少?如何衡量的? | 0.8 | 2 |
我們達到目标了麼(原計劃的功能做到了幾個? 按照原計劃傳遞時間傳遞了麼? 原計劃達到的使用者數量達到了麼?) | 1.5 | 3 |
使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼? | 0.5 | 4 |
計劃 | 是否有充足的時間來做計劃? | 0.2 | 5 |
團隊在計劃階段是如何解決同僚們對于計劃的不同意見的? | | 6 |
你原計劃的工作是否最後都做完了? 如果有沒做完的,為什麼? | | 7 |
有沒有發現你做了一些事後看來沒必要或沒多大價值的事? | | 8 |
是否每一項任務都有清楚定義和衡量的傳遞件? | | 9 |
是否項目的整個過程都按照計劃進行,項目出了什麼意外?有什麼風險是當時沒有估計到的,為什麼沒有估計到? | | 10 |
在計劃中有沒有留下緩沖區,緩沖區有作用麼? | | 11 |
将來的計劃會做什麼修改?(例如:緩沖區的定義,加班) | | 12 |
資源 | 我們有足夠的資源來完成各項任務麼? | | 13 |
各項任務所需的時間和其他資源是如何估計的,精度如何? | | 14 |
測試的時間,人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度? | | 15 |
你有沒有感到你做的事情可以讓别人來做(更有效率)? | | 16 |
變更管理 | 每個相關的員工都及時知道了變更的消息? | | 17 |
我們采用了什麼辦法決定“推遲”和“必須實作”的功能? | | 18 |
項目的出口條件(Exit Criteria – 什麼叫“做好了”)有清晰的定義麼? | | 19 |
對于可能的變更是否能制定應急計劃? | | 20 |
員工是否能夠有效地處理意料之外的工作請求? | | 21 |
設計/實作 | 設計工作在什麼時候,由誰來完成的?是合适的時間,合适的人麼? | | 22 |
設計工作有沒有碰到模棱兩可的情況,團隊是如何解決的? | | 23 |
團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其他工具來幫助設計和實作?這些工具有效麼? | | 24 |
什麼功能産生的Bug最多,為什麼?在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況? | | 25 |
代碼複審(Code Review)是如何進行的,是否嚴格執行了代碼規範? | | 26 |
測試/釋出 | 團隊是否有一個測試計劃? | | 27 |
是否進行了正式的驗收測試? | | 28 |
團隊是否有測試工具來幫助測試? | | 29 |
團隊是如何測量并跟蹤軟體的效能的?從軟體實際運作的結果來看,這些測試工作有用麼?應該有哪些改進? | | 30 |
在釋出的過程中發現了哪些意外問題? | | 31 |
總結 | 你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次? | | 32 |
你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段? | | 33 |
你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進? | | 34 |
你覺得目前最需要改進的一個方面是什麼? | | 35 |
對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。 | | 36 |
照片 | | 37 |
成員貢獻 | | 38 |
總分 | | 39 |