在上回提到一些應該要避免的措施，以及時時梳理 product backlog 讓團隊有較好的估算，這回則是作為一位 scrum master，我們該如何自省與發現估算的問題，也是以自我反省的方式完結這個系列。

職場產業

學習

當初上完課，很激勵地寫下當時的心得，不太符合現在閱讀的習慣，所以重新整理成較適合閱讀的系列作，這篇將主要分享看板方法的精神與原理，後續會陸續更新，第二篇則是視覺化的作法，第三篇是 WIP Limit 的使用，最後是落實與其他感想。

以前是學生，玩遊戲時不會有什麼特別的想法，現在玩著玩著卻發現，其實這遊戲的過程跟 Agile 軟體開發的過程有些地方很像。

為了業務的短期目標，工程師靠著意志力加班，勉強達成目標，但大家都知道，這段期間不只完成目標也累積龐大的技術債，本來承諾短期目標達成後，會有時間調整，像是整理技術債，或是讓菜鳥工程師能獲得技術訓練，但想也知道，馬上又會有下個短期目標...

會後，我與其中一位創辦人聊聊他們 scrum 怎麼跑，以及程式、美術與企劃，這三種技能差異甚大的成員怎麼合作，他也苦笑，其實他們也花了很多時間磨合，但我們都提到，要引導團隊需要的不是 process，而是很多的軟技能，讓團隊自己能夠成長。

在上回，我們已經把工作視覺化成看板，但這只是第一步，要想用看板方法優化工作的流程，我們得設置 WIP 限制，讓團隊開始知道瓶頸在哪裡，然後才能開始改善，這一回就來看 WIP 限制的設置。

這是 2016 年的舊文重新整理，這幾年應該很少聽到軟體生命週期管理了，裡面的部分概念被其他更夯的詞取代了，像是 DevOps，所以我在一開頭便選了張比較接近潮流的圖片，不過說真的，在這個領域，常常有很多新名詞出現，但真正落實的又有多少呢？

在上回討論 Scrum 對於估算的精神與常見的估算單位，這回就來討論一些應該避免的事項，讓團隊能有更好的估算，下回則是過去的自省與感想。要讓團隊有較高品質的估算，agile coach 或 scrum master 可以觀察一些徵兆，若有發現盡早排除，免得讓團隊成員有壞習慣或是對估算這件事有陰影。

在上回，探討 WIP Limit 的設置，但如果當被 WIP Limit 卡住時，直覺的想法是放寬 WIP Limit 而不是想著如何協助他人讓工作順利完成，那就失去使用看板方法的意義了，這回將探討如何讓團隊自覺與改善。

過去擔任 Scrum Master 時，曾觀察團隊用 planning pork 估時超過三或四輪仍無法取得共識，但點數或時數有時只差一點點 (2 or 3)，或是差距很大 (3 or 8)，若仔細聽他們的討論會發現，之所以會沒有共識，是因為成員都帶入一個心態：如果我做這個 task 要多久？

2008 年開始接觸敏捷與 Scrum 相關知識，也在業界實施多年，但總是會看到許多有趣的反例，這邊就分享一些反例，已經軟體專案管理相關的經驗，大家一起思考一下倒底什麼是敏捷？(本專題不定期更新)

這是從 Medium 開始的一個專題，主要是想用輕鬆閒談的方式，分享這幾年軟體開發的心得，原本比較侷限於軟體架構，但這幾年的文章不僅限於架構，也聊不少流程相關的心得，所以趁換平台，順勢換成閒談軟體設計。