第一次迭代基本情況
阿新 • • 發佈：2018-12-08
設想和目標
- 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
- 慢阻肺患者病情跟蹤以及醫患溝通問題
- 典型使用者：慢阻肺患者和醫治慢阻肺的醫生
- 典型場景：家庭
- 我們達到目標了麼（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)?
- 原計劃功能：醫生和患者端登入註冊，患者端醫生端能夠交流，患者端接收護理計劃，醫生端能夠釋出護理計劃
- 實現情況：
- 模組都有，但是有些模組未整合
- 部分地方的修改沒有提示，使用者體驗會比較差
- 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
- 暫未投入使用，使用者實際接受成度未知
- 產品完成度一般，離目標有差距，在第二次迭代中需要做好
- 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
- 整體實現難度大，如果重來一遍，會考慮換個專案
計劃
- 是否有充足的時間來做計劃?
- 計劃總是趕不上變化，最開始的計劃根據進度不斷調整
- 臨近第一次迭代仍有許多功能未實現，臨時趕工無法確保質量
- 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
- 計劃階段討論比較順利，但是一旦出現問題難以統一意見，往往留到之後討論
- 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
- 差不多都完成了
- 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
- 環境配置了很長時間，最後發現是硬碟空間不夠的問題
- 是否每一項任務都有清楚定義和衡量的交付件?
- 沒有，大家都在一起做，溝通都很及時，沒有絕對標準，標準隨時溝通調整
- 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
- 沒有完全按照計劃進行，計劃總是調整中
- 對於工作量的把控不到位，導致前端的程式碼完成時間延後
- 風險主要是時間問題，當然也估計到了
- 在計劃中有沒有留下緩衝區，緩衝區有作用麼?
- 沒怎麼感覺到緩衝區的存在
- 應該有用，但是沒有體驗到
- 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
- 在團隊合作方面，團隊儘量在一起工作
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
- 在團隊的合作中，收穫了很多課程以外的東西
- 如果能重來，要提高效率和溝通，儘量使整合程式碼的時間提前，留出多的時間應對問題
資源
- 我們有足夠的資源來完成各項任務麼?
- 時間限制，沒有做的很好
- 各項任務所需的時間和其他資源是如何估計的，精度如何?
- 時間主要是按任務量估計，時間按各自的安排估計
- 精度不好，不能總是保持高效且時間安排總會有意外的衝突
- 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
- 測試沒有系統、詳細的安排，在最終整合的時候出了些問題，倒是測試做的不是很好
- 人力資源足夠
- UI介面的設計基本沒有考慮，應該會在第二次迭代中中美化
- 你有沒有感到你做的事情可以讓別人來做（更有效率）?
- 沒有
- 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
- 分工不夠仔細、明確，對大家配合效率有一定影響
- 還有整合的問題，不要等到最後在整合，我覺得應該做一部分整合一部分
變更管理
- 每個相關的員工都及時知道了變更的訊息?
- 是的
- 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
- 根據複雜度和功能是否是核心功能
- 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
- 能完成主要功能並適當美化介面
- 對於可能的變更是否能制定應急計劃?
- 沒有提前制定應急計劃，但有變更時會及時做出反應和調整
- 員工是否能夠有效地處理意料之外的工作請求？
- 應該能及時調整
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
- 一起工作真的很重要！！！
設計/實現
- 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
- 整個模式的設計是在專案初期，由全隊成員和老師溝通商定的
- 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
- 沒有
- 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？
- 有UML圖來幫助設計，也有很多的設計素材網站為我們提供了很多圖片素材
- 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
- 文件更加豐富了，會在專案推進中，不斷完善、更新文件
- 什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
- SQL語句方面，沒有時候會出現沒寫對的情況
- 還沒有釋出
- 因為感覺會寫語句，就沒有太仔細
- 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
- 現階段沒有執行程式碼複審，有一定的程式碼規範
測試/釋出
- 團隊是否有一個測試計劃？為什麼沒有？
- 沒有詳細的測試計劃
- 是否進行了正式的驗收測試？
- 否
- 團隊是否有測試工具來幫助測試？
- 暫未考慮
- 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
- 暫未考慮
- 在釋出的過程中發現了哪些意外問題？
- 暫未考慮
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
- 還是以完成專案功能為首要任務，測試方面暫時沒有精力、時間考慮
團隊的角色，管理，合作
- 團隊的每個角色是如何確定的，是不是人盡其才？
- 團隊角色確定，以尊重個人意願為首要因素，再根據實際情況協商確定角色
- 團隊成員之間有互相幫助麼？
- 當然
- 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
- 共同應對，共同商討解決
總結
- 你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
- 屬於CMMI一級，完成級
- 你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
- 磨合基本完成
- 你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?
- 大家彼此更加熟悉，互相的配合會比之前更有效率
- 你覺得目前最需要改進的一個方面是什麼?
- 沒有什麼特別大的錯誤，不過可能可以在程式碼分塊中再細緻點，使得程式碼的可讀性和可維護性更高
- 程式碼規範，養成良好的編碼習慣
- 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
- 慢阻肺患者病情跟蹤以及醫患溝通問題
- 典型使用者：慢阻肺患者和醫治慢阻肺的醫生
- 典型場景：家庭
- 我們達到目標了麼（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)?
- 原計劃功能：醫生和患者端登入註冊，患者端醫生端能夠交流，患者端接收護理計劃，醫生端能夠釋出護理計劃
- 實現情況：
- 模組都有，但是有些模組未整合
- 部分地方的修改沒有提示，使用者體驗會比較差
- 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
- 暫未投入使用，使用者實際接受成度未知
- 產品完成度一般，離目標有差距，在第二次迭代中需要做好
- 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
- 整體實現難度大，如果重來一遍，會考慮換個專案
計劃
- 是否有充足的時間來做計劃?
- 計劃總是趕不上變化，最開始的計劃根據進度不斷調整
- 臨近第一次迭代仍有許多功能未實現，臨時趕工無法確保質量
- 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
- 計劃階段討論比較順利，但是一旦出現問題難以統一意見，往往留到之後討論
- 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
- 差不多都完成了
- 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
- 環境配置了很長時間，最後發現是硬碟空間不夠的問題
- 是否每一項任務都有清楚定義和衡量的交付件?
- 沒有，大家都在一起做，溝通都很及時，沒有絕對標準，標準隨時溝通調整
- 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
- 沒有完全按照計劃進行，計劃總是調整中
- 對於工作量的把控不到位，導致前端的程式碼完成時間延後
- 風險主要是時間問題，當然也估計到了
- 在計劃中有沒有留下緩衝區，緩衝區有作用麼?
- 沒怎麼感覺到緩衝區的存在
- 應該有用，但是沒有體驗到
- 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
- 在團隊合作方面，團隊儘量在一起工作
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
- 在團隊的合作中，收穫了很多課程以外的東西
- 如果能重來，要提高效率和溝通，儘量使整合程式碼的時間提前，留出多的時間應對問題
資源
- 我們有足夠的資源來完成各項任務麼?
- 時間限制，沒有做的很好
- 各項任務所需的時間和其他資源是如何估計的，精度如何?
- 時間主要是按任務量估計，時間按各自的安排估計
- 精度不好，不能總是保持高效且時間安排總會有意外的衝突
- 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
- 測試沒有系統、詳細的安排，在最終整合的時候出了些問題，倒是測試做的不是很好
- 人力資源足夠
- UI介面的設計基本沒有考慮，應該會在第二次迭代中中美化
- 你有沒有感到你做的事情可以讓別人來做（更有效率）?
- 沒有
- 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
- 分工不夠仔細、明確，對大家配合效率有一定影響
- 還有整合的問題，不要等到最後在整合，我覺得應該做一部分整合一部分
變更管理
- 每個相關的員工都及時知道了變更的訊息?
- 是的
- 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
- 根據複雜度和功能是否是核心功能
- 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
- 能完成主要功能並適當美化介面
- 對於可能的變更是否能制定應急計劃?
- 沒有提前制定應急計劃，但有變更時會及時做出反應和調整
- 員工是否能夠有效地處理意料之外的工作請求？
- 應該能及時調整
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
- 一起工作真的很重要！！！
設計/實現
- 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
- 整個模式的設計是在專案初期，由全隊成員和老師溝通商定的
- 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
- 沒有
- 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？
- 有UML圖來幫助設計，也有很多的設計素材網站為我們提供了很多圖片素材
- 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
- 文件更加豐富了，會在專案推進中，不斷完善、更新文件
- 什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
- SQL語句方面，沒有時候會出現沒寫對的情況
- 還沒有釋出
- 因為感覺會寫語句，就沒有太仔細
- 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
- 現階段沒有執行程式碼複審，有一定的程式碼規範
測試/釋出
- 團隊是否有一個測試計劃？為什麼沒有？
- 沒有詳細的測試計劃
- 是否進行了正式的驗收測試？
- 否
- 團隊是否有測試工具來幫助測試？
- 暫未考慮
- 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
- 暫未考慮
- 在釋出的過程中發現了哪些意外問題？
- 暫未考慮
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
- 還是以完成專案功能為首要任務，測試方面暫時沒有精力、時間考慮
團隊的角色，管理，合作
- 團隊的每個角色是如何確定的，是不是人盡其才？
- 團隊角色確定，以尊重個人意願為首要因素，再根據實際情況協商確定角色
- 團隊成員之間有互相幫助麼？
- 當然
- 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
- 共同應對，共同商討解決
總結
- 你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
- 屬於CMMI一級，完成級
- 你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
- 磨合基本完成
- 你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?
- 大家彼此更加熟悉，互相的配合會比之前更有效率
- 你覺得目前最需要改進的一個方面是什麼?
- 沒有什麼特別大的錯誤，不過可能可以在程式碼分塊中再細緻點，使得程式碼的可讀性和可維護性更高
- 程式碼規範，養成良好的編碼習慣