精益，敏捷，Scrum的至關不錯的總結

---

詞彙表：精益，敏捷，Scrum，Sprint，看板

將Lean和Agile看做幾乎相同的事情，它們基本上是處理具備不少不肯定性的項目的好方法，這就是爲何成功的初創公司採用這種方法。 （有關精益，敏捷和Scrum起源的事實歷史，請參閱 此處 。）

Scrum和Kanban是最受歡迎的兩個敏捷項目管理框架。 它們有很大的不一樣 -  Scrum彷佛更經常使用，純粹的看板更少。 但實際上每一個人都使用他們本身的Scrum修改版本，這是鼓勵的，一般採用看板的元素（咱們也這樣作）。

Sprint是一個Scrum術語。 這是Scrum中的迭代週期。

因此： 精益≈敏捷> Scrum>衝刺

爲何精益和敏捷？

由於在這個不斷變化的社交和數字參與世界中，咱們須要更好的方式來開展業務和管理組織。

精益和敏捷是現代組織功能失調的兩個主要緣由的解毒劑：

• 瀑布項目管理 ，和
• 功能層級組織結構 。

瀑布與敏捷項目管理

當咱們想到項目管理時，咱們大多數人都會想象一個規範，按部就班的工做方法，並有良好的規劃和明確的目標設定。 這基本上是瀑布項目管理。

瀑布項目管理思想在咱們的文化中根深蒂固。 咱們的教育強調良好的準備和一步一步的審慎。 進展正在達到檢查點的標記。 瞭解咱們正在走上正軌可讓咱們感到溫馨和自信，同時也有助於咱們的教師和領導者更輕鬆地監控和管理。 這是一個很好的方法。 沒有瀑布，世界上許多現代奇蹟都不會存在。 全球各地的企業已成功擴展瀑布。 但瀑布有其侷限性：它在重複性和相對較低的不肯定性項目中運行良好。

現實是，世界充滿了不肯定性。 人類的行爲很難預測。 在您正在開發還沒有找到市場的產品的項目中，瀑布式項目管理是尋找適合產品市場的很是昂貴的方式。 您能夠負擔得起廢棄和重建產品的次數有限，而且在瀑布中進行另外一次產品構建迭代所需的時間會使您在競爭中處於劣勢。

敏捷成爲解決瀑布缺點的解決方案。 對於企業來講，它是一種更快，更具成本效益且風險更低的方法，能夠應對其業務的諸多不肯定因素。 在這個快速數字化轉型的世界中，再也不僅僅是創業公司必須應對擾亂市場。 跨行業的各類規模的企業都須要更好的方法來應對變化，敏捷是一種解決方案。

傳統與敏捷組織結構

委派工做對領導者和管理者來講是一項平常挑戰。 團隊之間的移交文化爲追求更高層次的企業目標創造了障礙。 敏捷經過從新定義的團隊合做和領導模式從根本上解決了這些組織挑戰。

在傳統組織中，領導和管理團隊負責決策 - 戰略和解決問題，預計答案未來自上方。 這給領導者「作出正確決策」帶來了巨大風險。 再一次，在這個快速發展的數字和社交時代，對任何人而言，很難一鼓作氣。 認識到解決問題是一個發現過程，敏捷鼓勵假設創建和實驗做爲一個總體組織練習。 簡單地說，更多的眼睛和集體智慧增長了「把事情作對」的機會。

精益與敏捷的精神

精益和敏捷是方法，而不是方法。 即便是敏捷的實施框架Scrum，也拒絕稱之爲方法論。 這是由於沒有一種嚴格的方法能夠解決全部不肯定性問題。 相反，你遵循某些共同的原則，或者能夠歸納爲精益和敏捷的精神，而且大量適應：

• 堅持不懈地追求產品市場契合度 （=爲客戶提供真正的價值）做爲總體組織的努力。
• 列表項目
• 創建，衡量，學習 ：接受不肯定性 - 這就是爲何咱們假設，測試和驗證咱們是否愈來愈接近客戶真正想要的東西。
  在它被釘住以前，以小增量進行並繼續迭代。
• 瞭解客戶，而不只僅是銷售和營銷或領導團隊，這是每一個人的工做。 認爲客戶不是別人的工做 - 這也是你的工做。
  所以，您被容許並被鼓勵與客戶一塊兒進行構建測量 - 學習實驗（即便您不是直接面向客戶），領導團隊將做爲僕人領導者，促進系統化的協做工做框架。
• 在Lean＆Agile中，沒有人會受到指責。 若是出現故障，咱們不會責怪某人，而是檢查產生故障並修復故障的系統。

實施Scrum

視覺層次結構

首先，您的企業願景須要以「鏈接」的方式與組織中的每一個人共享：您的員工所作的一切，一直到我的工做的任務級別，須要鏈接到願景。

