全文共3518字，預計學習時長9分鐘

圖源：unsplash

大多數使用Scrum的公司都會花很多時間討論速度，並設計提高速度的方法。開發速度變成了一個不可思議的、幾乎是神話般的數字，開發人員在每個Sprint中都必須追求這個數字。

在速度被打破的公司裡充斥著這樣的評論：

· 為什麼我們這個Sprint的速度低於上一個Sprint? 你能提供一個合理的解釋嗎?

· 速度停止增加。也許該僱傭一個新的Scrum管理員了?如果一個Scrum Master不能提高速度，那還有什麼意義呢?

· 我們並沒有在Sprint中完成所有的故事。怎樣才能保證下次能全部完成呢?

對更快速度的競爭是許多開發人員討厭使用Scrum的首要原因。你永遠沒有足夠的時間來喘口氣，停下來反思一下工作，大家變得痛苦不堪。程式設計師感覺自己像流水線上的工人一樣被對待，他們需要儘快完成罰單。在任何時候放慢速度，很快就會受到懲罰。

速度崇拜被認為是必要的，開發人員是昂貴和稀缺的資源，我們需要榨乾他們的價值，速度是執行這種對金錢思考的最大作用的完美工具，高速度一定意味著我們從寶貴的資源中獲得了物有所值的價值。

不幸的是，事實並非如此。

速度統治一切

圖源：unsplash

速度成為了統治它們的唯一數字。每一次衝刺，數字看起來都很棒。但是，這種數字上的美麗帶來了高昂的代價——團隊中的每個人都很痛苦。團隊意識到讓人們滿意的唯一方法是速度遵從宇宙的法則：不斷膨脹。他們知道這不是能夠永遠保持下去的東西。

被速度崇拜洗腦的公司不會尊重軟體工藝，也不會尊重價值的交付。所有的人關心的是這個愚蠢的數字，以及什麼時候他們可以期望自己的特效能夠實現。技術債務拖累你了嗎？停止抱怨，這是一個假想的朋友，阻止我們提供更多的功能。

開發人員是流水線上的工人嗎?開發人員是否需要定期進行速度測試，以確保他們能夠不斷地推出新特性?提供更多的功能總是更好嗎?我相信所有這些問題的答案都是一個響亮的“不”。

過於關注Scrum團隊的速度表明公司對Scrum的目的一無所知，事實上，速度崇拜毫無意義

1.輸出的結果比輸出更重要

Scrum的目的是幫助你交付可能具有最高價值的產品。使用速度來度量開發人員的輸出很容易，但這並不重要。更多的功能並不意味著更多的價值或更好的產品。

請允許我用一個日常的例子來說明。我可能會花8個小時寫一篇只有100次瀏覽量的文章，有時我在火車上一小時內寫一篇文章，瀏覽量超過1萬次。在最好的情況下，努力和價值之間的關係是模糊的。

讀者不知道我在一篇文章上花了多少時間。他們只關心作品帶給他們的價值。客戶也一樣——他們不會關心開發人員在構建一個特性上花費了多少精力。

停止優化開發團隊花費的工作量，開始優化特性對客戶的影響。交付價值是一件棘手的事情。交付價值需要實驗、嘗試和錯誤，以及反思的空間。通過推動團隊優化功能交付，你扼殺了創造一個對客戶重要的產品所必需的創新和學習。

團隊是否為客戶和企業創造了有價值的結果?如果他們能通過減少交付來做到這一點，那就是一種勝利。

2.速度被有意地排除在Scrum之外

圖源：unsplash

速度不是Scrum的一部分，它是可選的和補充的實踐。Scrum團隊可以決定採用或拒絕開發速度。自組織Scrum團隊可以自由地停止進行計劃撲克遊戲，不再報告他們的開發速度。

速度被視為Scrum的同義詞，這是一種謬誤。Scrum讓你決定如何處理評估和吞吐量。你有無數可行的選擇：#不估計、t恤尺寸、理想的日子、能力驅動的衝刺計劃，等等。如果速度拖著你往下走，請拋棄它，只有Scrum團隊才能決定如何評估和預測。

3. Sprint的Backlog除了開發團隊之外，沒有人關心

Sprint通常被視為壓制開發人員的一種方式。它被視為一種工具，用來迫使團隊儘可能多地完成工作。這種想法是錯誤的，只有開發團隊被允許在Sprint期間進行更改。以下是Scrum指南中的措辭：

