[TEAP早期試讀]敏捷武士之敏捷簡介

圖靈社群按：TEAP是什麼？
TEAP是什麼？TEAP是Turingbook Early Access Program的簡稱，即早期試讀，它公佈的是圖靈在途新書未經編輯的內容。一本書的翻譯週期約為3到6個月，在這麼長時間內，譯者與讀者沒有溝通和交流是一件不可想象的事兒。通過TEAP，讀者可以提前閱讀將來才能出版的內容，同時譯者也能收穫寶貴的反饋意見，以便改進翻譯，提高質量。

本書為《敏捷武士：看敏捷高手交付卓越軟體》，有問題可以在這裡留言，也歡迎@譯者E路向前--北京，本篇內容選自書中第1章。

想要每週都能交付一些有價值的東西，都要做哪些方面的工作？

通過讓客戶親眼見證軟體交付的正確方式的尋找過程，我們就會發現以前所提供給客戶的服務有多少是徒勞無益的，並且我們還不止一次錯過了真正重要的東西—定期交付可工作的軟體。

讀完本文，你會更深刻地理解敏捷計劃，並瞭解我們是如何衡量敏捷專案成功與否的，以及你如何只用三條簡潔的準則就能從容而優雅地應對最緊張的期限和最艱難的專案。

每週交付一些有價值的東西

暫時忘記一會兒敏捷，假設你就是客戶。資金和專案可都是你自己的，你已經僱傭了頂尖的團隊去交付你想要的軟體。

什麼東西能讓你相信你所僱傭的團隊正在進行實際交付？是一摞摞的檔案、計劃和報告？還是每週都定期交付了你認為具有最重要特性並且可工作的、測試過的軟體呢？

所以當你開始以客戶的視角來審視軟體交付時，你也就步入正軌了：

1. 你要將大問題拆分為許多小問題：

一週時間相對較短，你不可能在一週內完成所有任務。要想搞定一切，就得將棘手的大問題分割為更小、更簡單、更易於管理的小問題。

2. 你要將你的注意力集中於最重要的事物，心無雜念。

我們所交付的傳統軟體專案對於我們的客戶很少有或者說幾乎沒有什麼價值。

當然，你需要文件，也需要計劃。但是它們僅支援一樣東西---可工作的軟體。

通過每週都交付一些有價值的軟體，你會逼迫自己變的更精益，放棄任何不能增值的工作。這樣你就可以只帶上必需品輕裝前進了。

3. 確保你正在交付的東西可以工作。

每週都交付一些有價值的東西意味著你要交付更好的軟體產品。這也就意味著你要進行很多測試——儘早、經常性的測試。

不斷摒棄一些東西，直到專案截止，這時日常測試會成為你的一種生活方式。你就是問題的終結者

4. 尋求反饋

你要定期停下來，向你的客戶徵求一下你的目標是否正確，否則你怎會知道是否達到預定目標？

反饋好比是汽車的大燈，能夠穿透你前方的霧靄，即使你在高速公路上把車子開到100公里/小時也仍然會安然無恙。沒有它，你的客戶會就會失去對汽車的控制—而你也會栽在溝裡面。

5. 必要時你可以改變過程

專案會有偶然情況發生，事情也會發生變化。一週中最重要的事情也可能被移到下一週。如果你建立一個計劃後只是循規蹈矩，那麼當實施計劃時你就無法做到收放自如、隨需應變。當現實破壞了你的計劃，你要改變的是計劃而不是現實，其原因也正是如此。

6. 你要勇於負責

如果你承諾每週都交付一些有價值的東西，然後向你的客戶展示你將他們的錢用在了哪方面，這時你要勇於負責。

• 你需要控制質量。

• 你需要控制進度。

• 你需要設定期望值。

• 你需要花錢時就像在掏自己的錢包，要格外吝惜。

我這樣說是否表明每個人最終都應該以這種方式工作呢？不可能——這道理就好比多數人的飲食習慣並不恰當，並且還缺少運動。

每週都交付有價值的東西並不適合膽怯者。它會讓你成為公眾注意的焦點，這在以前是不可能的。你會無處可藏。你要麼做出些有價值的東西，要麼什麼都別做。

但是如果你喜歡可見性，專注質量並且對執行有著非常強烈的渴望，那麼在敏捷團隊中工作會讓你個人受益匪淺，樂趣多多。

如果每週一付讓你覺得壓力過大，那也不要擔心—這沒什麼關係。多數敏捷團隊開始時都是每兩週交付一些有價值的東西（大團隊會每三週一次）。

這只是個比喻，讓你設想一下要定期給你的客戶提交可工作的軟體，然後得到一些反饋，必要時再改變程式。就這些。

現在讓我們先審視一下敏捷計劃

敏捷計劃如何生效？

