全域性角度出發討論敏捷

\

本文要點

\\

• 在全域性、系統工程框架中，敏捷實踐可以獲得最好的效果。\\t
• 敏捷需要有好奇心的文化。\\t
• 名義上的敏捷很常見，但並不實用。\\t
• 成熟的敏捷是一種思維方式，而不是生搬硬套的實踐。\\t
• 敏捷不等於Scrum。\

\\

Jon Kern對於是什麼促成了敏捷的成功有著自己讀到的見解。你可能會不同意他的觀點。

\\

下面列出了一些建立在專案全域性角度之上的關鍵實踐，專案本身就是從此開始的。如果不能從系統角度來做專案，那它就不能達到預期的效果，甚至可能會失敗。

\\

我最終不得不承認我是在使用Kanban過程

\\

我很早以前就認為，開發軟體就像是在完成一個很長的待辦事項列表。我試了很多方法來執行專案，從記事貼到Jira（從Jira剛釋出起我就開始使用）。我使用傳統Scrum風格的Sprint很多年，只是我的使用方式與眾不同。對我來說，Sprint就是定義廣泛優先順序的“儲存桶”，可以說就是分組機制。我不太關心我們是否在Sprint中解決了所有問題。在一開始，我也會通過燃盡圖來檢視我們是否達成了預估的目標。但之後我才發現，就算完成了又怎樣，完不成又怎樣？

\\

所以最後我才承認，在Sprint的偽裝下，其實我們是在使用Kanban。

\\

我認為，在選擇一個過程時，最重要的是要保證能在正確的時間將正確的事情完成到正確的“水準”，然後一直做到交付為止。換句話說，你要給團隊提供需要完成的業務功能的優先順序列表。這樣至少你會知道團隊在做的是當前最有價值的事情。

\\

Sprint計劃和估算

\\

我是怎麼怎麼做估算的？說實話，我儘量不去這麼做。

\\

至少我不會做傳統意義上的估算，就是估算每個故事點，然後根據估算值來決定這個Sprint中可以處理的問題數量。這非常無聊。

\\

即使是最近我們在做Sprint時，我也幾乎不做Sprint計劃和估算。（我想這是因為我職業生涯中有十年時間都在給海軍相關的合同工作提供投標和指導建議，因此留下了“後遺症”。）我的團隊和我經常拿Jira Sprint報告的燃盡圖來開玩笑，有時候直線上升，有時候下降到正常的幅度，之後保持平緩。

\\

\\

\\

這是因為我們不會浪費時間去思考在Sprint中我們能完成多少事情。我們只關心要安排恰當的優先順序順序，並將問題分解成合適的大小。我們把沒有完成的事項放到下一個Sprint的頂部（如果仍然有必要完成的話）。

\\

請注意我使用了“合適的大小”這個詞。這裡有一些隱式的“計劃”。如果一個問題需要兩週時間才能處理完，我們就不會把它考慮在內。相反，我們會把這個大問題分解為更有意義的小問題。我們甚至可以和業務方協商將大問題分解為不同的深度級別，這樣在一開始就可以輕鬆一些。隨著時間的推移，我們可以根據使用者的反饋來新增更多功能。

\\

什麼對我來說是有用的？

\\

無論是對一整個新專案、對一個新的主要功能，還是往遺留系統新增新功能，我都會在一開始搞清楚需求。這個過程有助於建立整個系統的全域性檢視，或者瞭解是否會對現有系統產生影響。我這裡用了“全域性”這個詞來表示組成系統的方方面面，或與你係統的發生互動的其他系統、會修改你的系統或者對你的系統有著決定作用的人（包括使用者和“業務方”）。

\\

我的第一原則

\\

• 發現業務需求\\t
• 建立有效的領域模型\\t
• 列出高優先順序的故事對映或功能\\t
• 列出任何有決定性影響的因素\\t
  • 不能改變的最後期限\\t\t
  • 瘋狂的效能需求\\t\t
  • 瘋狂的服務協定\\t\t
  • 其他\\t
  \

最重要的是要充分了解需要處理的業務問題（就是需求），並建立能反映業務需求的領域模型。我還會建立產品設計願景，也許還有一些其他重要的事情。最後架構成形，它可能是一個“普通的”響應式Web應用程式，也可能是一個非常新穎的特別架構（比如語義Web）。簡單來說，我喜歡做足夠的“前沿”設計，這樣可以避免我們沒能充分了解到的風險。

\\

\

你可能已經猜到了，我會花很多心思對問題領域進行建模。這有很多好處：

\\

• 捕捉業務方使用的術語，成為專案的通用語；\\t
• 創造領域架構，捕捉重要的關係；\\t
• 為團隊提供符合需求和UI介面模型的類資訊，簡化功能開發和問題修復；\\t
• 可以很方便地討論需要新增哪些新功能。\

\\

“足夠”這一詞是非常主觀的。它可能來源於多年的實踐經歷，告訴我們什麼重要，什麼不重要。儘管如此，你還需要思考是否要在早期的設計中為某個功能新增更多細節。或許你可以等到實現這個功能時再考慮細節問題。

\\

或許我可以給出一些極端的例子。

\\

