如何成為一個出色的敏捷開發者 —— 把習慣變成理念
敏捷開發不僅僅與開發人員有關
沒有人希望自己交付出去的軟體充斥著大量的漏洞和效能問題，而且還沒能讓客戶滿意。持續整合和程式碼審閱可以防止這種情況的發生，但問題是誰有時間幹這些事，對吧？今天，敏捷團隊就能擠出時間。
敏捷開發者關注的是專案的可持續性發展——而不是個人英雄主義。可持續性關乎專案週期的估計是否準確，程式碼管理分支策略的有效性，自動化測試對程式碼質量的保證以及能快速獲得使用者反饋的持續部署。踐行可持續開發需要大家都認可的規範，但實際上，當大家各自為政時就很難達成共識。因為沒人能憑空搞敏捷開發，它一定需要整個團隊文化作為後盾。這就意味著得讓專案負責人明白質量可遠比範圍和進度重要，這通常就是踐行敏捷開發最麻煩的地方。
「CODING 企業版」作為企業級軟體研發管理系統，助力團隊敏捷開發轉型升級。
不過這麼做是值得的。開發人員可以因此獲得解脫，從而開發出更可靠的軟體，還能一直保持與業務的密切聯絡。而業務層面則可以向市場推出更高質量的產品，進一步增強業務與開發之間的聯絡。另外（這是敏捷開發最好的地方），敏捷開發者很少會面臨“死亡之旅”（譯者注：這是個軟體工程領域的玩笑，指專案要交付的最後幾個月大家拼死拼活加班趕專案）。我們有時為了保持專案的高質量而付出了比預期更多的努力，導致開發落後於預期進度，這種情況下專案管理鐵三角的“實現範圍”部分可以適當改變，這樣大家都能輕鬆些。
所有軟體開發人員都瞭解專案管理的“鐵三角”即：範圍，進度和質量。我們大多數人都參與過那種實現範圍死板，進度混亂並且工作量因技術債不斷增加而不堪重負的專案。還有比這更糟糕的，有時最終交付的產品根本不是市場所需要的。這些事想想就讓人深受打擊。
別擔心：這有個好訊息。
在敏捷開發中，實現範圍是可以動態變化的，這可以使團隊保證開發質量並營造出充滿活力的氛圍，同時還能兼顧與業務層面的密切聯絡。我們有充分的理由認為，敏捷是每一個開發團隊（也包括很多非開發團隊）的核心。
敏捷不僅僅是一系列套路，它更是一種文化和技術哲學。
它可以使開發者個人在自己的產品中建立堅實的技術基礎，並在團隊中樹立協作文化。敏捷團隊的開發者更加樂意於投入工作，編寫的程式碼質量也更高，獲得的樂趣也更多。
「CODING 企業版」提供強大又易用的 Code Review 程式碼審閱功能。
牢靠的團隊關係就意味著更好的產品
敏捷是關乎團隊合作的，這並不奇怪，因為今天的大多數軟體都是由團隊開發的。開發人員要與產品管理，設計，質量監控以及運維建立牢固的聯絡，編寫可持續程式碼即意味著與專案的各個方面保持聯絡。鼓勵開發人員直接和業務層面其他部門合作的公司，在程式碼質量和開發人員滿意度方面獲得了顯著的成效。比如：程式碼質量變得更好， “徒勞的努力”變少了（即重複工作或者工作流衝突），以及各部門之間有了更多的交流。
交流意見是很重要的。敏捷團隊會進行交叉訓練，以確保整個團隊都能理解程式碼的基本理念。這樣做的一種常見方式就是程式碼審閱，它不僅能保證程式碼質量，還可以使整個團隊都熟悉程式碼。無論以什麼方式推廣這種理念，敏捷團隊不會因為由於只有某些人能理解特定程式碼導致負責這些關鍵部分的開發人員沒法休息，誰也不想當這樣的程式設計師。
與瀑布模式開發的同行相比，敏捷開發者能夠更輕鬆地在產品技術棧的上下游切換工作，因為敏捷團隊可以自我組織，讓成員們有更多機會學會新技能。實際上，讓開發人員接觸從 UI 到資料庫的完整特性，可以讓他們對程式碼有更好的掌控。在提倡分享知識的團隊或公司，我們更能培養全棧工程師。
程式設計，理念以及使敏捷開發更出色
敏捷就是指在你的組織中要建立起一種偉大的發展文化。請繼續保持關注以瞭解更多有關有效分支策略，自動化測試技術，持續整合以及如何與其他業務部分建立有效聯絡的資訊。下一篇文章將深入討論數以千計的開發人員在敏捷開發轉型過程中所做的具體工作，以及敏捷理念是如何驅動專案的。
敏捷開發是一趟修煉之旅，我們會在每一步做你的後盾。
「CODING 企業版」提供全方位工具支援，研發流程全紀錄。