[譯] 敏捷、Scrum和看板：這些詞究竟是什麼鬼？

當一個軟件開發人員聽到關於「新的JavaScript框架」或者「新的IDE」的新聞時，他不須要問多的問題的就能明白它是什麼。但若是他聽到的是」新的敏捷框架「時，他極可能會點點頭，僞裝他知道它是什麼，而他會有一個且惟一一個問題：」敏捷框架「究竟是什麼鬼？


在現代軟件開發環境中，咱們日漸聽到像」敏捷「、」scrum「和」看板「這些詞，而且他們常常會被錯誤地使用。在這篇文章中，我將會試着解釋並澄清其中的一些詞。

敏捷

若是你想在人羣中脫穎而出，當談論工做進展時你應該在每句話中都使用」敏捷「這個詞。它的範圍很是之廣，不責成你去很是瞭解你正在談論的主題，而且它真的是一個很好的形容詞或副詞：」敏捷思考「、」敏捷方法「、」根據敏捷原則「。但」敏捷「到底意味着什麼？

「敏捷」引自」敏捷軟件開發「，開發方法遵循敏捷原則。而」敏捷原則「又是什麼呢？能夠看下打下敏捷發展基礎的敏捷宣言：

         

         人和交互 重於 過程和工具

能夠工做的軟件 重於面面俱到的文檔

         客戶合做 重於 合同談判

   隨時應對變化 重於 遵循計劃

敏捷原則鼓勵能夠工做軟件的持續交付，團隊中緊密的溝通，和對需求改變的高度適應。若是在工做中你遵循這些價值和原則，你能夠說正在敏捷環境中工做。因此，敏捷軟件開發不是一個方法論，它僅僅是一系列不一樣的方法、框架和遵循相同原則的技術。能夠說，」敏捷「是思考和做出決定的一個框架。

敏捷 是思考和做出決定的一個框架。

可是爲何在咱們的工做中遵循這些原則那麼重要？

宣言和這些原則是爲了應對軟件開發挑戰而從數十年的演進中搜索出最好的解決方案的結晶。經歷過了70年代、80年代和90年代，全世界不一樣的開發人員和團隊已經對工做方法和解決問題的方法做出了實驗，發明了不一樣的的框架和技術（例如scrum和極限編程），甚至並行出現了一樣的想法。最後，在2001年1月，17位開發人員聚在了一塊兒併爲這些多樣的想法和經驗找到了共同的特徵。這就是宣言被創造的過程。

敏捷宣言是數十年出現的不一樣的經驗和可實現的解決方案的結果。

Scrum

若是你談論」敏捷「方法殊不知道他們意味什麼，可能會出差錯並在知道」Scrum和其餘敏捷方法「的談論者面前說一些暴露本身的東西。

Scrum不是一個方法論，儘管咱們聽到它的次數比權力遊戲的被殺的人數還要多。Scrum不會爲每個問題都提供答案，也不會爲響應每個你面對的場景提供清晰的過程。由此做爲不正確解釋的結果，大部分scrum實現也都是錯誤的：團隊得不到價值。這極可能致使了關於scrum最愚蠢的聲明：」scrum沒用「。

scrum是什麼？Scrum入門中的定義是：

一我的們能夠放置複雜自適應問題進內的框架，當清晰地和創造性地儘量交付最高價值時。

因此它是一個框架，而且像其餘可能的框架同樣，常常地，被錯誤地使用。高效地使用scrum不只僅要求適應scrum設置的結構，還要有深入的理解以及在貫穿整個團隊中對於敏捷原則的感恩。

scrum包含如下角色：產品負責人，ScrumMaster，和開發團隊；四種儀式：計劃會議，每日站會，Sprint評審，和Sprint回顧；以及三種輸出物：產品Backlog，Sprint Backlog，和產品增量。它以咱們稱之爲sprint的按期時間幀來組織。sprint應該持續在一週到四周之內。

產品負責人，即PO，負責引導項目的方向。當新的任務和特性決定後，PO把他們添加到產品Backlog。一個sprint以開發團隊從產品Backlog中選擇開始工做的任務以及計劃怎麼實現他們的計劃會議爲起點。接下來的是開發，在這個過程當中開發團隊使用Sprint Backlog來追蹤進度並在每日站會上碰面以便同步活動和在有須要時調整計劃。此開發的結果應該是產品增量，一些能夠應用到產品或者立刻發佈的東西。在sprint的最後，在爭論產品Backlog是否須要更多長遠的改變的Sprint評審上，這個產品增量將會展現給產品負責人。此後，整個團隊將參加討論工做進度和如何才能提升它的Sprint回顧會議（也可稱之爲發佈會議）。

這裏只是寥寥數語，若是須要更多關於scrum如何工做詳細的解釋，可查看此文章。

學習和理解scrum很容易，但適應它則很難。有不少緣由使得這個框架對於項目來講也許是又或者不是一個好的匹配。它一般須要大量的改變，不只僅是天天的開發，還有文化角度。scrum最適合於維持好久時間幷包含不一樣類型專家的複雜產品的開發。

爲何scrum如此流行，以及爲何相比於傳統的瀑布流模型它更有優點？簡單來講，是由於它爲產品或者客戶交付了更多的價值。使用諸如瀑布流這樣的」重量級「方法，在恐怖故事比比皆是的數月內沒人能看獲得任何東西。使用scrum，這種狀況是不會發生的。

scrum所有都是關於交付給終端用戶的價值。若是你真的使用scrum，你須要在每個sprint交付一些有價值的東西。價值應該能被評估，而且在接下來的迭代中交付更多的價值的目標下，團隊也強制要求進行障礙檢查和適應調整。

