柏良的乳酪之旅

執行SCRUM-13 – 使用者故事User story(4) 而實際上故事的撰寫，通常是從使用者的觀點出發，所以常會很難解析到工作卡片。或者是故事太大、太抽象等等，無法拆分為工作卡片，所以有下列幾種方法可以來切割、重寫、釐清、定義: (精實開發看版方法/李智樺)依照工作流程，拆解流程中的步驟，增量陸續完成。採用業務規則，區分主次要，再釐清使用者的主要需求，再拆解成大小不一的小故事。簡單或複雜場景，有時考量的因素太多，讓故事無法收斂。此時先發展一個最簡單的版本，讓團隊可以依此得到成果，給使用者驗証。...

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

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

工作卡片完成拆解建立，及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的級數以上者，代表彼此認知有落差，必須由造成差距者說明為什麼，並由團隊重新估計數值。 因為不是每個人都了解對方工作的專業，所以同仁有時會反應說，不知道如何...