組長部落格鏈結
專案總體進展充分
應該更深度地去挖掘爬取下來的大量資料潛在的含義
在柯老師的建議下、會專門寫一篇部落格分享慢慢買**的爬取克服。
成員名本次作業具體工作
貢獻度蘇偉煌
團隊選題報告ppt審核、部落格撰寫
12%林澤熙
修改報告、完善需求分析
9%黃艇淞
報告排版處理
9%陳本源
成果展示整理（答辯用）
10%陳碩
成果展示整理（答辯用）
10%翁敏
ppt製作
10.03%
石致彬統計組員心得感受
9.97%
林志煌統計組員心得感受
8%王毅萍
原型設計製作、類圖整理
9.98%
唐勁霆修改報告、完善需求分析
10.02%
我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述 ？
我們的軟體需要收集藥品的資料，對藥品的**進行分析視覺化，盡量讓藥品的**資訊變得透明。目前來看，我們的定義主體上還是比較清楚地，邊界比較明顯。對於典型使用者和典型場景也有比較清晰的描述。
我們達到目標了麼?（原計畫的功能做到了幾個？ 按照原計畫交付時間交付了麼？ 原計畫達到的使用者數量達到了麼?)
我們的目標大部分完成了，還剩下一些部分需要進行完善，原計畫的功能基本都完成了，比如要求的資料的爬取，前端的視覺化圖展示等。目前還沒有進行部署，使用者數量為0，暫時沒達到原計畫使用者數量
使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
使用者量目前為0因為還沒部署到伺服器，和我們預先設想的暫時不一致，使用者對重要功能的接受程度因為還沒上線暫時無使用者所以還無法調查，但是我們小組成員在進行執行時大部分功能實現的效果還行，我們認為我們正逐漸在靠近目標
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
會將分工進行細分，具體職責分配到位，以提高開發的效率，推進專案程序。並且要適當提高開會的頻率，跟進專案的進度。
是否有充足的時間來做計畫?
是。雖然有許多組員課程很多考試也很多並且都擠在一塊了沒什麼時間，但是也有幾個組員時間較為充裕且願意為小組花時間來做一些規劃。
團隊在計畫階段是如何解決組員對於計畫的不同意見的？
團隊成員意見不統一時，我們會多徵求意見，集中思考解決方案，盡可能得到乙個總體上大家都能接受的結果。團隊成員大家都可以相互理解相互體諒，因此也沒有出現不可解決的矛盾，大家都能和氣地商量解決
原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
沒有全部都做完，因為大部分人都需要從頭開始學習，學習成本很高，再加上其他課程的學習和考試，導致最後在專案開發的時間較少，暫時沒有全部完成所有功能的具體實現
有沒有發現做了一些之後看來沒必要或沒多大價值的事?
有。主要是爬取時候的技術方面。
是否每一項任務都有清楚定義和衡量的交付件?
是，每乙個任務都有最少完成的指標。
是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
不是都按照計畫進行，出的意外就是伺服器配置太過垃圾，而且沒有估計到的乙個風險是流量消耗太快，因為以前沒有過伺服器的使用經驗所以沒預估到
在計畫中有沒有留下緩衝區，緩衝區有作用麼?
有。緩衝區可以讓專案更有容錯率，雖然不能搞定所有但是至少能在ddl前解決一些問題
將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
將來的計畫就是組內大家再衝一波，加個班，在ddl前盡最大努力完成
學到了什麼? 如果歷史重來一遍, 會做什麼改進?
學到了在專案過程中分工明細很重要，如果再來一遍會更加細緻地進行分工，設定好各個部分的負責人，共同推進專案的進展
我們有足夠的資源來完成各項任務麼?
有，人力物力都有基本保障。
各項任務所需的時間和其他資源是如何估計的，精度如何?
所需時間和其他資源是根據分配的任務量以及與對應的任務負責人所商量的結果來估計的，精度到以天為時間單位
測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
測試的時間和人力和軟體/硬體資源較為足夠，大家都會盡量擠出時間來進行測試，我們小組人數也夠，開發所需的軟體硬體資源也是有的。對於那些不需要程式設計的資源沒有低估難度，都會指定乙個人來負責
你有沒有感到你做的事情可以讓別人來做（更有效率）?
沒有，我們的給每個人分配的任務都是尊重個人意願且衡量過個人能力來進行分配和調整的
有什麼經驗教訓? 如果歷史重來一遍, 會做什麼改進?
我們應該加強時間觀念，還有對專案進展的跟進。再來一遍的話要改進管理方式，多多注意專案的進展，不浪費一分一秒
每個相關的員工都及時知道了變更的訊息?
我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
根據我們專案需要實現的最基本功能來決定，必要的先做好，錦上添花性質的功能就是在先做完基本要求的前提下再談
專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
有，就是在前端能夠展示出我們想要的資料圖表
對於可能的變更是否能制定應急計畫?
能，小組會積極地進行會議，集思廣益指定應急計畫。
組員是否能夠有效地處理意料之外的工作請求？
是的，組員都很盡力，即使熬夜也會盡量完成
學到了什麼? 如果歷史重來一遍, 會做什麼改進?
一開始指定計畫的時候應該盡可能的考慮充分，讓計畫盡可能的周全，最大限度地避免在專案的進行過程當中做變更，也應該做應急方案，以防萬一。
設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？
比較專案開始的 uml 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 uml 文件？
什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
**複審（code review）是如何進行的，是否嚴格執行了**規範？
學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
團隊是否有乙個測試計畫？為什麼沒有？ 是否進行了正式的驗收測試？
團隊是否有測試工具來幫助測試？
團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
在發布的過程中發現了哪些意外問題？
學到了什麼? 如果歷史重來一遍, 會做什麼改進?
團隊的每個角色是如何確定的，是不是人盡其才？
團隊成員之間有互相幫助麼？
當出現專案管理、合作方面的問題時，團隊成員如何解決問題？ 每個成員明確公開地表示對成員幫助的感謝
林志煌：我感謝蘇偉煌組長對我的幫助,在他的幫助下，我學會了echarts的基本使用方法。能做出一些簡單的資料視覺化介面。
陳本源：我感謝黃艇淞對我的幫助,在他的提示下想到了用fake_useragent解決反爬問題。也完善了一些小細節，感謝蘇偉煌組長合理的任務分配，與任務進展節奏，以及很多good ideas,跟著組長的腳步不慌不燥。
陳碩：我感謝蘇偉煌組長對我的幫助,在他的幫助下，我學會了如何將資料視覺化美觀，能做出一些相對還行的視覺化結果，也感謝林澤熙的幫助，能和他一起做出視覺化結果及爬蟲。
黃艇淞：感謝陳本源對我的幫助,在他的提示下想到了用downloaddelay解決**和京東的反爬機制。也完善了一些小細節，感謝組長合理的任務分配以及很多靈感。
石致彬：我感謝蘇偉煌同學對我的幫助,在他的幫助下入門了後端開發，學會了使用j**a運算元據庫以及用springboot框架進行簡單的介面編寫
林澤熙：我感謝蘇偉煌組長的勤勉工作,在他的幫助下，我學會了如何去做好乙個團隊的部分，學習了很多課外卻有用的知識，也感謝陳碩同學的合作。
唐勁霆：我感謝蘇偉煌同學對我的幫助，在他的帶領下團隊工作有序進行，也感謝他帶領我一起學習資料視覺化等知識，同時感謝其他所有組員為團隊做的貢獻。
第10組 Beta衝刺 總結
因為alpha階段的產品做得偏離了方向，所以beta衝刺大家非常拼命，也拿出了相應的 成果，基本功能已經初步完成，剩下的就只有更多的資料收集和一些bug的修改，以及柯 老闆提出的拍照上傳的功能，我們會在最後的final階段完成的。beta階段的開發階段分為重構首頁，美化地圖，優化推薦功能以及收集資料...
8組 Beta衝刺 總結
現場答辯總結 根據老師的指導和建議，我們充分認識到了我們的不足。一是工作量不足，在這次衝刺中我們仍然沒有很好的完成這個專案，前端效果和ui設計還需要進一步改善 二是產品的測試需要加強，還存在一些bug 三是產品的展現，在答辯展示時，選取的例子需要具有代表性。非常感謝老師和同學們的建議。全組討論的 評...
8組 Beta衝刺 總結
現場答辯總結 根據老師的指導和建議，我們充分認識到了我們的不足。一是工作量不足，在這次衝刺中我們仍然沒有很好的完成這個專案，前端效果和ui設計還需要進一步改善 二是產品的測試需要加強，還存在一些bug 三是產品的展現，在答辯展示時，選取的例子需要具有代表性。非常感謝老師和同學們的建議。全組討論的 評...