https://www.cnblogs.com/xiao-qingjiang/p/15575571.html

一、基本情況

現場答辯總結：
根據老師的指導和建議，我們充分認識到了我們的不足。
首先是工作量不足，在這次衝刺中我們並沒有很好的完成這個專案，前端效果還需要進一步改善，後端的介面還需要儘快和前端互動，還有展示的形式上也需要改進，需要展示出產品使用的情況，而不是空洞的PPT，非常感謝老師和同學們的建議。

全組討論的照片

評估團隊中每個人對本次作業的貢獻比例，描述為本次作業的工作流程、組員分工、組員工作量比例（禁止一鍋端平的情況，如果沒有評估，組長得分減 50%）

二、總結思考

2.2.1 設想和目標（4分）

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

  • 解決的問題及定義：為有強烈使用需求的外地務工人員及其子女，以及缺乏學習環境和學習指導的在外閩南青少年提供學習閩南語的輔助平臺
  • 典型使用者：有強烈使用需求的外地務工人員及其子女，以及缺乏學習環境和學習指導的在外閩南青少年
  • 典型場景：使用者開啟軟體便可看有關閩南語的推文了解閩南文化，也可以開啟閩南鄉音歌曲感受閩南風情，還可以讀出自己不理解的閩南語進行查詞學習其中文意思，閒暇之餘還可模仿閩南歌曲等進行個人作品錄製，錄製之後可以得到其有關讀音準確性的評分。

• 我們達到目標了麼?（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)
  目標尚未完全完成，需要下一階段進一步完成。原計劃功能全部完成，只是在介面切換的流暢性，資料庫訪問的速度、雲的部署等不盡人意，需要進一步優化程式碼。
  有按照原計劃交付時間交付，原計劃達到的使用者數量尚未達到，因為還未完全上線，所以使用者數量尚未達到原定目標。

• 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
  由於產品未上線，還未推廣和產生使用者，難以評估是否使用者對重要功能的接受程度和我們事先的預想一致。
  離目標更近了，功能實現和預想的沒有太大偏差，很快應該就能夠上線。

• 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
  UI設計較為手忙腳亂，如果歷史重來一遍，會在一開始的時候先確定好介面設計的風格，再有所針對性地去尋找相關素材以便後續進行相關設計。

2.2.2 計劃（5分）

• 是否有充足的時間來做計劃?
  有，計劃的時間還是比較充足的，可以進行相對細緻的規劃。

• 團隊在計劃階段是如何解決組員對於計劃的不同意見的？
  經過協商討論，如果認為某計劃不可行，歡迎提出理由和新的方案，其他成員共同思考，最終得到能讓大家認可並願意執行的計劃。

• 原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
  原計劃的工作成功完成，沒有未完成的，但完成質量不夠高，接下來還需要進一步的優化。

• 有沒有發現做了一些之後看來沒必要或沒多大價值的事?
  有些需要大家共同參與的部落格都是讓成員發文檔給負責人，也許直接發聊天框可能更方便哈哈，就不需要開啟檔案了（懶人操作）。

• 是否每一項任務都有清楚定義和衡量的交付件?
  每一項任務都有清楚定義，並給了每項任務的稽核指標，完成任務需要達到稽核指標。

• 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
  專案的一些子任務的交付時間和原計劃有出入，主要是由於當時沒有考慮到這兩週考試很多（零零總總加起來有四門考試，大部分同學都有一到兩門），因此考試的備考時間沒有考慮到計劃裡，導致後期的進度比較趕。

• 在計劃中有沒有留下緩衝區，緩衝區有作用麼?
  留下了一天的緩衝區用於debug，但這個緩衝區被考試備考時間佔用了，似乎沒有發揮原有的作用，但緩衝了考試備考時間。

• 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
  結合接下來時間的考試、其他課程的作業安排以及同學們的比賽或訓練情況等進行進一步更細緻化的規劃，留出合適的緩衝區，在緊急時候可能會開展加班。

• 學到了什麼? 如果歷史重來一遍, 會做什麼改進?
  配置雲伺服器的難度預估不足，導致預留的時間不足，出現了一些意外之外的配置問題，如果歷史重來，會留出更多的緩衝時間以免出現意料之外的問題。

