好文翻譯丨爲什麼要實施敏捷

好文翻譯丨為什麼要實施敏捷

關注開源中國OSC頭條號,獲取最新技術資訊

參與翻譯 (2人) : 李Sir迷路了, ZICK_ZEON

在我很小的時候,家裡人給我起了一個綽號:“Bu’why”,這是因為我總是向周圍的人問為什麼。大多數時候,他們會嘗試解答我的問題,但是後來他們給我的這個綽號中也流露出了他們的挫敗感。

直到現在,我依舊執迷於事物背後的真正原因。因為我想知道交通擁堵背後的真正原因,於是我讀完了一整本關於交通模式的書籍。因為我想嘗試得到更好的休息,我讀完了一本關於睡眠的書籍。我堅信,‘為什麼’是至關重要的。

最佳實踐

已經被公認或確定的是正確且最高效的商業、專業流程。(維基百科)

不幸的是,大多數人想要的是“什麼”而不是“為什麼”。他們需要處理的事情太多了,他們需要的是能解決他們手上的問題的現成的解決方案:節流、軟件模型、制定計劃、軟件開發方法論、只要你堅持下來,你就能得到承諾於你的一切。

“我們上一次嘗試的系統因為其自身的先天缺陷被視為一個失敗品,而這個新系統比上一個更好,這一次一定非常棒。”, Holy Grail 說。可能借助新系統事物的發展不至於太糟糕,但是對其抱有的期望高的有點不切實際了。沒有人變得更開心,因為實際上並沒有顯著的提升。這到底是為什麼?

軟件開發很複雜

2012年,當我在Nordstorm創新實驗室工作時,我第一次知道了Cynefin框架。它著眼於給定系統的複雜度,然後來決定什麼樣的方法可以用在這個系統上。它把系統拆成了四個類別,通常用四個象限表示:

  • 淺顯的
  • 系統中擁有的關係通俗易懂的而且簡單
  • 例子:堆放貨架、修剪草坪
  • 方法:確定類別,採用合適的規則集合
  • 難懂的
  • 需要足夠的分析,可以預測到因果關係
  • 例子:摩天大樓,X光機
  • 方法:預先分析場景,確定採用的技術
  • 複雜的
  • 因果關係僅可以在回顧時得到,但是每次都不會重複
  • 例子:股票市場,天氣
  • 方法:調查問題範圍,以適應技術
  • 混亂的
  • 因果關係是無法去感知的
  • 例子:自然災害和其他緊急事件
  • 方法:應對和適應

你會注意到,越複雜難預測的系統隨著時間的推移,創建的那些嘗試預測這個系統的規則需要做的適應修改的地方越多。道理都是類似的。就拿股票市場這個複雜的系統來說吧,他的波動規律就經常性地打臉那些嘗試預測他的上漲下跌週期的股票理論的臉,作何理論在他面前都變得無用,要在這種領域有所作為,不能一勞永逸,需要不斷學習和適應。

問題是:軟件開發在這個連續過程中處在什麼位置?有人可能會說這只不過是個工程問題,所以這就像設計建造摩天大樓那樣按部就班做即可。另一些開發軟件的過程中受到挫折的人,可能會說這就像歷史中記載的自然災害那樣完全不可預測。

有時這很複雜,有時這很混亂無序。大多數時候,這是複雜的。

處理複雜情況

Cynefin告訴我們,沒有一套最佳實踐可以告訴我們如何在給定的複雜系統中採取行動。它也確實指出一些初始的啟發式類的方法是有用的,而我們的重點應該是探索問題領域,並隨著時間的推移調整我們的方法。

這聽起來很熟悉,不是嗎?每當開發團隊為給定的項目採用一種新類型的功能時,不確定性就會上升。要知道一個給定的解決方案是否有效,唯一的方法是多探索一下。這就是正在開發的軟件系統。還有五個複雜的系統在起作用:

  • 開發團隊
  • 較大的組織
  • 當前生產環境下的應用
  • 生產環境下應用的用戶
  • 商務環境

