以前做Dev時，覺得BA的工作十分專業，也十分有章可循。那是一個非local client的敏捷專案，我們的BA基本上是工作在Story級別的。

        準備一組需要和客戶確認的stories，畫好lofi。如果lofi畫的好，和客戶討論的時候，就進行的十分順暢。因為好的lofi既確定了這個story的scope，又將之前討論得到的客戶的想法形象具體的反應出來，那麼，討論的範圍和物件就十分確定，討論也就十分有效率。

        敏捷最講究第一時間獲得反饋。經過上述討論過程，客戶對BA的story分析作出確認，我們就拿到了我們想要的反饋。而在這個story從開始開發到完成，反饋中確認下來的東西基本都不會改變。這是因為，一方面因為，story的開發時間比較短，另一方面客戶對著lofi作出決定時對自己的需求十分明確。而story完成後，又會及時的展示給客戶看，我們叫做showcase，即使需求有變化，也可以在showcase時即使抓住，作出反應。

        這樣，通過不斷的及時反饋，不論是開發團隊，還是客戶，都可以將可能的浪費降到最低。

        然而，如果客戶是“agile不合作”的呢？“agile不合作”的表現有：

        一、對lofi沒有任何意見

        客戶覺得，lofi只是一個介面的示意圖，而看不到lofi應該承載的功能示意和範圍示意的用途。所以，在他們看來，也就沒有對著Lofi討論的意義。

        若是可以面對面的交流，也許可以糾正客戶對Lofi的認識，而做為一個分散式的專案，通過電話會議，雙方在電話的兩端對著同一份lofi設計，是無法達到預期效果的。

        二、不參與showcase

        showcase是story完成後獲取客戶反饋的最有效的途徑。既然客戶沒有Lofi階段的思考，那showcase的時候，也就沒有參照物件。說的直接一點，就是，客戶對做好的story，心中既沒有肯定意見，也沒有否定意見。既然如此，客戶也認為，showcase沒有意義，所以也就不參與了。

        三、不配合收集final users的反饋

        敏捷很厲害的一招就是迭代式交付。迭代式交付有兩個非常重要的好處：讓客戶儘可能早的得到可執行的軟體，優先實現客戶認為最重要的部分；儘可能早的得到final user的反饋，因為發現問題越早，修改代價越少。而客戶則認為，反饋即是批評，若系統不完善，是絕對不能讓使用者接觸到的，否則，第一印象不好的話，以後哪怕再怎麼逐步完善，這個系統也是曾經被人批評過的。

        其實，“agile不合作”並不能說是錯的。在本土客戶所理解所熟悉的開發模式下，他們認為：

        一、自頂向下的功能模組劃分比story好理解

        我只知道，我要這樣一塊功能，至於你們分解成什麼形式去做，為什麼非要我來確認？

        二、你們應該比我更熟悉我們要什麼

        不要問我具體要什麼東西，我只知道我的目的和我需要的功能的大概描述，你們不是有領域專家麼？給我點建議，我一定樂意採納。

        三、UE設計完全是開發團隊的事

        為什麼拿著圖來問我，是不是同意頁面分成這樣幾個功能區？為什麼要問我，是不是同意這樣的設計風格？這不是我需要考慮的問題。

        這樣一來，最初接觸這個專案的時候，我找不到有效的工作方式。