? ? 目前User Story初稿由PO根據(jù)客戶的需求來編寫，AC點作為故事的一部分對故事進行說明品山。然后通過Pb grooming胆建、計劃會等過程，與團隊共同review肘交，補充完善笆载。
? ? 然而，實際的迭代實施中涯呻，需求的傳遞并不總是順利的凉驻。迭代發(fā)布計劃會上，POs經(jīng)常會遇到團隊的質(zhì)疑“你這個Story的AC點為什么沒有寫這個邏輯复罐？”“你應(yīng)該在AC點里補充提示語是什么”“超長的處理邏輯需要在每個故事AC點提現(xiàn)下涝登，要不我們怎么知道要不要寫測試案例（TC）？”“計劃會時也沒說（或者不記得了）要做這個呀”效诅。每日站會上胀滚，團隊成員A：“昨天我完成了故事1！今天我將開始工作于故事2上乱投⊙柿”兩天后，PO找到團隊戚炫，“故事1怎么回事剑刑，這個流程和我想要的并不一樣……”。
? ??AC點是……
? ? 作為承擔(dān)需求澄清責(zé)任的AC點到底應(yīng)該怎么寫嘹悼，才能做到“讓團隊滿意”又“不漏不重不冗余”呢叛甫？
? ? 首先，我們來看下AC點是什么杨伙。AC全稱Acceptance Criteria其监，又名“驗收準則”，是PO檢驗user story完成度的重要衡量指標限匣。AC一般作為User story（用戶故事）卡的一個重要組成部分出現(xiàn)抖苦，針對user story內(nèi)容進行說明和解釋。每一條AC都應(yīng)體現(xiàn)出業(yè)務(wù)價值米死，是story的功能集锌历，是story交付時必須滿足的一組條件。
?? ?AC點輔助團隊理解需求峦筒，提高需求質(zhì)量究西，減少理解不一致造成的分歧、返工物喷。AC還可以控制Story可以完成什么卤材，不用完成什么遮斥，甚至該怎么完成。
?? ?AC點不是……
? ? ? User Story的INVEST原則有一條就是“可討論的（Negotiable）”：故事卡是功能的簡短描述扇丛，細節(jié)在客戶團隊和開發(fā)團隊的討論中產(chǎn)出术吗。也就是說，用戶故事不是確定不變的詳細設(shè)計說明書帆精，AC點也不是大而全的詳細設(shè)計较屿，AC點只故事完成的必要的條件。AC點內(nèi)容也只是關(guān)于關(guān)鍵或重要事情的簡短描述卓练，用以提醒團隊和PO進行關(guān)于此項內(nèi)容對話隘蝎。
? ? ? AC點不是澄清User story的唯一工具，PO還可能需要通過UI效果圖及切圖確定頁面布局昆庇、流程圖或交互圖說明交互流程末贾、提示語列表定義系統(tǒng)文案等使所有人對User story的理解達成一致。
? ? ?比如我們在計劃會中整吆，PO講解故事“修改LOGO”時拱撵，除了提供故事卡以外，還會提供UI圖表蝙，開發(fā)團隊提供（或經(jīng)討論）形成各種異常情況的處理策略及提示語拴测。
? ? AC與TC關(guān)系
?? ?Test Cases（測試案例）也是User story的一個重要補充，是AC的具體實現(xiàn)府蛇。TC應(yīng)該比AC更加詳細集索，不止包括AC的所有內(nèi)容，還應(yīng)包括很多異常測試用例汇跨，以確保系統(tǒng)對異常能正確的處理务荆。?比如AC點“用戶名長度為10個字符以內(nèi)”，那么TC就需要至少包括以下場景穷遂。
? ? 在討論中產(chǎn)生很多細節(jié)設(shè)計函匕，也都建議都通過TC明確，以防后續(xù)被遺忘蚪黑。還以前面的“修改LOGO”為例盅惜，在實施中討論到“允許上傳圖片的大小限制應(yīng)該是多少？”這個問題對客戶不敏感忌穿，但對代碼健壯性缺不可或缺抒寂。就需要在確定后，建立一條TC掠剑，以保證實施結(jié)果與與預(yù)期一致屈芜。
?? ?AC點中沒有寫到的內(nèi)容，若開發(fā)未實現(xiàn)朴译，故事算完成了嗎井佑？
? ? 從《Scrum 指南》對Story”完成"的2層定義我們可以找到答案：
（1）滿足DOD（Definition of Done）糕珊。DOD可以是開發(fā)組織的慣例、標準或指南毅糟，也可以是適用于本團隊的定制約定。比如需要所有測試案例都通過澜公，代碼都走查過姆另，儀表盤顯示都通過等。
（2）基于所有人對User story的理解一致的基礎(chǔ)上坟乾，滿足所有AC點迹辐。?比如，檢查AC點是否滿足前需要先確定前端頁面與UI設(shè)計一致甚侣，異常情況處理符合系統(tǒng)規(guī)約等明吩。
? ? ? ?實戰(zhàn)中，我們需要先定義所有人理解一致的”完成”定義殷费，再建立良好的溝通氛圍印荔，促進整個團隊對需求的思考，而不是單向的接收需求详羡。迭代結(jié)束時仍律，再由PO最終決定故事是否完成。
最后的最后
? ? 敏捷強調(diào)是溝通实柠，合作水泉，User story從編寫開始就需要嚴格遵守INVEST原則，范圍不能模糊不清窒盐、漫無邊際草则，PO作為User story的唯一負責(zé)人需要在AC點中說明關(guān)鍵要素，幫助團隊正確理解需求蟹漓。
