事後諸葛亮分析報告

2022-05-25 14:30:11 字數 4430 閱讀 6160

目錄隊伍名:銀河超級無敵艦隊

專案:招新通

集合貼:團隊作業6——複審與事後分析

一、會議**

二、設想和目標

我們的軟體要解決什麼問題?是否定義得很清楚?是否對典型使用者和典型場景有清晰的描述?
解決招新時的招新成員資料整理繁雜的痛點,定義清楚,是。詳情可見需求規劃說明書。

是否有充足的時間來做計畫?
有。我們通過2場長時間的線上討論會議,確定了軟體的初步框架和需求。在具體編碼的過程中,相應的人員對需求再進行細化、量化,並進行及時的調整。

團隊在計畫階段是如何解決同事們對於計畫的不同意見的?
三、計畫

你原計畫的工作是否最後都做完了? 如果有沒做完的,為什麼?
大部分計畫工作已完成。

部分拓展功能仍未實現。

有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
沒有,每個部分都很必要的。

是否每一項任務都有清楚定義和衡量的交付件?
是,必須能用於實際使用並且沒有功能性bug。

是否專案的整個過程都按照計畫進行?
否,錯誤估計了前端的難度,完成得較計畫略晚一些,但也完成了。

在計畫中有沒有留下緩衝區,緩衝區有作用麼?
沒有,我們計畫了必要功能和拓展功能。

將來的計畫會做什麼修改?
計畫繼續開發,完善功能,計畫可能會增加一些新的功能。

四、資源

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

各項任務所需的時間和其他資源是如何估計的,精度如何?
我們小組設定了pm(產品經理)進行需求分析,並且負責專案的開發進度。pm會針對各項需求分配任務,並且和對應人員討論時間、資源的初步預計情況。據統計,時間精度在1小時左右。

使用者測試的時間,人力和軟體/硬體資源是否足夠?
是。在測試階段,我們進行了兩方面的測試:

一是針對伺服器的介面測試,測試響應時間和響應狀態;

二是針對使用者方面的體驗測試,測試功能是否滿足使用者需求。

在事後總結階段,我們發現使用者測試的時間,人力和軟體/硬體資源充足。

你有沒有感到你做的事情可以讓別人來做(更有效率)?
沒有。根據pm的合理分配,每一項需求都是經過分析和討論再分配給對應人員。保證開發進度、效率最大化。因此,可能我做的事情別人可以做,但是肯定沒我快。

五、變更管理

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

我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
對專案進行分析,確定功能的必要程度,評估功能的難以程度,綜合考量後決定哪些推遲哪些必須實現。

專案的出口條件(exit criteria)是否得到清晰的定義?
是的,在做測試時有明確並執行,測試報告中也有寫明。

對於可能的變更是否能制定應急計畫?
能,我們隊員能力很強,有足夠的應對能力。

員工是否能夠有效地處理意料之外的工作請求?
能,我們隊員能力很強,有足夠的應對能力。

六、設計/實現

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

設計工作有沒有碰到模稜兩可的情況,團隊是如何解決的?
遇到模稜兩可的情況,會在各個成員充分發表意見後,由組長決定方案。

什麼功能產生的bug最多,為什麼?
管理端的檢視社團資訊、檢視報名人員資訊的功能,因為這兩個功能難度超出了一開始的估計,較難實現。

**複審是如何進行的,是否嚴格執行了**規範?
我們的專案基於不同的開發語言。每個語言的**,有1到2名的人員開發。

對於人數大於1的語言**,由人員之間互相審核。

對於人數為1的語言**。通過**自審和**測試軟體進行審核。

經過**複審,我們的專案開發**嚴格遵守了**規範。

七、測試/發布

團隊是否有乙個測試計畫?為什麼沒有?
是。後續有一系列對程式響應狀態、響應時間的測試。

是否進行了正式的驗收測試?
是。我們有一套對程式響應狀態、響應時間的測試,目前的專案已通過。

團隊是否有測試工具來幫助測試?
是。使用postman。

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

一是開發者方面。通過後台的日誌對軟體平時的效能進行跟蹤;

二是使用者方面。我們設定了客服,使用者可以對客服反饋軟體的使用情況,進而跟蹤軟體效能。

在發布的過程中發現了哪些意外問題?
無,一切順利。

