執行SCRUM-8 – SPRINT衝刺(2)

而在SPRINT排定工作之後,SCRUM希望能夠鎖定工作,讓團隊專心在這些工作上。因為根據人類同時多工的研究,工作同時間穿插進行,將會浪費轉換的時間。因為在進入工作之前,人類頭腦必須去回想、回復當時的場景、設定或是邏輯。下面是用SCRUM一半的時間做2倍的事>這本書提出的數據,並假設2件事情在轉換時需20%時間,可清楚知道,一旦同時進行工作越多,進行轉換的成本越高,得到的成效越低:同時間作1件事,轉換 0%,每件事分配時間100%,成效100%。同時間作2件事,轉換20%,每件事分配時間40%,...

執行SCRUM-7 – SPRINT衝刺(1)

之前有提到的SPRINT衝刺,指的是團隊在固定時段的工作循環。這個時段可以是1周、2周、10天等等,視團隊成員的協議,但是不宜太長。不過設定的原則,應該是可以完成工作卡片,即展示MVP的工作成果為主。 因為若是SPRINT時段太短,團隊無法完成卡片工作,也就是無法發布給客戶使用,亦即無法計算完成story point,專案管理者就很難估算完成時間及所需資源。若是時段太長,除了產品發布的時間間距過長,亦累積較多的產品一次發布,若是中途客戶變更或是執行方向錯誤,將導致產品失敗。雖然這與全部專案完成後才知...

執行SCRUM-6 –工作卡片的優先順序

工作卡片完成拆解建立,及story point估算之後,接著就是安排優先順序了。原則很簡單,就是以對專案最有價值的工作先完成。依照80/20理論,軟體的80%價值來自於20%的功能,所以優先處理使用者最需要的功能,再加上SCRUM頻繁地發布可使用功能的循環,在開發前期應該就可以獲得使用者正面的回饋。 所以在安排優先順序的作業上,我們必須要反思對顧問來說最重要的是什麼? 我們如何比別人更快提供價值? 而且優先順序的安排上不一定要完美,主要是讓客戶針對推出的功能可以回應,再編排下一階段的優先順序。 在...

執行SCRUM-5 – 故事點 story point(3)

了解story point的定義及用法之後,通常需要一段長時間會議,來設定專案所有卡片的story point。管理者最後會得到一個加總的數值,就是專案=XXX story point。那這個數值也什麼用處呢? 答案是,沒用。哈,你沒看錯,花了這麼大的功夫得到的數值,居然沒用,那你是在給我裝笑維哦。其實,是需要經過幾次的SPRINT之後,才會有用(所以管理者要多點耐心)。因為每次的SPRINT會安排工作,幾次之後,管理者就可以知道團隊1個SRPINT會完成多少點,也就可以知道最後的完成日。舉例來說,...

執行SCRUM-4 – 故事點 story point(2)

從story point(1)的文章內,應該大概了解story point的定義及為何要使用它(what、why),接下來就是要如何用它在執行SCRUM作業。(how、where、who、when) 團隊的成員在確定工作卡片沒疑問後,一起估計數值(不是由專門的人或老闆來估哦),並取平均作為工作卡片的story point。若是團隊中的數值有超過2的級數以上者,代表彼此認知有落差,必須由造成差距者說明為什麼,並由團隊重新估計數值。 因為不是每個人都了解對方工作的專業,所以同仁有時會反應說,不知道如何...

執行SCRUM-3 – 故事點 story point(1)

我覺得story point是SCRUM很重要的概念,一定要非常清楚它的意義與作法,管理者才能掌握專案期限與資源。 SCRUM與瀑布式的專案管理,我認為最大的不同之一,在於時程或是資源的估計方式有非常大的差異。簡單來說,瀑布式的專案管理是完成WBS之後,以工作包去計算所需的時間及成本的估算。而SCRUM是藉由story point的估算後,再由數次的衝刺(SPRINT)之後,才能獲知實際的完成時間及成本。 Story point的估算不是以精確時間來計算,而是以規模性來進行。軟體設計受限於功能、頁...

執行SCRUM-2 – 工作卡片

上一篇大概記錄些前期的準備工作等等,接著就是實戰了,目前團隊是以遠距工作為主,執行SCRUM也是邊作邊修正,也符合SCRUM的精神,GO ~~ 專案一開始要把所有功能、作業拆分成一張張的工作卡片,原則上卡片的工作最好是一個人可以獨立完成的(或小團隊也可以,因為我們人不多,暫以個人作業為劃分),而且是可以達到最小功能產品(MVP,minimum viable product)。當然會有些工作是需要其他人配合的,那就要在卡片內的subtask再開工作卡片。另外卡片最好是能夠以1個SPRINT能夠完成來...

執行SCRUM-1 - Start

我們雖然是個開發WEB APP的小團隊,還是需要建立一個「系統」來完成客戶的委託。東試試、西摸摸之後,決定來用用當前正紅的SCRUM敏捷方式來管理工作(至少以後可以拿來說嘴,哈)。 在K了X本書、爬了N篇文章之後,坐而言不如起而行,實踐才能獲得回饋,並在嘗試的過程中記錄想法、作法及結果,所以之後會這個主題持續建立文章。必須先說明的是,因為是trial and error,所以記載的順序是以時間為主軸,而不是以導入方式順序為記載方式。 軟體工具 工欲善其事,必先利其器,選擇一個適合SCRUM管理的軟...