組長部落格連結

一、基本情況

現場答辯總結

1. 專案總體進展充分
2. 應該更深度地去挖掘爬取下來的大量資料潛在的含義
3. 在柯老師的建議下、降低資料清洗的數量的同時提高清洗質量並且更進一步挖掘爬取到的資料的內在含義。對待資料分析結果的呈現應該更加謹慎。
4. 經同學建議、可能會採取更前沿的資料分析方法、具體列舉如下：
   

全組討論的照片

本次作業貢獻比例評估

工作流程

• 本次作業的工作流程
• 受限制於疫情和大家各自不同、我們選用github來同意大家的工作進展帶有 Develop 分支的 Git 功能分支工作流此工作流是開發團隊中比較流行的工作流之一。它與 Git 功能分支工作流相似，但它的 develop 分支與 master 分支並行存在。在此工作流中，master 分支始終代表生產環境的狀態。
  
• 具體到資料分析階段
  

二、總結思考

2.2.1 設想和目標

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

   我們的軟體需要收集藥品的資料，對藥品的價格進行分析視覺化，儘量讓藥品的價格資訊變得透明。目前來看，我們的定義主體上還是比較清楚地，邊界比較明顯。對於典型使用者和典型場景也有比較清晰的描述。

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

   我們的目標大部分完成了，還剩下一些部分需要進行完善，原計劃的功能基本都完成了，比如要求的資料的爬取，前端的視覺化圖展示等。目前還沒有進行部署，使用者數量為0，暫時沒達到原計劃使用者數量

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

   使用者量目前為0因為還沒部署到伺服器，和我們預先設想的暫時不一致，使用者對重要功能的接受程度因為還沒上線暫時無使用者所以還無法調查，但是我們小組成員在進行執行時大部分功能實現的效果還行，我們認為我們正逐漸在靠近目標

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

   會將分工進行細分，具體職責分配到位，以提高開發的效率，推進專案程序。並且要適當提高開會的頻率，跟進專案的進度。

2.2.2 計劃

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

   是。雖然有許多組員課程很多考試也很多並且都擠在一塊了沒什麼時間，但是也有幾個組員時間較為充裕且願意為小組花時間來做一些規劃。

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

   團隊成員意見不統一時，我們會多徵求意見，集中思考解決方案，儘可能得到一個總體上大家都能接受的結果。團隊成員大家都可以相互理解相互體諒，因此也沒有出現不可解決的矛盾，大家都能和氣地商量解決

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

   沒有全部都做完，因為大部分人都需要從頭開始學習，學習成本很高，再加上其他課程的學習和考試，導致最後在專案開發的時間較少，暫時沒有全部完成所有功能的具體實現

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

   有。主要是爬取時候的技術方面。

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

   是，每一個任務都有最少完成的指標。

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

   不是都按照計劃進行，出的意外就是伺服器配置太過垃圾，而且沒有估計到的一個風險是流量消耗太快，因為以前沒有過伺服器的使用經驗所以沒預估到

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

   有。緩衝區可以讓專案更有容錯率，雖然不能搞定所有但是至少能在ddl前解決一些問題

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

   將來的計劃就是組內大家再衝一波，加個班，在ddl前盡最大努力完成

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

   學到了在專案過程中分工明細很重要，如果再來一遍會更加細緻地進行分工，設定好各個部分的負責人，共同推進專案的進展

2.2.3 資源

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

   有，人力物力都有基本保障。

2. 各項任務所需的時間和其他資源是如何估計的，精度如何?

   所需時間和其他資源是根據分配的任務量以及與對應的任務負責人所商量的結果來估計的，精度到以天為時間單位

3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?

   測試的時間和人力和軟體/硬體資源較為足夠，大家都會盡量擠出時間來進行測試，我們小組人數也夠，開發所需的軟體硬體資源也是有的。對於那些不需要程式設計的資源沒有低估難度，都會指定一個人來負責

4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?

   沒有，我們的給每個人分配的任務都是尊重個人意願且衡量過個人能力來進行分配和調整的

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

   我們應該加強時間觀念，還有對專案進展的跟進。再來一遍的話要改進管理方式，多多注意專案的進展，不浪費一分一秒