· Scrum Guide, 2017年11月：只有開發團隊可以在Sprint期間更改其Sprint Backlog。

· Scrum Guide, 2017年11月："短跑進行時"。那麼衝刺什麼時候開始，什麼時候結束呢?一個新的Sprint在前一個Sprint結束後立即開始。

因為Sprint是所有Scrum事件的容器，所以第一次Sprint從第一個事件開始：Sprint計劃。第二個Sprint和後面的任何Sprint都在Sprint的時間盒到期時開始——基本上，你總是在衝刺。

簡而言之，只有開發團隊可以更改Sprint中的內容，即使是在Sprint計劃期間。認為Sprint存在的目的是向開發人員施加壓力的觀點是沒有根據的。只有開發團隊自己施加壓力，開發人員才會在Sprint中感受到壓力。完成了多少工作，最終會產生速度，這完全由開發團隊決定。

4.每一次衝刺所做的唯一承諾就是目標

圖源：unsplash

想象一下，即使團隊在Sprint中增加了太多的工作，他們也不會承諾完成新增到Sprint Backlog中的所有工作。開發團隊承諾在每個Sprint中只完成一件事：Sprint目標。

這對開發團隊意味著什麼?只要開發團隊沒有將Sprint目標置於風險之中，Sprint Backlog就是完全靈活的。與Sprint目標不相關的Sprint待辦項可以被帶到下一個Sprint，沒有任何損失。實現Sprint目標所需的計劃和工作可以在任何時候進行討論和修改。

實現目標比按照計劃或完成特定的工作更重要。沒有對速度的承諾，只有對範圍可變的目標的承諾。

5. Scrum已經為交付創造了足夠的緊迫感

Scrum已經包含了足夠多的裝置，這些裝置給開發團隊帶來了健康的壓力，讓他們在每個Sprint都交付一個工作產品。“衝刺”、“衝刺計劃”、“每日Scrum”和“衝刺評審”都是為了這個目的。即使是Sprint回顧也是為了瞭解你可以做得更好，以便下次交付產品增量。

它們的存在使得對速度施加額外的壓力是不必要的，甚至是有害的。在每日的Scrum中，每個工作日的緊迫性都被灌輸以滿足Sprint的目標。做好Scrum需要紀律和專注，給你的團隊施加太多的速度壓力只會埋葬你的團隊，讓他們走向失敗。

公司應該對他們的開發者表現出更多的信任和尊重

迷戀速度是特徵工廠思維模式的一個明顯標誌，對速度的關注表明該公司相信提供更多的功能總是更好的。不幸的是，更多的特性並不意味著交付更多的價值。為了創造價值，你需要時間去試驗、創新和反思。通過在建築上施加太多的壓力，你就剝奪了創造和弄清楚什麼才是真正會產生影響的必要的喘息空間。

不要過分關注開發速度，這個問題事關尊重：我們是否相信開發人員是有能力的，並且相信他們能夠在沒有開發速度之劍的情況下交付產品？Scrum已經包含了足夠多的工具，可以在每個Sprint中灌輸一種緊迫感來交付有價值的東西。

圖源：unsplash

Scrum給予開發者的權力比大多數人想象的要大得多。不要讓對Scrum自私錯誤的解釋把你放在一個想象的盒子裡，打破這個框框，使用Scrum為你服務，不要被公司的速度廢話所愚弄。

Scrum通過設計給了開發人員很多權力。通過設計，Scrum希望授權從事這項工作的人建立他們自己的規則。使用這種力量以可持續的速度工作，並在你認為合適的情況下處理技術債務。

如果你在一家餐館當廚師，你做飯時打掃廚房不需要得到許可。為什麼開發人員需要獲得許可來清理他們的程式碼?如果是有必要做的工作，你不需要徵求任何人的同意。

只要你能像承諾的那樣交付Sprint目標，任何人都會被你為了讓產品給客戶和業務帶來價值而做的其他事情所困擾。沒有人應該關心你完成了多少待辦事項，只要你交付了一個滿足Sprint目標的產品增量。

不要讓自己被速度所嚇倒，把自己放回到屬於你的駕駛座位上，不要讓那些不知道你在做什麼的人來決定你做了多少工作。作為一名專業人士，你很清楚自己應該得到公司的尊重和信任。

一起分享AI學習與發展的乾貨

歡迎關注全平臺AI垂類自媒體 “讀芯術”

（新增小編微信：dxsxbb，加入讀者圈，一起討論最新鮮的人工智慧科技哦～）