預示敏捷方法走偏的15個標誌——第1部分

【編者按】誤解和“最佳實踐”可能會讓你的團隊原地打轉，無法高效產出程式碼。本文主要介紹預示著敏捷方法走偏的15個標誌，作者為 Steven A. Lowe。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。

要趕時髦卻掉溝裡的情況很常見。這條準則在敏捷開發中表現得尤為明顯。很多公司因為敏捷的好處——容易變更、週期縮短、進化構架，等等，而轉投它的懷抱，結果最後公司最好的敏捷實踐者紛紛離職，剩下的人員卻沒有能力修復開發過程中的問題。

大部分敏捷操作的問題並不在于敏捷概念，而在於敏捷方法(Agile)。敏捷並不是一種方法，把它當做方法，就把開發過程與哲學和文化混在了一起，這樣做只會回到瀑布模型，甚至更糟的情況。

幸好，辨別敏捷方法出錯的標誌並不難，還可以採取行動重塑和諧。本文列出了敏捷方法走偏的15個標誌，任何一個都可能讓你軟體開發的前期努力付諸東流。

1、實施敏捷與敏捷實踐

敏捷以態度為先。如果你的公司強調實施敏捷，而不是敏捷實踐，那麼你們一開始就走錯方向了。敏捷是一個範例，是軟體開發方法的思路轉變。具體的技巧和儀式稍後再說，而且重要性相對較低。重點在於敏捷實踐，擁抱和使用敏捷宣言中列出的理念，你們自然而然就在“實施”敏捷了。

一定要認真閱讀敏捷宣言，裡面的內容都是字斟句酌才定下來的。想一想其中的含義：去除無用的儀式、管理和書面工作，專注於程式碼和快速反饋週期，自行組織、自行檢查、自行優化。這就是變革。實現宣言列出目標的具體行動則需要不斷髮展進化。

如果你們強制所有團隊遵循一刀切的通用敏捷“流程”，這種做法是錯的。這種“標準的”敏捷流程的想法是矛盾的，因為敏捷意味著持續不斷地適應和改進。

要想補救，不要忘了你們的主要目標是交付可用的軟體，而不是遵循某個方法；沒有方法是萬能的，適用於所有專案和團隊。因此，放手讓每個團隊自行操作，並修正和改進實踐。

2、將故事分值當成目標

使用者故事是敏捷的一個重要方面，從使用者角度描述軟體特徵的需求。故事被賦予分值，以此來預估完成故事所需要的工作量。

這些故事分值既不是承諾，也不是目標。它們並沒有本質意義或衡量標準，只是團隊成員就專案複雜程度和團隊能力達成的非正式共識。

你的團隊的三分故事可能是其他團隊的五分故事。將故事分值當做成功的衡量標準，破壞了它作為預估方法的價值，並且會導致“鑽制度空子”來假裝成功（已達到速度 X），實際上並沒有成功（交付可用且有用的軟體）。

解決方法很簡單：與產品負責人（使用者更好）在有用目標和衡量目標上達成共識。不要誤將要估計的標準或要計劃的規則跟“成功”混為一談，只有交付了價值才叫成功。

3、比較團隊或成員的速度

沉迷於指標幾乎是大部分程式設計師的第二天性。但是，如果你的團隊將速度——迭代計劃中團隊所用的每次迭代的故事分值衡量指標——當做比較點，你們就錯了。

再次說明一下，速度只是用於預估的中性指標。對比團隊速度毫無意義，因為每個團隊的基本單位（故事分值）“定義”不同。每個團隊都是獨一無二的，對比速度並無價值，而且還會引發負面行為和團隊之間的競爭，而非合作。

同樣的道理也適用於團隊內部成員。個體對故事分值的貢獻微乎其微。而且最重要的一點，故事分值本身並不是指標。比較同一團隊成員的速度並無意義。唯一重要的指標是一個主觀指標：在開發軟體中交付的價值。

最簡單的解決辦法：停下來。否則只會事與願違，浪費時間。

4、寫任務，而不是寫故事

敏捷故事模板在構建某個特徵對某個特定使用者或角色的好處時很有用。這提醒了我們，目標是為交付能夠滿足某些人的使用期望的軟體。如果你的“故事”大部分內容實際上都是任務，那麼開發過程就會變成任務導向（做事情），而不是交付導向（創造價值）。開發團隊與使用者保持聯絡很重要，沒有使用者的軟體一無是處。

這種問題的解決辦法是平衡：總會有一些必須完成的類似任務的事項，但是故事的規模應該控制在單個迭代過程能夠完成，因此把它分解成多個任務並沒有意義。“完成”75%的故事毫無用處。要麼做，要麼不做，沒有中間值可取。如果一個故事太過複雜，無法在一個迭代過程中完成，而且無法劃分成幾個故事，那就應該用幾個過程來完成（見下一部分）。

5、絕對不要重複故事

如果你把大的故事分解成幾個小故事，只是為了能夠符合一個迭代過程的時間長度，這樣做是不對的。這種行為會產生幾個聯絡更弱、任務導向的“故事”。與之相反，堅持更大的、更自然的故事，用幾個迭代過程去完成。有始有終，從能夠實現預期效能的最小功能“核心部分”做起，然後在後續的迭代過程中加入其它行為和元素。這樣可以保證故事的完整性，從核心部分發展到可用性。

一旦核心部分完成，它的結構和效能可能會引發其它子故事，或者你會在下個迭代過程中發現優先順序發生了變化，因此核心部分需要擱置。但是，如果你把故事分解成幾個任務，以為把每個任務當成一個“故事”來完成會更容易，那麼開發出來的軟體就不會包含可識別的附加價值，因為任務傾向於專注不關聯的部分，而不是相互聯絡的價值流。

在本文的第二部分，將繼續介紹預示著敏捷方法走偏的另10個標誌，敬請期待。

本文系 OneAPM 工程師整理呈現。OneAPM 能為您提供端到端的應用效能解決方案，我們支援所有常見的框架及應用伺服器，助您快速發現系統瓶頸，定位異常根本原因。分鐘級部署，即刻體驗，效能監控從來沒有如此簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術部落格。

本文轉自 OneAPM 官方部落格

原文地址：http://www.javaworld.com/article/3075443/agile-development/15-signs-youre-doing-agile-wrong.html