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

【編者按】誤解和「最佳實踐」可能會讓你的團隊原地打轉，沒法高效產出代碼。本文的第一部分介紹了預示着敏捷方法走偏的前5個標誌，下面將介紹另外10個重要標誌。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。

##六、誤將 Scrum 當作敏捷 Scrum 是一種過程管理方法，而不是軟件開發方法。Kanban 也同樣。Scrum 和 Kanban 若是缺乏強硬的敏捷原則，最終只會回到瀑布模型。不少企業開發環境中的大量待辦事項（使用瀑布模型，而不是漸進發展模型）和「標準化」敏捷實踐更會惡化這一問題。

##七、大量待辦事項 若是你很關心功能的交付時間——一個想法從概念到生產完成須要的時間——毀掉這一切的最好辦法就是列個長長的任務清單。不幸的是，不少公司仍舊按照大模塊來計劃、受權和執行軟件開發項目，這樣一開始就有一大堆待辦事項，而且會保證排在後面的功能的交付時間絕對長得嚇人。

假設你要去尋找此前據說過的一個隱祕湖泊。你會帶上擁有的全部物品，仍是隻帶上你須要的東西，以便快速前行呢？大量的待辦事項跟這個狀況很像，你但願能儘快發現或驗證功能價值，卻在一開始就負擔太重。

項目並非真實存在的事物，只是一種思惟模型。咱們發明項目這個詞，來談論一些模糊的工做，把它們當作一個時間和工做量的總體。項目並不存在，存在的只有產品。關鍵在於簡化。按照一系列可以交付可衡量價值的功能來組織項目，而後再進行小規模、可衡量的改進「浪潮」。

##八、毫不結對編程（或者老是結對編程） 結對編程有人愛有人恨。兄弟們，它只是個工具，並非個信仰。它應該用在適合的地方，並且沒錯，某些時候它老是適合的。

結對編程可以將系統、工具、方法、技巧等知識傳播到整個團隊，加強成員之間的聯繫，支持成員之間的互相指導，並且在不少案例中可以比程序員獨立工做的效率更高、質量更好。若是你看到一個故事時想的是「這個工做兩我的來作應該比一我的好」，顯然應該選擇結對編程。若是團隊中的某個成員可以完成這個故事，結對編程可能不會有很大幫助。跟全部的敏捷實踐方法同樣，結對編程只是個工具，應該用於有效的時間和環節。

##九、沒有重構 重構不只能幫助改善代碼的機械性能，還能幫助你從本身的代碼中學到東西。經過重構，你能匯聚出更好的模型。如今你的代碼能用，不過可能有些使人緊張，甚至有些脆弱。重構可以揭示內含的模型，告知你對該領域的理解。在測試導向的紅-綠-重構（red-green-refactor）開發流程中，「重構」並不是可選項，而是必選項，除非你累積了技術債務，而且未能從編碼經驗中吸收教訓。

##十、站立會議不能及時結束 站立會議本應該是個簡短的團隊分享儀式，可是很容易拖成耗時較長的會議。把談話限制成整個團隊應該瞭解的內容的簡短髮言——你昨天作了什麼，今天要作什麼，有什麼問題，是否須要協助。另外，說一兩句你學到的東西也頗有幫助。這樣就夠了。大家能夠採起循環制，「參照故事牆」，或團隊喜歡的其餘方式來進行。

站立會議並非探討技術、作出決策、提出設計方案、交換戰爭故事、重組迭代或其餘任何與必要的團隊協做溝通無關事情的場合。作好準備來參會，這樣你就能夠傾聽別人作了什麼，正在作什麼，而且決定這些是否與你相關，而不是思考你要說什麼。任何超出互相更新狀態的內容都應該隨後經過羣聊軟件或郵件來溝通。站立會議中，每一個成員的發言時長應該控制在15到30秒以內。

