這個貌似是很多項目在實施敏捷中的痛，因爲用戶故事可以很快的寫出來，但是對項目團隊來說，似乎永遠沒有定稿。總有再改一次的想法。
假設我們現在有一個用戶故事A，第一次改版是因爲需求需要明確，所以稱爲了A1。那麼A1能發表出去給團隊嗎？明顯還是不行。爲什麼？因爲我們需要有人審批呀？按照慣例，我們都會需要一些SME或者業務領導來審批，說明這個需求可以進行投產併發布。所以當SME審覈過之後，其實就有了A2版本，因爲必定會再次修改。試想，現在的A2離當時的A1有多遠呢？
這裏我們會面臨以下幾個問題
- A，A1，A2的版本如何有效管理？
- A，A1修改，定稿誰做，誰review
- A1，A2審覈是SME，定稿之後，還可能改，怎麼辦？
這些都是很頭疼的問題，但是不得不去面對。
如何解決
面對第一個問題，有效管理還是挺方便的，利用目前市場上的需求管理工具，可以看到每次修改的變動。例如JIRA裏的歷史記錄。另一種方法就是關閉前一個版本，create一個新版本。然後associate到前一個close的版本。這樣我們就看到故事是在不斷的演變的。並且也可以看到演變的記錄。
第二個問題的定稿就很清晰了，A到A1的時候，就是PO去和end users，team交流溝通得到一個結果就可以了。然後上去修改，或者委託BA代爲修改。
第三個問題的答案，其實就回歸到了第一個問題了，定稿了再改，首先在流程上來說，就是不對了。那麼如果真要修改，也應該是再開一個故事，然後associate到剛纔的一個故事上。作爲一個故事的補充。同時在第一個故事上，寫清楚新的變更被link到了哪個故事。
總結一下，今天我們來討論的是如何定稿，因爲我們做的是敏捷的用戶故事。所以一次是不可能定稿的，也不可能定稿，也永遠允許變更（按照價值觀）。我們的原則永遠是允許變更，但是需要不斷在用戶故事上做associate，作爲用戶故事的補充。
如果喜歡，也歡迎訪問我的個人wordpress，以獲得更多諮詢
http://www.agilep365.com/