組長博客鏈接
http://www.rzrgm.cn/147258369k/p/15573118.html

一、基本情況

1.1 現場答辯總結

• PPT制作方面略顯粗糙，對于產品描述的具體內容不太清晰，需要改進
• 視頻配音部分背景人聲比較粗糙，講解過程體驗感并不盡如人意
• 產品數據的解析需要更加完善，對于各部分內容需要稍加改動
• 盡量刪除不必要的，參考意義不大的數據展示
• 可以考慮比較好的推廣策略，提高產品知名度

1.2 全組討論的照片

1.3工作流程

1.4組員分工及組員工作量比例

二、總結思考

2.1 設想和目標（4分）

2.1.1我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述 ？
我們的軟件“奶茶攻略”主要定位于從事奶茶行業的實體經營者，對于奶茶大數據有明確需求的數據分析開發人員，對全國各地奶茶的消費數據進行有效整合與合理化分析，進行較為簡單明了的可視化呈現，并在此基礎上為經營者用戶推薦當前較為可行的營業方向。以提供可靠優質的數據服務為本產品的核心準則，該定義比較明確，典型用戶屬于從事奶茶行業的相關經營者，典型場景是對于對奶茶行業走向趨勢有了解需求的時候提供該信息渠道。

2.1.2我們達到目標了么?（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了么？ 原計劃達到的用戶數量達到了么?)
可以算是達到了我們α沖刺的基本目標，原計劃的功能幾乎全部實現，剩下的部分就是前后端的精確對接任務，以及交互性的完善，交付時間相比原計劃需要往后延時，尚未投入使用，所以還未確定既定用戶數量。

2.1.3用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?
在軟件推出之前用戶暫時為我們開發人員，所以和我們預先的設想一致，而我們團隊一直都在朝著我們的目標前進，同時也確實離我們的目標更近了。

2.1.4有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
基本上需要總結反思的就是需求分析階段問題，歷史如果重來的話，我們想做的最大改進應該是那時候應該再明確些研發方向，之后在細化功能的時候才不會那么吃力。

2.2 計劃（5分）

2.2.1是否有充足的時間來做計劃?
我們團隊有很充足的時間做計劃，在學期初確定選題之后就制定了初步項目計劃和分工，有充足的時間進行調度和進一步修改計劃。

2.2.2團隊在計劃階段是如何解決組員對于計劃的不同意見的？
我們團隊隊內氛圍友好，民主氣氛濃厚，在有不同的意見時會提出，并在團隊共同討論商議。

2.2.3原計劃的工作是否最后都做完了? 如果有沒做完的，為什么?
前端和后端各自的原計劃的內容大部分完成了，但是由于計劃趕不上變化，解決一個問題時會衍生出新的問題，加之前后端對接難度較大，目前對接部分暫時未完成。

2.2.4有沒有發現做了一些之后看來沒必要或沒多大價值的事?
由于組內分工得當，計劃較為精確，所以并沒有出現“做無用功”的情況。

2.2.5是否每一項任務都有清楚定義和衡量的交付件?
在真正開始項目之前，我們對項目進行過程中將會遇到的各項任務不能夠做到完全的估計和衡量，隨著項目的推進，我們對于各項任務的認識愈發得清晰了起來，基本上對每一項的任務都做出了清楚的定義并制定了衡量的交付件。

2.2.6是否項目的整個過程都按照計劃進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?
大部分過程都按照計劃進行了，項目的意外就是在最后要發布的時候發現了很多 bug，修了一整天。風險預估到了，所以修 bug 還是預料中。

2.2.7在計劃中有沒有留下緩沖區，緩沖區有作用么?
我們在計劃上預留下了兩天左右的時間緩沖區，這個預留的緩沖區對我們項目的最終完成起了很大的作用。

