M1階段事后分析


M1階段的開發結束了,在周四的課上我們組也進行了alpha階段的匯報。我們的努力得到了應有的回報,下面我們將針對M1階段產生的一些問題進行分析和反思。

一.設想和目標

1.我們的app更像是一款針對北航學子的“知乎”應用。這款app可以實現基本功能:用戶管理、搜索、分類、上傳下載、用戶貢獻與交互等。

2.在alpha階段,我們利用第一周的時間對學長的代碼進行解讀和分析,制定出相應的計划。我們認為制定計划的時間是非常充裕的,但是由於我們的經驗不足,在測試原有網站的功能時出現了一些問題,導致后期修改原代碼中的bug占據了過多的時間。

3.由於團隊中只有一個人是真正做過安卓應用開發的,在制定大體計划時並沒有產生多少分歧。可能在開發過程中遇到其他問題時,團隊的核心技術人員會根據情況不同給出不同的解決方案。我們一直處於多溝通,多交流的開發模式,我認為這也是整個團隊能夠在alpha階段取得階段性成功的重要因素之一。

首先,由於我們的搜索功能在今天才正式完成,還沒有將應用放在其他平台上推廣,因此用戶量比較少。但是我們對alpha階段的成果進行使用測試的時候,基本的功能已經能夠使用了。這也說明我們一個月的項目開發是成功的,盡管經歷了一些波折。

因為最后作報告的時候才發現其他做有關“學霸網站”的小組拿到和我們一樣的代碼,bug也是很多。如果歷史重來一遍,我們可能一開始就會召集四個組的成員集中精力先修改bug。我們組的隊員能力很強,但也花了將近10天的時間去修復。如果一開始就讓四組同學一起商量分析修改bug,可能我們還會做的更好。

 

二.計划

1.我們原有的計划就是初步實現學霸網站的基本功能,事實上,在組員將近一個月的熬夜后我們也確實完成了。

2.一個月的開發時間,每一個人都在盡自己最大的努力去做好每一件事。我們只在過程中發現我們自己的一些不足,但是還沒有發現哪件事做了無用功。

3.在並不熟悉項目的時候,每個人都是摸索着盡量不去糾結細節,只求做出大概的一個成果,在beta階段再繼續修復。

4.項目的計划是第一周解讀代碼,第二周和第三周進行軟件開發,第四周進行測試,當然這是非常理想的一個狀態。但是在開發的過程中我們遇到兩個比較大的挑戰,打亂了我們的計划。第一次挑戰是在測試原代碼的時候,發現的bug讓我們的項目在10天內幾乎沒有進展。第二次挑戰是在第三周周末的時候發現了一個連接數據庫的重大問題,為了解決這個問題我們又花費了將近一周的時間去調整。究其原因,還是我們開發項目的經驗不足,沒有想到各方面的問題。但是這也成為我們今后項目開發的一個經驗教訓。

5.本來計划有三天左右的緩沖時間,但是在接連遭遇兩個挑戰后,我們的緩沖區沒有了。慶幸的是,組員的技術很強,這才能讓我們的軟件如期發布。

6.在將近一個月的時間內,組員在項目上花費的時間是平均每天5-6個小時。核心技術人員平均每天將近十幾個小時,遠遠超出了我們計划的工作時間。因為我們的軟件已經能實現基本功能,因此下一階段的主要任務就是修復bug。

 

三.資源

1.組員的能力強是我們項目最終得以成功的最重要的保證。最初我們可能還是低估了這個項目的難度,后期遇到的問題也着實給了我們很大的打擊。

2.各項任務的最初分配是由核心技術人員討論得到的。在開發過程中,PM根據每人每天的工作量酌情分配。

3.我們在開發的過程中就做了簡單的測試,由於存在的bug確實比較多,我們打算在Beta階段做更加細致的測試。

4.我們在項目開始前就經過會議討論了每個人的強項,技術不行的就去認真寫文檔,技術能力強的就帶領大家一起攻克一個個難題。

 

四.變更管理

1.我們在項目初期就建立了一個QQ群,方便大家隨時交流。因為項目中有兩位女生,沒法和男生隨時碰面交流,因此QQ群的交流顯得極為重要。

2.因為軟件的基本功能確定,我們在決定一個功能是推遲實現還是必須實現時是圍繞基本功能確定的。和基本功能相關的,影響alpha階段成果的功能是必須實現的。

3.我們在認定軟件的出口條件時以是否能夠實現基本功能為准則,如果能夠實現,那么可以發布。

4.對於之前遇到的一些問題和挑戰,我們都及時召開會議商討解決方案。因為在項目中,我們在前端設置了兩名人員,后端有兩名人員,還有一位機動人員,相對能力更強一些,可以隨時處理一些應急事件。

5.從團隊創立到現在,我們沒有一個人因為懈怠而放棄自己的工作,每個人幾乎拿出了200%的熱情去對待項目。意料之外的工作請求大概每天都會出現,主要原因還是原有代碼中問題過於多,以至於在進行開發的過程中,不得不花費超出一倍的時間去修復,而不是去創造。

 

五.設計/實現

1.設計工作在項目開始的第一周結束的時候由團隊中熟悉安卓應用開發的人員完成了。因為第一周開會的時候計划先看一周代碼,在這一周的時間內大家互相幫助盡可能多的讀懂代碼,然后再進行開發。我們的項目可能在設計上不用太費工夫,需要我們考慮的是每個人的分工。

2.設計階段並沒有產生模棱兩可的情況。

3.因為開發時間非常長,導致沒有進行深入測試,將在下一階段進行。

4.在測試階段,發現用戶管理和搜索兩個部分的bug非常多。主要是因為原有代碼中這兩部分幾乎是空殼功能,團隊的兩個人分別負責這兩個部分。在不到兩個禮拜的時間內處理完這么多的bug非常難。

5.前端后端分別有兩名開發人員,並且一名機動開發人員可以隨時互相審閱代碼,查出漏洞。

 

六.測試/發布

1.初期我們確實制定了一個測試計划,預計是在第四周進行。但是開發在第四周才結束,並且開發過程中做了一些小的測試,所以最后計划沒有實現。

2.暫時還沒有進行正式的驗收測試。

3.發布的過程中由於發布平台的賬號要審核,測試平台的賬號也要審核。因此我們只在百度網盤上發布了我們的alpha版本的應用。

 

經歷了萌芽和磨合階段,我認為我們的團隊正在逐步邁向規范階段。M1階段結束的時候,我們看到了我們付出的回報,完成了既定的計划。

 

對比敏捷開發的原則,我認為我們團隊做的最好的就是“以有進取心的人為項目核心,充分支持信任他們”和“無論團隊內外,面對面的交流始終是最有效的溝通方式”。我認為我們最后能夠在有限時間內開發出一款功能如此多的應用不僅在於項目核心人員的技術能力強,更是因為我們充分的互相信任以及頻繁的溝通。試想,如果我們在開發階段沒有相互理解,溝通,在bug產生的時候沒有交流,而是一味的自己悶頭苦想,可能軟件的發布又會有所拖延。在接下來的一個階段,我們將繼續保持我們的熱情和責任心,迎接其他的挑戰!

 

M2階段的計划:

1.繼續完善功能,修改UI

2.和其他學霸組進行項目整合

3.修復bug

 


注意!

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



M1事后分析報告 M1事后分析報告 M1事后分析報告 M1事后分析匯報總結 M1事后分析報告 M1事后分析報告 事后分析報告(M2階段) M1階段事后總結 M1階段事后總結 【Beta階段】M2事后分析
 
粤ICP备14056181号  © 2014-2021 ITdaan.com