DMA01

敏捷開發與Scrum、draw.io & user flow chart

寓意科技

敏捷開發/迭代的重要觀念與快速製作原型的工具, e.g. draw.io user flow, etc.

一、敏捷開發與Scrum

會進到這邊的同學，想來對敏捷開發一定不陌生吧~？

那你知道敏捷開發只是一個精神，不是一個具體的操作方法嗎？

讓我們從敏捷軟體開發宣言開始：

獨立工作成員與互動勝於流程與工具的管理
工作產出的軟體勝於廣泛而全面的文件
與客戶合作勝於合約的協商
因應變化勝於遵循計劃

看出來了嗎？最一開始的宣言，只是想把大家的焦點從流程、產出文件、計劃轉移到互動、產出成品、變化上。並不是說前者都不重要，而是說隨著網路時代的來臨，遠距協做的可能性增加、軟體開發使用者需求經常變動的前提下，改變常常無時無刻地出現。相較於以往瀑布流的開發，一開始就要設想好各種意外的狀況，敏捷開發更強調的是先上線後再快速迭代。這樣的方式也更符合現在這個技術快速更迭的時代。既然敏捷開發是個精神，那Scrum就是大家最常聽到的方法論，用以實踐到管理上。

Scrum是一個包括了一系列實踐和預定義角色的操作範式，用來達成敏捷開發的精神。
Scrum中的主要角色包括：

Scrum Master是Scrum教練和團隊帶頭人，確保團隊合理的運作Scrum，並幫助團隊掃除實施中的障礙；
產品負責人，確定產品的方向和願景，定義產品發布的內容、優先級及交付時間，為產品投資報酬率負責；
開發團隊，一個跨職能的小團隊，人數5-9人，團隊擁有交付可用軟體需要的各種技能。
其他利益相者，影響項目成功的人，諸如：客戶、上下游提供商、老闆等。

Scrum中的物件

Item：一個產品的產出或是功能。
Task：完成Item所需的工作。
Product Backlog：產品待辦清單，以Item為單位。
Sprint Backlog：衝刺待辦清單，本次Sprint(衝刺期)會盡力完成的Item List；以Task為單位。
Potentially Shippable Product Increment：潛在可交付產品增量，指的是要上線就可以馬上上線的Items。
Burndown Chart：燃盡圖，指的是尚未完成的工作，以Task為單位。

Scrum活動

Sprint：衝刺期，固定每次的Sprint大小，並決定本次Sprint須放入多少的Task。
Daily Scrum：每日站立會議，用以同步團隊資訊。
Sprint Planning：衝刺規劃會議，Sprint開始時，討論一下本次Sprint，可以交付哪些Item。
Product Backlog Refinement / PBR：產品待辦清單精煉會議，PO跟Team一起討論近期內會開始施工的Item，主要是從商業和使用者角度切入，盡可能不觸及技術細節。
Sprint Review：衝刺檢視會議，Sprint結束時針對產品的會議，邀請利害關係人對產出給意見，針對軟體操作取得回饋。
Sprint Retrospective / Sprint Retro：衝刺回顧會議，Sprint Review後，Scrum Team成員針對這個Sprint團隊的工作模式討論改善，並定出下個Sprint。

相較於過往瀑布流會有PM的角色，Scrum的體制下，將角色分成Scrum Master與產品負責人，前者負責維持整個開發的秩序以及流程，後者則負責統合所有利害關係人的需求，轉化成需求清單。並且讓整個團隊共同為時程負責，這與過往的PM一人擔當的狀況有很大的不同。

在產品開發的時間裡，我們最一開始會針對客戶的需求列出所有待完成的Items以及Product Backlog，並轉換成工程師的Tasks。之後，會將產品的開發時程區分成幾個sprint，在sprint前一小段時間，我們會先開展Sprint Planning，討論本次sprint的Sprint Backlog，每天舉行Daily Scrum，本次sprint結束後，與利害關係人進行Sprint Review，與團隊內部成員進行Sprint Retro，並隨時增補Potentially Shippable Product Increment。每一輪的sprint後，可能都會面臨到利害關係人提出的建議，團隊需要因應這個建議帶來的變化，重新修改Product Backlog、Potentially Shippable Product Increment等，而這就是Rapid Prototyping，快速迭代。

接著，讓我們來思考看看：

如果在公司中實際應用Scrum，那能夠保證公司一定是「敏捷」的嗎?

事情當然沒有這麼簡單~很多公司都是打著敏捷的口號跟制度，但其實還是在搞一些很拖沓的制度，反而失去敏捷的精神。舉例來說，如果應用了Scrum，組織內也部署了Scrum Master、產品負責人，當產品負責人依舊沿用過往瀑布流開發的思維，覺得自己預先設想好了所有的狀況，不跟客戶、其他利害關係人進行需求訪談，這時候的公司一定不是「敏捷」的。從結果論來看，如果應用了Scrum，「公司資訊同步得更快」、「讓客戶跟進產品開發」、「因應客戶提出的變化，而非照著原本的計畫」這樣就表示公司確實正在朝「敏捷」的方向改進。

