那么，需要做多少前置分析呢?在開(kāi)始開(kāi)發(fā)一個(gè)用戶(hù)故事之前，我們只關(guān)心三件事：

　　交付用戶(hù)故事的marginal value是什么?

　　交付用戶(hù)故事的marginal成本是什么?

　　我們是否有足夠的信息開(kāi)始開(kāi)發(fā)用戶(hù)故事?

　　前兩個(gè)問(wèn)題是很重要的，這樣當有交付能力時(shí)，我們就可以決定我們應該做哪個(gè)用戶(hù)故事。為了做到這一點(diǎn)，需要找到哪個(gè)用戶(hù)故事會(huì )讓經(jīng)濟產(chǎn)出最大化。而后兩個(gè)問(wèn)題是緊密相關(guān)的，因為評估某個(gè)用戶(hù)故事的成本所需信息的數量通常要比你開(kāi)始實(shí)現它所需的信息量多。但是，象我的同事Peter Gillard-Moss曾經(jīng)和我說(shuō)的：至少需要一個(gè)驗收條件。

　　“剛好夠用的分析”這個(gè)紀律需要在整個(gè)項目生命周期持續進(jìn)行，并要強調創(chuàng )建小的、增量式的用戶(hù)故事。這會(huì )把我們帶到下一個(gè)實(shí)踐： doing less。

　　Do Less

　　“[如果]你發(fā)現自己沒(méi)有空間放卡片，就使用更小的卡片.” PhlIp (see “Re: [XP] Re: Token definition in User Stories”).

　　在敏捷分析中，也許最流行的短語(yǔ)就是Bill Wake的INVEST原則。Wake認為，好的用戶(hù)故事是獨立的(independent)，可協(xié)商的(negotiable)， 有價(jià)值的(valuable)，可估計的(estimable)，小的( small)，和可測試的(testable)。我想說(shuō)的是：“小的(small)”。

　　大家常常認為，特性 features 和 stories 是可以互換的。有時(shí)候人們認為一個(gè)特性就是需要花兩星期完成的工作。我記得在某個(gè)項目里，一個(gè)用戶(hù)故事就是一個(gè)幾頁(yè)長(cháng)的word文檔。

　　XP讓人們把用戶(hù)故事寫(xiě)在一個(gè)3 [ts] 5的索引卡片上，這是有原因的。用戶(hù)故事不應該幾天內還做不完。超過(guò)一個(gè)星期的工作就是太長(cháng)了，應該被分成更小的工作。為什么呢?

　　為了確保我們可以從用戶(hù)那里得到對我們工作產(chǎn)出的瞬時(shí)反饋，以便我們可以發(fā)現我們做的事情是否有價(jià)值。

　　為了驗證我們是否做完了——不只是“開(kāi)發(fā)完成”，而是可發(fā)布——以便我們可以展示我們真實(shí)的工作進(jìn)度。

　　為了避免完成大塊工作后再集成、測試和發(fā)布帶來(lái)的痛苦。

　　為了確保我們不斷地測試并改進(jìn)我們的交付過(guò)程

　　常見(jiàn)聽(tīng)到的反對意見(jiàn)是，我們不能在幾天內就完成有價(jià)值的事兒。我認為，這說(shuō)明了兩件事兒。一是缺乏想象力，二是沒(méi)有理解“哪些東西組成了價(jià)值”。正如我之前提到的，只有通過(guò)向用戶(hù)展示，一個(gè)用戶(hù)故事的價(jià)值才能被衡量。的確，你無(wú)法在一兩天之內就完成整個(gè)特性。是，你可以完成該特性的一個(gè)很小的部分，并得到反饋。比如說(shuō)，你正在做一個(gè)網(wǎng)上訂酒店的網(wǎng)站，打算增加一個(gè)特性，讓人們能選擇他們是否需要早餐。你不必為所有的酒店或所有的合作方創(chuàng )建這個(gè)功能。相反，最開(kāi)始的一個(gè)用戶(hù)故事只是為某個(gè)酒店增加這樣的特性，而且也不需要什么配置選項，然后在進(jìn)行下一步時(shí)，為這種特性的可行性收集一些反饋。

　　無(wú)論你做什么，都不要把特性按照解決方案中的那些分層概念來(lái)劃分用戶(hù)故事，比如一個(gè)故事是實(shí)現持久層，另一個(gè)故事是實(shí)現業(yè)務(wù)邏輯，還有一個(gè)是實(shí)現UI。用戶(hù)故事應該總是很小的縱向切分。如果你不得不做一些集成工作，也要聚焦于讓這種切片盡可能薄。比如，假如作為功能的一部分，你要傳遞一系列信息的消息給另外一個(gè)系統，那么你第一個(gè)用戶(hù)故事應該是傳遞那個(gè)最簡(jiǎn)單的消息，以便第一次實(shí)現就做到“端到端”的集成。

