譯者 | 李睿

審校 | 孫淑娟

如今，很多開發(fā)人員將太多的注意力集中在敏捷慣例上，而敏捷宣言中提到的關(guān)鍵方面沒有根據(jù)它的重要性來考慮。  

敏捷實踐已經(jīng)在全球范圍內(nèi)采用。而許多企業(yè)都以敏捷為榮，并且以不同的方式實現(xiàn)它。這很好，但并沒有一個單一的方法來實現(xiàn)它，需要根據(jù)每個場景進行調(diào)整。

高級軟件工程師Jorge Fernández Rodríguez表示，過于關(guān)注敏捷的某些方面容易遺忘了另外一個關(guān)鍵方面。這不是什么新鮮事，但如果不考慮這一方面，發(fā)布軟件的新版本可能是一個永無止境的故事。這就是要在本文中解決的問題。  

但在深入研究之前，先回顧一下軟件開發(fā)的演變，先從瀑布和敏捷方法的誕生開始。

1.很久以前就采用瀑布方法  

許多在過去10年開始職業(yè)生涯的開發(fā)人員可能在敏捷環(huán)境中工作過。然而，敏捷并不總是存在。而在本世紀初，瀑布就是一種常見的做法。  

在瀑布方法中，應(yīng)用程序通常是作為一個整體進行規(guī)劃的，客戶可能需要幾個月才能看到一些可用的軟件。

開發(fā)計劃是作為一個項目進行的，而有了開頭，在理論上也有一個結(jié)束（有時可能是公司倒閉）。該項目分為以下幾個階段：

• 需求收集
• 系統(tǒng)設(shè)計
• 任務(wù)計劃
• 開發(fā)
• 測試和交付

每個階段通常由不同的人員進行。客戶在開始和結(jié)束時都參與了合同的簽署。如果項目成功完成，應(yīng)用程序就會部署到生產(chǎn)環(huán)境中，并且通常會移交給另一個團隊，該團隊將負責保持正常運行。  

眾所周知，這些做法造成了很多問題。其中一些是：  

收集所有需求、預(yù)先設(shè)計系統(tǒng)和規(guī)劃任務(wù)幾乎是不可能的，并且需要數(shù)周時間。  

每個階段的交接都會導(dǎo)致溝通不暢。  

交付產(chǎn)品需要很長時間，并且實施很多次，遠遠超出預(yù)期。

在預(yù)算和范圍內(nèi)結(jié)束也很困難。  

階段之間沒有反饋循環(huán)。很多時候，只有最后才有反饋。如果反饋是否定的，那么整個投資都失敗了。

2.敏捷解決關(guān)鍵問題  

Rodríguez表示，在他當初開始其職業(yè)生涯時就聽說一個新概念：敏捷。當時并不知道這是怎么回事。那時他專注于提高開發(fā)技能，并不太關(guān)心軟件開發(fā)方法。  

敏捷似乎解決了瀑布方法難以解決的許多問題，并迅速被采用。但許多人將其視為一種教條，認為采取一些慣例可以解決他們所有的問題。行業(yè)專家聽到的最多的是一些流行術(shù)語，如：“Scrum”、“極限編程（XP）”、“Sprint”、“Retro”、“ Grooming”，以及其他一些術(shù)語（后來發(fā)現(xiàn)它們與精益更相關(guān)），例如“看板”、“ 進行中的工作（WIP）”。

大多數(shù)這些流行術(shù)語本身并沒有告訴很多。在工作一段時間后，他開始對了解為什么很多企業(yè)都采用這些做法感興趣，所以開始深入研究這個話題。  

他在工作中理解了其中一些術(shù)語的含義，并且看到了很多討論：開發(fā)團隊應(yīng)該做Scrum、看板、極限編程（XP）還是其他？團隊每個Scrum應(yīng)該在每個慣例上花費多長時間？應(yīng)該談?wù)撌裁?？等等? 

他了解一些膚淺的信息，并且遺漏了一些信息。也許這是他的研究技能?；仡欉^去，發(fā)現(xiàn)不僅如此。  

當閱讀敏捷宣言時，他了解其中一件事是：“個人和交互優(yōu)于流程和工具”。  

在他工作的過程中，其印象是過于關(guān)注過程和慣例。這是第一個跡象表明，無論是谷歌的算法還是軟件行業(yè)的某些部分都在關(guān)注不太重要的主題。  

