組長部落格連結：https://www.cnblogs.com/GuoHail/p/15586232.html

一、基本情況

組長部落格連結：https://www.cnblogs.com/GuoHail/p/15586232.html

現場答辯總結：

• 這次現場答辯還算是圓滿成功，在這之前我們雖然付出了巨大努力，但是對成果沒有足夠自信，一度認為我們的成果是所有隊伍裡面進度最慢的，但是老師給與我們的肯定和大家提供的建議讓我們非常暖心，我們會繼續把‘一研為定’做好，最終回報給大家，不負老師與同學們的期望。在這一階段後，我們深刻反思了我們的不足：

• 對於核心功能，沒能提前經過調研等方式瞭解過使用者的具體需求和痛點；
• 在此階段衝刺後，還有一部分功能未對接好，沒能展示；
• 對完成專案所需要的能力和知識沒能提前進行了解和學習，開始具體專案 的時間大大推遲，導致專案進展緩慢；
• 在人員任務分配中，雖然有具體的分組，但仍然存在任務分配不均的情況，沒有完全利用好每個人的時間。
  ......

我們會改進我們的方案，調整狀態，加快步伐，把剩餘的功能和介面實現，儘快將完整的產品APP交付。

全組討論的照片：

評估團隊中每個人對本次作業的貢獻比例，描述為本次作業的工作流程、組員分工、組員工作量比例：

二、總結思考

2.2.1 設想和目標

1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述 ？

• 我們的軟體主要是為了向考研學生及時提供院校的夏令營及調劑資訊。定義的足夠清楚，如針對夏令營資訊，我們主要推送的是985和211的一些院校，而調劑資訊則主要集中在一本及以下的一些院校。

2.我們達到目標了麼?（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)

• 基本達到了目標。核心功能如對於院校資訊的及時爬取和推送，使用者對於喜好院校的關注都做到了。有在原計劃交付時間內交付，原計劃達到的使用者數量達到了。

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

• 使用者量和我們預想的差不多（我們預想的使用者量在alpha衝刺內達到10人），使用者對重要功能的接受程度一般，我們會繼續完善我們的功能和介面。我們離目標更近了，但還需繼續努力，向目標不斷靠近。

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

• 對於核心功能，要提前經過調研等方式瞭解過使用者的具體需求和痛點後進行分析確認，我們由於前期沒有重視而忽略了這一點。如果歷史重來一遍，我們在專案開始之前，會進行更為詳細的使用者需求調研。

2.2.2 計劃

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

• 是，我們在開始之前進行了較為完全的計劃，進行了功能確認和人員分配。

2.團隊在計劃階段是如何解決組員對於計劃的不同意見的？

• 首先經過全體成員的集體討論後對計劃有了初步定義（確認共識，擱置爭議），再根據各成員的意向及能力以及專案需求進行了分組，對一些具體問題，各部分成員基於負責部分提出問題並集體討論。最後由組長進行決議，全體成員遵循。

3.原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

• 基本完成，有一小部分非核心功能未完成。如使用者的一些非必要個人資訊，理由是不影響核心功能，且時間較短，考慮後決定之後騰出時間繼續完善核心功能，第二輪會繼續完善。

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

• 有，在使用者登入介面的製作上投入了大量人力和時間。到後來發現其實這個部分只需要一個人來完成即可，多人一起做的效率反而降低了，由於沒有交流好，大家的工作做了許多重複之處。

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

• 沒有，我們初次合作完成專案，沒有清晰的考慮到這一點，因此在工作協調上確實存在一些問題。

6.是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

• 整個專案程序是按計劃進行的，出現的重大意外是在答辯的前一天晚上發現各小組的成果不能打包在一起，最後熬夜解決了這一問題。溝通問題是開始沒有注意到的，也導致了各小組之間的對接問題，可能是因為大家都過於信任彼此，認為各部分都會做出理想的效果。

7.在計劃中有沒有留下緩衝區，緩衝區有作用麼?

• 有留下緩衝區，緩衝區給我們提供了最後一刻完成app打包的時間，有很大的作用。

8.將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）