上述系統中的任意一個都能輕易地導致一個排期緊密的開發項目出現問題:一堆意料之外的影響了正常業務的線上bug,開發團隊成員突然的身體不適,業務方提出的關於發展方向上的改變。

這就是為什麼要實施敏捷。敏捷幫助開發團隊來應對前面提到的所有問題,同時建立一個隨時間變化而適應當前形勢的框架。敏捷向開發團隊提供了一套使之變得最棒、最具有生產力的工具。

關於為什麼要實施敏捷的實踐

接下來會討論一些特定的“禮儀”以及它們存在的理由。我們需要擺脫“必須”和“應該”的思維模式,我們不這麼做是因為它們是必要的,我們這麼做是因為我們想從中得到一些我們想要的東西。如果我們沒有辦法再得到我們想要的,那麼我們需要作出一些改變。

  • Sprints - 人類的規劃能力還不是特別的強大。通過任務拆分,如果事情走向出現了問題,他們需要應對的問題就不會特別大。同時,在最開始的時候通過明確任務範圍也縮小了外力因素帶來的影響。
  • 關於執行完成的嚴格定義 - 當一個任務已經完成時,確保不會留下任何需要處理的工作來避免“技術債務”。
  • 故事點而不是小時數 - 確保估算是一種僅用於團隊在一段時間內實現計劃和執行一致性的工具。 防止管理層認為“開發團隊能力不足”,或試圖鑽制度的空子。
  • Spikes - 實際上是從Cynefin複雜域中“調查問題域”來提高確定性並且啟動規劃。
  • Sprint 階段成果 - 開發人員應通過實際完成的產品原型來展示他們的工作成果。慶祝本次Sprint的完成並期待下一個Sprint即將要做的工作。
  • 回顧總結 - 這是敏捷關於適應機制的核心。如果你僅僅做一件事情,那就去做,但是你必須解決在回顧總結過程中暴露出的困難和其他問題。
  • 待辦事項列表 - 一旦Sprint啟動,在業務方和開發人員之間不應該有頻繁的需求變動。在準備開始一個新的sprint會議中,主要由業務方決定本次Sprint中需要完成的事項和任務,當然,有時也需要開發人員的參與。
  • Sprint計劃 - 這個會議的主要目的是開發人員評估任務,同時規劃本次Sprint的目標。業務方應該出席會議並對關於本次Sprint中涉及的任務需要最終確認的問題負責解答確認。

現在,那些敏捷教練說的諸如“在你接受採用敏捷的早期,你的估算會被停止”的言論是有道理的。這一切都是因為你處在一個逐步適應和提高的過程中。你的估算會更精確,困難阻礙會被解決,團隊也會逐步減少歷史遺留下來的技術債務問題。

反饋循環

控制系統的一部分,允許其進行反饋和自我修正,以及可以根據實際輸出結果和期望的理想輸出結果之間的差異調整其接下來的操作。 (American Heritage® Dictionary)

敏捷可以創建一個引導你走向你的最終目標的反饋循環。每一步都是一個小的勝利,讓你感覺良好,給你帶來更多的勝利。它就像一個恆溫器,只不過你暫時還不知道目標溫度是多少。事實證明,反饋循環也是測試驅動開發(TTD)和精益創業背後的本質。

這裡留給讀者一個問題:如何調整你的軟件開發反饋循環來使你的團隊成為最棒的那個?在我的第二篇敏捷文章:可定製的敏捷中,我會為各位讀者提供一些思路和想法。

開源社區OSC「好文翻譯」欄目,旨在每天為用戶推薦並翻譯優質的外網文章。再也不用怕因為英語不過關,被擋在許多技術文章的門外。關注開源社區OSC,每日獲取翻譯好文推薦,點擊“瞭解更多”,閱讀原文章。


分享到:


相關文章: