講一個(gè)小王跟小李的故事负甸，小李是程序員流强，小王是產(chǎn)品經(jīng)理。當(dāng)小李接到一個(gè)新的需求呻待，讓他開發(fā)一個(gè)單點(diǎn)登錄打月。經(jīng)過幾天的奮戰(zhàn)，他順著寫完代碼蚕捉，這時(shí)產(chǎn)品經(jīng)理小王路過他身邊奏篙，順便問了他一下。
小王：單點(diǎn)登錄做的咋樣了迫淹？
小李：做完了我給你演示一下秘通。
小李演示了一遍自己的功能，小王看上去很滿意敛熬。
小王：不錯(cuò)肺稀，不過怎么沒有支持驗(yàn)證碼？
小李：為什么要做這個(gè)应民？
小王：這不就是登陸了一部分嗎话原？
小李：哪里規(guī)定要做驗(yàn)證碼了？
小王：現(xiàn)在登錄哪有不用驗(yàn)證碼的诲锹？
雙方的對(duì)話都充滿了火藥味繁仁，有可能控制不好情緒，那么就會(huì)一觸即發(fā)归园。在工作中你是否也會(huì)遇到過這樣的情況黄虱？他倆為什么會(huì)有這么大的分歧？其中一個(gè)重要的原因就是開始這個(gè)需求之前沒有把需求給定義好庸诱。
這在軟件開發(fā)的過程中是一個(gè)很重要的問題悬钳。我們一般如何去定義需求？有些需求你直接聽到還好偶翅，但是有些需求是他人轉(zhuǎn)述的默勾，可能就會(huì)存在一些偏差，因?yàn)樾畔⒃趥鬟f的時(shí)候聚谁，它是呈衰減的母剥。你不可能把你理解的信息的100%傳遞給另一個(gè)人，在傳遞的過程中它是存在衰減的。
如何處理這樣的問題环疼，一般像產(chǎn)品經(jīng)理就會(huì)有比較詳細(xì)的需求文檔习霹，具體到某一需求都會(huì)羅列出來相關(guān)功能列表。用功能列表式的需求描述方式炫隶，將一個(gè)完整的需求打成一個(gè)個(gè)碎片淋叶，按照類似于清單的方式煞檩，一條一條列出來。這樣開發(fā)人員再去開發(fā)的時(shí)候栅贴，就知道自己有到底有沒有把它給弄完。只有當(dāng)所有的功能完成后檐薯，然后將它對(duì)接在一起，才算是“破鏡重圓”的時(shí)刻坛缕。
那么，我們一般如何去描述一個(gè)新的描述需求赚楚。通常我們會(huì)“用戶故事”方式去闡述陶衅。簡單的說就是站在用戶的角度，你提供一個(gè)什么樣的功能膨俐？他要經(jīng)過什么樣的路徑勇皇？達(dá)到怎樣的結(jié)果焚刺，這就是一個(gè)完整需求的場景。
用戶故事大致分為四個(gè)部分：
第一個(gè)是標(biāo)題乳愉，這個(gè)需求是什么？就比如說注冊(cè)用戶使用用戶名和密碼登錄蔓姚。
第二個(gè)是概述，概述的格式可以按照：你作為一個(gè)什么樣的角色坡脐？做的事情要達(dá)到怎樣的效果泄私？比如說作為一個(gè)注冊(cè)用戶晌端，我想通過用戶和密碼登錄捅暴，然后才可以使用注冊(cè)用戶的使用的服務(wù)咧纠，
第三個(gè)是詳述，就是把一些操作流程和用戶界面的信息展示出來漆羔，比如說我登錄成功之后跳到什么頁面，登陸失敗又是怎樣的效果钧椰？這些都是要描述出來。
第四個(gè)是驗(yàn)收標(biāo)準(zhǔn)嫡霞，它一般是一個(gè)正常的流程，同時(shí)我們還需要考慮一些異常的流程诊沪，這往往是我們比較欠缺的养筒。
怎樣才算做完了需求端姚？驗(yàn)收標(biāo)準(zhǔn)說了算。驗(yàn)收標(biāo)準(zhǔn)會(huì)給出這個(gè)需求的測試用例渐裸，他會(huì)保證開發(fā)人員完成需求的最基本的質(zhì)量。這就是我們所說的行為驅(qū)動(dòng)開發(fā)昏鹃，可以按照這樣的標(biāo)準(zhǔn)去給出測試用例。
實(shí)際工作中許多產(chǎn)品經(jīng)理的需求洞渤，把需求交給開發(fā)人員之前阅嘶，很多細(xì)節(jié)沒有想清楚讯柔，那種功能列表式的需求常常只包含了正常路徑，而缺失的細(xì)節(jié)就是在后續(xù)過程中有開發(fā)人員補(bǔ)的护昧。用戶故事就是一種固定的格式，讓他們把這些應(yīng)該想清楚的問題想清楚惋耙。所以慈格，如果你的團(tuán)隊(duì)是采用用戶故事的格式進(jìn)行需求描述，固然如果不能在功能儀表中補(bǔ)充驗(yàn)收標(biāo)準(zhǔn)浴捆，也會(huì)極大地程度改善雙方協(xié)作的效率。
至此选泻，今天要聊的就這些，如果你只能記住一件事的話美莫，那么請(qǐng)記住：在做任何需求和任務(wù)之前先定義好驗(yàn)收標(biāo)準(zhǔn)厢呵。
