Jira同Bitbucket都係我喺第一間公司Halcyon接觸到嘅。個team靠Jira入面嘅睇板運作,倉庫就交畀Bitbucket管理。不過我只係喺嗰塊睇板上做嘢嘅人,並唔係搭建佢嘅人。Workflow、權限、自動化規則,早喺我加入之前就已經有人設定好咗。我只不過係喺人哋搭好嘅系統入面做嘢。
Bitbucket後尾都跟埋我入大學。幾年之後做畢業設計嗰陣,我哋team用佢嚟管理倉庫,直至撞到成員數量嘅上限。Bitbucket對可以加幾多人有限制,一到咗嗰個上限,基本上冇乜其他選擇,我哋將所有嘢都搬咗去GitHub,之後就一直留喺嗰邊。
自從嗰陣開始,我日常用嘅工具徹底變咗樣。喺而家做緊嘅Cody,team用嘅係Asana,但唔係agile team成日講嗰種用法。冇故事點,冇估算儀式,有嘅淨係時間線:一個功能大概要用幾多個鐘,再加埋追蹤邊個負責邊樣、做咗未。Linear同n8n佔咗我日常實際接觸嘅其餘部分,JetBrains嗰套就靠TeamCity。
所以最近,幾乎純粹出於好奇心重新打開Jira嗰陣,佢已經由2022年或者2023年左右開始就一直冇畀人掂過。而我發現嘅,係趁我冇留意嘅呢幾年,佢其實早就成熟咗好多。
自動化嗰部分理解起嚟好輕鬆。工單一建立就自動指派畀某個人,設一條喺workflow狀態變化嗰陣觸發嘅規則,呢啲都冇令我覺得陌生。撕開Atlassian嗰層包裝,底下其實就係我每日喺n8n或者Zapier入面用嗰套「當X發生嗰陣,做Y」嘅邏輯。Jira仲喺自動化設定深處收埋咗一個Incoming Webhook trigger,可以接收嚟自任何地方嘅POST request,包括Stripe,然後用一個叫{{webhookData}}嘅smart value將payload讀出嚟。如果你已經識得點樣將Stripe嘅webhook接入n8n,再轉去Discord或者Telegram,咁其實你已經搞懂咗Jira automation九成嘅嘢,無非係換咗個名嘅目的地node啫。
真正令我停低嚟認真諗嘅係故事點。呢個詞我隱約知道好多年,但從來冇真正需要用過佢,因為我自己嘅經歷入面根本用唔著呢種機制。查完之後先發現,佢根本唔係項目層面嘅設定,而係掛喺每個issue上面嘅一個欄位,通常喺backlog梳理或者衝刺規劃階段填上,即係喺正式開始做嘢之前。佢代表嘅係相對嘅工作量同不確定性,而唔係實際嘅鐘數,所以大部分team揀嘅係斐波那契式嘅數字,好似1、2、3、5、8、13咁,而唔係線性嘅刻度。
呢個又帶出一個更難嘅問題:你點知一件嘢真係做完咗?Jira唔會幫你答呢個問題。將張卡拖入Done欄,淨係將一個status欄位反轉咗,並唔會驗證任何實際發生嘅嘢。如果你希望呢種驗證真正有意義,要麼喺Done之前加一個review或者QA嘅column,等做嗰件事嘅人以外嘅其他人負責將佢移過去;要麼就設定workflow validator,喺未滿足某啲條件之前擋住狀態轉換。如果有人將一件其實仲未做完嘅嘢標成咗Done,亦都冇乜特別嘅撤銷機制,你就好似處理其他狀態變化一樣,將佢拖返In Progress就得。
一開始我完全搞錯嘅,係Groups同Teams嘅關係。我以為Groups地位高過Teams,有一種層級關係,畢竟Groups係負責分配權限嗰個。呢個諗法聽落幾合理,結果卻完全錯晒。佢哋根本唔係嵌套關係,而係兩套並行運作嘅獨立系統。Groups由管理員管理,控制緊真正嘅存取權限,好似permission scheme、安全等級、通知方案。Teams可以由任何人自由建立,主要係令合作變得可見。而家Teams完全唔涉及權限,你亦都冇辦法將一個Group直接塞入某個Team度。
返轉頭諗吓點解會搞錯,其實同Jira本身複唔複雜冇太大關係。我真正用過呢啲工具嘅場合,要麼係喺Halcyon,做人哋已經搭好嘅系統入面嘅一個成員,要麼就係完全一個人。個人項目,一個人自己搞,permission scheme嗰邊從來冇第二個人,可以喺我理解錯嗰陣即刻提醒我。關於Groups、Teams、permission scheme呢啲嘢,你可以讀幾多都得,但只要冇真正為一個會即刻發現問題嘅隊友配置過權限,呢啲知識就永遠停留喺理論層面。呢個大概先係真正嘅原因:一個我技術上「用過」嘅工具,卻喺淨係涉及其他人先至真正重要嗰部分,一直令我拿捏唔準。