敏捷開發（agile development）概念從2023年初開始廣為流行。bailar非常支援這一理論，他採取了"敏捷方式"組建團隊：capital one的"敏捷團隊"包括3名業務人員、兩名操作人員和5～7名it人員，其中包括1個業務資訊指導（實際上是業務部門和it部門之間的"翻譯者"）；另外，還有乙個由專案經理和至少80名開發人員組成的團隊。這些開發人員都曾被bailar送去參加過"敏捷開發"的培訓，具備相關的技能。
每個團隊都有自己的敏捷指導（bailar聘用了20個敏捷指導），他的工作是關注流程並提供建議和支援。最初提出的需求被歸納成乙個目標、一堆記錄詳細需要的卡片及一些供參考的原型和模板。在整個專案階段，團隊人員密切合作，開發有規律地停頓--在9周開發過程中停頓3～4次，以評估過程及決定需求變更是否必要。在capital one，大的it專案會被拆分成多個子專案，安排給各"敏捷團隊"，這種方式在"敏捷開發"中叫"蜂巢式（swarming）"，所有過程由一名專案經理控制。
為了檢驗這個系統的效果，bailar將專案拆分，從舊的"瀑布式"開發轉變為"並列式"開發，形成了"敏捷開發"所倡導的精幹而靈活的開發團隊，並將開發階段分成30天乙個週期，進行"衝刺"--每個衝刺始於乙個啟動會議，到下個衝刺前結束。
在bailar將其與傳統的開發方式做了對比後，他感到非常興奮--"敏捷開發"使開發時間減少了30%～40%，有時甚至接近50%，提高了交付產品的質量。"不過，有些需求不能用敏捷開發來處理。" bailar承認，"敏捷開發"也有侷限性，比如對那些不明確、優先權不清楚的需求或處於"較快、較便宜、較優"的三角架構中卻不能排列出三者優先順序的需求。此外，他覺得大型專案或有特殊規則的需求的專案，更適宜採用傳統的開發方式。儘管描述需求一直是件困難的事，但經過陣痛之後，需求處理流程會讓cio受益匪淺。
敏捷開發是由一些業界專家針對一些企業現狀提出了一些讓軟體開發團隊具有快速工作、響應變化能力的價值觀和原則，並於2001初成立了敏捷聯盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟體開發方法。通過這項工作，他們認為：
個體和互動 勝過 過程和工具
可以工作的軟體 勝過 面面俱到的文件
客戶合作 勝過 合同談判
響應變化 勝過 遵循計畫
並提出了以下遵循的原則：
我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意。
即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。
圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。
在團隊內部，最具有效果並富有效率的傳遞資訊的方法，就是面對面的交談。
工作的軟體是首要的進度度量標準。
敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持乙個長期的、恆定的開發速度。
不斷地關注優秀的技能和好的設計會增強敏捷能力。
簡單是最根本的。
最好的構架、需求和設計出於自組織團隊。
每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。
敏捷開發（一）敏捷開發和Scrum
工作的軟體是首要 進度度量標準。敏捷過程 提倡可持續的開發速度。責任人 開發者和使用者應該能夠保持乙個長期的 恆定的開發速度。不斷地關注 優秀的技能和好的設計會增強敏捷能力 簡單 盡最大可能減少不必要的工作 是根本的。最好的構架 需求和設計出自與 自組織的團隊。每隔一定時間，團隊會在如何才能更有效地...
敏捷開發分享 一
三 敏捷與傳統 什麼是專案?事先規劃好的工作計畫,需要在定義好的時間 工作量和計畫下去完成。專案有其目的和目標，並 且經常必須在限定的時間和預算內完成 什麼是專案管理?用於完成乙個專案的過程。什麼是專案管理?用於完成乙個專案的過程。什麼是敏捷專案管理?這種專案管理的風格專注於商業價值的盡早交付 專案...
敏捷開發實錄 一
記錄一下敏捷開發的一些過程，因為沒有實實在在的走這個流程，新公司會按這個模式開發，自己也很有興趣，因為之前也帶了一年多專案，也曾深陷泥淖，所以很期待這個模式下的開發實踐帶來的效果。在迭代計畫會上，產品負責人講解迭代要開發的條目，團隊進行估算並放入下乙個迭代。在這產品負責人建立條目化的產品待開發項，並...