目錄
一、背景
二、致謝
三、遇到的困難與克服方式
1. 給自己的心理建設
2. 小組事前準備工作
2.1 第一次會議
2.2 專案前的協作練習
2.3 工作分配
3. 開始實作的幾個問題
3.1 前後端討論資料與API
3.2 大家來找碴
四、未來一、背景
關於這篇文章，首先簡單介紹一下自己，我原本並非資訊相關背景，近期踏上了學習網頁開發的路。在過去半年多的時間裡，我參加了ALPHA Camp的課程。這篇文章是我完成這趟旅程的最後一份作業總結，期待這是我成為工程師的起點。在這篇心得中，主要討論了在「第一次協作」中遇到的問題和想法，並未涉及太多技術細節。由於篇幅限制，我會在以後的文章中逐一整理專案的前端技術內容。如果有參加ALPHA Camp課程的同學經過這裡，遇到任何問題，歡迎隨時在DC與我聯繫。對於準備踏入工程師之路的朋友，希望這篇文章能讓你對於「第一次協作專案」有更深入的了解。
關於專案，專案目標是完成一個簡化版的Twitter網站。課程提供了設計稿和user story等素材，並引入了Scrum流程。專案總時長約2週（包含小組準備工作），分為3個衝刺（Sprint）進行。小組需要根據課程提供的素材，自行製作系統分析文件、Acceptance criteria & DoD、Task list，以確定小組對於專案規格和分工的共識。小組模式有3人和4人兩種，3人小組是全端小組，由3名後端開發人員組成；4人小組則是前後端分離，由2名前端和2名後端開發人員組成。每個人會與自己在同一期的同學自主分配組隊，形成這兩種分組模式。
關於我們小組，是前後分離的4人隊伍，事先彼此不認識。在這個專案中，我負責前端任務，同時也有幸擔任隊伍的coordinator。後面我會說明我們所面臨的困難和工作情況，這裡首先要提到的是我們的起點：「4個剛剛結束課程的新人，彼此不認識，完全遠距溝通，沒有協作經驗（對於git不熟悉），前端只有少數幾次串接API的經驗。」在這種情況下，我們要在專案中加入Scrum的短期衝刺概念。因此，我認為在後續的實作規劃中，我們需要的不是一個完善的方案，因為一群新手的計劃必然會有許多缺陷。相反地，我們需要抓住整體方向和原則，然後在實際實作過程中動態調整細節。所以接下來的文章中，會看到有一些小段落特別用【反思】來補充說明。
二、致謝
在開始分享心得之前，我首先要感謝這次一起協作專案的三位夥伴：兩位後端成員tschiang23、Anna0118，以及前端成員quick123835。在這次的協作過程中，除了專案本身，我從觀察夥伴們的努力收穫了滿滿的感動。有些同學一邊全職工作，下班後開始做專案直到深夜；有些同學一邊照顧小孩，一邊參與會議；還有一些人和我一樣，不要命似的從白天起床開始弄到凌晨5點才睡。看到大家的努力，我更加認為自己沒有任何藉口。這已經不僅僅是寫程式，而是一種態度。非常開心能和大家一起努力完成，儘管辛苦，但在完成專案後，獲得了滿滿的成就感和感動。
三、遇到的困難與克服方式
1. 給自己的心理建設
要先談到自己的心理層面，這邊姑且稱這個過程的障礙為「與陌生人的協作困境」，首先必須有的認知是你/妳的組員有可能來自各方、不同年齡層、從一些自己完全沒有接觸過的領域而來的人，而ALPHA Camp的課程，雖然過程中有助教會批改作業，但全程是自主學習，也就是說每個人的學習狀況不同，是你/妳必須接受的現實。當專案有任何因為個人能力不足的情況發生的時候，要有隨時挺身承擔起問題的決心。除此之外，大家習慣的通訊軟體、筆記軟體、進度追蹤工具，或是日常能夠出勤的時間，都需要協調及安排，這些都與專案的程式無直接相關，但每個環節都有可能直接影響專案的成敗。
前面在致謝提到，有組員是一邊全職工作、一邊進行專案，身為coordinator第一個課題，不是專案進度，而是要考量「這是一位陌生人，你對於對方的毅力與能力一無所知，如果他/她因為半夜只剩一個人在做作業，遇到任何困難再加上白天工作的壓力，直接放棄了怎麼辦？整組放棄嗎？你很難因為這樣要求所有組員一起熬夜吧？」面對這個問題我選擇了一個比較笨的方法「白天我照常作息進行專案，凌晨我個人繼續和組員並肩作戰」。雖然過程中我並沒多做什麼事，就是上線掛在DC一邊做事，偶爾和組員說一些廢話，讓辛苦的同學在半夜也能感受團體，當下的我能想到的僅此而已。當然，這個方法是前面幾天，後來發現隊友非常可靠，我常常直接去睡覺😂
2. 小組事前準備工作
2.1 第一次會議：
我們小組第一次會議的時間比較早，算是提前了一個禮拜，內容沒有太實際的規劃，但這其實就和我想像的差不多，因為一群陌生人在線上的第一次對話，大家通常不太會提意見，要能有什麼具體方向開始實作，是相對比較困難的，所以這次會議有兩個重點「1.時間不能太長 (既然確定不會有重點，聊天別聊太久)、2.要大家都講過話」。由於距離專案開始還有一週，我在會議中拋出幾個相對簡單卻又需要預先準備的話題，如下：
(1) coding style
首先是coding style，其實在AC的課程中，只約略提到過關於JS有一個熱門的standard，至於實際上要怎麼設定Eslint配合Prettier則並未詳細說明。其實這是一個不錯的話題，除了表面上知道大家對於程式碼的整理習慣，還可以大概知道「有哪些同學在完成緊湊的課程的同時，還有餘力去研究其他套件」。
(2) GitHub操作練習
在AC的課程中，大家的GitHub使用次數應該是個位數 (假設自己沒另外研究)，因此提醒大家各自練習。
(3) 共筆方式
我個人筆記習慣用Notion，但Notion操作需要一些學習成本，大概能想像不是每個人能接受筆記軟體的使用，所以這件事情小組一定要事先討論 (必須知道我們接下來是處在一個短期衝刺的節奏，不能讓組員分配太多時間去研究專案主體以外的東西)。
【反思】
不是每個人習慣Notion，而且多人協作有額度限制，但又想以Notion為主要workspace，作為小組繳交文件給AC的窗口。因此就讓組員各自以習慣的google試算表或其他方式整理筆記，在把分類好的筆記連結貼到Notion的workspace做連結的統整。(4) 專案大方向討論
針對專案大方向的討論，這個過程中注意到一個小細節，後端同學原先是看著user story規劃後端的東西。但是當小組一起看著設計稿討論時，發現前後端同時在線，討論畫面的互動性與資料變化是一個不錯的方式 (雖說合作模式是前後分離，但是不要前後各自去猜想畫面會需要什麼資料)。我覺得這算是前後分離小組，開始協作解鎖的第一個盲點 (沒人告訴你要這樣做，但事情很自然就會朝這個方向發展)。
(5) 開啟小組DC群
我覺得這是一個不錯的方式，原因有兩個：首先，line的使用雖然更即時，但是我個人偏好「工作與生活分離的概念」，雖然我們也有line群，但更希望DC群變成工作主要溝通的管道，所以會在line群發出的通知，通常只有重要的行程提醒。其次，在AC上課的同學大多有使用DC，所以預設選擇DC可以省去大家適應新軟體的時間。
2.2 專案前的協作練習：
在開賽之後，除了組員達到共識分頭開始準備前後端系統文件，我們小組還提前做了一次協作練習 (底下是紀念當時練習的截圖)。我覺得這特別重要，在看完指令說明與實際操作有蠻大的差異。即便我們已經做過事前練習，在實作過程中仍遇到過幾次操作上的困難，幸運的是，大家都非常耐心地一起解決了這些問題，再次感謝大家的努力。
2.3 工作分配：
由於我主要負責前端，對於後端工作理解有限，所以關於後端的分配，我能做到的只是在實作的過程中，一邊關注他們的任務清單變化，並未干涉他們的任務分工。而前端的工作分配，我們是採用React框架進行專案，主要以component為單位進行分工。
在進行分工時，需要注意一些細節。每個basic element會應用的場景不同，需要在分配的同時，就開始思考後續要將各個元件開始組成page層的任務分配。讓我先簡單描述一下我們的元件拆分概念，這邊我將component分成大、中、小，這樣可以逐步由小型元件組合成中型和大型元件。其中大型元件描述的是網頁前台及後台的主要內容 (例如三欄式layout中，除了左右兩側的nav和sidebar以外的中間區域)，而中型元件則是直覺的將大型元件拆分成兩段或三段。
在實作時，我們會按照順序分別從小型、中型到大型元件來完成。然而，由於元件適用於不同的頁面，所以在分配元件時，我們會盡量同時考慮之後的各個page層工作由誰來完成，而元件的分配則基於「這個元件屬於哪個頁面」為原則。
【反思】
因為這是初次協作，加上前端也是剛剛學習React，可以預期的是會有很多重複工作的部分，但是我覺得沒關係，重工也是學習，你會發現同樣是前端，在看待同樣一個小元件時，可以有完全不同的處理方式。當然，大概能想像實務上需要儘量避免重工問題，提升工作效率，但這些可能需要的是一次次的專案經驗磨練，而不是兩個新手在第一次一起工作就完美精準達到分工。所以在整個實作過程中，經常需要互相照應，誰先完成一個段落，可以休息一下同時觀看組員現在卡在哪個瓶頸，也許他在跟你說明瓶頸的過程中，自然的就把問題給想通了。因此即時溝通非常重要，即便是各做各的事，隨時在線互相說明問題是整個專案順利進行的關鍵。3. 開始實作的幾個問題
3.1 前後端討論資料與API：
這個部分是前後分離小組需要解鎖的主要技能，我們小組前後大概經歷3次「所有頁面資料討論」。一開始由於前端這邊在課程中其實沒有太多串接經驗，所以如同開頭提到的想法「抓準大方向/原則，然後所有細節在實作過程中動態調整」。前後端在一開始根據設計稿討論的時候，先一起判斷每個畫面需要哪些資料，不需要鉅細靡遺的文件紀錄，在有個概念之後，馬上開始分頭進行，再回頭討論就會知道問題。
果然在專案開始實作約3–4天的時間後，大家開始分別提出對於一些資料的想法及修正，緊接著的小組討論，不需要太長的時間，就能有一個比較具體的規劃。這個時候大家一起畫一張大圖 (下面為示意圖，完整圖太大放不進來)，以前端page層為單位，先判斷哪個頁面會需要哪些資料及路由，都標示出來。在這之後，前後端對於彼此的工作、專案架構會有更具體的認識，在開發的效率上也會明顯高於前面幾天。
【反思】
在事後看來，的確有可能在專案初期就把前端路由、資料流、後端api…等等都講清楚才開始動工，但這是已經建立在大家都有經驗的前提。而這次的教案設計，不只是第一次協作，而且沒有設計師讓你問問題，也就是說前後端對於專案需求的理解，全憑設計稿和user story做猜測。所以我的作法，是在第一次討論設計稿的時候，先口頭快速的逐一描述每個頁面需要哪些資料、每個按鈕串接的api可能會需要什麼功能，等前後端做了一個階段以後(前面提到約3–4天)，回頭討論馬上就知道問題，這時候後端組員，很自然的就主動提出了需要與前端一起羅列每個頁面及對應路由的要求。當然，我相信如果再一次，可能在一開始憑空跟大家討論每個畫面需要什麼之後，大家對於整件事情就會有具體的認識，並且也不需要畫圖，甚至可能一個簡單的試算表就能直接把任務釐清。
3.2 大家來找碴：
在專案動工約 1 週的時間以後，前端預先將目前的進度部署至GitHub，並且邀請組員們進行「大家來找碴」。可以預期的是，第一次協作專案，非常考驗切版基礎，所以要大家開始挑戰現有的作品，一邊做一邊隨手修正細節。除此之外，提前部屬讓後端同學對於當前專案的進度心理有數，也能一邊檢查一些細節 (例如字數上下限制)。下圖是紀念當時大家來找碴的成果，雖然看似誇張，但實際修正這些bug並未花費前端太多的時間 (約半個小時)，因為剛剛做完這個部分記憶猶新，趁這個時候把這些細節都調整完，同時可以一邊跟後端討論接下來要串接哪些資料。
【反思】
雖然在這件事情上，達到預期效果，不過事後反思整個過程，其實前端在dummy data就可以設計極端案例，在切版的過程直接就避免這些問題，不過這都是經驗😅。而且即便一開始透過dummy data避免一些問題，但難免思考會有盲點，我想再次經由大家用力的測試還是必須的。
四、未來
回顧這段時間，我發現很多當時困住的瓶頸，在和組員討論的過程中迎刃而解，有時甚至在描述問題的過程中自己就找到答案。這給了我一些啟發，溝通和願意傾聽是協作的關鍵，而這些都需要耐心。隨著一次次小組討論的進行，組員們一邊熟悉各自負責的內容，對專案的共識也更多，效率就會逐漸提升。我想，文章看到這裡，後端的夥伴們可能會意識到，在過程中有那麼幾天可能會想：「怎麼昨天聽前端說才做幾個小元件而已，進度超慢，今天突然就部署了，而且有畫面出來了？」
在這個專案中，學到了很多技巧，但其中核心的想法就是一個「不要紙上談兵」。整個執行過程中，避免需要鉅細靡遺的規劃才開始做事，不過這並不代表我們沒有計劃，而是在確定好整體方向後，抓準目標，先做再說。我想自己往後不管是專案協作或是個人學習，也會持續保有這份習慣。
