M1事后分析報告


設想和目標

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

  我們要解決的是用戶通過移動端學習北航MOOC精品課程的問題,定義很清楚,典型用戶是北航校內的學生以及想要學習

北航精品課程的校外人群,使他們能夠在有網絡情況下隨時隨地進行學習,因為現在北航MOOC網上的資源還不是很豐富,所

以有待於網站的繼續建設,更好的內容才能吸引更多的用戶。

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

  時間不是很充足,因為當時拿到學長的代碼就晚了一些,為了趕作業的deadline,就倉促的把任務分成了三大塊,並沒

有很好的評估每一項任務的難度還有工作量。

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

  剛開始的計划不是很詳細,而且大家對Android開發也沒有什么概念,在討論之后就直接同意了分配的任務還有進度的安

排,並沒有出現什么反對的意見。

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

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

 計划

1. 你原計划的工作是否最后都做完了? 如果有沒做完的,為什么?

  計划中的工作最后沒有全部完成,因為之前對聯網部分的難度估計不正確,而且和學長的聯系也不順暢,所以最后在聯

網部分卡住了,最后我們一起忙這塊又導致UI部分做的比較粗糙。其它的功能我們都已經基本實現了,就因為網絡連接拿不

下數據下來,最后M1階段項目失敗。

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

  我們在開發的第二周一直在看學長的代碼,后來發現Android平台和IOS平台差異,我們沒辦法對他的代碼進行改寫,只

能重新編寫,只有服務器端我們能夠使用學長的一些接口,最后還沒有連接成功,所以這部分工作的價值不大。

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

  沒有,剛開始的任務分的很大,就兩個人負責其中一塊,后來因為各部分的進展不一致,而且好幾名隊員的實力差一些,

進度很緩慢,PM也沒有對開發的任務細節有很多的了解,所以就導致任務的定義還有團隊之間的交付出現了問題。

4. 是否項目的整個過程都按照計划進行,有什么風險是當時沒有估計到的,為什么沒有估計到?

  整個過程和計划出入還是挺大的,主要有兩點,一個是聯網部分的難度和計划出入很大,從學長IOS代碼中找出服務器接

口的設置有些難度,第二個是開發的進度拖慢了,原因部分是實力問題,還有部分是有些隊員的積極性不高,沒有主動去完

成任務。

5. 在計划中有沒有留下緩沖區,緩沖區有作用么?

  計划中的緩沖區是兩個周六和周日,緩沖區作用沒有想象中大,周一到周五因為有課的原因可能時間不夠,但是周末是

有時間的,所以想着大家會認真做項目,后來發現周六日大家的工作效率很低,而且中間有一次假期,玩兒的過多了。

6. 將來的計划會做什么修改?(例如:緩沖區的定義,加班)

  在下個階段我們會重新制定計划,先讓一個人專門負責UI的設計,我們剩下的人集體把網絡的問題搞定,實力差一些的

隊員就跟着學,要求每個人每天拿出自己寫的東西,即使是學習的東西也可以,就是任務分配更加機動一些,確保讓每個成

員都參與進來有自己的任務。

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

 資源

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

  有的,有代碼,有隊員,有學長。

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

  當初分配任務是根據學長在IOS上的開發經驗來的,任務分成了三大塊,時間是按照項目總體持續時間,就是四周(實際

上只是三周)的時間來分配的,精度不怎么准,主要還是經驗問題,對每項工作的內容和難度估計不准。

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

  項目最后沒有完成,測試就很簡陋,對不需要編程的工作難度估計有些偏低,沒有想象中那么輕松。

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

變更管理

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

  我們通過QQ討論組等一些通訊工具,將變更及時告知給位成員。

2. 我們采用了什么辦法決定“推遲”和“必須實現”的功能?

  我們的項目中客戶端的功能比較少,為了第一階段的展示,我們團隊投票同時也根據功能實現的難度來決定“必須實現”

的功能,其他的功能可以先推遲。

3. 項目的出口條件(Exit Criteria – 什么叫“做好了”)有清晰的定義么?

  有的,我們參照的是學長做出來的那個版本,我們能夠把那個版本中的功能全部實現並且測試之后沒有bug算是最終完成。

4. 對於可能的變更是否能制定應急計划?

  沒有,最初考慮的沒有那么多,而且項目中間也沒有什么大的變化,最后連接服務器我們是采用本地的視頻調用模擬了

一下。

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

  因為團隊中有的成員實力不強,然后實力強一些的帶着實力弱一點的,意料之外的工作我們討論之后就直接進行了分工,

團隊中並沒有什么爭議。

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

 設計/實現

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

  設計工作在項目開始的時候,學長為我們演示過軟件之后,PM對工作進行了粗略的估計並進行了分配,時間是合適的,

過因為PM本身對Android開發不熟悉,所以分配任務會有一些偏差。

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

  開始分配任務的時候因為每個人都是新手,所以不知道該給什么人分配什么任務,就讓大家自己選擇,看隊員自己對哪

一部分比較感興趣,這樣最后確定的任務分配。還有UI界面設計的時候,我們選擇的UI是參照學長的UI進行設計的,這個選

擇是當初投票決定的。

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

測試/發布

1. 團隊是否有一個測試計划?為什么沒有?

  沒有,最開始是因為沒想到,后來是因為沒有時間,而且項目沒有完成,就只在我們自己操作上找出軟件中的bug。

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

  沒有,項目聯網部分沒有完成,很多東西都沒辦法測試。

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

  沒有。。。。。

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

 

總結:

1. 你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?

  目前覺得仍然在初始級,和其他項目團隊相比,我們這方面做得很不好,可能是缺少一個技術核心的人員來帶領,所以

項目隊員之間的合作並不是很緊密,而且遇到自己難以克服的困難的時候團隊里面也沒有很好的求助對象。

2. 你覺得團隊目前處於 萌芽/磨合/規范/創造 階段的哪一個階段?

  仍處於磨合的階段,讓負責開發的幾名隊員之間的配合更加默契,建立良好的信任關系,盡量把代碼規范化,更好地配

合他人的工作。

3. 你覺得團隊在這個里程碑相比前一個里程碑有什么改進? 

     對團隊的任務更加清楚,明白自己應該做的是什么,並且對Android開發的熟悉程度有了很大的提高,實力進一步增強。

5. 你覺得目前最需要改進的一個方面是什么?

  最需要改進的是讓每一位團隊成員都參與進來,有自己的貢獻,即使是做出的成果少一些,但是付出了努力都是很值得

肯定的。

 團隊討論的照片:


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



M1事后分析報告 M1事后分析報告 M1事后分析報告 M1事后分析報告 M1階段事后分析 M1事后分析匯報總結 M1事后分析匯報以及總結 M1事后分析匯報以及總結 M1事后分析匯報以及總結 M2事后分析報告
 
粤ICP备14056181号  © 2014-2021 ITdaan.com