M1事后分析報告


我們的項目整體分為服務端和客戶端。服務端准備架設在服務器上,進行多平台用戶數據的存儲。客戶端目前打算做兩個,一個基於Windows平台,一個基於Android平台。主要需要實現的功能有兩個:

  1. 對於個人用戶,實現個人的設置鬧鍾,取消鬧鍾的操作,這些操作將會上傳至數據庫,並被同步到所有的客戶端上。在服務器端要實現用戶注冊、數據的增刪改查等功能。
  2. 對於群組,我們還要加入用戶的好友功能,可以根據其他人的ID來添加好友,將好友拉入群組,如果好友同意的話,這個群組可以設定群組鬧鍾,這些鬧鍾會被共享給整個組內的所有成員。對於這個功能,我們在服務器端還要加入用戶的好友數據,以及群組。

【計划】

我們目前打算用Bmob后端雲,這也是我們在第一輪迭代之前需要完成的。另一個需要在第二輪迭代完成的是windows端的客戶端,我們需要在第一輪迭代前實現Beta版本。

         對於這個項目,我們認為用心做就一定會有用戶,界面簡介,沒有廣告,做良心的應用。

   

M1事后分析報告

設想和目標

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

軟件的靈感來源於組員的最初需求,生活中經常會發現很多社團會議難以加入日歷項,大多數會議也只是口頭通知,我們的鬧鍾提醒軟件就是由活動發起用戶建立群組來提醒所有組員,從而解決這些問題。定義和典型用戶及場景已在說明書中明確說明。

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

有時間,但是沒有充分利用時間來做計划,對計划的執行力度不夠。

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

主要是在團隊會議討論階段,大家提出自己的看法,最后由幾位核心負責人總結並制定計划。

 

計划

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

我們目前打算用Bmob后端雲,這也是我們在第一輪迭代之前需要完成的。另一個需要在第二輪迭代完成的是windows端的客戶端,我們需要在第一輪迭代前實現Android版本。

對於這個項目,我們認為用心做就一定會有用戶,界面簡介,沒有廣告,做良心的應用。

目前原計划的實現Android版本完成了一部分。因為第一輪我們的開發主力被學院調走參加挑戰杯比賽。落在其余組員身上的壓力過大,以至於沒有完成。

 

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

有,而且這些事浪費了我們時間。比如糾結用何種開發工具。

 

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

不是,因為開發人手不夠,所以任務只有少數人清楚。

 

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

不是,項目中途有很多突發狀況,出現很多次人手不足的情況,導致后來一直要趕進度。

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

有緩沖區,還是有一定作用的,緩解了一部分人員短缺和突發狀況的問題,但是不能從根本上解決問題。

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

      將開發工程師人數提升到4人。分別負責2名前端,1名后端,1名UI界面。測試由工作量較小者完成 

資源

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

人力資源不夠充足。

完成任務的學習資料很充足。

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

 由於第一輪人手不足,所以開發人員壓力比較大,沒有很細致的考慮資源分配和任務分配的問題,所以也談不上精度如何。只是在有限時間內,每個人能做多少就做多少。

  1. 用戶測試的時間,人力和軟件/硬件資源是否足夠?

在百度開發者平台發布時,留有開發者聯系方式。至今為止沒有用戶聯系過我們。但是身邊的同學在使用過我們的Agenda Manager之后,提出了一些建議。

人力資源自然是不夠的。

軟件和硬件資源充足。

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

本來人手就不足,基本是每個人的利用率最大化了,所以基本沒有人可以代替別人完成任務。 

變更管理

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

 不是。在更換PM的時候,前一位PM沒有及時的得到消息。

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

根據功能的優先級即重要程度來確定,將一些次重要的功能留給下一個階段實現。

  1. 項目的出口條件(Exit Criteria)是否得到清晰的定義?

是的,如下:

(1)、注冊新用戶並登錄

(2)、通過ID添加好友

(3)、創建群組

(4)、邀請好友進入群組

(5)、被邀請的好友選擇接受或拒絕

(6)、創建群組的用戶在本地創建好日程提醒

(7)、可以創建多個日程    

(8)、將日程提醒推送給群組內每個人

(9)、組內用戶收到推送后選擇接受或拒絕

(10)、某個用戶拒絕后,創建者收到反饋。

(11)、日程提醒的時間格式應為: year – month – hour - minute

(12)、創建日程提醒的人可以手動修改或刪除該日程的任意信息。

(13)、日程提醒過后,可自動刪除該項

(14)、實現自動登錄,即在退出后的短時間內,無需再次通過用戶名和密碼登錄。

(15)、到設定好的日程提醒時間后,完成彈窗震動或響鈴提醒。

(16)、重啟后,原有日程提醒不失效。

 

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

目前采用的是較簡單的頂替做法,沒有系統地制定應急方案。

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

能。

 

設計/實現

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

設計工作由主力開發人員完成,都在M1前期完成。

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

經常碰到,大部分是由具體執行的人自己解決,如果問題比較嚴重,就會拿出來和其他組員進行討論,再由核心成員一起制定解決方案。

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

M1階段沒有進行單元測試。

4.       什么功能產生的Bug最多,為什么?

鬧鍾提醒功能BUG最多。

因為開發人員對於Android的廣播、注冊機制了解不夠透徹。

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

       開發進度一直很拖,最后沒有進行代碼復審。 

測試/發布

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

團隊有明確的測試計划。

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

是。在Android 內測版完成編碼后,由本隊的測試員進行了全方位的測試。

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

由於是移動端的App,所以僅需進行使用測試。

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

在M1階段,我們僅進行了使用測試。

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

    由於是第一次發布產品,所以有很多需要嚴格執行的程序。比如要有獨立版權的App圖標,並且圖標必須是512X512高清圖;有登錄功能的產品需要提供測試賬號、測試密碼等。

 

 

1)   對比敏捷的原則,你覺得你們小組做得最好的是什么?

  1. 保持簡明,盡可能簡化工作量。任何還沒有明確的工作都會花不可知的時間,因此在計划中時刻最大化未完成的工作量,不把那些還沒有做的工作和正在做的工作混起來。

 

  1. 敏捷流程中保持可持續的開發速度。不論目前手頭的事有多少,總能在一個長期恆定的開發速度中完成任務,因此中間的一些突發狀況也能較好地應對過去。

 

  1. 注重需求,把客戶當做團隊的一部分,時刻注意新的需求的產生,並制定實現的新方案。

 

2)   什么是在下個階段 M2 要改進的地方?越具體越好。 

  1. 我們認識到了具備一位統攬全局的PM之重要,在第二輪我們將任命一名專職的PM,以掌控全局。
  1. 改善整體的團隊成員分配,我們需要在第二輪迭代中引進一位能夠編寫代碼的同學,這樣我們就有了4位主力進行開發。此舉能夠大大加快我們的進度。解決我們碼力不足的尷尬境地。
  2. 提高全體成員的積極性。這對我們而言是不簡單的工作,因為我們還同時有編譯原理和數據庫作業,所以一定要拿出成果,及時播報成果,讓隊伍有了成就感,就自然有了團隊的向心力。這個任務交給黃上,由他來帶動整體的氣氛。
  3. 重構代碼,整合Bmob提供的API。
  4. 嚴格執行績效制度,想要得分就一定要對團隊有正貢獻。用以防止我們出現人手不足的這種情況,讓所有的同學能夠加入到開發過程中來。每次的任務都有任務點(Mission Point)來標記,最后將按照任務的權重來分配分數。

 


注意!

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



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