事後諸葛亮分析

2022-07-11 12:06:12 字數 2236 閱讀 8051

這個作業屬於哪個課程

這個作業要求在**

/homework/11154

這個作業的目標

事後分析報告

目錄

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

答:我們軟體主要解決班級裡面用通知群作為通知手段的一些痛點。定義其實並不是特別清楚,還有一些場景沒有描述。

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

答:有充足時間來做計畫

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

答:先一起商量,不行就聽組長的

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

答:使用者量少,使用者對重要功能的接受程度和我們的預想有一定差距,主要是有些地方沒優化好。不過離目標還是更近了

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

答:教訓就是在招兵買馬時要快,不然高手都被別人搶走了。。。還有就是衝刺前要確定隊員們對於要用的技術熟練到什麼程度

如果重來一遍,我們會把使用者需求做的更好,收集不同使用者的需求再衝刺

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

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

答:有,寫sql語句,大部分都可以通過框架自動實現

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

答:基本上是,但有一些因為團隊實力原因,沒法分的更細

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

答:基本上是按照計畫進行,唯一意外就是團隊沒有人學過linux

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

答:有,緩衝區讓隊員有充足時間去實現,遇到沒有學習到的知識還能去學習之後再實現

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

答:時間充足,但技術不夠,經驗也沒有

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

答:pm根據個人的學習程度估計的,精度一般

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

答:一開始應該抓緊時間學習,某個隊員專攻某個方面

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

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

答:用那個四個象限的方法決定的

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

答:功能正常執行,沒有影響使用的嚴重bug,較少的不影響使用的bug

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

答:是的,比如我們留下了緩衝區。

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

答:是的。

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

答:經過討論決定人員。合適的人,時間也還行

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

答:有,都是怎麼簡潔怎麼來

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

答:有使用

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

答:上傳的bug最多,原因是前端直接用的別人的元件,難以進行定製化。主要是沒有開發和設計經驗

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

答:pm人工檢視,大體上做到了**規範

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

答:在設計時應該積極溝通,在實現前建議各個任務的負責人對設計有清楚的認識

團隊是否有乙個測試計畫?為什麼沒有?

答:有是否進行了正式的驗收測試?

答:進行了主流瀏覽器的測試

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

答:沒有,都是手動測試,因為現階段專案不大,功能也少。

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

答:伺服器到期了沒續費

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

答:自動化測試對於程式來說還是很重要的,雖然現階段工程小沒有必要,以後會去系統的學習測試方法

你覺得團隊目前的狀態屬於 cmm/cmmi 中的哪個檔次?

答:初始級

你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段?

答:萌芽階段,還是有很多很多很多需要學習的地方。

你覺得目前最需要改進的乙個方面是什麼?

事後諸葛亮分析

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

事後諸葛亮分析

目錄我們的軟體要解決使用者想聊天卻找不到人時,可以在網路上找到有緣人排洩情緒。在前面的部落格中已經有很清楚的定義和對典型使用者和典型場景有清晰的描述。團隊有充足的時間來做計畫,同事們對於計畫的不同意見時,先相互辯論,如若不能解決,則採取各退一步的方式進一步協商。每一項任務都有清楚定義和衡量的交付件,...

事後諸葛亮分析報告

目錄隊伍名 銀河超級無敵艦隊 專案 招新通 集合貼 團隊作業6 複審與事後分析 一 會議 二 設想和目標 我們的軟體要解決什麼問題?是否定義得很清楚?是否對典型使用者和典型場景有清晰的描述?解決招新時的招新成員資料整理繁雜的痛點,定義清楚,是。詳情可見需求規劃說明書。是否有充足的時間來做計畫?有。我...