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

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

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

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

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

一、實施敏捷與敏捷實踐

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

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

若是大家強制全部團隊遵循一刀切的通用敏捷「流程」，這種作法是錯的。這種「標準的」敏捷流程的想法是矛盾的，由於敏捷意味着持續不斷地適應和改進。

要想補救，不要忘了大家的主要目標是交付可用的軟件，而不是遵循某個方法；沒有方法是萬能的，適用於全部項目和團隊。所以，放手讓每一個團隊自行操做，並修正和改進實踐。

二、將故事分值當成目標

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

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

你的團隊的三分故事多是其餘團隊的五分故事。將故事分值當作成功的衡量標準，破壞了它做爲預估方法的價值，而且會致使「鑽制度空子」來僞裝成功（已達到速度 X），實際上並無成功（交付可用且有用的軟件）。

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

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

沉迷於指標幾乎是大部分程序員的次日性。可是，若是你的團隊將速度——迭代計劃中團隊所用的每次迭代的故事分值衡量指標——當作比較點，大家就錯了。

再次說明一下，速度只是用於預估的中性指標。對比團隊速度毫無心義，由於每一個團隊的基本單位（故事分值）「定義」不一樣。每一個團隊都是獨一無二的，對比速度並沒有價值，並且還會引起負面行爲和團隊之間的競爭，而非合做。

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

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

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

敏捷故事模板在構建某個特徵對某個特定用戶或角色的好處時頗有用。這提醒了咱們，目標是爲交付可以知足某些人的使用指望的軟件。若是你的「故事」大部份內容實際上都是任務，那麼開發過程就會變成任務導向（作事情），而不是交付導向（創造價值）。開發團隊與用戶保持聯繫很重要，沒有用戶的軟件一無可取。

這種問題的解決辦法是平衡：總會有一些必須完成的相似任務的事項，可是故事的規模應該控制在單個迭代過程可以完成，所以把它分解成多個任務並無意義。「完成」75%的故事毫無用處。要麼作，要麼不作，沒有中間值可取。若是一個故事太過複雜，沒法在一個迭代過程當中完成，並且沒法劃分紅幾個故事，那就應該用幾個過程來完成（見下一部分）。

五、絕對不要重複故事

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

一旦核心部分完成，它的結構和性能可能會引起其它子故事，或者你會在下個迭代過程當中發現優先級發生了變化，所以核心部分須要擱置。可是，若是你把故事分解成幾個任務，覺得把每一個任務當成一個「故事」來完成會更容易，那麼開發出來的軟件就不會包含可識別的附加價值，由於任務傾向於專一不關聯的部分，而不是相互聯繫的價值流。

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

本文系 OneAPM 工程師整理呈現。OneAPM 能爲您提供端到端的應用性能解決方案，咱們支持全部常見的框架及應用服務器，助您快速發現系統瓶頸，定位異常根本緣由。分鐘級部署，即刻體驗，性能監控歷來沒有如此簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客

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