2.2.8將來的計劃會做什么修改？（例如：緩沖區的定義，加班）
將來的計劃中將會留下更多的時間緩沖區用以解決發生在意料之外的情況，以及更好地完善產品；進一步改善任務的分工安排，優化團隊間的合作，提高團隊的工作效率，避免不必要的“加班”。

2.2.9學到了什么? 如果歷史重來一遍, 會做什么改進?
在這次團隊沖刺中，我們團隊協力完成了Alpha版本的發布，在這一過程中，我們不僅在各自研究的前后端領域學到了全新的知識，還認識到了好的計劃調度和團隊合作對整個項目進度的重要性。如果歷史重來一遍，我們會事先做好更加完善的計劃，可能會更早確定選題的方向和所要完成功能，這樣能更好的協調組內分工細則，計劃也會更加明確。

2.3 資源（3分）

2.3.1我們有足夠的資源來完成各項任務么?
1.資源稍有不足。
2.在前端開發上大家還沒有開發經驗，開發人員全力以赴學習，但對于各方面的實現較為緩慢。
3.在后端開發上有較好的基礎，對Python語言較為熟悉，但對后端數據獲取一直沒有找到較好的渠道，導致進度在一段時間內一直處于低迷狀態

2.3.2各項任務所需的時間和其他資源是如何估計的，精度如何?
對于不同任務根據人員學習能力，編程能力估計時間、資源。精度不太準確，實際開發中，在前期的環境搭建上遇到一些問題耗費一定時間，導致部分功能實現緩慢。

2.3.3測試的時間，人力和軟件/硬件資源是否足夠? 對于那些不需要編程的資源 (美工設計/文案)是否低估難度?
1.測試的時間，人力和軟件/硬件資源不足夠。Alpha階段的測試暫時由任務負責人員自行測試，還存在些bug需要花時間修繕。
2.沒有低估難度，在不需要編程的資源 (美工設計/文案)上，有專門人員進行，同時文案設計上全組通力配合，進行順利。

2.3.4你有沒有感到你做的事情可以讓別人來做（更有效率）?
沒有，在任務分工上人員分配合理，各人員在負責任務上有效的發揮自己長處。

2.3.5有什么經驗教訓? 如果歷史重來一遍, 會做什么改進?
經驗教訓：及時的線下技術交流、功能實現討論能進一步有效推進開發的進度，同時提高開發的完成質量。
改進：任務開發人員及時進行討論幫助，加快解決相互之間的一些問題，減少在相似問題上所耗費的時間。

2.4 變更管理（4分）

2.4.1每個相關的員工都及時知道了變更的消息?
每個相關組員都能夠及時知道變更的消息。

2.4.2我們采用了什么辦法決定“推遲”和“必須實現”的功能?
我們根據產品完整性的需求來決定“必須實現”的功能，而將耗時長，且非核心的功能進行“推遲”。

2.4.3項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?
我們項目的出口條件是否能夠實現數據圖表良好交互性，數據是否能比較明晰地呈現，能否給予用戶較為直觀的信息解讀。

2.4.4對于可能的變更是否能制定應急計劃?
對于可能的變更我們有制定應急計劃，我們有先做出一個保底的成果，然后再在此基礎上進行更進一步的學習與工作。

2.4.5組員是否能夠有效地處理意料之外的工作請求？
我們組員能夠及時補足自己的知識缺口去應對意料之外的工作請求。

2.4.6學到了什么? 如果歷史重來一遍, 會做什么改進?
我們學到了如何將工作的輕重緩急給分配清楚，如果重來一遍，我們會更加及時的根據任務的重要性與難易程度來合理變更組員的工作任務。

2.5 設計/實現（4分）

2.5.1設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
由我，天一，欽凱三人合作完成，時間較為合適，人員也比較合適

2.5.2設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
有碰到模棱兩可的情況，團隊一起商量一步一步統一想法進行解決。前端組討論以后，決定頁面調整以簡潔清晰美觀便捷為開發方向。后端組的成員也通過交流和討論確定了數據展示類型、數據獲取渠道及數據庫設計方向并進行了明確的分工。

