團隊事後分析

2022-09-12 07:36:13 字數 1989 閱讀 1233

gamma階段原計畫的密碼找回功能,排名功能,移動端的適配功能等均做到了,按照時間交付了,原計畫的目標使用者200已經達到,目前django後台記錄的數目為243個使用者。

整個團隊的軟體工程質量提高了,我們有wiki來儲存所有的完整文件,所有的檔案均有完整的注釋,並且通過code review,測試保證等方式確保了**質量。

這個階段我們確定了任務的優先順序,改進了燃燼圖,加了任務總量這條曲線,pm能更好地把控任務進度。因為家庭的原因,pm有段時間未在學校,如果重來一遍的話,pm應該會更加注重進度的把控,隨時push團隊成員。

我們在每個階段的末尾都會提前討論下一階段的任務,在階段的開始又會再次確定好階段任務,因此是有充足的時間來確定計畫的。

我們都是當面討論,討論任務的可行性和複雜性,針對大家提出的考慮來判斷是否要做這個任務。

都做完了,只是部分任務的完成度沒有太高,因為時間還是有一定的不足。

前端的分頁功能,實現起來太過於複雜,總是出問題,其實現在覺得讓後端分頁更簡單。

有。每個任務都確定了優先順序以及相關人員。

基本按照計畫進行。安全性問題在alpha初期沒有考慮到,準備新增在beta階段任務中,但是在alpha階段末尾**突然被攻擊,因而採取了一定的緊急措施,恢復了**的正常功能,避免了再次被攻擊。

留下了一定的緩衝區。任務執行時出現突發情況時,緩衝區就能夠避免任務總體進度出問題。

完成所有基本功能的資源足夠,但是在完成一些比較麻煩的功能例如移動端適配的時候,時間不太足夠因而不太完美。

主要是由開發和測試人員依據alpha,beta的經驗來估計,精度比較準確。

資源足夠,對移動端的適配低估了難度。

我們使用了自己設計的燃盡圖,其中有一項是當前任務總數,pm能抓住重點,及時判斷任務能否完成,進而將下一階段的任務提前或者砍掉某個任務。當某階段任務穩定並且全部完成後,就達到了該階段的出口條件。

我們有一定的應急計畫,比如我們在**受到攻擊時,應急修復,在1.5小時就讓**成功重新上線,盡可能減少了使用者的損失。團隊對於這類意料之外的任務處理起來也比較順利,隊員能主動認領,有效處理。

後端的設計工作是在後端的線上會議的時候敲定的。設計由後端的兩位同學,結合專案具體情況,共同擬定。前端的設計工作是由ui和前端開發成員你一起決定的。

在設計中,我們遇到了這樣的情況。比如,原專案中,並沒有採取前後端分離的設計方式,而是由後端全部完成,返回html給前端。我們在發現了這個設計之後,經過討論,覺得不符合我們的專案設計。決定更改整體的設計。

後端的**複審,通常是一位後端的開發在完成了自己的任務後,通過issue或者即使通訊軟體的形式,聯絡另一位後端開發同學,通知他開發已經完成。再交付測試同學之前,另一開發同學需要閱讀實現了的**,結合已經擬定好的後端介面文件,以及**的規範要求,對於**的功能已經標準性進行複查。如果遇到不合規範的情況,會在issue以及即時通訊工具中提醒,要求開發人員進行更改。

團隊有完整的測試計畫。也有測試工具,並且進行了驗收

沒有考慮到測試樣例執行速度的問題,雖然是放著跑一下就完事了,但會佔著那麼久電腦,而且每次跑都要跑那麼久確實是個問題。

測試樣例的管理問題,雖然我當初的理想是使用tag進行管理。但事實上對上百個樣例使用tag來進行管理真的是個折磨。一套更方便的管理系統可能更好,這有助於在測試樣例執行速度無法提公升的情況下選擇性地進行測試。

對需求變更的即時響應問題,雖然我使用了page object方便了同類測試樣例的批發式編寫,但問題是當page本身發生變更時,我的即時響應方面,雖然工作量不大,但存在較高的抽象複雜度。因為我和前端那邊對頁面的抽象方式不同,所以每次他們修改我都要想想怎麼適配成我這邊的邏輯。手工工作量是減少了,但思維工作量增加了。

團隊目前的磨合非常不錯,處於「創造」階段。整個gamma階段,在pm因特別原因的缺席下,也能不延期地完成所有任務。同時團隊成員也注重了軟體工程的質量等,對安全性測試,相容性測試,以及使用自動化測試工具等都非常熟練,相比起alpha階段和beta階段來說,我們組已經成為乙個相對「成熟」的軟體工程團隊~

團隊作業6 事後分析

每個人都會遇到大大小小的問題,解決這些問題只有當面交流,現場除錯修改的效率才是最高的。我們五個人都是第一次做這種專案類的挑戰,我們明顯覺得單打獨鬥是沒有用的,團結就是力量,每個人的鼓勵都是這個外賣軟體前進的每一步。計畫是否有充足的時間來做計畫?不太夠,後面遇到一些,例如後台管理評價系統有些不太懂,又...

團隊作業9 事後分析(Beta版本)

設想和目標 能監聽手機的來電事件,同時對歌詞檔案的獲取時常會不顯示這個功能未能完善。只按照原計畫交了乙個比較完善的版本。因為這個專案對我們組來說是屬於學習的階段,所以還達不到上線的程度,自然,原計畫的使用者數量沒有達到。跟上乙個階段相比,團隊的開發效率明顯 提高了,分工也更明確了。出錯,因為第二階段...

團隊作業9 事後分析(Beta版本)

1.我們的軟體要解決什麼問題?是否定義得很清楚?是否對典型使用者和典型場景有清晰的描述?單個系統的部分功能 是 是 2.我們達到目標了麼 原計畫的功能做到了幾個?按照原計畫交付時間交付了麼?原計畫達到的使用者數量達到了麼?完成原計畫第一部分的需求 3.和上乙個階段相比,團隊軟體工程的質量提高了麼?在...