同樣值得澄清的是，有些人將這些原則解讀為“第二部分并不重要”。然而，正如他多次聽到的那樣，這些原則應(yīng)該被理解為：“盡管第二部分很重要，但第一部分更重要。”  

專注于敏捷的要點，與瀑布的主要區(qū)別之一是以增量的方式組織開發(fā)：應(yīng)用程序?qū)⒈粍澐譃榫哂袃?yōu)先級的小塊。每個塊都是在一個Sprint內(nèi)開發(fā)的（通常是1周或2周）。在每個Sprint之后，應(yīng)該為客戶提供應(yīng)用程序的功能版本?？蛻簦ɑ蛘咴谀承┣闆r下是業(yè)務(wù)代表）積極參與了該過程，因此可以盡早獲得反饋?？梢钥吹竭@些想法是如何解決瀑布方法出現(xiàn)的一些問題，它通過快速交付和通過早期獲得反饋來快速失敗。  

而在敏捷宣言中，其中一個價值觀是“歡迎不斷變化的需求，即使是在開發(fā)的后期”。一開始，Rodríguez無法理解這句話的含義，他不確定這是否是一個好主意。然而，在思考它并在敏捷環(huán)境中獲得不同的經(jīng)驗之后，他認為它是最重要的部分之一。重要的是要考慮到變化可能涉及領(lǐng)域的新特征和新概念，但也可能涉及現(xiàn)有行為和市場的變化等。  

因此，不僅在敏捷中快速行動很重要（盡早交付客戶需要的價值，通過早期反饋快速失?。?，而且對環(huán)境變化快速做出反應(yīng)也很重要。它們不是唯一重要的方面，但以下將重點關(guān)注這兩個方面。  

因此繼續(xù)這種軟件開發(fā)實踐的演變，提到一些主要有助于快速發(fā)展的改進。  

3.快速行動：軟件編碼和交付實踐的演變  

當時的工具并不容易采用敏捷實踐，例如頻繁部署。在過去的25年中出現(xiàn)了一些實踐和技術(shù)，以幫助開發(fā)團隊更快地發(fā)布軟件。其中一些是敏捷的結(jié)果，而另一些則是獨立出現(xiàn)的。  

Rodríguez簡要提及其中的一些技術(shù)及其好處，而沒有詳細說明。他認為大多數(shù)都是廣為人知的技術(shù)，但如果對人們來說是新技術(shù)，那么網(wǎng)上有很多資源可以找到更多信息：  

• 測試自動化通過防止大量錯誤和減少調(diào)試需求為開發(fā)人員提供信心。
• 版本控制幫助開發(fā)人員將更改追溯到添加時，輕松恢復(fù)更改，以更輕松的方式解決沖突，并且它是許多其他改進的基礎(chǔ)。
• 功能分支或與分支并行工作。具有并行性總是好的，這在很多情況下也帶來了一個新問題：當進行大量更改或長時間保持分支打開時，開發(fā)人員需要花費大量時間來集成這些更改。
• 功能標志。如果團隊需要長時間并行處理多個計劃，但希望避免長期存在的分支經(jīng)常出現(xiàn)的沖突，這是一個選項。
• 持續(xù)集成（CI）/持續(xù)交付（CD）。通過集成更改、運行測試和經(jīng)常部署，交付到生產(chǎn)的巨大障礙正在消失。
• 代碼審查/配對編程。多年前，每個開發(fā)人員都在自己開發(fā)，甚至是關(guān)鍵代碼。審查代碼不僅可以幫助開發(fā)人員更好地編碼，還可以分享知識、學習并減少遺漏重要內(nèi)容的可能性。Rodríguez認為這并不總是必要的，但與對長期存在的分支進行大型拉取請求相比，它可以提供優(yōu)勢，因為反饋是在編碼時提供的，避免了重新編寫代碼。
• 開發(fā)人員構(gòu)建并運行它。開發(fā)團隊也開始負責維護應(yīng)用程序。這很有意義，因為開發(fā)應(yīng)用程序的團隊比其他任何人都更能理解它，并且它帶來了幾個好處：
• 發(fā)現(xiàn)問題的時間更少。
• 解決問題時犯的錯誤更少。
• 在生產(chǎn)環(huán)境中處理問題會帶來寶貴的經(jīng)驗。這些有利于進一步的發(fā)展。
• 由于不再需要交接會議，因此節(jié)省了大量時間。
• 如果團隊進行隨叫隨到的工作，軟件的質(zhì)量可以進一步受益，因為每個人都會盡最大努力避免在不適當?shù)臅r間聯(lián)系。
• 團隊結(jié)構(gòu)的變化：組建小型、獨立、跨職能的產(chǎn)品團隊來打破IT孤島。
• 消除開發(fā)階段之間的交接可加快交付速度，并避免溝通不暢。
• 讓團隊更接近領(lǐng)域?qū)＜覍鉀Q方案的質(zhì)量產(chǎn)生積極影響，并通過減少場景切換等方式提高關(guān)注度。
• 它還促進了系統(tǒng)的模塊化（康威定律）。
• 需要注意的是，跨職能人員并不是指全棧人員，Rodríguez認為這非常困難，甚至會適得其反。“T型開發(fā)者”的想法可能更有趣。
• DevOps、容器、服務(wù)網(wǎng)格、分布式架構(gòu)和云平臺?；A(chǔ)設(shè)施變?yōu)樽灾?wù)（團隊無需等待服務(wù)器分配即可部署）。它還變得不可變、易于替換、提高安全性等等。
• 自動依賴項更新。
• 更好的監(jiān)控和事件管理，例如SLI/SLO、DORA指標和其他，以關(guān)閉反饋循環(huán)并做出更明智的決策。

