程式開發員，放棄「敏捷」吧！ (Developers Should Abandon Agile)
本文為翻譯作品，原作者Ron Jeffries為極限編程的共同發明人，也是敏捷宣言起草人之一。
文中，作者敘述了「自認敏捷」和「暗黑敏捷」如何違反敏捷精神，使得程式開發員的生活更加痛苦。更多訊息請見原文、簡中版翻譯、及簡中版點評。
大生意
如今，「敏捷(Agile)」一詞，儼然已變成了一筆大生意。無疑地，在Scrum Alliance透過發行所謂「CSM」認證的推波助瀾下，市面上已經出現了巨量的「敏捷教
練」與「敏捷培訓員」流竄，同時，也有各式各樣「敏捷方法」與「敏捷框架」盛行著。
我們也能看到一些培訓活動，如「如何成為敏捷領導人」，而求職市場甚至已經開始出現一些相關職缺，如「敏捷的PM」等。
對公司十分有利
而今，對公司來說，以上的職缺中，有許多(甚至可說是大多)並非代表著壞事。一般來說，一間公司只要嘗試改變，通常就會改善。也就是說，即使「敏捷」的概念根本就被誤用得亂七八糟，光是「嘗試」這件事兒本身就可以給公司帶來助益。譬如，「工作可視化」就可以改善，而這就有助於做出更好的決策。這當然是好事，我十分贊同。
對程式開發員卻不太好
然而另一方面，對那些正在所謂「敏捷」的公司內參與產品開發的程式開發員來說，就沒那麼好棒棒了。當敏捷的概念被誤用時，常會直接導致開發員的工作遭遇更多阻礙、更少時間從事開發、更大的壓力、以及更多的期待要你「做快一點」。這對開發員來說簡直糟透了，而且也終究會傷害公司。因為，絕大多數做得爛的「敏捷」開發，會帶來更多更多的爛程式、以及比原本更慢的開發進度。而通常此時，好的開發員會選擇離開，只留下一些雜魚在公司，最終，可以想像的是，公司的效率變得比「敏捷」前還要糟糕許多。
要Safe，不要SAFe
我的想法是，如同Kent Beck十多年前就說過的一樣，我希望開發員的工作能更舒適一些。(譯者註：這裡原作使用safe一詞，但譯者選擇翻成舒適，以求更符合中文使用慣例。) 儘管近年來我大多從事管理、顧問、與寫作的工作，但我骨子裡始終是一名開發員。我自己如果可以，每天，或至少每週會寫一點code — 我今天稍早就在coding。因此，這些年來，每當看到我們當年寫下的「敏捷宣言」的真正意涵，如今被誤用後使得開發員的生活不但沒變好，甚至更糟，簡直痛徹心扉！雖然我也會對於沒有得到他們應得好處的公司感到傷心，但我更關心的還是那些站在一線，辛苦的開發員們。
過去幾年來，我聽過許多開發員們說：「敏捷爛斃了！」（他們其實通常說的是「scrum爛斃了！」，因為大家在公司推動敏捷時，通常由scrum開始。）我試著幫助他們，讓他們了解到，他們的公司用了錯誤的方式做敏捷：他們沒有照敏捷宣言作者建議的做，也沒有照scrum建議的做，更沒有照其他許許多多敏捷開發專家們建議的做。我希望我的聲音可以幫助他們以及他們的公司，讓他們能更接近宣言所說的理想境界，而遠離坊間盛行的「自認敏捷」與「暗黑敏捷」。
培訓這條路，看起來不太通。那些如「進階scrum」的培訓與認證，以及領導力的培訓立意很好，長期來看也許能收到不錯的功效，但這些需要長期來看才會有效果，也可能一階一階傳下來，到最底層時，效用已所剩無幾，救不了那些水深火熱的開發員們。
是時候了，來試試新方法吧，那就是：
程式開發員應該放棄敏捷開發。
現況是這樣子的：如今開發員們持續身處scrum環境，或在使用SAFe流程的公司上班。有些甚至遇到更令人不解的DAD，有些幸運一點，遇到好一點的，如Modern Agile，或是Heart of Agile。另外更有一些更幸運的可以使用Extreme Programming，也就是所謂「真正有效的scrum」。
別被方法論的名字迷惑了
儘管方法有百百種，我認為開發員們不應該再把注意力放在任何特定的著名「敏捷方法」了。反之，開發員更應該試著用一種「可以套進任何敏捷方法」的方式開發。雖說世上有很多方法可以達到上述目的，但私以為，你可以選擇「使用Extreme Programming提到的實踐們」。更正確來說，開發員應該致力於「可支持敏捷開發的基本原則」，這也是吾人當初寫下敏捷宣言時，腦中所想的事情。如今，我想再一次總結這些idea如下：
不管你老板認為他們正在從事的是什麼框架（或方法），你都學著這樣做：
- 固定交付「可動、測過、符合需求、並不斷整合」的軟體。先是每兩週一次，然後，精進技術，變成每天、每天兩次、最後每天很多次地交付全新版本。
- 永遠保持程式碼乾淨。隨著產品擴大，程式會慢慢變得又亂又醜。你永遠都要勇敢抗拒並修復此局面，用小而持續的步調重構。如此一來，你就可以一直保持一個固定、始終如一的工作速率。
- 與老板溝通時，永遠以你產品的新增功能為基礎。告訴他們你手上有什麼功能可以上線賣錢了，並問他們下一個功能想要什麼。（譯者註：關心產品有了什麼變化，而非你做了什麼事。）
這其實是開發團隊的最理想生活了。只要保持產品「隨時可上線」，我們就可以「在任何deadline前，以目前手上最好的功能交付產品」。
「什麼？今天是deadline？拿去吧，這是我手上所有的功能，都已經具上線條件了。」
只要我們隨時為deadline做好準備，並且總是可以協調下一步行動，在跟老板對談時，我們手上的這個「隨時可上線軟體」讓我們可以永遠只聚焦在下一步，並且是最重要的事情，而不是老板腦中那看似永無止境的功能清單。的確，要老板動心轉念，從「我全都要」，變成「下一步我想要…」，是非常非常不容易的一件事兒，但要獲得一個美麗人生，這是必做之事，而且通常，只要我們先改變自己，從「為他們工作」，轉變為「和他們一起工作」的話，老板的轉念是大有可能的。
當公司正在「導入敏捷」
有太多太多團隊使用所謂的「敏捷」方法都是被「導入」的。事實上那些大規模敏捷方法都建議你導入這些流程。這些方法們就包含了坊間所謂的「SAFe」「Scaled Scrum」、以及「LeSS」等。這些方法被植入公司高層的腦中，公司就設法「導入」或「實踐」它們。
身為開發員，你可以確定這些實踐既不會順利，也不可能做到真的敏捷。你大概不會真的被好好地訓練或教育，你甚至得不到在敏捷轉型過程中，你真正需要的那些幫助。嗯，你的老闆可能有機會接受一些訓練，譬如花一整個禮拜外出上課之類的，就是為了讓他們充分準備，好回來狂風掃落葉般地把這些新方法一口氣灌輸到產品與開發流程上頭。哇！這光聽起來就是阻礙重重。
「軟體本身」才是你的唯一救贖
然而，如果真的在一個Sprint週期，或一個版本貨櫃，或是任何你的版本列車在開始準備Release的時候，你都有選擇工作的自由度，並且在這段期間內將其完成，並打包進一個可以動、測試過、整合好、隨時可以上線的全新版本的話，其實你已經做好完全準備了。
慢下來！考慮部署先。
反之，如果你無法這麼做，我就會建議你在每個週期拿少一點的工作來做，少到你每個週期有足夠的時間做完上述那些流程為止。這當然不容易！別人永遠會督促你「做快一點」 而你應該盡力而為。什麼意思？當你被要求承諾做完超過負荷的工作量，在這樣的壓力下，我建議你先專心做完其中一兩件事兒（這裡的做完，指的是「完整打包、測試、並且有效」），然後才去做其他的。如此一來，到了交付日，你即使沒有每一項都完成，至少有一些功能是你可以自信地拿得出來說是「完全做完」的。承擔未完成所有工項的責難，並試著針對現實做規劃與估計，而非虛幻的要求，那些你根本辦不到的要求。
這麼做可不輕鬆，而且這樣的辛苦日子，至少會持續一段時間。然而這是就我所知，要爬出這程式泥沼的這最佳解了。要扭轉乾坤，除了時時努力呈現可運行的程式以外，我想不出其他更好方法了。時機壞壞，我們也只能先盡力而為，並試著讓事情好轉。
可以想像，一個已經知道這些敏捷方法，正在學習改進的公司，會對敏捷宣言背後真正涵義的態度會變得越來越開放。我相信，待著，未來這裡的工作方式會變更好。
我自己也曾身處其此種環境，而比起轉頭走人，我所知的最佳方法是做好工作，提高可見度，堅持產出可運行、通過測試、高度整合的程式，並試著幫助別人認清現實
你自己選擇工作方法
敏捷宣言支持自組織團隊，而在最佳情況下，這代表團隊可以自己選擇工作流程。如果我要開一間公司，我會讓團隊們自己決定要怎麼工作。
我會關注結果，而非特定流程
然而，我還是得下些限制，我不想管他們想怎麼工作，但我有我必須要看到的東西。我會明白地告知同事們，最多最多每隔兩週，我要看到他們測試過可運行的產品功能。他們得告訴我他們原定要做什麼，以及他們實際做了什麼。這些功能必須能運作，而且必須能讓我一目了然。我們接著會討論他們接下來該做什麼。同時，我也會讓他們知道一週的週期是好過兩週的，而一天更會好過一週。
我會提供協助
我會提供協助給他們。我會把產品的商業需求確實地告訴某人，讓他去幫助團隊決定下一步應該怎麼走。我會提供他們工作所需的訓練與支援。我會提供他們工作上所需的所有設備。
當然啦，我是因為知道怎麼做才這麼做的。你的話，也許你會遇到一個像我一樣的老闆，或至少至少像我一樣讓你自己決定自己的工作流程。或許吧。
（小聲說）試試XP吧！
如果你真的萬幸，可選擇自己的工作流程，我會推薦你從Extreme Programming開始。它包含了所有從規劃到回饋的工作循環，它也包含本文所述，所有你需要的技術實踐，而如果你要來給我請的話，你也會需要這些的。
同時，我也建議你隨時注意你可能會需要的新知。私以為，你就是會需要「驗收測試驅動開發、測試驅動開發、與重構」，在你找到更棒的方法之前。然而，世上還有數以百萬計的資源是你所需的，請隨時關注，並在你需要時使用。
產出卓越的軟體是軟體開發員畢生的志業。即使是Extreme Programming這個我認知中最好的工作方法，也才觸及皮毛而已。要不要向卓越更近一步，全都取決於你的團隊成員們。
總結
我自己倒是自由地選擇了Extreme Programming為努力方向，而我是認為比起方法論，它更像是一群概念的集合。但這不是最主要的。我撰寫本文主要是認為軟體開發員們無論如何都不要再執著於任何『敏捷方法』了。這些方法在真正落地實行時，絕大部分都 成為了卓越軟體開發的敵人，而非朋友去了。
然而，敏捷宣言所述的價值與原則，仍舊是就我所知開發軟體的最佳方法。而我從自己的眾多經驗中學習到，不管這些大公司喜歡用什麼流程開發，我還是遵守這些原則卡好。
我呢，就提供上述建議給各位參考。如覺得合用，請不吝套用之。
註：
在本文與其他文章中，我用「」括起來的「敏捷」，代表那些把「敏捷」二字掛在頭上，實際上不太符合我們當初寫下敏捷宣言，背後隱含的精神的方法們。我有時也會稱它們為「暗黑敏捷」或「自認敏捷」，因為它們事實上根本就變質了。 我有時會以「宣言中的敏捷」 來表示我至今仍深信不疑的，敏捷宣言隱含的真正意涵。
