柏良的乳酪之旅

從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的估算不是以精確時間來計算，而是以規模性來進行。軟體設計受限於功能、頁...

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

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