除了這些實踐之外，新工具、IDE改進、框架、庫和語言演變使開發(fā)人員能夠加快軟件開發(fā)。  

如果企業(yè)采用上述大多數(shù)做法，這可能意味著軟件可以比以前更快地交付。而且這些更改不僅更快而且更安全，因為許多任務(wù)都被自動化或委派了。  

有些人可能會認為軟件交付就像閃電一樣快，對嗎？

根據(jù)Rodríguez的經(jīng)驗，即使遵循了這些做法，也可能需要很長時間才能實現(xiàn)價值。以下是一些案例：  

示例1：  

Rodríguez表示，他花費三天時間來理解必須修改的代碼。這是他第一次接觸到那個代碼。值得慶幸的是，他正在與非常了解該應(yīng)用程序的人一起工作。通過相應(yīng)的測試來實施主要更改花費了開發(fā)團隊兩周時間。最后，他們花費大約16周的時間在整個代碼中尋找錯誤并實施修復(fù)。  

正如人們所看到的，在第三點上花了很多時間。在這16周中，大約70%的人在尋找錯誤，大約20%的人理解開發(fā)人員發(fā)現(xiàn)的邏輯并考慮如何使其適應(yīng)新行為，3%的人用于編寫自動化測試，1%的人自己實施更改。  

以下是為什么花費這么長時間的一些原因：  

• 服務(wù)做的事情太多了。
• 代碼耦合非常緊密，因為代碼的不同部分發(fā)生了很多問題。
• 與此同時，代碼的內(nèi)聚性不是很強。處理同樣問題的邏輯被廣泛傳播。

示例2：  

Rodríguez表示，他們的研究團隊花費三天時間了解需要改變什么，并花費一天的時間來實施這些更改，并花費七天的時間讓測試再次通過。  

在這種情況下，開發(fā)人員正在修復(fù)代碼以前的錯誤。其中一些甚至沒有完全修復(fù)。很明顯，一些開發(fā)人員對這些技術(shù)還不夠熟悉。幸運的是，問題并不嚴重，客戶也沒有注意到。糟糕的是，它們在應(yīng)用新更改時突然出現(xiàn)，使得測試幾乎不可能，因此必須在完成任務(wù)之前修復(fù)它們。

另一個問題是堆棧不是最新的，開發(fā)團隊想要實施的許多解決方案都行不通。在這些情況下，可能看到大量時間被浪費在調(diào)試和理解需要調(diào)整的代碼上。  

除此之外，還有一些可以永遠運行的構(gòu)建通道（同一應(yīng)用程序中的大量代碼、緩慢或不穩(wěn)定的測試等）。  

4.而被遺忘的部分是...  

