一點也不敏捷
21免費公開
2008 年開始接觸敏捷與 Scrum 相關知識，也在業界實施多年，但總是會看到許多有趣的反例，這邊就分享一些反例，已經軟體專案管理相關的經驗，大家一起思考一下倒底什麼是敏捷？(本專題不定期更新)
在上回提到一些應該要避免的措施，以及時時梳理 product backlog 讓團隊有較好的估算，這回則是作為一位 scrum master，我們該如何自省與發現估算的問題，也是以自我反省的方式完結這個系列。
在上回提到一些應該要避免的措施，以及時時梳理 product backlog 讓團隊有較好的估算，這回則是作為一位 scrum master，我們該如何自省與發現估算的問題，也是以自我反省的方式完結這個系列。
在上回討論 Scrum 對於估算的精神與常見的估算單位，這回就來討論一些應該避免的事項，讓團隊能有更好的估算，下回則是過去的自省與感想。要讓團隊有較高品質的估算，agile coach 或 scrum master 可以觀察一些徵兆，若有發現盡早排除，免得讓團隊成員有壞習慣或是對估算這件事有陰影。
在上回討論 Scrum 對於估算的精神與常見的估算單位，這回就來討論一些應該避免的事項，讓團隊能有更好的估算，下回則是過去的自省與感想。要讓團隊有較高品質的估算，agile coach 或 scrum master 可以觀察一些徵兆，若有發現盡早排除，免得讓團隊成員有壞習慣或是對估算這件事有陰影。
這同是 2016 年的舊文，根據現在的閱讀習慣重新整理，文章分成三回陸續發布，本回先談談在 Scrum 中，為什麼要估時，然後談談比較常見的單位與用法。下回則是幾個小方法，讓團隊能有更好的估算。最後一回，則是一些過去的自省與感想。
這同是 2016 年的舊文，根據現在的閱讀習慣重新整理，文章分成三回陸續發布，本回先談談在 Scrum 中，為什麼要估時，然後談談比較常見的單位與用法。下回則是幾個小方法，讓團隊能有更好的估算。最後一回，則是一些過去的自省與感想。
這是 2016 年的舊文重新整理，這幾年應該很少聽到軟體生命週期管理了，裡面的部分概念被其他更夯的詞取代了，像是 DevOps，所以我在一開頭便選了張比較接近潮流的圖片，不過說真的，在這個領域，常常有很多新名詞出現，但真正落實的又有多少呢？
這是 2016 年的舊文重新整理，這幾年應該很少聽到軟體生命週期管理了，裡面的部分概念被其他更夯的詞取代了，像是 DevOps，所以我在一開頭便選了張比較接近潮流的圖片，不過說真的，在這個領域，常常有很多新名詞出現，但真正落實的又有多少呢？
在上回，探討 WIP Limit 的設置，但如果當被 WIP Limit 卡住時，直覺的想法是放寬 WIP Limit 而不是想著如何協助他人讓工作順利完成，那就失去使用看板方法的意義了，這回將探討如何讓團隊自覺與改善。
在上回，探討 WIP Limit 的設置，但如果當被 WIP Limit 卡住時，直覺的想法是放寬 WIP Limit 而不是想著如何協助他人讓工作順利完成，那就失去使用看板方法的意義了，這回將探討如何讓團隊自覺與改善。
在上回，我們已經把工作視覺化成看板，但這只是第一步，要想用看板方法優化工作的流程，我們得設置 WIP 限制，讓團隊開始知道瓶頸在哪裡，然後才能開始改善，這一回就來看 WIP 限制的設置。
在上回，我們已經把工作視覺化成看板，但這只是第一步，要想用看板方法優化工作的流程，我們得設置 WIP 限制，讓團隊開始知道瓶頸在哪裡，然後才能開始改善，這一回就來看 WIP 限制的設置。
在上一回 說明看板方法相關的精實精神與原則與實務，這一回則是來設計看板，包含看板的範圍應該多廣、有哪些狀態、工作的顆粒度，以及 DoD 的呈現。
在上一回 說明看板方法相關的精實精神與原則與實務，這一回則是來設計看板，包含看板的範圍應該多廣、有哪些狀態、工作的顆粒度，以及 DoD 的呈現。
當初上完課，很激勵地寫下當時的心得，不太符合現在閱讀的習慣，所以重新整理成較適合閱讀的系列作，這篇將主要分享看板方法的精神與原理，後續會陸續更新，第二篇則是視覺化的作法，第三篇是 WIP Limit 的使用，最後是落實與其他感想。
當初上完課，很激勵地寫下當時的心得，不太符合現在閱讀的習慣，所以重新整理成較適合閱讀的系列作，這篇將主要分享看板方法的精神與原理，後續會陸續更新，第二篇則是視覺化的作法，第三篇是 WIP Limit 的使用，最後是落實與其他感想。
以前是學生，玩遊戲時不會有什麼特別的想法，現在玩著玩著卻發現，其實這遊戲的過程跟 Agile 軟體開發的過程有些地方很像。
以前是學生，玩遊戲時不會有什麼特別的想法，現在玩著玩著卻發現，其實這遊戲的過程跟 Agile 軟體開發的過程有些地方很像。
會後，我與其中一位創辦人聊聊他們 scrum 怎麼跑，以及程式、美術與企劃，這三種技能差異甚大的成員怎麼合作，他也苦笑，其實他們也花了很多時間磨合，但我們都提到，要引導團隊需要的不是 process，而是很多的軟技能，讓團隊自己能夠成長。
會後，我與其中一位創辦人聊聊他們 scrum 怎麼跑，以及程式、美術與企劃，這三種技能差異甚大的成員怎麼合作，他也苦笑，其實他們也花了很多時間磨合，但我們都提到，要引導團隊需要的不是 process，而是很多的軟技能，讓團隊自己能夠成長。
創業團隊就會很在意story的內容，會有相當多的意見，refinement meeting就是一個很好的場合讓大家把對需求的想法提出來，否則讓成員失去參與感，這對創業團隊是很大的傷害。
創業團隊就會很在意story的內容，會有相當多的意見，refinement meeting就是一個很好的場合讓大家把對需求的想法提出來，否則讓成員失去參與感，這對創業團隊是很大的傷害。
第一次參加 Agile community in 內湖辦的社群活動 (2017 年)，同一天其實也是 C.C. Agile #59，當初報名時想了一下，C.C. Agile 從開始到現在，幾乎快要場場都到，似乎有點在同溫層打滾，是否該換個客場，看看其他地方的社群活動，加上這次的主題很有意思
第一次參加 Agile community in 內湖辦的社群活動 (2017 年)，同一天其實也是 C.C. Agile #59，當初報名時想了一下，C.C. Agile 從開始到現在，幾乎快要場場都到，似乎有點在同溫層打滾，是否該換個客場，看看其他地方的社群活動，加上這次的主題很有意思
為了業務的短期目標，工程師靠著意志力加班，勉強達成目標，但大家都知道，這段期間不只完成目標也累積龐大的技術債，本來承諾短期目標達成後，會有時間調整，像是整理技術債，或是讓菜鳥工程師能獲得技術訓練，但想也知道，馬上又會有下個短期目標...
為了業務的短期目標，工程師靠著意志力加班，勉強達成目標，但大家都知道，這段期間不只完成目標也累積龐大的技術債，本來承諾短期目標達成後，會有時間調整，像是整理技術債，或是讓菜鳥工程師能獲得技術訓練，但想也知道，馬上又會有下個短期目標...
隨著團隊組織方式的改變，個人在團隊中的角色也有了改變，改變至今大概有三個多月，從不同的角度在看事情時，也能得到許多有趣的想法，加上幾次參加C.C. Agile也都能得到意外的驚喜，讓自己反省：自己真的Agile了嗎？真的了解scrum？
隨著團隊組織方式的改變，個人在團隊中的角色也有了改變，改變至今大概有三個多月，從不同的角度在看事情時，也能得到許多有趣的想法，加上幾次參加C.C. Agile也都能得到意外的驚喜，讓自己反省：自己真的Agile了嗎？真的了解scrum？
這名字是刻意取Stop starting, start finishing的相反，有一陣子在觀察團隊時發現，story/task 的 burn-down線圖會發現到task幾乎都完成了，但story卻還懸在半空中，甚至在sprint結束前一天，還是有不少stories接近完工卻還沒完工。
這名字是刻意取Stop starting, start finishing的相反，有一陣子在觀察團隊時發現，story/task 的 burn-down線圖會發現到task幾乎都完成了，但story卻還懸在半空中，甚至在sprint結束前一天，還是有不少stories接近完工卻還沒完工。
Acceptance criteria 確保 do the right things，DoD 則是確保 do the things right，兩者合在一起，才會 do the right things right。
Acceptance criteria 確保 do the right things，DoD 則是確保 do the things right，兩者合在一起，才會 do the right things right。
一般來說，會斤斤計較估算的數字，一個可能的潛在原因是來自管理層，忘記從哪看來的一句話：總是會得到想要的 KPI。意思是當制定一個指標，總是能得到期望的數字卻不一定能達到預期的效果。
一般來說，會斤斤計較估算的數字，一個可能的潛在原因是來自管理層，忘記從哪看來的一句話：總是會得到想要的 KPI。意思是當制定一個指標，總是能得到期望的數字卻不一定能達到預期的效果。
過去擔任 Scrum Master 時，曾觀察團隊用 planning pork 估時超過三或四輪仍無法取得共識，但點數或時數有時只差一點點 (2 or 3)，或是差距很大 (3 or 8)，若仔細聽他們的討論會發現，之所以會沒有共識，是因為成員都帶入一個心態：如果我做這個 task 要多久？
過去擔任 Scrum Master 時，曾觀察團隊用 planning pork 估時超過三或四輪仍無法取得共識，但點數或時數有時只差一點點 (2 or 3)，或是差距很大 (3 or 8)，若仔細聽他們的討論會發現，之所以會沒有共識，是因為成員都帶入一個心態：如果我做這個 task 要多久？
如果工作的預估和實際的執行是一致的，就不會有《人月神話》中那一句話：用人月的前提必須是人力與工時可以互換的情況下。我並不是說反正執行結果都不會跟預估的一樣，所以團隊成員在 planning meeting 裡可以亂估，而是要回頭想一下，Scrum 裡 planning meeting 的本質是什麼？
如果工作的預估和實際的執行是一致的，就不會有《人月神話》中那一句話：用人月的前提必須是人力與工時可以互換的情況下。我並不是說反正執行結果都不會跟預估的一樣，所以團隊成員在 planning meeting 裡可以亂估，而是要回頭想一下，Scrum 裡 planning meeting 的本質是什麼？
之前讀《Refactoring: Improving the Design of Existing Code》，書中提到了若干個smells，用來聞出程式設計不太理想的地方，那在用Agile或Scrum方法時，是否也能聞出哪裡有些問題呢？可以的，我把過去參與過的經驗整理成幾個 smells。
之前讀《Refactoring: Improving the Design of Existing Code》，書中提到了若干個smells，用來聞出程式設計不太理想的地方，那在用Agile或Scrum方法時，是否也能聞出哪裡有些問題呢？可以的，我把過去參與過的經驗整理成幾個 smells。
在上回提到一些應該要避免的措施，以及時時梳理 product backlog 讓團隊有較好的估算，這回則是作為一位 scrum master，我們該如何自省與發現估算的問題，也是以自我反省的方式完結這個系列。
在上回提到一些應該要避免的措施，以及時時梳理 product backlog 讓團隊有較好的估算，這回則是作為一位 scrum master，我們該如何自省與發現估算的問題，也是以自我反省的方式完結這個系列。
在上回討論 Scrum 對於估算的精神與常見的估算單位，這回就來討論一些應該避免的事項，讓團隊能有更好的估算，下回則是過去的自省與感想。要讓團隊有較高品質的估算，agile coach 或 scrum master 可以觀察一些徵兆，若有發現盡早排除，免得讓團隊成員有壞習慣或是對估算這件事有陰影。
在上回討論 Scrum 對於估算的精神與常見的估算單位，這回就來討論一些應該避免的事項，讓團隊能有更好的估算，下回則是過去的自省與感想。要讓團隊有較高品質的估算，agile coach 或 scrum master 可以觀察一些徵兆，若有發現盡早排除，免得讓團隊成員有壞習慣或是對估算這件事有陰影。
這同是 2016 年的舊文，根據現在的閱讀習慣重新整理，文章分成三回陸續發布，本回先談談在 Scrum 中，為什麼要估時，然後談談比較常見的單位與用法。下回則是幾個小方法，讓團隊能有更好的估算。最後一回，則是一些過去的自省與感想。
這同是 2016 年的舊文，根據現在的閱讀習慣重新整理，文章分成三回陸續發布，本回先談談在 Scrum 中，為什麼要估時，然後談談比較常見的單位與用法。下回則是幾個小方法，讓團隊能有更好的估算。最後一回，則是一些過去的自省與感想。
這是 2016 年的舊文重新整理，這幾年應該很少聽到軟體生命週期管理了，裡面的部分概念被其他更夯的詞取代了，像是 DevOps，所以我在一開頭便選了張比較接近潮流的圖片，不過說真的，在這個領域，常常有很多新名詞出現，但真正落實的又有多少呢？
這是 2016 年的舊文重新整理，這幾年應該很少聽到軟體生命週期管理了，裡面的部分概念被其他更夯的詞取代了，像是 DevOps，所以我在一開頭便選了張比較接近潮流的圖片，不過說真的，在這個領域，常常有很多新名詞出現，但真正落實的又有多少呢？
在上回，探討 WIP Limit 的設置，但如果當被 WIP Limit 卡住時，直覺的想法是放寬 WIP Limit 而不是想著如何協助他人讓工作順利完成，那就失去使用看板方法的意義了，這回將探討如何讓團隊自覺與改善。
在上回，探討 WIP Limit 的設置，但如果當被 WIP Limit 卡住時，直覺的想法是放寬 WIP Limit 而不是想著如何協助他人讓工作順利完成，那就失去使用看板方法的意義了，這回將探討如何讓團隊自覺與改善。
在上回，我們已經把工作視覺化成看板，但這只是第一步，要想用看板方法優化工作的流程，我們得設置 WIP 限制，讓團隊開始知道瓶頸在哪裡，然後才能開始改善，這一回就來看 WIP 限制的設置。
在上回，我們已經把工作視覺化成看板，但這只是第一步，要想用看板方法優化工作的流程，我們得設置 WIP 限制，讓團隊開始知道瓶頸在哪裡，然後才能開始改善，這一回就來看 WIP 限制的設置。
在上一回 說明看板方法相關的精實精神與原則與實務，這一回則是來設計看板，包含看板的範圍應該多廣、有哪些狀態、工作的顆粒度，以及 DoD 的呈現。
在上一回 說明看板方法相關的精實精神與原則與實務，這一回則是來設計看板，包含看板的範圍應該多廣、有哪些狀態、工作的顆粒度，以及 DoD 的呈現。
當初上完課，很激勵地寫下當時的心得，不太符合現在閱讀的習慣，所以重新整理成較適合閱讀的系列作，這篇將主要分享看板方法的精神與原理，後續會陸續更新，第二篇則是視覺化的作法，第三篇是 WIP Limit 的使用，最後是落實與其他感想。
當初上完課，很激勵地寫下當時的心得，不太符合現在閱讀的習慣，所以重新整理成較適合閱讀的系列作，這篇將主要分享看板方法的精神與原理，後續會陸續更新，第二篇則是視覺化的作法，第三篇是 WIP Limit 的使用，最後是落實與其他感想。
以前是學生，玩遊戲時不會有什麼特別的想法，現在玩著玩著卻發現，其實這遊戲的過程跟 Agile 軟體開發的過程有些地方很像。
以前是學生，玩遊戲時不會有什麼特別的想法，現在玩著玩著卻發現，其實這遊戲的過程跟 Agile 軟體開發的過程有些地方很像。
會後，我與其中一位創辦人聊聊他們 scrum 怎麼跑，以及程式、美術與企劃，這三種技能差異甚大的成員怎麼合作，他也苦笑，其實他們也花了很多時間磨合，但我們都提到，要引導團隊需要的不是 process，而是很多的軟技能，讓團隊自己能夠成長。
會後，我與其中一位創辦人聊聊他們 scrum 怎麼跑，以及程式、美術與企劃，這三種技能差異甚大的成員怎麼合作，他也苦笑，其實他們也花了很多時間磨合，但我們都提到，要引導團隊需要的不是 process，而是很多的軟技能，讓團隊自己能夠成長。
創業團隊就會很在意story的內容，會有相當多的意見，refinement meeting就是一個很好的場合讓大家把對需求的想法提出來，否則讓成員失去參與感，這對創業團隊是很大的傷害。
創業團隊就會很在意story的內容，會有相當多的意見，refinement meeting就是一個很好的場合讓大家把對需求的想法提出來，否則讓成員失去參與感，這對創業團隊是很大的傷害。
第一次參加 Agile community in 內湖辦的社群活動 (2017 年)，同一天其實也是 C.C. Agile #59，當初報名時想了一下，C.C. Agile 從開始到現在，幾乎快要場場都到，似乎有點在同溫層打滾，是否該換個客場，看看其他地方的社群活動，加上這次的主題很有意思
第一次參加 Agile community in 內湖辦的社群活動 (2017 年)，同一天其實也是 C.C. Agile #59，當初報名時想了一下，C.C. Agile 從開始到現在，幾乎快要場場都到，似乎有點在同溫層打滾，是否該換個客場，看看其他地方的社群活動，加上這次的主題很有意思
為了業務的短期目標，工程師靠著意志力加班，勉強達成目標，但大家都知道，這段期間不只完成目標也累積龐大的技術債，本來承諾短期目標達成後，會有時間調整，像是整理技術債，或是讓菜鳥工程師能獲得技術訓練，但想也知道，馬上又會有下個短期目標...
為了業務的短期目標，工程師靠著意志力加班，勉強達成目標，但大家都知道，這段期間不只完成目標也累積龐大的技術債，本來承諾短期目標達成後，會有時間調整，像是整理技術債，或是讓菜鳥工程師能獲得技術訓練，但想也知道，馬上又會有下個短期目標...
隨著團隊組織方式的改變，個人在團隊中的角色也有了改變，改變至今大概有三個多月，從不同的角度在看事情時，也能得到許多有趣的想法，加上幾次參加C.C. Agile也都能得到意外的驚喜，讓自己反省：自己真的Agile了嗎？真的了解scrum？
隨著團隊組織方式的改變，個人在團隊中的角色也有了改變，改變至今大概有三個多月，從不同的角度在看事情時，也能得到許多有趣的想法，加上幾次參加C.C. Agile也都能得到意外的驚喜，讓自己反省：自己真的Agile了嗎？真的了解scrum？
這名字是刻意取Stop starting, start finishing的相反，有一陣子在觀察團隊時發現，story/task 的 burn-down線圖會發現到task幾乎都完成了，但story卻還懸在半空中，甚至在sprint結束前一天，還是有不少stories接近完工卻還沒完工。
這名字是刻意取Stop starting, start finishing的相反，有一陣子在觀察團隊時發現，story/task 的 burn-down線圖會發現到task幾乎都完成了，但story卻還懸在半空中，甚至在sprint結束前一天，還是有不少stories接近完工卻還沒完工。
Acceptance criteria 確保 do the right things，DoD 則是確保 do the things right，兩者合在一起，才會 do the right things right。
Acceptance criteria 確保 do the right things，DoD 則是確保 do the things right，兩者合在一起，才會 do the right things right。
一般來說，會斤斤計較估算的數字，一個可能的潛在原因是來自管理層，忘記從哪看來的一句話：總是會得到想要的 KPI。意思是當制定一個指標，總是能得到期望的數字卻不一定能達到預期的效果。
一般來說，會斤斤計較估算的數字，一個可能的潛在原因是來自管理層，忘記從哪看來的一句話：總是會得到想要的 KPI。意思是當制定一個指標，總是能得到期望的數字卻不一定能達到預期的效果。
過去擔任 Scrum Master 時，曾觀察團隊用 planning pork 估時超過三或四輪仍無法取得共識，但點數或時數有時只差一點點 (2 or 3)，或是差距很大 (3 or 8)，若仔細聽他們的討論會發現，之所以會沒有共識，是因為成員都帶入一個心態：如果我做這個 task 要多久？
過去擔任 Scrum Master 時，曾觀察團隊用 planning pork 估時超過三或四輪仍無法取得共識，但點數或時數有時只差一點點 (2 or 3)，或是差距很大 (3 or 8)，若仔細聽他們的討論會發現，之所以會沒有共識，是因為成員都帶入一個心態：如果我做這個 task 要多久？
如果工作的預估和實際的執行是一致的，就不會有《人月神話》中那一句話：用人月的前提必須是人力與工時可以互換的情況下。我並不是說反正執行結果都不會跟預估的一樣，所以團隊成員在 planning meeting 裡可以亂估，而是要回頭想一下，Scrum 裡 planning meeting 的本質是什麼？
如果工作的預估和實際的執行是一致的，就不會有《人月神話》中那一句話：用人月的前提必須是人力與工時可以互換的情況下。我並不是說反正執行結果都不會跟預估的一樣，所以團隊成員在 planning meeting 裡可以亂估，而是要回頭想一下，Scrum 裡 planning meeting 的本質是什麼？
之前讀《Refactoring: Improving the Design of Existing Code》，書中提到了若干個smells，用來聞出程式設計不太理想的地方，那在用Agile或Scrum方法時，是否也能聞出哪裡有些問題呢？可以的，我把過去參與過的經驗整理成幾個 smells。
之前讀《Refactoring: Improving the Design of Existing Code》，書中提到了若干個smells，用來聞出程式設計不太理想的地方，那在用Agile或Scrum方法時，是否也能聞出哪裡有些問題呢？可以的，我把過去參與過的經驗整理成幾個 smells。