柏良的乳酪之旅

執行SCRUM-19 - 看板實務2- 分配 從使用者故事拆分成待辦事項後，要不要指定誰來作，是個問題。一般看板是不指定工程師，由開發人員依序拿取待辦事項進行開發。而SCRUM是要指定每項待辦的負責工程師。我們團隊因為工程師專業不同(前端工程師、介面UI/UX設定)，所以工作比較無法彼此支援，所以我們採取指定的方式。 待辦事項指定負責人員後，接著要估算story point。我們是利用費式數列來估算(1,3,5,8,13)，是以待辦事項的規模來作評估。這個部份必須說明的是，數字的估算是以完成待辦...

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

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

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

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