CODING 敏捷實戰系列課第三講：可視化業務分析
業務分析處在開發過程的上游，提高業務分析的品質，可以減少後續開發、測試和集成過程中的反覆確認，場景遺漏。採用可視化的業務分析工具箱可以大幅度避免文字版的業務需求描述所帶來的不夠完整，有誤解等問題。CODING 特邀敏捷顧問、「業務分析工具箱」創始人王洪亮老師將在本次 《可視化業務分析》 課程中，帶領大家掌握可視化業務分析的基本工具和方法，以提高業務分析的品質和效率。
今天我為大家介紹可視化業務分析。提到業務分析，是指以文字為主的業務描述文檔 SRS，即軟體需求規格說明書。在線下培訓時，我會讓學員做個小互動來直觀感受詳細的業務分析的重要性：首先讓學員分組，每組選一位代表來觀看展示在螢幕上的圖形，把看到的內容記下來並以口頭表達的方式傳達給組員，組員在 A4 紙上來複現。
因為涉及到很多精確的元素位置，以口頭的方式並不能正確復現。比如組員描述：「這個焦點叫圓心，正方形的邊長是圓形半徑的一半。」組員在復現尺寸時則會產生較大的偏差。可想而知，當我們用口頭或者文字的形式，去表達很複雜的需求時，我們的開發團隊、測試團隊會在理解上產生偏差，從而在復現上產生錯誤。如果讓組員把圖形拍照之後交給團隊去復現，則復現錯誤的可能性會大大降低。同樣道理，我們在表達業務需求時，能夠表達的資訊頻寬越寬、表達的資訊越充分，我們傳遞的資訊就越準確，組員理解越透徹，產品做出來就越精準。
舉個例子，從 ATM 機上取錢的形式叫 IPO（Input Process Output），分別是輸入參數、處理過程和輸出參數。賬戶如果扣減失敗，需要提前把扣減的賬戶餘額退回賬戶，但如果只在這個條件下進行了描述，其他條件下沒有標註，就有可能產生遺漏且難以被識別。而當我們發現了需要補充相關的資訊時，就會引起格式上的調整。
如果我們採用如下格式來書寫 SRS ，想要準確的表達給開發團隊就要在文檔上花很多功夫。由於全是文字，如果複製時產生了覆蓋就會造成資訊的丟失，因此採用純文本方式描述業務需求會產生問題：一是難以閱讀；第二是會產生一些錯誤並且不容易被發現；最後是修改時會產生格式調整，引起不必要的新錯誤。
同樣的業務需求，我們可以換一種表達方式——泳道形流程圖。圖上矩形、菱形分別表示處理和條件，加上用戶、ATM 和賬戶三個泳道，讓每個處理者能清晰了解是誰在負責；當發生變更時，就能明顯呈現出哪裡發生了變更。採用可視化的方式表達業務需求，可以更好地呈現所有資訊。
語言表達會增加誤解的可能性，更何況語氣無法在文字中表達，所以當開發人員和測試人員產生理解偏差，他們就會爭論到底誰是正確的。當沒法判斷時，就到上游來詢問 BA，如果 BA 也沒法判斷就會繼續向上詢問，為了避免浪費時間，在 BA 向開發和測試團隊傳達需求時，就應該清晰地傳達，確保需求的正確性和可讀性。如果 BA 最開始對需求描述就是錯誤的，而且通過文字表述的方式向客戶確認，客戶也沒有發現錯了，就會導致開發和測試白乾；如果在測試時才發現場景或條件有遺漏，就會導致產品品質下降、項目延期，如果在初期能夠發現遺漏，這些隱患就可以及早消除，不至於產生反覆、推遲的問題；還可能遇到因為多個 BA 處理自己負責的部分，根據自己的理解去需求，導致最終結果不一致，開發無法進行的情況，這可以通過互查工具來避免。
當業務需求分析人員遇到了需求分析，簡略寫過後讓開發人員自行發揮，就有可能與原始需求不一致，之後發現問題進行返工就會導致開發時間過度消耗。為了避免出現這樣的情況，在最初就要將需求細化到一定程度，讓開發人員能夠按照明確需求做出正確版本。
需求沒有優先順序會導致用戶發現產品的各種問題，這種情況可以通過迭代的方式解決，每個迭代交付一次，按照價值的優先順序進行排序，用戶可以更短周期地給出回饋，開發就可以做出更正確的產品；如果總是需求變更，當發生變更時，BA 機械地從上游把變更情況傳遞給開發人員，會產生 BA 沒有責任，都是開發人員背鍋的情況，那二者之間可能產生矛盾，打擊士氣。其實需求變更就是 VUCA 時代，誰能更好地響應變更，就具有更強的競爭力，這對整個團隊來說都是非常好的事情。
例如判定矩陣，我遇到過一幫業務專家研究什麼情況下叫故障，我問判斷設備是否故障有多少因素？專家說共四個因素，那麼每個因素有兩個選項，列成表格形式，一共是 16 種組合。這個問題就迎刃而解，整個項目可以快速往下推動。軟體開發團隊使用正確的工具，可以起到非常大的改進作用，甚至縮短交付周期進而提高整體程式碼品質。在整個軟體開發的過程中，BA 的角色叫業務分析師，他的定位是在領域專家和技術專家之間搭建起一個橋樑，將領域專家提出的領域需求翻譯成一個技術需求，讓技術專家能夠實現正確的過程。BA 拿出一份需求文檔，兩方都有相同的理解，這才是一個優秀的 BA 應該做的事情。
以 Scrum 環境為例，在 Scrum 中團隊沒有進行細化，所以 BA 也是團隊的一部分。在團隊里 PO 跟最終用戶進行溝通，將收集到的最初業務需求分解成用戶故事，進行價值排序並設定產品計劃、產品戰略等等，那麼 BA 就應該是把最初拿到的以用戶故事為單位的需求，轉換翻譯成開發團隊能夠看懂，並且能夠正確實施的需求過程，因此 BA 是介於這二者之間的一個溝通橋樑。需求處在開發過程的最上游，那麼需求分析的品質改善就會對下游產生一個槓桿作用，因此 BA 不要去做低價值的事情，而是需要讓團隊價值得到更好地體現。
需求變更是常態，如果能夠提前去想到應對變化的措施，那就真正掌握了如何提高靈活性。變化不僅體現在程式碼上，在需求層面也需要響應變化，才能夠真正推進整個軟體工程。需求文檔寫出來開發團隊要看、測試團隊要看，在 Scrum 中 Scrum Master、PO、UI、最終用戶、干係人都要看，但每個人所處的立場不一樣，希望看到資訊也是不同的，如果把文檔以合適的形式來組織，讓每個角色都能快速理解並且保證高品質，那麼整個軟體開發過程都能得到很大程度的提升。
例如虛擬一個巴士租賃項目：中國旅行社要租賃國外的巴士安排旅客行程，接到訂單就將乘客安排上巴士，行程結束司機結算相應費用。用如下流程圖的方式將巴士租賃的主要業務邏輯畫出來，可以發現在某些情況下並沒有說明判斷基準。遇到一個業務需求時，可能會有各種各樣的條件來判斷這些步驟是否可以往下推動，把這些條件全部列出時整個流程圖會變大、沒有分層導致難以閱讀和維護，而且非常難以變更，如果想實現不論條件如何判斷這張圖都不發生改變，那麼就需要通過解耦合的方式讓文檔產生一份固定和一份可變動的。
可以從下圖看出判定矩陣的構成形式，前面是條件，每一個條件的選項按照 Excel 的形式列出，用這種方式列出所有的四種組合，動作全是派車，那麼最後的結論就很清晰。用這種方式可以確保條件覆蓋率達到 100%。如果有遺漏那是因為所採用的工具沒法達到 100% 覆蓋率，比如純文字描述。如果是一個更龐大的表格，達到上百甚至上千行時，也可能產生人為的遺漏，因此需要採用更科學的工具進行自我校驗。
下圖表格的構成形式，前面是條件、中間是操作、後面是預期，這種 Give When Then 的形式就是測試用例，測試人員拿到表格，可以直接作為測試用例使用。這個判定矩陣不僅能提供 100% 的覆蓋率，還能夠引導程式設計師開發出正確的程式碼，達到一個好的效果。
狀態之間是通過具體的操作進行切換的，例如狀態 4 無法切換到狀態 1，用這種方式把前面流程相應的狀態全部梳理出來，就可以進行下一步的分析。舉兩個例子：一是貸款審批，實際上內部有三個步驟，第一步核實用戶的真實身份，第二步核實用戶的徵信狀況，第三步核實銀行卡與用戶資訊的一致性。內部在處理數據時有子狀態，但是對外都顯示「貸款審批」，所以會分為內部狀態和外部狀態。另一種叫主狀態和子狀態，比如說出國手續的步驟可以分為機票——酒店——簽證，每一個子過程都有自己的狀態，並且三者是並行，全部狀態完成之後整個過程才算完結。
如圖所示，在當前狀態下能否進行左邊的操作，如果能就打勾，這就是所謂的決策矩陣。如果列出一個 M×N 的矩陣，那麼該矩陣一定是覆蓋所有的場景，列出了所有的狀態操作。實際上在畫流程圖時只提供畫對勾的操作，不會表達出空白格所代表的資訊，所以決策矩陣可以用來了解列出的異常資訊。
善用工具可以更好地呈現業務需求，讓開發人員的理解更深刻。例如綱舉目張：在需求中每一個未確認點就是漁網的一個孔，把網子撐起來才能夠看到有多少孔沒有填充，利用數學或者客觀規律來找到這些潛在的點，然後逐個確認，才能夠達到提升品質、提高效率的目的。如果遵循這些原則，可以發展出新的工具，也能夠更好適應不同的業務場景。
一圖勝千言，以上的所有案例都在講如何用可視化的方式去展示相應的業務需求，例如圖示、圖片、圖表、表格、流程圖等等。業務需求分析一定要完整，要保證以下幾個方面：
- 正確性：一定要讓需求得到正確的表達；
- 精確性：在表達業務需求時一定要精確，表達不夠清晰就會產生誤解，如果用數學表達式誤解就會消除，所以要用精確的方式來表達需求，而不是過多地採用自然語言；
- 一致性：盡量保持書寫格式、措辭習慣、表達方式等的一致，用同一種工具表達可以讓成員理解起來更順暢，讓團隊協助更順利；
- 柔軟性：需求變更一定會發生，所以文檔書寫越具有柔軟性的響應，變更能力就越強。還要記住分層表達，採用不同的層將主流程和條件判斷分開，可以讓文檔具有更高的柔軟性。在需求發生變更時儘可能減少所影響的範圍，可以更快、更準確、更好的讓開發團隊傳遞所有的需求變更資訊；
- 解耦合：包括依賴注入，主業務和依賴是基於介面和校驗的，介面用原型表示，校驗用 Excel，主要邏輯和次要邏輯進行分離。通過解耦合的方式，可以很大程度上提高文檔響應變化能力，更好地讓團隊以更高的效率、更好的品質來提高復用性；
- 多面性：需求讀者是多種多樣的，要考慮每種讀者所站的立場和他們所希望獲取的資訊，所以提供的需求要讓讀者能夠輕鬆獲得想要知道的資訊，提高讀者的理解程度加快效率；
- 節約時間：BA 在工作上節約的時間都會變成開發的時間，在文檔書寫上儘可能讓調整格式的工作減少，儘早交付反覆迭代，在保證品質的情況下完成並且交付，可以更快的推動開發前進，完成比完美更重要；
- 投入時間：把時間花在有意義的事情上，比如品質、需求表達可讀性的提升，減少開發和測試時間投入，包括減少遺漏或錯誤造成反覆溝通確認的問題；
- 未雨綢繆：有很多內容可以提前準備，如果能預先準備好相應問題，在遇到該場景時，可以馬上檢查是否分析全面，是否還有遺漏，同時內容復用率也可以得到很好的提升；
- 最後是墨菲定律，要記住：凡是你不分析的地方一定有問題。
