客戶訪談 – Ruddy Lee 分享空間

不寫規格書是軟體專案開發中最大不必要的風險，其愚蠢程度就像不帶裝備就想橫越寬闊的莫哈維沙漠，並心存僥倖能逃過一劫。

– Joel Spolsky

000 requirements

敏捷規格文件的產出物及流程

第一份文件

傳統的開發方法；訪談的目的就是要產生第一份規格書。首先；與客戶約好時間過去訪談，採用一對一或一對多的採訪方式進行並做成紀錄。接著將紀錄帶回公司之後一定要趁熱，在客戶還沒有開始遺忘訪談內容時盡快地整理成文件並讓客戶確認。客戶確認過(簽名蓋章)的這份文件便是專案開發最重要的依據了。如果能夠順利地進行到這裡，系統分析人員便可以依據這份文件開始他的分析作業，接著是系統設計人員上陣把該做的架構設計完備(當然，資料庫的設計也OK了)，然後再交棒給程式開發人員的手上來進行實際開發作業，此時專案便可以算是順利地開始運作起來了。整個流程看似人人各盡其職，每個關卡都把任務交給擁有專長的人做它們最拿手的事，這很合理，但敏捷開發並不這麼做。

收集使用者故事，弄清楚客戶真正的需求

「敏捷開發」則是將訪談設定為: 設法收集描述客戶需求所採用的使用者故事(而使用者故事嚴格說起來不能算是功能規格的描述文件，它的目的只是想藉由故事來引出交談討論的效益)，而目標則是放在能夠弄清楚客戶真正的需求。

.

000 客戶訪談

邀請客戶與開發團隊一同進行需求訪談.

敏捷開發所進行的訪談方式與傳統開發的正好相反，敏捷開發是邀請客戶到公司來對著整個開發團隊一起做需求說明的方式，讓負責開發的工程師(整個團隊)實際上與客戶面對面一起進行討論，而不是透過SA或PM來進行所謂的專訪紀錄。無疑的這是一種成本較高的訪談方式，但它能給真正負責開發的人員有機會接觸到真正的客戶(這一點未必辦得到，因為要找到真正的客戶，有時候還真是困難)並就需求進行討論，對未來的開發作業有著莫大的幫助，這一點不難理解，但是很多人認為這樣做會太花時間了，還不如把工程師的時間節省下來進行真正的開發工作，其實這便是約耳所謂的最大的錯誤，它就跟不寫文件，認為「寫文件」是浪費一模一樣了。請務必再看一次文章開始那句話。

不寫規格書是軟體專案開發中最大不必要的風險，其愚蠢程度就像不帶裝備就想橫越寬闊的莫哈維沙漠，並心存僥倖能逃過一劫。

– Joel Spolsky

000 JOEL

Joel 有中文名字

邀請客戶與團隊一起做訪談，可行嗎?

如果開發團隊只有一個人，那又要如何來進行訪談呢? 這是普遍開發人員都會碰到的問題，一個人的開發專案要怎麼做呢? 這種單打獨鬥型的開發人士不論國內外或是大的IT單位，都是經常會遇到的情境，那該怎麼進行呢?

一種運用資深人才或技術領導Technical Lead的作法，它是讓技術小組的組長或資深人員陪同負責開發的工程師一起進行訪談的作法。除非你是一個人的公司，否則千萬不要讓工程師一個人埋頭苦幹，然後才在背後說完全不知道他都在做什麼(苦笑)! 一定要製造一種讓團隊能夠互相扶持與回饋的作法。敏捷；只要是開發團隊就需要維持著這樣的透明化的行為，才不會讓團隊失去他的聚合力而產生漸行漸遠的現象。

好吧! 我就是一個人的開發團隊，怎麼辦呢?

》不急；先來弄清楚製作文件的目的，先了解規格文件能幫上你什麼忙，才能抓住重點，要做到敏捷開發所謂的 Just enough的文件製作。只要把握這個原則，一個人或是再多人一起進行開發工作，也就不是問題了。

首先要知道，規格文件可以幫你:

預作程式的功能設計 (所以如果能有多幾個人來幫你，該有多好?!)
維護的好幫手 (幾個月後，保證第一個來看程式的人應該還是你自己)
便利於溝通 (文件並不是好的溝通方式，但卻是一種可以依據的基礎)
作為估算進度的依據 (給客戶作計畫用?這應該是客戶或主管最基本的要求)

》接著要設法讓這些文件「活起來」

