软件开发本质论——自然之路
喔家ArchiSelf
曾經特別喜歡閱讀《xx本質論》系列叢書,當圖靈的1月新書《軟件開發本質論》上架時,果斷買下,選一個并不忙碌的周末,傾聽《敏捷宣言》起草者之一 Ron Jeffies 的文字,并記下自己的隨感。
本質論似乎還是有譯文標題黨的嫌疑,原名《The nature of software development》,核心觀點是keep it simple,make it valuable,build it piece by piece。和敏捷思想的核心一致,保持簡潔,追求價值,循序漸進。從終極的目標看,軟件開發和其他非軟件產品一樣,都是為了盡早提供價值,持續提供價值。
價值第一
價值是what you want,是那些我們想要的東西。通常,軟件的價值都與金錢有關,因為軟件能夠幫助人們節省時間或金錢。只有當軟件發布的時候,價值才能體現,所以要找到一種方法盡早地交付價值。由于二八法則的存在,大部分用戶并不會使用軟件中所有的功能特性,想知道哪些特性是用戶所必需的即方向是否正確,一個好方法就是盡早發布產品的小版本,所以必須看到并理解產品的各個部分。
價值包括商業價值、客戶價值等不同維度,可能是信息,金錢,運行速度,開發進度,持續能力等等,不同類型的價值不具備可比性。價值的衡量在于共識。實現價值的途徑就是構建軟件并查看它的運行效果。 根據功能特性來劃分價值,高度代表價值,寬帶代表成本,價值的增長取決于我們選擇做什么。價值的最大化在于頻繁交付小的并以價值為中心的功能特性。
Talk is cheap, show me the values.
業務團隊
要正視我們并不能實現所有的功能特性,進行引導而不是任其發展。事情很少會按計劃發展,基于活動階段的產品是一塊搬不動的巨石。根據功能特性交付產品更具有可預見性,能夠提供更好的信息和指導,也容易產生更好的效果。
了解康威定律,根據功能特性構建團隊,就是“two pizza team” 或者全棧小團隊,組建橫向的實踐社區,這樣的功能特性團隊使得“水平擴張”很容易。專家的高薪不僅因為他是專家,更重要的是能夠幫助他人成為專家。一個強大的團隊,目的來源于具體業務,自主能夠給整個團隊帶來責任感,專精來自于迭代的過程。
計劃本身是無用的,但做計劃是必要的。根據功能特性進行計劃,目標小而明確,開發能夠以更好的方式進行。詳細的計劃往往是無效的,需要通過持續的計劃分解功能特性。每個功能特性(user story)最好在2~3天內完成。工作量由團隊自己作出,會更加投入。估算過程可能是,確定預算和截止日期,找一位產品負責人來決定功能特性的開發順序,并組建能隨時交付軟件的團隊,估算是有風險的。根據挑戰性的目標制訂計劃,危害性很大。趕工會帶來更多bug,糟糕的代碼同樣影響進度,壓力大多數時間具有破壞性。估算會將注意力放到成本上,而忽略價值。
Talk is cheap, show me the features.
產品迭代
采用短周期迭代方法開發完整的小產品,細化產品的愿景,總是將價值可能最大的任務列為下一個目標。任務拆分的標準是:團隊成員認為自己能夠把握整個模塊并且能夠在一周完成。確定真實的進展,淘汰測試修復的收尾方式。為了確保沒有bug,必須隨時對一切進行檢測,通過觀察開發速度的變化,調整設計的程度。
產品需要堅實的基礎,沒有基礎架構,構建功能特性往往無從談起。基礎優先意味著能夠進入市場的功能特性太少,每次構建包括基礎服務的功能特性同樣意味著能夠進入市場的功能特性太少,所以首先構建簡單實用的版本MVP,在多次迭代中逐漸完善功能特性,構建夠用的基礎,為在交付日期前獲得盡可能好的結果而努力。
Talk is cheap, show me the deliverables.
測試開發
良好的過程控制可以有效地減少代碼中的bug,產品的構建是由數量不斷增長的能夠正確運行的功能特性組成。bug 是拙劣的功能特性,使進展變得不確定,修復bug會帶來不確定性的時間延遲,隨時發現bug隨時修復,只有消除bug,才清楚真正完成了哪些功能特性。出現了一兩個bug,就意味著很多,必須盡最大的努力避免bug。這需要持續全面的測試,業務測試和開發者自測都需要自動化技術的支撐,開發自測需要以更快的頻率進行。測試并未減少開發速度,反而更快。
設計容易退化,需要與時俱進。 每次改動都可能會破壞當前的設計,放任設計慢慢退化是不可取的。改進措施是預留空間或feature的重新處理,在改變設計的同時保持其良好狀態,重構是一項必備技能。測試與重構結合,使增量開發成為可能。遵循營地規則可能是最好的選擇:離開露營地時,要讓它比你來的時候更好。
Talk is cheap, show me the codes.
敏捷管理
管理層從總體上決定要做什么,由誰來做,控制好自己所參與的產品和項目的數量。沒有固定的目標,一切都是為了能夠獲得最好的結果。努力將比較小的組織決策權力下放到基層,通過預算控制任務規模的大小,盡最大的可能以結果為導向來評價工作的好壞。
了解現有團隊成員的價值,同時,團隊對總體格局了解越多,工作就會做到越好。支持和指導是確保產品與企業的宗旨保持一致,向團隊提供幫助和培訓,優先提高團隊的工作效率,然后才是個人,為提升技能提供真正的機會。能力是提高速度的前提,不要被迅猛當作高效,速度最快的團隊總是平穩優雅地前進。
你并不能夠總是得到你想要的東西,敏捷很簡單,但是做到并不容易。Scrum 結合其他的技術實踐就是極限編程,框架要輕,且不要被框架掌控,保持流程的改變貼近團隊的實際,把學習放在首要的位置,多思考。大規模敏捷同樣是簡單的,敏捷團隊是通過測試進行協調配合的。?
Talk is cheap, show me the tests。
微信掃一掃
關注該公眾號
總結
以上是生活随笔為你收集整理的软件开发本质论——自然之路的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: linux常用命令-查看文本/cat,t
- 下一篇: Android 5.1上MultiDex