- 敏捷宣言
- 實踐
- 計劃
- 測試
- 回到開發本身：敏捷的設計
- 認清處境：敏捷團隊走向成熟的三個階段
- 認清邊界：目管理鐵三角：質量，價值，約束條件
- 敏捷的最終交付，代碼和軟件
- 微服務與敏捷開發
- 參考資料
如今軟件開發離不開“敏捷的話題”，既然離不開，那我們來深入的聊聊，到底什麼是敏捷。
關於敏捷我感覺我一直沒有深入理解，敏捷到底在敏捷什麼？我不由自主的有了一個疑問，一次評審，負責研發的同事說我們根本沒有敏捷，於是我便有了我這次的問題和理解。
敏捷宣言
從軟件開發的歷史：瀑布模型，增量開發,CMMI 等等軟件從開始到結束經歷的週期越來越長，開發過程越來越臃腫，現代的商業活動要求產品更快的能觸達到用戶並在現實環境中接受驗證並作出適時調整，持續完善。爲了解決膨脹的過程帶來的痛苦和不確定性，敏捷概念油然而生，敏捷的原則和價值觀構成了一個可以打破搓成膨脹循環的方法，敏捷的過程有XP極限編程， SCRUM，自適應軟件開發 等等其中應用最多的便是scrum
最終的目的是交付用戶可用的軟件，結果導向，落地，變想法爲現實，在這個前提下變有了一下知道的原則
1. 個體的交互，團隊的協作和溝通勝過過程和工具
過程爲結果服務，人是獲取成功的關鍵，團隊不一定非要一流的程序員，但要是優秀的團隊成員，他能夠友好的和他人合作，溝通，這些比編程能力更重要，不然一個項目很大程度上會跑偏，因爲任何一個人未完成，整個就不算完成
不要試圖單純的藉助工具和外力來解決當前之問題，要從問題的內在出發，去打通問題的核心流程，工具是外在的，內在恰如其分的架構和設計纔是解決問題的關鍵，不要認爲更好更大的工具能爲你自動的解決所有問題
- 不要試圖引入一個高性能的數據庫除非迫切且必要
- 不要試圖引入一個收費的商業工具除非迫切且必要
- 人與人之間交互是複雜的，人不是插入即兼容的編程裝置，上下文切換和多線程不會讓人的生產力有良好的促進，人需要聚焦，於此同時人一旦融入了場景之中發揮主觀能動的時候人的潛力似乎是不可限量的
2. 可工作的軟件勝過文檔，文檔也不是關鍵
直到十分迫切和意義重大時才編制文檔
3. 客戶和做勝過合同談判，從一錘定音不支持修改到擁抱變化持續優化，客戶和研發更緊密和頻繁的交流打在軟件從原型到雛形到成品，合同指導了這種寫作而不是視圖規定項目的範圍和固定的成本
- 任務列表是相當於一個合同，這個一定要是可以靈活變動的，不然就會有爲了進度犧牲質量和一系列其他東西
- 需求入組，產品和研發已經緊密的協作了
4. 響應變化：計劃不能太過遠，環境是變化的，需求可能也會跟着改變
當這些改變的時候，我們的看板，大白板，進度和進程就會不在適用，721原則，我們2周內做了詳細的計劃，並且有任務隊列和優先級下一個月甚至下三個月都有一個模糊的範圍
對於迫切的任務有詳盡的計劃，2周之外的計劃部分仍然保持靈活性準備結合環境來做出適時的調整
我們的客戶仍然不是最終付費的客戶，客戶是我們的需求開發人員，我沒又有走到價值的第一線去，這麼來說，我們的敏捷算不算真正的敏捷？？？不算吧
原則
1. 我們最優先要做的是通過儘早的，持續的交付有價值的軟件來使客戶滿意，因爲價值是由人來定義的
- 功能越少，質量越高（變動和風險在較小範圍內）
- 交付越頻繁，質量越高（變動和風險在較小範圍內）
2. 即便到了需求開發的後期也歡迎需求的變化，利用敏捷的過程爲客戶來創造競爭優勢
- 改變需求是好事，團隊學會如何滿足市場的需求
- 優秀的架構就是用來相應變化的不然那麼模式和設計毫無發揮之地，也促使開發提升
3. 交付間隔越小越好，交付滿足客戶需要的軟件
4. 業務人員和開發人員在一起工作，業務人員對軟件項目進行持續不斷的引導
5. 激勵團隊成員提供他們所需的環境，資源和支持，信任他們可以完成工作
6. 團隊內部最有效率的溝通就是面談，而不是文檔
7. 能夠工作的軟件是進度的衡量便準，代碼即文檔
8. 要可持續發展，責任人，開發，用戶能夠長期，恆定，敏捷不是短跑而是馬拉松，需要保持能量和精力
9.不斷關注優秀的技能和良好的設計，增強敏捷能力
10. 完成工作最大化的藝術是簡單，簡單是高階的複雜
不要嘗試整那些花裏呼少的東西，用最簡潔，最高效的方式完成任務
11. 最好的架構和需求和設計皆出自於自組織的團隊
如魚飲水冷暖自知，面臨什麼問題，需要什麼效果，我們由哪些限制，我們由哪些挑戰，這些第一現場做事的你最清楚，只有你從心出發，用心思考，才能達到恰如其分的優雅
12. 跟上情境的變化，每隔一段時間要進行反省，PDCA檢視並調整自己，組織方式，規則，規範，關係，隨環境一起變化，讓自身保持敏捷
我們的相關方是僱主和客戶，滿足他們的需求，爲他們提供可工作的軟件，增強他們在市場的競爭力是軟件開發人員的職業目標
敏捷方法並不會讓涉衆得到他們想要的，不過它意味着能夠以最小的代價獲取最大的商業價值
實踐
1. 客戶是團隊中的成員，參與軟件開發，引導軟件朝着預期的方向構建
2. 頻繁的交付並給客戶演示，得到反饋並修正
3.使用自動化和反覆的驗收測試方式，提效驗證環節
4. 敏捷模式下任務項目信息要透明，大家可以互相補位，互相評審和勘誤，每個人不會被限制在特定的領域，模塊沒有負責人，大家共同參與UI開發，數據庫設計，等等
5. 敏捷模式下優秀的工程師，技術不一定是最好的但是一定是善於溝通的
6. 持續構建，持續繼承，自動化發佈開發完成的功能
7.可持續的開發速度，不加班，保持精力和能量，保持旺盛的活力和敏銳的警覺應對今日的變化，做出抽象，簡潔的設計應對今日之需求，響應明日之變化
8. 簡單的設計，如無必要，保持簡單
- 使用能夠工作的最簡單方案
- 只有真正需要的時候在引入先進的工具，模式設計，等等
- 單一職責原則，多提煉抽象
9. 持續不斷的重構，持續的代碼持續的變化，跟上需求的變化，保持簡潔和表現力
10. 使用隱喻來將整個系統聯繫在一起，形成全局視圖，它將指導軟件按照藍圖來構建
我們用裝卸卡車運垃圾來比喻整個系統，緩衝區是小卡車，屏幕是垃圾場，程序員是垃圾製造者
所有名字互相吻合，這有助於我們從整體上進行思考和設計整個系統
計劃
1. 任務故事不能用數字表達就是不瞭解，就無法度量
2. 迭代任務要有彈性不是計劃了都要必須完成，這樣會導致犧牲軟件的質量和穩定性，併爲自己在將來埋下隱患
3. 任務分配要靈活，721法則 ：7 經典業務，2 創新和嘗試， 1 非功能改進
4. 迭代過程中段與客戶一起對任務進行檢視和調整，確保迭代完成能夠完成所有的任務和故事
5. 演示過後，客戶可以使用新的故事來提交反饋和改進
測試
自動化測試促進系統的高內聚低耦合，測試驅動的方式，會促使開發人員開發更加抽象和解耦的軟件，促進模塊之間隔離，從而改善整體軟件的設計和質量
代碼即文檔，單元測試和驗收測試也是一種可編譯可執行的文檔
回到開發本身：敏捷的設計
在前面敘述了那麼多，算是給敏捷的定了個性，什麼樣的是敏捷的，什麼樣是不敏捷的，那我們既然要向敏捷靠近，那應該如何做到呢？
認清處境：敏捷團隊走向成熟的三個階段
我們貌似還是停留在第一階段
認清邊界：目管理鐵三角：質量，價值，約束條件
清華大學管理學教授寧向東一針見血地指出，管理，其本質就是關於如何“破局”的智慧。所謂“局”就是管理者周圍的各種資源相互聯繫，相互作用的一種狀態。以上約束，也是軟件工程表現出來的組織複雜性，也是一種局。
在日常開發過程中，我們需要要找到固定的一條邊或兩條邊，然後去調整剩下的邊，最終達到平衡。
敏捷的最終交付，代碼和軟件
優秀建築師可落地的是宏偉的建築，優秀的廚師能夠做出美味的大餐，那敏捷的開發人員能夠產出什麼呢？
敏捷是在開發過程中敏捷，那最終產出還是代碼！
先前講了敏捷的原則和實踐，敏捷的判斷標準，敏捷過程中的流程和協作方式，那回到軟件本身，軟件是由代碼組成的，那開發人員構建什麼樣的代碼纔是敏捷的？
軟件構建是軟件交付最本質的要求，你得做出來先呀！那我們做出來的東西如何評判是好還是壞呢？
假如我們是給客戶加工蛋糕的小工廠，那用什麼樣的機制保證自己能夠交付優質且美味的蛋糕呢？我們得有一套最佳實踐和評判和勘誤的標準，告訴我們怎麼做才能做出好的東西，做出來後我們怎麼樣來確認我們確實做好了
噹噹噹噹噹噹，感謝無數軟件的先驅，軟件的前輩們已經總結出了一份標準告訴我們什麼樣的代碼是有臭味的，這樣的代碼和設計會阻止你走向敏捷
僵化性
脆弱性
牢固性
粘滯性
不必要的複雜
不必要的重複
晦澀
敏捷的設計是一個過程，持續的應用原則，模式，實踐來改進軟件的結構和可讀性，保持系統往簡潔，乾淨，富有表現力的方向發展
微服務與敏捷開發
微服務與敏捷十分適合的搭配
個人曾經思考了一個問題與大家分享和交流：敏捷開發倡導無需專人負責，代碼平權大家都可以提交，微服務的核心在於高內聚業務領域也就是說要持續的投入和深耕不斷重構纔可以，這二者有沒有衝突？
基於這個問題，經由思考並結合團隊目前的狀況來看，必須每個模塊有人負責纔行，業務領域需要持續的深耕和投入和打磨才能達到恰如其分的架構設計，現實中也是有幾個服務被幾個人共同開發，但是沒有人負責在這上面持續投入，導致這裏複製粘貼的代碼很多，代碼有粘連性，不精簡，幾乎沒有任何模式和設計，這塊功能後續勢必給整個系統帶來隱患。
但深入思考下，每個人的維護方式和編程範式和習慣不一樣，要如何能協同一個系統朝着既有的藍圖和設計進行演化呢？
這就需要有頂層設計，從整個業務和架構角度對系統進行規劃，劃分，約束和限制。
參考資料
績效考覈 – 敏捷轉型的鴻溝