M1階段事后總結


  • 設想和目標

1. 我們的軟件要解決什么問題?是否定義得很清楚?是否對典型用戶和典型場景有清晰的描述?
我們組要爬取網上的內容供下一組使用,定義的不太清楚,因為用戶只有下一個團隊所以沒有進行詳細的需求分析,而且和下一個團隊做的交流也有限,沒有及時得到下個團隊的需求反饋。
2. 是否有充足的時間來做計划?
有時間,我們組在展開工作之前總共開了兩次很長會,進行了大量的討論。
3. 團隊在計划階段是如何解決同事們對於計划的不同意見的?
我們會協商討論,直到計划得到大家的認可。

  • 計划

1. 你原計划的工作是否最后都做完了? 如果有沒做完的,為什么?
學長遺留下來的諸多bug均已經修復,而且所有幾個新增功能都做完了,但有些功能模塊沒做好,仍有BUG需要改。因為剩下的時間不太夠了。
2. 有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
有。比如選擇存儲路徑的功能我們做了之后又刪掉,因為我們一開始對總體規划不夠,而且與下一個組溝通欠佳。
3. 是否每一項任務都有清楚定義和衡量的交付件?
有些有,比如爬蟲爬取數據量的要求(十萬級頁面)、過濾無關頁面的准確率這些都能從已經存在的一些爬蟲軟件中獲得清楚定義和衡量的交付件;而有些沒有,因為一些新增功能的評判我們大家都不知道做到多少才叫“好”。有些情況下,大家對細節過早地進行討論,花了很多時間。不如等到后來再討論。
4. 是否項目的整個過程都按照計划進行?
基本上是,一是大家比較自覺,團隊凝聚力比較強,二是PM與DEV之間,DEV相互之間都會互相督促。
5. 在計划中有沒有留下緩沖區,緩沖區有作用么?
沒有,因為展開工作之前我們已經開了兩次長會,充分考慮了各個功能的完成時間,功能我們覺得自己可以按時寫完,而且事實上我們也實現了所有預計的功能。
6. 將來的計划會做什么修改?(例如:緩沖區的定義,加班)
首先我們要留下緩沖區,以備進度完成情況不好。
然后是要在動手開發前做更多的計划,避免開發過程中做無用功。

 

  • 資源

1. 我們有足夠的資源來完成各項任務么?
有。
2. 各項任務所需的時間和其他資源是如何估計的,精度如何?
開始精度很粗略,后來隨着項目任務的加重,大家只顧得上干活,沒時間考慮精度問題。
3. 用戶測試的時間,人力和軟件/硬件資源是否足夠?
足夠。有三個測試分別從不同的方面做黑盒測試,充分模擬了用戶的情況。

  • 變更管理

1. 每個相關的員工都及時知道了變更的消息?
我們QQ群會經常聊天以溝通最新的變化或進展,同時出現重大的bug的時候會召集成員進行面對面的交流。
2. 我們采用了什么辦法決定“推遲”和“必須實現”的功能?
綜合1、緊急程度(討論協商定) 2、時間剩余 3、人員能力 來討論哪些功能必須做哪些可以推遲。
3. 對於可能的變更是否能制定應急計划?
一般不能,直接告訴具體負責人要做哪些變更,沒有應急計划。
4. 員工是否能夠有效地處理意料之外的工作請求?
能,新的意外的工作請求會發到群里討論分配給新的人做或延長原負責人的規定時間。

  • 設計/實現

1. 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其他工具來幫助設計和實現?這些工具有效么?
使用了單元測試,我們會對不同的小模塊進行測試,看他是否已經完善沒有bug且符合規格,前者是比較有效的(無法下載pdf功能),但是我們沒有做UML的測試。
2. 什么功能產生的Bug最多,為什么?
url爬取識別過程的BUG最多。因為這是我們最難的核心功能,總不同的URL有不同的形式,容易出現各種BUG。
3. 代碼復審(Code Review)是如何進行的,是否嚴格執行了代碼規范?
這個是從頭到尾一直在進行的,測試人員和開發者A,B,C會對開發者D寫的代碼進行審核,因為首先復審是測試分內的事,而A,B,C一是要二次檢查D的代碼是否有一些幼稚的錯誤,二是確定D寫的代碼有沒有對整體代碼架構造成不良的影響,確保整體代碼保持一個高內聚、低耦合的特質。

 

  • 測試/發布

1. 團隊是否有一個測試計划?為什么沒有?
我們有測試計划,而且測試的效果比較好。
2. 是否進行了正式的驗收測試?
進行了,發現了bug,於是又清空了數據庫並修改了bug。
3. 團隊是否有測試工具來幫助測試?
單元測試使用了Junit工具。
4. 團隊是如何測量並跟蹤軟件的效能的?從軟件實際運行的結果來看,這些測試工作有用么?應該有哪些改進?
TFS 還是很有用的,至於改進,有這樣一些建議:
(a)輸入Bug 還是步驟比較多,很多需要手動重復填寫的字段。
(b)不是所有的Bug 或 task 都記錄在TFS中。
5. 在發布的過程中發現了哪些意外問題?
比如,由於我們采用的是google pagerank算法,他是根據網頁之間相互的超鏈接計算每個網頁的熱度,錄視頻的時候由於時間不夠,所以爬取了很少url,我們發現熱度排序功能的算法在抓取數據量不大時迭代次數較少,不能很好地將網頁都按熱度排序,算法適用性低。

 

  • 兩個問題:

1) 對比敏捷的原則, 你覺得你們小組做得最好的是什么?
我們覺得我們小組做的最好的地方是敏捷原則中的“擁抱變化”。
每當有新的問題出現時,我們都可以最迅速地解決。
在代碼剛拿到手我們大概讀了一遍后,我們發現整個項目與我們想象的完全不同:代碼質量沒想象中的好,功能實現差的很多,沒想到的還有要學服務器、數據庫還有TFS得使用。但是我們通過1次網上討論,兩次全員會議和多次部分人員會議迅速地制定了下一步地方向。
開發過程中,我們又遇到很多沒想到的新問題:1最開始測試的時候,發現怎么爬都爬不到pdf文件,即使爬到的pdf也只是數據庫中的壞項,最后發現是學長保存pdf文件的bug2由於是多線程程序,新增的熱度排序功能實現起來難度很大,BUG很多、3臨展示發現選擇本地文件功能沒用、4臨展示下一組告訴我們數據庫有問題
可我們都通過及時地內部討論、變更計划、重新規划計划完成了最終的ALPHA版本,這是我們小組最棒最自豪的地方。

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

下一階段我們必須改進的是要做好整體地規划:
在這一階段,我們需求討論階段做了大約兩天,討論出結果后以為可以開始干活了,可是之后進行過程中發現事實不是如此。或者是做的功能多余,或者是做完已有功能后不知道下一階段干什么,導致軟件開發過程中走了很多彎路。
因此,我們下一階段必須在整體地架構上多費功夫。這個不是會不會的問題,而是用心不用心的問題。我們要花大約3天的時間來仔細地探討我們得需求,盡可能多地羅列,然后為每個需求得重要性、可行性進行評估,得出實現每個需求的性價比。然后結合我們可以開發的時間,來確定最終需求。同時留出緩沖區時間,以防止意外需求或某些不可控因素干擾進程。這樣我們就可以保證我們的需求對症下葯、葯到病除,以最少地精力達到最好的效果。

 

會議討論圖片記錄:


注意!

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



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