軟體工程 事後Postmortem 會議

2022-06-23 22:51:11 字數 1961 閱讀 8653

團隊事後分析會議

會議截圖

設想和目標

1.我們所設計的作品要解決的要求?典型使用者和典型場景?

想要解決當代大學生社團以及交友問題。

典型使用者:在校大學生

典型場景:社團交流、社團招新

2.與之前我們的個人作業和結對作業相比,有什麼進步?

文件寫得更多,技術上的進步,團隊交流以及互相推鍋的能力

3.設計的目標有沒有達到?如果沒有達到,具體原因是什麼?

一開始的目標有偏差,由最初的聊天系統偏離到社團管理,**量過多導致不能按期完成。

預期目標過於龐大,我們的目標整個完成就相當於兩個作品的**量。

前端技術問題也導致了目標沒有完美實現。

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

計劃時間充足,但是學習技術時間相對較少。

2. 團隊在計劃階段是如何解決同事們對於計劃的不同意見的?

進行少量討論之後達成共識,但還是缺少更多的商討時間。

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

前端:沒有做完,由於技術問題

後臺:完成

測試:完成

釋出:完成

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

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

實現介面定義之後交付給後臺進行連線。

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

幾乎沒有風險,最主要的就是併發量,沒有對作品進行壓力測試(其實主要是伺服器端的壓力測試)。

由於最初的估計使用者數量比較低,沒有想到這一點。

還有可以通過直接修改位址列中使用者名稱,會直接使用其他的使用者名稱切換使用者。

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

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

根據自己之前打**的經驗估計,精度有誤差但在接受的範圍內。

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

測試資源、人力、時間足夠。

剛開始上手會覺得很簡單,隨著時間會逐漸覺得變難。剛開始覺得前端就只是設計一下樣式,結果後來發現還有與後臺對接以及邏輯指令碼設計等,就比較棘手。

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

釋出:覺得自己的部分並沒有安排很好,因為演示的書序比較靠前,有些緊張還沒有準備好演示內容。

設計/實現

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

在編寫規格書之前,由前端與後臺一起進行設計。

時間上來說,有一些緊張,因為任務拖到了還剩兩三天。

人選是很合適的,由實現人員作為主導,更容易完成。

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

沒有,意見幾乎一致。

測試/釋出

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

測試涵蓋了作品的大部分功能,但是由於對程式語言的不熟悉導致不夠深入。

2.釋出過程中遇到的問題?

團隊角色管理/合作

1.影響進度和作品完成度最大的原因?

技術問題,很嚴重。

2.隊長是否起到了積極作用?

有起到積極作用。

3.在完成相關任務的時候,有沒有與其他隊員進行協調?

有,但團隊內部交流不夠。

4.團隊內部氛圍?

雖然我們整體技術不強,但是團隊內部互幫互助還是很強的。

團隊內部貢獻分規則

團隊貢獻分

姓名貢獻分

尚通93.5

孫爭80

李彥霆77

王卓75.5

賴學程47.5

廖浩任44

專案複審請見: