1、所謂“熱門”

　　“敏捷”儼然成為了熱門。毫無疑問，由Scrum Alliance領導的通過ScrumMaster認證的風潮，導致我們現(xiàn)在蜂擁而來成百上千個所謂的“敏捷”教練和培訓師，以及許多競爭性的框架和方法。所謂的“敏捷”領導力培訓，“敏捷”項目管理產(chǎn)品，等等，層出不窮。

2、企業(yè)的快樂

　　當然，很多，或者甚至大部分這些產(chǎn)品都不是壞事，至少對于企業(yè)是這樣的。嘗試改進的組織通常確實可以得到改善，而且即使“敏捷”思路應用不當，嘗試的過程仍然會為組織帶來一些好處。組織至少可以更好地了解正在發(fā)生的事情，而這往往會使得即使是最不明智的管理層也能夠做出更好的決策。很好，企業(yè)方面表示完全贊成。

3、開發(fā)者的痛苦

　　對于開發(fā)人員來說，這畫面就沒有那么美了，所有實際參與過構建“敏捷”企業(yè)產(chǎn)品的人員皆是心有戚戚然?！懊艚荨崩砟畹膽貌涣?#xff0c;往往會對開發(fā)者產(chǎn)生更多的干擾，使得他們用于工作的時間更少，壓力更大，需求“更快”。這對開發(fā)人員來說是不利的，回過頭來最終也會對企業(yè)造成不利的影響，因為拙劣的“敏捷”會導致更多的缺陷和更慢的進展。通常而言，優(yōu)秀的開發(fā)人員會選擇離開這樣的組織，從而導致企業(yè)效率比之前還沒裝備“敏捷”時更低。

4、safe而非SAFe

　　這一條源自Kent Beck在十多年前所說的話。我希望這個世界對開發(fā)者來說是safe的。盡管歷經(jīng)多年的管理、咨詢和寫作工作，但我的本質依然是開發(fā)人員。今天早些時候我就在寫代碼，哪怕不是每天，至少每周我都會寫代碼。因此，在《Agile Manifesto》中看到“這會使得開發(fā)者的生活變得更糟而不是更好”的觀點時，著實讓我傷心了一把。雖然企業(yè)沒有從中得到什么也讓我感到難過，但我主要關心的是開發(fā)人員。

　　在過去的幾年中，我聽到許多開發(fā)人員在說“敏捷很糟糕”。而我則幫助那些人理解原因在于他們的組織使用的“敏捷方法”是錯誤的：企業(yè)沒有做到Manifesto作者推薦的內容、沒有做到Scrum建議的內容、或者沒有做到許多敏捷軟件開發(fā)專家推薦的內容。我希望聽到我的解釋之后，這些人可以幫助自己和他們的組織接近Manifesto Agile背后的真實想法，遠離我們周圍所見的各種形式的Faux Agile或Dark Agile。

　　這并不真正解決問題。雖然諸如“高級”Scrum培訓和認證，以及以領導為中心的努力也挺不錯，并且可能會隨著時間的推移而獲得成果，但進展緩慢，并且可能永遠不會真正過濾掉“堆積如山的代碼” 。

　　現(xiàn)在是時候接受新的觀念了，那就是：

　開發(fā)人員應摒棄“敏捷”

　　請注意，開發(fā)人員將繼續(xù)在Scrum條件下或在使用SAFe的組織中工作。有些甚至可能會遇到像“DAD”這樣更為晦澀的“敏捷”方法，或者如果幸運的話，采用的是更為開明的方法，如“Modern Agile”或“Heart of Agile”。有些人甚至可能足夠幸運到發(fā)現(xiàn)自己正在進行極限編程，也被稱為“The Scrum That Actually Works”。

5、能抓老鼠的才是好貓

　　盡管如此，我認為開發(fā)人員應該從任何特定的所謂的“敏捷”方法中解放他們的思想。不管它叫“黑貓”還是“白貓”，能抓老鼠的才是好貓。他們應該將他們的注意力和學習方向轉向可以在任何這些“敏捷”方法中工作的軟件開發(fā)方法。對我而言，開發(fā)方法涉及極限編程的使用實踐，但不限于此。更一般地說，開發(fā)人員的工作應該堅持支持敏捷軟件開發(fā)的基本原則，正如我們在編寫Manifesto時所考慮的那樣。這就是我們這篇文章的中心思想。

　　無論管理層認為他們正在應用什么框架或方法，學會以這種方式工作：

• 每兩周生產(chǎn)一次可運行的、經(jīng)過測試的、可工作的、集成的軟件，然后每周生產(chǎn)一次。學習技能直到你可以每天創(chuàng)建一個全新的完全可操作的版本，然后一天兩次，甚至一天多次。

• 保持軟件的設計簡潔。隨著它的發(fā)展，設計將趨于復雜和笨拙。始終要有意識地抵制和扭轉這種趨勢，始終以微小的連續(xù)步驟進行重構，以便你的進度可以盡可能的穩(wěn)定和一致。

• 使用當前的軟件增量作為你與產(chǎn)品領導和管理人員進行對話的基礎。就準備好的事情以及他們希望你下一步做什么來說明問題。

　　這是一個理智的開發(fā)團隊的最大希望。軟件的整裝待發(fā)，可以讓我們在最后期限內實現(xiàn)最佳結果?！敖裉焓亲詈笃谙蘖?#xff1f;我們已經(jīng)搞定了，隨時可以發(fā)布?！?/p>

　　當我們接近截止日期時，當我們爭執(zhí)接下來要做什么時，我們手頭的軟件會讓我們將談話集中在下一個最重要的事情上，而不是天馬行空。將重點從“做所有這些”轉變?yōu)椤敖酉聛碜鍪裁础辈⒉蝗菀?#xff0c;但這會讓我們的生活變得更容易，而且也使得改變的可能性更大，因為我們是與領導者合作而不僅僅是在他們的指揮下工作。

