最一開始的前兩天，都在磨合跟討論規格，處理些行政上的東西，例如討論要多久開會一次、每天幾點開會、分工與時間安排、研究每一條user story、以及要有哪些路由等等，光是第一天，就從下午2點討論到晚上8~9點，第一週每天至少都花3小時左右在開會。
在分工上，覺得我很幸運，每一位成員都很主動說要承擔工作，不會一件事拋出來後就一陣安靜XD 同時也不會說分工之後，就全部丟給那一位去做，其他人有能力也會去自願去分擔，就像是要交四次作業，幾乎是每一次都是不同人去交的XD 所以每一項工作可以說是每一個人都有處理到。而且其他成員也都有工作經驗，甚至有PM的經驗，我就從中觀察並推敲開會跟安排進度的一些眉角，對一個沒什麼工作經驗的人真的是很難得的機會。
在一開始，都是用ZOOM作為平台來進行討論，一開始也覺得沒什麼問題，但直到要開始前後端串接開始，發現一個能夠長時間、同時分享螢幕、並不吃效能的平台真的很重要；因為ZOOM大概我才剛用吧，都沒有時間限制，其他成員都有40分鐘的限制，每40分鐘就要重開一次，而且要是一段時間沒反應就會強制關閉，就這兩點就會需要一直重開。
直到去用了gather，就直接用AC搭建好的，可以邊做事邊掛著，不然就有需要討論就直接上去，不需要一直在那開ZOOM，同時也能多人分享視窗，對於在釐清前後端做法方面，方便很多。
因為光是兩個學期的分流，就能感覺出來說前後端會不了解對方是如何實現某一個user story，需要互相介紹自己這端是怎麼做的，甚至是一行行code解釋背後機制是怎麼運作的。例如前端要怎麼串後端的API，我真的直到前端成員示範一次，才了解到底要怎麼做到，因為光是工作坊的回答、以及之前課程的經驗，真的無法想像要怎麼做到，甚至覺得是天方夜譚。另外在修正上傳圖片的問題時，也是要拿對方的教材，一行行研究對方那端到底是怎麼做到的，最後是前端成員要我一行行解釋後端的code，才發現問題是出在哪裡。
在twitter專案的部分，最後幾天其實後端的API都弄得差不多了，都在等前端的測試，看少抓了哪些變數、哪些資料跑不出來、或是有沒有跑出錯的東西，此時即時聯絡跟溝通真的就顯得很重要，這時候gather就幫了很大的忙；因為我就那種電腦還行，只要有在做事就會掛在那，要是成員有發現問題，就能即時找到人來處理，不然光靠slack，有時候沒跳出通知，就一直找不到人，工作就會卡在那邊，繼續也不是，等在那也不是。
那時候真的為了修正目前登入的使用者有沒有追蹤其他使用的功能，真的不知道死了多少腦細胞，四個人一起盯著我分享的畫面，一起想到底是要用哪些變數來判斷，偏偏又有不少路由都要用到，最後也是齊心協力才修好。
到了黑客松的挑戰，從後端等前端測試，變成前端在等後端研究好了XD 雖然早早就知道黑客松的題目可能是什麼，但也就只有去官網看看介紹，簡單了解下到底要怎麼做，想說既然是規劃兩天的挑戰，就不要偷跑好了XD 直到了開始後，光是Model要怎麼設定就花了好多時間去討論跟修正，就壓縮到了研究後續功能與讓前端測試的時間。
在這過程中，我的問題是沒有統整出來我研究出的東西、也沒有附上備註，自己埋頭苦幹，寫出來後就自己在摸索、測試，使得另一位後端成員要花很多時間在研究我寫了什麼、前端成員也要花時間從我的code研究說到底問題出在哪，導致拖慢了進度QQ
這次團體專案真的是很難得的機會，之前課程中都是自己做，習慣自己顧好自己的進度就好，真的要實際團隊合作了，才發現原來分工、安排時程、規格釐清等等事情有多困難、多重要，尤其在這種前後端分離的情況下，更需要溝通、了解對方所會的技術及使用的工具，才不會提出很不合理的要求。
由於團隊分工，可以學到他人對於相同功能的不同做法，來充實自己的技術；另外還能藉由文件，在技術上學習到規格確定後要怎麼做紀錄，而在行政上學到怎麼做會議紀錄、開發時程以及QA list等，對我來說是收穫滿滿。
基於前後分離，透過前後端的溝通，不只能了解前後端的差異，也在解釋後端的內容時，使自己對於過去所學的理解更加深刻。
最後，真的很高興能夠有這份團體專案，也很慶幸早早就找到組員，才能有這次合作機會。而且我們的聊天室功能沒有完全完成，之後還約定好要一起繼續完成這樣規格，希望能夠研究的順利XD
以下是我們的Google sheet跟Github：
