事后分析報告(M2階段)


我們的項目是自選項目,一款名為備忘錄鎖屏MemoryDebris的軟件。

 

 在第二輪的迭代中,由於各科的大作業都集中在這一段時間,所以這段時間各個組員間的負擔都比較大,但是在大家共同努力,最終我們還是交上一份滿意的答卷。

 

 

一、小組成員在M2階段的貢獻

 

在M2階段,我們小組成員並不像在M1階段那樣分工明顯,大部分情況下都是誰有時間就編寫軟件的某個模塊,或者是修復某個BUG。如果非要明顯地區分出來的話,大致如下:

顧育豪:負責鎖屏模塊的連接工作和鎖屏界面的設計。

劉強:調整了備忘錄,讀書筆記的數據庫結構,修正了數據庫存在的BUG。

王洛書:負責使用說明和備忘錄界面的設計、實現;市場宣傳。

黃明源:軟件主界面的設計者;其他工作如修改小bug,軟件圖標,各部分連接時候提供幫助;……。 

陳睿翊:負責軟件設置界面的設計實現,對軟件進行測試並提出改進意見。

張夢達:審美一流的設計者,負責團隊美工方面;市場宣傳;寫博客。

 

 

 

二、小組成員M1階段的分數分配

王洛書 21.5分

顧育豪21分

劉強20.5分

黃明源:19.5分

張夢達:19分

陳睿翊:18.5分

 

 三、總結

3.1設想和目標

 

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

 

我們要做一個能夠幫助人們利用解鎖屏幕時間的軟件。便捷地將每天需要記憶地內容呈現在鎖屏界面,讓用戶根據自己的需求設置、記憶。

定義的很明確。

 典型用戶:學生、商人、學者等

 典型場景:

   “解鎖屏幕的時候,是不是可以提醒一下自己今天的任務清單是什么?

       是不是可以再背一遍今天在書上看到的巧妙算法?

       是不是可以再看一看presentation的提綱?

       是不是可以再溫習一下某個朝代重大事件?

       是不是可以再記一下今天要背的生詞?

       是不是可以再記憶一下等會兒談判的要點?”

 

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

 

有,我們在第一輪迭代開發時花了1-2周的時間來做計划。

 

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

 

開會討論不同意見,大家評價哪種想法更好。事實證明,我們的方法很有效,大家對產品設計產生過很多分歧,但是最后都通過討論達到共識。

 

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

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

 

一致,我們對現在2000+的下載量表示滿意。

我們的經驗是前期分工太亂了,讓大家一起做一個項目,如果重來一遍,我們會更明確分工內容。

 

3.2計划

 

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

 

完成了。

 

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

 

沒有。

 

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

 

是。

 

4、是否項目的整個過程都按照計划進行?

 

是。

 

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

 

有緩沖期,緩沖期讓我們有充足的時間應對計划之外出現的情況。

 

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

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

增加緩沖期的長度,更注重界面的設計和風格的統一。

 

 

3.3資源

 

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

 

資源較少,因為我們的選題是一塊市場相對空白的領域,網上幾乎沒有公開的可供參考的代碼。

 

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

 

大家坐在一起討論分析,在大體時間把握上不錯,但細節精度不太准確。

 

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

 

是。我們低估了美工設計的難度。剛開始寫會議總結時分工也有點亂,下一輪會改進。

 

4. 你有沒有感到你做的事情可以讓別人來做(更有效率)?

 

暫時沒有團隊成員提出。 

 

 

3.4變更管理

 

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

 

是,我們建立了QQ群,每天都會在群里溝通,每周也會在現實里組織開會。

 

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

 

通過去掉這個功能,用戶體驗會降低的程度和程序是否還能正常運行來判斷。

 

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

 

有。

 

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

 

能。

 

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

 

能夠,我們完善地應對了很多次突發狀況。 比如說團隊成員生病、發現實現難度有些大、部分Bug修復困難等,最后都很好的解決了。

 

3.5設計/實現

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

 設計工作是第一輪迭代時,大家一起討論設計,再分工完成每個人自己的部分的。很合適。

 

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

有,投票決定。

 

3. 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其他工具來幫助設計和實現?這些工具有效么?

有,有效。

 

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

把設置的內容顯示在鎖屏上,需要考慮屏蔽安卓自帶的鎖屏功能,有時一不小心會出bug。

發布之后發現v1.0只能支持4.0以上版本,我們在編碼時由於缺乏開發經驗,並沒有想的這么全面。

 

5. 代碼復審(Code Review)是如何進行的,是否嚴格執行了代碼規范?

 

我們在初期采取的是把6個人分成3組,進行兩兩結對編程,一邊編程一邊復審。

 

 

3.6測試/發布

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

有測試計划,很有用。

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

進行了。

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

有。

4. 團隊是如何測量並跟蹤軟件的效能的?從軟件實際運行的結果來看,這些測試工作有用么?應該有哪些改進?

大多是人工檢測,通過判斷是否和預期一致檢查性能。這些測試工作挺有用的,后期應多借助一些工具。

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

發現部分網站審核時間過長,失算。 


注意!

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



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