創新課程管理系統-第一次迭代開發心得
阿新 • • 發佈:2018-12-09
第一次做專案,第一次用javaee開發web工程專案,很多東西不會,摸著石頭過河,也學到了很多東西。
第一次迭代開發,小組總體做出來的東西不多,與計劃相比少了不少。完成的大致有兩個半模組,其一是登入註冊,其二是報警資訊展示,其三是工單處理,還在技術上研究了動態資料在圖表上的動態展示的實現(基於單個數據項的展示)。總體來說,很多後臺工作沒實現,前端做的頁面倒是蠻多,互動功能也有,前端的工作進度是先於後臺的;後臺開發的滯後性,以致於功能模組的整合進度受到了阻礙。
接下來就說一說我們組專案(創新課程管理系統)第一次迭代的心得。
設想和目標
1. 我們的Web專案的目的是實現一個創新課程管理系統,開發出一個基礎版本,供下一個專案組接手並投入實際使用。
2. 第一次迭代開發目標完成。
計劃
1. 有很長一部分時間都在做計劃、原型。
2. 在整個第一次迭代的過程中,我們小組先是學習guns框架,guns框架學習成本很高。再一點是在人員分配上,感覺還是較混亂的,如果哪一模組遇到問題長時間沒有解決的話,整個組的節奏會受到影響(不過也沒辦法,大家都是從零開始,guns框架的學習成本也確實較高)。
4. 專案的整個過程都按照計劃進行,專案中途伺服器、網頁的功能出現一些問題。
5. 在計劃中沒有留下緩衝區,導致開發後半段十分緊張。迭代開發驗收的前兩天,邊老師突然在群裡發了一份兒驗收要求,仔細一看,我們組當時做的沒有幾條是符合要求的。於是我們趕緊加班加點按照老師 的要求各種改程式碼,找bug。這也給我們一個教訓,不要正好卡在ddl完成專案,一定要留出充足的時間去應對各種突發情況。幸運的是,最終驗收結果還算較為滿意。
6. 將來的計劃將留出充足的時間檢測bug,儘量將進度往前趕。
資源
1. 我們有足夠的資源來完成各項任務。
2. 各項任務所需的時間和其他資源是通過其大致專業難度,聽取老師意見決定的。
3. 對於那些不需要程式設計的資源 (美工設計/文案)沒有低估難度。
變更管理
1. 因為我們小組每週都會開一次專案例會,彙報自己本週進度,所以每個相關的員工都可以及時知道了變更的訊息。
2. 我們採用了舉手表決,少數服從那個多數的方法,決定“推遲”和“必須實現”的功能。
3. 對於可能的變更沒能制定應急計劃,這點需要改進。
4. 組員能夠有效地處理意料之外的工作請求。
設計/實現
1. 因為之前大部分時間一直都在寫各種各樣的文件,所以我們的專案起步比較晚,真正意義上編寫程式碼的時間只有不到兩個禮拜。而且,我們當初把專案實現想得過於理想,導致後來時間有些不夠用。
2. 設計工作碰到模稜兩可的情況,團隊舉手表決。
3. 團隊運用UML來幫助設計和實現。工具有效。 比較專案開始的 UML 文件和現在的狀態,發現有些邏輯在實際實現中發生了改變。需要要更新 UML 文件。
4.前端頁面註冊登入功能產生的Bug最多,因為在這個模組中需要反覆測試各種錯誤提示。
5. 程式碼複審(Code Review)是小組間互相審查的,較為嚴格地執行了程式碼規範。
團隊的角色,管理,合作
1. 團隊的每個角色是通過表明自己所擅長或感興趣的方面來確定的,大致做到了人盡其才。
2. 每次遇到問題時,團隊成員之間能夠做到互相幫助。
3. 當出現專案管理、合作方面的問題時,團隊成員通過討論開會達成一致。
4.但是有一點不是很適應,因為我們組並沒有全員參與開發,其實老師有一些強制性的要求對我們組不是很公平,不過也好在我們組內5個人都比較有凝聚力,我相信大家迎難而上我們一定可以按期按量地完成任務。
總結:
第一次迭代開發學到了很多,主要是研究技術上的實現,沒有多少時間幫助後臺人員進行開發。但是,作為PM,在此我不得不說,後臺的開發真的是太慢了!大家要抓緊時間,多多把任務放在心上。真心希望每個人都是開發中,“雞與豬”故事裡的豬。