　　通過(guò)不斷對功能的分解，直到找到你可以向用戶(hù)展示的功能最小集，來(lái)強迫自己找到某個(gè)特性的真正價(jià)值(并從中學(xué)習)是一個(gè)很困難，但也極其有價(jià)值的學(xué)問(wèn)。你可以使用得到的反饋來(lái)決定下一步(兩三天的工作)的工作是什么，或者是否不要再按當前的樣式開(kāi)發(fā)這個(gè)特性，因為它并沒(méi)有象你想的那么有價(jià)值。

　　時(shí)刻牢記一點(diǎn)，即軟件開(kāi)發(fā)中，最大的浪費就是無(wú)用的功能——超過(guò)50%的功能從來(lái)沒(méi)有或很少被使用(詳見(jiàn)這里)。

　　不要問(wèn)下面這類(lèi)問(wèn)題：“我們還要加點(diǎn)什么放在這個(gè)特性里，才能確保大家喜歡它?”或者“我們還要在當前這個(gè)版本中增加哪些功能，才能算一個(gè)真正偉大的產(chǎn)品?”。相反，需要問(wèn)這樣的問(wèn)題：“我們現在就能交付我們手里的東西嗎?如果不能，那是為什么呢?”少做點(diǎn)兒，你就不再太關(guān)注你付出的努力，而是關(guān)注于從你的用戶(hù)那里學(xué)到了什么。

　　你可能想做一堆用戶(hù)故事之后才把某個(gè)特性展示給所有人。但總是要在發(fā)布和確保發(fā)布內容滿(mǎn)足質(zhì)量要求(由用戶(hù)決定)之間做出平衡。所以你需要feature toggles。

　　Include Feature Toggles in Your Stories

　　“現在，在Facebook.com網(wǎng)站上的代碼中，已經(jīng)包含了后六個(gè)月后將要發(fā)布的特性了。” Chuck Rossi (see TechCrunch discussion about Rossi’s May 26, 2011 “Facebook Tech Talk”).

　　如果你想提高發(fā)布的頻率，將應用的部署和特性的發(fā)布解耦是關(guān)鍵。特性開(kāi)關(guān)是一種模式，用于控制誰(shuí)可以使用哪個(gè)特性。這樣，即使軟件中包含一兩個(gè)故事，還不想公開(kāi)的未完成特性，你也可以發(fā)布新版本。

　　Facebook的工具Gatekeeper讓它可以動(dòng)態(tài)控制誰(shuí)能看到哪個(gè)特性。比如，將某個(gè)特性?xún)H開(kāi)放給10%的Facebook用戶(hù)， 或者那些在Facebook工作的人，或者25歲以下的女性用戶(hù)，或者是英國居民，等等。(Gatekeeper甚至有這樣一個(gè)開(kāi)關(guān)，可以讓除了TechCrunch員工以外的所有人使用某個(gè)特性)。這使得Facebook的開(kāi)發(fā)人員可以?xún)H在某類(lèi)人群中試驗某個(gè)特性，并逐步向更多的人群擴展。

　　在將特性分解成多個(gè)用戶(hù)故事時(shí)，特性開(kāi)關(guān)是一種非常重要的約束條件。對于使用開(kāi)關(guān)來(lái)說(shuō)，常見(jiàn)的反對意見(jiàn)是： ”有些用戶(hù)故事會(huì )涉及所有的用戶(hù)界面。如果對其使用特性開(kāi)關(guān)的話(huà)，需要增加很多工作。” 答案是：以一種非常容易增加特性開(kāi)關(guān)的方式將特性分解成用戶(hù)故事。

　　特性開(kāi)關(guān)應該是用戶(hù)故事中的一等公民。Orbitz的一個(gè)團隊在其用戶(hù)故事中有特性開(kāi)關(guān)，那么他們在實(shí)現這個(gè)用戶(hù)故事時(shí)的第一個(gè)任務(wù)就是加一個(gè)開(kāi)關(guān)。特性開(kāi)關(guān)是用戶(hù)故事價(jià)值的一部分，當然，由于增加開(kāi)關(guān)所帶來(lái)的開(kāi)發(fā)成本也在估算時(shí)考慮了。如果增加開(kāi)關(guān)的成本太高了，這就是一個(gè)信號，你的用戶(hù)故事分解的不好。

原文轉自：http://kjueaiud.com