團隊作業第六次——事后諸葛亮


設想和目標

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

我們的軟件要解決的是用戶選擇電腦困難的問題。
定義的很清楚了。
通過4個典型用戶場景,引出了我們的四個主要功能,硬件知識,硬件匹配電腦,關鍵詞匹配電腦,論壇交流。

2. 我們達到目標了么(原計划的功能做到了幾個? 按照原計划交付時間交付了么? 原計划達到的用戶數量達到了么?)

我們離目標還有一定的距離,原計划的功能大都實現了,按照原計划時間交付了。

原計划的用戶數量還沒有達到,只在同學小范圍內使用傳播,而且數據庫中的數據還沒有錄入完畢,一些頁面的細節還沒有實現好,缺少了論壇交流功能。

3. 和上一個階段相比,團隊軟件工程的質量提高了么? 在什么地方有提高,具體提高了多少,如何衡量的?

團隊軟件工程的質量只能說略有提高,我們主要完善了管理員角色的新增文章功能以及一些頁面的初始化。

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

並沒有,因為我們側重在了功能實現,但是前端與用戶的交互還不能夠讓人滿意。但是我們確實離目標更近了。希望在今后的日子里,還可以為這個項目添磚加瓦。

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

不同成員們的代碼風格略有差別,整合在一起時難免有些雜亂,還有不少冗余代碼。如果歷史重來一遍我們會提前商量好代碼風格,還有命名規范也有待加強。

計划

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

沒有,因為大部分都是因為運動會的幾天大家都有共同的空余時間去活動室一起工作,在α沖刺之后,大家都有其他科目的大作業,使得能用於項目的時間大大減少。排除考試上課的的因素,時間有些緊張,但敲代碼的時間是其次,主要是上網查找資料和學習還有不斷地試錯,耗費了團隊成員大量時間。

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

開會討論,暢所欲言,再由所有團隊成員一起提出意見,判斷具體的可行性和實現內容或是放棄當前的想法。

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

最大的未完成的就是論壇交流功能,因為過多的時間用於學習,導致只做了原型,並沒有具體去實現。

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

沒有。

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

因為任務安排較為明確,大家的完成度也還不錯,所以每一項的任務都有清楚的定義和衡量的交付件

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

第一次沖刺階段基本按照計划進行,沒啥意外。但是因為技術視野受限,沒有預估好任務的實現難度,且需要實現的內容較為模糊,所以完成度不是很高。

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

有,本來是用於測試和進行階段的進度總結,但是后來還是都用於編碼了。

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

如果還有機會,我們會依照原計划進行,因為目前已經掌握了許多功能的實現方法。

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

我們會在前端的交互上下功夫,讓用戶使用起來能夠更加舒適。

資源

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

有的,前后端的團隊成員都有各自的渠道獲取學習資源並實現學習資源的共享。

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

各項任務需要的時間和資源一開始確實沒有什么明確的概念,只能按任務大小籠統分配,但是因為大家是在一起開發的,所以在開發過程中可以靈活調整任務量共同克服困難。

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

是,因為對於測試工具的不熟悉,使得測試時壓力特別大。而美工/文案確實比想象中難度要大很多,因為這是一整個項目的基調與基礎,不是划划水就好了。

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

不會,因為團隊里面每個人都有自己的任務,大家也都很好的相互配合,才有了這個項目現在的樣子。

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

沒有好好學習spring boot,如果重新來一次,就不會跳過很多細節的東西。

變更管理

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

是的,每個成員都關注團隊群的情況,使得消息通知特別及時被大家接收到。

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

通過集體討論,表決哪些功能暫不實現。

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

各個功能都做完成好,並且能讓第一次上手的用戶就方便的使用。

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

在論壇交流這一塊,我們認為無法迅速實現,因此就果斷選擇了拋棄,轉去實現兩個核心的匹配功能。

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

能,一開始我們沒有打算實現管理員功能,后來經過組長的堅持,成員們也接受了這個意見,並且認真完成了任務。

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

組員需要規范代碼,以應變需求的變更或者是功能的新增,如果重來,我們會規范代碼的命名和結構。

設計/實現

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

設計工作是在沖刺之前,由吳俊傑,阿說阿加,朱煜喆完成,因為這個項目本來就是由組長提出的,因此項目經理和美工負責將組長的想法細化。

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

有,一開始對功能的設計還是很模糊,但是后來經過成員們的協商,定下了具體要實現的內容。

3. 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其他工具來幫助設計和實現?這些工具有效么? 比較項目開始的 UML 文檔和現在的狀態有什么區別?這些區別如何產生的?是否要更新 UML 文檔?

用E-R圖來幫助數據庫的搭建。UML類圖讓后端的分工更加明確。

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

匹配功能,由於對於網頁間的數據傳輸的方法不熟悉,導致了該bug。在我們開發時還沒有發現,到最后展示的時候才發現。

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

沒有嚴格代碼規范是一個重大的失誤,以至於出現了甚至中文命名的尬尷情況。

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