2.2.4 變更管理

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

   是的，我們一旦有了變更都會通過騰訊會議來進行通知每一個人

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

   根據我們專案需要實現的最基本功能來決定，必要的先做好，錦上添花性質的功能就是在先做完基本要求的前提下再談

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

   有，就是在前端能夠展示出我們想要的資料圖表

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

   能，小組會積極地進行會議，集思廣益指定應急計劃。

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

   是的，組員都很盡力，即使熬夜也會盡量完成

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

   一開始指定計劃的時候應該儘可能的考慮充分，讓計劃儘可能的周全，最大限度地避免在專案的進行過程當中做變更，也應該做應急方案，以防萬一。

2.2.5 設計/實現

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

• 設計工作從Alpha之前的一兩星期就開始準備了，設計人主要是由蘇偉煌組長為核心，其他組員提出自己的建議。
• 是合適的時間，和合適的人。

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

• 有過。
• 在設計的過程中，例如前端的頁面設計中，和原型圖略有出入。解決方法：有問題的人在內部溝通，儘量求同存異。如果還有疑問的話，則找其他組員，少數服從多數。

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

• 有利用過單元測試（unit test）來測試後端的介面是否能夠使用。

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

• 有一定的區別。
• 原因在於，在專案開始時，可能因為考慮不周全，現在會增添一些細節。還有就是因為之後開發時候，因為發現技術能力有限，放棄了一些功能。
• 是應該更新 UML 文件。

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

• 在跳轉頁面的時候產生的bug最多。
• 主要是因為程式碼之間函式的執行順序出了一點問題。所以一直再改。
• 釋出之後並沒有發現什麼重要的bug。
• 在設計的時候，由於時間問題和對設計相對於不太重視的原因。

6. 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
   • 由組內大佬審查，嚴格執行了程式碼規範。並建議其他組員如何修改自己的程式碼。
7. 學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
   • 設計對於後續的開發工作時有很大的幫助的，會減少走彎路的時間。不是題目一拿來就開始敲程式碼的。
   • 改進：對開發會更加註重設計，儘量做到兼顧一些細節問題。

2.2.6 測試/釋出（3分）

1. 團隊是否有一個測試計劃？為什麼沒有？ 是否進行了正式的驗收測試？
   • 有一個測試計劃，由前後端共同測試。進行了非正式的驗收測試。
2. 團隊是否有測試工具來幫助測試？
   • 有，我們利用postman來測試介面
3. 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
   • 測試軟體是否能夠正常執行，是否能夠搜尋出正確的結果。執行速度如何，正確性如何。
   • 有用
   • 執行出來的結果應該更加優化一下介面，提高使用者的體驗感。
4. 在釋出的過程中發現了哪些意外問題？
   • 在釋出的過程中，我們只在web端部署了一下，因為考慮到相關政策、只允許查詢基本的功能。在後續我們會根據釋出體驗進行優化。除了這個，暫時沒有其他問題。
5. 學到了什麼? 如果歷史重來一遍, 會做什麼改進?
   • 在軟體的開發的過程中，軟體測試是極為重要的。即使是測試過很多次後，仍可能會出現很多問題。這需要我們不厭其煩的測試。
   • 改進：更加花時間地去測試。

2.2.7 團隊的角色，管理，合作（3分）

1. 團隊的每個角色是如何確定的，是不是人盡其才？
   • 每個人先表明自己已經基本掌握的技術特長。再根據團隊專案的根本需求來決定每個人該做什麼，該學什麼。最後確定團隊的每個角色。
   • 是人盡其才。
2. 團隊成員之間有互相幫助麼？
   • 自然是有的，無論是前端還是後端，還是其他小組。在開發過程中，遇到自己實在解決不了的問題，都會進行討論研究。
3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？ 每個成員明確公開地表示對成員幫助的感謝

• 蘇偉煌：我感謝陳本源對我的幫助,在他的提示下想到了用抓包工具在手機端嘗試爬取藥監局的藥品名稱資料。也完善了一些小細節
  • 學到了什麼?
    學到了fiddler的簡單使用
  • 如果歷史重來一遍, 會做什麼改進?
    如果alpha衝刺階段重來、應該會在爬取的時候講爬取藥品數縮減到十分之一、講具體藥品的資訊條爬取數量略增、減少大家工作量的同時也能縮減繁瑣的資料清洗。