這比人們想象的要難。 領導可以分辨和銷售願景，但這並不必定能讓每一個人都參與其中。 視覺分享練習其實是與您的員工一塊兒進行的視覺造成練習。

輸入Scrum：Epic，Story，Task是Scrum術語，可幫助人們思考產品或項目中須要構建或完成的全部關鍵事項，以實現共享願景。 根據設計，Scrum經過沿着視覺層次結構進行「Backlog」建立練習，將每一個人放在同一頁面上。

運行Sprint

Scrum是一個由時間限制的項目管理框架，由Sprint組成，根據團隊工做的特色，您能夠設置一個固定的工做週期，一般在一到四周之間。 （據您所知，另外一個流行的敏捷項目管理框架看板是一種「容量受限」的方法。）

咱們的想法是以小增量和快速迭代的方式完成工做，特別強調審查工做以幫助團隊實現目標。 假設構建和重複實驗是Scrum不可或缺的一部分，由於大多數項目都面臨不肯定性，而發現是關鍵（營銷是一個很好的例子 - 產品市場適合本身是一個發現過程）。

1.積壓 (backlog)

想一想可能包含在產品中或須要在項目中完成的全部事情。 踏上用戶旅程的道路：用戶故事是將客戶需求和需求置於背景中的一種很好的方式。

用戶故事：做爲[用戶]，我想[什麼]，因此[值]。

2. Sprint計劃 (Sprint Planning)

優先考慮和估計Backlog，決定在即將到來的Sprint中作什麼。

• 爲了估計完成每項工做須要多長時間， 規劃撲克 頗有用。
• 該 看板 （或Scrum的董事會）是Scrum的一個關鍵項目。 這是信息持久顯示，可視化和與團隊共享的地方。
  鼓勵定製以適應團隊的工做流程。
• 完成的定義 是Scrum中另外一個必須遵照的規則。 Done的定義不只僅是Sprint團隊成員在發佈前驗證工做的質量保證概念。
  它也是Sprint中發生的許多假設和實驗的測量和學習標準。
• Scrum中有兩個輔導員角色。 第一個是 產品全部者 ，「什麼」的人，第二個是 Scrum Master ，「如何」的人。 關鍵在於促進 -  Scrum團隊的生產力以「 速度 」 來衡量 ，或者他們可以以多快的速度完成任務，而且最有效的是促使團隊成員單獨和共同決定作什麼和作什麼，而不是而不是像傳統的等級組織那樣指導他們。

3.每日站立 (Daily Standup)

一個典型的Scrum團隊應該在3到9人之間 ，包括產品負責人和Scrum Master。 任何更大的，團隊的速度降低，因此最好分紅不一樣的Scrum團隊。

速度的關鍵在於團隊成員之間在進步和障礙方面的豐富溝通。 固定格式每日站立被證實是用於這一目的很是有效： 天天都 在 同一時間 ，爲 不到15分鐘 ，球隊在看板前彙集，而且每一個團隊成員經過回答如下分享他們的進步三個問題：

• ✓昨天作了什麼工做？
• ✓今天計劃作些什麼？
• ✓任何阻礙的方式？

或者，團隊也能夠按照看板上的完成和待辦事項的順序進行。 若是多個團隊成員參與每一個看板委員會項目的工做，這能夠是更好的格式。

在 每日站立不是狀態更新會 爲經理，找出誰是落後於計劃或給工做指令。 狀態更新僅提供快照 - 重要的是簽入流程。 站起來是團隊瞭解已完成的工做和剩下的工做，以便人們加快團隊合做。 若是有人被困，其餘團隊成員會幫忙。 若有必要，Scrum Master會從新調整工做流程，以便於移除障礙物。

4. Sprint評論和回顧 (Sprint Review and Retrospective)

在每一個Sprint結束時，Scrum團隊會召開兩次會議。

第一個是「什麼」會議：Sprint Review將討論由產品負責人推進的最後一個Sprint所作的工做。 此次會議一般伴隨着新版本和其餘成就的演示，歡迎來自組織其餘成員的成員加入。

第二個是「如何」會議：Sprint回顧展。 這是Scrum團隊成員反映和討論在上一個Sprint期間出現的障礙，即便事情進展順利，還有改進的想法。 Scrum全部者經過確保重點仍然是修復流程而不是人們責備來促進此會議。

在兩次會議結束時，團隊更新Backlog並計劃下一個Sprint。

Scrum的常見陷阱

‣無靈魂的Scrum：衝刺爲迷你瀑布

一般，用戶故事成爲迷你規範文檔。 而後，執行編碼或任何活動，而後進行UAT（用戶驗收測試）或其餘籤核過程。 乍一看，這聽起來並不錯，許多團隊陷入了這個陷阱。

問題是，這只是以迷你瀑布風格運行的迷你項目。 分析，設計，編碼和測試以順序方式完成，可能跨越多個Sprint，最有可能做爲功能之間的移交過程（例如BA（業務分析師）>開發人員> QA（質量保證））。

