我們這組是全端開發 Tweets 專案,謝謝組員 Allen / Elliot 兩位夥伴一起完成這次專案。
我主要負責功能,因為功能彼此交織,有點難細分就是誰負責哪些功能。
不過在此附上專案成果:
LiveDemo 與 GitHub 連結
事情沒有那麼簡單
首先,這是第一次團體協作,有共有三個組員,我們素未謀面,要達到牢不可破的默契,是有點難度,中間有摩擦、有衝突、有放下,我想這才是團體專案最重要的功課。這篇文章會分成三個部分,首先,有幾件事情必須在正式實作前完成,第二,實作過程,與最後,未來如何做得更好。
Definition of Done (DoD)
首先,我們透過 User Story 制定出 Definition of Done(DOD)
大家一定要對於目標有一定共識,不然開發的過程會增加許多溝通成本,那制定後,一定就沒有問題嗎?也不是這樣說,有時候計劃會趕不上變化,後面再多做說明。
User Flowchart
透過教案提供的 UI 設計圖,我們需要清楚知道,網站的流程會如何進行,按下 Button 後會轉跳什麼頁面,點擊畫面的連結會轉跳到什麼頁面 …,我覺得在繪製 User Flowchart 的過程可以更快的瞭解專案的全貌,視覺得呈現專案的功能與需求。
ERD
ERD 幫助視覺化呈現 Model 關聯性,對於後續建立 Model 關聯性很有幫助。
進入開發階段
進入開發階段,紀錄幾個我比較印象深刻的經驗:
快馬加鞭
當完成上述的前置作業,只剩一個多禮拜的開發時間。由於有 sprint check-in 的時間壓力,因此,除了加速開發速度,沒有別的。但加速開發速度,勢必有些畫面細節無法兼顧,謝謝 Allen 一肩扛起畫面的調整。
Code Convention
每個人都有不同的風格,可以看到不同的寫法,但是以整個專案來說,會有點難以維護。但是因為時間有限,要在短時間擬定出一致的 Coding Style 會有難度。也只能邊做邊改,盡量維持一致的 Code Convention。
隨時更新進度
每日的 Standup meeting 讓夥伴掌握彼此進度,在透過 Trello 管理 tickets,哪些事情還沒做,哪些事情需要先做…
昨天做了哪些事 | 今天預計要完成的事 | 有沒有遇到困難
但這個過程中有發現,有時候遇到問題不一定會及時提出,會先嘗試自己解決,但未必能解決。最好的辦法還是設定停損點,花點時間釐清問題,假如仍然不行,就必須趕快丟出來詢問老師或同學。
找蟲
寫程式有趣的是自己覺得沒有問題,但畫面有問題,來吧,來找蟲吧~
到後期對於整個專案更了解,所以找蟲的時間可以省下不少,而且很有成就感,但反觀專案前期,在茫茫程式碼裡找蟲,結果通常是找到自己。
反思
其實專案進行的過程中已經有一些摩擦,有些人可能會怕,想說會吵架,好可怕。但要銘記一件事在心:目標導向為主!
Git 情境與指令要熟
Git 協作過程一定會碰到衝突,解完衝突,功能壞了,畫面歪了。或是離主幹太遠,回不來…太多情境都是之前一個人沒辦法實驗的。等到遇到又有點不知所措,只好趕快 google 指令。
確認認知
有時候雖然有明確的目標(DOD),但彼此的認知可能會不一樣,可能有些人會對於畫面比較要求,有些人可能對於功能的完整性更在乎。到最後一定要有個取捨,取捨已可以成功交出專案為目標。剩下的,針鋒相對就沒有那麼重要。因此,有衝突很正常,但最重要的是成功交付專案。因此誰在乎畫面,或誰在乎功能,就不是問題了。
這次團體專案協作,技術層面不需要太擔心,因為有不熟的技術,趕快回頭看教案內容,看看網路上有沒有相關的 simple code 參考,要是卡關太久,馬上詢問老問。
最後,相信所有的事,當下看起來很難,事過境遷後,就換下一關,然後會發現自己升等了,轉換到不同層級關卡的循環。