以前做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設計完全是開發團隊的事
為什麼拿著圖來問我，是不是同意頁面分成這樣幾個功能區？為什麼要問我，是不是同意這樣的設計風格？這不是我需要考慮的問題。
這樣一來，最初接觸這個專案的時候，我找不到有效的工作方式。
我的敏捷之旅
首先說說我對敏捷的理解 敏捷在於 敏捷本身 以最有效最快捷最簡單的方式解決問題，這是我對敏捷的理解。而且那些sprint，scrum，tdd，stand up什麼的，甚至是no hierarchy的結構，只是個形式，可以說是best practice。對於敏捷，我認為 在我和客戶之間，和我partn...
誰是我的客戶？
一直埋頭工作，突然間忽視了這個重要的問題 誰是我的客戶？我們通常理解的客戶是指組織外部的客戶，我們要將我們的工作成果交給他 她，當然工作成果也稱為交付成果，需要令客戶滿意，不然，客戶是不會買帳的。根據工作成果為了令誰滿意，客戶還有其更廣闊的意義。組織內的個體也都有自己的客戶，而且有的，客戶不只乙個。...
我的事實客戶
select id 客戶編號 客戶名稱 客戶級別 持有金額 萬 累計購買 萬 首次投資日期 可用積分 客戶經理 客戶狀態 關注狀態 直代銷 from select id 客戶編號 客戶名稱 客戶級別 持有金額 萬 累計購買 萬 首次投資日期 可用積分 客戶經理 客戶狀態 關注狀態 直代銷 rownu...