【編者按】誤解和“最佳實踐”可能會讓你的團隊原地打轉，無法高效產出代碼。本文的第一部分介紹了預示着敏捷方法走偏的前5個標誌，下面將介紹另外10個重要標誌。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。
6、誤將 Scrum 當做敏捷
Scrum 是一種過程管理方法，而不是軟件開發方法。Kanban 也一樣。Scrum 和 Kanban 如果缺少強硬的敏捷原則，最終只會回到瀑布模型。很多企業開發環境中的大量待辦事項（使用瀑布模型，而不是漸進發展模型）和“標準化”敏捷實踐更會惡化這一問題。
7、大量待辦事項
如果你很關心功能的交付時間——一個想法從概念到生產完成需要的時間——毀掉這一切的最好辦法就是列個長長的任務清單。不幸的是，很多公司仍舊按照大模塊來計劃、授權和執行軟件開發項目，這樣一開始就有一大堆待辦事項，並且會保證排在後面的功能的交付時間絕對長得嚇人。
假設你要去尋找此前聽說過的一個隱祕湖泊。你會帶上擁有的所有物品，還是隻帶上你需要的東西，以便快速前行呢？大量的待辦事項跟這個情況很像，你希望能儘快發現或驗證功能價值，卻在一開始就負擔過重。
項目並不是真實存在的事物，只是一種思維模型。我們發明項目這個詞，來談論一些模糊的工作，把它們當做一個時間和工作量的整體。項目並不存在，存在的只有產品。關鍵在於簡化。按照一系列能夠交付可衡量價值的功能來組織項目，然後再進行小規模、可衡量的改進“浪潮”。
8、絕不結對編程（或者總是結對編程）
結對編程有人愛有人恨。兄弟們，它只是個工具，並不是個信仰。它應該用在適合的地方，而且沒錯，某些時候它總是適合的。
結對編程能夠將系統、工具、方法、技巧等知識傳播到整個團隊，增強成員之間的聯繫，支持成員之間的互相指導，而且在很多案例中能夠比程序員獨立工作的效率更高、質量更好。如果你看到一個故事時想的是“這個工作兩個人來做應該比一個人好”，顯然應該選擇結對編程。如果團隊中的某個成員能夠完成這個故事，結對編程可能不會有很大幫助。跟所有的敏捷實踐方法一樣，結對編程只是個工具，應該用於有效的時間和環節。
9、沒有重構
重構不僅能幫助改善代碼的機械性能，還能幫助你從自己的代碼中學到東西。通過重構，你能匯聚出更好的模型。現在你的代碼能用，不過可能有些令人緊張，甚至有些脆弱。重構能夠揭示內含的模型，告知你對該領域的理解。在測試導向的紅-綠-重構（red-green-refactor）開發流程中，“重構”並非可選項，而是必選項，除非你累積了技術債務，並且未能從編碼經驗中吸取教訓。
10、站立會議不能及時結束
站立會議本應該是個簡短的團隊分享儀式，但是很容易拖成耗時較長的會議。把談話限制成整個團隊應該瞭解的內容的簡短髮言——你昨天做了什麼，今天要做什麼，有什麼問題，是否需要協助。另外，說一兩句你學到的東西也很有幫助。這樣就夠了。你們可以採取循環制，“參照故事牆”，或團隊喜歡的其他方式來進行。
站立會議並不是探討技術、做出決策、提出設計方案、交換戰爭故事、重組迭代或其他任何與必要的團隊協作溝通無關事情的場合。做好準備來參會，這樣你就可以傾聽別人做了什麼，正在做什麼，並且決定這些是否與你相關，而不是思考你要說什麼。任何超出互相更新狀態的內容都應該隨後通過羣聊軟件或郵件來溝通。站立會議中，每個成員的發言時長應該控制在15到30秒之內。
11、缺少回顧
敏捷團隊應該自行組織，選擇適合團體行爲的實踐和儀式。這一點也應該定期檢查，讓全體成員都參與進來，探討改進流程的方法，並採取相應的行動。這通常被稱爲“回顧”，是個中性方法，用於修正流程，避免浪費時間責備成員。
舉個例子，某位團隊成員注意到，產品用戶的反饋來得太遲，他建議縮短迭代時間也許會有幫助。團隊通過了這條建議，嘗試縮短迭代時間，並在下次回顧會議上評價這樣做的效果。通過這種方式，團隊的流程不斷得到改進。
通用的“敏捷”通常會導致團隊跳過回顧環節，或者將該環節縮減爲機械的儀式，無法獲得任何有意義的經驗教訓。如果你注意到團隊流程中存在問題，卻不敢在回顧中提出來，你們的回顧環節就已經變成了機械儀式。未經檢查的流程無法得到優化，應該多多鼓勵團隊成員提出意見建議。
12、手動測試（或缺少測試）
測試對生產可操作軟件非常關鍵，如果你沒有將測試自動化，就錯失了極大的效率性和準確度。類似行爲驅動開發（BDD）的輕量級測試規格技術與敏捷故事搭配時效果絕佳。在瀑布式模型中，BDD 描述可以通過一張非常簡潔的表格來定義用例、明確要求和接受度測試。
將這些測試用例，還有“測試金字塔”（技術單元測試、功能集成測試、接口契約測試、用戶接受度測試）的剩餘內容自動化，提供了一種高效可靠的備選方案，不需要破壞任何東西，就能驗證一個代碼變更是否達到預期效果。自動化的測試是一張安全網，能給團隊帶來自信和勇氣。
13、完全跳過模型和設計階段
開發軟件優先於文檔記錄並不代表着“跳過所有模型和設計活動，只寫代碼”。需要避免的是花費無數個小時來制定詳細的圖表和規格這類投機性任務。畢竟，要了解一個模型或設計是否正確，唯一的方法就是通過寫代碼來進行測試。
但是如果你需要解決一個特別難的問題，那就想盡一切辦法來解決。低保真度的模型或設計可以在故事的測試用例中通過大腦進行測試，而且不同的設計可以迅速完成探索。你可能還會想基於故事規模來規定這個活動的完成時間：舉個例子，5分鐘用於審查一個一分值故事的基本流程和接觸點，15分鐘用於查看一個兩分值故事是否隱含有複雜問題，等等。
你的模型或設計應該能夠說明故事的好處，並推動你找到解決辦法，後者應該在代碼中進行測試。使用你的判斷力來決定需要設計多少，按照什麼樣的保真度，使用什麼方法，每個故事用多長時間，不要因爲你要“實施敏捷”，就覺得你“不能”建立模型或設計。
14、避免 devops
如果某件事令你感到痛苦，多做這件事。這會激發自動化。
把機器當做牲畜，而不是寵物，使用 Ansible、Chef、Puppet 等工具實現基礎架構自動化。啓動測試，實施軟件自動化，或者至少打開開關。解決基礎架構問題，把它作爲代碼庫的一部分合並進去，並使用類似 AWS 這樣的自助服務平臺。生產週期——從處理代碼變更到產品發佈所需時間——會被自動地大幅度縮短，因爲反饋週期變短，相應的理解時間也會縮短。理解時間加快會帶來更頻繁、更優質的軟件交付。
15、採取“最佳實踐”
通用的“最佳”實踐並不存在。適用於一個團隊的方法可能並不適用於另一個團隊，哪怕在同一公司，甚至是同一項目。我們建造的所有東西都是基於獨一無二的設計和條件，每個團隊擁有的個性、技能和環境也都是獨一無二的。看一看別人覺得有效的實踐方法，如果可行，就試用一下，但是不要因爲某些權威人士說這些方法是“最好的”，就自動套用。別人的“最好的”方法也許會成爲你的團隊的負擔。
本文系 OneAPM 工程師整理呈現。OneAPM 能爲您提供端到端的應用性能解決方案，我們支持所有常見的框架及應用服務器，助您快速發現系統瓶頸，定位異常根本原因。分鐘級部署，即刻體驗，性能監控從來沒有如此簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。
本文轉自 OneAPM 官方博客
原文地址：http://www.javaworld.com/article/3075443/agile-development/15-signs-youre-doing-agile-wrong.html