我們學到了代碼需要規范,而且在設計時下一定功夫是由好處的,讓實現人員更加明確目標,能夠加快項目的速度

測試/發布

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

沒有,因為時間較為緊張。

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

都還是停留在完成功能后人為測試。

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

沒有,都是組員通過postman自行測試。

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

有,因為到最后發現還是有一些bug沒有結果。比如匹配到信息還會出現查詢錯誤的消息。

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

提前租賃的服務器過期了。

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

測試以及測試工具的使用真的很重要,如果重來,我們會專門安排一個人進行測試工作。

團隊的角色,管理,合作

1. 團隊的每個角色是如何確定的,是不是人盡其才?

是一開始組隊時都定下的,基本上每個組員都在做事,並且自己負責的部分都完成的很好。

2. 團隊成員之間有互相幫助么?

有,前端之間相互協商界面功能的實現方法,以及后端之間一起學習spring boot。

3. 當出現項目管理、合作方面的問題時,團隊成員如何解決問題?

沒有出現特別大的合作方面的問題,成員們都很團結。

每個成員明確公開地表示對成員幫助的感謝 (並且寫在各自的博客里):

陳聰

我感謝黃楊龍對我的幫助,因某個具體的事:CSS應用中的繼承、網頁自適應

江海天

我感謝陳聰對我的幫助,因為某個具體的事情:在我們對前段框架一籌莫展的時候,發現了ibootstrap這個可視化的網站,讓我們對於前段開發有了質的飛躍。

邱健強

我感謝吳俊傑同學對我的幫助,因為在項目遇到瓶頸的時候,也就是前后端如何交互的問題上,通過和吳俊傑同學的交流學習,才解決了這個問題。

李清宇

感謝吳俊傑,因為某個具體的事情:他利用阿賈克斯幫我實現前后端交互的難題並促進團隊項目進度

朱煜喆

我感謝林志全對我的幫助,因為用mysql建立數據庫時他告訴我用excel表格直接插入更方便,節省了大量時間

吳俊傑

我要感謝李清宇,因為當初若不是他鼓勵我上台講出這個項目,也就不會有hunter這個小組,更不會有如今這一項目。

黃楊龍

我感謝陳聰對我的幫助,因為某個具體的事情:在界面設計時意見的不統一,他提供了很多的很優秀的想法,很好的幫助我們最后頁面的設計

沈溢煌

我感謝吳俊傑對我的幫助,因為某個具體的事情:雖然他主要在做前端,但當我后端上遇到難以解開的BUG時,他也積極幫我一起尋找和解決。

林志全

我感謝吳俊傑對我的幫助,因為在進行前后端交互時他教會了我很多,讓我學會了很多ajax的知識

阿說阿加

我感謝吳俊傑對我的幫助,因為剛開始團隊成員不熟悉是他帶我們進入團隊狀態彼此了解,很多作業問題也是找他商量解決,組長優秀!

總結:

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

我認為團隊屬於可重復級(Repeatable)。管理制度化,建立了基本的管理制度和規程,管理工作有章可循。 初步實現標准化,開發工作比較好地按標准實施。 變更依法進行,做到基線化,穩定可跟蹤,新項目的計划和管理基於過去的實踐經驗,具有重復以前成功項目的環境和條件。

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

我覺得我們屬於磨合階段,大家之間因為有這共同的目標才能團結,但是相互之間的配合還有不夠默契的地方。

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

只是小小的前進了一步,多實現了一些項目上的功能。

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

前端還有登錄狀態的一些細節。

正如我們前面提到的, 軟件的質量 = 程序的質量 + 軟件工程的質量,那團隊在下一階段應該如何提高軟件工程的質量呢?

首先要規范代碼,其次養成寫文檔的習慣,使用一些管理軟件來輔助團隊的工作。

組長想說的話

這段時間大家真的都很辛苦,很多組員在運動會的那四天假期都特別配合,而且在項目進行期間,都非常團結,沒有發生矛盾。我們的活動室在五區,去的路途都很遙遠,但是組員們真的一個去的比一個早,而且一去都是一整天,有時候回來了還在宿舍加班,讓我一個做組長的都有點不好意思了。一開始看后端的進度時,我特別的慌,甚至都有點想放棄了,但是我的組員們沒讓我失望,在學習了spring boot之后立馬展開了功能的實現。感覺我們組的成員在α沖刺的時候真的是實現了從零開始的蛻變。
learning by doing 在我們組就是件常事,后端的學習,前后端的交互,前端頁面之間的交互,都是通過上網找資料,自己寫代碼測試,然后應用到實際項目中的。盡管最后的項目有點不盡人意,但也是我們組最真實的努力體現。最后感謝大家對這個組的付出,也感謝大家信任且選擇了我這么一個菜雞組長,只能和大家一起學,不能夠帶飛大家。希望這次的組隊,會成為你們每個人最難忘的記憶。

我們一起努力過的紀念



免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM