小組背景概述
開發模式：前後分離（兩位前端、兩位後端）
負責部分＆展現能力：
PM 能力：
- 統整小組內資訊，向導師和教練彙報
- （PM 能力）注意小組開發狀況
- （PM 能力）小組 Workspace 架設和檔案管理
過去的工作職務內容主要是 PM，沒想到這次實作上還能運用到許多相關能力，像是主動溝通，主動詢問組員需求和建議，彙整小組意見，向上呈報給小組導師和班級教練；以及用文件和表格管理開發流程，透過表格就能看出當前需要完成、進行中和已經完成的任務；建立提問區，並在標題上寫下：求救中、解決中和已解決，讓導師能透過瀏覽標題，就知道這個問題目前的狀況，只需要點進去有標示「求救中」的頁面就好。
工程師能力：
這次開發上跟以往課程中實作很不一樣，沒有助教手把手帶著做，需要自己分析規格，設計邏輯和架構。 第一次自己分析規格，把分析後的內容撰寫成文件，撰寫過程幫助我更有條理得去思考整個架構和每一個 request 到 response 之間會發生哪些事？request 和資料需要如何被處理？有些測試檔內沒有指定的路由，也是在分析規格中找出來的。 進而設計出路由表和寫出前端組員能快速理解的 API Document。也是因為先釐清規格和需要回送什麼資料內容，在撰寫程式碼上花的時間少很多（反而是 debug 和解決問題時間比較多XD），也不容易遺漏需要傳到前端的資料，深刻體會到寫文件的益處和樂趣，有用的文件對大家的開發上有幫助，我也覺得很有成就感。
開發中過程遇到的問題＆反思（心得）：
A. 溝通：
第一次參與多人協作開發，不論是跟前端組員，或是跟同樣是後端的組員，在溝通上都有遇到一些摩擦
- 跟後端組員間：
我習慣先分析規格、釐清問題和各種流程，經過討論之後，才會開始動手寫程式的人，組員則是行動派，想到就開始做。一開始只有討論基本的分工，我負責分析規格、寫文件、規劃 RESTful API 路由和寫一半的邏輯，他負責寫專案基本設定和另一半的邏輯，然後就各自開工。 剛開始的合作過程不太順利，尤其是討論實作細節和流程中，組員性格比較強勢，很多時候讓我覺得很像被「命令」做什麼，而不是在「討論」。
鼓起勇氣說出自己的做法和為什麼會想這麼做之後，同時詢問對方為什麼會想用他的方法，發現到組員不是不能溝通的人。慶幸這樣的摩擦發生在專案初期，後續實作中，我們時常有意見完全相反的時候，有了初期的經驗，我們都能就事論事把觀點闡述清楚，經過討論後的解法，常常是融合彼此做法的第三種答案。
- 跟前端組員之間：
由於不太清楚前端是怎麼使用框架開發，在寫文件和設計 API 路由的時候，需要不斷詢問前端組員資料會怎麼渲染？依照 UI設計稿和 User Story 寫下前端會需要的資料後，再詢問前端組員需要補上什麼資料？初期還在熟悉彼此的開發模式的階段，時常發生聽不懂對方在說什麼，導致需要解釋比較久的狀況發生。
但在和前端組員的溝通上遇到的最大問題，是沒有即時發現前端組員卡在某些技術問題上，組員也沒有即時求助，導致進度落後。單看每天回報的開發狀況（依綠燈、黃燈、紅燈區分），看到綠燈就以為大家都開發順暢。
直到前端組員進入透過 API 取得和串接資料的流程，卻超過一兩天都沒聽到前端組員回報任何問題，我才驚覺狀況不對勁！怎麼可能都沒遇到問題！這時距離向小組導師 demo 已經不到一天，而且距離專案截止不到三天的時間，趕緊召開小組會議，請前端組員說出當前遇到的情況和問題，討論出解法，並把小組情況回報給導師和班級教練。 緊急會議和小組遇到的狀況，讓我深刻理解到溝通的重要性，如果大家能夠每天撥出 15 分鐘，講出自己目前的進度和遇到的瓶頸，或許能早點發現組員遇到的問題，降低開發時程落後的問題，也能即時為需要幫助的組員找到度過難關的資源。
- 反思：
每個人都是獨立的個體，過去的成長背景、經驗和歷練不同，做事情上難免會帶著過去的經驗和習慣，對於壓力的承受度也不一樣。所以就事論事，好好溝通和認真聽彼此講話真的很重要，當大家都願意把自己的想法講出來，別人也願意傾聽，一起找出解決辦法，對一個人來說是大問題的問題，就會變成小問題，甚至不是問題。
另外，設停損點和適度求助也是團隊協作上所必要的，有時候自己卡在一點，容易當局者迷，越想越往死胡同鑽。把問題拋出來跟大家討論，聽聽別人怎麼解決問題，嘗試用對方解法，理解對方的思路，有時候把別人的方法結合自己的方法，反而能創造出更有效率或更有創意的解法。
B. 技術：
分析問題、嘗試作法和解決過程，都在各個問題的相關連結內
情況一：（link)
- 說明跨開發環境導致 script 指令寫法不同，組員用 windows os ，我用 mac os，導致每次 merge main 之後，都會覆蓋掉對方的 script 指令程式碼
- 解法簡述：使用 cross-env 套件
情況二：（link)
- 每次跑測試，跑完之後，資料庫內的種子資料都會被移除，需要重新建立一次，才能再跑一次測試，無法一邊修改程式邏輯，一邊測試修改內容是否符合規格
- 解法簡述：建立專門給測試用的資料庫，就不會影響到開發環境下的資料庫
心得：
除了上面兩個開發過程中遇到的大問題，也有很多小問題，像是 clone下來的專案架構內，套件老舊不敷使用，不斷跳 error message，或是跑測試過程中，有些錯誤情況無法從 terminal 輕易上看，需要一直console.log()去找出問題，以及在撈資料時，耗時過久，需要透過語法先去篩選不要撈出的資料和資料表。 從分析問題、拆解問題、嘗試解法到實際解決問題，一連串的過程，雖然很耗腦力，也佔大多數的開發時間，不過我覺得很有趣，很像在玩解謎遊戲，一點一點找出線索，嘗試解決，這個方法解決不了就再找下一個，直到解決為止。
總結
雖然這次協作專案，組內發生了沒有儘早提出遇到的問題（不論是技術上或心理狀態上），導致最後大家必須連續熬夜兩天到天亮，才能勉強完成專案的情況。以及溝通上跟組員發生各種摩擦，意見不合，或因為對方的態度讓我感覺不舒服。 我仍然覺得很慶幸自己遇到這麼多問題，遇到問題並且認真去想辦法解決問題，才會成長和進步。如果這兩週沒有發生那麼事情，就不會有那麼多學習和成長的機會，像是在請求導師協助前，提問的前置作業要自己先做好，導師才能比較快速就問題點給予指導和協助；還有遇到衝突的時候，即使覺得不舒服，也要理性去面對和解決，願意提出想法和好好說明，自己和組員都會有所成長；以及要更主動溝通，讓小組內大家的聲音是暢通的，問題才能及早被發現和解決。
特別感謝小組導師 Eugene 助教和班級教練 Dan
謝謝導師 Eugene 助教，每天關心我們的開發狀況，甚至主動關心我們有沒有遇到問題，工作和生活都很忙碌，在下班和週末還是會為我們解答，指導和給予協助，對我們的付出遠超過導師的職責範圍。真的超級無敵萬分感謝導師 Eugene 助教（180度鞠躬<( )>)
謝謝班級教練 Dan，在知道我們小組遇到的困難之後，即使休假也不斷關心和詢問狀況，主動幫我們爭取資源、解答和協助解決問題，沒有因為遇到困難無法準時交付專案，而直接判定我們失敗，還給予我們補救的機會，真的超級無敵萬分感謝教練 Dan（180度鞠躬<( )>)