先學寫程式還是先學測試?
對於初學者或新人而言由測試開始是再好不過的了。
一旦寫程式的功力夠了，製造缺陷的機率自然會下降些，這個時候再來寫程式，才不會害己害人。
原因很簡單；因為缺陷是程式沒寫好所造成的，所以要學寫好程式，先學如何測試別人的程式，先看懂別人的程式，再來嘗試寫好程式，似乎會好一些!
.
先學 Scrum還是 Kanban?
大部份的時候；你可能完全沒有選擇的餘地，這可不是老天能安排的，而是看老闆的安排。
從屬性上來看:
Scrum 容易探討未知，處理複雜專案，拿來開發新東西威力無比。
Kanban 是教我們如何自我檢討，可以迅速消除浪費，而得到好的效能。
如果你是開發團隊，當然是先從Kanban 開始。先檢討好團隊的基本動作，整頓好了再來開始作新的東西，從事開發的動作，自然少浪費。這是精實Lean 的好處。
(有太多開發團隊，只曉得一意往前衝刺，忽略了自己在開發上的浪費，這會造成很難走得久遠，尤其是Startup的團隊尤其如是。)
如果你是維護團隊，當然是先從Kanban 開始。視覺化是最大的亮點，團隊可以看見工作上的維護流程是一件相當有價值的事，針對個人亦是如此，人們常常因為養成習慣了，就一直持續做同樣的事情，很少會有機會回過頭來檢討，哪裡做得浪費了應該改進。看板方法的第一步: 視覺化。正是團隊可以拿來持續改進的基礎。這一點對維護工做更顯得珍貴。
如果你是測試團隊，當然是先從Kanban 開始。看的見以後才可以減少猜測的比例。測試團隊在擬定測試計畫之前，一定要對待測的產品或程式有足夠的了解，才可能開出實用的測試案例，不至於浪費大量的測試資源。或做了過多的重複性測試。
.
(你可能覺得奇怪，為什麼都是 Kanban Method 先行呢? 其實原因很簡單，因為它"單純“，不是簡單喔! 它沒有想像上的簡單，因為它可以演進得很有深度，但是它的目的很單純，就是追求效能。不像 Scrum 的目的，是要來應付複雜的專案開發作業，基本上的方向就完全不一樣的)
.
將看板方法融入Scrum的開發過程才是上策
看板方法是一種流程控制，他不是一種具有完備基礎的方法學，雖然他的潛在發展相當可觀，但目前他仍只是一種提供我們產出高效能的流程控制法而已。他缺少需求描述、沒有完備的會議規畫、少了團隊職責分配，少了很多很多軟體開發上該有的措施，這一點讓他看起來十分空泛，但就是這個特性也讓他十分適合融入其它開法方法中，尤其是 Scrum。
看板方法之父 David J. Anderson 是在Microsoft 公司推行敏捷開發法 Scrum 的時候發明看板方法的。他原本的目的只是要求能夠在最少阻力之下順利在組職中推行敏捷式的開發法而已。卻由於他熟悉限制理論的運作而開創了看板方法Kanban Method。做出了對敏捷開發的精實Lean 一支的重大貢獻。也就是這樣的典故，讓看板方法Kanban Method可以十分容易的融入到Scrum的開發過程。
著名的《 Essential Scrum 》 的作者Kenneth S. Rubin(它是2013年Amazon 敏捷理論最暢銷書)，書中就大量的採用 WIP(Work-In-Process)的觀念，實際的運用在工作看板上面。讓Scrum在開發流程上減少了許多的浪費現象。
.
※ 看板方法先行
因為它可以減少組職在推行敏捷上的阻力，它能讓工程師以最好的節奏持續進行開發工作。又能將精實觀念帶入團隊運作。
※ 融入Scrum的開發過程
因為看板方法的流程控制方式是用來提升Scrum運行迭代開發時的效能。讓 Scrum 能真正用來克服複雜的軟體程式開發過程。
.
Ruddy Lee 分享空間 