過後諸葛亮

做業格式

隊員學號 隊員姓名 博客地址 備註
221600131 Jamin https://www.cnblogs.com/JaminWu/ 隊長
221600308 我超可愛的 http://www.cnblogs.com/XNC-SoCute/
221600305 haziza http://www.cnblogs.com/haziza/
221600340 你看見個人小熊了嗎 https://www.cnblogs.com/stereohearts/
221600426 Hunterj Lin https://www.cnblogs.com/HunterJ/
021600823 玫葵 https://www.cnblogs.com/offeroques/

目錄

  1. 設想和目標
  2. 計劃
  3. 資源
  4. 變動管理
  5. 設計/實現
  6. 測試/發佈
  7. 團隊的角色,管理,合做
  8. 總結

做業正文

  • 設想和目標

  1. 咱們的軟件要解決什麼問題?是否認義得很清楚?是否對典型用戶和典型場景有清晰的描述?
    • 咱們的軟件要解決的是福州大學服務外包實驗室的對外展現和賽事管理交流方面的問題。
    • 定義的挺清楚的。
    • 對典型用戶和典型場景有相對清晰的描述。根據老師和實驗室管理者進行需求分析,從而創建文檔。
  2. 咱們達到目標了麼
    • alpha計劃的接口和組件都作到了。
  • 有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?
    • alpha階段咱們的策略就是鋪好底層代碼,尤爲是前端咱們不急於拼接頁面整合路由,而都是再封裝以後須要的組件。這樣以後不管是要實現後端的功能擴展仍是前端組件的多樣化,都能很快地繼承原有的接口或組件進行實現,因此alpha階段主要是介紹咱們的開發流程、過濾算法和底層組件,沒有演示頁面點擊跳轉的功能。而從你們答辯提出的問題中所有都是圍繞沒有直接演示這一點展開。因此若是歷史重來我可能會先爲了保證團隊分數,先單首創建一個展現分支,將已完成的頁面路由進行整合,方便演示。
  • 計劃

  1. 是否有充足的時間來作計劃?
    • 有的。課程前的選題報告分析和需求分析報告等讓咱們有足夠的時間制定相應的計劃。在數據庫設計等以前就完成了計劃制定和任務分工。
  2. 團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的?
    • 目前並無出現有較大分歧的狀況發生,極少數有不一樣意見的狀況下,咱們會分別進行闡述,而後進行投票,選擇更合適的方案
  3. 你原計劃的工做是否最後都作完了? 若是有沒作完的,爲何?
    • 任務基本按原計劃完成。
  4. 有沒有發現你作了一些過後看來不必或沒多大價值的事?
    • 因爲前期規範不夠清楚,你們在建立文件夾和文件時可能只是遵循本身的開發習慣,這樣後期merge就會出現功能相同但名字不一樣的文件夾,就會有一部分人須要妥協修改本身的目錄及代碼中的引用路徑,這些若是前期強調清楚,並在master創建文件時先建好目錄框架,實際上是能夠避免的。
  5. 是否每一項任務都有清楚定義和衡量的交付件?
    • 有明確的交付件和代碼定義規範。
  6. 是否項目的整個過程都按照計劃進行,項目出了什麼意外?有什麼風險是當時沒有估計到的,爲何沒有估計到?
    • 咱們的計劃和分工都較爲合理和明確,項目目前並無出什麼意外。
    • alpha階段前端進度較慢,但這是以前預估到的,因此一開始計劃的進度也是較慢的。主要是爲了以後的編碼打好基礎。
  7. 在計劃中有沒有留下緩衝區,緩衝區有做用麼?
    • 有留下緩衝區,咱們認爲緩衝區是十分有必要的,咱們能夠在緩衝區的時間段內進行修整,並對其餘科目的考試進行準備。
  8. 未來的計劃會作什麼修改?
    • 對新加入成員的培訓。由於新加入成員是Java技術棧,而咱們後臺用的是 .net,因此須要讓新成員熟悉咱們底層大量封裝的代碼是當務之急。同時爲了預防新成員沒法較快上手的狀況,咱們也提供了讓新成員參與測試任務的方案。
    • 因爲項目規模與組員時間的矛盾,咱們會先將交流中心功能放在最後實現,保證其它功能先上線。若有時間再開發交流中心模塊。
  • 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
    • 主要學到了對項目進度的總體把控能力。
    • 我會更精準地預估項目花費時間以及可能會面臨的困難,列出時間點更詳盡的計劃。
  • 資源

  1. 咱們有足夠的資源來完成各項任務麼?
    • 硬件資源上,服務器選擇的是實驗室的服務器,其餘的電腦等配置也都足夠。
    • 人力資源上,小組人員分工合理,但前端工做量較大,略有壓力。
  2. 各項任務所需的時間和其餘資源是如何估計的,精度如何?
    • 按照學習上手的時間和實際編碼的時間來估計,對於小組中有人已經掌握的技術估計精度較高,由於能夠根據本身的經驗判斷;但若是小組沒人瞭解過,那估計精度就會存在誤差,這應該也是難以免的。
  3. 測試的時間,人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度?
    • alpha階段主要只進行了單元測試,因此是足夠的
    • 並無低估難度。由於小組成員已有完整的開發經驗。
  4. 你有沒有感到你作的事情可讓別人來作(更有效率)?
    • 先後端的編碼若是給有較豐富項目經驗和有框架經驗的人來作確定效率會更高。
  • 有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?前端

    • 可能不會選擇規模這麼大,仍是最後要交付甲方的項目,須要考慮代碼可維護性、軟件壽命、拓展性、性能優化等現實問題,挖坑給本身跳。設計和編碼階段時間緊張,確定沒辦法全面分析該項目的每一個功能模塊,最後得分還不如時間花的少的隊伍。而選擇小項目,花費時間少,分析和編碼都能完成度更高,最後分數也更高。
  • 變動管理

  1. 每一個相關的員工都及時知道了變動的消息?
    • 是的
  2. 咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?
    • 根據甲方需求。
    • 沒有就不能上線的項目即爲必須實現,沒有也能夠先上線使用的能夠推遲。
  3. 項目的出口條件(Exit Criteria – 什麼叫「作好了」)有清晰的定義麼?
    • 代碼風格統一,目錄清晰易懂,可快速定位須要維護的組件
    • 前端最低適配900px寬度,最高適配1400px
    • 每一個接口經過mock.js搭配swagger進行的測試
    • 經過自動化測試,測試日誌無異常
  4. 對於可能的變動是否能制定應急計劃?
    • 能。好比此次隊伍忽然換人。
  5. 員工是否可以有效地處理意料以外的工做請求?
    • 是。如這次隊伍忽然換人,咱們就作好了兩手準備,不管組員最終結果是否能融入,都將減小對團隊形成的影響。
  • 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
    • 學到了應對隊友變對手的可能性。
    • 若是歷史重來,咱們會編寫規範的代碼文檔,且作好備份,防止刪庫跑路。
  • 設計/實現

  1. 設計工做在何時,由誰來完成的?是合適的時間,合適的人麼?
    • 前期有爲期數週的設計階段,由全組協做完成。
    • 前期時間較寬裕,很合適。
    • 團隊人數有限,沒有更合適的選擇了。
  2. 設計工做有沒有碰到模棱兩可的狀況,團隊是如何解決的?
    • 有。
    • 請教項目經驗更豐富的學長。
  3. 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其餘工具來幫助設計和實現?這些工具備效麼? 比較項目開始的 UML 文檔和如今的狀態有什麼區別?這些區別如何產生的?是否要更新 UML 文檔?
    • 運用單元測試、UML、easy-mock、SwaggerUI等。
    • 有效。
    • 無區別,前期設計花了很長的時間已較嚴密地考慮了可拓展性的問題並想出瞭解決方案。
  4. 什麼功能產生的Bug最多,爲何?爲何咱們在設計/開發的時候沒有想到這些狀況?
    • 賽事模塊,由於須要有較強的拓展性,且有不少細節須要考慮。
    • 項目開發主要靠經驗,顯然咱們的代碼經驗都不夠豐富。
  5. 代碼複審(Code Review)是如何進行的,是否嚴格執行了代碼規範?
    • 使用ESlint,可設置代碼規範和風格,由插件進行檢查和錯誤提示,定位未符合規範的代碼。
  • 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
    • 開發過程當中遇到一個很大的問題是因爲前期規範不夠清楚,你們在建立文件夾和文件時可能只是遵循本身的開發習慣,這樣後期merge就會出現功能相同但名字不一樣的文件夾。若是歷史重來我會先在目錄裏將後期全部會遇到的文件夾按功能模塊先都創建起來,以後根據功能模塊創建feature分支,分支之間基本不存在耦合,這樣後期合併分支就會省去不少選擇保留的時間。若是後期須要前期沒有預估到的目錄,那應該彙報給項目負責人,由項目負責人在dev分支創建後其餘人及時更新。
    • 學到了業界規範的開發流程。前端使用webpack+Vue全家桶開發,後端使用 .net core跨平臺開發SPA。由於單網頁的特性還增長了許多性能優化的措施,如keep-alive、路由懶加載、異步組件等。後端作了不少提升安全性的措施,如防sql注入、一句話木馬、RSA加密等。代碼規範方面使用ESlint自動審查每一個人的代碼並定位不規範的代碼片斷,提升效率。
  • 測試/發佈

  1. 團隊是否有一個測試計劃?爲何沒有?
    • 有,見團隊測試博客。
  2. 是否進行了正式的驗收測試?
  3. 團隊是否有測試工具來幫助測試?
    • 有。easy-mock、SwaggerUI、RIDE
  4. 團隊是如何測量並跟蹤軟件的效能的?從軟件實際運行的結果來看,這些測試工做有用麼?應該有哪些改進?
    • 一開始是本身編寫mock腳本,目前使用的是可視化插件和工具更加便捷,且搭配使用效果更佳。
    • 測試工做確定是有用的,減小上線後出現的問題。
    • 測試這個環節是咱們學生開發經常忽視其重要性的,以前面試阿里天貓時一位測試工程師談到他們現在的工做不只是在開發後期測bug讓開發人員修復,還要從設計的時候就要進行風險評估,預防開發人員寫bug,其實對項目的把控要求很是高,但後者咱們顯然還未作到,也是我目前想了解但沒機會沒時間深刻學習的。
  • 咱們學到了什麼? 若是重來一遍, 咱們會作什麼改進?
    • 學習了一些測試工具,提升了項目的規範性,更好地預知了項目的bug並修復,減小了上線後的風險。
    • 雖然在選擇測試工具上咱們沒有直接瞭解到如今的測試工具,是進行到一半纔在查閱資料中學習到的。可是我認爲這樣的過渡是在所不免的,說不定過幾天又學習到了更適合的開發工具也未可知。
  • 團隊的角色,管理,合做

  1. 團隊的每一個角色是如何肯定的,是否是人盡其才?
    • 因爲你們接觸編程的時間都不長,因此有明顯的技術偏向和喜愛,因此這一點仍是很容易把控的。
  2. 團隊成員之間有互相幫助麼?
    • 團隊兩級分化較大,必需要花不少時間來幫助一些組員上手框架,不然任務將集中在少數人身上。
  3. 當出現項目管理、合做方面的問題時,團隊成員如何解決問題?
    • 哈孜娜:我感謝熊寧暢對個人幫助,由於有任何不會的問題都會認真幫我分析並解決。
    • 吳嘉民:我感謝林將航對個人幫助,由於我能夠很放心地把後臺和網絡安全交給他負責,讓我集中精力在前端上不用兩頭兼顧。
    • 熊寧暢:我感謝吳嘉民對個人幫助,由於前端的知識和框架都是他告訴我要怎麼學的。
    • 周楊富:我感謝熊寧暢對個人幫助,由於在寫不動代碼的時候她能鼓勵我。
    • 餘秉鴻:我感謝吳嘉民對個人幫助,由於關於測試的方向和技術都是他給個人指導。
    • 林將航:我感謝吳嘉民對個人幫助,由於與我對接後端接口、以及指出後端接口設計的不合理之處。
  • 總結

    • 你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?
      • 可複用級
    • 你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?
      • 規範
    • 你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?
      • 團隊逐步熟悉開發框架,開發效率提升。
    • 你以爲目前最須要改進的一個方面是什麼?
      • 兩極分化較大,組員還須要提升編碼能力,提升代碼質量。
  • 新進組員工做交接

    • 因爲新進組員擅長Java後臺開發,而咱們項目是 .net框架,因此須要新進組員較漫長的學習,大體方案以下:
      • 掌握C#基本語法與 .net core框架的基本結構和用法。
      • 講解後端底層代碼
      • 因爲alpha階段後端對底層進行了大量封裝,現在controller層的對外接口只是水到渠成。因此可將一些對外接口交予實現
      • 若不肯意另外學習 .net技術棧,也可參與測試工做,編寫更規範完善的測試腳本,爲項目掃雷。
  • 照片

相關文章
相關標籤/搜索
本站公眾號
   歡迎關注本站公眾號,獲取更多信息