https://www.cnblogs.com/wu372620060/p/15616365.html

一、基本情況

• 組長部落格連結：https://www.cnblogs.com/wu372620060/p/15616365.html

• 現場答辯總結：

  ​ 適配在正方形螢幕上翻了車，不過評測組用自己的電腦看了應該問題不大——

  ​ 問的問題主要都和政策檔案的齊全性有關，首先部分省份的省檔案庫中就包括了地級市，而有些沒有，導致了與人們印象中政策檔案數量的差異。比如內蒙古的省檔案庫裡就包括了地級市，導致其政策活躍度看起來很高。再加上部分省份難以爬取，獲得的檔案數較少，造成了公平性上的問題，也就導致了最後這個政策活躍度排名看起來非常的不靠譜。

  ​ 第二是搜尋介面過慢的問題，一是數量過多，二是優化做的比較差。

  ​ 總的來說還是爬取工作量太大了，即使全組上陣也無法很好的完成任務，也導致了介面慢、資料不全。但是無論如何，預期完成的工作還是交付了，並且也有比較好看的前端介面和規範的文件和程式碼，還是較為令人滿意的。

• 全組討論的照片：

• 評估團隊中每個人對本次作業的貢獻比例，描述為本次作業的工作流程、組員分工、組員工作量比例：

  團隊成員	分工情況	任務比例%
  吳振溢	前端、爬蟲	11%
  林蔣輝	伺服器部署	11%
  黃朝威	爬蟲主要負責人	15%
  周浩東	部分後端介面	14%
  周偉傑	部分後端介面、爬蟲	11%
  張樂芃	前端和前端伺服器部署	11%
  潘春佳	文案	8%
  陳宇揚	爬蟲	11%
  蔡樹峰	文案	8%

二、總結思考

2.2.1 設想和目標

1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述 ？

   • 對各大政府網站的政策檔案進行大資料收集、基於知識圖譜進行分類，提供政策檢索，資料大屏，政策地圖等功能，方便普通民眾瞭解所需政策或攥寫文章查詢檔案的需要。定位清晰，面向普通民眾，檢索方便快捷。

   • 典型使用者：擁有政策檢索需求的普通民眾：如高校應屆畢業生、私營企業家等。

   • 典型場景：大學生需查詢購房、人才政策時；企業家想了解政府補貼、退稅等政策時

2. 我們達到目標了麼?（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)

   • 計劃做出政策地圖、資料大屏、政策檢索三個模組。

   • 三個模組，基本按照原計劃交付時間交付。

   • 暫時未對期望使用者量做出明確定義，並且由於核心功能還沒有完善，需要在Beta版本完成之後考慮進行推廣獲取使用者量。

3. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?

   • 由於β衝刺短暫，暫時還未進行推廣，因此使用者量為零，使用者對重要功能的接收程度，需要在之後進行調查。
   • 是的，隨著前後端對接，軟體功能實現，我們離目標更進一步了。

4. 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

   • 團隊合作需要在任務開始前有明確的目標

   • 需要合適的分工以及分工方式

   • 開發過程要保持充分的溝通

   如果歷史重來一遍, 我們會做什麼改進：

   • 更早的開始開發
   • 分配任務更加精細化
   • 打造更準確的計劃表

2.2.2 計劃

1. 是否有充足的時間來做計劃?

   • 是的，對於前後端來說有充足的時間。在Beta版本階段，我們開過多次組會，確定好每天需要做的事情，並把每個任務細化，分配各個成員的工作。

2. 團隊在計劃階段是如何解決組員對於計劃的不同意見的？

   • 通過開會並一起討論，分析利弊，最後做出合適的選擇。

3. 原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

   • 基本完成，到總結時都已達成在Beta階段的目標。
   • 政策檔案仍然不全，要爬取的省份太多，單單多就能帶來巨大的問題。

4. 有沒有發現做了一些之後看來沒必要或沒多大價值的事?

   • 有。比如一開始試圖爬取到地級市的具體範圍內，並且也爬了幾個地級市，後來發現省都要完不成了。

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

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

   • 是，三個模組，資料獲取則是全國34個省級行政區的政策爬取進度。

