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

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

寓意科技

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

一、 敏捷開發與Scrum

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

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

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

  • 獨立工作成員與互動 勝於 流程與工具的管理

  • 工作產出的軟體 勝於 廣泛而全面的文件

  • 與客戶合作 勝於 合約的協商

  • 因應變化 勝於 遵循計劃

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

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

  1. Scrum Master是Scrum教練和團隊帶頭人,確保團隊合理的運作Scrum,並幫助團隊掃除實施中的障礙;

  2. 產品負責人,確定產品的方向和願景,定義產品發布的內容、優先級及交付時間,為產品投資報酬率負責;

  3. 開發團隊,一個跨職能的小團隊,人數5-9人,團隊擁有交付可用軟體需要的各種技能。

  4. 其他利益相者,影響項目成功的人,諸如:客戶、上下游提供商、老闆等。

 

Scrum中的物件

  1. Item:一個產品的產出或是功能。

  2. Task:完成Item所需的工作。

  3. Product Backlog:產品待辦清單,以Item為單位。

  4. Sprint Backlog:衝刺待辦清單,本次Sprint(衝刺期)會盡力完成的Item List;以Task為單位。

  5. Potentially Shippable Product Increment:潛在可交付產品增量,指的是要上線就可以馬上上線的Items。

  6. Burndown Chart:燃盡圖,指的是尚未完成的工作,以Task為單位。

 

Scrum活動

  1. Sprint:衝刺期,固定每次的Sprint大小,並決定本次Sprint須放入多少的Task。

  2. Daily Scrum:每日站立會議,用以同步團隊資訊。

  3. Sprint Planning:衝刺規劃會議,Sprint開始時,討論一下本次Sprint,可以交付哪些Item。

  4. Product Backlog Refinement / PBR:產品待辦清單精煉會議,PO跟Team一起討論近期內會開始施工的Item,主要是從商業和使用者角度切入,盡可能不觸及技術細節。

  5. Sprint Review:衝刺檢視會議,Sprint結束時針對產品的會議,邀請利害關係人對產出給意見,針對軟體操作取得回饋。

  6. 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,快速迭代。

 

接著,讓我們來思考看看:

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

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

 

  1. 如果公司越來越敏捷了,那對於公司是有幫助的嗎?

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

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

 

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

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

  1. 共同創造價值的策略思考模式

  2. 靈活的和可擴展的組織模式

  3. 快速的決策以及學習週期

  4. 賦予員工必要的權力,激勵員工們以團隊的方式協作

  5. 技術是開啟價值,快速回應各種需求的一大關鍵。

 

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

「資訊更流通」代表讓第一線工作者的經驗反饋回管理階層;這在美式的管理文化,其實改變不大,因為美式的管理,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標誌啦!

(上圖取自:https://medium.com/as-a-product-designer/%E5%85%88%E5%88%A5%E6%80%A5%E8%91%97%E7%95%ABui-%E4%BD%A0%E8%81%BD%E9%81%8Eflow-chart%E5%97%8E-c6715f055cfc)

 

1. 進入draw.io的網址,可以點選製作新的圖(上),或是打開舊有的圖(下)

2. 這邊可以點選製作新的圖(上),此時出現各種不同的user flow chart範本供我們選擇,當然也有空白的範本可以讓我們自行發揮。

3. 我們隨意點選任一個範本進行觀察,左側是圖示區、中間是繪圖區,可將左側的圖示拉到中間繪圖區、右側則可以修改圖示的格式,像是:顏色、大小、外框粗細等。

4. 讓我們動手實作一個user flow chart吧,我想剛剛的教程就是一個很好的題目!

(PS:該如何繪製從打開draw.io的網站開始,到進到繪圖頁面的user flow chart呢?)

答案一定很多種,希望大家能了解這個工具該怎麼使用!

寓意科技
寓意科技

寓意科技提供專業的及系統資訊科技管理顧問服務,協助企業規劃並完成軟體建置

fable寓意科技官方網站:https://www.fable.com.tw/

fable寓意科技 Medium:https://medium.com/@fableltd

團隊的 GIT 分支管理策略 (2) : 主線整合與功能分支
繼第一篇講述基本概念之後,我們來看看整合模式有哪些,以及整合頻率對於團隊效率的影響。
【產品規劃系列(三)】軟體 PM 撰寫規格書的三大工具之三,UI Flow
這篇文章說明了「Flow Chart」、「UI Flow」、「Wire Flow」的差異,透過漸進的文件產出,最終可以得到一份完整的功能/畫面規格。
團隊的 GIT 分支管理策略 (1) : 基本概念
此文分兩個重點部分: 『整合』:工程師們如何把自己的產出整合成一個統一版本。『準備發佈』:從整合好的 codebase 到實際上線的分支處理。