模板
教程
環境
性能
功能
管理
一種新的軟件生命周期模型
拉動的力量：一種新的軟件生命周期
IT項目的起因很多，但是只有一部分軟件能夠帶來真正的改變。軟件開發是昂貴的，在預算緊張時，把錢花在刀刃上就變得異常重要。
在這篇文章中，我們將要看到如何把來自精益方法的看板，與來自行為驅動開發的特性注入模版結合在一起，來幫助我們識別最重要的軟件，在開發的各個階段中消除不必要的浪費，用最少的產出來完成目標。
下面的圖顯示了本文所講述的新的軟件生命周期。這些產出物給每個角色發出信號，促使他們創建更多的產出物，直到完成目標并獲得商業價值。
最有價值的軟件是還沒有寫出來的軟件
Dan North將軟件與金屬進行了比較?！吧蓤蟾妗?，他說，“就像鉛。很容易得到，還很便宜。但同時也很重，沒什么價值，還會拖你的后腿。開發人員耗費大量 時間編寫報告軟件。為什么不直接買一個、安裝上、做一點修改，這樣不是也行么?或者使用Excel。除非你是一家銷售這些軟件的公司，否則不要花錢來構建 報告軟件。
“還有些軟件是比較難做的，需要配置并與第三方交互，但你還是可以購買。這就像銅”。他談到了子域(subdomains)支持，這個詞來自于Eric Evans的《領域驅動開發》。這就好比一個核心業務是尋找石油的公司，“他們需要GPS系統。雖然不是每個人都需要這樣的系統，但是他們需要，而且還有 很多人也需要。那么你可以購買GPS系統，然后集成到你的系統中”。
“因此”，我建議，“如果你有類似的需求，而且這種需求對誰都是一樣的，但是還沒有人賣，那么你或許希望能有人幫你做一個這樣的產品?！?/p>
“當然?！彼诳ㄆ蠈懙溃?/p>
| LEAD | COPPER |
Dan說：“這個是鉛。我跟CIO們談談，問問他們花了多少錢在這上。太多了!”
“那么上面是什么?”我問道。
“上面(左上角)是能快速帶來價值的東西。我們有一些軟件，它們很容易構建，而且涉及到你的核心領域。這是Agile實驗項目的理想目標，可視的、高價值的項目，而且沒有人做過。本質上來說它們是差異化的。它們有價值，它們是黃金?！?/p>
“然后是右上角，這個象限是白金項目。它們很難做，是核心領域，充滿風險而且可能需要和第三方進行交互，非常困難的交互，它們是有價值的差異?！?/p>
| GOLD | PLATINUM |
| LEAD | COPPER |
David Anderson定義了四個商業關注點：商品、差異、節約成本和破壞者?！斑@是必然的”，我說，“總會有人破壞你的這些差異性-你的黃金和白金項目。他們 會盜用你的創意-不需要承擔你所承擔的風險，因為他們看到它確實可以使用-然后用更低的成本實現。這就是為什么我們需要敏捷，未來的某一點我們必然要改 變，來創建新的差異?！?/p>
Dan笑著說：“Chris Matts認為，構建軟件只有三個原因：賺錢、省錢、捂錢，這第三個原因非常有意思。LastMinute.com是一個典型的例子，他們通過與供應商簽 署排它性協議贏得了所有的市場-劇院、休閑以及任何他們認為具有最后期限，而且人們可以在到期之前取消的東西?；叵肫饋?，LastMinute的想法是顯 而易見的，但當所有人都來分一杯羹時，逐漸縮小的投資回報導致只有很少一部分人能夠堅持下來。
“當然，白金項目成本會比較高，因為他們很復雜，但從這個角度看，它比黃金項目更有價值?！?/p>
“好的”，我說，“因此，理想情況下，我們應該每周或每兩周就發布新的軟件版本，我們需要快速響應商業需求。當然，我們知道有些人會破壞我們的東西。因此 為了保護我們的錢，我們需要有一個最小商業特性集，它要能使復制的成本非常高昂。而且，必要的復雜度實際上是好事，它能使我們保持不同……至少在某段時間 內不同。創建一些差異，然后保持這些差異，這就是我們的工作范圍?！?/p>
現在，我們知道了如何識別重要的目標和它的范圍，下面我們該看看如何實現它了。
愿景促使干系人創建特性集
一旦識別出愿景，最初的干系人會通過思考所有需要參與的人，來確定項目其他的干系人。然后干系人會考慮他們需要哪些東西來實現愿景。我們通常是用這個模版：
作為……
我希望……
于是……
我記得Guardian的編輯們使用這種格式，業務分析師們將之稱為“討要功能”。Chris Matts發現了這個問題，“你將干系人放在了最前面，所以他們會考慮那些能證明他們的東西。換一種方式，我們可以將愿景放在前面。這樣人們就不會添加和 愿景無關的東西，有助于減少需求范圍的蔓延。事情本來就應如此……”。我將他的建議記了下來：
為了……
作為……
我希望……
特性集對愿景的依賴與開發人員將依賴注入到代碼中的方式很相似，并不是因為它是個好主意，而是因為它是必須的，因此有了這個詞-“特性注入”。
有時我們發現，將愿景分割成一些小的目標很有用，它們定義了一個終點，而且總是可以回溯到大的愿景。
除此之外，那些提出story的干系人并不總是最后會使用它們的人。Captchas-使用難以識別的圖形字母來做圖靈測試-就是一個例子?！白鳛?一個用戶，我希望有一個captcha，于是……等等，我不想要captcha，這是浪費我的時間”。我們使用模版來寫這個story：
為了……
作為……
我希望……
例如：
為了防止機器人給我的網站添亂
作為論壇的管理員
我希望用戶必須要回答captcha才能寫注釋。
有些特性甚至跟軟件沒關系!可能我們的story會包含如培訓、物流、網絡管理、法律等東西。干系人通常都會有軟件解決不了的，或者不用軟件解決更好的東西，例如LastMinute.com的排他性合同。當我們考慮愿景時，也需要考慮這些。
這些故事通常會很大，以至于開發團隊無法處理或估算。Mike Cohn將之稱為“themes”，而特性驅動團隊稱之為“特性集”，我們也這樣稱呼它們。
每個特性集的輸出-例如，別讓機器人來煩我-可能不能只依賴一個特性或者一個干系人來實現，我們會在過程中發現，其他的特性集可以實現或幫助同一個產出。當這種情況發生時，我們會再次審視一下我們的特性集。
特性集促使BA(業務分析師)創建用戶故事
Chris Matts有一個理論?！澳阒廊藗兿胍裁疵?”
“想要什么?”我問道。
“他們向你要求的。你知道他們不想要什么么?”
“不想要什么?”
“你希望他們要的。你知道還有什么么?”
“還有什么?”
“一旦他們得到了他們想要的，他們就會要的更多?！?/p>
從多年嘗試瀑布模型的經驗中我們得出，我們很少能夠事先預知所有的事，試圖在一開始就做對是不完美的。干系人想要一些不同的東西，當我們終于將事情做對了，他們又開始要更多的東西了。
通常，我們在用戶故事和特性集上做決定時所處的環境，會隨著時間而改變，特別是在項目的生命周期內。唯一能讓我們知道我們對項目的理解是否正確的方 式就是盡早得到反饋。得到反饋最好的方式，是給干系人一些他們可以實際操作的東西，他們可以體會用戶或其他消費者的體驗，并調整他們最初的想法。
為了達到這個目的，我們可以先拿掉與愿景實質上不想干的東西，即時它是發布商品或者保護差異的最小特性集的一部分。例如，對于購物車我們只有固定的送貨費。修改送貨選項或者大宗商品折扣可以放到以后的story中。
考慮大多數在線商店都會有類似的特性集：
為了能銷售更多的商品
作為網絡銷售的頭
我希望消費者能夠在線訂購商品，并能收到商品
它可以被分解為多個用戶故事：
為了能銷售更多的商品
作為網絡銷售的頭
我希望消費者能夠訂購商品
為了能銷售更多的商品
作為網絡銷售的頭
我希望消費者能夠將商品放在籃子里而且能夠訂購籃子(里的商品)
為了能銷售更多的商品
作為網絡銷售的頭
我希望消費者可以修改送貨選項
為了能銷售更多的商品
作為網絡銷售的頭
我希望當(消費者的)訂單超過一個最小值時，提供免費送貨
