業務分析師在敏捷專案中的作用

agile_boy發表於2009-03-10
敏捷
    在Agile 2008大會上，Alan Cooper做了一個很棒的演講，他熱情洋溢地提到：敏捷專案中需要包含互動設計的工作，要有人能夠理解人的行為、而且可以確保相關的產品能夠在現實世界中有效工作。

    我的觀點是：最理想、最有效的做法，是由業務分析師承擔這個職責；而且我們應該一直這樣做。我們接受培訓，部分上也是處於這個目的：理解更廣泛的業務需求，並向負責技術的團隊以他們可以理解的方式解釋這些需求。一直以來，業務分析師一直充當客戶需求的守護神。

    業務分析師可以幫助團隊成功

    我 堅信：對業務分析師角色的輕視，是如今眾多敏捷團隊的嚴重問題。在很多組織中，由於缺乏組織架構和管理層的支援，分析師的職能被削弱了，他們無法完全體現 自己的價值。業務分析師應被視為客戶的代言人，並加入以業務為核心的解決方案提供團隊，而不是技術的提供者。在面對問題時，業務分析師能夠帶來不同的視角 和理解，因此他們應該被授以足夠的權力、信任和感謝，他們應向負責業務改進的人員和部門報告自己的工作，而不是去報告給資訊科技團隊。在這樣的組織結構 中，業務分析師將會給予足夠的許可權，以提升業務價值為明確目標，推薦專案的變化向這個目標努力；而不僅僅只是作為技術團隊的一部分，被看做“技術的跟屁蟲 ”。

    那系統分析師又該如何？

    注意這裡的區別：我們所說的是業務分析師，而不是系統分析師。“系統分析師”是幹什麼的？雖然在多數情況下，系統分析師的技能足以有效地完成業務分析相關 的工作，我還是要區分開這兩個角色，因為他們的角度不同——業務分析師的重點放在對業務需求的理解之上，並受其驅動；而系統分析師卻常常從相反的角度考 慮，他們主要思考基於技術的解決方案，有時提出的方案甚至不利於真正解決業務問題（“Wow，我已經告訴你解決方案了！”）。系統分析師可以成為好的業務 分析師，但是他們一定要小心，必須壓抑自己提出技術建議的衝動。

    要業務分析師幹什麼？我們需要“客戶”

    業務分析師願意花時間去接近 不同的“利益相關者”，也就是那些代表公司或組織、關心業務變更成功交付的人。業務分析師要理解多種不同維度的業務需求；與管理層討論總體方向和目標；法 務部門一起工作，看看新的或是變更後的業務流程會產生哪些法務上的影響；跟後勤部門一起工作，識別辦公空間或倉庫佈局的變化，理解流程變化對於物流、產品 直到發貨過程的潛在影響；還要跟行政人員一起，搞清楚新的稽核過程可能造成哪些潛在的瓶頸……以及諸如此類的事情。

    分析調研進行到某個時間點時，我們會發現：要解決某個業務問題，就得在技術上想辦法。此時，業務分析師的角色會有點變化，我們要加入到技術可行性的討論之 中，要決定是“構建vs購買”，或是決定內包還是外包。在這個階段中，傳統的業務分析師就會參與業務案例的制定，組織在實施敏捷時可以藉助這些案例；至於 對專案的判斷，要看它們能夠為組織帶來哪些業務上的好處。如果沒有這個價值取向，為了管理敏捷待辦事項列表而正在進行的優先順序排定工作，可能就會缺乏對項 目願景的全面理解，從而導致需求出現問題。

    上述決策確定之後，而且組織也打算在技術上投入一定資金，此時業務分析師的角色就又變了，成為了需求的 看護者、使用者故事的收集者和指導者。業務分析師也是在此時積極參與到敏捷專案中，併成為敏捷軟體開發專案團隊的重要成員，代表客戶和終端使用者，並與其他團 隊成員協作，以達成明確的業務需求，使其受益於基於技術的解決方案。

    業務分析師與專案團隊一起工作，保證使用者故事的正確實現。對於團隊來說，他們是客戶的代言人，推進使用者故事的詳細說 明。在面對更廣泛的利益相關者群體時，他們充當專案的代言人，負責在正確的時間將客戶正確的聲音傳達給專案團隊。一般來說，這裡的“客戶”，在很多敏捷相 關的文化中都有提到，並不是一個單一的個人，而是表示很多“利益相關者”構成的群體。這群人構成多樣，經常意見相左，互相角力，有時甚至彼此敵對。他們對 於業務需求和“完成”的定義經常充滿分歧。

    看完上面這段話，你是不是覺得我不相信“現場客戶”的作用？絕 對不是！我120%地堅信：敏捷開發過程要想成功，我們必須有現場客戶。我們所面對的挑戰在於：有太多不同客戶的聲音，經常向團隊發出彼此衝突的命令。在 整個專案中，業務分析師必須隨時能夠從這些“噪音”中過濾出有用的訊號，並識別出那個時刻哪個客戶適於作為代表。

    那麼業務分析師到底是幹嘛的？

    在 敏捷專案中，業務分析師也是使用者故事的守護者。他們會引導發現過程，並促進團隊之間的溝通，通過提出“如果……會怎麼樣？”之類調查性的問題幫助客戶代 表；而這些問題來自於他們對專案發端因素的廣泛調查， 對於利益相關者群體的印象，以及對於組織正式結構之下錯綜複雜的政治和人際關係的理解。他們還有能力接觸出資方，爭取機會訪問真實的客戶（這些人是真正為 系統提供的服務付錢的人），知道應該怎麼做才能形成競爭優勢，讓客戶滿意，並最終讓組織取得商業上的成功。

    業 務分析師要廣泛掌握調研和人際交往技能，掌握使用批判性思維和懷疑思考的能力，還要使用多種多樣的建模技巧和其他工具，幫助客戶代表發現構成系統的故事範 圍。業務分析師還能幫助客戶代表用清晰易懂的方式表達這些故事，從而讓“完成”的含義一目瞭然，同時與測試人員和客戶代表共同工作，幫人們看清使用者故事必 須要具備的驗收條件。

    最好的業務分析師會參與故事各個方面的討論，並積極加入到系統的互動設計過程中。他們深刻理解使用者群體與系統互動的多種方式，知道不同需求之間的分歧，並可以平衡這些分歧，讓系統在設計上滿足不同利益相關者的要求。

    敏 捷業務分析師也是設計師，他們對系統的理解遠不僅僅是識別和記錄需求文件這麼簡單。他們知道螢幕上的功能流程背後意味著什麼，也能保證系統的流程符合人們 實際的工作流程。顏色和字型、螢幕的介面佈局和響應時間，這些因素對系統使用者的工作效率會產生哪些影響，敏捷業務分析師都瞭如指掌。他們尋找一切機會創 建人們願意使用的、真正實用的系統，並願意引導開發人員構建符合人的直覺和自然使用習慣的使用者介面。在理想狀況下，使用者介面會讓人覺得似乎消失不見了，因 為它們非常易用，操作人員甚至感覺不到介面的存在。

    傳統的分析方法，希望在弄明白“怎麼做”之前先搞清楚要“做什麼”。可這不適用于敏捷專案。敏捷開發過程有一種與生俱來的工作方式，就是在一個高效的迭代開發週期之中，我們總是要通過“怎麼做”的過程來知道“做什麼”。

    在處理系統與使用者互動的介面工作時，系統的外觀和感覺很重要，敏捷業務分析師能將這方面的工作清晰地展現出來，使其得到團隊的重點關注。

    敏捷業務分析師要確保真正的業務價值得到發掘和展現，他們要跟專案團隊和客戶代表一起找到這些價值，這可以使得所有人的工作都變得更加簡單、高效，同時達成客戶的滿意度和“粘性”。我們的客戶也就會一而再、再而三地跟我們反覆做生意。

    誰應扮演業務分析師的角色？

    在 Scrum專案中，產品負責人或首席客戶推廣人員最適於充當敏捷業務分析師。因為他們有足夠的權力，也能得到相應支援，足以代表客戶。這些分析師要積極參 與管理產品待辦事項列表，並識別產品功能的優先順序。此外，還要構建與業務利益相關者的良好關係，同時理解技術實現的可行性；有了這些作為基礎，業務分析師 就可以積極參與專案價值的交付過程。敏捷業務分析師必須要成為業務專案團隊的積極成員，還得努力做出貢獻；而不僅僅是試著產生一長串帶有“應該”之類詞彙 的句子；還要代表、放大、守護許許多多客戶的聲音，提出“你們有沒有想過……”這樣艱難的問題，從而保證我們交付的產品可以達成客戶多樣化、相互牽制的需 求；還要基於以往和眼下的使用者故事，與整個專案團隊一起討論和互動，以理解並識別缺陷、流程和問題。

    業務分析師角色對於專案的成功不可或缺

    技術是為了滿足人的需要而存在，而不是成為人的需要！

    ——Malcolm Watson, 墨爾本Pronto軟體公司開發經理

    業務分析師人群應該走上前臺，成為敏捷協作團隊的積極參與者，因為他們力圖建立可以交付真正的價值和客戶滿意度的系統。主動承擔“業務分析師”的角色，將 問題拆分成各個組成部分，理解真正的潛在需要，然後成為專案團隊的積極參與者；這樣交付的解決方案，能夠建立出真正的競爭優勢，提升客戶滿意度！

    業務分析師在敏捷專案中的作用

    敏捷軟體開發實踐的文化中存在著一個斷層，該斷層同樣體現在許多敏捷團隊中。這個斷層就是業務分析人員在敏捷專案中的角色——誰來擔任這個角色？它的作用 和價值是什麼？它又是如何發生改變的？這種情況的潛臺詞（其實我曾至少聽人說過一次）就是：“我們不需要什麼見鬼的分析師！”。無需贅言，我當然認為這是 大錯特錯！在本文中，我證明如下觀點：只要以正確的方式向業務看齊，業務分析師就可以幫助敏捷團隊成功，而不是像大多數情況那樣以開發團隊為導向。

    為什麼要有業務分析師這個角色？

    我的觀點是：沒有業務分析人員，就會發生真的斷層。舉例來說：

    誰會注意最大的組織問題？

    為了高效工作，使用者（可怕的詞彙——不過這是另外一個話題了）有自己的需求，而管理層（說到底，他們是為開發軟體買單的“客戶”）的要求可能與之衝突，誰去識別這種潛在的衝突？

    假如現在有1500人以目前現有的方式工作，如果我們實施了新的軟體之後，他們的工作模式會發生很大變化，誰來發現這樣的事情？

    當組織的工作流程因為新軟體的實施而發生改變時，有些人要負責設計新的工作流程，以保證業務可以繼續順利運轉，那麼誰來幫助這些人？

    與客戶互動不當產生的潛在業務損失，誰來發現？

    我可以繼續舉例，不過我想你應該有概念了。

    誰是我指出的這些“業務分析師”？

    國際業務分析師協會（IIBA）指出：業務分析師“要充當各個利益相關者之間的聯絡人，從而提煉、分析、構成、驗證與業務流程、方針政策、資訊系統的變更相關的需求”。

    業務分析師要承擔“萬能溝通者”的角色，以清晰有力的方式理解並表述出不同利益相關者考慮問題的角度，協助業務人員發現模糊的潛在需求並使其逐漸清晰，從而識別出真正有附加值的需求。

    這個角色超越了使用的開發方法論，最新版本的BABoK?（Business Analysis Body of Knowledge，業務分析知識體系）明確說明了敏捷相關技巧的價值和重要性，還介紹了業務分析活動在敏捷專案中的變化。

    關於IIBA

    國際業務分析師協會（IIBA）是一個職業組織，它這樣描述自己：“世界領先的業務分析師職業聯合會”。IIBA在全球13個國家有78個分部，涵蓋44個國家的7128位成員，它的宗旨是：“為業務分析師的實踐和相關認證制定並維護相關標準。”

    IIBA釋出了BABoK?這個知識體系，其中涵蓋了作為職業業務分析師應該具備的廣泛技能和素質。BABoK?不特定於某種特定的方法論，不過在2.0版本中明確指出了敏捷方法對於開發軟體解決業務問題這方面的重要貢獻。

    IIBA為業務分析師提供了認證計劃，稱為“業務分析職業認證”（CBAP?），主要基於該領域中經過驗證的經驗和BABoK?知識領域中的知識。

    關於作者

    Shane Hastie是Software Education的 首席知識官，Software Education是位於澳大利亞和紐西蘭的培訓和諮詢提供商。Shane教授的課程和提供的諮詢服務涵蓋下列領域：敏捷相關技巧、軟體專案管理、業務分 析、軟體測試。Shane通過了“業務分析職業認證”（CBAP?），並在2007年拿到了他的資訊管理專業的碩士學位。他的碩士案例研究了在一家澳大利 亞ERP廠商實施敏捷方法帶來的好處。他還是一名通過認證的ScrumMaster（Certified ScrumMaster），並於2008年12月2日開始生效。Shane有25年以上的經驗，長於為業務問題提供技術解決方案，涵蓋包括財務機構、航空 公司、製藥公司、設施管理、車隊管理和電信等諸多行業。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-566572/，如需轉載，請註明出處，否則將追究法律責任。

相關文章