在大部分軟件開發中，咱們並非在建設摩天大樓；咱們不須要在開始前要準備好整個計劃，並嚴格執行這個計劃直到最後。咱們正在開發軟件，而且咱們有能力針對不一樣的場景作出調整以及在開發過程當中改變產品需求。很長一段時間內，很好開發人員把這看做是第八重罪（eighth deadly sin），但從產品的角度它對於優化可預測性和風險控制有着巨大的好處。scrum圍繞着這個能力發展了起來，而它的實現則提供了一種處理必要變化的可靠且高效的方式。

不少技術與scrum配合使用：計劃撲克，結對編程，測試驅動開發（TDD），行爲驅動開發（BDD），和其餘。他們不只是scrum的一部分，仍是兼容的技術。與scrum一塊兒常常被提到的一個方法是看板，而且對於這二者相互之間的關係有着大量的困惑。

看板

當你談論scrum和看板時，人羣中常常會問到的一個問題將會是，」哪一個更好，scrum仍是看板？「你不知道如何做答由於這就像把蘋果和橙子比較，或者問，」哪一個更好，薄煎餅仍是啤酒？「 二者都不錯。

看板是在未超過團隊成員負荷的同時致力於即時交付的一個簡單方法。它和scrum中在最後交付最大化價值的目標同樣，但它比scrum更加靈活。

看板不是軟件開發社區發明的。實際上，它來源於豐田的製造過程，而且已普遍應用在其餘領域。沒有你須要遵循的嚴格過程，也沒有你須要實現和使用看板的嚴格方式，而是，有一系列原則和實踐你能夠從中選擇以適應你的須要。但在軟件開發中有一個最常使用的看板實現包含了看板白板的使用，它包含了表明工做狀態的列，和任務。

列表明着開發過程當中各個任務的狀態。簡單的示例包含着這三列：」待辦「，」進行中「和」已完成「。因此，任務能夠添加到」待辦「，當任務開始時移到」進行中「，而且移到最後一列時被看成爲」已完成「。固然，它也能夠更加複雜：

「Backlog」 --> 「定義規範」 --> 「準備開發」 --> 「開發」 --> 「code review」 --> 
「測試」 --> 「部署」 （--> 「沒人使用」 --> 「移除」）。

每一列都有其子列；例如，「開發」能夠劃分爲「計劃」和「編碼」；「測試」能夠劃分爲「單元測試」和「集成測試」，等等。若是適當的話，列也許專門針對於專家。團隊根據須要定義列和狀態。每個「拉」的理念，僅當需求是即時時任務才能進入此工做流。

這個白板的目的是爲了可視化工做流，這也是看板中首要關鍵的實踐。實際上，看板也能夠一點也不用白板！它能夠是在Google表格中經過不一樣的背景色表明任務狀態的簡單的任務列表，或者多是甘特圖，圖，表。。。它甚至能夠是辦公室中一系列的桶，每一個桶表明着任務不一樣的狀態，而球則看成是任務來使用。只要能可視化工做流以及提供整個過程的透明度便可。

另外一個重要原則是減少你努力的批次。簡單地，這意味着避免多任務。這意味着減小你同時工做的任務量。若是你的團隊中有三個設計人員，那麼團隊將會在「設計」這一列中設置最大的任務量爲三。

像scrum同樣，看板也在過程當中把團隊視爲最重要的計量。但它並不像scrum那樣建議角色，而且你能夠保持既有的角色以避免對已有的流程做出改變。針對持續提升相同的標準：看板一般喜歡你學習和持續提升，卻不像scrum的sprint回顧那樣爲此指定具體的事件。

我應該使用哪一個？

scrum和看板並非相互排斥的但也並不是能夠徹底兼容。在scrum中，有定義好的角色，而看板則會說，「搞什麼鬼，保持你當前的角色和職責就能夠了。」scrum會強制你改變工做的方式；看板則容許你從既有的流程開始。在scrum中，框架會對事件制定一個清晰的時間表；在看板你並無事件。然而，他們也在着大量的相同之處：二者都是以價值爲中心，團隊成員被尊稱爲系統中的「老大」，而且本質上，他們有着相同的使命：不斷消除浪費並消除障礙。

但問題，「在我特殊的項目和特殊的團隊中我該使用什麼？」意味着更多的場景。看板不要求那麼多的流程和文化改變，且在大多數狀況下，相比scrum它更容易適應。另外一方面，scrum明顯地提供了更多引導流程的結構，以便當不少人都在相同的頁面時能夠消除大量的開銷。

但這二者之美都不是一系列嚴格的規則。沒什麼能夠阻止你爲本身拾取和選擇最好的scrum元素，例如每日站會和回顧。也沒理由你不能將看板白板和scrum結合起來。

scrum已被證實當整個團隊能很好理解它時它是一個高效的框架。然而，在個人經驗中，我發現和某些客戶在scrum中一塊兒工做時很困難。針對合適的scrum實現而要求的過程和文件變化太多太多了（特別當處理相信他正在創造一個谷歌的人時）。另外一方面，看板更爲靈活且不強制人們做出改變。有些做者也說看板是通往敏捷性的一個好途徑，且比scrum提供更容易的實現。其餘人則說使用scrum應該最終會引入看板。

真相則是每一個項目都是不一樣的，沒有放之四海而皆準的解決方案。做爲一個項目管理者，由你來決定對於你的團隊什麼最有用。

本文翻譯做者爲：dogstar，發表於開源中國我的博客；歡迎轉載，但請註明出處，謝謝！