采用了許多圍繞軟件開發(fā)的實踐可以使其更快：敏捷、CI/CD、DevOps、團隊結(jié)構(gòu)等。但是，在更改現(xiàn)有代碼的同時保持現(xiàn)有代碼的工作可能是一場噩夢。大量時間仍然浪費在理解代碼和四處尋找錯誤上，盡管已經(jīng)存在了很多有用的實踐。與此同時，圍繞Scrum、看板、獨立團隊等有很多爭論，而且，正如以上提到的，敏捷宣言并沒有過多地關(guān)注特定的流程或儀式；它只是給出了一些一般性的想法。所以代碼（測試）質(zhì)量（尤其是靈活性）是敏捷中被忽略或遺忘的最重要部分之一。  

代碼質(zhì)量并不是敏捷的獨有問題，但它在這里尤其重要，甚至比傳統(tǒng)項目更重要。還有一種誤解是，在敏捷方法中，不需要在軟件架構(gòu)和設(shè)計上進行任何計劃或投入精力，但實際上恰恰相反。代碼經(jīng)常被擴展和調(diào)整，因此使系統(tǒng)易于更改至關(guān)重要，否則它們將使未來的開發(fā)變得非常緩慢。因此，對于敏捷開發(fā)，這句話的下一個迭代可能是：系統(tǒng)靈活性是敏捷中被忽略或遺忘的最重要部分之一。  

這并不是什么新鮮事。正如在以上內(nèi)容看到的，敏捷宣言中提到了這一點，但持續(xù)關(guān)注卓越的技術(shù)和良好的設(shè)計可以提高敏捷性。  

敏捷流程促進可持續(xù)發(fā)展。贊助商、開發(fā)人員和用戶應(yīng)該能夠無限期地保持恒定的速度。如果代碼混亂、難以理解和變化，團隊如何保持恒定的步伐？  

需要記住的是，質(zhì)量并不意味著復(fù)雜性。簡單也很重要：而簡單就是最大化未完成工作量的藝術(shù)。  

架構(gòu)通常與剛性和提前規(guī)劃有關(guān)，因為經(jīng)常想到難以改變的架構(gòu)。從這個角度來看，在敏捷環(huán)境中投入時間在架構(gòu)或設(shè)計上是沒有意義的，因為事情經(jīng)常發(fā)生變化。  

但是在軟件世界中，可以選擇讓選項保持開放并使更改更容易的架構(gòu)。事實上，敏捷促進了短期思維。眾所周知，預(yù)測并不容易，開發(fā)人員最終付出了代價，甚至不知道兩天后客戶會需要什么。  

對于沒有采用敏捷方法的開發(fā)人員來說，需要知道的是，高績效員工不必以速度換取穩(wěn)定性，反之亦然，因為通過提高質(zhì)量，可以實現(xiàn)兩全其美。

5.開發(fā)緩慢的后果  

隨著開發(fā)人員添加更多代碼，開發(fā)速度變得更慢，這不僅是開發(fā)人員的問題。每個利益相關(guān)者都用自己的方式說話，并且含義略有不同：  

• 對于用戶體驗（UX）實驗愛好者：實驗可能需要數(shù)周而不是數(shù)天。
• 對于產(chǎn)品愛好者：及時響應(yīng)市場/滿足客戶需求……會發(fā)生嗎？
• 對于管理者：目標缺失，工作積壓。
• 對于DevOps研究與評估( DORA )指標愛好者：部署頻率(DF)降低，變更的平均提前期(MLT)增加，變更失敗率(CFR)增加。
• 對于企業(yè)：即使開發(fā)人員有很好的想法，如果不能輕易地轉(zhuǎn)化為軟件，企業(yè)就會陷入困境。代碼將是一種責任而不是一種資產(chǎn)，與此同時，競爭對手可能會利用。
• 對于開發(fā)人員：不得不處理糟糕的代碼可能會導(dǎo)致開發(fā)人員精疲力盡。

所以很明顯開發(fā)速度會變慢，但幸運的是，如果投資于靈活的代碼，可以節(jié)省一些時間。  

然而，要讓一些人相信這一點并不容易。還有一個問題：僵化代碼的效果不是立竿見影的。從長遠來看，它們是可見的。在短期內(nèi)投資開發(fā)靈活的代碼可能看起來更慢。那么，誰愿意投資于沒有立竿見影的效果呢？很多人的想法大多是短期的，需要更多地了解代碼質(zhì)量將如何影響未來的發(fā)展。  