6. 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

   • 有，主要就是低估了爬取政策的難度。除了甘肅以外的省份確實沒有對政策進行加密，但是它們的標籤極不規範，並且各不相同，要耗費很多無謂的人力進行爬取，到β階段為了爬取完全部省份基本整個開發組都在爬。

7. 在計劃中有沒有留下緩衝區，緩衝區有作用麼?

   • 大家首先自行進行自己負責部分的相關學習並初步完成相應的任務，接著會有組員負責找出已經完成的任務中的問題和不足，釋出出來，並且選擇大家都有空的時候，在活動室一起討論和解決問題，並根據問題接著完成自己負責的任務。因此可以說是有留下緩衝區的，在每個任務的完成之後都會進行第二步操作，進行相應部分的完善和調整。以及組長衡量專案進度後決定是否需要集體加班。
   • 緩衝區的作用就是可以幫助我們更好地發現問題和更高效地解決問題，進行交流彌補溝通不足和不明確各部分任務完成情況的缺陷。必要情況下進行“衝刺”。

8. 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）

   • 在一個長的時間範圍內進行任務細分，避免拖延症導致最後衝刺完成工作。

9. 學到了什麼? 如果歷史重來一遍, 會做什麼改進?

   • 儘早開始計劃，為突發狀況留足餘量。
   • 在專案早期儘量多的進行學習，避免後期過多的成員無法在開發上起到作用。
   • 增加爬蟲和AI的成員數量，他們的工作量由一個人承擔太大了。

2.2.3 資源

1. 我們有足夠的資源來完成各項任務麼?
   • 可能沒有，專案目標可能過於龐大了，導致AI和爬蟲的工作負重過高。還好的是前端和後端結構相對合理。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
   • 一對於各項任務難以估計出精確時間，一般只精確到天。隨著開發的進行，對於每個任務的耗時大概有了概念，能夠精確到小時。
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
   • 測試方面，時間不足，主要精力集中於主要功能的實現。低估了美工設計/文案的難度（如果按柯老師的要求）
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
   • 一開始的分工已經考慮到每個人的特性，相對比較合理。
   • 每個人都無可替代，反而一定程度上起到了反效果，一旦發生意外就出現斷節。
5. 有什麼經驗教訓? 如果歷史重來一遍, 會做什麼改進?
   • 應該多組織模組對接交流，協調好各個部分的進度，避免過多工序列而導致時間浪費的情況。

2.2.4 變更管理

1. 每個相關的員工都及時知道了變更的訊息?

   • 我們有站立會議，更有積極的線上交流，變更訊息都能及時傳達。

2. 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?

   • 通過商量討論，將那些核心功能作為必須實現；將那些實現起來難度較大，耗費時間長的功能，交付之後實現。

3. 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

   • 能實現理想情況下的功能
   • 通過自己設計的一些樣例測試

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

   • 產品的業務邏輯在初期就已經敲定，對於小範圍變更也可以根據當時的人手和情況進行應急處理

5. 組員是否能夠有效地處理意料之外的工作請求？

   • 部分員工的效率較高，可以處理額外的工作請求

6. 學到了什麼? 如果歷史重來一遍, 會做什麼改進?

   • 對於產品細節要求應該一開始儘可能的確定，且充分考慮其可行性，預估可能遇到的困難，儘量減小變更發生的可能性。

     實現過程中嘗試了一些未曾接觸過的技術，由此帶來的變更卻又無法避免，需要提前預留足夠的資源餘量。

2.2.5 設計/實現

1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？

   • 頁面設計工作在選題報告的時候就開始了，由周偉傑和陳宇揚實現最初的原型設計。作為專案的起始自然是合適的時間合適的人。
   • 當然，前後端的程式碼風格、類結構設計等等是由各開發組組長在專案前期負責的，效果也相當不錯。在Beta階段中，負責爬蟲的黃朝威也將相容度極高的程式碼分享給全部開發組，以便於大家都快速進行爬取。

