[知識路書]過後分析

設想和目標

Qcss

  1. 咱們的軟件要解決什麼問題?是否認義得很清楚?是否對典型用戶和典型場景有清晰的描述?
  2. 咱們達到目標了麼(原計劃的功能作到了幾個? 按照原計劃交付時間交付了麼? 原計劃達到的用戶數量達到了麼?)
  3. 和上一個階段相比,團隊軟件工程的質量提升了麼? 在什麼地方有提升,具體提升了多少,如何衡量的?
  4. 用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?
    有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

參考咱們的選題博客,咱們但願解決「文獻梳理、呈現與展現沒有直觀形式」這個問題,但願可以圍繞學術閱讀中的需求,以知識導圖爲主要形式,實現一款集文獻管理與內容呈現於一體的軟件。因爲這個概念略顯新穎,定義並非十分精準明確,可能隨着迭代演進產生細微調整,但大的方向不會改變。前端

咱們對典型用戶和場景有較爲清晰的描述分析,能夠參考咱們的功能規格書,主攻科研羣體,細微提供小而美的服務。vue

就alpha結果來看,咱們實現了初期制定的全部功能需求,根據實際須要又額外實現了用戶權限系統、路書分享外鏈、bibtxt批量導入等功能,同時定製了路書編輯器,對界面及佈局也作了必定程度的美化。咱們收到的用戶反饋絕大多數都是4分及以上的積極評價。總的來講,從完成度、美觀度、用戶滿意度來看,咱們都認爲切實達到了本階段的開發目標。惟一的遺憾是咱們的用戶數量沒有達到預期的100人,咱們已經討論分析了推廣策略、推廣渠道等存在的問題,並有但願在下一步的推廣中更快速增添用戶量ios

咱們目前的工程質量雖然不是完美的,但徹底處於可控範圍內,這主要得益於咱們較爲合理的協做方式和開發流程,容許咱們更從容地管理工程。下一步咱們會進一步強調代碼質量,尤爲是命名規劃與必要性註釋。git

用戶對於功能的反饋能夠查看咱們的項目展現博客,總的來講咱們關注的特性大多也是用戶關注的,如文獻批量添加、界面美觀、用戶引導等。期待後續在解決用戶提出的問題後咱們能收到更多正向反饋github

計劃

Qweb

  1. 是否有充足的時間來作計劃?
  2. 團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的?
  3. 你原計劃的工做是否最後都作完了? 若是有沒作完的,爲何?
  4. 有沒有發現你作了一些過後看來不必或沒多大價值的事?
  5. 是否每一項任務都有清楚定義和衡量的交付件?
  6. 是否項目的整個過程都按照計劃進行,項目出了什麼意外?有什麼風險是當時沒有估計到的,爲何沒有估計到?
  7. 在計劃中有沒有留下緩衝區,緩衝區有做用麼?
  8. 未來的計劃會作什麼修改?(例如:緩衝區的定義,加班)
    咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

總的來講咱們仍是有至關充足的時間進行計劃與規劃的。實際上開發初期你們的主要工做就是學習開發技術並做一些開發計劃。固然,計劃永遠趕不上變化,因此我認爲咱們的一大優點就是能夠不間斷地調整計劃、補充計劃從而適應變化,這得益於咱們強調開發人員「可替代性」與「不可替代性」權衡的協做節奏。我想,這也是敏捷開發的哲學內含,以不斷的變化來應對快節奏的開發與交付django

咱們的不一樣意見大多能夠在同步會中解決,一方面是由於團隊氣氛自由融洽,你們能夠很好地表達本身的觀點、參考別人的觀點,所以分歧總能快速消除。實際上這或許也是前段時間三明治交流法的實踐結果。我觀察到你們在對待異見時總能先總結對方的優勢,再指出其不足,並給出本身的解決方案————這樣的溝通理性而容易達成組內共識編程

原計劃的工做所有完成,並額外完成了一些工做,能夠參考上一節。惟一遺憾的是咱們一直受限於資源與政策,沒有解決部署域名的問題,或許下個階段咱們能找到一些免費的解決方案,或替代方案。axios

總的來講咱們的每一項工做都是有意義的,開發節奏緊湊充實。惟一(看起來)沒什麼價值的工做是給全體組員開了個超級用戶帳號,最後發現你們大部分時候仍是用本身的(普通用戶權限)帳號密碼登進去作測試……(主要由於咱們幾乎不須要手動修改生產環境的數據,這實際上是個好現象)