• 我們的線下程式設計活動會從兩天一次縮減為一天一次，加班完成剩下的任務，爭取把剩下的時間留給緩衝區，以應對意外的出現。同時在人員任務分配上，我們根據上一階段的考慮，我們會做出一些調整。最後就是加強各小組之間的溝通，以免重蹈覆轍。

9.學到了什麼? 如果歷史重來一遍, 會做什麼改進?

• 一定要在任務開始前做出周詳的計劃，並且要留出緩衝區應對意外。如果歷史重來一次，我們在專案開始之前會特別召開一次會議，制定好計劃，然後嚴格按計劃執行，同時也要讓每個小組做好溝通。

2.2.3 資源

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

• 有足夠的資源完成各項任務，如前端需要的學習資源及做專案需要的資源，爬蟲組需要的網上資訊。針對各部分所需要的能力，各成員及時進行了學習。

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

• 每項任務所需的時間視具體難度來定，其他資源的分配由需要者自行獲取，團隊提供所有能提供的資源，精度不錯，大都可以滿足任務需求。

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

• 我們在這一階段只進行了簡單的測試，其他測試將在全部功能實現後再進行。對於不需要程式設計的資源，美工方面我們還沒有開始具體的優化，文案和PPT的設計還是在能力之內，沒有太多難度。

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

• 有的，因為我們隊內有六邊形大佬，所以許多事情由他來做會更有效率，但是這樣就不能讓全體成員一起進步，獲得製作軟體的經驗。還是大家共同合作完成任務為宜。

5.有什麼經驗教訓? 如果歷史重來一遍, 會做什麼改進?

• 對完成專案所需要的能力還要提前一些進行了解和學習，早一點開始具體專案，在完成過程中繼續學習。雖然我們這次基本完成了計劃，但時間確實有點趕，如果歷史重來一遍，希望更早開始。

2.2.4 變更管理

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

• 我們有每週的兩次例會，由組員輪流進行每次會議的記錄和總結，再加上群內交流，所有人都能及時獲取變更訊息。

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

• 根據交付剩餘時間、各部分完成及對接情況、是否影響核心功能等標準進行判定，並再例會進行討論和決定。

3.專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

• 專案完成的出口條件我們有比較明確的定義，即達到了預期功能，存在bug可以先通過，後面再debug。

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

• 可以。由於我們有借了一間會議室，距離大部分成員的宿舍都很近，可以立即召集大家舉行臨時會議進行商討，制定應急計劃。比如在答辯前一天，我們就舉行了應急會議，保證了產品功能的準時實現。

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

• 可以。雖然大家都沒有軟體工程的經驗，但是學習能力很強，可以在短時間內處理意外情況。

6.學到了什麼? 如果歷史重來一遍, 會做什麼改進?

• 學到了要有應對意外的心理準備，在意外發生時要儘快交流，達成共識並做好解決措施。如果重來一遍，會對一些可能出現問題的部分做好備用計劃並預留時間。繼續保持組內的隨機應變能力。

2.2.5 設計/實現

1.設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？

• 有合適的時間和人，設計工作在工作開始前，由大家商量後，經過使用者需求的考量，由隊長決定並設計。

2.設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？

• 有，在對我們推送的院校保研和調劑資訊是採用直接爬取網址，還是處理分析資料後再展示給使用者，我們比較糾結。經過切實的考慮後，我們決定先從簡單的開始做，先以爬取網址的方式來製作，如果有時間我們再進行資料分析。

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

• 有使用過UML。這些工具有效，但是由於時間緊迫，我們沒有太多使用。

4.比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？

• 一樣。我們的專案目標和框架和開始一致，沒有更新UML文件。

5.什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

• 在爬取各高校網頁時，會出現html返回正常，但解析出來的列表長度為0的bug，可能是因為瀏覽器對html文字進行規範化，導致解析失敗。我們在設計階段時並沒有掌握有關爬蟲的知識，所以上手後有一定的知識空白。

6.程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？

• 我們在這一階段還沒有進行程式碼複審。

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

