思考總結

設想和目標

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

　　我們軟體很明確的定義為，製作一個變電站向量圖形編輯器

　　典型使用者：變電站管理員

　　典型場景：------

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

　　原計劃功能：對現實中的變電站實現一個建模管理，每一個虛擬的元器件都能夠實現背後的資料聯動，動態更新，監測

　　實現情況：

　　能夠對元器件進行建模

　　1)對編輯器編輯的圖形進行開啟與儲存，只是存入資料庫以及從資料庫中解析出資料部分還沒實現

　　2)最難的資料聯動部分暫未實現

　　3)軟體功能基本實現，但實際投入使用存在困難，暫時無法投入使用

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

　　1)暫未投入使用，使用者實際接受成度未知

　　2)產品完成度好，當然離目標更近了

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

　　1)整體實現難度大，如果重來一遍，會考慮換個專案

　　2)小組成員之間的金誠合作才是關鍵

　　3)開發過程中需要提交一些很繁瑣的文件（周總結、周計劃、迭代開發計劃等等等燈），感覺不需要這些文件也能夠開發軟體

　　4)我們在剩下的幾周時間裡，一定會加班加點，加倍努力。。。。。。

計劃

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

　　1）計劃總是趕不上變化，最開始的計劃根據進度不斷調整，到最後就拋棄了計劃，趕+肝

　　2）時間就像是海綿裡的水，擠一擠總會有的，關鍵是要對自己夠狠。。。。。。

　　3）而且大部分時間不是在做計劃，一共16周，主要還是要用在軟體開發（碼程式碼）上面

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

　　1）有不同的意見是好事，小組討論的時候，多多交流，溝通是解決分歧的最佳方法，可能更好的idea會因此應運而生

　　2）當然也可以求同存異。。。。。。

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

　　並沒有全部做完

　　因為時間、空間、人力、物力、財力等因素，最主要是沒時間以及開發過程中踩到的地雷（BUG），需要不斷的拆地雷，還要反覆測試地雷是否真的拆除成功，會不會還有爆炸的可能

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

　　有！  比如提交開發的過程文件  寫各種計劃之類的

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

　　沒有，大家都在一起做，溝通都很及時，沒有絕對標準，標準隨時溝通調整，大家都覺得ok就直接整合對接

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

　　沒有完全按照計劃進行，計劃總是調整中

　　前端介面在一開始的設計不夠規範，後期實施中很多介面不得不推翻重做

　　風險主要是熬夜+時間，當然也估計到了

　　另一個風險就是發現遇到了怎麼也調不通的BUG，不調好可能也沒辦法繼續往下做了，浪費大量的時間，到時專案無法按期完工

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

　　有緩衝區：睡眠+翹課

　　有用，deadline前的效率都相當高，有時間就有產出

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

　　學期只剩下不到四周時間了，當然會踏踏實實的乾點實事，加倍努力。

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

　　在團隊的合作中，收穫了很多課程以外的東西，很重要但不好描述

　　基本瞭解並參與了整個小程式的開發流程

　　如果能重來，要提高效率和溝通，避免不必要的熬夜

　　學習到以專案程序和作業deadline，來驅動自己學習。

　　如果能重來，我要做前端

　　如果能重來，會全面、有條理、計劃地學習小程式開發

　　如果能重來，會選擇專注前端製作，好好學習

　　如果能重來，我一定拉個隊友，不想一個人剛了，同時也會提高自己的學習效率

　　如果歷史重來一遍 我會換一個新專案 或者換一個專業 專注賣滷菜。。。。。。

資源

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

　　我們完成了任務，但時間和資金的資源限制，沒有做到完美

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

　　時間主要是按任務量估計，時間按各自的安排估計

　　精度不好，不能總是保持高效且時間安排總會有意外的衝突

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

　　測試沒有系統、詳細的安排，在最終整合之後，有做了簡單的測試，沒有花費很多時間

　　人力資源嚴重缺乏（我們組的人數本來就少）

　　美工是做的很不好的一點，在後期實施上出了很多問題，低估了難度

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

　　這個問題很挑事兒，沒有問大家

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

　　開發前一定去多找一些特別方便好用的工具 比如powerdesigner  ，設計完資料庫可以自動幫我們生成UML圖的C語言或者java程式碼，基本上都不用我們自己動手寫程式碼了，我也是上課聽老師講了以後才知道了，那時候呀，腸子都悔青了，白白做了好幾周的程式碼塊框架居然就被老師畫幾張圖，給搞定了。。。。。。嗚嗚嗚嗚嗚嗚

設計/實現

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

　　整個模式的設計是在專案初期，由pm和老師溝通商定的

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

　　有 當然有 小組交流討論 誰有道理聽誰的  很民主吧

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

　　文件更加豐富了，會在專案推進中，不斷完善、更新文件

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

　　畫圖編輯過程中的BUG最多  我們用的是MFC框架 加上很多的圖形使用者介面（GUI）實現的繪圖，經常會出現資源申請失敗的Asstion Failed執行錯誤 或者 指標帶來的痛苦。。。。。。

　　還沒有釋出

　　有想到，但確實無法申請，但在軟工角度來講，這只是其中一個模組，不能因為這個模組放棄整個專案

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

　　現階段沒有執行程式碼複審，也沒有嚴格的程式碼規範

測試/釋出

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

　　有制定詳細的驗收標準，但沒有詳細的測試計劃

　　“完成，比完美更重要”，現階段已完成專案為主

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

　　否 但是進行了中期驗收

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

　　暫未考慮

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

　　暫未考慮

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

　　還是以完成專案功能為首要任務，測試方面暫時沒有精力、時間考慮

團隊的角色，管理，合作

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

　　團隊角色確定，以尊重個人意願為首要因素，再根據實際情況協商確定角色

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

　　當然，每天的工作都是和諧友愛、互幫互助的~

　　每週都要進行小組會議 交流討論學習心得 

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

　　作為組長，有責任更有義務管理好整個團隊，這是金誠合作，能夠開發出一款很好的軟體的前提，只有成員之間都能夠互幫互助，團結起來，才能夠匯聚成一股力量，最終爆發出來，璀璨奪目。

總結

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

　　（百度才知道這一問什麼意思。。。）屬於CMMI一級，完成級

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

　　規範吧

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

　　大家彼此更加熟悉，互相的配合會比之前更有效率

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

　　專案經驗不足，做事效率不高

　　小組成員合作不夠緊密（可能與專案內容有關係）

　　時間太緊，想要在16周的時間內從需求分析->資料庫設計->迭代開發，要做出一個工業級的專案不太可能，不過我們都還算熟悉了整個做專案的流程，積累了經驗吧！！！