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 的矩陣，那麼該矩陣必定是覆蓋全部的場景，列出了全部的狀態操做。實際上在畫流程圖時只提供畫對勾的操做，不會表達出空白格所表明的信息，因此決策矩陣能夠用來了解列出的異常信息。

善用工具能夠更好地呈現業務需求，讓開發人員的理解更深入。例如綱舉目張：在需求中每個未確認點就是漁網的一個孔，把網子撐起來纔可以看到有多少孔沒有填充，利用數學或者客觀規律來找到這些潛在的點，而後逐個確認，纔可以達到提高質量、提升效率的目的。若是遵循這些原則，能夠發展出新的工具，也可以更好適應不一樣的業務場景。

一圖勝千言，以上的全部案例都在講如何用可視化的方式去展現相應的業務需求，例如圖示、圖片、圖表、表格、流程圖等等。業務需求分析必定要完整，要保證如下幾個方面：

1. 正確性：必定要讓需求獲得正確的表達；
2. 精確性：在表達業務需求時必定要精確，表達不夠清晰就會產生誤解，若是用數學表達式誤解就會消除，因此要用精確的方式來表達需求，而不是過多地採用天然語言；
3. 一致性：儘可能保持書寫格式、措辭習慣、表達方式等的一致，用同一種工具表達可讓成員理解起來更順暢，讓團隊協助更順利；
4. 柔軟性：需求變動必定會發生，因此文檔書寫越具備柔軟性的響應，變動能力就越強。還要記住分層表達，採用不一樣的層將主流程和條件判斷分開，可讓文檔具備更高的柔軟性。在需求發生變動時儘量減小所影響的範圍，能夠更快、更準確、更好的讓開發團隊傳遞全部的需求變動信息；
5. 解耦合：包括依賴注入，主業務和依賴是基於界面和校驗的，界面用原型表示，校驗用 Excel，主要邏輯和次要邏輯進行分離。經過解耦合的方式，能夠很大程度上提升文檔響應變化能力，更好地讓團隊以更高的效率、更好的質量來提升複用性；
6. 多面性：需求讀者是多種多樣的，要考慮每種讀者所站的立場和他們所但願獲取的信息，因此提供的需求要讓讀者可以輕鬆得到想要知道的信息，提升讀者的理解程度加快效率；
7. 節約時間：BA 在工做上節約的時間都會變成開發的時間，在文檔書寫上儘量讓調整格式的工做減小，儘早交付反覆迭代，在保證質量的狀況下完成而且交付，能夠更快的推進開發前進，完成比完美更重要；
8. 投入時間：把時間花在有意義的事情上，好比質量、需求表達可讀性的提高，減小開發和測試時間投入，包括減小遺漏或錯誤形成反覆溝通確認的問題；
9. 未雨綢繆：有不少內容能夠提早準備，若是能預先準備好相應問題，在遇到該場景時，能夠立刻檢查是否分析全面，是否還有遺漏，同時內容複用率也能夠獲得很好的提高；
10. 最後是墨菲定律，要記住：凡是你不分析的地方必定有問題。

點擊觀看完整錄播視頻