• 在設計階段要對專案有一個明確的方向，還有就是bug是無處不在的，我們不能完全消滅它們，但是應該盡力減少。寫程式碼的時候應該有一個程式設計師的素養，執行不同語言的規範。如果歷史重來一次，我們會嚴格執行程式碼規範，這樣不僅會讓我們的程式碼顯得非常專業，也可以讓其他隊員閱讀時減少壓力。

2.2.6 測試/釋出

1.團隊是否有一個測試計劃？為什麼沒有？ 是否進行了正式的驗收測試？

• 有測試計劃，我們從前端小組，後端小組和資料庫小組中各挑選了一名隊員組建測試小組，預計會在下一輪的衝刺結束後進行正式的驗收測試。

2.團隊是否有測試工具來幫助測試？

• 暫時還沒有，在最終驗收測試時我們會商討使用哪些測試工具來幫助我們測試。

3.團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進?

• 我們還沒有進行測試工作，這一點我們會在下一輪的衝刺結束後來完成。

4.在釋出的過程中發現了哪些意外問題？

• 意外是我們由於各小組的對接問題，是在答辯前一天晚上才進行打包釋出的，一位隊員是極短的時間內現場學習的app打包方法。

5.學到了什麼? 如果歷史重來一遍, 會做什麼改進?

• 測試是非常重要的，我們最終出現了對接上的重大問題，如果早先測試，也許就不會出現。如果歷史重來一次，我們會把測試工作提前到這一階段末尾，同時也要加強各部分的交流。

2.2.7 團隊的角色，管理，合作

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

• 根據專案各部分的功能需求、各成員的能力及喜好進行了分組，大致分為前端、後端、資料庫、爬蟲四個部分。基本做到了人盡其才。

2.團隊成員之間有互相幫助麼？

• 有相互幫助、各部分組內大擊會一起交流學習，資源共享。團隊之間有誰需要幫助大家都會盡力去幫助，一起解決問題。

3.當出現專案管理、合作方面的問題時，團隊成員如何解決問題？ 每個成員明確公開地表示對成員幫助的感謝 。

• 這個問題應該主要是出現在各部分的對接之中，如前後端的對接、爬蟲與資料庫的對接、資料庫與後端的對接。出現問題時大家會一起在會議上討論，在工作中大佬們對整體工作會對整體工作進行說明（即對接時所需要做什麼），起到了很大的幫助。總之，互幫互助，有事討論，解決問題。隊員進行互相交流來解決問題，在開會時就共同討論來商討方案，在宿舍時就通過線上溝通來解決。

• <郭海龍>：我感謝<其他九位成員>對我的幫助， 因為某個具體的事情:
  萬事開頭難，第一次擔當小組長，帶領這麼一個團隊相當沒有經驗，一種摸不著頭頭腦的體驗感：你不知道該如何前景規劃，你不知道該如何分配任務，你不知道該如何push組員。很感謝我的隊友們，帶著我一步一步不斷學習，不斷進步，我們的團隊也不斷成長，不斷進步，慢慢去調整、去優化、去挑戰！

• <伍浪>：我感謝<謝文灝>對我的幫助， 因為某個具體的事情:
  在前期我對於我該如何進行具體工作產生迷茫時，他回答了我的疑問讓我確切了自己所負責部分該如何去學習和實現。
  <伍浪>：我感謝<李涵>對我的幫助， 因為某個具體的事情:
  在我被軟工折磨的死去活來時，是他在我閒暇之時陪在我身邊，讓我緩解壓力，能夠以更飽滿的精神和跟良好的心態。

• <汪煒劍>：我感謝<伍浪>對我的幫助， 因為某個具體的事情:
  他總是耐心地給我答疑解惑，並且也很好地督促了我學習新知識。

• <劉雨歡>：我感謝<謝文灝>對我的幫助， 因為某個具體的事情:
  在完成基礎的前端介面,因為知識的匱乏,與後端的介面不知道如何加進去,他主動將這方面的任務承擔,程式碼是我們在網上找的修改,大部分的程式碼我們也看不懂,他需要額外花時間讀懂程式碼,這些我們前端的同學感謝他的幫助。

