敏捷開發一千零一問系列之六：業務人員怎樣參與開發？

這是敏捷開發一千零一問系列的第四篇。（之一，之二，之三，問題總目錄）

有一次課程上竟然來了一個非開發人員，他是個網站的業務人員，提出了這個問題，並被評爲課堂最佳問題之一。

問題

一線業務部門應該怎樣具體參與到敏捷開發中來？

答案

方案1：

敏捷開發中有不少活動是須要業務部門參與的，若是沒有時間，第一個要參與的事情是「評審會」，就是階段性驗收產品的會議。在會上應該思考產品在實際應用中是否可用，並提出改進意見。

可是要注意改進意見不要急於實現，而是應該詢問下一步原來的計劃，或許原來的計劃更加劇要。

若是能在評審會上對產品將來的應用作出一點預測，對以後的迭代會有幫助。

方案2：

若是能選出一個表明，參與到計劃會中，對於產品經理難以解答的問題給出補充解答，是一個更好的活動。

各類解答應該具備預見性，由於所謂軟件需求，無非是業務需求在軟件中的體現。業務需求不多是沒有計劃就盲目開展的，所以若能提供預見性的解答，對整個產品將來的方向都會有很大的幫助。

方案3：

將業務架構、商業計劃轉達給開發人員。

技術架構其實是業務架構的體現，好比360，其業務從最開始就沒打算侷限於殺毒，因此業務部門就能夠提早告訴開發組，當有一天要開發聊天、安全桌面、安全瀏覽器的時候，開發組並不須要把一個殺毒軟件「重構」成一個聊天軟件，這是不可能的。

對於產品研發，業務部門若能將市場定位、商業計劃、競爭對手等信息充分與開發人員溝通，能夠有效地避免閉門造車、缺少預見性、變動頻繁等狀況。

方案4：

變敏捷開發爲敏捷交付。

敏捷交付是最近的一個熱詞，其核心是真正地次第地交付產品。

在以往的開發中，好比微軟、Nokia，都是作敏捷開發、持續集成的高手，可是他們的產品都不是「敏捷交付」的，都有巨大的版本和斷代存在，而銷售模式也是工業時代的模式：一次付款，不退不換。

在新興的企業中，好比騰訊、蘋果、Google、Facebook及衆多網絡遊戲，都會感受到他們的產品不是「一次買來的」，每次使用均可能有所更新（蘋果是更新應用），這就叫作敏捷交付。

敏捷交付創造了新型的互動關係，使得「擁抱整個市場的變化」落到實處，而再也不是「把可用產品拿給部分用戶評價一番」，這將是將來業務架構的趨勢。

案例

1. 某銀行

在訪談某銀行的開發過程時，開發部門抱怨說業務部門的人只能說出零星的功能，並且還常常在變化，致使變動不少。

後來訪談業務部門的時候，業務部門卻抱怨說開發部門每次開發的產品都不太符合本身的預想，並且每次增長功能都要「重構」，反應時間較長。

後來又訪談一個「戰略規劃部」，發現原來業務部門的業務發展，遠在一年前就會有詳盡的規劃，業務部門所提出的零星需求，其實都是基於這些計劃產生的。若能與研發部門事先溝通這些計劃，開發部門就能充分理解需求的來源、根本目的、將來走向等等客戶價值相關的信息，開發出更加好的需求。

戰略規劃部接受了一個建議：將按期與研發部溝通將來的計劃，從而讓研發部能看到整個業務的全貌。

實際上在銀行這類業務預見性較強的領域，「擁抱變化」不是不斷改進核心價值（在互聯網則是），而是在肯定業務目標的狀況下，不斷改進具體的實現方法而已。

分析

1. 在不少場景中，業務部門都以「客戶」自居（尤爲是甲乙方真正的合同關係時），認爲摸索、返工這些事情都是開發組的負擔，與本身無關（有我）。

但實際上，若是開發混亂，真正受害的無疑是業務人員這些終端用戶。所以應該以無個人精神，去幫助那些爲本身「交付價值」的開發人員，最終本身也將受益。

2. 從案例中可見，「擁抱變化」和低頭走路是兩碼事

在能看到將來的時候，有時候能夠延長Sprint0中作架構的時間，將變化侷限於具體業務細化、評審會上改進產品等活動，開發出來的產品反而更好。

人們在「敏捷地」尋找最佳方法的時候，找到的未必是「敏捷的」方法，而是一種相對重型的方法，由於其業務自己是重型的。這是「無住」的一種典型體現。

用副詞「敏捷地」來描述敏捷開發的時候，一個問題就成了僞命題：「什麼項目（不）適合敏捷？」任何項目，都應該敏捷地尋找最佳方法。