Dual Track Development / Agile(雙軌敏捷) Part 5 - Planning meeting
【Dual Track Development / Agile(雙軌敏捷) Part 5 - Planning meeting】
在上一篇準備好下一個Sprint所需要的相關資料(User Story,Acceptance Criteria,圖)，並且輸入到自己的專案管理系統，就可以開始Planning meeting囉!
由於我們雙軌的二個團隊一個在台灣(需求探索)，一個在大陸(產品發行)，非常倚賴電子專案系統(Azure DevOps)，有些事前準備要先做，像是把User Story的順序做個排序(讓情境是完整或連續的)，降低當下遠端溝通成本。否則，可能在會議當中又再次過度發散討論或者聽不太懂需求描述，更可怕的是聽錯意思，導致最後產出歪很多的產品功能。
【使用者故事、驗收標準】
經驗來說，User Story是比較開放性的需求描述，非常適合用來說明需求的情境和發想需要的功能。但在雙軌敏捷的話，對於開發團隊來說，就不是主要文件。
我們會盡量以"圖"為主，示意圖、流程圖、草圖、分鏡圖、結構圖、Mockup、影片、競品....等等，當作主要說明文件，能用圖就用圖說明。
- User Story在過程中用情境帶入(用圖說故事)
- AC則在關鍵點時說明
團隊越是有文化差異，就盡量用圖為主，文字為輔。
以登入驗證來舉例說明，
- 出張示意圖把可以登入的方式標示出來(FB、LINE、官方帳號的按鈕)
- 看圖說故事，三顆按鈕的故事
- 分別說明FB、LIN、官方登入的AC
- 同樣的，如果過於複雜，最好也用流程圖來說明AC
【規格書】
也許大家會懷疑，這不就是規格書?不就是瀑布嗎?
因為需求探索已經把開發團隊要列的AC列完了，他們只要照著做就好。
雙軌敏捷如同之前的前言所說，視團隊和專案的狀況調整交付的精確度，如果開發團隊都有設計的思維、專案上線壓力不大、需求探索團隊的專業組成能產出較高較正確的價值，那也許由需求探索團隊把AC寫清楚會較合適。
不過呢，真的在用AC描述的時候，其實正常狀況下，應該也寫不出像規格書那樣細。反之，當發現交付過程中，連一點討論的聲音都沒有，可能就表示你的User Story或AC格式、寫法錯了，應該都還有2-3成的討論、想像的空間。
那........規格書哪裡去了?
規格書會在Sprint結束後整理完成，由產品開發團隊成員、企劃、QA等人員，在Sprint Review後，把這次衝刺所做的Task整理成規格書文件。當然，也可以邊做邊寫，持續補上與目前功能相符的規格說明文件，而非一開始產品還沒做出來，就精確寫下"預測"的功能描述。
敏捷式的開發裡，文件隨專案屬性，適量的產出。大原則，先夠用就好。
【如何做Planning meeting?】
雙軌敏捷+遠端的Planning meeting該如何做呢?
Planning meeting 會分成上午場和下午場(視團隊狀況調整)。
●上午場1000-1200
首先，雙方一起開Planning meeting需求 規劃/交付 會議，以電子系統搭配通訊軟體(Zoom)來溝通，然後使用桌面共享功能，以圖說故事。以二個星期的衝刺期，通常二個小時是夠的，如果超過，可能表示太多會造成開發團隊(七人)做不完。
●下午場1700-1800
早上開完會後，下午的時間交還給開發團隊，讓他們消化吸收並拆解這次要做的Task。對於早上交付的需求，如果有任何疑慮或問題的話，會在1700再一次開個會議來釐清。或者隨時線下保持溝通，就不需特別定這會議。建議初期要保留這固定時間。
【小細節】
●開發團隊.邊交付邊用便利貼寫下任務或關鍵訊息
●會前先行閱讀、、理解
●需求探索團隊-指派主持人與紀錄者
●PO在場，當下確定遺漏或沒想到的點
●每個User Story的停頓點時間長短，讓遠端的開發團隊思考、討論
●User Story順序
●預計交付的範圍、量
●必要、非必要的參與人員
●視訊設備和網路品質
【結論】
需求交付的拿捏是一大考驗，要先替所有團隊做好心理準備，會失敗個幾次才會順暢，更重要的是，失敗後有沒有看出問題，找出解決的方案來進步。這沒有絕對正確的答案，雖然目前是雙軌，當然，也可以朝單軌為目標，也就是未來讓開發團隊來進行需求探索。而這雙軌的過程則是培養、訓練產品思維的漸近好過程。
一開始就建立心態，把失敗納入計劃的一部份，會更能持續改善。
留言
張貼留言