1、所謂“熱門”

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

2、企業(yè)的快樂

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

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

　　對(duì)于開發(fā)人員來說，這畫面就沒有那么美了，所有實(shí)際參與過構(gòu)建“敏捷”企業(yè)產(chǎn)品的人員皆是心有戚戚然。“敏捷”理念的應(yīng)用不良，往往會(huì)對(duì)開發(fā)者產(chǎn)生更多的干擾，使得他們用于工作的時(shí)間更少，壓力更大，需求“更快”。這對(duì)開發(fā)人員來說是不利的，回過頭來最終也會(huì)對(duì)企業(yè)造成不利的影響，因?yàn)樽玖拥摹懊艚荨睍?huì)導(dǎo)致更多的缺陷和更慢的進(jìn)展。通常而言，優(yōu)秀的開發(fā)人員會(huì)選擇離開這樣的組織，從而導(dǎo)致企業(yè)效率比之前還沒裝備“敏捷”時(shí)更低。

4、safe而非SAFe

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

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

　　這并不真正解決問題。雖然諸如“高級(jí)”Scrum培訓(xùn)和認(rèn)證，以及以領(lǐng)導(dǎo)為中心的努力也挺不錯(cuò)，并且可能會(huì)隨著時(shí)間的推移而獲得成果，但進(jìn)展緩慢，并且可能永遠(yuǎn)不會(huì)真正過濾掉“堆積如山的代碼” 。

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

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

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

5、能抓老鼠的才是好貓

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

　　無論管理層認(rèn)為他們正在應(yīng)用什么框架或方法，學(xué)會(huì)以這種方式工作：

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

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

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

　　這是一個(gè)理智的開發(fā)團(tuán)隊(duì)的最大希望。軟件的整裝待發(fā)，可以讓我們?cè)谧詈笃谙迌?nèi)實(shí)現(xiàn)最佳結(jié)果。“今天是最后期限了？我們已經(jīng)搞定了，隨時(shí)可以發(fā)布。“

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

6、人在江湖

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

　　作為開發(fā)人員，你可以肯定的是，這樣推出方法是不會(huì)順利的，也沒有以一種真正的敏捷方式進(jìn)行。你不可能接受培訓(xùn)，得到的教導(dǎo)微乎其微，更不用說提供的真正可用于完成工作的幫助了。可能你的領(lǐng)導(dǎo)已經(jīng)接受過培訓(xùn)，甚至用了整整一周時(shí)間，以便于他們可以準(zhǔn)備好面對(duì)組織生產(chǎn)方法和軟件開發(fā)中出現(xiàn)的徹底改變。總而言之，道路是崎嶇的。

7、現(xiàn)實(shí)軟件是你唯一的救贖。——Leia

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

8、放慢交付速度

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

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

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

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

9、選擇一種方法

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

　　要求結(jié)果，而不是特定的過程

　　然而，這是有限制條件的，限制不在于他們?nèi)绾芜x擇工作，而在于我需要看到結(jié)果。我會(huì)清楚地說明，至多每兩周，我會(huì)回顧他們正在運(yùn)行的測試產(chǎn)品的片段。他們會(huì)展示給我看他們計(jì)劃構(gòu)建什么，以及他們已經(jīng)構(gòu)建好了什么。這樣的要求使得他們不得不實(shí)實(shí)在在地致力于工作，并包含我可以理解的可見功能。我們會(huì)談?wù)撍麄冊(cè)谙乱粋€(gè)時(shí)間段應(yīng)該做什么。我會(huì)清楚地說明一周回顧一次優(yōu)于兩周回顧一次，一天回顧一次優(yōu)于一周回顧一次。

10、提供幫助

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

　　當(dāng)然，我會(huì)這樣做是因?yàn)槲抑涝趺醋觥Ｈ绻銐蛐疫\(yùn)的話，可能正處于與此類似的情況中——至少可以選擇自己的流程。

11、看我極限編程！

　　如果你有機(jī)會(huì)選擇，我建議你從極限編程開始。它包含所有你需要的規(guī)劃和反饋循環(huán)，包含完成我們?cè)诖擞懻摰哪切┗炯夹g(shù)實(shí)踐，幫助完成我所要求的工作。

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

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

12、總結(jié)

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

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

　　最后聲明，我以建議的形式提出這一意見。請(qǐng)按照你認(rèn)為合適的方式去做。

?

英文原文：Developers Should Abandon Agile

總結(jié)

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

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