2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？

   • 存在。各個模組內部的不一致，小範圍討論即可；遇上模組間對接的分歧，用過組會討論達成一致，以可行性為第一目標。

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？

   • 進行了各個功能的分別的單元測試，由各個功能的開發者完成。有效，在整合前和整合後都能實時地對各個模組的正確性進行驗證。
   • 在開發前也完成了各個部分的UML，雖然在實際開發時有所更改，但大致思路都沒有問題，增加了開發效率。

4. 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？

   • 區別不大，一方面是開發人員經驗較為豐富，對於需求所需要的程式碼構成很熟悉。只進行了少量的更改和擴充套件，並不需要過多更新。

5. 什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

   • 主要是爬蟲，來源於各種政府網站的介面和html都各不相同，從排版到加密方式等等，導致bug頻出。
   • 暫無
   • 設計開發經驗不足，預見性不夠。沒有專門負責code review的成員。

6. 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？

   • 由各小組組長統一制定，但實際上最後由開發者自己進行程式碼複審，開發者在開發中有意執行程式碼規範，沒有太多風格各異的程式碼。

7. 學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

   • 掌握了不斷學習新技能的能力和學到了新的技術，運用了新的知識。
   • 如果歷史重來一遍，我們還是要不斷犯錯才能獲取相應的經驗，應該更早進行模組對接討論。

2.2.6 測試/釋出

1. 團隊是否有一個測試計劃？為什麼沒有？ 是否進行了正式的驗收測試？
   • 有的，前端方面也完成了測試計劃，在各種比例的電腦螢幕上（除了正方形？）進行了適配和動畫流暢度觀察。但是沒有進行正式的驗收測試。
2. 團隊是否有測試工具來幫助測試？
   • 沒有太專業的測試工具，主要靠谷歌瀏覽器提供的各類控制檯。
3. 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
   • 看谷歌控制檯判斷哪些資源或者接口占用了過多的時間，適度的更改程式碼、更換元件或者刪除。
   • 還算有用吧，啟動時間在多次測試下大致從7s減少到4s。
4. 在釋出的過程中發現了哪些意外問題？
   • 已經發佈於外網，可能在適配方面仍有問題，並且隨著資料量的增加，介面的請求速度越來越慢了。
5. 學到了什麼? 如果歷史重來一遍, 會做什麼改進?
   • 學到了沒事儘量不要重複請求介面，各種元件應該按需引入。
   • 寫程式碼的時候考慮防抖和節流。

2.2.7 團隊的角色，管理，合作

1. 團隊的每個角色是如何確定的，是不是人盡其才？
   • 在充分考慮個人意願的情況下，根據個人的技術棧進行角色分配。使團隊成員各司其職，創造巨大的生產力。
2. 團隊成員之間有互相幫助麼？
   • 有，幾乎每天都在溝通交流解決成員遇到的困難。由於我們小組成員宿舍相隔不遠，線下交流也十分方便。
3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？ 每個成員明確公開地表示對成員幫助的感謝 （彙總至組長部落格）：

• 吳振溢：我感謝**<張樂芃> **對我的幫助， 因為某個具體的事情: 幫我部署前端伺服器。

• 張樂芃：我感謝 __<吳振溢>__對我的幫助， 因為某個具體的事情: 介面和部分邏輯遇到些問題，非常感謝zygg的幫助。

• 蔡樹峰：我感謝 __<黃朝威>__對我的幫助， 因為某個具體的事情: 他太能爬資料了，任務量max。

• 陳宇揚：我感謝 __<黃朝威 >__對我的幫助， 因為在beta衝刺期間，最緊張並且最需要的就是爬蟲工作。黃朝威對我爬蟲上遇到的難題都一一解答或是一起解決，並且對於部分無效資料也負責任的去除並重新注入資料庫。

• 潘春佳：我感謝__ <周浩東>__對我的幫助， 因為某個具體的事情: 在寫部落格和做ppt時，為我提供了豐富的成果圖，並且很細心的告訴我每個圖的展示內容。

• 周偉傑：我感謝 __<林蔣輝>__對我的幫助， 因為某個具體的事情: 幫我部署了伺服器，也教了我很多後端開發的基礎。