2.2.3 資源（3分）

• 我們有足夠的資源來完成各項任務麼?
  有，我們的任務所需的資源都是可獲取且容易獲取的，可能比較緊張的資源就是組員們的時間資源了，畢竟這學期課多考試也多，還有其他課程有大作業。

• 各項任務所需的時間和其他資源是如何估計的，精度如何?
  會根據每項任務先進行評估，評估的指標包括完成這項任務是否需要學習未掌握的技術、學習的時間成本、完成的時間成本、以及完成任務需要哪些資源（如框架、介面以及其他成員需要提供哪些資源（如介面）等）。

• 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
  人力和軟體/硬體資源是足夠的，而測試時間比較緊張，測試並不是特別完善。
  不需要程式設計的資源 (美工設計/文案)都分配了比較充足的人員進行完成和稽核，總體還是比較合理的。

• 你有沒有感到你做的事情可以讓別人來做（更有效率）?
  可能讓其他人做效果會更好，畢竟我的文字功底挺一般的。

• 有什麼經驗教訓? 如果歷史重來一遍, 會做什麼改進?
  一開始的雲伺服器沒有先去處理，直到需要部署才開始去找，導致了進度有點緊張，再加上部署過程遇到了一點問題，如果歷史重來，會在部署前做好前期準備工作，預留充足的時間進行部署。

2.2.4 變更管理（4分）

• 每個相關的員工都及時知道了變更的訊息?
  有，每次都會通過qq群進行通知，對於沒有看到的同學會私聊提醒。

• 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
  根據緊急程度和依賴關係進行決定，比如某個功能的實現必須在前一個功能實現的基礎上開展（即該功能依賴前一個功能），那麼該“前一個功能”就是必須實現的；
  如果某個功能與其他功能無關且並不緊急，便是可以“推遲”。

• 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
  針對每個小功能做出了清晰的功能出口條件，但對整個專案的出口條件還未給出明確的定義。

• 對於可能的變更是否能制定應急計劃?
  理論上是能的，但在執行過程中似乎這個應急計劃並不是很有效，因為我們這次的工作便不是完成的很好，希望在接下來的工作裡能夠做好更合理更有效的應急計劃。

• 組員是否能夠有效地處理意料之外的工作請求？
  這取決於組員們的時間安排，如果最近有考試的話就有點難度，如果沒有都是可以有效處理意料之外的工作請求的。

• 學到了什麼? 如果歷史重來一遍, 會做什麼改進?
  做好應急備用計劃，以免不時之需。

2.2.5 設計/實現（4分）

• 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
  設計工作有產品經理，前端、後端、UI的負責人在充分吸取組內成員的意見後進行討論完成的，在alpha衝刺的第一天完成總體規劃，第二天完成較為細緻的規劃。
  是合適的時間，也是合適的人。

• 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
  有，經過討論後確定採納一種確定的方案。

• 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？
  有的，起了很大的作用，使得我們的工作更加規範。

• 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
  有一定的區別，區別主要是在實施過程中有一些之前設計沒有考慮周全的事情，在實踐之後才發現的。需要部分改動並更新UML文件。

• 什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
  部署階段產生bug較多，因為大家對部署的原理不是很瞭解，主要是參考網上教程和部落格進行部署，而網上的質量參差不齊，所以出現了比較多的bug。
  還未成功釋出，非常抱歉。
  設計/開發時這會比較簡單，跟著教程依葫蘆畫瓢就可以，但事實上還是有一定難度的。

• 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
  進行功能測試和程式碼測試，有嚴格執行程式碼規範。

• 學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
  一個成功的專案需要在設計階段就做好規範和細節考慮，如果歷史重來，我們會更好地做好規範（包括程式碼和文件格式）和細節考慮（包括一些具體的技術和功能可能遇到的問題），做好預備。

2.2.6 測試/釋出（3分）

• 團隊是否有一個測試計劃？為什麼沒有？ 是否進行了正式的驗收測試？
  這個暫未考慮，因為我們還沒有成功部署，暫時沒有考慮到測試的詳細計劃，還未進行正式的驗收測試。

