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


這個作業屬於哪個課程 2019秋福大軟件工程實踐Z班 (福州大學)
這個作業要求在哪里 團隊作業第六次—事后諸葛亮
團隊名稱 T-MAX
這個作業的目標 組織事后諸葛亮會議並發布隨筆
作業正文 團隊作業第六次—事后諸葛亮
其他參考文獻 項目管理之事后諸葛亮會議

設想和目標

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

  • 我們的軟件要解決的是針對福州大學學生飲食選擇的問題。
  • 定義的挺清楚的,就是針對飲食問題。
  • 對典型用戶和典型場景有清晰的描述。目標用戶即針對福州大學校園學生,場景也很簡單,如:A想要去餐飲店吃飯,在平台上查找瀏覽關於該店面(窗口)的服務和菜品信息,並進行選擇決定。

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

  • 沒有達到目標,現在仍然缺少很多主要的功能尚未實現。
  • 已按照原計划交付時間交付
  • 用戶數量未達到預期

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

  • 質量提高了,特別是在完成一定數量的任務時每個人的開發效率都提高了,團隊配合更加緊密。以提交任務的時間和效果為標准衡量。

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

  • 用戶量不一致,
  • 接受程度比較一致
  • 更近了

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

  • 要預先規划好任務進度,進行調整,如果歷史重來一遍,我們會將文檔、框架等寫的更加詳細一些,將任務更加細化。

計划

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

  • 我們在沖刺開始前就完成了計划制定和任務分工。

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

  • 鼓勵大家積極發言, 讓意見產生分歧的人輪流發言,然后團員共同商討選出大家認為比較合適的方案。

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

  • 沒有全部完成,主要是由於技術不懂,隊員有幾門考試,時間不夠,開發不夠熟練

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

  • 有,一是制作原型時討論度不足,導致后面手忙腳亂。二是畫類圖的人和建立數據庫的人是獨立分開完成的,當對接的時候發現數據庫的表和類圖對應不上。事實上數據庫和類圖不能分開完成。

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

  • 有明確的交付件,在編寫過程中有調整。

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

  • 沒有整個過程都按照計划進行。
  • 意外主要時來自考試和技術問題。
  • 就是提到的意外。

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

  • 沒有,因為計划時不了解緩沖區的概念。

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

  • 每個人都應明確緩沖區的具體時間段,不要在緩沖區以外的時間仍在休息。

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

  • 更加合理的安排時間, 預先安排好人手分工與准備突發情況備用計划,另外, 做規划的時候不能將餅畫的太大,目標還是得定在可實現范圍內,畢竟不是專門做開發的,在開發沖刺的同時還有課業。討論方案時要討論到更加細節的地方,而不是大致的商討,並將商討結果做詳細的記錄,不至於遺忘。

資源

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

  • 有,團隊資源相對來說是比較充足的情況。

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

  • 首先確定我們的任務相對應的難度值,再根據任務難度和任務類型分配給每個人,最后確定每個任務的完成時間以及資源。 精度大致相同

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

  • 人力、軟硬件資源充足,但是時間就比較趕。
  • 文案的編輯還是很重要的,我們有些低估了難度。

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

  • 每個隊員的能力都不同,每個人擅長的也不同。但不能因為一個人做事更有效率,就把每件事都交他做。能力相對較差的人可以分配相對比較簡單點的任務,當然能力較高者可以分配相對較難的任務。所以前期分配任務時就應先了解每個人的能力,再分配相當的任務。

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

  • 團隊之間多進行交流和溝通, 合理安排手上的資源,物盡其用,任務分配明確且盡量均等,避免有人任務過重,有人清閑,使效率變得更高。

變更管理

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

  • 因為每天都會開會,有什么問題也會轉發到群里討論,所以消息傳遞效率還是有保證的。

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

  • 通過開會討論共同商議決定的。

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

  • 在需求報告里的性能、界面需求等模塊中有比較清晰的定義。

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

  • 基本沒有,緊急情況全靠加班。

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

  • 沒碰到意料之外的工作請求。

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

  • 目前沒有遇到變更情況。
  • 如果歷史重來一遍,我們會提前制定好變更應急計划,應對突發情況。

設計/實現

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

  • 設計工作是在做項目需求分析的時候完成的,主要由做原型設計的同學設計,大家也會討論決定。
  • 是合適的時間,合適的人 。

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

  • 沒有碰到模棱兩可的情況,一般一起討論后就會有結果。

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

  • 團隊運用了單元測試、UML等工具幫助實現。
  • 有效。單元測試有效地幫助測試了每個類的debug,uml幫助我們理清用戶、需求、系統功能單元之間的關系。
  • 主要是類圖變化比較大,其他的沒有什么區別。
  • 需要更新uml文檔。

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

  • 前后端交互功能產生的bug最多。因為這一塊的代碼邏輯比較復雜,需要考慮的方面也比較多,而且不熟練,BUG很多。
  • 暫時未發布。
  • 錯誤估計了難度。

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

  • 代碼復審由審查者評審代碼的格式、風格、命名是否符合規范。
  • 嚴格執行了代碼規范。

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

  • 我們學到了如何用測試工具輔助設計和實踐。
  • 如果歷史重來一遍,我們會多應用自動化工具進行代碼的測試和復審。

