事前準備
找好隊友之後，如何與隊友達成共識並追蹤進度很重要。我們達成協議使用 Notion、Trello、Google excel sheet 作為主要工具（重要程度是Notion > Trello > Google excel sheet），以下分項介紹：
Notion ：作為共同協作的主要 workspace
notion 可以說是我們的大平台(?)，任何跟專案有關的東西都必須放在 notion 上面，包含時程、個人進度及筆記、bug 清單、個人 github/ trello/ google excel sheet 的連結、user story、 UI 稿等，簡單來說可以從 notion 找到所有跟專案相關的一切。
notion 的操作簡單易懂，上手也很快，個人十分推薦作為多人協作時的 workspace！
Trello：分工及進度追蹤
我們決定以 trello 作為「任務分工」及「進度追蹤」的平台。（原本打算在 notion 上做，但這種划拉卡片的方式還是 trello 做得比較好～）
在使用 trello 之前，很重要的一點是與團隊成員定義好開發流程，下圖是我們談好的開發流程：
- Sprint to do：可以當作 Task List，根據 user story 或者團隊討論出來的 acceptance criteria 所定出需實作的細項，每一張卡片就是一個 task list
- Developing： 當工程師要開始開發時，則將卡片移動並標註自己的名字，作為一個開始動作，同時也可讓大家知道目前每個人正在開發什麼內容
- Blocked by：若有卡片開發到卡住（可能是需要等其他人的某些功能開發玩才能繼續、或者test fail…etc），則將卡片移到此處
- Done：已完成開發的卡片，開發者需發 PR ，同時通知 QA (a.k.a 要 review 的人)
- Review：QA 開始 review 的時候，把卡片移到 review 區域。之後該卡片會依照 review 結果移動： pass 的話 → 移到 to deploy；fail 的話 → 移到 to revise
- To revise： code 有需要修正的地方，QA 須在 PR 中註記，並將該卡片丟至此處
- To Deploy：QA review 通過，並將該分支 merge 回 master（但此時還沒有部署到 heroku）
- Deployed：功能正式上線(a.k.a. 部署到 heroku) 並確認沒問題後，卡片就會丟到此處，此時才算流程完整跑完，大家也能在此看到已上線哪些功能
Google Excel Sheet：規劃路由及 acceptance criteria
notion 中的表格不算特別好用，因此這兩塊我們移動到 google 雲端硬碟來規劃及追蹤。
acceptance criteria 是專案初期很重要的一環，目的是團隊們要達成共識：哪些 feature 一定要被驗收，這也是之後 trello 分工的基礎。
我們的運作方式是：團隊先講好，在第一次 internal kick-off meeting 之前，先各自看完 AC 題目中的 user story 並各自到這份 acceptance criteria 中編輯 -> 第一次會議時逐條 review 每一項任務清單，確認每人都同意此標準 -> 分工並列出 owner -> 當開發者做完發 PR 時，需要來 acceptance criteria 勾選進度，review code 的人要覆核該項是否完成。
路由總表則是讓團隊們更清楚如何串接，例如我們將首頁、個人頁面分工，但各自的頁面或 nav bar 都需要做連結連到其他頁面，這時候就可以來路由總表確認自己放的路由是否正確。
專案開發
我們的分工大概是：
- Yunya：專案初始化(基礎建設)、登入驗證機制、admin 後台所有 feature、前台首頁、部署 heroku
- 任：nav-left 、三個 modal 、API 相關路由等
- Andy：nav-right、前台的 user profile 所有頁面等
但這也不是一開始就分工好，我們大概每 2–3 天會開一次小組會議，每次會議訂出下一次會議前個人要完成的項目，而每次會議時也會動態調整任務分配：例如可能發現這次 A 的預計完成進度沒有達標，B 和 C 就會跳出來分工或接手剩下的任務等等，總得來說我們小組的成員都很負責!!
前端 CSS
由於我們三個組員都是主修後端，因此一開始就有共識「盡可能 follow 設計稿，但不求百分百相同」。
一開始有在專案 public 資料夾規劃 style.css，但其實還是有非常多 CSS 是直接寫在 HTML 裡面的，這的確會造成後續的維護困難，不過因為 simple twitter 只有 2 週的時間，所以這部分我們沒有再花時間去調整把 style 拉出來，小組成員的目標就是「把專案做出來」！
另外，雖然我們是三個後端組成的團隊，但最後實作出來前端的完成度很高！還意外獲得導師的稱讚（甚至有比一些有前端的團隊還要細緻～）這也算是意料之外哈，還記得在第一次與導師 kick-off 的時候，導師有問過我們三人為什麼選後端，大家的答案都是「因為不喜歡前端切版/ 調整 style 很煩」，沒想到大家意外的有天份 XD
modal 應用
這部分對我來說比較苦手，還記得一開始看到設計稿要求要做 modal 的時候我滿頭問號，很感謝組員們研究 modal 的 HTML 和 JavaScript 方法後分享給我，讓我重拾了當初操作 DOM 和塞資料的記憶~
邏輯操作上其實很簡單：先在頁面的 icon 埋 modal （我們使用 bootstrap ）-> 例如 reply-modal 或 profile-modal 這種要塞資料的，需要在頁面最下面放一個 script 去監聽 -> user 按下按鈕的時候再把資料塞回 modal
Git 協作
我想 git 應該是很多人會覺得滿頭問號的部分，針對我們這種「多人協作的小白」，我的建議會是：
- 組員 local repo 的進度要隨時跟上 remote repo 的 master
- 分支 merge 回 master 後，要馬上告知組員 master 有更新
- 每個人開分支的時候，要很清楚從自己從 master 的哪一個 commit 節點往外長？這個 commit 包含哪些功能？不包含哪些功能？
- 這個分支會動到哪些檔案？（必須與隊友們討論好，盡量不要在不同分支修改到同一個檔案；若需要動到，也盡量選定一人修改，以免最後合併時遇到 conflict）
- 談好開發順序
- 團隊中必須至少有一人非常清楚整個 master 和 branch 進度，並隨時追蹤
如果對初學者來說 sourcetree 看不太懂，也可以參考下圖這種更直觀的視圖來追蹤～
PR 及 code review
這點倒是(意料之外)我在這次的 simple twitter 中學到滿多的部分～以往都是自己寫自己的 code，不需要去管別人怎麼寫、寫得對不對，但在多人協作時 code review 其實很重要，影響層面包含：
- 組員的寫法是否會造成 bug 或 side effect（重要！）
- 組員的寫法是否符合規格或 acceptance criteria（重要！）
- 組員的寫法是否符合整體 code style
- 組員的寫法是否有優化的地方
本次因為時間不多，所以我個人在做 code review 的時候是著重在第一點和第二點；聽起來容易，實際做下來發現難度也不低！
因為每個人的邏輯不一樣、所以同一個 controller 每個人的寫法也不同，要知道組員們寫得對還錯，首先就必須先「看懂」他在寫什麼，才有辦法進而「判斷」這樣的寫法是否正確。
以前總是覺得自己能寫出來就好，但如果未來加入其他團隊，code review 的技能也是不可獲缺的呀～
總結
其實一開始有點猶豫要不要參加 simple twitter 專案（有點懶惰覺得多人協作好麻煩），參加完之後的感想只有一個：
還好有參加!!!!!
很多坑和很多坎無法明說，必須實際參加過後才懂，很建議走到學期 3 的同學們如果有空真的要衝一波，不管最後的結果是什麼，都是很棒的經歷。
我們這組比較佛系（並沒有馬上要就業），所以完成指定功能就結束了，沒有再進入挑戰功能的環節；但整體來說花 2 週的時間衝刺做完指定功能還是挺有挑戰性的，也是一個很好的機會去重新複習到目前為止所學的前後端的技能。
感謝我的組員 — 任、Andy，希望大家都可以在這條路上繼續前進！