Alan Shalloway最近列舉了他所謂的關(guān)于看板的“一般神話”。 他的列表中包括以下內(nèi)容：

• 精益開發(fā)是一種能夠在社會化系統(tǒng)中起作用的規(guī)范方法。
• 看板要求線性地工作，并且需要太多的傳遞。
• 顯式的規(guī)則是靜態(tài)的，難于改變，并且不具有靈活性。
• 看板已經(jīng)獲得了成功，因為它是由早期的采用者完成的。
• 開始時使用Scrum，然后再從看板開始，這樣做會好一些
• 看板不像其它敏捷方法那樣注重人的作用。
• 看板沒有對人做足夠的處理
• 想要獲得強大的改變，你需要進行革命性的改變，而看板則是漸進發(fā)展的。

[...]

• 看板是沒有迭代的Scrum。
• 看板大多是用來作為支持的。
• 看板會導(dǎo)致團隊固定不變。
• 看板無法生效，因為顯式的規(guī)則在敏捷世界中是不合理的。

　　Shalloway盡其所能在《看板神話》這篇文章中消除其中的一些神話。

　　Alan Dayley引用了關(guān)于響應(yīng)的神話：

我遇到最多的神話是關(guān)于WIP限制的。

“如果我們已經(jīng)達到了極限，那么看板會降低我們對客戶做出快速響應(yīng)的能力。”

　　Adam Sroka向列表中添加了關(guān)于時間箱（timeboxing）的神話：

　　一直以來我所認為的是看板 == 沒有時間箱。

　　有些人認為它是必要的（通常是因為他們認為兩周的時間太短了）。 其他人則認為這意味著他們會破壞規(guī)定。

　　這兩種想法都是錯誤的。 我們的節(jié)奏不一定必須是兩周，但是我們需要有節(jié)奏并且知道它是多少。 我們不會刻意地使用時間箱，但是我們會衡量每件事情會花費多少時間，并試著按照平均的時間讓它最小化。

　　Matthias Bohlen認為Ken Schwaber引用的內(nèi)容也是一種看板神話： “上帝保佑， 人們試圖找到各種方式，可以在瀑布模式中放松一下，從而獲得休息，并變得更有創(chuàng)意。 有了精益和看板，其中隱藏的部分已經(jīng)被移除了。 因此現(xiàn)在我們要持續(xù)向死亡行軍而沒有停頓。” Bohlen回應(yīng)說：

　　沒有什么“持續(xù)向死亡行軍而沒有停頓”。 人們可以在任何需要的時候停下來喝杯咖啡。 可以決定在什么時候休息。 看板不會比其它方法更嚴重地壓榨人們，因為看板并非是一種方法——人們是使用團隊現(xiàn)有的方法完成的工作。 看板讓工作變得更加透明，但是本身并不是一種方法。 如果你愿意，可以認為它是“非方法”（至少我是那么認為的）。

　　看板與“持續(xù)向死亡行軍而沒有停頓”恰恰相反。 考慮一下驗收測試團隊，它的職責(zé)是幫助產(chǎn)品所有者發(fā)現(xiàn)是否已經(jīng)正確實現(xiàn)了backlog項目。 如果整個團隊都感冒了會怎么樣呢？ 開發(fā)團隊就會遇到WIP限制，因為測試人員都病了，無法把已經(jīng)開發(fā)完成的內(nèi)容從開發(fā)狀態(tài)轉(zhuǎn)換為驗收測試狀態(tài)。 因此，這些內(nèi)容會保持在開發(fā)狀態(tài)。

　　然后會怎么樣呢？ 開發(fā)者會由于自己的WIP限制而停止開發(fā)——他們會休息。 他們會讀書、參加培訓(xùn)、重構(gòu)他們的軟件、學(xué)習(xí)一直想要學(xué)習(xí)的新知識等等。 當(dāng)測試人員的感冒好了，并繼續(xù)工作的時候，他們會發(fā)現(xiàn)在這段時間中開發(fā)人員并沒有創(chuàng)建大堆的工作等著他們。 沒有任何“死亡行軍”——他們只是繼續(xù)工作，并把項目從開發(fā)者那里拉過來。 然后，開發(fā)者也開始繼續(xù)工作，工作流程又開始流轉(zhuǎn)了。

　　看板的這些“神話”真的是神話嗎？ 你聽說過哪種看板神話呢？

　　查看英文原文：Myths of Kanban

it知識庫：看板神話，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。