M1事后分析報告


設想和目標

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

  我們的爬蟲現階段解決的就是文件爬取的問題。在定義中爬取對性能和功能的要求高,典型用戶和場景的描述較為清晰。

 

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

  有一周的時間來進行計划,這個時間還是很充裕的。

 

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

  異議者可以對PM和主DEV提出質疑,但是最終還是由PM決定計划。

 

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

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

  從發布部署到項目展示,我們的爬取時間不多,但是由於對性能的改進,我們最終的爬取數目喜人。網頁及問答頁的爬取全部達到要求。但是由於種子URL的缺乏以及爬取時間的限制,我們的doc和ppt的爬取數目離目標數據差距較大。如果歷史重演,我們會對這兩項目標進行調整,並積極收集相關種子URL,在發布前這兩項爬取功能完善時就開始進行爬取。

 

計划

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

  原計划的工作有性能和功能兩個方面。性能方面改進進行的較好,爬取效率大有提高。但是由於個別成員積極性和人員分配統籌的問題,新功能方面還是做得不夠完美。

 

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

  基本上沒有。

 

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

  否。這點是PM的疏忽,PM進行任務的分配,對於任務完成的交付衡量定義不是特別的清晰。

 

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

  大體上是按照計划進行的。沒有估計到的風險主要還是個別成員的任務完成情況距離要求差距較大。例如UI的設計。

 

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

  周日是我們小組成員自由工作的緩沖時間,能夠減輕一下壓力。

 

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

  首先在分配任務時清楚定義和衡量交付件;其次如若成員消極隨意對待工作,不延長其交付時間,他之后的工作照常加上,由該成員自己統籌時間全部完成,否則進行相應的貢獻分處分。最后是保證每周的一個階段性工作總結會議的質量。

 

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

  計划要考慮各項指標,不能只分配任務,例如任務的交付,成員對任務的完成能力等等。其次要重視風險評估,讓我們不至於在突發情況時措手不及。

 

資源

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

  資源不盡人意,由於我們的項目對網速的要求較高,但是服務器上的網頁訪問奇慢無比。所以我們大多數還是通過數據庫連接用PC爬取的。希望能夠改善一下服務器的網頁訪問速度。

 

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

  每項任務的時間根據成員能力和任務難度來定,一般成員一天任務時間不會超過三小時。

 

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

  由於部署的較晚,測試時間還是偏少。人力和軟件資源都足夠,硬件資源還是服務器網速的問題。對於設計文檔等各種文案的難度沒有低估。

 

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

  不可能。

 

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

  資源方面應該是沒什么教訓。如果歷史重來,死纏爛打找老師提升服務器網速。

 

變更管理

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

  是的,PM會及時在TFS,QQ群上通知。由於寢室離得比較近,PM會奔走相告。

 

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

  根據每周階段性總結會議的討論和與數據處理小組協商他們的需求。

 

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

  定義較為清晰,主要有3點要求:1.能夠爬取網頁、問答頁、pdf、ppt、doc;2.根據關鍵字爬取;3.信息入庫,提供給數據小組使用。

 

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

  一般如果有突發情況,都是由包括PM的個別成員熬夜完成。

 

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

  可以處理。例如連接數據庫的各種權限問題,成員能自行登錄服務器進行權限的分配。

 

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

  由於M1階段中變更情況較少,所以這方面對我們的影響不太大。需要改進的是我們可以評估和准備可能到來的變更,減少成員熬夜的情況。

 

設計/實現

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

  設計工作是在迭代一開始的一周時間里。通過小組討論,最終由PM和主DEV功能完成。

 

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

  有,並且對現在的版本發布造成了較大的影響。分配給成員的一個分類功能,在當時設計時沒有說清楚,最終成員僅實現了分類統計,沒有時間分類存儲和管理。從現在來看應該是都要實現,團隊對當時這一情況解決得不好。

 

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

  使用了java unit test。由於當時有很多新功能沒實現的擱置代碼,所以覆蓋率不高。在M1測試階段junit對我們的作用不是很大。

 

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

  爬取線程產生的Bug最多。因為我們缺少線程管理的方案。發布之后也有發現在爬取數目較大時偶會發生線程Bug,在設計時由於我們缺少長時間大數目的評估測試,導致了這一Bug的存在。

 

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

  這一點我們團隊沒有做到。

 

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

  在設計中缺少一些任務的評估和代碼復審。在設計時進行一些系統性的測試對我們項目的進行是有幫助的。

 

測試/發布

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

  測試計划是較為完善的,計划要求對功能性、可靠性、可使用性、安全性和性能進行測試,並給出了測試基本要求。

 

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

  是的。最終進行大數目的爬取測試,達到了驗收的數量。

   

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

  沒有。

 

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

  與上一版本的爬蟲進行了單次最大爬取數目和單位時間爬取數目的比較,從運行結果來看,我們的爬取性能更優。

 

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

  缺乏種子URL導致爬取的ppt、doc數目較少。

 

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

  這一方面我們小組做的比較好,不足的還是URL的收集不夠積極有效。

 

總結

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

  CMMI。

 

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

  規范。

 

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

  我們這是第一個里程碑。

 

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

  PM對基礎每日工作的統籌、監督和交付評定。

  

Postmortem 會議成員照:

 


注意!

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



 
粤ICP备14056181号  © 2014-2021 ITdaan.com