測試/發布

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

  • 有。

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

  • 還未進行正式的驗收測試。

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

  • 沒有運用專門的測試工具。

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

  • 軟件的效能還只是靠大家在測試的時候分辨,沒有做專門的評估。

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

  • 還未發布。

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

  • 我們學到了測試的重要性。
  • 如果歷史重來一遍,我們會花更多一些的時間在學習自動化測試上。

團隊的角色,管理,合作

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

  • 團隊的角色是根據團隊成員各自選擇喜歡或熟悉的方向確定的。
  • 基本上做到人盡其才。

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

  • 有,一個成員出現問題時,會進行討論,由部分或者全部成員一起解決。

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

  • 還未出現過這樣的問題。如果出現了會及時反饋,集體進行合作方面的debug吧。

    每個成員明確公開地表示對成員幫助的感謝 :

    陳功賢:身為這個小組的隊長,首先,我要感謝團隊的所有成員。我的性格偏着急,容易急躁,感謝隊員們對我的包。在這次時間的過程中,雖然我們的產品做的不是很成功,同時,在交流的過程中也有着磕碰和摩擦,但是,這是一次難忘的體驗,讓我可以與團隊的小伙伴們和諧的共同進步和成長。

    陳友昆: 我感謝陳功賢同學對我的幫助,因為在使用Android Studio的過程中,是他一步步耐心地教會了我這個開發工具的的使用,同時在前端開發的過程中,通過他的幫助,我也懂得了如何實現底部導航欄以及使用一些簡單的控件,讓我在Andorid的前端開發上少走了不少的彎路,少踩了很多坑。不僅在技術方面,每當我遇到困難時他都會盡力地幫助我並且鼓勵我,讓我一路地與團隊的小伙伴們共同進步和成長,雖然我們的產品做的不是很成功,但是我對軟件的開發過程有了更進一步地認識,也讓我懂得了如何與團隊的其他成員合作。

    賈懿: 我感謝陳功賢同志對我的幫助,在項目開展初期,因為我個人原因不能接任組長,他有擔當地接過了任務,並且一直兢兢業業負責到底,給他點贊,噢里給!

    塗崢嶸: 我感謝陸志陽對我的幫助,因為在起初小組分工后我是挺迷茫的,是他幫助我確定學習的方向,在后面我才能得以在團隊中發揮自己的作用。

    徐美佳:我感謝隊長陳功賢對我的幫助,在每一次任務的完成過程中給予我指導,幫助我解決遇到的問題

    李愛軍:我感謝陳功賢同學對我的幫助,因為某個具體的事情: 每每遇到不會的問題,都會很熱情地幫助我,他在團隊里盡心盡力,是團隊里付出最多的人。

    蔡智偉:我感謝 陳友昆、陳功賢 對我的幫助,因為某個具體的事情: 完成前端工作時,對我工作方面的幫助,比如安排任務、技能學習(布局)、其他科目的作業完成等等。

    林生枝: 我感謝陸志陽對我的幫助,因為在一開始軟件環境的配置和軟件的選擇上他給予了我很大的幫助。

    洛桑平措: 我感謝團隊里的所有成員,特別是蔡智偉和隊長對我的幫助, 因為在項目沖刺階段的時候蔡智偉幫助了我很多,尤其是在制作界面的時候我剛跟那個軟件接觸,他幫我教了軟件的使用方面和制作界面的知識,雖然后面也沒能弄出來幾個界面,但是我還知道關於這些方面的技巧。還有感謝團隊的所有成員對我的幫助與寬容,還感謝隊長的付出,因為整個項目開發過程中隊長是最難得,無論做什么事都事先用一定的時間去考慮分配任務等,隊長你辛苦了

    陸志陽:我要感謝陳功賢同學,因為他在我編碼算法陷入苦苦的困境之時,是陳隊陪伴我於水火之中直至深夜,我很開心一起熬夜的日子。

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

  • 我們學到了團隊氛圍對開發的重要性。
  • 如果歷史重來一遍,我們會保證良好的團隊氛圍,我們會遇到不會的多問,一個人不會,但是團隊中其他人可能會,這樣可以減少浪費的時間 。

總結

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

  • 我們認為目前團隊還處於CMMI一級,執行級的檔次。因為大部分同學沒有太多開發經驗,很多開發上的問題還是第一次接觸,還是只能奔着實現項目需求出發。希望未來可以繼續努力,鍛煉出更強的軟件綜合開發能力,往更高一級水平邁進。

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

  • 我覺得團隊目前處於磨合階段。

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

  • 相較於之前的,都有的很多進步,對於技術方面也學了很多

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

  • 我覺得目前最需要改進的方面是前端和后端之間協作同步的問題。

5、 對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

  • 不論團隊內外,傳遞信息效果最好效率也最高的方式是面對面的交談:我們每天都會開一次會議,來交流我們當天的進度,遇到的問題和心得體會。
  • 每隔一定時間,團隊會在如何才能更有效地工作方面進行反省,然后相應地對自己的行為進行調整:在每次會議的時候,如果大家的進度落后太多,就會反思一下是什么原因導致了我們的進度落后,並對我們接下來需要做出什么調整做好規划。

照片

img

各組員對於最終項目成果的貢獻度

學號 姓名 貢獻度
031702429 陳功賢 21%
031702430 陳友昆 8%
031702414 陸志陽 8%
031702510 徐美佳 8%
031702136 李愛軍 8%
031702344 林生枝 8%
031702325 塗崢嶸 8%
081700414 賈懿 15%
031702149 洛桑平措 8%
031702143 蔡智偉 8%


免責聲明!

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



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