敏捷軟體開發宣言是現正流行的開發精神。敏捷宣言雖然看起來有點抽象，其實背後有十二個原則：
我們最優先的任務，
是透過及早並持續地交付有價值的軟體
來滿足客戶需求。竭誠歡迎改變需求，甚至已處開發後期亦然。
敏捷流程掌控變更，以維護客戶的競爭優勢。經常交付可用的軟體，
頻率可以從數週到數個月，
以較短時間間隔為佳。
前三點原則，相信老闆聽到都會非常開心。相信這些不只是老闆想要的，團隊也非常想要。
開發者也希望寫好的程式能馬上被使用，並也能常常推出讓使用者滿意的新功能，設計人員、企劃人員亦是如此。
只要先有共識，我們就可以繼續看下去：
業務人員與開發者
必須在專案全程中天天一起工作。以積極的個人來建構專案，
給予他們所需的環境與支援，
並信任他們可以完成工作。面對面的溝通
是傳遞資訊給開發團隊及團隊成員之間
效率最高且效果最佳的方法。
大家都希望能做到持續交付（Continuous Delivery），但我們要做什麼事才能達成這個目標呢？
這三個原則告訴我們要持續溝通。為什麼會強調持續溝通呢？這裡來聊個小故事：
圖片來源：壹讀
有本很有名的漫畫叫火影忍者，裡面有個崇高的角色叫火影，而主角漩渦鳴人一開始則是個忍者學校裡的吊車尾學生。但鳴人在故事的中後期，成功的練成火影無法練成的忍術。這個吊車尾鳴人練習的方法是：影分身之術。它能創造另一個鳴人，並且擁有自己的意識，當解除忍術時，會將當時的記憶和知識傳回本體。反覆操作就能短時間得到更多練習經驗，因此最終學成了高難度的忍術。
我們來換成開發情境思考一下：團隊有十個人，如果是九個影分身加自己組成的，工作一天後解除影分身，就可以知道當下所有需求、邏輯、技術、知識、進度等等，而且也會知道目前狀況該做什麼樣的決策，比方說進度超前，可以多花時間在優化程式；或是進度落後，該思考如何用品質換時間等等。
畢竟這是漫畫，現實團隊十個成員都會是不同個體，而各自放在腦袋的東西，只要不溝通是不會有人知道的，如果決策者不注意警訊的話，很容易會因為資訊不足而下錯決定；而有持續溝通的團隊則會像鳴人一樣，將成為一個強大的自我組織團隊，持續為公司產生價值！
因此，持續溝通是非常重要的敏捷精神！
可用的軟體是最主要的進度量測方法。
敏捷程序提倡可持續的開發。
贊助者、開發者及使用者應當能不斷地維持穩定的步調。持續追求優越的技術與優良的設計，
以強化敏捷性。
能快速交付當然很好，但持續交付才是敏捷精神所提倡的。
為了要擁抱改變，在需求調整的過程中，技術債有可能會不斷產生，要如何做到持續？當然，除了團隊要追求技術之外，還要持續改善品質，才有辦法做到持續交付。
是的，為了改善品質，這時候我們就會需要重構！
精簡──或最大化未完成工作量之技藝──是不可或缺的。
最佳的架構、需求與設計皆來自於
能自我組織的團隊。團隊定期自省如何更有效率，
並據之適當地調整與修正自己的行為。
最後，團隊要有自信但不能自滿，隨時面對環境變化做調整，並持續精進個人技術，才是一個好的敏捷團隊。
許多敏捷開發方法的概念與重構在做的事很雷同，因此敏捷開發很適合使用重構，甚至會要求流程也要使用重構！
以下是幾個跟重構有相關的敏捷開發方法：
TDD（Test-driven development）與 BDD（Behavior-driven development）要求先要有規格，再開始寫程式，而最後再進行重構。換個角度來看，它們都是先處理簡單的目標，快速達成後，再開始改善架構。
雖然軟體是軟的，改善架構的難度理論上是簡單的，但只要範圍一大，難度就會指數性上升。 TDD / BDD 建議每做一個功能，就重構一次，只要有做到頻繁重構，每次重構的難度就不會太高－－因為每完成一個功能就立刻清理當下的技術債，就比較不容易被循環利息懲罰。
Scrum 支持先交付不完美、但可以操作的成品，接著得到使用者回饋，進而持續改善產品。
同樣地，重構也支持先設計不完美、但可以跑的程式，後續再做設計的改善。
iThome鐵人賽
看影片追技術