如果公司越來越敏捷了，那對於公司是有幫助的嗎？

很遺憾，我的答案是否定的。作為公司的最高管理者，我們該思考的，與敏捷一點關係都沒有。我們該思考的是：該怎麼利用各種方法，來讓事情變得更順暢。如果要打保守牌，不見得用敏捷的思維是好事，按照過往的經驗繼續做下去就可以了，不需要更改組織的模式，來提高公司經營的風險；但是如果公司讓每週週會(類似sprint planning)或daily standup meeting，都「開」得好，加速資訊流通，就算開發進度較慢，其實也無妨。也就是說，如果能透過敏捷的一些方法論，讓資訊流通跟開會的效率提升，這就是有效的管理。

因此，第一線管理者就算理解敏捷、理解scrum，還是要回頭思考什麼方法是對團隊最有效的，甚至先從小地方改起，比如說開會的效率等等，反而是比探討敏捷更有意義的事。

一番思考過後，你還是覺得公司適合敏捷。那該如何做，才可以保持組織的敏捷呢？

麥肯錫公司認為「組織敏捷性」是面對瞬息萬變、模糊動盪的環境，快速調整策略、結構、流程、人員和科技，以獲得創造價值（和保護既有價值）機會的能力。並提出了五大方針：

共同創造價值的策略思考模式
靈活的和可擴展的組織模式
快速的決策以及學習週期
賦予員工必要的權力，激勵員工們以團隊的方式協作
技術是開啟價值，快速回應各種需求的一大關鍵。

有點空泛對不對~？其實，「敏捷」兩個字，我們可以把它視為：「資訊更流通」+「快速迭代」，兩大基本原則。

「資訊更流通」代表讓第一線工作者的經驗反饋回管理階層；這在美式的管理文化，其實改變不大，因為美式的管理，Bottom Up的機會本來就比較多，但是這在亞洲的管理文化，尤其是日本、台灣這種Top Down非常明顯的文化背景下，就很難實行，所以這個文化衝擊是很多公司要完成導入敏捷最困難的。舉個簡單的例子，敏捷提倡客戶至上，當第一線的產品負責人發覺了某個能幫助客戶的重要服務，不過這件事一方面可能要投入新資源，另一方面可能跟老闆的決策有所抵觸，在台灣，這件事很有可能連討論都不會發生，而我們希望先能做到的第一步，便是大家可以放下角色的成見，來做有效的溝通，而這就已經十分有幫助了。

「快速迭代」則可以應用在產品(開發)迭代、組織迭代、人員迭代上，如果說起點與終點隔著一大段的距離，迭代的意思就像是在一團迷霧中，往前直直走，你不能百分之百的肯定自己的方向是正確的，但可以偶爾把自己的視角拉遠一些，重新確立新的、可能正確的方向。而這個「重新確立新的、可能正確的方向」就是迭代。

應用在產品開發上，我們就可以透過與客戶進行多次的需求訪談，或使用者調研，把自己的視角拉遠一些，重新確立新的、可能正確的方向。在組織迭代上，則可以依照需求進行組織再造，指派某個小組負責該需求，需求結束後，該小組也任務完成，可以打散成員去協助其他需求，這就是「變形蟲組織」。應用在人員迭代上，個人則是需要持續不斷的迭代自己，無論是透過學習、實作等的方式，讓自己更適應現階段的職位。

實務上來說，台灣常有各部門分立的狀況，想要進行產品/組織快速迭代，可能就要同時經歷3~4個大主管。因此，如果要達成這兩個原則，導入敏捷，對台灣許多公司來說，難點在於所面臨的文化衝擊跟組織重整的狀況。

二、Draw.io & User Flow Chart

既然談到敏捷開發，為了因應客戶變動的需求，我們常常需要把新的需求製作成原型圖，供客戶以及團隊了解產品大概的樣貌，在此，我們會簡單告訴大家原型圖的相關製作工具：draw.io，用來繪製user flow的工具。

https://app.diagrams.net/

user flow chart 既然以flow為名，是指一個流程的進行，那就會出現流程的起點與終點，而根據不同的中間處理過程，起點和終點也會不一樣，所以我們使用長弧形作為流程的起點、終點的標誌。使用者進入流程起點後，依照不同的使用方式，系統會經歷不同的處理流程，並給予使用者不同的回饋。舉例來說，使用者點選網站右上方的登入後，系統會將頁面跳轉到登入介面，並要求使用者輸入帳號密碼。此時的處理流程就是頁面跳轉，使用者得到的回饋就是輸入帳號密碼。我們以長方形作為系統處理流程的標誌；以斜方形作為系統得到資料的標誌。除了要求使用者輸入資料以外，也有可能需要使用者進行選擇，像是選取商品類別等，這時候就以菱形作為使用者選擇的標誌。這些就是基本的user flow chart標誌啦！