2.5.3團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？
使用了uml來幫助設計和實現，效果不錯。

2.5.4比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？
目前還是有一些區別的。在項目開發過程中，我們希望將項目更好的制作與呈現，所以對制作的成功進行初步優化，故需要進行更新，以更好的輔助開發。

2.5.5什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
生產和開發的環境有些許不同而導致。

2.5.6代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
在pull requsts先粗略閱讀判斷，不合要求的退回，merge后測試新加入部分的功能，若有bug先roll，對產生bug的代碼修改后再合并。
采用下劃線型命名規范，遵循單一職責原則，開閉原則，具有良好的可維護性和可拓展性。

2.5.7學到了什么? 如果歷史重來一遍, 我們會做什么改進?
我們學到了許多東西，團隊成員對于項目開發的流程有了更深的理解與感悟，學到了很多從未接觸過的知識，對于一個項目開發所需的人員、工具和分工情況都有了一定的認識，還有大家的團隊協作以及氛圍都是很好的。如果歷史重來一遍，我們會花更多時間提前學習新的知識，以避免模糊不清的情況影響項目開發進度。

2.6 測試/發布（3分）

2.6.1團隊是否有一個測試計劃？為什么沒有？ 是否進行了正式的驗收測試？
有測試計劃，每兩天沖刺后都會進行前端頁面交互性評估，后端具體是對于數據的請求返回測試，還沒有進行正式的驗收測試，項目還沒有開發完成，前后端尚未對接好。

2.6.2團隊是否有測試工具來幫助測試？
對于api的編寫使用了測試工具runapi和postman，利用Google的network查看請求返回時間。

2.6.3團隊是如何測量并跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
在完成一個階段的時候，會進行功能試用評估，以此跟蹤軟件效能，測試工作的作用總體而言幫助很大，明確了開發過程中需要加以完善和可以簡略設計的內容，主要需要改進的地方便是對于數據呈現后的分點介紹

2.6.4在發布的過程中發現了哪些意外問題？
有時會出現一些請求時延

2.6.5學到了什么? 如果歷史重來一遍, 會做什么改進?
學到了主要用echarts做可視化數據分析的呈現開發，如果能重來，我們會重新分配好分工，安排更合理的開發與測試計劃，不造成“資源浪費”。

2.7 團隊的角色，管理，合作（3分）

2.7.1團隊的每個角色是如何確定的，是不是人盡其才？
1.項目經理這個角色是認為自己有管理能力并且能夠積極督促團隊成員的，有良好的與團隊成員溝通的能力。
2.前端開發是根據成員的興趣意愿、以及團隊需求來確定的。
3.后端開發也是根據學習興趣以及能力來確定的。
4.可以說是團隊成員都是人盡其才，分配得體。

2.7.2團隊成員之間有互相幫助么？
互幫互助的情況經常出現，因為都是第一次學習web開發, 大家共同學習，互相分享經驗、教程，一起解決了很多安裝、寫代碼上的問題。

2.7.3當出現項目管理、合作方面的問題時，團隊成員如何解決問題？ 每個成員明確公開地表示對成員幫助的感謝 （匯總至組長博客）：
<姓名>：我感謝 ___<姓名>__對我的幫助，因為某個具體的事情: _________。

當出現項目管理、合作方面的問題時，團隊也會積極組織開會討論，發表各自的看法，通過投票或其他方式確定最終的解決方案。