八、團隊的角色,管理,合作

團隊的每個角色是如何確定的,是不是人盡其才?
各自說明自己的長處和意願、結合根據專案的需要,大家選擇自己想要的角色或者為專案折中。

是的,人盡其才。

團隊成員之間有互相幫助麼?
有。當團隊成員有人出現在技術上的困惑時,團隊內的其他成員會及時地給予解答以及解決方案。

當出現專案管理、合作方面的問題時,團隊成員如何解決問題?
並沒有出現這樣的問題,我們關係親密、溝通良好、合作愉快。

九、總結

對於軟體工程的理論,規律有什麼心得體會或不同意見?
在經過了乙個多月的計畫、編碼的團隊經歷後,我們發現,當我們對於產品的設計、需求的實現、專案的管理產生困惑與不解時,在課堂中老師講解的案例、理論都能對應上我們碰到的一些難題,可以從中尋找到解決辦法。

對於人的領導和管理, 有什麼具體可以改進的地方?
管理者在領導和管理時,要注意促進資訊的有效流通,維護團隊開發的良好氛圍,為專案實現提供信心,合理的分配和調整各名成員的任務。

你覺得目前最需要改進的乙個方面是什麼?
專案整體的計畫可以再詳細、再合理一些。

對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
個體鬥志強,大家對開發專案的態度積極。

團隊間傳遞資訊的效率高、效果好。

**管理的質量具體應該如何提高? **複審和**規範的質量應該如何提高?
更嚴格規範的專案管理,每日進行**複審。專案管理人員和開發人員要遵守**規範的要求。

其它軟體工具的應用,應該如何提高?
對於伺服器負載能力的測試我們沒有很好完成,後續應該學習相應軟體的使用並完成測試。

專案跟蹤使用者資料方面,計畫要提高什麼地方?例如你們是如何知道每日/周活躍使用者等資料的?
計畫提高方面。我們是通過伺服器、後台的請求次數來判斷使用者是否活躍、活躍程度以及主要的活動型別,從而判斷使用者的使用習慣,

專案文件的質量如何提高?
首先是多觀摩、上手,對於專案文章的大體框架要有乙個屬於自己的理解,不能只是千篇一律的套模板。其次是要尋找機會參與專案,讓自己擁有能夠真正去參與乙個專案的計畫到落地,有乙個完整的專案經歷,這樣能夠更加有利於自己迅速上手專案文件的撰寫。

十、團隊成員角色與貢獻

姓名學號

角色角色貢獻分

可驗證貢獻

郭奕材3118004959

組長、管理端開發

18.5

開會、寫部落格、管理端划水開發

劉婉兒3218004994

設計師20.1

ui設計、pm

辜仰淦3118004957

後台20.2

端茶倒水寫後台

王煜墉3118004972

管理端開發

20.3

管理端主力開發

陳 餘3118004952

小程式開發

20.4

小程式端開發

姜達成3118004964

文件撰寫、小程式開發

20.5

撰寫文件、小程式混子

事後諸葛亮分析報告

我們的軟體要解決什麼問題?是否定義得很清楚?答 日常生活中,我們常常會為自己制定計畫或目標,並給這些計畫和目標定下完成的期限,於是light note網頁版備忘錄應運而生,旨在督促和鼓勵使用者在規定的期限裡完成自己制定的目標,應用的定義也較為清楚。我們達到目標了麼 原計畫的功能做到了幾個?按照原計畫...

事後諸葛亮分析

這個作業屬於哪個課程 這個作業要求在 homework 11154 這個作業的目標 事後分析報告 目錄1.我們的軟體要解決什麼問題?是否定義得很清楚?是否對典型使用者和典型場景有清晰的描述?答 我們軟體主要解決班級裡面用通知群作為通知手段的一些痛點。定義其實並不是特別清楚,還有一些場景沒有描述。2....

事後諸葛亮分析

一.設想和目標 1.我們的軟體要解決什麼問題?是否定義得很清楚?是否對典型使用者和典型場景有清晰的描述?我們的軟體預期在實現最基本的打卡工具的基礎上,新增番茄鐘專注功能和社交圈子吸引使用者,定位明確。但有些使用邏輯略顯累贅,後期稍有修改,但還有地方可以做到更好。2.我們達到目標了麼 原計畫的功能做到...