本節書摘來自華章出版社《靈活可執行需求說明 scrum提煉及實作技術》一 書中的第3章,第3.4節,作者:(美)mario cardinal,更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
正如我在第2章裡提到的那樣,建構軟體是為了解決問題。這些問題的描述組成了需求說明的核心内容。對“問題”一詞最有幫助的定義是我曾經從gerald weinberg和don gauss的書《are your lights on?》裡看到的[5]:
“問題:就是願望和感覺之間存在的差距。”
根據這個定義,軟體的存在就是為了滿足這個願望。沒有不為了滿足願望而存在的軟體。一個“願望”是可展示的、對某個幹系人或某些幹系人群體有價值的一部分功能。但是願望本身并不是證明這些需要的唯一動機。
weinberg和gauss突出了願望和感覺之間的沖突關系。“感覺”定義了什麼是人們所需要的。這種沖突關系很好地被新詞“願求”(desirement)表達出來,這個詞是單詞“願望”(desire)和“需求”(requirement)的混合詞。“願求”是“一個非常重要的、是以被了解成需求的願望。”這個杜撰的單詞最初是由david starr [6]提出來的,他把願求定義為“一個非編譯的軟體變更請求”。[7]
“願求”是通過很早就開始、并持續在每個sprint結束時都傳遞有價值的、幹系人願意參與評價的軟體來實作的。通過定期評價可運作的軟體這種方式,幹系人們的想法和願望也會随着他們對軟體的變更請求一起發生變化。
除非你既是軟體的開發者又是唯一的使用者,否則關于“願求”的溝通是一個非常有挑戰的任務。為了更好地了解這些挑戰,讓我們想象一下,在一間黑暗的大屋子裡,開發者和幹系人之間正在針對“願求”進行溝通。因為沒有燈光,是以,在這種情況下是沒辦法收集到任何有用的資訊的。坦白地說,開發者們處在黑暗之中。幹系人跟産品負責人一起也在這間屋子裡,他們每個人都在描述着他們想要的功能。因為産品負責人幾乎什麼也看不見,他隻能從一開始就僅依賴聲音來判斷,但他聽到的都是持不同意見的噪音。想象一下另一種情況,即當每一個幹系人在說話的時候都會發出一種有顔色的光。
當幹系人們大聲地說出他們的想法時,不同顔色的光點照亮了黑暗的屋子。一個人可能會發出綠色的光點,另一個人也許是發出黃色或者紅色的光點,等等,直到大量的彩色光點飛舞在産品負責人身邊,就像五顔六色的螢火蟲。雖然所有這些光點都圍繞着産品負責人,但是他仍然處在黑暗之中,因為并沒有什麼有意義的事情發生。
随着産品負責人試着去辨認這些點亮屋子的小光點,他通過詢問幹系人們的“願求”來引導他們之間的談話。他磨煉着自己的反應能力,當一個“願求”從三個或者四個幹系人嘴裡重複說出來時,他便緊緊抓住不放。當那些關鍵的“願求”被加進來時,這些不同顔色的光點就開始彙聚,直到都變成的白色光束。這些白色的光束就是團隊可以繼續下去的起點。僅僅依靠這些普通的要素,團隊就可以逐漸看清幹系人們期望的利益是什麼。
通過收集這些合并過的“願求”,團隊就可以開始建立有價值的軟體産品增量,并請求得到幹系人的回報。這些回報也許是确定團隊對需求的了解是成功的,或者會有一些幹系人認為他們的“願求”被誤解了。通過這些回報環,“願求”被定義得更加清晰,産品負責人就可以從幹系人那裡收集更多的資訊,繼而開發出更棒的軟體。回報環每隔幾周循環一次,在每個回報環的結束點,産品增量就會傳遞到幹系人手中。當這些增量被完成以後,又一個新的疊代就會從頭開始。在這些幹系人達成共識的過程中,那些白光會變得越來越亮,越來越充足。對于開發者來說,他們的目标就是達到整個房間都被點亮的狀态。
使用靈活軟體開發,你會通過疊代的方法逐漸網羅“願求”進而消除不确定性。“願求”也參與疊代過程了,它們促進了如何建立價值的讨論。通過将關注點從解決方案的屬性轉移到幹系人的“願求”上來,産生了更多有價值的對話。