目前軟件開發業界已存在多種開發合作模式，各有其特點、適用性和侷限性，沒有一種開發模式是通用又完美的，可以適用任何組織、任何業務的研發協作。所以每個公司研發組織要根據自身業務特點、自身組織實際情況來採用合適的開發管理模式。
對於大多數開發人員來說，對敏捷開發的思想、方法論大多略有研究。敏捷開發提到的相關原則，敏捷開發模式應用到實際開發過程中，實施起來或多或少與理論存在差異。所謂理論結合實際，作爲開發人員或者開發組織來說，不可完全照搬。
敏捷開發實施背景
敏捷開發模式，總體來說適合迭代演進的產品項目。相對來說ToC的業務應用應開發採用的比較多，因爲產品需求一開始不明確、市場變化快，需要快速對客戶反饋進行響應，產品需不斷迭代完善調整。當然敏捷開發也適合ToB的輕流程或面向互聯網相關業務應用、業務總體流程不復雜，應用業務之間關係相對比較獨立，可分段式推進上線。
產品項目研發採用敏捷開發模式，首先得建立符合敏捷開發模式的組織團隊，強調團隊穩定、目標明確協作一體化，團隊參與全過程、爲質量負責。本文對相關業界提到的敏捷開發原則並結合以往實際產品項目開發實施經驗進行總結，僅代表個人觀點，僅供大家參考。
儘早交付
“我們優先要做的是通過儘早的、持續的交付有價值的軟件來使客戶滿意。”
傳統的瀑布式開發模式涉及到多個環節，整個研發週期過長，中間環節都可能會發生各種不可預期的因素，最後交付大批量的成果給到客戶進行試運行，等待反饋，來回的週期往往超出預想的計劃，對於需要敏捷響應的業務不太適合。
實際很多項目產品後期交付給客戶試運行經常發生反覆調整，加上中間響應過程過於繁瑣，造成雙發的滿意度、成就感都很差。
當然傳統的瀑布式開發模式運用多年，每個開發組織經過多年也積累相當的經驗，形成了一定的風控經驗措施，還是適合一些特定客戶特定業務的產品研發，但始終存在多環節帶來的週期不可控風險、風控成本不確定的弱點，不太適合目前對週期要求快速響應的業務應用。
敏捷開發中強調持續集成交付有價值的成果。把產品項目整個任務進行拆分成多個小批量目標，根據優先級進行迭代式推進，每個小批量任務完成後都是可交付給到客戶使用的，縮短客戶等待週期反饋週期，及時根據反饋結果進行調整，以此達到客戶滿意度。
在實際產品項目開發採用敏捷開發模式過程中，經常碰到很多對交付成果反饋並不敏捷的情況，ToB應用這種情況比較多，有客戶因素也有團隊因素。
同時，迭代劃分規劃也存在不夠合理情況，例如：人員因素、外界因素、技術因素等等。
組織內部的迭代測試與開發過程經常性交接不順，很多敏捷開發團隊共享一個測試團隊，無法持續的交付可使用的成果，，甚至最終還是採取瀑布式驗收模式，ToB應用這種情況比較多，到最後才統一進行試運行使用，客戶滿意度也不高。
不論產品還是項目，對於敏捷開發模式運用，都需儘可能讓需求提出者、敏捷開發團隊組織等參與整個過程，儘早提供給最終用戶（客戶）使用已取得反饋進行優化調整。但這些都是現實中採用敏捷開發模式會碰到的難點。
不畏調整
“即使到了開發的後期，也歡迎改變需求。”
傳統項目瀑布型開發模式，基本前期階段需求調研製定需花費大量時間，目標已基本明確，需求方基本需求已定，基本上不會發生大的變化，進入里程碑的階段，再在進入後續階段。
但實際很多項目產品按前期需求完成後，在交付運行期間往往存在需求變更、調整等，ToB項目因爲多種因素，所以這種情況比較多，“改或不改”變成了後面與客戶的博弈。但總體來說項目每一期的需求範圍不會發生太大的變化，如果發生很大的變更，一般會採取商務手段，將變更納入下一期項目的目標或者新的項目。
實際上大部分團隊，目前有些應用業務產品受到市場用戶反饋影響很大，長期目標並不太明確，以需求爲依據，需要根據市場反饋快速反應調整，因此採用敏捷開發模式，特別對於ToC業務，需要快速迭代、持續交付，滿足最終用戶的需求。
爲了擁抱變化，讓產品有持續生命力，所以對於某個項目產品的敏捷開發，到後期也是歡迎需求調整的。
分解規模，增量發佈
“經常性地交付，交付的時間間隔越短越好，可以從幾周到幾個月。”
敏捷開發強調持續集成並推進持續交付，使用分解成小批量任務進行增量發佈，而非大規模的作業和瀑布流程的發佈。
開發團隊通過提供最小化可用產品獲取用戶反饋，並在這個最小化可行產品上持續快速迭代，直到一個相對穩定的階段產品。因此交付的週期間隔越短，持續迭代收集的反饋速度越快，及時對產品項目進行調整，則能快速提升產品的市場競爭力。
通常敏捷開發每個迭代週期基本一致，便於定位每次迭代的主要目標。對於迭代的規劃、目標任務項分配和調整產品組織者或項目開發團隊的能力，迭代週期基本保持一致主要爲了控制開發的節奏。
現實中我們在產品項目採用敏捷開發模式後，我們更多采用先業務模塊垂直劃分，再考慮業務模塊協作，以此爲基礎來進行細化定義任務項。根據優先級分配到不同迭代中去，每個迭代週期可以沿用目前大部分公司保留的工作管理模式和習慣，結合關鍵里程碑，一週一個小迭代，一月一個大迭代，而不是全面推倒以往的工作計劃管理模式，同時引入版本概念。
如果要保證不同業務模塊可以分配到不同小團隊，那需要把模塊協作的點在關鍵迭代中合理分配，同時關注關鍵里程碑，儘可能保證每次交付成果有成效，也縮短每次交付的間隔時間。
打破職能，全員參與
“在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。”
採用敏捷開發模式，原來按職能規劃的團隊組織必須調整，全部團隊成員必須貫穿項目，對項目最終質量負責。
由於敏捷開發強調持續迭代開發、快速交付，因此人員角色職能可以模糊化，一起做好軟件的質量保證。例如業務人員不再是一個需求提出者，需要全程持續的對項目產品階段性目標提出建議，也需參與到項目產品階段的設計評審、質量的驗證測試等。
敏捷的組織文化中，相對以往的瀑布流程，敏捷更關注人，因此敏捷測試組織應該以人爲導向，是一種驅動、自組織、協作式的文化氛圍。
實際上每個公司在敏捷模式實施過程中，根據的自身實際情況和成本考慮，要求組織成員天天在一起工作難免過於理想，經常會作一些妥協（包括組織成員可能屬於多個敏捷團隊、地點因素、任務時間因素），但總體要求敏捷團隊所有成員能夠做到高頻率、高效的溝通，例如必須參與每日站立會溝通等。
敏捷的組織文化對很多開發組織是一個持續改進過程。
人人都可構建，快速驗證
“圍繞被激勵的個人來構建項目。”
敏捷開發模式要求打破團隊成員以往的職能劃分、團隊共同協作，都爲了項目質量負責。因此勢必需要搭建好的工具鏈或者完善DevOps平臺，實現持續集成、持續交付自動化，人人都可構建，快速驗證，提供可交付使用的產物。
實際中很多開發組織的工具鏈不完善或環節割裂，無法做到全鏈路打通、自動化，缺乏統一的DevOps工具平臺等，後續需要不斷的優化過程和工具平臺等。
面對面交談，有效傳遞信息
“在團隊內部，最具有效果並且富有效率的傳遞信息的方法，就是面對面的交談。”
以往項目的傳統開發模式，項目每個階段涉及其對應的職能專業人員，每個階段的主要成員通常在很少參與其他不同階段，不排除有些成員身兼多角色。因此在每個環節間溝通流程上會存在一些瓶頸風險，例如：文檔不明確、人員協調、時間協調等，導致效率低下，溝通繁瑣週期過長。
對於敏捷開發，要求不斷的迭代式往前推，每個迭代週期都不長，所以要求講究高效，簡化溝通流程，減少各環節間的時間浪費。由於敏捷團隊成員經常性在一起，可以通過每日站立會等方式進行面對面溝通，這樣反而是最節約時間、最有效率的方式。
關注交付成果，關注用戶反饋
“工作交付的軟件是首要的度量標準。”
在現實中，任何項目產品是否達成目標，必須交付給客戶使用，取得了反饋纔是代表開發進度完成。
對於敏捷開發模式來說，不斷的持續迭代交付，不斷持續提供的階段性可使用、可運行起來的產品成果，纔是評估敏捷開發的迭代進度是否有效，同時交付作爲敏捷開發其完成度的度量評審依據之一。
對於產品來說，用戶反饋結果也是決定產品設計和後續計劃的調整依據，敏捷開發要求縮短每次交付的週期，持續增量發佈工作軟件，以取得用戶的反饋，以此作爲產品項目是否達到效果和後續調整的依據。因此產品的敏捷開發整個過程，要時刻關注交付成果；未運行未被用戶使用，則不能稱之爲交付成功。
平穩的開發節奏
“敏捷過程提倡平穩的開發節奏，發起人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。”
具體每個項目開展，在現實開發過程中，要求每個迭代都是恆定的週期，這對於產品規劃和實施開發迭代計劃有一定能力要求和難度；敏捷開發組織在全程都要時刻關注迭代規劃週期合理性，保證敏捷團隊可持續交付、用戶可持續快速反饋等。
現實中在項目產品開展後，每個項目的敏捷開發團隊成員基本可確定和穩定擴展。爲保證項目產品開展順利、每個迭代規劃是否合理十分重要。恆定的迭代週期很重要，可保證團隊的節奏，但這並不容易，比較理想化。
實際中還是存在一些預期週期的deadline、關鍵里程碑的檢查點，所以根據這些前提反推，對於業務規劃迭代涉及的任務項取捨很重要，關注每個迭代的業務重點和目標。
關注優秀技能和好的設計
“不斷地關注優秀的技能和好的設計會增強敏捷能力。”
敏捷組織是以人爲導向的，注重團隊協作，一起爲質量負責，爲持續交付高質量的軟件成果給到客戶使用、而不是持續交付質量不好的軟件。
現實中不可能每次交付都能達到一個完美的成果讓客戶滿意，造成新迭代推遲，這要求敏捷團隊成員不斷的在實施過程中進行學習、總結經驗，提升團隊自身技能，完善問題處理跟蹤機制，不斷增強團隊技術能力等，同時也要依據敏捷組織的技能方向推進深度學習研究。
敏捷開發要求快速迭代，快速交付週期性成果，增強敏捷團隊自身能力以便縮短每個迭代週期，增強應對能力，快速應對市場反饋。同時敏捷組織也是不斷改進成長演進的，因此提升團隊能力也是一個持續不間斷的過程。
簡單化是根本
“以簡單化爲根本，不做過度設計和預測。”
傳統項目的瀑布開發模式，由於項目需求範圍基本明確確定，所以完善的設計階段是一個關鍵環節，後續具體開發環節以此爲標準來開展。
而敏捷開發強調迭代式開發、持續交付，產品項目的目標預期和需求存在不確定性，需要能根據市場或用戶反饋及時調整發生變更，因此過渡設計或預測不適合，只作適度的設計便於後續迭代快速響應調整，同時節約一些不必要的資源投入和時間成本。
把過程簡單化是敏捷開發模式推進的一個原則。由於團隊常駐在一起、面對面溝通高效，不像以往瀑布式開發流程，所以不需要過度詳細的設計，有問題就直接面對面溝通，避免迭代中需求變更造成設計調整而引發的時間人力成本的過渡浪費。
在現實當中，實際產品或項目實施開發完成後，到達了一定運行穩定階段後，還是需要補充相關的設計文檔等，只是把該過程後置了。因爲驗收需要、宣傳需要、知識轉移需要、歸檔文檔需求、未來團隊內部培訓等，因而實際敏捷開發推廣、工作協作過程可以簡化，但有些關鍵性結果產物還是不可簡化。
構架、需求和設計源於自組織團隊
“最好的構架、需求和設計出自於自組織的團隊。”
敏捷要求根據反饋及時響應，不斷快速迭代調整。爲達到目標，保證敏捷高效，往往自身的團隊參與整個產品項目全過程是最優的模式，也可保質保量。自身團隊的需求規劃、設計更容易高效的快速調整，減少不必要的間接溝通成本。對於敏捷開發模式來說要求精益化，減少不必要的過程和週期。
團隊外人員存在不穩定性，在很多公司，項目間的人員複用是很常見，跟公司成本、資源有關，有可能在時間、工作安排上存在衝突，會給敏捷開發團隊協作帶來一定不可控風險。溝通流程不順暢、協調週期長帶來溝通成本等，都會對敏捷開發造成影響。
總結一句：自己的總是最可控的。
定時反思、檢討
“每隔一定時間，團隊會在如何才能更有效地工作方面進行反思並對自己的行爲進行相應調整。”
實際在推進敏捷開發的模式時，完全按照敏捷開發的敏捷理念及方法論進行團隊搭建、改造和實施，一步到位是不可能的。存在團隊組織因素、職責轉換因素、人員能力因素、產品項目業務因素等，包括公司的組織架構和管理制度規範都涉及可能調整。
只有產品項目開發實施過程中逐步的進行敏捷開發模式推進，不斷迭代調整，對問題進行收集，總結出每次存在問題的原因，後續進行改進。例如：如何推廣敏捷文化、搭建合理敏捷組織、規劃資源安排、協調各角色的工作安排、問題管理、平臺搭建改進、協作規範制定等等。
總之敏捷組織團隊定期自我反思和調整改進是很有必要的。
總結
產品項目實施開發模式有很多種，敏捷開發模式只是其中一種，有其前提條件、適用性和約束條件，是目前大多數公司採用的方式，每家公司落地成效也不盡相同。總之，敏捷開發模式落地是一個不斷持續改進和優化的過程。
以上分享的是將敏捷開發相關的原則進行自己的理解闡述，如有更多的想法和更進一步的學習，歡迎聯繫我們交流探討。
作者：陳楚相
出品：嘉爲科技