• <葉紹文>：我感謝<寧乙浩>對我的幫助， 因為某個具體的事情:
  在完成軟工實踐的過程中，每當我遇到困難停滯不前時，我的舍友寧乙浩都會給予我積極樂觀向上的鼓勵，讓我可以用一種良好的心態面對困難，所以在此我感謝寧乙浩對我的幫助。

• <謝文灝>：我感謝<葉紹文>對我的幫助， 因為某個具體的事情:
  在我沒有思路的時候，更葉紹文進行溝通交流後，我獲得了許多靈感。

• <寧乙浩>：我感謝<謝文灝>對我的幫助， 因為某個具體的事情:
  他在我遇到困難的時候能夠激勵我，給與我鼓勵，他積極向上學習的態度與精神給我很大的激勵。

• <謝之越>：我感謝<詹珊，劉雨歡，葉紹文>對我的幫助， 因為某個具體的事情:
  他們對任務態度端正並且在前端任務上完成出色，在前端學習為我分享了許多學習資料，讓我學習到了許多前端相關知識。
  <謝之越>：我感謝<郭海龍>對我的幫助， 因為某個具體的事情:
  他是一個很負責的人，在我們小組每一次會議中組織規劃好需要完成的任務，帶著我們團隊前行，對我的幫助很大。

• <詹珊>：我感謝<謝文灝，劉雨歡>對我的幫助， 因為某個具體的事情:
  此次alpha衝刺我負責的是前端介面的實現。由於之前只在結對程式設計中接觸過微信開發者工具來實現前端，但此次做的是一個app，加上團隊討論之後決定採用vue來做前端的框架，實在是從未接觸過，只好從頭學起。還好有大佬謝文灝同學在群裡分享了vue的速成學習視訊，後來劉雨歡同學又在群裡分享了uniapp外掛的使用方法，讓我在學習的過程中少走了很多彎路。不僅僅是他們兩個，在此次的alpha衝刺中，每一個隊員都給了我很大幫助，十分感謝。

• <李涵>：我感謝<郭海龍>對我的幫助， 因為某個具體的事情:
  在此次alpha衝刺中，我們親愛的隊長在百忙之中還是組織好了每一次會議，甚至有早上出門，到了第二天凌晨才能回到宿舍的情況，以及他用每次用溫柔的聲線和我們對話的聲音，依然在我腦袋裡餘音嫋嫋，我非常感謝隊長的負責，為這一個團隊做出的所有貢獻，他就像是我們團隊的脊柱，支撐著我們前進，承載著我們的精神。
  <李涵>：我感謝<謝文灝>對我的幫助， 因為某個具體的事情:
  我很清楚文灝大佬是我們團隊的核心，名義上他屬於後端小組，但是對前端和資料庫都做出來卓越貢獻，在後端組更是一個人撐起了一片天，他就像是我們團隊的大腦，沒有他我們行將就木，有了他我們運籌帷幄決勝千里。
  <李涵>：我感謝<伍浪>對我的幫助， 因為某個具體的事情:
  伍浪是個開朗的哥們，在每一次會議中都積極發言，在答辯演講中也表現的非常優秀，同時也能關心隊員，對隊員之間的溝通和工作對接也起到了一定作用，他就像是我們團隊的口舌，能說會道，鼓舞我們的士氣，述說我們的故事。
  <李涵>：我感謝<詹珊，劉雨歡>對我的幫助， 因為某個具體的事情:
  她們是學習能力最強的兩人之二，在前端的學習中，她們總能最快的學習知識，做出預想的成果，她們勤勞又智慧，如同我們團隊的雙手，兢兢業業，戰必勝攻必取。

4.學到了什麼? 如果歷史重來一遍, 會做什麼改進?

• 人和大於天時與地利，團隊的和諧是最重要的，大家齊心協力朝著一個目標努力，就能無往不勝。如果歷史重來一遍，在這一點上我們做的很好，不需要回到過去。

2.2.8 總結

• 郭海龍：
  最大的感觸就是溝通，小組的溝通是最大保障。溝通得好，任務進展順利；溝通不及時，可能分工停滯不前甚至出bug。其次就是學習，及時的快速的學習能力，對於軟工專案來說有質的提升。最後感謝我得隊友們，大家相互進步相互成長，漸漸熟悉彼此，默契彼此！

