第一次迭代開發總結-創新課程管理系統

思考總結

 

　　第一次迭代開發，小組整體作出來的東西很少，與計劃相比少了很多。完成的大體有兩個半模塊，其一是登陸註冊，其二是報警信息展現，其三是工單處理，還在技術上研究了動態數據在圖表上的動態展現的實現（基於單個數據項的展現）。整體來講，不少後臺工做沒實現，前端作的頁面卻是蠻多，交互功能也有，前端的工做進度是先於後臺的；後臺開發的滯後性，以至於功能模塊的集成進度受到了阻礙。

接下來就說一說咱們組項目（創新課程管理系統）第一次迭代的心得。

 

設想和目標

一、咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？

　　咱們軟件很明確的定義爲，實現一個創新課程管理系統，開發出一個基礎版本，供下一個項目組接手並投入實際使用。

　　典型用戶：創新課程的系統管理員、學校管理員、教師、助教、學生。

　　典型場景：上軟工導論課。

二、咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)?

　　第一次迭代開發目標完成。

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

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

　　2)暫時能夠說離目標更近了

四、有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

　　項目看似簡單，實則很複雜，且要求使用框架實現，須要學習更多東西，因此。。。若是上天給我再來一次的機會，我（不）會再選這個項目。。。

 

計劃

一、是否有充足的時間來作計劃

　　有很長一部分時間都在作計劃、原型。但後來導師說要用框架，作的原型基本不能用，只能照着框架去加功能。

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

　　不一樣意見就討論，雖然原型沒什麼太大用，可是至少把需求弄清楚了。

三、你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

　　沒有所有作完

　　框架須要學的東西實在是不少，只能在第一次迭代中力所能及地實現能實現的功能。

四、有沒有發現你作了一些過後看來不必或沒多大價值的事?

　　不少，好比提交開發的過程文檔  寫各類計劃，還有過多的討論。

　　我以爲咱們應該把第一次迭代分兩次迭代進行，加快第一次上手開發的時間。

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

　　並無，每一個功能在各自版本上實現了，就git到服務器上。

　　假如後面有BUG了，那就GG。

六、是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?

　　基本沒有按計劃進行，一方面是由於咱們組太糾結於原型需求，

　　另外一方面由於導師要求用框架，致使後期交付的一週咱們整個組的心態都是崩了的。

　　由於咱們太天真可愛善良了，不懂人世間的黑暗艱難險惡。

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

　　在計劃中沒有留下緩衝區，致使開發後半段十分緊張。迭代開發驗收的前兩天，邊老師忽然在羣裏發了一份兒驗收要求，仔細一看，咱們組當時作的沒有幾條是符合要求的。因而咱們趕忙加班加點按照老師      的要求各類改代碼，找bug。這也給咱們一個教訓，不要正好卡在ddl完成項目，必定要留出充足的時間去應對各類突發狀況。幸運的是，最終驗收結果還算較爲滿意。

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

　　硬着頭皮往前衝！第一週就開始先在加功能的同時熟悉框架，第二週就突擊剩下沒有實現的功能，第三週就看看有什麼BUG沒。

九、咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

　　一、儘量快的開始迭代開發，開發週期儘量地壓縮，把精力更多地放在開發上面。

　　二、應該一開始就集體集合開發，這樣能提升整個組的效率。

 

資源

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

　　咱們有足夠的資源來完成各項任務。

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

　　各項任務所需的時間和其餘資源是經過其大體專業難度，聽取老師意見決定的。

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

　　對於那些不須要編程的資源 (美工設計/文案)沒有低估難度。

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

　　我真的一點都不想作各類文檔。。。感受很打斷我開發，各類佔時間，澆滅我開發的熱情。

五、有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

　　儘快的把要作的跟開發無關的工做作完，給開發流出足夠多的整塊的時間。

 

設計/實現

一、設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

　　由於以前大部分時間一直都在寫各類各樣的文檔，因此咱們的項目起步比較晚，真正意義上編寫代碼的時間只有不到兩個禮拜。並且，咱們當初把項目實現想得過於理想，致使後來時間有些不夠用。

二、設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？

　　設計工做碰到模棱兩可的狀況，團隊舉手表決。

三、比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

　　團隊運用UML來幫助設計和實現。工具備效。 比較項目開始的 UML 文檔和如今的狀態，發現有些邏輯在實際實現中發生了改變。須要要更新 UML 文檔。

四、什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?

　　前端頁面註冊登陸功能產生的Bug最多，由於在這個模塊中須要反覆測試各類錯誤提示。

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

　　代碼複審（Code Review）是小組間互相審查的，較爲嚴格地執行了代碼規範。

 

 

測試/發佈

一、團隊是否有一個測試計劃？爲何沒有？

　　只有簡單的進行一些數據的測試。

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

　　進行了中期驗收

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

　　暫未考慮

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

　　暫未考慮

五、咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

　　等咱們有能力完成開發了再考慮測試吧。

 

團隊的角色，管理，合做

一、團隊的每一個角色是如何肯定的，是否是人盡其才？

　　團隊的每一個角色是經過代表本身所擅長或感興趣的方面來肯定的，大體作到了人盡其才。

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

　　每次遇到問題時，團隊成員之間可以作到互相幫助。 

三、當出現項目管理、合做方面的問題時，團隊成員如何解決問題？

　　當出現項目管理、合做方面的問題時，團隊成員經過討論開會達成一致。

　　可是有一點不是很適應，由於咱們組並無全員參與開發，其實老師有一些強制性的要求對咱們組不是很公平，不過也好在咱們組內5我的都比較有凝聚力，我相信你們迎難而上咱們必定能夠定期按量地完成任務。

 

總結

四、你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?

　　屬於CMMI一級，完成級

五、你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?

　　規範

六、你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?

　　更加有效率

七、你以爲目前最須要改進的一個方面是什麼?

　　學習框架知識儘量地多開發

 

總結: 

第一次迭代開發學到了不少，主要是研究技術上的實現，沒有多少時間幫助後臺人員進行開發。可是，做爲PM，在此我不得不說，後臺的開發真的是太慢了！你們要抓緊時間，多多把任務放在心上。真心但願每一個人都是開發中，「雞與豬」故事裏的豬。