分發的每個任務都會在開會時清楚定義,並在issue中描述要點。但衡量標準每每是不固定的,由於咱們但願組員根據本身的實際開發狀況與我的理解決定手頭正在開發的功能須要實現到什麼程度(固然後端開發,尤爲是測試,是有很是明確的驗收指標的,好比後端的兩位同窗很辛苦地把覆蓋率拉到了100%),背後的思想是:司令部把指揮權交給戰地指揮官每每是合理的。

項目總體按計劃進行,意外大多來自第三方組件。好比咱們調研到的一款markdown渲染插件,它的實現有一些問題,傳入slot中的內容沒有實現數據雙向綁定,數據更新後必須從新掛載渲染組件才能刷新————這是咱們意料外的,而且有些反直覺而難以排查。因此花費了額外的精力去定位、修復這個錯誤。

咱們使用了測試-生產雙分支的形式管理代碼倉庫,這實際上就是一種緩衝機制。

資源

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

學習資源:

  • 很是充足。
  • 不管是前端的 Vue.js,仍是後端的 Django,網上的學習資料都十分豐富。
  • 同時,本組有資深開發人士,能提供足夠的技術支持。

人員配置:

  • 較爲充足。
  • 4 人負責前端,2 人負責後端,1 人機動。

硬件資源:

  • 匱乏。
  • 本身的服務器性能較差。
  • 缺乏可以使用的域名資源。
  1. 各項任務所需的時間和其餘資源是如何估計的,精度如何?

在每次的任務發佈以前,經過例會進行任務拆解,分發到我的頭上。

每一個人領取 issue,將分解任務的時間資源按小時級別估計,需求任務的時間資源按天級別估計。

估計在大部分時間是比較精準的,可是因爲某些不可抗力的干擾,偶爾會出現估計錯誤。

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

足夠。

後端組 2 人負責測試工做。分別從 CURD、Permission 和 Auth 三個方面進行測試工做。

關於美工設計與文案方面,美工設計方面的難度不是很大,可是咱們對文案的重視程度有必定不足,後期須要補充。

  1. 你有沒有感到你作的事情可讓別人來作(更有效率)?

沒有。咱們組強調每一個開發者專精一個方向(不可替代性)並熟悉其餘人的開發方向(可替代性),從前者的角度來看,我作的事情由我來完成是效率最高的。

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

因爲經驗不足,錯誤類型的接口定義和錯誤處理方式小組成員未作統一約定,致使錯誤提醒內容存在差別和錯誤。

因爲對後端文獻數據內容形式的不瞭解,以及文獻表格顯示哪些內容也不清晰。咱們文獻管理的table以及建立文獻的drawer的相關字段設計混雜,不夠人性化,table和drawer之間字段也有衝突。

改進:在和PM以及相關負責同窗協商,充分考慮用戶需求後,進行相關字段的設計和重構。

變動管理

Q

  1. 每一個相關的員工都及時知道了變動的消息?

是的,咱們採用GitHub上的項目管理相關功能來保證隊友及時瞭解變動代碼或者消息。

  1. 在每次dev代碼更新以後,均可以瞭解更新的內容和時間,git自帶的拉取功能也能隨時確保本身的代碼是最新的。
  2. 團隊採用issue和解決issue的開發模式,每一個issue合理分配給不一樣的隊友,咱們在接收到issue以後,會收到GitHub的郵件,保證任務分發和出現突發變動的時候,3. 每一個隊友都能及時知曉。
    週期性的大組會和隨時的小範圍會議,保證了每一個成員都能瞭解項目的進度與方向的變動。並且每一個成員的問題都能隨時獲得解決。
  1. 咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

咱們在項目最初設計文檔時,肯定了必須功能和附加功能,因此在面對具體功能的規劃時,能夠參考 最初設計文檔的功能規劃,來決定這一項功能時必須按時完成的核心功能仍是能夠推遲的提高功能。

  1. 項目的出口條件(Exit Criteria – 什麼叫「作好了」)有清晰的定義麼?

有,出口條件也是在最初的設計文檔中肯定了的。在設計文檔中,除了肯定必須功能和附加功能外,也肯定了𝝰階段和𝝱階段的可發佈的幾大核心功能。
同時,從測試和debug的角度出發,出口在知足核心功能的同時,也須要總體代碼有90%以上的測試覆蓋率,以及前端代碼審覈後交付且新手可流暢使用。

  1. 對於可能的變動是否能制定應急計劃?

能夠。
咱們面對代碼上可能的變動,能夠及時發佈新的issue,其中能夠設計各類label好比優先級程度、是不是bug、是不是核心功能,並分配個一我的或者多人來完成。
在大的代碼思路上可能出現的變動,咱們有密集的大小組會,能夠隨時統一思想,而且集思廣益理清思路、解決問題。

  1. 員工是否可以有效地處理意料以外的工做請求?