• 林蔣輝：我感謝__<周浩東>__對我的幫助，因為在開發期間對我的問題耐心回答，知無不言，給我帶來很大的進步和幫助

• 周浩東：我感謝__<黃朝威>__對我的幫助， 因為某個具體的事情: 爬取大量資料。

• 黃朝威：我感謝 __<陳宇揚>__對我的幫助， 因為某個具體的事情: 我們一起完成了剩下的爬取工作，沒有他，我單個人恐怕比較吃力。我感謝 __<吳振溢>對我的幫助，因為某個具體的事情: 總是在我遇到抓介面無法成功的時候，幫我整合生成對應的程式碼，加速了爬取程序。我感謝<周偉傑>__對我的幫助，因為某個具體的事情：感謝他也能在最後階段能用模板程式碼一起完成任務。

學到了什麼? 如果歷史重來一遍, 會做什麼改進?

• 對於不同的人要採取不同的溝通方式，調動大家的積極性，避免成為ddl戰士。

2.2.8 總結

列出組內所有人的心得。

• 吳振溢：beta衝刺加入了爬蟲的行列，以致於養成了看見爬蟲負責人員進入宿舍就開啟pycharm的PTSD，直至專案完成後的沒有消除。並且還把後端給的介面接上了，還是挺累的，不過前端部署工作全面交給了張樂芃，感激。

• 張樂芃：beta衝刺主要任務是在接介面和部署，好久沒有用過伺服器，真是又熟悉又陌生，學習的話，更多是去學習了很久之前一直想學的nginx，部署的過程和學習還是蠻愉快和順利的（不錯，以後可以更多的部署好玩的東東了，蕪湖）。最後還是感謝各位隊員的辛勤付出，比較順利的完成了這次的大作業。

• 蔡樹峰：β衝刺主要都是隊友在衝，感謝隊友帶飛！我還剩下製作視訊的任務，接下來的時間，其他科目的任務也很繁重，得構思好視訊的製作方案，提前開始準備。

• 陳宇揚：這次beta衝刺階段，爬蟲工作還是比較繁重的，以至於後面全組人都在爬資料，最後我們的政策數也從20w+漲到了50w+。最後感謝全組人的辛苦付出。（爬資料真的好難！）

• 潘春佳：做僅有的任務時我還時不時犯錯，還好有隊友們及時發現改正，而且還沒有責怪我，讓我倍感慚愧，希望有機會的話能做更多。

• 周偉傑：從什麼都不會到會簡單的開發，這學期在軟工這門課上付出了大量的時間。有時覺得實在不值，但一切都結束時又覺得過去的努力都有是意義的。也遺憾前兩年沒有進行學習，導致現在如此狼狽，不過過去的事再想也沒用，一切從現在開始。

• 林蔣輝：學會了elastic search框架實現框架，也知道了部署也不用無腦用docker，也有一些更簡單的方法，程式碼能力也得到了提升。

• 周浩東：時間飛逝，不知不覺間《軟體工程》的學習已經過了大半了。在這將近半學期的學習中，雖然我不能說我將《軟體工程》學習的有多麼的好，但是通過學習，我還是受益良多。

• 黃朝威：在Beta衝刺中度過了非常難忘的幾個夜晚，總的來說異常艱難，充滿著收穫和遺憾，遺憾的是爬取的數量有限未能所有省均將地級市包含在內，部分省有涉及地級市爬取部分省未能夠爬取地級市，收穫是發現自己寫的程式碼越來越好用了，發現自己初期辛苦專研摸索出來的模板異常強大僅需改改部分內容即可推廣，具有一定的普適性，在這個階段內我和宇揚都在完成爬取剩下的內容，甚至後面寫出了模板程式碼讓組內前端和後端動員一起加速程序，遺憾的是部分省份由於請求採用的引數為Token儘管模擬瀏覽器後仍然無法攻克，採用先進工具甚至無法刷出網頁，我和前端的組長都除錯過那令人絕望的Ajax，本以為可以獲得生成Token的js程式碼進而直接攻關，但沒想到請求引數還是來自政府網頁後端生成。