精益與敏捷是關於不肯定性的發現。 在Scrum中，構建 - 度量 - 學習週期被設計爲在Sprint中發生，而且從事假設，MVP（最小可行產品）構建和測試的團隊成員須要彼此儘量地工做; 即跨職能團隊合做。 工做沒必要是順序的 - 若是某些東西不起做用或缺乏標記，那麼徹底能夠進行設計更改和修改，或者作出有意識的決定以採用不一樣的方法; 即調整和微型旋轉。 迷你瀑布擊敗了迭代的目的，只實現了Scrum的小增量優點。

‣領土Scrum

敏捷如今在軟件開發團隊中很常見。 問題是，在許多組織中，只是運行Scrum的開發團隊，有效地在組織內建立了一個島。

結果是開發團隊與組織其餘部門（即銷售團隊）之間的交流文化：「咱們按照您的規範將產品整合在一塊兒，如今就去銷售它」。

傳播組織範圍敏捷的關鍵是讓人們將敏捷視爲一種更普遍的溝通，合做和共同創造概念，而不只僅是一個項目管理框架。 問一個問題，若是咱們內部沒法很好地鏈接，咱們如何與客戶創建聯繫？ 這應該會促使持續的客戶價值創造和產品市場適應各個團隊的思惟。

在組織範圍的敏捷的實際實施方面，銷售和營銷的Scrum能夠與開發團隊的Scrum並行運行。 最終，最好的目標是轉向跨職能的Scrum團隊，其中開發，銷售和營銷職能都在每一個Scrum團隊中，並與產品或客戶項目保持一致。

‣Scrum Master in Command

在每日站立期間，若是人們向Scrum Master提供狀態更新，而且Scrum Master告訴人們該作什麼，那麼你就是在擊敗Scrum的目的。

Scrum是一種系統性的努力，可使組織脫離管理者 - 工做者模式。 在解決問題的企業中，指揮領導模式失敗 - 它依靠領導者獲得全部答案，使領導者本身成爲障礙。

在敏捷組織中，你試圖從人們身上帶出全部「合做」 - 合做，協做，協調，共同創造，溝通，聯繫等等。 Scrum Master的做用是保持「co」流向側面，而不是像指揮同樣垂直。

咱們還必須瞭解「工人」在經理 - 工人模式中的被動安慰：接受工做指示是使人欣慰的，由於您沒必要考慮緣由和方法，而且您不受決策責任的影響。 Scrum以多種方式解決了轉變爲自主工做模式的痛苦; 小型構建模塊方法使工做更容易管理，每日站立是爲了讓團隊成員在遇到困難時互相幫助，而且不責備人的文化鼓勵我的承擔實驗風險。

‣衝刺直到你掉落

若是一個領導者設計「衝刺」做爲一種系統的手段，令人們在永久的高度戒備中儘量地努力工做，那只是危機的習慣性管理，或者更糟糕的是，剝削勞動力。

一個不那麼邪惡的領導者可能將「衝刺」定位爲相似於賽道或游泳中的間歇訓練。 他可能會說，經過持續不斷的緊張工做，團隊將可以突破其表現的界限。 但這會給團隊成員帶來精神疲憊的風險。 在如此高壓力的環境中吸引和留住人才是很難的。

在一次Sprint以後，下一個Sprint當即開始。 若是團隊開始嘗試從最後一個恢復新的Sprint，顯然他們已通過度踱步。 Sprint必須以可持續的速度運行，不須要Sprint之間的休息或恢復時間。

實際上，Scrum Sprints可能不該該被稱爲sprint。 它應該更像是慢跑或其餘東西。 是的，你確實但願你的團隊的「速度」增長（在Scrum中咱們使用「 Burn Down Charts 」來衡量這一點），但這並非你追求的終極速度。 你追求的是平均速度的提升，即在相同的時間內覆蓋更多的距離。 正如任何長跑運動員都會證實的那樣，找到合適的節奏和節奏是邁向遠方的關鍵。

採用精益和敏捷並不是易事。 精益和敏捷背後的意識形態是理性的，對大多數人來講都是有意義的，可是將其付諸行動須要思惟方式的轉變和許多破碎的習慣。 雖然若是作得好，精益和敏捷將帶來使人難以置信的生產力，積極性和突破組織。 在Lifecycle，咱們很是瞭解組織行爲和黑客攻擊方法，以推進成功的精益和敏捷組織轉型。

Agile & Scrum Basis

• Comprehensive Scrum Guide
• What are Scrum's Three Pillars?
• What is Agile Software Development?
• Scrum in 3 Minutes
• What are the 5 Scrum Values?
• Classical Project Management vs Agile Project Management
• Why is Scrum Difficult to Master?
• What is Velocity in Scrum?
• What is Agile? What is Scrum?