是。
咱們團隊採用網狀式扁平化的團隊開發方案,每一個隊友都有各自最擅長的開發方向,並且也經過組會交流對其餘人的開發代碼比較瞭解,可以處理自身開發代碼以外的功能需求,而且可適應跨功能的開發。
並且,總體隊友的開發積極性高。可以在完成基本功能的基礎上,發動本身的主觀能動性,開發提升功能,而且本身思考打磨各自的模塊,開發主動性高,能夠有效處理意料以外的工做請求。

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

咱們學到了軟件工程的團隊開發的方法。好比基於GitHub的代碼管理,團隊會議組織方法,面對變動的羣策羣力,等等。
若是歷史重來一次,咱們會作:

  1. 在初期需求分析的學習階段,天天請同窗進行學習交流,進行知識交流,並同步組內的學習進度。
  2. 設定開發每一個時間分段的任務和人員安排,讓開發更有節奏,讓每一個隊友也知道本身的進度安排。
  3. 提早推廣,更早的知道用戶的反饋,輔助後續開發。

設計/實現

Q

  1. 設計工做在何時,由誰來完成的?是合適的時間,合適的人麼?

在咱們團隊的敏捷開發過程當中,不一樣層面的設計工做其實貫穿了整個流程。初期時,設計工做關注功能,在撰寫產品功能說明書時,咱們側重從用戶使用角度去設計產品的目標和功能;而在實際開發時,咱們側重從技術角度設計整個軟件框架、工程維護規則、界面風格規範、錯誤處理規範、axios請求規範等;而到alpha階段接近完成時,隨着測試和使用反饋,又進入了新一論的設計和實現過程。

咱們認爲團隊在參與設計的時間是合適的,正如《構建之法》在介紹設計、編碼、測試等內容在敏捷開發的流程時的圖示,每一部分並非徹底割裂的,而是此消彼長式地相互融合。

對於功能設計和工程實現設計,咱們主要交由本組開發經驗豐富的hdl和zwx同窗完成。後期分析,咱們認爲這樣的設置是合理的,避免團隊設計不切實際的目標或走過多的彎路,同時也有助於其餘組員學習。

  1. 設計工做有沒有碰到模棱兩可的狀況,團隊是如何解決的?

在沒有編碼實現或編碼實現初期時遇到過模棱兩可的狀況,例如前端向後端的請求接口設計在沒有實現狀況下很難作到完備地考慮。

解決思路:構建一個基礎的設計先行實現,並可以在demo環境下完成功能。然後在scrum例會時,向組員講解清楚功能實現,由團隊共同協商再提出新的具體優化內容,由此產生迭代的過程,最後達到滿意的結果。

  1. 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其餘工具來幫助設計和實現?這些工具備效麼? 比較項目開始的 UML 文檔和如今的狀態有什麼區別?這些區別如何產生的?是否要更新 UML 文檔?

團隊針對後端使用了單元測試,並檢驗了代碼覆蓋率。

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

總體上項目的Bug分佈比較均勻,在各處均有產生。在修復問題時,遇到問題比較可能是腦圖MindMap組件的定製,主要涉及到了css風格自定義以及傳統js&vue的編程,所以比較困難。

在實現時,咱們採用了release/dev雙分支的設計,全部的pull request均合併到dev分支,待檢驗完畢後合併至release分支,在每一個版本發佈前均會進行測試,所以分佈版本未遇到什麼重要的bug。對於小問題,發佈後曾出現了頁面跳轉錯誤的狀況,過後分析是因爲vue.router部分調用方式不遵循解耦思想,在Beta階段時,須要規範組員在路由器跳轉、錯誤處理、axios請求調用接口上的使用規範。

  1. 代碼複審(Code Review)是如何進行的,是否嚴格執行了代碼規範?
    Code Review 藉助 Github 的 Pull Request 和 Issue 功能實現,全部的pr要求必須有一名組員贊成,github會根據近期的編碼歷史,向pr發起者推薦合適的reviewer。

代碼規範:咱們團隊並無自行定義一套完整規範,而是使用了代碼規範ESLint+WebStorm風格檢查代碼的規範。通過組員反饋,對兩套規則下的代碼複審和閱讀持好評。

對於團隊大部分組員來講,這是咱們第一次基於Github合做完成工程項目,在流程上,咱們體驗了軟件開發一個週期中的設計、實現、測試的流程,在內容上,具體瞭解了Web開發的技術,在合做技術上,基本掌握了基於Github的項目推動和團隊合做方法。

若是歷史重來一邊,咱們會改進的地方有:

  • 明確Issue和Pr的規範和格式。
  • 測試更早時間介入。

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

