[A社筆記] 閒聊 Product Backlog

前言

Although implementing only parts of Scrum is possible, the result is not Scrum.

雖然實施部分的 Scrum 是可能的,但結果並不是 Scrum 《Scrum Guide》

之所以在文章一開頭就引述這段文字,是因為世界上太多 Scrum But 了;
而我下文所敘的則是 Not Scrum
未來有機會再深入討論兩者的差異,對我來說主要是心態上的差異。

我們透明、檢核、調試,我們擁抱改變,我們有所堅持,我們有理想但我們也務實。
好啦,說不定只有你自已。

在 A 社的導入的過程中,我開場白通常會說「這不是 Scurm」然後開始拿 Scurm 的東西說嘴。
至少對我來說,這比那些號稱「我們跑 Scrum」「But #^%!~…」要好得多,
與其讓你難以分辨斷句在哪,或是誤會怎麼 Scrum 這麼糞,不如讓我明確的告訴你「這不是 Scurm」。

背景

蠻小巧的團隊,小到我覺得也許不用任何「敏捷」
分為兩個組成 QA 部門與 RD 部門,遠端工作的 RD 主管兼職 PM
QA 團隊的主管除了目前這個團隊,也要兼者作其它團隊的測試,
此外還有一個大主管,在國外有時差,每周固定會與成員們開 3 次的會。
RD 團隊成為會有一個 Daily Sync 的會議,每天約 5~10 分鐘。
整個團隊有使用 Azure DevOps 的看板,但是 QA 只會用來開 Bug。
但不知道什麼時候 Bug 才會被修復。

問題

Azure DevOps BackLogs 太像文件

Azure DevOps 的 BackLogs 放著許多 Feature ,
依據不同的功能,再將每個 Sprint 的 User Story 放進去
這些 Feature 永遠不會被作完,隨著時間過去,
儘管完成了許多 User Story ,但是也會有新的 User Story 被加進去。
而作為文件,他的巢狀結構又不足以面對複雜的需求內容,
分散式存儲對於維護與修改上也是相同不便。

Bug 隨時蹦出

QA 的工作就是不斷的測試,一有發現問題就開立 Bug,
RD 有空就會去領來作,有時候也會有 RD 主管確認過後再分配給 RD
這導致不同面向的問題,RD 自領的情況可能會無序的作,
導致真正有價值的 Bug 無法第一時間被修正。
而如果每件事情都要 RD 主管確認後再進行動作,
RD 主管恐怕會變成瓶頸所在。

BackLogs 簡介

下面是我在向團隊介紹 Backlogs 後的筆記。

在 Azure DevOps 上會有 BackLogs 與 Sprints > Backlog。
恰巧與 Scurm 的 Product BackLogs 與 Sprints Backlog 可以一一對應。
如果以 XP 來說,可以投射到發佈計劃會議與迭代計劃會議中討論的「用戶故事清單」。
如果以 GTD 的方法論來說 BackLogs 可以當作收集一切事務的 Inbox,
而 Sprints > Backlog 可以視作專案裡面的工作項目。

總的來說,這些方法論的名詞故有所不同,但本質上卻是非常接近的事務。
我們總是有許多新的想法,但是沒有足夠的時間作所有的事。
所以我們必須補捉這些想法,放入 BackLogs 之中
補捉了之後,必須排序,這裡的概念有「重要且緊急」先作 ( 參考 Eisenhower Matrix ),
或是「價值高」的先作,或是有影響力的先作 ( 參考 Impact Mapping )。
GTD 的概念是 5 分鐘能完成的想法,立刻去作不然就丟到 BackLogs ( Inbox ) 之中,
我認為團隊不適合這樣作,畢竟 GTD 是針對個人的工作法。
團隊反而要刻意不作為,才能讓真正重要的事情浮現,而不是被一堆雜訊 DDos,
所有想法我的建議是「丟到 Backlogs 之中」,然後定期梳理吧。

理論上大部份事情會由模糊到清晰,這是個過程,之後才會進入到一個可以被執行的階段。
在 Scurm 之中,常用「遠光燈」作例子,我個人比較喜歡用「通勤」舉例。

留個問題給你,誰來衡量 ? 團隊 ? PO ? 客戶 ?

想像一下你要上班了,在家裡你對公司的方向與位置其實有個大概的想法,
要走過哪些路口,經過某個大樓,穿越了一座橋後你需要待轉,
再過幾個紅綠燈,看到速食店後就可以開始找車位了。
實際上路後,也許路上施工,你必需繞個路,或是運氣很好一路綠燈。
哦,不!! 你的車拋錨了,你必須改搭公車,而它的路線是……

有個大方向就是你的目標,路口、橋、大樓,就是你的每個迭代,
每次的煞車、轉彎或催油門就是再被細分下來的工作項目,
紅燈、拋錨、下雨天就是你真實上路後才會體驗到的事。
有個概念「Road Map」其實也是在說差不多的事。

回到 Product BackLogs 與 Sprints Backlog ,
我們也就是不斷的細化這些項目,一直到可執行然後被執行為止。

至於怎麼變快呢 ?
也許你要選一條最優路線,最短的距離最少的車流,沒有紅綠燈之類的,
也許你要有最棒的工具,最好的機車、定期保養之類的,
也許你要改變的開車習慣,不要危險駕駛、不任意切換車道等等…

透過的調整工作順序、找尋最佳工具輔助與保持正確心態,是我目前的答案。

(fin)

Please enable JavaScript to view the LikeCoin.