• 成員感謝：

  • 葉超煒：我感謝吳杰對我的幫助，因為某個具體的事情：經常會監督我的學習情況，很多時候處于摸魚狀態時他會及時把我拉回狀態，督促我學習新的內容，非常感謝他對我學習效率的幫助。

  • 吳杰：謝謝我們前端的組長蔡煒鑫在前端學習中給我的幫助，比如安裝vue框架之類的，還有一些方面不懂就問，也得到了解決

  • 童錦濤：我感謝張梓晗同學對我的幫助，展示前一天晚上由于我有別的科目要忙，臨時給他布置了一個任務，他很好的完成了。

  • 張梓晗：我感謝童錦濤對我的幫助，因為某個具體事情：由于我是第一次接觸flask的web后端開發，不管是在各種技術方面還是在一些代碼規范方面都很糟糕，錦濤給了我很多代碼技術上幫助，也糾正了我的一些代碼不規范的地方。從他身上學到了很多新東西。

  • 侯欽凱：我感謝錦濤對我的幫助，在選題的時候我們遇到了困難，很多選題都被否決，最后是錦濤提出了一個合適的選題。

  • 陳翁豪：我感謝蔡煒鑫和童錦濤對我的幫助，因為他們在我遇到困難時給了我鼓勵。

  • 蔡煒鑫：我感謝侯欽凱對我的幫助，因為沖刺之前有個auto.js的團隊編程，作為前端人員，這件事我們本應去做的，但由于時間緊迫vue框架還沒學習完，實在沒時間去學習auto.js所以欽凱作為我們的隊長，他就站出來去學了auto.js。

  • 姚天一：我感謝楊開彬對我的幫助，因為某個具體的事情; 我們在產品需求與功能上，UI設計中有大量的交流討論，開彬給了我很多具體思路和實踐方法

  • 陳捷祥：我感謝蔡煒鑫對我的幫助，因為某個具體的事情：在制作圖表部分時，因為我當時要復習搜索引擎準備考試沒有時間，他就把分配給我的任務獨自做完了

  • 楊開彬：我感謝姚天一對我的幫助，因為某個具體的事情; 在產品美工上，很多內容需要和天一合作完成，對于美工定位不太明確的我，很多時候都是在他的幫助下慢慢進步的

2.7.4學到了什么? 如果歷史重來一遍, 會做什么改進?
我們學到了一些團隊協作的精神，如果歷史重來一遍，我們會在一開始動員更早一些，讓彼此了解更快。

2.8 總結（4分）

2.8.1列出組內所有人的心得。

• 葉超煒：
  首次接觸后端編寫，很多操作都處于盲目階段，再加上自身代碼能力較弱，在本次編程中未能幫上太大的忙，但是對于自己的學習進度卻有著較好的規劃，會在自己給自己規定的時間內學完需要學的內容。總體來說，雖然在alpha沖刺階段自己沒有給團隊做出太大的貢獻，但是對于我自身來說，我已經達到了既定的目標，收獲還是挺豐盛的。

• 吳杰：
  在alpha沖刺中，學到了很多有用的知識，前端三件套的學習，vue框架和echarts的使用，雖然感覺學的還不夠充分，但比起啥都不會好多了，軟工作業真是貫穿整個學期，兩天一次的博客也確實帶來了很大的壓力，不過也因此沒有落下軟工的學習，希望在beta沖刺中能學會更多的東西吧。

• 童錦濤：
  團隊項目中理論上要在一定程度上平均工作量，但是由于能力和效率的不同還是無法避免的分配失衡，在分配時沒有站在他人的能力和效率的角度考慮，是自己考慮不周

• 張梓晗：
  這次Alpha沖刺，我是做后端API編寫工作的。在接觸這門課程之前，我對前端后端都不了解。從最開始不知道如何導入隊友搭建好的數據庫、自己測試寫的代碼跑都跑不起來，到后面把bug改完能正常運行，在自己本地能完成相應API的編寫的那一刻，我總算是感覺自己真正成為了一名菜鳥后端工程師。但是在第一次和隊友通過github合作的時候，把隊友搭建好的API框架克隆到本地，卻看不懂，跑不起來，修改代碼pull requests的時候給隊友造成了不少麻煩；到后面掌握藍圖的原理，能正常運行代碼并幫助隊友編寫API接口，自己編寫的API接口能被前端正常調用，能返回正確的數據……感覺自己還是成長了許多的。也希望自己beta沖刺的時候能繼續保持干勁，和隊友一起完成好這個項目。