測試/發佈

Q

  1. 團隊是否有一個測試計劃?爲何沒有?

有測試計劃

  1. 是否進行了正式的驗收測試?

是, 在正式發佈前, 咱們尋找了目標用戶, 讓目標用戶在軟件的環境中使用了一段時間, 在未知用戶操做的狀況下, 讓用戶可以接受軟件。

  1. 團隊是否有測試工具來幫助測試?

測試工具主要使用django rest test和coverage, 經過django rest test對後端的CURD, 鑑權, 用戶註冊等操做進行正確性驗證, 利用coverage工具對django測試的代碼覆蓋率進行檢查, 若是添加新功能後, 代碼覆蓋率沒到100%, 那麼繼續添加測試。 前端主要是使用場景測試, 在前端web app的幾個主要的界面和路書的功能場景內進行測試。

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

測試工具對於先後端的驗證有做用, 以後須要對前端添加更多自動測試。

  1. 在發佈的過程當中發現了哪些意外問題?
    咱們學到了什麼? 若是重來一遍, 咱們會作什麼改進?

咱們須要添加功能後進行更細節的測試, 使用CI CD工具進行迴歸測試。 在beta階段, 咱們會添加更多功能, 在以後的開發中, 須要不斷完善測試, 若是再來一遍, 咱們會更早使用TDD(測試驅動開發)。

團隊的角色,管理,合做

Q

  1. 團隊的每一個角色是如何肯定的,是否是人盡其才?
  2. 團隊成員之間有互相幫助麼?
  3. 當出現項目管理、合做方面的問題時,團隊成員如何解決問題?

團隊角色是第一次開發會上劃分的,因爲你們基本都沒有相關經驗,只是憑藉興趣選擇方向。你們開發積極性都很高,再加上咱們的任務的動態調整機制,總的來講是人盡其才的

相互幫助是確定存在的,咱們的協做中穿插了大量結對編程與小範圍會議,不乏互相幫助的過程。咱們也經過這種形式解決了大部分合做問題,餘下的難題留給同步會與集中開發。

  1. 每一個成員明確公開地表示對成員幫助的感謝 (而且寫在各自的博客裏):

我感謝 _______<姓名>______對個人幫助, 由於某個具體的事情: _____________________。

總結:

你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?
你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?
你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?
你以爲目前最須要改進的一個方面是什麼?
對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。
正如咱們前面提到的, 軟件的質量 = 程序的質量 + 軟件工程的質量,那團隊在下一階段應該如何提升軟件工程的質量呢?

團隊階段介於「規範」與「創造」之間

最須要改進的是代碼質量管理

作的最好的是:學習所有經驗

在程序質量上,咱們會引入更多測試與錯誤處理相關的機制,藉助自動化手段將勞動力解放並確保質量。這或許能夠藉助Github Action實現

在工程質量上,咱們會緊抓代碼質量管理,重構一小部分有「壞味道」的代碼,更注意規範命名、註釋與項目結構管理,寫出更可讀、可維護的代碼

  1. 代碼管理的質量具體應該如何提升? 代碼複審和代碼規範的質量應該如何提升?

目前的複審形式良好,前期出於「快速實現」的思想並無十分嚴格要求代碼規範,後續提高過審標準便可。這須要一次同步會議進行全組範圍內的規範與說明

  1. 整個程序的架構如何具體提升? 如何經過重構等方法提升質量,如何衡量質量的提升?

總體架構良好。前端追求更扁平的頁面/組件嵌套邏輯,並將經常使用操做集抽象爲工具函數。後端已經藉助插件框架實現了比較好的工程結構

  1. 其它軟件工具的應用,應該如何提升?

TODO

  1. 項目管理有哪些具體的提升?

暫無,目前管理流程運做流暢,維持現狀便可

  1. 項目跟蹤用戶數據方面,計劃要提升什麼地方?例如大家是如何知道每日/周活躍用戶等數據的?

因爲未成規模,暫時沒有相關統計。後續咱們考慮引入一些第三方BaaS服務統計DAU等指標

  1. 項目文檔的質量如何提升?
  1. 對於人的領導和管理, 有什麼具體能夠改進的地方? 請看《構建之法》關於PM、績效考覈的章節, 或者 《人件》等參考書
  1. 對於軟件工程的理論,規律有什麼心得體會或不一樣意見? 請看閱讀做業。 (這個做業的期中閱讀)

討論截圖

關於後續如何重構/改進代碼質量的問題,組員積極討論:

Q: 對比敏捷的原則,你以爲大家小組作得最好的是什麼? Q: 什麼是在下個階段要改進的地方?越具體越好。

相關文章
相關標籤/搜索