5組 Beta衝刺 總結

2022-09-10 01:15:21 字數 2505 閱讀 1370

現場答辯總結:

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

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

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

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

全組討論的**:

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

團隊成員

分工情況

任務比例%

吳振溢前端、爬蟲

11%林蔣輝

伺服器部署

11%黃朝威

爬蟲主要負責人

15%周浩東

部分後端介面

14%周偉傑

部分後端介面、爬蟲

11%張樂芃

前端和前端伺服器部署

11%潘春佳

文案8%

陳宇揚爬蟲

11%蔡樹峰

文案8%

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

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

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

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

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

是否有充足的時間來做計畫?

團隊在計畫階段是如何解決組員對於計畫的不同意見的?

原計畫的工作是否最後都做完了? 如果有沒做完的,為什麼?

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

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

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

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

在計畫中有沒有留下緩衝區,緩衝區有作用麼?

將來的計畫會做什麼修改?(例如:緩衝區的定義,加班)

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

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

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

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

你有沒有感到你做的事情可以讓別人來做(更有效率)?

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

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

我們採用了什麼辦法決定「推遲」和「必須實現」的功能?

專案的出口條件(exit criteria – 什麼叫「做好了」)有清晰的定義麼?

對於可能的變更是否能制定應急計畫?

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

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

設計工作在什麼時候,由誰來完成的?是合適的時間,合適的人麼?

設計工作有沒有碰到模稜兩可的情況,團隊是如何解決的?

團隊是否運用單元測試(unit test),測試驅動的開發(tdd)、uml, 或者其他工具來幫助設計和實現?這些工具有效麼?

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

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

暫無設計開發經驗不足,預見性不夠。沒有專門負責code review的成員。

**複審(code review)是如何進行的,是否嚴格執行了**規範?

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

團隊是否有乙個測試計畫?為什麼沒有? 是否進行了正式的驗收測試?

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

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

在發布的過程中發現了哪些意外問題?

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

團隊的每個角色是如何確定的,是不是人盡其才?

團隊成員之間有互相幫助麼?

當出現專案管理、合作方面的問題時,團隊成員如何解決問題? 每個成員明確公開地表示對成員幫助的感謝 (彙總至組長部落格):

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

列出組內所有人的心得。

5組 Beta衝刺 總結

現場答辯總結 適配在正方形螢幕上翻了車,不過評測組用自己的電腦看了應該問題不大 問的問題主要都和政策檔案的齊全性有關,首先部分省份的省檔案庫中就包括了地級市,而有些沒有,導致了與人們印象中政策檔案數量的差異。比如內蒙古的省檔案庫里就包括了地級市,導致其政策活躍度看起來很高。再加上部分省份難以爬取,獲...

5組 Beta衝刺 總結

現場答辯總結 適配在正方形螢幕上翻了車,不過評測組用自己的電腦看了應該問題不大 問的問題主要都和政策檔案的齊全性有關,首先部分省份的省檔案庫中就包括了地級市,而有些沒有,導致了與人們印象中政策檔案數量的差異。比如內蒙古的省檔案庫里就包括了地級市,導致其政策活躍度看起來很高。再加上部分省份難以爬取,獲...

8組 Beta衝刺 總結

現場答辯總結 根據老師的指導和建議,我們充分認識到了我們的不足。一是工作量不足,在這次衝刺中我們仍然沒有很好的完成這個專案,前端效果和ui設計還需要進一步改善 二是產品的測試需要加強,還存在一些bug 三是產品的展現,在答辯展示時,選取的例子需要具有代表性。非常感謝老師和同學們的建議。全組討論的 評...