答辯總結：
為完成團隊專案，每個組員都付出了自己的努力和汗水，雖然歷經坎坷但最終迎難而上。即使每個人的技能、積極性和工作態度各異，但都在alpha衝刺中得到了成長。
全組討論的**：
測試組提問：
1、 分割依據可以多項嗎？
答：可以做到多項，如果分割依據選擇多項的話，以兩項為例，比如說學號前六位和姓名第一位（也就是姓氏），則所有學號前六位和姓氏都一樣的記錄匯出在同一excel檔案中，而所有學號前六位或者姓氏不一樣的記錄都在不同的excel檔案中。
2、此次展示沒有前端展示，那在前端介面互動上，如何選定相關的格式，比如**某一欄限定格式，其他欄格式不變？
答：因為現在前端和伺服器端的互動還沒正式開始，我們認為這個要參照我們後端的**，進而設計出具體的互動的方式，所以還是要等真正互動時，根據需要來做出調整。
•主要解決的問題：我們的文件處理器主要用於解決辦公學習中excel、word之間的大規模的轉換。
•這款軟體主要運用在辦公室和學生或者其他的大批量資訊管理中，例如四六級眾考生成績excel批量轉成word，企業公司員工請假及日常填報資訊word彙總自動生成excel等。
•原計畫主要核心功能為四個，現在每個功能後端都已經初步實現，但還需要一些演算法上的修改完善，爭取更高效更完善。
•未在原計畫時間內完整交付，前端頁面的互動方面以及後端的功能拓展方面還未完成。
•原計畫沒在alpha衝刺中設定使用者數量，現在由於只有初步的後端模型所以使用者侷限在組內。
•在經過問卷調查，抽查找問使用者後，使用者對重要功能的接受程度在大致上與我們的事先預想是有許多共同之處。
•在經過對潛在使用者的調查後，我們認為我們目前所努力的方向是正確的，所以是逐漸靠近目標的。
•剛開始的設想目標，感覺稍微偏離實際的方向。如果歷史重來一遍，我們會更加盡可能考慮到方方面面。
•在時間規劃中，做計畫的時間是比較充足的。
•在計畫階段面對組員不同的意見 ，選擇是讓隊員們充分提出自己感到不合適的地方，而後採取協商處理或者重新提出新的意見計畫。
•原計畫的工作大部分都做完了，但也存在部分沒做完的工作，因為開發過程中遇到了一些沒預期到的困難，解決這些困難花了不少時間。
•並沒有，因為每一件事都是一種經驗和新的經歷，這在以後，面對相似的場景時會處理更加熟練。
•大部分都是有清楚定義和衡量的交付件的，但出於經驗問題，無法覆蓋清楚定義每一項任務的交附件。
•並沒有整個專案都按著計畫進行了，最主要的意外還是知識儲備方面與能力方面帶來的導致任務進度上的時間規劃出現偏差。
•前後端互動的技術難度是當時沒有估計充分的，因為缺乏開發經驗。
•有留下緩衝區，緩衝區是有作用。
•在緩衝區上估計會比這一次的衝刺要少一點，爭取在加班上比這一輪的衝刺要少。
•在計畫方面學到了緩衝區的作用，這對我們的任務完成調節挺有用的。如果重來，我們會在這上面預留的時間更加的上心一點。
•不能說有完全足夠的資源來完成各項任務，有的任務的技術難度目前還是在我們的能力之外，但我們會努力利用已有的各項資源來完成任務。
•通過自己已有的知識儲備，以及通過查閱資料後的了解，將各項任務所需時間和資源進行乙個估計。
精度方面不說完全貼切，但是大致上還算是較為準確的。
•測試時間、人力和軟體/硬體資源目前來看是足夠的。
•不需要程式設計的資源一開始稍微低估了難度，但主要也是因為沒經驗導致的，所以總體上還算是可以的。
•並不是很確定，最開始進行任務分工的時候，隊員們是盡量按照自己的能力來進行挑選任務的。
•經驗教訓：在進行資源和時間分配上，需要更加的明確具體。
•會做什麼改進：任務分工更加明確，時間分配更加合理。
•是的，在群裡發布變更訊息後，相關人員都會回覆。
•對功能任務進行評級，評出功能重要程度的等級，將資源優先傾向於能夠實現且 重要的功能，就此決定出「推遲」和「必須實現」的功能。
•「做好了」，應該是在測試上首先是達到可靠而合格的要求，其次，我們將分別模擬使用者進行操作測試，還會邀請真正的潛在使用者進行測試評分，不可能一下子預料到所有問題，但是起碼要經得住使用者簡單的操作測試。
•可以的，而且將會集中大家的意見針對常見的變更預留應急計畫。
•可以的，相信自己的隊員，以及強大的網路支援。
•在變更管理上，我們體會到了計畫安排和變更之間的聯絡。如果能夠重來，我們應該會在一開始估計更多的可能的困難和可能出現的問題，避免變更頻繁。
•是由李佳樂和吳潔穎完成的，是。
•出現過，是由大家共同討論解決的。
•由於後端演算法初步完成還需要變動**進行優化，所以目前還未運用單元測試，將來完善**後會運用單元測試測試**效能，有使用jmeter工具測試系統效能，對伺服器壓力等資訊可以反映出來。
•沒區別，不需要更新。
•在批量word歸併到excel這個功能實現的過程中產生的bug比較多，因為word歸併到excel中，應用場景word檔案是**形式的比較多，而**可以有非常複雜的形式，所以這方面的解決也需要不少時間。產品並未進行發布，所以沒有出現發布之後的重要bug。
•**複審由隊長負責，正在改善**規範中，會努力嚴格規範**，**規範後，會由負責測試的隊員進行測試。
•學到了什麼：後端功能的實現中學到了如何利用強大的庫函式解決問題
•會做什麼改進：在整合**之前做好交流，使**整合之前就更加規範，減少**整合時間。
•有測試計畫。由於開發尚未完成，所以暫未開始驗收測試。
•使用jmeter進行測試。
• 首先進行介面測試，測試網頁是否能連線；連線成功之後進行效能測試，測試網頁的請求數、響應時間、錯誤率與吞吐量。這些測試工作還是有用的，能夠觀察到網頁的效能如何。改進的話就是細節問題吧，不是很全面。
• 花費的時間超出預期：因為以前沒有這方面的知識，所以幾乎所有東西都是現學的，比較費時間。
• 學到了如何測試網頁；如果歷史重來，我們會提前了解一下這方面的知識，有所準備。
•在確定團隊角色時，我們本著自願優先的原則，盡量保證每個成員分配的任務都是他所擅長或感興趣的，做到人盡其才。
•有困難的時候會密切溝通，互相幫助。
•當遇到管理合作的問題時，我們會先在群裡初步溝通，然後挑選乙個大家都有空的時間，當面交流討論。
•學到了如何資源利用最大化和團隊協作的重要性，如果重來，我們會在目前薄弱的地方多安排人手。
•屬於defined檔次。
•在磨合的後期。
•增強了團隊協作能力，隊伍的凝聚力有了顯著的提高，各方面的開展更加規範。
•目前最需改進的是—每個隊員完成工作的責任感 ；對照敏捷開發原則，我們小組做的好的方面有：
① 簡單化是根本（不做過度設計和**）。在設計介面時，我們將設計重心放在了4個核心功能
頁面的設計上，專案本身除了基礎功能設定外幾乎沒有其他多餘的功能。
② 每隔一定時間，團隊會在如何才能更有效地工作方面進行反思並對自己的行為進行相應調整。
我們每週都會開3-4次的會議來交流各小組的成果進度，並據此做出接下來的規劃。
③ 在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談。
我們每週都會開3-4次的會議來交流各小組的成果進度，並據此做出接下來的規劃。
第07組 Alpha衝刺 總結
答辯總結 為完成團隊專案，每個組員都付出了自己的努力和汗水，雖然歷經坎坷但最終迎難而上。即使每個人的技能 積極性和工作態度各異，但都在alpha衝刺中得到了成長。全組討論的 測試組提問 1 分割依據可以多項嗎？答 可以做到多項，如果分割依據選擇多項的話，以兩項為例，比如說學號前六位和姓名第一位 也就...
第07組 Alpha衝刺 總結
答辯總結 為完成團隊專案，每個組員都付出了自己的努力和汗水，雖然歷經坎坷但最終迎難而上。即使每個人的技能 積極性和工作態度各異，但都在alpha衝刺中得到了成長。全組討論的 測試組提問 1 分割依據可以多項嗎？答 可以做到多項，如果分割依據選擇多項的話，以兩項為例，比如說學號前六位和姓名第一位 也就...
第07組 Alpha衝刺（6 6）
還剩下哪些任務 還需要帶領團隊進行前後端同步的修進 遇到了哪些困難 github ip和本地ip不符合，調了好久 有哪些收穫和疑問 無，沒有疑問。組員 容慧珺 接下來的計畫 完善前端頁面 還剩下哪些任務 繼續美化頁面 遇到了哪些困難 頁面的排版有點醜 有哪些收穫和疑問 收穫就是更加熟練前端語言 疑問...