Dual Track Development / Agile(雙軌敏捷) Part 0 - 前言
【Dual Track Development / Agile(雙軌敏捷) Part 0 - 前言】
Dual Track Development / Agile(雙軌敏捷/開發)，這題材好像Google的中文資料蠻少的，英文的也不多，因緣際會下，最近剛好在公司應用上了。秉持著取之於社會，也回饋社會，就如果前幾篇一樣，來分享整個過程囉!因為老闆直接參與的關係，所以本來是要如同前幾篇Scrum和Kanban系列文一樣，應該是要花個半年慢慢發酵，這次只用個二個多月就成型了。當然，也可能是因為有特別挑選人員，經驗和成熟度都有一定水準以上，所以過程中有些步驟或基礎可能就會輕輕帶過，還是要視每個團隊成員去做型式和活動，不全是適用每個團隊。請大家看的時後自行斟酌使用，沒有對錯，只有嘗試後前進。
先介紹一下個人覺得還不錯的文章
設計與開發思維的雙軌並行
Dual Track Development is not Duel Track(中譯)
Dual-track agile
這張圖足以說明整個框架，但裡面有很多執行細節，後續文章再來寫。也有參考Less和Nexus。譬如說，拿Nexus的整合團隊的概念，受限於有限資源，Discovery Team我也當成虛擬團隊，一半人員full time一半人員視討論的主題再進入。
【兩邊都有迭代】
- Discovery - 是不斷透過討論+原型來驗證功能的價值，再決定要不要交付給開發團隊做。當然，這裡討論出來的不是詳細的規格，而是User Story(使用者故事)+Acceptance Criteria(驗收標準)+示意圖或流程圖，當作交付需求的文件。
- Development - 迭代MVP功能，可以專注在品質和架構上。
【週期】
- 一週或二週，視需求討論的狀況。如果是一週的，就合併下次Sprint再舉辦Review Retro.
【會議】
- Planning meeting - 需求探索會議、需求交付會議、開發團隊任務拆解會議
- Daily - 共有
- Review - 共有 + 利害關係人
- Retrospective - 各自、整合
- Refinement - 視需要
【人員】
- 視團隊.組織狀況，也許還有客服.營運.維運人員，還有地理位置的限制，負責的範圍可能會變。譬如說，QA人員，如果因為地理位置不得不在探索團隊，則會賦予除了功能測試之外，還需驗證交付的是否符合US.AC的描述。還有在需求討論的會議中，加入QA(User)的意見。
- 探索團隊，可視任務和主題再挑選必要且熟悉的人員進入討論，動態的虛擬團隊。
【需要的資源】
- 下午茶，因為需求討論很傷腦
- 足夠大的白板或塗鴉牆，隨即畫下流程.草圖.示意圖溝通
- 長條便利貼，寫下User Story . AC
- 使用者故事地圖
- 影響地圖
- mockup,wireframe工具
- A4紙
- 實體或電子看板
- 螢幕，隨時投影資訊討論
- 視訊軟體和鏡頭(遠端).zoom
- MoSCoW重要.優先序(觀念引入使用)
【可嘗試應用的情境】
- PO = BOSS時，固定出需求討論會議時間，讓決策和需求不會最後翻盤。
- 團隊因地理位置分散，開發人員一組，營運需求人員一組。
- 設計需求人員的經驗不足，或者產品過於複雜時，由Discovery Team代表PO。
- 產品有時間壓力下，讓開發較多時間專注在品質和避免太多來回修改。
- 產品需要更多市場資訊或更多創新，讓探索團隊專注在UX&市場提高精確度。
- 先熟悉原型迭代，因為付出的成本小且時間快容易得到近程勝利。
- 先建立 產品探索團隊，再由團隊成員另外建立敏捷團隊，擴散影響。
- 漸進敏捷，先為成員培養設計思維，才能在Scrum的Planning meeting中規劃出正確的事。
- 有限資源且人員還是偏執行思維(組織分工細，職能區分部門)，可以先為敏捷轉型鋪路，先有Discovery概念。
- 讓隕石變慧星
《 One Team 是最重要的原則，我們為同一個產品一起負責。 》
留言
張貼留言