“敏捷”已然成為一門“大生意”。以 Scrum 聯盟認證 Scrum Master 為首，我們看到了成千上萬所謂的“敏捷“教練和培訓師，以及很多相互競爭的框架和方法，比如“敏捷”領導力培訓、“敏捷”項目管理，等等。
或許這些不算是壞事，至少對于企業(yè)來說。想要進步的企業(yè)通常會進步，即使“敏捷”思想沒有得到充分應用，付出的努力也不會白白浪費。至少，企業(yè)知道這當中都發(fā)生了什么，即使是最不開明的領導層，也會因此知道該怎么做出更好的決策。從這方面來說，事情是好的，我完全贊同。
但對于開發(fā)者來說，就不是這么一回事了。當“敏捷”思想沒有得到充分應用，只會給開發(fā)者帶來更多的干擾和更大的壓力，消耗他們的時間，讓他們感覺像是被鞭子抽著往前趕。這對開發(fā)者來說不是好事，而最終也會對企業(yè)不利，因為糟糕的“敏捷”實踐只會造成更多的缺陷和更緩慢的進展。好的開發(fā)者通常會因為這個而離開企業(yè)，而對于企業(yè)來說，“敏捷”比“不敏捷”更加糟糕。
我的想法來自 Kent Beck 十多年前說過的話——我希望這個世界對于開發(fā)者來說是安全的。我骨子里是個開發(fā)者，盡管做了多年的管理、咨詢和寫作工作。我?guī)缀趺恐芏紩懘a。看到“敏捷宣言”里所宣揚的想法并沒有讓開發(fā)者的生活變得更好，而是更糟糕，我感到很傷心。企業(yè)也沒能從“敏捷”中得到應得的好處，我也感到很悲哀，不過我最關心的還是那些參與敏捷實踐的人。
多年來，我聽到很多開發(fā)者吐槽“敏捷”。我試著讓他們明白，其實是他們所在的企業(yè)沒有做好“敏捷”，他們沒有按照“敏捷宣言”作者和敏捷軟件開發(fā)專家說的那樣去做。我希望和我有同樣想法的人能夠救救自己，救救所在的企業(yè)，真正理解“敏捷宣言”背后的想法，遠離那些到處可見的偽敏捷和暗黑敏捷。
但事與愿違，一些“高級”的敏捷培訓和認證以及來自領導力方面的努力或許可以開花結果，但進展緩慢，而且可能永遠都觸及不到真正的開發(fā)者。
是時候嘗試一些新的東西了。
開發(fā)者會繼續(xù)在敏捷環(huán)境或使用 SAFe 框架的企業(yè)里工作。有些人甚至會遭遇隱晦的“敏捷”方法，比如 DAO。或者如果足夠幸運的話，他們會遇上更加開明的方法，比如“現代敏捷”或“敏捷之心”，有一些還可能從事極限編程。
話雖如此，我認為開發(fā)者應該拋棄任何與“敏捷”方法論相關的想法，而是把注意力放在那些在“敏捷”方法論之下行之有效的軟件開發(fā)方法上。這些開發(fā)方法包括了極限編程，當然，不僅限于此。開發(fā)者的工作應該遵循敏捷軟件開發(fā)的基本原則，正如我們在撰寫敏捷宣言時所想的那樣。我將這些想法總結如下：
無論管理層認為他們在應用什么樣的框架或方法，都要按以下這些方式展開：
每一兩周都要交付經過測試的可運行軟件。鍛煉你的技能，直到可以每天一次、每天兩次甚至是每天多次發(fā)布可運行的版本。
保持整潔的軟件設計。隨著規(guī)模的增長，軟件的架構設計會趨于復雜。有意識地抵制并扭轉這種趨勢，通過持續(xù)小步快跑式的重構來盡可能保持穩(wěn)定和一致的進度。
將軟件的當前增量部分作為與產品領導層對話的基礎，告訴他們哪些事情已經就緒，并詢問他們希望你接下來要做什么。
對于開發(fā)團隊來說，這是他們最有可能過上理想生活的方式。讓軟件保持就緒狀態(tài)，我們就能夠以盡可能最好的結果應對任何一個截止日期。“今天就是截止日期了？我們已經準備好了，可以交付了”。
隨著越來越接近截止日期，當我們在商討接下來要做什么時，我們會將談話的重點放在接下來要做的最重要的事情上，而不是他們腦子里幾乎無窮無盡的想法。從“把所有東西都做出來”到“接下來要做這個”的思維轉變有點困難，但這是讓開發(fā)人員過上美好生活最佳時機。當我們以協作的方式與領導者共事，而不是完全聽命于他們，就很有可能把這種焦點轉變過來。
通常，團隊所使用的“敏捷”方法是被強加的。大規(guī)模“敏捷”方法實際上就是建議強加流程，包括所謂的“SAFe”、可伸縮 Scrum，等等。這些都是針對企業(yè)的，要求企業(yè)去“推行”它們。
作為一名開發(fā)人員，你可以肯定這種方式不會得到順利推行，也不會實現真正的敏捷。你可能接受不到培訓，在工作上也獲取不到必要的幫助。你的領導可能會接受培訓，一培訓就是一兩周，他們?yōu)檫@些即將給產品和軟件開發(fā)帶來徹底改變的東西做足了準備。但這條路可能有點難走。
不過，如果你能夠穩(wěn)定地在每一個 Sprint 里把工作做好，把系統(tǒng)打包，運行、測試、集成，然后等待發(fā)布，就有可能獲得最好的結果。
如果你做不到，我建議你還是在每一個 Sprint 里少做一些事情，直到可以把這一階段內的東西都做好。但這也很難！因為人們會催促你，要你盡全力往前趕。頂著壓力超負荷運作，還不如每次只完成一兩件事情，等把它們都做好了，再去做其他的，那么在 Sprint 結束的時候，你才有已經完成的東西拿出手。坦然接受因為未能完成所有事情而遭受的指責，試著讓計劃和期望更接近現實情況，而不是那些你永遠都沒有機會去做的東西。
事情不會那么完美，而且在一段時間內，也不會那么有趣，但這是我所知道的最好的生存契機。完成可運行的產品片段是扭轉局勢最好的方式。如果情況不妙，我們所能做的就是盡我們所能，讓事情盡可能好起來。
很顯然，在一家開明或者有持續(xù)學習意愿的企業(yè)，很多東西都會對真正的敏捷持開放態(tài)度。生活會更美好，我也希望如此。
我經歷過這些，我知道最好的方式是把工作做好，保持軟件的可見性，讓它運行起來，進行測試和集成，并幫助人們認清現實。
敏捷宣言呼吁團隊的“自我組織”能力，在最好的情況下，就是指團隊可以選擇自己的流程。如果我自己創(chuàng)辦一家公司，我會讓團隊自己選擇他們想要的流程。
當然，還是有一些限制的，但這種限制不在乎他們的工作方式，而在乎我需要看到什么。我會告訴他們，最多每兩周我需要評審一下他們完成的產品片段。他們需要向我展示他們的計劃以及已經完成的東西。產品片段必須是可運行的，并且包含我能夠看到和理解的功能。我們會討論下一階段需要做哪些事情。我還會告訴他們，如果一周可以完成，就不要做兩周，如果一天可以完成，就不要做一周。
我會給他們提供幫助，讓對產品需求很了解的人幫助他們決定后續(xù)的工作。我會給他們提供培訓和支持，幫助他們更好地完成工作。我會確保他們有能力去完成我所要求的事情。
當然，我之所以這么做，是因為我心里很清楚這些事情。你可能也會很幸運地遇到類似的情況，至少，你可以選擇自己的流程。
如果你有機會做出選擇，我建議從極限編程開始。極限編程提供了必要的計劃和反饋閉環(huán)，還提供了一些基本的技術實踐，這些技術實踐是你完成目標所必需的。
另外，我建議你時刻對你的需要的東西保持警惕。在我看來，“ATDD、TDD 和重構”這些東西正是你需要的。當然，除了這些，你還需要其他很多東西。保持警惕，當它們出現時，抓住它們。
追求卓越的軟件開發(fā)是一項終生的活動，即使是極限編程也只觸及到表面而已。是否能夠走向卓越，這取決于你的團隊。
除了極限編程（我們可以把它看成是一種思想而不是方法），我認為開發(fā)人員不要拘泥于任何一種“敏捷”方法。正如這些方法在實際當中所體現的那樣，它們通常是開發(fā)者的敵人，而不是朋友。
不過，敏捷宣言的價值和原則仍然是用來指導軟件開發(fā)的好方法。從我長久以來的經驗來看，無論企業(yè)使用了哪一種方法，我都會遵循敏捷宣言的價值和原則。
我把這些作為建議提出來，如果你覺得適合你，可以嘗試一下。
https://ronjeffries.com/articles/018-01ff/abandon-1/
