作者 Geoffrey Wiseman 譯者 苑永凱 發(fā)布于 2008年1月24日 上午6時46分

社區(qū)

Agile

主題

敏捷技術,

客戶及需求

標簽

業(yè)務/IT整合

在《我雖不知想要什么，但卻知道怎樣得到它》一文中，Jeff Patton談及了敏捷團隊與商業(yè)用戶在溝通中造成彼此誤會的幾個方面，并主張敏捷社區(qū)應當正確的使用術語“迭代（iterating）”、“增量（incrementing）”和“可交付（shippable）”。

Jeff在文中首先羅列了一些句子，來凸顯對商業(yè)用戶和軟件開發(fā)團隊更準確的闡明迭代概念的必要性。

• “我們知道想要什么。但你能估算出構(gòu)建它需要多長時間嗎？”
  
• “在啟動開發(fā)之前，我們必須將這些需求明確下來。”
  
• “客戶不知道他們想要什么”
  
• “客戶時常改變想法”

接下來，Jeff記述了迭代和增量兩個截然不同的概念——雖然兩者常常被混為一談，但都被敏捷團隊用于交付價值（deliver value）——以及使用它們的原因。

就增量開發(fā)來說，我的意思是每次遞增的添加軟件功能。每一次增量都會添加更多的軟件功能——這與往墻上添磚加瓦有幾分相似。在多次增量之后，你將得到一面大墻。

• 我們使用增量法逐漸地增進功能，那么如果開發(fā)花費的時間多于預期，我們可以將迄今為止已經(jīng)增量構(gòu)建的功能發(fā)布出去。（之所以使用黑體的“如果”，是因為我實在不記得有哪個我參與過的項目開發(fā)花費的時間少于預期。）
  
• 增量地釋放版本，所以我們可以實際地得到我們已創(chuàng)造的商業(yè)價值。因為在人們開始使用我們構(gòu)建的軟件之前，我們是不會真正地得到投資回報的。在那之前，預期的商業(yè)價值只是一種估計。如果你認為估算軟件開發(fā)是困難的，那么就嘗試估算投資回報率吧。

對迭代開發(fā)的描述如下：

我對迭代開發(fā)的理解是我們構(gòu)建軟件，然后評估它是否能夠正常的工作，然后對其作出修改。我們構(gòu)建軟件然后期望對其作出修改。我們從不指望構(gòu)建結(jié)果正是所需的。如果是的話，那這是一個幸運的意外。正因如此，我們至少要做到常常構(gòu)建，然后校驗其構(gòu)建是否是正確的。

• 我們通過迭代找到正確的解決方案。
  
• 然后給出一些好的候選方案，可能而后我們在迭代中改進某個候選方案。

在敏捷開發(fā)中，當沒有人計劃迭代時，那么一切都會癱瘓。

他接著爭論道，術語“可交付”的使用進一步混亂了局面：

對于想要出售或者使用軟件的客戶，可交付就意味著他們可以明確地出售或者使用軟件。這意味著軟件要保證最小功能集可用。軟件必須達到計劃中的目標——至少 要做到與舊軟件或者被替代的文件流程功能相同。軟件必須有良好的外觀和功能——保證高質(zhì)量的精確度和完整度（fit and finish）——特別對于商業(yè)軟件，而你的競爭對手正在對你造成威脅。

可交付意味著已經(jīng)完成了。徹底地完成并掃尾。不再需要為一些事情進行迭代——真正的可交付了。

對客戶們說“可交付”就意味著暗示他們最好確保提出的需求都是正確的，因為這就是敏捷開發(fā)工作的方式。

那么，為了幫助客戶理解迭代的含義，他建議：

我們應該對客戶和產(chǎn)品所有人（product owner）解釋說，將那些他們不打算發(fā)布的需求寫到用戶故事（user story）中也是重要的。將他們打算評估、學習、改進或者作為失敗的實驗品丟棄的需求都寫到用戶故事里。

在與我的朋友Alistair交談中，他提議為每個需求編寫三份故事卡片而不是一份。第一個故事卡片上描述了真實的故事。第二個卡片是為了我們了解故事之后作出不可避免的修改而準備的。第三個卡片用于修改之后的微調(diào)。

這是一個規(guī)劃迭代的例子。它能緩解客戶大部分的壓力——由于擔心其描述的故事是否正確（因為必須保證這些故事“可交付”）而極度苦惱、戰(zhàn)戰(zhàn)兢兢。

他還創(chuàng)造了一個新的縮寫詞：“YAGRI：你將不會發(fā)布它（You aint gunna release it）”。