6、人在江湖

　　通常情況下，團隊使用的“敏捷”方法往往是強制的。實際上大規(guī)模的“敏捷”方法似乎就是建議強制的。這里包括所謂的“SAFe”方法、Scaled Scrum和LeSS等等。這些方法進入到企業(yè)，就像蝴蝶的翅膀，引發(fā)了一場龍卷風。

　　作為開發(fā)人員，你可以肯定的是，這樣推出方法是不會順利的，也沒有以一種真正的敏捷方式進行。你不可能接受培訓，得到的教導微乎其微，更不用說提供的真正可用于完成工作的幫助了?？赡苣愕念I導已經(jīng)接受過培訓，甚至用了整整一周時間，以便于他們可以準備好面對組織生產(chǎn)方法和軟件開發(fā)中出現(xiàn)的徹底改變?？偠灾?#xff0c;道路是崎嶇的。

7、現(xiàn)實軟件是你唯一的救贖?！狶eia

　　但是，如果你可以可靠地選擇在“Sprint”或“boxcar”的過程中完成工作，或者無論你發(fā)布什么，列車售票員都開始調用時間段并完成該工作，將其打包為可運行，已測試，已集成，即將推出的新系統(tǒng)版本，那么你將能盡最大努力實現(xiàn)這個目標。

8、放慢交付速度

　　如果你不能很好地解決這個問題，那么我建議你在每個時間段內減少工作量，直到工作批量足夠小到你實際能夠完成。這很難！總是會有人死命地催你“跑快點”。盡你所能吧！在壓力下簽署超出能力范圍的工作量，我的建議是從事一兩項工作，直到完全完成——完全打包、經(jīng)過測試和可工作——然后再做另一項工作，以便在boxcar的最后你有絕對可以稱之為“完工”的內容。不要采取廣撒網(wǎng)的策略，以免最后反而一事無成，嘗試從現(xiàn)實出發(fā)來制定計劃和期望，不要幻想那些雖然是要求的但從來沒有機會做的事情。

　　這個過程肯定不是完美的，至少一段時間內如此，甚至可能也不會很有趣。然而，這是我知道的在代碼山中生存下來的最好機會。擁有完成的可運行的產(chǎn)品片段是我知道可能改變代碼山這種狀況的最佳方式。在糟糕的情況下，我們所能做的就是盡我們所能，努力讓事情往好的方面發(fā)展。

　　顯然，在一個更開明的組織中，或在一個保持學習的組織中，事物才會越來越接納真正的Manifesto敏捷思想。我們的編碼生活將得以改善，這正是我的期盼。

　　我一直處于這樣的處境中，除了離開之外，我所知道的最好的就是做好工作，讓軟件保持可見，可運行，經(jīng)受得住測試和整合，并幫助人們實現(xiàn)現(xiàn)實事務。

9、選擇一種方法

　　Manifesto呼吁“自組織的”團隊，最好的情況就是，團隊選擇適合自己的流程。如果我創(chuàng)辦一家公司，那就讓團隊自己選擇他們想要的流程。

　　要求結果，而不是特定的過程

　　然而，這是有限制條件的，限制不在于他們如何選擇工作，而在于我需要看到結果。我會清楚地說明，至多每兩周，我會回顧他們正在運行的測試產(chǎn)品的片段。他們會展示給我看他們計劃構建什么，以及他們已經(jīng)構建好了什么。這樣的要求使得他們不得不實實在在地致力于工作，并包含我可以理解的可見功能。我們會談論他們在下一個時間段應該做什么。我會清楚地說明一周回顧一次優(yōu)于兩周回顧一次，一天回顧一次優(yōu)于一周回顧一次。

10、提供幫助

　　我會為他們提供幫助。我會提供一個與業(yè)務需求緊密聯(lián)系的人，他將幫助他們決定下一步要做哪些工作。我會提供培訓和支持，以幫助他們需要完成的工作。我會確保他們有能力做我要求他們做的事情。

　　當然，我會這樣做是因為我知道怎么做。如果你夠幸運的話，可能正處于與此類似的情況中——至少可以選擇自己的流程。

11、看我極限編程！

　　如果你有機會選擇，我建議你從極限編程開始。它包含所有你需要的規(guī)劃和反饋循環(huán)，包含完成我們在此討論的那些基本技術實踐，幫助完成我所要求的工作。

　　建議隨時保持警惕，注意你所需的其他東西。 “ATDD，TDD和重構”就是我認為需要注意的東西，當然可能你知道更好的。但是，你還需要許許多多其他的東西。保持警惕，以便于可以隨時識別并獲取。

　　制作出卓越的軟件是一項終身的活動。即使是極限編程——我所知道的最好的官方命名的方法——我也只是略懂皮毛而已。走向卓越取決于你的團隊及其成員。

12、總結

　　我真的認為軟件開發(fā)人員不應該遵守任何類型的“敏捷”方法。因為這些方法體現(xiàn)在實際中時通常是軟件開發(fā)的敵人，而不是朋友。

　　然而，敏捷軟件開發(fā)宣言的價值和原則仍然提供了我所知道的構建軟件的最佳方式，并且根據(jù)我資深又豐富多彩的經(jīng)驗，無論大型組織使用何種方法，我都會遵循這些價值觀和原則。

　　最后聲明，我以建議的形式提出這一意見。請按照你認為合適的方式去做。

?

英文原文：Developers Should Abandon Agile

總結

以上是生活随笔為你收集整理的为什么开发者应该摒弃敏捷？（转）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。