計劃一個敏捷專案與為一個忙碌的長週末假期準備東西沒什麼兩樣。我們不用待做事項列表和任務這兩個詞，我們換兩個有趣的名字：總故事列表和使用者故事。

在敏捷中，總故事列表就是你的專案待做事項列表。它包含了所有的高階別特性（使用者故事），而這些正是你的客戶希望在他們的軟體中能見到的。你的客戶對其設定優先順序，你的開發團隊會對其進行估算，而這正是形成你專案計劃的基礎。

敏捷專案中的核心就是迭代—在一週至兩週內選取你客戶的最重要的故事，然後將其轉化為可執行的、測試過的軟體。

你的團隊成員通過測算團隊速率來決定需要承擔多少工作（每個迭代週期你可以完成多少）。通過追蹤你的速率並預測未來你所能完成的任務量，你的計劃就可以實事求是，從而避免你的團隊誇下海口。

如果你和客戶面臨的任務過多，那就先做你唯一能做的事——少做一些。在範圍方面要靈活處置，也就是你要學會平衡你的計劃，並將你的承諾變為現實。

當現實與你的計劃相悖時，就應該改變計劃。適應性計劃是敏捷交付的基石。

敏捷計劃也就以上這些了，我們將在第八章中對其進行更深入的探討。

如果犧牲不可避免，你還是順其自然吧。不過你要確認你的犧牲物有所值，而不是因為你在一年前的業務評估中所做出的不切實際的承諾。

確實，人們會做出不切實際的承諾，也經常要求團隊去盡力而為。但這並不能解決問題。“靠奇蹟去管理”這種假象如果一直持續下去，會成為一種糟糕的專案執行方法，要是這個期望值是你和客戶一起設定的，那就更糟糕了。

有了敏捷，你就不需要這些奇蹟了，因為從開始階段你就會與客戶開誠佈公地配合工作—對客戶直言不諱，讓他們自己做出範圍、資金和資料方面的明智決策。

這要看你的選擇了。你可以總是想著“奇蹟總會出現”來工作，或者你也可以與客戶一同制定出雙方都認可的計劃。

還有一些事你要知道：敏捷是如何定義“完成的事情”

“完成”的意思就是“完成”

假設你的爺爺奶奶僱傭你鄰居的小男孩去將他們草坪前的葉子打掃乾淨並裝進袋子。當這個小孩完做了如下工作後，爺爺奶奶會認為他就把活幹好了嗎？

• 製作了一份如何打掃院子的計劃報告？

• 是否有漂亮的設計？

• 是否製作了一份詳盡、面面俱到的測試計劃？

不可能！這個小孩要是不把樹葉掃乾淨、裝袋並且在屋後給葉子找個歸宿的話，他一個子也得不到。

在敏捷中，我們使用同樣的定義。在敏捷中，交付一個特性就意味著要完成所有必須的任務才能生產出可交付的程式碼。

分析、設計、編碼、測試和使用者體驗（UX）—東西都在這裡了。這不是說我們必須要把首個版本特性搞的花裡胡哨，或者我們要將最新版本的作品放在每個迭代的最後才可使用。但是我們的態度是：要做就得做好。

如果作品還不能交付，那就是沒有完成。這也是為什麼作為敏捷開發者，我們必須要堅持敏捷原則並要接受如下三條簡單準則。

三條簡單準則

下面就是三條簡單的專案準則，一旦接受這些準則，我們就可以去除多數我們在軟體專案中常見的戲劇性效果和機能障礙。

1. 在專案的初期不可能收集到所有的需求。
2. 不管你收集到什麼需求，最終它們肯定都會發生變化。
3. 需要做的事情太多了，總會超出時間和金錢的允許範圍

接受第一條準則意味著即使沒有萬事俱備，你仍大膽地開始了你的旅途。你意識到要自己去發現需求，如果等著一切都收集完畢才開始，那永遠也開始不了

接受第二條準則意味著你不再懼怕變化或者刻意避免變化。你知道變化無法避免；你只能承認它。必要時你會調整你的計劃後再繼續下去。

接受了第三條準則，當你的待做事項列表超出你的交付時間和資源時，你不會再有壓力。對於任何有趣的專案來說，這都是正常狀態。你只是做了你唯一能做的事—你設定了一些優先順序別，先完成最重要的任務，將最不重要的留到最後。

一旦你接受以上這三條簡單的專案準則，大部分軟體交付方面的緊張和焦慮感都會消失。

然後你就能夠以集中而清晰的思路去思考和創新了，而我們的行業多數都失去了這種能力。

你要記住，沒有任何書籍或方法是萬能的，你仍需自己去思考。每個專案都是不同的，雖然一些原則和實踐永遠不會出錯，但是如何對其進行應用仍然取決於你特有的情況和環境。

相關閱讀：好書短評之《敏捷武士：看敏捷高手交付卓越軟體》