Showing all posts tagged kanban:

執行SCRUM-22 - 看板實務5 - 人月神話

執行SCRUM-22 - 看板實務5 - 人月神話 在軟體開發專案進行中,常會因為需求變更、除錯、測試、發佈等狀況發生,而導致期程落後的情形。此時,專案經理通常首先想到的是,投入人力資源,希望用更多的人力,提升專案開發的速度,企圖讓專案符合預定交付的期程。 在軟體業有著「人月神話」的說法。一般來說,100單位的工作量交給5人作,需要20天。若改成10人作,理論上期程會縮短成10天。但是,這個算法有個假設常被忽略,就是工作之間是彼此獨立的。而軟體專案的開發,通常涉及許多的資料規格、介面、流程等等,...

執行SCRUM-21 - 看板實務4 - 緊急

執行SCRUM-21 - 看板實務4 - 緊急 在執行各種的專案中,緊急要處理的待辦事項常常發生,例如程式執行出現嚴重錯誤、客戶急需某功能修正,有時只是名詞修正,有時需要功能大幅度的調整。此時,在看板中對於此種情形,是另外開闢一條泳道(LANE),並限制WIP個數。其原因是,緊急狀況的處理必須快速,所以獨立泳道是讓團隊能夠集合眾人的力量,快速地完成。此外,為了避免緊急工作與預劃工作一直切換,造成工程師多工,形成時間浪費,所以要限制WIP的數量。 不過,緊急工作除了藉由看板機制處理外,管理者要思考...

執行 SCRUM-20 - 看板實務3 - 作業

執行 SCRUM-20 - 看板實務3 - 作業 開始作業之後,就按照之前分配的工作及順序,每位工程師都有自己應該負責的部份。通常設定WIP很小的流程區間,會發生瓶頸卡住的現象。有時為了讓工作能夠進行,或者老闆不想看見某個員工閒著,可能會把WIP放大,但放大後,就會產生多工及排隊的現象,所以要謹慎為之。 另一方式是可以設置緩衝區,例如在開發階段,再分成「作業中」及「已完成」,如圖3所示,讓工程師A將完成的待辦事項放「已完成」欄位,可以繼續拉動下一個工作。此外,在完成排定工作後,在SPRINT結束...

執行SCRUM-19 - 看板實務2- 分配

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

執行SCRUM-18 - 看板實務1-初始

執行SCRUM-18 - 看板實務1-初始 在開始看板實作之前,我們似乎忘了作一件事,就是設定各個階段的WIP(Work in Progress)。WIP的限制是避免多工現象發生,進而產生浪費的情形。但是WIP的設定,通常要依團隊、專案的狀況而變化,沒有一種標準或公式可供參考。而且數字大些,造成多工浪費,數字小些,造成人員閒賦,老闆看了心情不好,所以如何取捨,要多多嘗試,無一定論。 在開發階段有2位工程師,WIP暫定4,測試階段有1位測試員,WIP暫定為2。至於預備階段,則要看每位工程師SPRI...

執行SCRUM-17 - 看板實務0-設定

執行SCRUM-17 - 看板實務0-設定 寫了很多有關SCRUM的文章,大都是以某個觀點來敘述,對於整體的實作流程,或是要注意的事項似乎還是霧裡看花的樣子,所以我在[精實開發與看板實務]這本書,看到有人利用漫畫的方式,展現看板實作,所以也來東施效顰,以漫畫的方式一幅幅來敘說,如何將看板代入實際的作業,如果對之前網路發佈的「一日看板」有興趣的,可以搜尋Henrik Kniberg的部落格。 必須先聲明的是,本系列文章所製作的看板實務,是改編一日看板,再加上自己團隊導入後的作法,所以不見得適用所有...

執行SCRUM-16 – 看板方法KanBan method

執行SCRUM-16 – 看板方法KanBan method 我們希望在SCRUM有效管制迭代工作,所以採用「精實作業」提出的看板方法(KanBan method)。這個方法是David J. Anderson在2005年提出,並成功地運用在軟體開發上。簡單來說,看板方法是一種流程管理的方法,透過視覺化的型式了解自己及團隊的工作,並半自動化的控制行為。我們所用的JIRA也是一種運用看板管理的軟體。 看板方法有4個基本原則及六大核心實務,當然在使用這個方法會覺得,好像很多原則及操作方法,不過這裏還是...

執行SCRUM-11 –半成品的限制WIP

上一篇文章有提到WIP(Work in Progress),而它的概念來自看板方法(KanBan Method,會在之後詳細介紹,可以先視為控制流程的方法),有些書籍翻譯為「半成品」,我覺得有表達出隱涵的「未完成」意思。而限制WIP的數目,是為了讓團隊手上的工作,在一個階段中可以集中心力來完成。如同之前文章所說的,未完成且發布的功能,其成效為零。即使作了許多的努力、花費SPRINT時間、投入很多的資源,但是未完成的工作,是不能算入績效的。 舉個例子來說,若設定kanban階段為預備->開發->測試...