例項化需求常見問題
推動例項化需求，講到這個例子時，經常會碰到這些問題：
6
件可配嗎？：例子中提到6件免運費，顯然這個在系統中要可配的，不能在產品中硬編碼（hard code）。但是這個需要在例子中講清楚嗎？
「否者我的開發團隊又要說我需求沒講清楚，不過我總覺得這點意識他們應該有的？」，乙個有著很多痛苦經歷的po問道。
沒有一定的說法。記住！！最重要的是溝通，把需求澄清出，不要有歧義。
這不是wate***ll嗎？：這是乙個簡單的例子，看上去很快就弄明白了。但是在實際中，有太多的需求要澄清呀？
「這樣看上去和以前沒有兩樣，還是要花好多時間來搞清需求，只是快了一點而已？」
不是的，在實際運作中，這是乙個迭代式的不斷澄清的過程，可以把最重要的先澄清。這裡面還有乙個很重要的是：就算在優先順序最高的需求中也有不重要的小功能，這個用例子的方式很容易體現出來。
和用例有區別嗎？：很多人初次接觸這個時總覺得和用例沒區別。
可能，但是我很少看到好的用例，用例很多時候關注在技術實現的步驟上了，所以有很多不必要的技術細節，不太適合產品經理來閱讀。這兒我們要求的是乙份大家都能容易讀懂最少歧義的需求。
當然不排除你的用例很容易讀，沒有冗餘，那往往就是例項化了。
如何實施
以前在估計時間時，團隊很容易用含糊的原因解釋。敏捷實施中又要求團隊來估時間，常見的毛病就是：
我們需要1000人時（manhour），300人時是準備環境，400設計加開發，300人時是測試。
現在用例項化需求後，很容易的針對每個例子來估時間，po也可以根據時間的代價來取捨。
認可了這種實踐，實施起來也相對容易一點，下面列出幾個要點。
循序漸進和現有流程的結合
我們可以不用改變現有流程的方式把例項化需求循序漸進的開展起來，這一點在企業中很重要，大的改變都很費周折。
在測試分析階段，我們可以把簡單的需求列出來，加上理解的乙個最重要的例子就可以了。可以結合迭代式的方式，優先順序高的先多花時間來寫測試用例。
當然在寫測試用例時，我們可以繼續前面的格式，只是多加幾個例子，並且持續地提煉需求說明，使得越來越清晰。
這樣子，你現有的流程就不需要改變，如果你已經有現成的框架來做測試指令碼，那就繼續用下去吧，只要需求明白了，什麼都好解決。
貼在牆上
把需求貼在牆上視覺化一點也是非常有效果的，它可以減少浪費。企業最大的毛病就是會多，每個人都是認為自己的會重要，這是很浪費時間的。
只要我們把需求貼在牆上，團隊就隨時隨地得可以了解最新的進展。隨手拿個即時貼提建議：時間估計，架構的影響...
如果對某個需求需要討論了，召集相關人（千萬不要整個團隊）在小房間搞清楚，然後立即更新需求。因為我們現在用上了自然語言的例項化的需求，任何時候團隊成員應該很容易讀懂，而且沒有偏差；如果有，說明還不清楚。
課後練習
試著把身邊最近工作過的乙個需求用這種方式體會一下
小結
例項化需求是一種很棒的協作探索需求的好辦法，它強調無時無刻地溝通的必要性，還有就是用例子來講述需求更容易理解。但是要用熟練還是有難度的。
考閱讀
1. book: specification by example.
2. specification by example:
3.
例項化需求中文書：
敏捷開發每日一貼 敏捷估算方法
敏捷估算方法 無論是團隊研發一款產品或者開發某乙個專案，我們都需要回答 我們大概什麼時間能夠完成？或者到某乙個時間點，我們能夠做到什麼程度，因此和傳統的開發模式一樣，我們在故事拆分之後需要對我們需要做的事情進行工作量的估算。相對於傳統的工作量估算方式，敏捷估算有如下幾個特點 1.團隊集體估算 在sc...
敏捷開發每日一貼 需求管理和例項化需求
需求管理和例項化需求 軟體開發的最大問題之一往往是需求，而且它也很容易的被作為替罪羊。在公司專案延遲和出大問題的最大藉口，就是 需求不清楚 需求變更 那把需求早點弄清楚不就行了嘛？聽著挺容易，但要做好它卻很困難。敏捷迭代起來以後是否會好點呢？理論上會好點，因為需求在乙個迭代中東西會少點，更容易理清楚...
敏捷開發每日一貼 自組織敏捷團隊的特點
自組織敏捷團隊的特點 敏捷常提到自組織團隊，通俗的講它是乙個由外部建立，然後給與授權，自行決定行動綱領的乙個團隊。這個團隊接受外部給與的任務和約束條件，自行決定如何完成任務。在這個團隊中，團隊成員自己決定做什麼，以及如何做，是 民主 還是 集權 團隊說了算。橄欖球 籃球 足球等體育團隊，就是非 敏捷...