##十一、缺乏回顧 敏捷團隊應該自行組織，選擇適合團體行爲的實踐和儀式。這一點也應該按期檢查，讓全體成員都參與進來，探討改進流程的方法，並採起相應的行動。這一般被稱爲「回顧」，是個中性方法，用於修正流程，避免浪費時間責備成員。

舉個例子，某位團隊成員注意到，產品用戶的反饋來得太遲，他建議縮短迭代時間也許會有幫助。團隊經過了這條建議，嘗試縮短迭代時間，並在下次回顧會議上評價這樣作的效果。經過這種方式，團隊的流程不斷獲得改進。

通用的「敏捷」一般會致使團隊跳過回顧環節，或者將該環節縮減爲機械的儀式，沒法得到任何有意義的經驗教訓。若是你注意到團隊流程中存在問題，卻不敢在回顧中提出來，大家的回顧環節就已經變成了機械儀式。未經檢查的流程沒法獲得優化，應該多多鼓勵團隊成員提出意見建議。

##十二、手動測試（或缺乏測試） 測試對生產可操做軟件很是關鍵，若是你沒有將測試自動化，就錯失了極大的效率性和準確度。相似行爲驅動開發（BDD）的輕量級測試規格技術與敏捷故事搭配時效果絕佳。在瀑布式模型中，BDD 描述能夠經過一張很是簡潔的表格來定義用例、明確要求和接受度測試。

將這些測試用例，還有「測試金字塔」（技術單元測試、功能集成測試、接口契約測試、用戶接受度測試）的剩餘內容自動化，提供了一種高效可靠的備選方案，不須要破壞任何東西，就能驗證一個代碼變動是否達到預期效果。自動化的測試是一張安全網，能給團隊帶來自信和勇氣。

##1三、徹底跳過模型和設計階段 開發軟件優先於文檔記錄並不表明着「跳過全部模型和設計活動，只寫代碼」。須要避免的是花費無數個小時來制定詳細的圖表和規格這類投機性任務。畢竟，要了解一個模型或設計是否正確，惟一的方法就是經過寫代碼來進行測試。

可是若是你須要解決一個特別難的問題，那就想盡一切辦法來解決。低保真度的模型或設計能夠在故事的測試用例中經過大腦進行測試，並且不一樣的設計能夠迅速完成探索。你可能還會想基於故事規模來規定這個活動的完成時間：舉個例子，5分鐘用於審查一個一分值故事的基本流程和接觸點，15分鐘用於查看一個兩分值故事是否隱含有複雜問題，等等。

你的模型或設計應該可以說明故事的好處，並推進你找到解決辦法，後者應該在代碼中進行測試。使用你的判斷力來決定須要設計多少，按照什麼樣的保真度，使用什麼方法，每一個故事用多長時間，不要由於你要「實施敏捷」，就以爲你「不能」創建模型或設計。

##1四、避免 devops 若是某件事令你感到痛苦，多作這件事。這會激發自動化。

把機器當作牲畜，而不是寵物，使用 Ansible、Chef、Puppet 等工具實現基礎架構自動化。啓動測試，實施軟件自動化，或者至少打開開關。解決基礎架構問題，把它做爲代碼庫的一部分合並進去，並使用相似 AWS 這樣的自助服務平臺。生產週期——從處理代碼變動到產品發佈所需時間——會被自動地大幅度縮短，由於反饋週期變短，相應的理解時間也會縮短。理解時間加快會帶來更頻繁、更優質的軟件交付。

##1五、採起「最佳實踐」 通用的「最佳」實踐並不存在。適用於一個團隊的方法可能並不適用於另外一個團隊，哪怕在同一公司，甚至是同一項目。咱們建造的全部東西都是基於獨一無二的設計和條件，每一個團隊擁有的個性、技能和環境也都是獨一無二的。看一看別人以爲有效的實踐方法，若是可行，就試用一下，可是不要由於某些權威人士說這些方法是「最好的」，就自動套用。別人的「最好的」方法也許會成爲你的團隊的負擔。

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

本文轉自 OneAPM 官方博客

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