敏捷開發是一種「務實」的開發方法，它不是不作文件，而是不想擁有不正確的文件，當文件能夠擁有足夠的正確(包容)性時，我們就可以繼續相信它，例如一些系統概述、架構簡介之類的高階的說明類文件。這種文件不論是採用傳統的Word或Excel 甚至 Power Point來製作都OK，重點是它能夠抽象的表達它的意圖，並讓觀看的人能夠迅速理解，這才是重點。因此它不能太過仔細，因為一旦太過明確化了它的生命週期就會很明顯地跟著變短了。

製作活文件；一種可以持續被修改而大家都能看得見的資料。專案開發的時候持續把資料放在Wiki上是最典型的作法，這一點就是幾乎所有的 Github 伺服器都會附帶wiki server的原因。例如會議記錄、結論或各種版本的規格，記載在這裡是最好不過的了。它展現出一種集中的保存方式，隨時可以被看見或是追朔則是最基本的功能要求。

》最後；要讓這些文件「持續地活著」

這樣的要求看起來很簡單，但有很多的單位卻都做得很糟糕。我們就用對Bug的處理方式來做說明。請問貴單位有 Bug Tracking System 嗎? 如果沒有的話，那貴單位的程式品質一定不會太高的。我們都很清楚，沒有程式會沒有 Bug的，但卻又都選擇不去面對它。這一點很有趣，像極了高德拉特的限制理論，我經常拿它來比喻成Bug的修復過程(註2)。以下是Bug Tracking system 至少需要作的紀錄:(請參考 Joel on software )

如何重現此缺陷bug的完整紀錄。
系統應該要有的正常行為表現。
實際觀察到系統在缺陷下的行為表現。
修復的負責人員名字。
最後一次修復後的狀態。

持續的tracking 這些系統的缺陷是絕對物超所值的。你只要想想那些星期一剛上班，就收到Bug回報電話，緊接著而來的雞飛狗跳的情景。趕緊下決心就從今天開始啟動Bug Tracking 系統吧!

真實的訪談

只要是人跟人的溝通，訪談的成果跟參與者的人格特質與技巧好壞就是一個很難避免的問題(當然經驗是絕對可以幫上忙的)。傳統開發經常把訪談看成是一次決生死的場景，即便不是認定一次就OK，也經常會為自己設限訪談的次數，總之是越少越好。但敏捷開發不這麼作，而是採用迭代(iteration)的方式來打破這種需要訪談幾次才夠的思維模式。敏捷把客戶看成是團隊的一員(萬一客戶屬於那種不會出現的類型時，就挑個代理的客戶，由他全權來代理客戶，我們稱它為Proxy PO)。目的是讓需求能夠做到持續優化的改善行為，目的當然是讓產品在長期的開發作業之後，在上市時仍然能夠符合到市場上的需求，不會因此而成為過時的產品。

問「問題」是訪談時最基本的工具

但如何才能把問出來的零星解答驟合成一幅較完整的需求描述呢? 我想；大家都曉得問問題的 5個 W理論，它很有效但也很短暫。為何「短暫」呢? 因為你很難從頭到尾都這麼去問問題，受訪者很快就會因此而到煩躁起來，所以這麼問問題可能會造成訪談很快就結束了。敏捷開發主張以故事的方式來描述問題(使用者故事裡只有3個W，Who、What、Why)，但明確的指出受益者是誰，這種圍繞者使用者的描述方式，能讓問出來的問題始終有所依歸，問題只有對當事人的輕重區分，而不至於跳過當事人形成方向上的凌亂雜湊。在收集足夠多的使用者故事後你可運用階層式的「使用者故事地圖」來開始拼湊需求的全貌，一種抽象的解題技巧就開始成形了。它可以做為運行 Scrum的計畫會議時最好的依據，讓整個專案能夠自始自終在足夠的抽象層上看見全貌，這種技巧在敏捷開發裡十分受到歡迎(細節請參考:看見的力量 – (III)使用者故事地圖 )。

哈哈!受訪者很少會知道如何來講述使用者故事的，因此撰寫故事的工作便成為訪談者的責任，而如何引導問題的描述讓它變成使用者故事便是一種訪談者該有的技巧了，需要多練習(此時Gojko Adzic 的 Impact Mapping 可能最適合排上用場了，請參考影響地圖)。

還有一些細節跟作法，請參考 : Agile Documentation 敏捷開發需要哪些文件?

》要如何讓使用者故事便成規格文件呢?

只要針對使用者故事再加以提供畫面、場景(scenario)描述或是流程說明，它就變成了如假包換的功能規格書了。

000 scenario