思考總結
設想和目標
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語言或者j**a**，基本上都不用我們自己動手寫**了，我也是上課聽老師講了以後才知道了，那時候呀，腸子都悔青了，白白做了好幾周的**塊框架居然就被老師畫幾張圖，給搞定了。。。。。。嗚嗚嗚嗚嗚嗚
設計/實現
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 中的哪個檔次?
5、你覺得團隊目前處於
萌芽/磨合/規範/創造
階段的哪乙個階段?
規範吧6、你覺得團隊在這個里程碑相比前乙個里程碑有什麼改進?
大家彼此更加熟悉，互相的配合會比之前更有效率
7、你覺得目前最需要改進的乙個方面是什麼?
專案經驗不足，做事效率不高
小組成員合作不夠緊密（可能與專案內容有關係）
時間太緊，想要在16周的時間內從需求分析->資料庫設計->迭代開發，要做出乙個工業級的專案不太可能，不過我們都還算熟悉了整個做專案的流程，積累了經驗吧！！！
我的第乙個敏捷專案總結
2016年11月開始了休長假回來後的第乙個專案。也是我職業生涯中的第乙個敏捷專案。本人在專案中擔任需求分析。專案啟動已經五個多月，目前一切執行樂觀。閒來覺得有必要總結下人生中第乙個敏捷專案，於它人可以取良去莠，於自己可以沉澱一二。回想一下之前做過的專案都是用瀑布 迭代。需求收集用瀑布。即盡量在需求收...
我的第乙個hbulider專案
7月3日實訓第一天 實訓內容 五子棋遊戲 達州的天氣真的不是一般的熱，分分鐘就可以把人熱化，就這樣我們帶著沉重的腳步開始了我們第一天的實訓，老師叫李胤，剛開始我還不知道這個字怎麼讀，很尷尬啊，是乙個比較幽默的老師，希望和老師有乙個愉快的實訓。我們學習h5，說實話我們之前還沒有接觸過h5 學的還是基本...
我的第乙個PyQt專案
環境 python 3.6.0 pyqt5.9.1 pycharm 功能 1.選單欄 有control和help兩個選項 2.狀態列 3.退出詢問 import sys from pyqt5.qtgui import from pyqt5.qtwidgets import class mainwin...