6.將剛性系統(tǒng)的影響與業(yè)務(wù)聯(lián)系起來  

嚴格的代碼對開發(fā)某個產(chǎn)品需要多長時間的影響并不容易被發(fā)現(xiàn)。因此，對業(yè)務(wù)的影響也不明顯。如果兩者之間沒有聯(lián)系，就很難讓人們相信擁有靈活系統(tǒng)的重要性。這是一個非常復(fù)雜的話題，但需要填補空白。  

DORA指標至少部分解決了這個問題。其代碼不是同質(zhì)的，代碼路由很慢，問題可能被發(fā)現(xiàn)得太晚。  

軟件架構(gòu)師Glenn Engstrand在他的演講中介紹的技術(shù)能力計劃（TCP）在微服務(wù)架構(gòu)中管理技術(shù)債務(wù)可能是一個起點。  

Rodríguez表示，他并沒有一個理想的解決方案，夢想有一個在每次提交后更新的分數(shù)，它可以用作估計未來任務(wù)需要多長時間才能完成的乘數(shù)。  

然而，想以一些關(guān)于如何提高代碼靈活性的簡單想法作為結(jié)束。

7.提高代碼靈活性的思路  

網(wǎng)上有很多關(guān)于代碼質(zhì)量的書籍和資源，因此就不再贅述：  

• 代碼需要易于理解。通過閱讀方法名稱，應(yīng)該清楚它的作用。例如，理解一種方法不應(yīng)超過10秒。
• 代碼需要模塊化。模塊，松散耦合，封裝。這適用于每個級別：系統(tǒng)、庫、包、類和方法。
• 代碼需要有凝聚力。每個部分只需要做一件事，并且做這件事的所有代碼都需要緊密結(jié)合在一起。
• 將業(yè)務(wù)邏輯與控制器、偵聽器、過濾器等框架結(jié)構(gòu)分開尤為重要。
• 代碼需要簡單（不要過度設(shè)計，不要強行引入設(shè)計模式）。
• 針對當前需求進行開發(fā)。當開發(fā)人員想：“如果我們需要X功能怎么辦？”，采用YAGNI。

對于測試，需要記住它們提供安全性，但它們抵制更改，并且可能會比生產(chǎn)代碼本身占用更多的時間，因此：

• 他們需要帶來足夠的價值。進行測試驅(qū)動開發(fā)（TDD）是一種可以幫助企業(yè)實現(xiàn)它的實踐。
• 如果他們測試實施細節(jié)，他們將很難改變。

很多單元測試來驗證提供內(nèi)部結(jié)果的代碼片段。這些代碼是開發(fā)人員組織代碼的結(jié)果。如果邏輯需要以不同的方式組織和移動，許多測試就會中斷。發(fā)生這種情況時，測試不再保護并且?guī)缀鹾翢o用處。它還給團隊額外的工作。因此，重要的是要考慮什么是實際的單位。在不得不多次重組代碼之后，Rodríguez表示一直在思考這個問題，開始認為單元的概念可能不僅僅是方法或類，而是可能需要從特性的角度來考慮。這可能聽起來很奇怪，并且類似于集成測試，但事實并非如此。

• 支持更簡單、更快速的測試：單元優(yōu)于集成。考慮應(yīng)用層面的集成；集成測試應(yīng)該處理單元測試中無法驗證的事情，例如與框架的集成。
• 在默認情況下，并非每個功能都需要端到端測試。它們對于可能危及生命、個人可識別信息(PII)至關(guān)重要、可能使企業(yè)損失大量資金或類似情況的功能非常重要。

8.結(jié)論  

如果開發(fā)人員需要經(jīng)常引入更改，保持系統(tǒng)的靈活性至關(guān)重要，就像在敏捷環(huán)境中一樣。否則在一段時間后，合并更改將變得越來越困難。其他做法將幫助暫時彌補這一點，但最終它們的影響將不那么顯著。很多時候，幫助開發(fā)人員保持代碼靈活性的實踐非常容易應(yīng)用。

每天都有更多的證據(jù)支持這樣一個事實，即質(zhì)量有助于保持持續(xù)的發(fā)展速度。此外出現(xiàn)了一些新的想法，可以將僵化代碼在業(yè)務(wù)中的作用聯(lián)系起來。

原文鏈接：https://dzone.com/articles/agile-forgotten-parts