敏捷和精實開發是一種行之有效的軟體創建模型。數以萬計的軟體工程師理解並看到了使用這種軟體開發方式的好處。敏捷具有增加協作，提高質量及提高士氣的優勢。但是，對於研發團隊以外的人來說，什麼是最重要的？最終，由於構成其基礎的原則，敏捷會帶來成本節省的效益。
敏捷和精實開發的基礎原則是什麼呢？下面讓我們帶過這些基礎原則並使用這些原則與軟體開發成本的連貫性來做舉例。
＞簡化和"剛剛好" (Simplicity and “Just Enough”)：從團隊流程（ex: Scrum）到開發實踐（ex: 可以很好地完成一件事情的小型單元測試），敏捷中的一切都刻意做的簡單不複雜（請注意：這並不意味著容易）。透過做最簡單的事情來獲得結果是最具成本效益的方法–做到剛剛好時就停下來，並避免過度設計（over-engineering）解決方案，這會導致錯過最後期限和隨後的成本超支。
＞商業價值/消除浪費 (Business Value / Eliminate Waste)：敏捷宣言（Agile Manifesto）的其中一個重要元素是「可用的軟體重於詳盡的文件」（Working software over comprehensive documentation）。軟體開發前的大量文件增加了成本，實際上的價值卻沒有隨之增加。這些從未使用過的大量文件是種浪費。通過關注每項活動的商業價值，開發團隊可以降低成本超支的風險，並避免無法提供價值的昂貴活動。順帶一提：“敏捷”不是說不製作文件，而是建立“剛剛好”足夠使用的文件以滿足需求。
＞在過程中保持品質（Quality Throughout）：敏捷鼓勵完成小批量的工作。儘管工作“完成”的定義對每個團隊來說都是主觀的，但敏捷團隊通常會在2-3週的迭代（iteration）中使自己保持較高的品質。這有助於最小化技術債（technical debt）。技術債的定義是那些需要被盡快解決的技術問題。舉例來說，團隊剛發現了一個新的bug但直到幾個月後才決定去動手修復他。幾個月後在開發人員準備動手前會需要重新去學習了解與bug所在的區域相關的程式碼，這會導致開發人員的大型上下文切換，從而延長了診斷及修復缺陷的時間，最終結果是大幅增加了開發成本。
＞承諾與責任（Commitment and Accountability）：與如瀑布法之類的古老開發模型相比，敏捷中的承諾要小得多。要求團隊提前18個月以固定的日期，固定的功能和固定的開發預算承諾一組可交付成果是不切實際的。由於團隊基本上是為失敗做好準備的，因此延遲交付的成本（cost of delay）會因錯過交付日期而持續增加。團隊若忽視質量，客戶滿意度就會下降，從而影響銷售和營收。敏捷鼓勵具有長期目標的較短期承諾（例如季度），並使人們對實現這些目標負責。開發人員對較短期的承諾負責是相對容易的，並且可以更準確，更自信地估算工作。
＞快速跌代的交付（Rapid and Iterative Delivery）：軟體的快速交付可以實現快速的反饋週期（feedback cycle），從而降低了建構無法解決用戶問題的錯誤功能之風險。在見到實品之前客戶通常無法精準地說出他們要的是什麼。快速交付提供用戶見到實品的機會，並且團隊可以根據反饋進行迭代，並有助於確保我們不會去建構那些不會被使用到的功能。儘管通常會花費一些時間基於用戶反饋對軟體進行重新設計，但整體成本會比花費了較長時間（例如數個月）去交付更多功能並在用戶反饋後發現要在功能上做重新設計還來的低上許多。
＞合作與透明度（Collaboration and Transparency）：敏捷和精實團隊在工作上通常比在其他開發模型下能更有效地進行協作。敏捷鼓勵這種協作方式並有相應使用的工具。例如：比起需要花費數週的時間來編寫且可能編寫完正要列印出來就已過時的破百頁需求規範，敏捷團隊利用用戶故事（User Story）來開始對話並就需要實時構建的內容進行協作。這意味著更快的上市時間，這會幫助到產出的銷售。
＞此外，敏捷確實地消除了專案長期進行所需的專案經理角色，這意味著在人力資源上潛在的成本節省。由於敏捷團隊的工作進度是透明的，沒有中階管理人員需要和以前一樣四處奔波並不斷地收集狀態報告。取而代之的是，團隊可以使用類似Jira這樣的軟體管理工具並通過點擊按鈕取得開發狀態和不同的指標，而使用實體看板（ex: Scrum Board, Kanban Board...）的團隊每天都能在牆面上的看板取得明顯的狀態資訊更新。這些都減少了組織的經常支出（overhead）。
＞持續性的改善（Continuous Improvement）：回顧會議（Retrospective）是最重要的敏捷實踐之一。在這裡，團隊批判性地回顧最近一次的發展週期，並採取建設性的行動來改善現有的工作方式。高效的回顧會議取決於結果與成本。該活動引導團隊去自動化更多在過去容易造成人為失誤及低效率工作的操作行為，例如部屬和測試。最終，組織會減少依賴生搬硬套的手動任務，反之加重依賴有能力自行運作的自動化行為，從而最大程度地節省開支，並能為精實團隊提供有效的交付（delivery）。而且舉例來說，一旦部署自動化，遷移到雲端主機代管服務（cloud hosting）也可以節省資本支出和營運支出。儘管雲端主機代管服務和成本模型並非歸因於敏捷開發，但敏捷幫助實現了它。
敏捷會影響公司的底線，對於領導者而言，了解他們能如何（How）為公司提供支持以及他們能為公司提供什麼樣（What）的支持至關重要。切記，僅僅因為一個團隊說它“敏捷”並不意味著這是事實。例如：僅擁有“每日立會（Daily Scrum）”並不能使團隊變得敏捷。要完全實現敏捷與精實軟體開發的成本優勢，團隊必須遵守核心原則。請以商業成果為導向（business-results-driven）的第三方敏捷教練來評估組織對敏捷的應用有助於實現敏捷和精實能帶來的成本效益。
關注我們