黑先生

【Dual Track Development / Agile(雙軌敏捷) Part 6 - Review meeting】 上一篇 Planning meeting 後，探索團隊和開發團隊就回到各自的衝刺節奏，由共同的Daily來確保交付項目，有沒有什麼意外需要即時調整。畢竟是遠端協作，當初交付的需求可能不盡完整，多少會有遺漏掉的。 【會議前】 Review也是共同會議，除了所有成員以外，還要包含產品的利害關係人也要參與，除了解進度外，更重要的是回饋與調整。所以不要忘記在Review前一天，以Mail或其它方式通知相關人到場，附上此次的Review內容和順序資訊，有助於加速理解目前產品狀況。 為了讓演示過程順暢，會請開發團隊事前檢視確認一下目前的版本與環境，把所需要的畫面、帳號、服務都先開啟。更進一步，可以安排演示的順序。因為有些User Story接著演會具有連貫性，對於利害關係人來說是更容易進入狀況理解。 遠端演示有些小細節做了會更好，譬如說， - 投影共享操作手機畫面時，開啟點擊觸控的回應功能，讓遠端的人知道剛剛的操作是點了哪個地方才切換畫面。 - 演示人員的講話速度慢些和停頓點多一些，讓遠端的利害關係人容易理解。 - 麥克風是共用放在桌子中間就可聽清楚，比需要靠近拿來拿去更好溝通。 - 座位的安排 【會議中】 Review過程中，探索團隊會指定主持人與紀錄者，主持人先做開場，然後由開發團隊操作、展示。利害關係人的討論與意見回饋，當下會做適當但不深入的討論，最後摘要記錄下來，於會後由探索團隊深度討論是否要做調整。最後的決定權還是以探索團隊為主。 初期會議裡，如果有個像教練或SM的角色會更好。會議過程中，SM以客觀的角度去發現需要改進的地方，帶進雙方的Retro.中，會加快進步、改善的速度。 【會議後】 Review會議後，探索團隊和開發團隊有各自的Retro.，其中，探索團隊的Retro.會先行討論剛剛Review中紀錄的回饋，確定是否進一步討論或取捨，納入到待辦清單中。回饋討論完後才進入Retro.。 【大致上的流程】 ●事前通知，附上Review內容與此次Sprint燃燼圖 ●演示內容的流程安排 ●測試機與相關展示設備的準備(Zoom、手機投影、視訊...

【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成...

【Dual Track Development / Agile(雙軌敏捷) Part 4 - 需求探索衝刺】 雙軌敏捷中，負責需求探索的團隊也如同Scrum一樣，有著固定的週期和節奏，也和開發團隊有著共同的會議(Review.Retro)，負責同一個產品目標。 需求探索團隊可能不是一個專職團隊，是一個約七人的虛擬團隊，來自各方的代表，人員角色也必須多元(PO.營運.RD.企劃.QA.UI/UX)，參與的人員大多是固定的，但會依不同主題找必要人員，譬如說客服.財務人員。 需求探索團隊主要職責是 「運用設計思考的思維創造或發現"對的事"(Build the right things)」 ，通常需要時間來發酵，如果能善用引導或方法(思考框架)可以提高效率。 雖然需求是由探索團隊討論&確定下來，很重要的一點是，最後交付出去的絕對不是封閉式規格書，而是開放式的使用者故事(User Story)、驗收標準(AC)、示意圖or流程圖，會跟開發團隊做Planning meeting，最後還是要交由做事的人決定方法。 需求探索五步驟 ●發散思考 有很多方式可以做，如果需要搶點時間的話，先前可以準備好相關競品資料、最新趨勢參考，或是先設計好一版的原型後，大家再來一起發想討論。 當然，視主題而定，如果遇到殺手級的功能，也許可以安排一下Design Sprint來決定。 到後期熟悉時候，大多時候帶著Design Thinking的思維來寫下"使用者故事"就足以解決了。 ●收斂成 示意圖/流程圖 發散思考討論會有很多的建議、想法，所以，最好在有足夠大的白板旁邊進行，這樣就可以隨時把大家腦中畫面視覺化。很多時候似乎嘴巴講的都對，實際畫出來後卻問號連連，怎完全不一樣，尤其是面對複雜流程、功能更明顯。 流程圖可以用畫的，也可以事前準備分鏡圖，讓大家排出最有共識的流程。 ●寫上US.AC 經過前二步驟，其實大家腦中已經累積大量資訊，要趁熱把腦中資訊和眼前畫面連結。 有二個方式，有不同的效果 - 邊畫圖的過程邊寫上US.AC - 事後補上 事後補上是讓每個人對剛剛所有資訊進行轉換，以US.AC的方式記錄，重疊也沒關係，有時會出現剛剛沒想到的想法，36...

【Dual Track Development / Agile(雙軌敏捷) Part 3 - 需求探索的實驗與衝刺_開場】 有了 上一篇 的知識和心態工作坊準備後，就要透過不斷的行動和嘗試，不斷的修正和調整，找出最符合目前團隊.組織.現況的最佳做法。 【準備】 這裡沒有特別技巧， 準備好面對失敗的態度 是唯一方式。說起來有點簡單也有點困難，因為過去的大家，通常都不太習慣失敗，很容易卡住然後進入檢討氛圍，這大概就是之前電子業PM傳承下來的習慣，已不太適用於VUCA的軟體業。 我們可以做的就是打預防針，利用 Tuckman Man的團隊發展模型 來預告，接下來我們會共同面對一段很糟的時期， 在事情變好之前一定會先變差 ，而有沒有能力面對後回饋修正，就是敏捷所需要的能力，也是考驗。 準備好之後，還有個重要的關鍵點，如果可以的話， 初期密集的安排 不斷的嘗試和實驗，讓改變在短期間發生，產生近程小勝利。譬如說，連續三天下午產品探索團隊都在不斷的討論.探索，找出屬於這專案最好的方式來交付。 【 可以這麼做 】 如果教練只有一份心力的話，在 Dual Track Development / Agile(雙軌敏捷) 中，先專注進行產品探索讓需求正確為主，再花心力到開發團隊，也就是" 先做對的事，再來把事情做對"。 只要交付的需求能讓開發團隊覺得有價值的話，他們可先用之前的開發方式也無妨，漸近變革會是個低風險的選擇。 進入實驗與衝刺開始前，補充一些更細節的方法與工具使用，過程中做引導，且適時說明背後的原則和精神。所以，開場準備簡報內容，裡面放入這三天可能會用到的資訊，讓大家有所想像、依據和步驟，讓改變更容易(香蕉法則)。 香蕉之所以比柳橙更受歡迎，只是因為香蕉更容易剝皮。 【 開始 】 開場大致內容 ●講個小故事切入產品探索， 星巴客和麥當勞為何排隊方式一個是衡的，一個是直的 ? ●未來的專案模式 (未來的開發模式介紹) (需求探索著重的地方) ●影響地圖 ●使用者故事地圖 (接下來會使用到的技巧) ●User Story使用者故事 ●Acceptance Criteria驗收標準 ●DoD ●實例化需求 ●迭代週期 【 結論 】...

【Dual Track Development / Agile(雙軌敏捷) Part 2 - 起航.建立團隊迫切感工作坊】 藉由 上一篇 的訪談ORID，獲得目前專案的O&R，進行分析後，為這專案問題重新發現.詮釋(I)問題根源，把D的想法設計在工作坊內容裡面。 之後邀請相關人參與會議，讓大家都認同與理解目前現狀的處境，建立團隊迫切感，給予未來導入的相關活動與技巧，等團隊成員就續後再出發，這就是起航的最主要目的。 所以，這個工作坊的內容完全取決於訪談後的資訊，還有自己分析後的結果。如果方向設定錯誤，大家會對內容無感，往後的推動力道可能會變小，甚至變成阻力。 在這步驟，建議多花點時間思考或請教其它有經驗的教練，或者再回頭翻點相關的書籍.文章，都有助於自己校正方向。反之，如果方向.內容對的話，投資這場的工作坊時間成本會翻倍，未來可是會讓事情發展一帆風順。 提供這次專案的工作坊大致的內容參考囉!(視各團隊狀況，會有不一樣的工作方型式.內容)： 【全貌】 讓團隊了解敏捷概念.全貌，如果可以的話，映射到目前專案上的盲點。大家有想像空間後，也能降低對未來不安的感覺。 ( Ruddy Lee ) 【改變】 寫下一件想  改變/解決 的事/問題。具名，寫完後隨機交換。 這點很重要，要讓別人的事變成自己的事，最後要幫對方寫下自己認為的解決方案。 【容易消化的詮釋】 敏捷的層次，這是看目前專案.組織或公司所在意的點是什麼，再去把敏捷做上對映，所以，不見得一定是這樣表達，視當時專案的背景資訊。 【遊戲體驗】 通常專案上已經卡住了，頭腦需要抽離一下，安排體驗活動，藉由活動反思.聯結到目前狀態。這專案我選的是 - 棉花糖挑戰 。同樣的，也是視團隊狀況會有不同的體驗活動。 【授能 - ORID】 大多團隊都用錯誤的方法在溝通，提供適當的溝通技巧，有助於改善未來彼此合作關係。 當然，會特別在ORID帶個活動，讓大家能更深入使用，也把過去的痛點引出來。 請大家分享過去專案的經驗，其它人則聽出他的O&R。 然後再用HMW請大家重新詮釋問題點 而D不用急著給答案。 這裡的HMW會在後續導入過程中，持續追蹤改善。 【Agile介紹】 介...

【Dual Track Development / Agile(雙軌敏捷) Part 1 - 準備.資訊蒐集&整理】 進入雙軌之前，首先要做的是，蒐集大量的目前狀況資訊，才能決定用哪種型式的變革，在過程中檢視(inspection)和調整(adaptation)方向。但對於引進變革者(或SM)，在所有不確定都很高的情況下，一定要先有方向，才不會自我迷路.迷失。 個人認為初期的 "方向" > "目標" ，目標在過程中慢慢清晰或者不斷修正，也有可能臨時需要"階段目標"來輔佐。如同 "不確定性圓錐"或者精實原則中"延遲決策"，如果一開始並不需要強調目標的話，不仿有個方向後就行動出發囉! 情境說明： 這專案先前已經用自己的方式跑了半年了，不過後來成效不太讓BOSS滿意，所以決定重新來過，以敏捷的方式。這是老闆的期望....但很有可能老闆其實...不太曉得敏捷是什麼，只是覺得"想改變"而已。 所以，要做的事情有幾項 了解原因 -  心情 和 事情 目前進度狀態與為何不滿意的點 每個職能和團隊做各別訪談。一定要是各別的，這樣才能聽到比較真實的聲音。譬如說，誰誰誰....，大多數專案發生狀況，通常是各團隊都是先指著誰...... (邊訪談邊紀錄) 重新詮釋 各職能.組別訪談後，要把所有狀況做個整合，重新詮釋。好好靜下心來發現整個系統的問題盲點所在，用系統思考去畫或者關係流程圖做關聯是個不錯的方法。 找到痛點 設計執行 解決方案的設計 - 利用工作坊來鋪陳 進入實際變革 有覺得很熟悉嗎??沒錯，就是ORID焦點討論法。 訪談中利用ORID來了解整個狀況。我個人是利用O&R來做訪談蒐集資料而已，並沒有在訪談中做I&D，因為主要目的是獲得資訊不是各別解決，且問題點可能不是單一面向而是整個團隊，單一聽到的通常只是症狀而已，當下做I&D的話可能會給出症狀解而非根本解。所以，I&D是留給自己解讀分析用的。 有了O&R後，試著畫出你的解決方案草圖，而這就是你往後的" 方向 "。既然稱做它方案草圖就表示不要把這當作目標，讓自...

【Dual Track Development / Agile(雙軌敏捷) Part 0 - 前言】 Dual Track Development / Agile(雙軌敏捷/開發)，這題材好像Google的中文資料蠻少的，英文的也不多，因緣際會下，最近剛好在公司應用上了。秉持著取之於社會，也回饋社會，就如果前幾篇一樣，來分享整個過程囉! 因為老闆直接參與的關係，所以本來是要如同前幾篇 Scrum 和 Kanban 系列文一樣，應該是要花個半年慢慢發酵，這次只用個二個多月就成型了。當然，也可能是因為有特別挑選人員，經驗和成熟度都有一定水準以上，所以過程中有些步驟或基礎可能就會輕輕帶過，還是要視每個團隊成員去做型式和活動，不全是適用每個團隊。請大家看的時後自行斟酌使用，沒有對錯，只有嘗試後前進。 先介紹一下個人覺得還不錯的文章 設計與開發思維的雙軌並行 Dual Track Development is not Duel Track ( 中譯 ) Dual-track agile What Dual Track Agile is, and how it's done successfully How to set up Dual-Track Scrum in Jira 這張圖足以說明整個框架，但裡面有很多執行細節，後續文章再來寫。也有參考Less和Nexus。譬如說，拿Nexus的整合團隊的概念，受限於有限資源，Discovery Team我也當成虛擬團隊，一半人員full time一半人員視討論的主題再進入。 【兩邊都有迭代】 Discovery - 是不斷透過討論+原型來驗證功能的價值，再決定要不要交付給開發團隊做。當然，這裡討論出來的不是詳細的規格，而是User Story(使用者故事)+Acceptance Criteria(驗收標準)+示意圖或流程圖，當作交付需求的文件。 Development - 迭代MVP功能，可以專注在品質和架構上。 【週期】 一週或二週，視需求討論的狀況。如果是一週的，就合併下次Sprint再舉辦Review  Retro. 【會議】 Planning meeting - 需求探索會議、需求交付會議、開發團隊任務拆解會議 Daily...