商品銷量分析及預測 

設想和目標

1.    我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？

·         解決銷售商通過app即時掌控銷量及其預測分析的問題

·         典型使用者：零售商

2.    我們達到目標了麼（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)?

·         原計劃功能：app上實現登入查詢分析預測

·         實現情況：基本實現

3.    使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?

·         未投入使用，功能幾乎幾乎實現，倒是介面可能不合口味

4.    有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

　　　對於剩下的功能不能盲目樂觀

　　   在不熟知的領域需要謹慎，不然可能會在某一個bug上卡很久

計劃

1.    是否有充足的時間來做計劃?

·         後臺任務安排時間足夠並幫助前端同學查詢一些資料

2.    團隊在計劃階段是如何解決同事們對於計劃的不同意見的？

·         計劃階段很順利，因為大家一開始都不懂各方面要做啥

3.    你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

·         趕在alpha版本驗收前完成

4.    有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

·         在挑選框架時對比了很多雜七雜八的框架，沒必要，都差不多

5.    是否每一項任務都有清楚定義和衡量的交付件?

·         有，因為前後端需要連線埠，所以平時交流標準很多

6.    是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

·         一開始對於安卓等啥都不懂，所以計劃幾乎無效

7.    在計劃中有沒有留下緩衝區，緩衝區有作用麼?

·        有，大量工作基本都在這個緩衝區完成

8.    將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）

·        儘量提前完成，不能把deadline作為最終完成時間

資源

1.    我們有足夠的資源來完成各項任務麼?

·         有，同學們對學習的熱情

2.    各項任務所需的時間和其他資源是如何估計的，精度如何?

·        最初估計基本是錯誤的。

3.    測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?

·         測試和程式設計同步進行，實現一個功能就測試一次

·         資源倒是足夠

·         UI介面開始比較醜陋，後來有所改進。

4.    你有沒有感到你做的事情可以讓別人來做（更有效率）?

·         沒有，我算是最有效率的那一個

5.    有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

·         還是實力不夠，大部分時間都在學怎麼處理bug

變更管理

1.    每個相關的員工都及時知道了變更的訊息?

·         是的

2.    我們採用了什麼辦法決定“推遲”和“必須實現”的功能?

·         是否核心，達到測試標準

3.    專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

·         基本測試通過

4.    對於可能的變更是否能制定應急計劃?

·        應該說全靠應急計劃

5.    員工是否能夠有效地處理意料之外的工作請求？

·         是

6.    我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

·         在不知情的情況下儘量留下足夠的時間來緩衝

設計/實現

1.    設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？

·        隊員和老師共同設計完成。

2.    設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？

·         有，統一標準即可。

3.    團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？

·        主要是uml圖幫助設計

4.    比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？

·         更加豐富

5.    什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

·         基本無BUG。

6.    程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？

·         信任隊員，有一定的程式碼規範

測試/釋出

1.    團隊是否有一個測試計劃？為什麼沒有？

·         有詳細的測試計劃，每個功能都全方面測試

2.    是否進行了正式的驗收測試？

·         是

3.    團隊是否有測試工具來幫助測試？

·        無

4.    團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？

·        無

5.    在釋出的過程中發現了哪些意外問題？

·         打包問題

 

團隊的角色，管理，合作

1.    團隊的每個角色是如何確定的，是不是人盡其才？

·         有相應經驗的首先分配，其餘再按量分配

2.    團隊成員之間有互相幫助麼？

·         有

3.    當出現專案管理、合作方面的問題時，團隊成員如何解決問題？

·         互幫互助，查閱資料完成

總結

1.    你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?

·         屬於CMMI一級，完成級

2.    你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?

·         規範階段

3.    你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?

·         整體程式設計實力有所提升，專業領域相應提高

4.    你覺得目前最需要改進的一個方面是什麼?

·         程式碼規範，養成良好的編碼習慣

設想和目標

1.    我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？

·         解決銷售商通過app即時掌控銷量及其預測分析的問題

·         典型使用者：零售商

2.    我們達到目標了麼（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)?

·         原計劃功能：app上實現登入查詢分析預測

·         實現情況：基本實現

3.    使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?

·         未投入使用，功能幾乎幾乎實現，倒是介面可能不合口味

4.    有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

　　　對於剩下的功能不能盲目樂觀

　　   在不熟知的領域需要謹慎，不然可能會在某一個bug上卡很久

計劃

1.    是否有充足的時間來做計劃?

·         後臺任務安排時間足夠並幫助前端同學查詢一些資料

2.    團隊在計劃階段是如何解決同事們對於計劃的不同意見的？

·         計劃階段很順利，因為大家一開始都不懂各方面要做啥

3.    你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

·         趕在alpha版本驗收前完成

4.    有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

·         在挑選框架時對比了很多雜七雜八的框架，沒必要，都差不多

5.    是否每一項任務都有清楚定義和衡量的交付件?

·         有，因為前後端需要連線埠，所以平時交流標準很多

6.    是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

·         一開始對於安卓等啥都不懂，所以計劃幾乎無效

7.    在計劃中有沒有留下緩衝區，緩衝區有作用麼?

·        有，大量工作基本都在這個緩衝區完成

8.    將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）

·        儘量提前完成，不能把deadline作為最終完成時間

資源

1.    我們有足夠的資源來完成各項任務麼?

·         有，同學們對學習的熱情

2.    各項任務所需的時間和其他資源是如何估計的，精度如何?

·        最初估計基本是錯誤的。

3.    測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?

·         測試和程式設計同步進行，實現一個功能就測試一次

·         資源倒是足夠

·         UI介面開始比較醜陋，後來有所改進。

4.    你有沒有感到你做的事情可以讓別人來做（更有效率）?

·         沒有，我算是最有效率的那一個

5.    有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

·         還是實力不夠，大部分時間都在學怎麼處理bug

變更管理

1.    每個相關的員工都及時知道了變更的訊息?

·         是的

2.    我們採用了什麼辦法決定“推遲”和“必須實現”的功能?

·         是否核心，達到測試標準

3.    專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

·         基本測試通過

4.    對於可能的變更是否能制定應急計劃?

·        應該說全靠應急計劃

5.    員工是否能夠有效地處理意料之外的工作請求？

·         是

6.    我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

·         在不知情的情況下儘量留下足夠的時間來緩衝

設計/實現

1.    設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？

·        隊員和老師共同設計完成。

2.    設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？

·         有，統一標準即可。

3.    團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？

·        主要是uml圖幫助設計

4.    比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？

·         更加豐富

5.    什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

·         基本無BUG。

6.    程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？

·         信任隊員，有一定的程式碼規範

測試/釋出

1.    團隊是否有一個測試計劃？為什麼沒有？

·         有詳細的測試計劃，每個功能都全方面測試

2.    是否進行了正式的驗收測試？

·         是

3.    團隊是否有測試工具來幫助測試？

·        無

4.    團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？

·        無

5.    在釋出的過程中發現了哪些意外問題？

·         打包問題

 

團隊的角色，管理，合作

1.    團隊的每個角色是如何確定的，是不是人盡其才？

·         有相應經驗的首先分配，其餘再按量分配

2.    團隊成員之間有互相幫助麼？

·         有

3.    當出現專案管理、合作方面的問題時，團隊成員如何解決問題？

·         互幫互助，查閱資料完成

總結

1.    你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?

·         屬於CMMI一級，完成級

2.    你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?

·         規範階段

3.    你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?

·         整體程式設計實力有所提升，專業領域相應提高

4.    你覺得目前最需要改進的一個方面是什麼?

·         程式碼規範，養成良好的編碼習慣