• 團隊是否有測試工具來幫助測試？
  有選取幾個比較主流的工具，但還未開展工作，還未確定最終選取哪個工具。

• 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
  團隊還未完成軟體，很抱歉還沒開始測試。

• 在釋出的過程中發現了哪些意外問題？
  很抱歉還未成功釋出，目前前後端互動還未完全完成，我們接下來會抓緊完成工作的。

• 學到了什麼? 如果歷史重來一遍, 會做什麼改進?
  更好地規劃時間，加快進度，做好測試工具的選擇和測試方案，防止測試階段出現差錯。

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

• 團隊的每個角色是如何確定的，是不是人盡其才？
  根據大家所擁有的技術棧和以往的實踐經驗，以及大家未來想要發展的崗位來進行確定角色，做到了人盡其才，也複合大家未來發展的需求。

• 團隊成員之間有互相幫助麼？
  有的，當有同學進度難以趕上時，空閒同學會主動伸出援手。

• 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？ 每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的部落格裡）：

肖清江：
我非常感謝趙威威對我的幫助，因為11.12晚上我有考試，而那天晚上也要提交軟工部落格，感謝她幫我分擔了那一晚上的軟工部落格的撰寫工作。

李忱軒：
我十分感謝陳鬆慶同學對我的幫助，在雲伺服器環境配置出問題的時候，他與我攻克難關，一同尋找解決辦法，讓我的工作壓力瞬間少了很多，同時感謝劉凌斌和陳鬆慶同學在團隊分工上的配合，讓後端小團隊工作進展順利。

陳鬆慶：
我十分感謝忱軒同學對我的幫助，我對許多東西都是十分迷茫的，他給我指引了方向。讓我有了比較明確的工作目標。

劉凌斌：
我很感謝李忱軒同學對我的幫助，這是我第一次參與到後端的工作之中，對後端應該是一直處於一知半解的狀態，感謝李忱軒同學，幫助我走進後端的世界。

楊潮湧：
我感謝黃海濤對我的幫助。
因為某件個具體的事情：在最開始寫靜態介面時，由於第一次上手wxml和wxss，我其實沒什麼頭緒，後來去請教了海濤，才順利完成了最初的程式設計設計。

黃海濤：
我感謝劉璐瑀對我的幫助。在我們的相互交流修改前端介面時，避免ui設計和前端介面不符。

田劍心：
我感謝楊潮湧對我的幫助，因為某個具體的事情：在專案開始之前，楊同學把整個前端的具體工作羅利出來，幫助成員做了規劃，如果沒有他的安排，我感覺可能做出來的成果會更加糟糕。

趙威威：
我感謝肖清江對我的幫助，因為在製作PPT的過程中，有一些部分不知道在怎麼部署，他詳細地為我解答，十分感謝。明白了考慮事情要全面。

劉璐瑀：
我感謝黃慧卿對我的幫助，我們一起尋找素材、確定介面設計風格、研究怎麼使用PS。

黃慧卿：
我感謝劉璐瑀對我的幫助，我們一起做ppt，一起尋找素材以及一起設計介面。

• 學到了什麼? 如果歷史重來一遍, 會做什麼改進?
  時間和進度安排不夠合理，如果歷史重來，會更好地進行規劃和推進進度。

2.2.8 總結（4分）

肖清江：
這次的alpha衝刺中，我產品經理的角色其實不是很合格，沒有做好前期的規劃和規範，在接下來的工作中，我會更好地做好規劃和規範，並在過程中實時反省是否哪裡還需要改善以提高效率和效果。

李忱軒：
由於之前有過一些經驗，以為配置雲伺服器特別簡單，但是在實際上遇到了大量的環境配置問題，在本地成功執行的程式碼，放到ubuntu伺服器上就一直報錯，在Alpha衝刺中，我學了很多東西，對雲伺服器ubuntu配置和gunicorn的部署有所瞭解，並且成功實現了部署，比較重要的是瞭解了以前以為很簡單的東西，好在團隊整體實力偏強，讓我在團隊合作中總能尋求幫助並且獲得解決。