• 林志煌：我感謝蘇偉煌組長對我的幫助,在他的幫助下，我學會了echarts的基本使用方法。能做出一些簡單的資料視覺化介面。
  • 學到了什麼?
    學會了echarts的基本使用方法
  • 如果歷史重來一遍, 會做什麼改進?
    如果alpha衝刺階段重來，我一定會好好學習，不至於每種東西都是隻涉及一點點，只會一點點，這樣就不用麻煩其他人幫助我一些簡單的問題了。
• 翁敏：我感謝蘇偉煌組長和王毅萍同學對我的幫助,在她的幫助下，我學會了vue的使用及搭建一些基本的網站框架。
  • 學到了什麼?
    vue的入門及搭建頁面
  • 如果歷史重來一遍, 會做什麼改進?
    如果可以重新來遍，我會在九月初課程還未很忙的時候好好學習技術為後面做鋪墊，還是沒有好好珍惜時間，沒有抓緊時間學習新的技術，比如vue框架別人都可以熟練運用構建介面了，自己還只是個入門小白狀態，重來一遍，一定珍惜時間學習。
• 陳本源：我感謝黃艇淞對我的幫助,在他的提示下想到了用fake_useragent解決反爬問題。也完善了一些小細節，感謝蘇偉煌組長合理的任務分配，與任務進展節奏，以及很多good ideas,跟著組長的腳步不慌不燥。
  • 學到了什麼?
    加強了爬蟲能力，突破了防爬取能力
  • 如果歷史重來一遍, 會做什麼改進?
    重新選擇價效比較高的資料進行爬取和處理
• 陳碩：我感謝蘇偉煌組長對我的幫助,在他的幫助下，我學會了如何將資料視覺化美觀，能做出一些相對還行的視覺化結果，也感謝林澤熙的幫助，能和他一起做出視覺化結果及爬蟲。
  • 學到了什麼?
    學會了python資料視覺化
  • 如果歷史重來一遍, 會做什麼改進?
    如果alpha衝刺階段重來、應該會更加努力學習爬蟲相關知識來幫助團隊。
• 黃艇淞：感謝陳本源對我的幫助,在他的提示下想到了用downloaddelay解決淘寶和京東的反爬機制。也完善了一些小細節，感謝組長合理的任務分配以及很多靈感。
  • 學到了什麼?
    熟練了對於各個爬蟲框架的使用
  • 如果歷史重來一遍, 會做什麼改進?
    對於各個網站用不同的爬蟲進行爬取
• 石致彬：我感謝蘇偉煌同學對我的幫助,在他的幫助下入門了後端開發，學會了使用Java操作資料庫以及用springboot框架進行簡單的介面編寫
  • 學到了什麼?
    學到了spring boot的簡單使用
  • 如果歷史重來一遍, 會做什麼改進?
    如果可以重新來遍，我會在前面比較輕鬆的時候好好了解並且學習所需要用到的技術，好好珍惜時間，抓緊時間學習新的技術，比如spring boot框架。現在還只是一個入門階段的小白
• 林澤熙：我感謝蘇偉煌組長的勤勉工作,在他的幫助下，我學會了如何去做好一個團隊的部分，學習了很多課外卻有用的知識，也感謝陳碩同學的合作。
  • 學到了什麼?
    學會了echarts的基本使用方法
    學會如何爬取大量的複雜資料
  • 如果歷史重來一遍, 會做什麼改進?
    如果alpha衝刺階段重來，我會爭取做更多的工作，學習更多的知識，認識更多實用的工具
• 唐勁霆：我感謝蘇偉煌同學對我的幫助，在他的帶領下團隊工作有序進行，也感謝他帶領我一起學習資料視覺化等知識，同時感謝其他所有組員為團隊做的貢獻。
  • 學到了什麼?
    學會了資料視覺化。
  • 如果歷史重來一遍, 會做什麼改進?
    要是能重來，我要提前分配好時間，因為考試和alpha衝刺時間重了，所以複習考試花費了較多時間。