• 李涵：
  在這一段時間內，我學習了很多知識，包括資料庫，Java，js等，也和大家度過了勞累又愉悅的一天天。雖然我主要負責文書類的工作，但是陪著大家也瞭解到了軟體開發各個分組的流程，收穫滿滿。

• 伍浪：
  1，第一階段主要負責的是資料庫部分，將前端爬取的資料存入建立的資料庫，中間用到了資料庫課學習的一些知識，學習到了許多新知識。
  2，做事情不要拖拉，提前做好計劃，然後抓緊時間執行，這次團隊作業，前期學習階段划水了比較久，影響了後續工作，以後要好好吸取教訓。
  3，團隊交流是非常重要的，在工作中出現過由於對接問題出現無用功。

• 汪煒劍：
  這次衝刺讓我學到了很多知識，也意識到自己的很多不足。從理論到實際工作的完成並不容易，很感謝成員們的付出，我也要努力趕上他們的步伐。

• 劉雨歡：
  上一週的alpha衝刺一週的時間都很焦慮,從一開始確定自己加入前端,一開始我也花了大量的時間去學習Android開發的相關知識.我們組都是小白,沒有一個指導我們從哪裡開始,前端的框架使用哪個,在第二週的答辯時,聽到很多組都使用vue框架.我就向大家建議先學vue吧,在看B站視訊的時候發現HBuilderX和uniapp很搭,裡面有外掛市場可以用,我們的前端介面大部分是從外掛市場中找到使用的,在使用的過程中，也遇到了很多不懂的,兩個元件放在一起就不行,往往令我很崩潰,在這個過程中,又發現UView也是一個很好的框架,裡面有很多可以直接用的,但我們已經用uniapp寫了主介面.Uview的現成的介面更精美,但我現在是不太敢和隊友說使用Uview如果我們後續加入Uview不知道前面做的能不能整合到一起,寫後端介面的同學可能會崩潰。就到目前為止，我們前端小組的氛圍都是互幫互助，上一週我們大家基本上都有考試，在我有數學建模考試的那兩天，另外兩位同學考完了。他們倆主動接過一部分任務繼續完成。這一段時間最大的遺憾是，沒有一個指導我們方向的，大家都是小白，在摸索中學習，一開始介面分配沒有做好，我們頁面的完成是序列的，所以導致進度很慢。

• 葉紹文：
  在軟工實踐的過程中，我碰到了很多的困難，絕大部分的知識都是現學現用，因此花費了挺多的時間。但付出與回報是成正比的，我也從中收穫了很多，希望以後能夠學到越來越多有用的知識吧。

• 謝文灝：
  大家一起努力就能取得意想不到的成果。

• 寧乙浩：
  經過這段時間，我認識到了開發一個app所需要的流程，知道了自己的不足。隊友們都非常的給力，而且能夠認真的做好各自的任務。這段時間我由於比較薄弱的程式設計能力，就在學習java，努力的提高自己的程式設計能力。

• 謝之越：
  在本次團隊作業中我學習了很多關於前端的新知識，並且瞭解到了軟工的各個過程的流程。其實軟工理論中，並沒有規定那麼具體每個人要如何程式設計，這都需要我們去親身實踐，親身嘗試，這也再次印證了軟體工程是一門需要實踐的學科。最後，雖然開發過程中遇到不少困難，但我真的很高興能與團隊做出一個專案。

• 詹珊：
  在本次的alpha衝刺中，經歷了視訊學習vue、uniapp文件瞭解、上手實現介面的階段。但也確實由於之前沒有接觸過vue以及uniapp，上手比較困難；同時，對於外掛的使用也不夠熟練，還經常碰到一修改就出現大量bug的情況；此外，就是介面的整合部分，和隊友共同實現了一個介面的不同部分，但是整合在一起容易出現介面覆蓋以及比例失調的問題。這些都是在此次alpha衝刺中碰到的困難。此次alpha衝刺前端介面確實實現得不夠理想，還有很多地方有所欠缺，這也導致整個專案進展緩慢。我也會吸取此次alpha衝刺的教訓，希望可以在β衝刺中做得更好！