編程領域不僅僅關乎代碼。許多企業一開始都認為開發人員只需要學習編程語言就可以了。但是，要想讓開發人員效率更高，企業還必須了解代碼的細微差別及其與編碼內容的關系。

代碼不僅僅是代碼，它還編纂了規則，集成了人們對編程內容的理解與解讀。如果開發人員無法理解編程的內容，就無法高效地工作。

這也是為什么開發人員不僅僅是程序猿——他們的工作不僅限于根據給定的、相對模糊的營銷需求來敲鍵盤。雖然這種情況很常見，但事實上，開發人員絕不應止步于此——尤其是想成為一名敏捷的開發人員。

[[275427]]

對于敏捷的誤解

敏捷是一個有趣的詞。很多人都似乎“了解”它。企業更是深信不疑地認為自己在踐行這一點。但很多人都理解錯了。大部分情況下，敏捷變成了奇怪的瀑布式開發。一個項目被劃分為幾個階段，最后一次性交付給客戶，這種情況很常見。

在瀑布式開發，或者說偽敏捷開發中，開發人員都無法參與到中間流程中，只負責最后的流程。但開發人員不是泥瓦匠，也不應該被那樣對待。

當馬丁·福勒 、羅伯特·馬丁和其他15位軟件開發領軍者在《敏捷軟件開發宣言》上署名時，他們的側重點是革新軟件的開發方式，賦予開發人員在工作中更多的有效性與自主權。

這在一定程度上是因為他們認識到開發人員不是一味執行他人計劃的機器人。他們還是建筑師、工程師和建設者，通常被包裝成一個獨特的角色。他們是你的全棧工程師、軟件開發人員、IT運維技術人員和混合開發人員，有著交叉領域的知識和技術。他們是專業技術人才，也是通才。

企業如何改變這一現狀

如果開發人員覺得自己只是個程序猿，那么解決這一問題就是一個機構層面的過程和結構問題。如果你是小型初創企業的一員，處理這一問題可能要比思維模式根深蒂固、工作關系穩固的大企業容易一些。

敏捷開發的目的是通過循環交付為企業創造速度和流動性。與主流觀點相反，軟件從來都不是一個完整的產品。人們總是要對軟件做一些修改——無論是基于市場需求，還是由于不可預見的情況引起了錯誤，亦或是這一修改對公司發展至關重要。軟件開發中唯一的永恒的就是改變本身，這是無法避免的。

為了應對這些變化，開發團隊必須要小——那種人數在一位數或兩位數出頭、兩張披薩就可以管飽的小團隊。杰夫·貝佐斯稱之為“雙披薩原則”。一個大項目擁有多個團隊無可厚非，但關鍵是要把人數維持在最低標準，這樣才能實現成員間的有效溝通。

每個團隊可以在一個團隊主管或負責人的帶領下負責一個功能，但團隊主管或負責人必須有效地將戰略性開發計劃傳達給每一個成員。這點至關重要，因為它能讓開發人員提前構思代碼和結構，想出有效的自動化流程方法，使其輸出結果與企業需求保持一致。

自主、負責地創建代碼

代碼或許是開發人員創建的最終輸出，但它也受市場營銷、管理、商業團隊和任何關系到最終輸出的人的影響。當出現問題時，不能只責怪代碼。

最高效的開發人員也會參與到溝通、用戶故事創建、最終決策制定和交付功能排序等其他過程中。這種參與非常重要，因為它可以讓開發人員了解他們編碼的領域。如果開發人員不了解這一領域的知識和實踐，或者在這方面沒有牢固的基礎，那么他們必不能將企業的規則和要求有效地轉化為‘計算機語言’。

編程不僅僅是編程語言，還是對規則和期望的集成，同時也要讓電腦以人類能明白的方式去理解和重現這些規則與期望。如果代碼因開發人員對源代碼的誤解而出錯，假設他們的能力沒有問題，那么就是沒能準確理解企業對數字材料格式的需求。

對于別人的代碼又能做些什么呢?

有時，開發團隊可能繼承前一支團隊的代碼。這些代碼可能很好。但通常情況下，由于遺留方法、過時的格式和當時流行但現在低效的工程模式，這些代碼現在可能不適用了。

這種情況時常發生，尤其是對于那些在軟件開發行業干了很多年的人。雖然這些代碼是過時的產品，但企業及其團隊依然要對其負責。每個軟件、硬件和基礎架構都有保質期，超過了5年就要接受檢測，使其適應新的時代。還能用并不代表還能保持高效——這也可能成為團隊敏捷開發能力的主要瓶頸。

這一點開發人員最清楚，當參與更高層次的溝通和決策時，他們可以充分規劃更新并創建應急計劃，以降低遺留系統帶來的風險。直接在遺留系統中添加新功能無異于在檢查舊房子結構完整性之前拆除房梁。如果真的這樣做了，你永遠也不知道這個房子什么時候或是否會坍塌。

結語

代碼如同數字房地產，企業需要接受的事實是，開發人員不僅僅是程序猿。只有當開發人員被視為一個具有凝聚力、跨功能團隊的一員時，他們的編碼能力才會有效提高。

把開發人員都放到項目的末尾就如同憑借一些草圖和一塊平頂木板蓋房子。開發人員的職責是選擇、構建、美化及其中間的所有流程，最終將企業的理想轉化為現實。這就是為什么在項目開發周期中，盡早讓開發人員參與其中至關重要。