在我聽到一些主題專家或使用者描述他們的觀點和需求時（可能通過使用者故事或者將功能和抽象概念些下來），我會為他們的業務領域建立模型（即問題領域）。這些模型包括屬性、方法和聯絡。在需求誘導的開始階段，我主要關注大類和基本功能。通常是瞭解有使用者存在，而且使用者是借款人（比如這是一個貸款應用程式）。主題專家一開始想告訴我借款人的20個屬性，我一般會阻止她。我會禮貌地問她是否有任何特定的屬性會影響我們將要深入探究的需求。如果沒有的話，我建議我們之後再討論細節。如果業務專家偶爾提到幾個估算或合規性需求，我可能會問他們幾個問題，確保它們不是超級複雜的大需求。

\\

極端例子：使用者類的名稱。如果“名稱”包含名字、姓氏、中間名、稱呼、頭銜等等，是否會影響架構的複雜度呢？

\\

如果不會對設計產生實際的影響，就不需要在很早的時候花太多時間來研究這些細節，因為這樣的話就會忽略一些重要的元素。

\\

另一方面，我有個客戶故意將細節保留到後面再說，他認為等待是最好的。除了有一次，他又在很後面才說出細節，但我希望我能早點知道，因為影響到我對設計的看法了。（我現在忘了具體是什麼了，大概是與泵動原理有關的一個技術問題。）

\\

這個方法對我是有用的，因為我通過全域性系統工程方式來進行軟體開發。通過建立系統的心智模型（和紙上），我們可以瞭解系統元件之間的關係和影響。

\\

要有耐心，不能操之過急。獲得足夠的需求，進行恰到好處的設計，不要一開始就瞭解太多需求細節！

\\

大規模敏捷

\\

在我第一次聽到“大規模敏捷”這個詞的時候，我在想，這是不是像“大規模Java”或“大規模Rails”一樣？當然，如果你在和五個團隊成員一起開發Web應用程式，那麼和超過100人的團隊相比自然不是一個數量級的。

\\

但我很少將“大小”和“規模”與更多複雜性掛鉤。

\\

\

我曾經設計過的最大專案是IBM的生產執行系統，用在他們分散的電腦工廠裡。大約有七個核心模組，200-300個問題領域類，200萬行程式碼，分散式的瘦客戶端，多使用者介面選項（Windows NT、DOS graphics、OS2），多資料庫選項（Oracle和DB2）。

\\

之後採用了“敏捷”原則（就像他們現在做的一樣）。應用程式範圍要大得多，在我們開始正式寫程式碼之前，有更多前期設計和架構設計要做。我們還參觀了工廠，進行了使用者訪問，設計UI原型，並做了早期部署。這發生在敏捷和DevOps興起前的1995年！

\

\\

當然，一個與其他系統有依賴和互動的專案會更具挑戰性，成本也更高。關鍵是要通過全域性的視角理解系統和子系統，最小化大型應用程式終究會面臨的“額外開支”。

\\

無論怎樣，我會遵循這裡所列出的有關通過敏捷方式來開發軟體的原則。大型專案當然會比小型專案需要更多的前期工作和協調。

\\

我會盡我所能，將巨大的專案分解成一組規模較小、較自治的專案。

\\

我永遠不會採用100多人的團隊，我可能會採用20個5人的團隊，或者用25個（甚至更少）高績效開發人員團隊來完成100個普通開發人員的工作。

\\

我的建議：學會分解問題，瞭解如何通過介面進行架構，通過解耦系統將大問題分解為合理的小問題，這樣就不會產生太多開銷。

\\

敏捷宣言的狀態

\\

有時候我會被問到，如果可以的話，我是否會回到過去修改敏捷宣言。

\\

我的回答是“不會”。

\\

如果可能的話，我們想要（重新）讓人們瞭解我們在編寫宣言時的想法。

\\

我們的一個嘗試是敏捷起義（Agile Uprising），一個組織在Snowbird採訪了我有關敏捷活動的內容。他們還採訪了幾乎所有的其他合著者。可以訪問他們的網站，註冊並瞭解一些有意思的討論！他們正在試圖將我們這些作者幾年前的想法展現給大家！

\\

現代敏捷（Modern Agile）是另一個嘗試，是由我的一些朋友牽頭組織的（Joshua Kerievsky、Tim Ottinger等）。我只是留了名，是原來的“敏捷”已經老了嗎？不夠現代化了嗎？

\\

回到核心問題

\\

就像《美國獨立宣言》和《憲法》的核心是監管人類行為，我認為敏捷宣言的本質是關於軟體開發中人的行為。

\\

對於軟體開發的未來，這四方面的內容會什麼時候（為什麼）不再適用？

\\

• 個體和互動高於流程和工具；\\t
• 可執行的軟體高於詳盡的文件；\\t
• 客戶合作高於合約談判；\\t
• 響應變化高於遵循計劃。\

有關作者

\\

Jon Kern 是敏捷宣言的合著者之一，他非常樂於幫助客戶通過軟體交付商業價值。他具有長遠的眼光，在看到大局的同時，也知道細節內容，並在關鍵時刻推動商業取得成功。

\\\\

檢視英文原文：Agile in the Context of a Holistic Approach

\\

感謝無明對本文的審校。