• 侯欽凱：
  這次的alpha沖刺完成度整體是很高的，從中也學到了很多東西，前端知識，管理和協調團隊的能力都有了進步，但是最后答辯的時候做得不是很好，ppt和其他組的有點差距，然后我們由于是第一個上場，我們用視頻介紹了我們的產品，其他組都用的騰訊會議現場介紹，明顯效果好了很多，感覺有點可惜，我們的產品完成度應該是比較高的，但我的失誤導致了答辯結果不是很理想，下一次我會把視頻和ppt都弄得好一點。還有一點是我們組進度穩定，沒有集體熬夜趕項目，這個還不錯。

• 陳翁豪：
  通過本輪沖刺，我了解并學習前端的許多知識，包括js，vue框架和echarts，在小組成員的幫助下我完成了前端網頁的發布。雖然許多時候還是難以學以致用但是努力過了也不后悔，還是覺得收獲滿滿。現在我更能理解一個項目需要大家的共同努力去實現，對前后端的分工協作有了更深入的了解

• 蔡煒鑫：
  這次沖刺還是收獲比較大的，學習了vue2以及echarts，雖然vue2就用到了很小的一部分，然后我也感覺到了去B站看視頻講解不如到官網查看文檔來得快速以及有效。然后的話就是應該在做項目之前得充分了解我們的需求是什么，這一次我應該做得挺失敗的，給大家指了條錯誤的路，讓每個人都先去學習vue2導致大家也都沒學完，然后我也僅僅是潦草的看了。然后的話就是分工方面，沒有分好，沒有充分的了解組員的情況，挺對不起捷祥同學的，他學了挺多但由于我的分工問題沒有讓他得到好的發揮。

• 姚天一：
  計算機的學科不是孤立的，而是相互依賴。在軟工作業中，用到了不少從前學的知識，在作業中鞏固了知識，同時也讓我意識到，目前掌握的知識還是太少，要多學習。在項目開始前，先作計劃可以更好地利用時間，之前做事情時，總是這做一點，那做一點，大大浪費了時間。

  • 新的知識總是有用處的，所謂技多不壓身。在Alpha沖刺中用到的AE，PR等知識之前有過粗淺了解，在沖刺中有了使用機會，但限于水平，質量堪憂，后續會繼續提升
  • 實踐出真知。在網上看過后的學習視頻和資料如果自己不實操永遠不會真正掌握，還是要多多進行練習

• 陳捷祥：
  這個實踐作業可以說是我參與的第一個這么多人合作完成的項目，因此我在過程當中也遇到不少困難，不知道怎么和組內其他人溝通，不知道怎么配合別人的工作，面對從未涉足的知識領域感到不知所措，不過好在組內的大家都很友好，期間我也努力學習必要的知識技能，雖然實力不足貢獻不多，但也是貢獻自己的微薄之力，在團隊的共同努力下，產品如今已經實現了大部分的功能，離順利完成的時刻也不會太久了，在這里，我想感謝團隊所有人為此的付出，特別感謝前端負責人蔡煒鑫，在我們都缺乏基礎的情況下，他投入了很多時間，完成了前端大部分功能的開發，保證了整體的開發進度。

• 楊開彬：
  在這次Alpha階段沖刺中，我始終把學習作為獲得新知識、掌握方法、提高能力、解決問題的一條重要途徑和方法，本著認真負責的態度去對待每項工作。雖然開始由于經驗不足和認識不夠，覺得在小組產品研發工作中對自身定位模糊不清，之后迅速從自身出發尋找原因，和組內成員交流，認識到自己的不足，以至于迅速的轉變自己的角色和工作定位。為使自己盡快熟悉工作，進入角色，我一方面抓緊時間查看相關資料，熟悉自己的工作職責，根據工作的實際情況，結合自身的優勢，把握工作的重點和難點，盡心盡力完成工作的任務。