• 王毅萍：感謝組長在工作分配上花費的心思，讓大家能專心做自己的工作。感謝各位組員們的積極配合，讓工作得以有序推進。
  • 學到了什麼?
    再一次被“沒有大致的規劃就很難高效率地完成工作”這一點所痛擊。總之就是更深刻地認識到“工程”的重要性，對自己的能力和短處有了更清晰的瞭解。
  • 如果歷史重來一遍, 會做什麼改進?
    做好規劃！！！時刻提醒自己當下哪些事一定要先用最快的辦法解決。

2.2.8 總結（4分）

• 蘇偉煌：
  1. 應該戒驕戒躁、莫訴無用之苦
  2. 應該多開會、合理分配工作量
  3. 不要急於開工
• 王毅萍：
  1. 規劃是重中之重
  2. 要靜下心做好工作設計
• 唐勁霆：
  1. 調整心態，多接受。
  2. 多學習，多交流，學習其他同學的優點。
  3. 合理分配時間。
• 林澤熙：
  1. 學習知識應該有深度，只是片面的學習會在遇到困難時寸步難行
  2. 自己有很多不如他人的地方，需要增強自己的個人能力
  3. 團隊合作至關重要，好的團隊能有1+1＞2的效果
• 石致彬：
  1. 努力學習，多花時間
  2. 應該多加強與其他成員的溝通，多多聽取他人的建議和意見
  3. 調整好心態
• 黃艇淞：
  1. 做好完整的規劃在進行爬蟲，提高效率
  2. 早點開始學習資料分析方面的知識
• 陳碩：
  1. 要加強團隊溝通能力。
  2. 認識到了自己的不足，知道了許多要學習的東西。
  3. 要多瞭解其他成員負責的工作，從中能學習到很多新東西 。
• 陳本源：
  1. 應該多和他人討論，做好完整的規劃在進行爬蟲，以免造成資源浪費
  2. 應該早些時候開始瞭解pyechart,也就不會學的很匆忙
  3. 多聽取他人意見
• 林志煌：
  1. 應該學習全面，不能只是涉及。
  2. 認識到了自己的不足，今後應該補缺補漏。
  3. 凡事要循循漸進，不能剛開始就想馬上完成，最後什麼也做不出來。
• 翁敏：
  1. 珍惜時間，充分學習。
  2. 學會交流溝通吧，自己性格原本就是偏安靜喜歡盲幹，但是接受新的思想新的見解就會有新的認識，別人真的很優秀，多溝通可以有新的收穫。
  3. 相信自己，不要妄自菲薄，努力就完事了，剩下的時間好好學習吧，不要浪費時間，畢竟大學也快結束了。

全組總結(捨不得刪實在是)

• 1.你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
  • 我們認為目前團隊還處於CMMI一級，執行級的檔次，因為只有少部分組員以前接觸過專案開發，大多陣列員都沒接觸過。還有很大的提升空間。
• 2.你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
  • 我們認為團隊目前處於磨合階段，但應該很快能達到規範階段。
• 3.你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?
  • 最明顯的是，團隊中每個人的技術能力得到了進一步的提升。團隊分工更加地合理明確。專案的基本部分已經實現。
• 4.你覺得目前最需要改進的一個方面是什麼?
  • 我覺得現在最需要改進的方面是在規劃方面做得更好，以及加上提高使用者自身的體驗，還有減緩組內浮躁的情緒。
• 5.對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
  • 團隊合作，每日互動：業務人員與開發者在專案進行中，必須每天一起工作。
  • 事例：我們組內幾乎每天都會在群裡討論學習，進行一定的進度報告和互動。
  • 持續交付，小步快跑：經常交付可用的軟體（系統），頻率可以從數週到數月，以較短的時間間隔為佳。
  • 事例：在組內的每個小隊中，都會把工作分成一部分一部分去進行。例如前端小隊中：實現頁面，實現與後端對接，實現搜尋功能。等等，交付的頁面每次都有功能的新新增。
  • 精簡產品，杜絕浪費：精簡——精髓是要盡最大的可能，排除不需要做的工作
  • 事例：之前一直討論的鬧鐘提醒定時吃藥功能被摒棄了，原因是手機都會自帶鬧鐘功能，若硬加功能，有點畫蛇添足。