陳鬆慶：
由於我自身的心態，直接或間接地導致一些工作進展受到了限制，我在以後的生活裡應該有所改變。在Alpha衝刺中，我學了很多東西，瞭解了後端的開發流程，加深了對資料庫視覺化工具的使用理解，更重要的是意識到了自己心態方面的不足。好在隊友們比較猛，能填住我自己失誤挖的坑（砰砰砰）。

劉凌斌：
首先，我要和我的隊友們說一聲對不起，因為考試還有學生工作的原因，再Alpha衝刺階段，在軟工方面投入時間大大減少，我們小組沒法按時交付Alpha衝刺成果，負責資料庫的我有不可推卸的責任。但是，在Alpha衝刺中，我學到了很多東西，對資料庫的操作原理更加熟悉，也更能靈活運用資料庫完成一些功能，也學會了提高個人的工作效率，兩天一次的衝刺還是極為驚險刺激，6次的ddl的生產力也是驚人的。最後，還是要感謝我的隊友們。

楊潮湧：
第一次寫小程式，雖然一切都是新的，但在同組同學的幫助和自身的努力下，還是在這次衝刺裡學到了不少東西。同時，我也對於前端的這個角色以及前端與UI、後端之間的關係有了更清晰、更深層次的理解。同時我也發現，人的精力是有限的，但有的時候，你不逼一逼自己，就永遠沒法想象，自己敲程式碼趕ddl熬到一兩點，會越來越精神（逃）。當然，雖然我很感激這段“充實”的生活，但是但是，熬夜是真的傷身體，希望我以後能繼續提升自己的學習效率，該休息的時候，真的還是好好休息為好。

田劍心：
通過本次阿爾法衝刺，完成了前端大部分的功能，但是由於考試等因素，導致時間上預估有所出入，因此前端部分細節做到不夠好。其次，在前後端交接上，一下介面引數上沒交接好，導致工作進展的很忙。總體而言，感覺自己做得不夠好。對於個人能力而言，或多或少的得到了提高。在後續的工作中，應努力做的更好。

黃海濤：
第一次這樣和很多隊友做一個大作業，大家前期交流都不太放得開，進度不快，但是慢慢就加快了。然後我是前端的一員，感覺自己前端完成的不算太好，因為之前學期都沒有學過HTML，css和js。所以得先花挺多時間來學新技術，感覺這樣的過程很折磨，不能一蹴而就的完成分配的任務，雖然動力十足，但是壓力更大。

趙威威：
ALPHA衝刺階段的時間我上網複習了剪視訊的技巧，重新撿起大一的基礎，看了許多教程，自己上手後發覺還可以，並沒有自己想象中那麼難。以及在網上找了一些PPT的模板，還算比較滿意。由於時間比較緊，因此本次彙報的視訊剪得比較粗糙，彙報PPT中一些其他因素也沒有考慮到，希望這些問題都能在BETA彙報階段解決。也希望BETA彙報的PPT做的更加全面，更加有趣。

劉璐瑀：
只在上次結對程式設計作業中接觸了UI設計，剛開始設計此次團隊程式設計作業時也是手忙腳亂的。一開始設計出來的介面不盡人意，後面多次推翻重來，最終設計出了自己感覺比較滿意的頁面。在週六答辯時，被柯老闆“一頓痛批”，說一看就知道是學生作品，不夠成熟，以為又要重來，幸好後面給他看了我們的設計圖，通過了柯老闆的檢查，但是就要麻煩負責前端的同學再次加工潤色了。在與前端人員的溝通交流上存在一定的問題，應該要和他們及時溝通交流，保證一定的還原度。

黃慧卿：
原先不太會使用ps，只會最簡單的填充顏色，經過這次ui設計，對ps的使用更加熟練。雖然大部分介面都並不複雜，但是如何讓介面看起來更協調，更舒服也並不太容易，體會到了每個角色都有辛苦的地方。週六答辯時我們的介面被柯老闆痛批”過於粗糙“，我們以為還要再返工一次，一整個大慌張，幸好最後柯老闆認可了我們的ui部分，只能辛苦前端隊友提高還原度了。