今天開始來聊聊如何現形需求生命週期的相關看法吧！一樣先來重拾前面提過的觀點，並藉此去展開。
流動流暢度講述的是流動的狀況，對應到開發的狀態；開發流程講述的流動的方式，對應到開發方式；而需求生命週期則是流向，對應到業務領域的理解與協作關係。
想像一個需求從誕生到結束是怎麼樣的流動？並不是所有需求都有機會被開發，很多時候優先順序一直被其他的新需求往下擠壓，最後就消失不見了。好不容易開始展開被開發的路程，可能會依序流向好幾個部門與業務單位，最後終被交付。
然而並不是所有人都能看見整個生命週期，通常是 Product Owner 相見能看見全貌，其他人通常只看得到其中一段，這就是需求生命週期的邊界。
軟體開發團隊通常只有交付段的視野，而這個視野的開闊程度，仍取決與 Product Owner 給予的資訊量，但是對 Product Owner 來說這個視野的真實程度則取決於團隊給予的回饋。 當共享的視野月是開闊，就越能看到更廣闊與可參考的狀態。
筆者會把需求生命週期在分成三個面向去探討：
你所參與的團隊，目前交付的視野通常聚焦在怎樣的層級？是追求價值的交付，還是任務的完成？是端到端的成果，還是只停留在某個開發階段的狀況？對於交付視野的不同，會讓團隊對於產品開發遇到狀況的應對也有不同。
比如說，就算是一個跨職能團隊，若只專注任務是否都完成，不一定能夠意識到就算任務都完成了，也有可能現在的方案沒辦法滿足使用者並帶來價值；只專注在某個開發階段的團隊，並不會去理會其他階段做得怎樣，反正自己的工作都做完了。
如何讓團隊能夠更在意價值的交付，而不是當純的作工？首先就是要讓團隊了解自己在交付什麼，理解自己的工作是能產生價值的，然後接著就是未來要交付什麼？這些預計交付的項目價值有何差異？要先交付哪一個？這就是所謂的交付的視野的面向。
從自己身處的路段開始 — 開發團隊
當身處在一個不太熟悉的地方時，通常人會先從哪裡開始探索？當然是自己身邊，對吧！總不可能連自己身邊都還沒熟悉，就先想辦法弄清楚十公里遠的狀況。
所以若要現形自己工作環境的開發流動，那我想也是從自己的日常工作開始。假如身處在分工非常明確的環境，至少先從個人本身業務做起；如果是一個以團隊為單位的工作方式，那就把團隊的本身的開發流動做起吧！
就像在前面有聊到，我會用團隊所接觸的生命週期區段作為邊界。在一開始就先以開發團隊最實際接觸的地方去檢視即可。我想這邊多數人應該都正在或曾經運行過 Scrum，那類似 Scrum board 的實踐就這樣一個好的開始。
我們先只從團隊視角作為邊界去看開發流動的產品生命週期就好，並先專注在一個週期的內要交付的事情，把這些事情的流動狀態給呈現出來。
這時候可以在團隊空間繪製一個實體的看板，或是使用 Jira 等專案管理工具都可以。
比 Sprint 更遠一點 —— 分隔線
隨著團隊能夠處理當個週期要交付的事情時，就可以讓團隊的視野看得更遠，從任務的完成到價值的交付。若是只讓團隊透過 Scrum Board、Task Board 去看當前 Sprint 的事務，相對是難以讓團隊培養這些概念的，對團隊來說那些資訊只是任務產生的背景知識。
這時候要讓團隊透過為什麼這周要交付這些，是怎麼排出來的，開始將視野看向價值層級的視野。讓團隊知道比起一個 Sprint 更遠一點的視野，還有哪些 PBI 要做，那些是即將要做的？那些還等待團隊去釐清？為什麼會這樣排序？團隊覺得重要的為什麼排序不高？
讓團隊逐漸參與在排序的過程中，透過自己在意的事情，與 Product Owner 進行討論，以價值為中心去交流彼此的看法，與團隊就會開始習慣這樣的討論方式。
可以在視覺化的 Product Backlog 搭配分隔線去示意。通常 Product Backlog 都是按照優先順序列表式的排序，既然如此可以用三條有順序性的分隔線去區隔：
這幾個分隔線是以不影響 Priority 的概念制定的，若是 Product Backlog 是按照優先順序去排序，那通常只要移動分隔線就好。就算某 PBI 還沒有 Refine 過，但他是 PO 排序後，預測能在這次 Sprint 完成的項目，那就放在第一條分隔線以內即可，而不是放在第一條分隔線與第二條分隔線之間，因為每一條分隔線的意義範圍都包含在更上面的分隔線內的範圍。
至於為何有第三條分隔線，那是因為隨著 Product Backlog 的增長，PBI 遲早會超過 PO 排序上符合性價比的數量，每張 PBI 都排序相對沒有意義，因為越後面的 Item 未來排序的變動性會越大，甚至可能根本排不上開發裡。所以通常在這部分 PO 只需聚焦在三個 Sprint 內的範疇去排序即可。
比 Sprint 再遠更多 —— Release Plan
但若是接下來要開發的是一個大型專案，需要有一個更好的風險管理，單單仰賴列表式的 Product Backlog 其實難以呈現更長遠的規劃，需要一個視覺化的方式能幫助團隊更得更遠。
筆者過去就有這樣的經驗，團隊接下來有一個粗估需要三個月的專案要去開發，但是這個專案對團隊來說是一個新的嘗試，對於能否在三個月內完成並沒有足夠的信心。單純用列表式的 Product Backlog 也已經無法給予團隊想要對齊與協商的程度，所以就將迭代週期與該週期預測可以完成的 PBI 貼上去，看是不是真的所有範疇都能完成。若是無法有足夠的信心去預測能夠完成，那就會開啟與 PO 的協商討論，是否能有更小可發布的版本，或是縮簡單個 PBI 的範疇，或是減少某些這版本階段相對非必要的功能。
這樣的一個方式，並非傳統專案管理的甘特圖或是壓死線的概念，更多是現形彼此對於未來需求流動的預期，並以此揭露認知落差，展開對話與協商。通常建議每次 Sprint Review 的尾聲時，與團隊重新對其這樣的一份計劃，並且當下調整重新對其認知。
筆者第一次嘗試這樣的實踐時，是與團隊在實體牆上透過便利貼時做出這樣的概念，透過移動紙卡，整個 Scrum Team 共同參與、討論，產出第一個版本。後來隨著疫情時代的到臨，才轉成透過數位化工具進行，採用數位化白板工具 Miro 去實作。
除了 Miro 外，任何數位化白板工具都能夠有相同功能的產出，比如說現在 Atlassian 的 Confluence 也有推出白板功能，雖然功能不及 Miro 完善，但也足以去弄出給能夠協助溝通與對齊的版本。
數位化白板的好處在於彈性極高，不用耗費太多學習成本就可以拉出一份可以使用的版本。當然，不代表這件事只能仰賴白板工具，若是數位化工具有提供能夠產出類似成效的功能，也是可以利用的。比如說 Azure Board 的 Delivery Plan 就能達到類似的效果。
有了 Release Plan，就可以讓團隊更得更遠。如果要在看得更遠，就建議搭配 Product Roadmap 的實踐，這部分就等明天聊到現形探索的考量再多談談吧。
iThome鐵人賽
看影片追技術