待業的日子--關於敏捷的總結

離職一個多月了。前幾天進行了第一次面試，問了下你以爲敏捷有什麼好處，還一下把我給問住了，因此特來寫篇博文梳理一下個人認識的敏捷。水平有限，敬請諒解。

 

背景

在我入職前，大版本的開發和交付要經歷較長的時間，質量很不穩定。因爲對軟件質量要求較高等各類緣由，沒人敢亂動亂碼， 可是新特性還要開發，致使整個代碼臃腫不堪，上千行的函數隨處可見。最後的最後，你們發現這不能忍啊，活無法幹下去了。

敏捷介入

公司花重金聘請了敏捷顧問團隊，跟項目組共同開發特性，進行一對一的敏捷培訓。效果上說仍是達到了目的，開發效率，產品質量都有了很大提升，支撐了以後多個版本的穩定開發和交付。敏捷顧問撤離，仍是保留了每日版本構建，項目組持續集成，狀態牆，TDD，結對編程，每日站會等敏捷實踐和活動。

價值思考

其實這一點我後續的實際體會很少，都是從老員工的講述中獲得的。敏捷顧問當時很是強調從價值出發去考慮問題，再分析特性的時候，會以」這個特性有什麼價值「、」這個特性不作會怎麼樣「、「這個特性要知足什麼目的」，「這個特性有反作用」這樣的思惟方式去思考特性的價值。這樣想清楚了纔會去思考方案有什麼，哪一個方案最合理。經過價值思考能夠明確特性開發完後軟件的外部行爲是什麼樣的，會引導你思考開發的代價，收益率這些問題。不過仍是作了不少沒用的特性，咱們都知道價值不大什麼沒價值，可是，哈哈。。

作一個剛恰好的軟件系統

在明確特性的價值和目的後，就要思考投入多少資源去作成什麼樣子了。一個僅僅用於演示和一個要在全球部署的特性固然是徹底不同的。一開始我以爲在早期作的好一點會更好吧。可是在後面的實際工做中，發現你的精力，資源都是有限的、總有人會提出垃圾的需求作完後被廢棄、還有就是把代碼寫好而後去擁抱變化吧。大型的軟件系統應該是逐步演進，那麼就沒必要糾結於一開他有多簡單了。

縱向劃分story

在劃分story的時候更習慣橫向地思惟方式。拿切蛋糕來做比喻，story應該是一小塊完整的蛋糕（可測試，可交付）；而不是被劃分紅水果層，奶油層，蛋糕坯。能夠工做的軟件賽過面面俱到的文檔。

各類自動化腳本工具

敏捷不光有一組理念，一些支撐這些理念的方法論，一堆支撐這些方法論的實踐，還有支撐實踐地工具。有現成的各類單元測試框架，有持續集成工具cruisecontrol等等，但也有不少不適用於本項目組甚至沒有的工具，就須要本身去開發不少腳本和工具來提升生產率。總之就是能用機器乾的，就別手工勞動。經過工具能夠很好地提升團隊的開發效率，更重要的是承載了處理問題的寶貴思路和經驗。

保證你們都清楚

早期開發和測試分家的時候，開發完了而後交給測試，而後各類bug，各類攻關關，各類延期，各類哈，身心憔悴啊。最崩潰的是開發認爲這不是問題，可是測試以爲這直接關乎x億用戶的正常使用啊。其實究竟是不是風險，影響有多大，誰知道呢，bug在運行幾年後才隨機出現，並且沒法復現的狀況有的是。因此理想的狀況是開發，測試，項目經理，維護等各路人馬對特性，目標，影響，潛在風險等都很是明瞭，甚至提出本身的意見使方案看起來是通過各個角度的深思熟慮的。後續由於實現、進度等緣由的變動也要及時知會，這樣，辛辛苦苦寫完代碼推翻重來的風險大大下降。在大公司，溝通永遠有着高昂的成本。

用例

我認爲用例是設計、實現層面最好的書面材料和溝通媒介。經過用例詳細描述特性或者問題修復後的軟件外部表現，提供明確的運行結果，直觀，無二義性，有說服力。後期若是能加入自動化用例庫，至少在版本發佈前你們內心都有底。若是護週期很長的軟件系統有很長的維護週期，自動化用例庫和團隊內部使用的形形色色的自動化工具，是最寶貴的資產。

TDD

先寫用例，再寫代碼。一開始的時候還真是把人給憋的，幾十分鐘寫個用例還真是很痛苦。到後來不寫幾個用例還真不會寫代碼了。其實在寫代碼以前可否寫出用例，能夠說明是否理解了需求或方案，根據方案設計代碼應有的執行結果，對代碼的邏輯流程，異常輸入的處理是否思考到位。而不是在寫代碼的過程纔去取理解問題，並不斷修改代碼。聽從TDD寫出來的代碼短小，邏輯清楚。可是也有一個問題，經過打樁，用例來驅動coding只是代碼的寫做方式，並非設計，一堆mock並不能解決缺少設計而致使的缺少靈活性，缺乏維護手段等問題。

結對編程

在老員工帶新員工的時候效果不錯。倒不是說對代碼自己的學習，老員工高效率的工做方式讓人受益不淺。不過我也看到過老員工之間及其默契的結對，當一我的還沒明白爲何用例失敗的時候，另外一我的已經把代碼修復了。至於提升代碼質量上，我卻是沒發現有不可替代的價值。

迭代回顧

從我自身的經驗來看，迭代回顧會議的效果十分有限。迭代回顧並不能解決各類老大難問題，不少問題幾乎在每一個迭代回顧會議上都能聽到。不過卻是一個充分溝通的平臺，至於下情可否上達就是另外一回事了。不過一些能當即實施的措施，經驗卻是能在迭代回顧會議上獲得傳播。不過只要團隊的內部溝通順暢，這都不是問題。我認爲迭代回顧會議的目的應該是站在團隊層面，對迭代中不符合預期的狀況提出解決的方案，提高團隊的效率，逐步完善團隊能力。

更高的代價

敏捷對每一個人的能力要求仍是很高的，或者說要付出的代價是很大的。好比工具，敏捷仍是比較依賴工具的，在咱們產品內部，因爲項目組較多，致使有各類各樣本身開發的工具，有python2.7的，python3的，有tcl的，有shell的，有bat的等等等等，這維護代價。還有就是若是一個特性作出改動，一天甚至更多的用例修改也是讓人感受厭煩的事情。