上篇說了流氓碼農(nóng)們的一些典型語錄，來彰顯工匠的一些價值觀：
- 把測試當(dāng)作開發(fā)的一部分。
- 事情要么“做完”，要么“沒做完”，沒有“做完了，但是”。
- Test First，往往會告訴QA哪里可能有bug，而不總是被QA告知。
- 把測試當(dāng)作一種設(shè)計過程
然而，價值觀或者文化不是關(guān)于如何說的，是關(guān)于如何做的。作為一個管理者或者Scrum Master，有什么實踐可以讓團(tuán)隊從流氓開始走向工匠呢？
下面結(jié)合本人經(jīng)歷，按順序推薦4個：Event Storming，開發(fā)拆解Story，Example Mapping， Test Case Map Review。
DDD之Event Storming
有個常見的荒唐事實：開發(fā)團(tuán)隊作為解題者，往往不很清楚問題是什么。他們只負(fù)責(zé)交付產(chǎn)品經(jīng)理提的“需求”，而不理解需求背后真正的業(yè)務(wù)問題，而那，才是我們要解的題。
讓團(tuán)隊理解真正的業(yè)務(wù)，不是一件容易的事情。事實上，各種陡峭的“群體學(xué)習(xí)”曲線，總是軟件開發(fā)面臨的最大的困難。
軟件研發(fā)是個學(xué)習(xí)的旅程，代碼只是副產(chǎn)品。by 記不得名字的某外國人。
Event Storming 最大的作用之一就是加速團(tuán)隊對業(yè)務(wù)的群體學(xué)習(xí)，建議在一個 Epic 或者 Feature 啟動之前進(jìn)行。會議的產(chǎn)出對業(yè)務(wù)問題的一致性理解，和一個共創(chuàng)的 Domain Model。
讓開發(fā)團(tuán)隊拆 Story
很多團(tuán)隊是產(chǎn)品經(jīng)理（PO）來拆 Story 的，這很不高效。
我們都知道計算機(jī)算法里的“分而治之”： 解題的關(guān)鍵手法是分解問題。所以開發(fā)團(tuán)隊作為解題人，把大的 Story 分解成小的 Story，再自然不過了吧？
另外一個重要的目的是，培養(yǎng)團(tuán)隊“拆”的習(xí)慣，工匠級的程序員，無時無刻不在“拆”，拆需求，拆任務(wù)，拆類，拆函數(shù)，拆 test case。這可謂第一心法。
哪有什么天才，我只是把別人寫代碼的時間都用在拆解上了。by 不愿透露姓名的工匠程序員周迅。
BDD 之 Example Mapping
這個是拆 Story 的延續(xù)，每個 Story 都有一些“業(yè)務(wù)規(guī)則”，這些規(guī)則在 PO 傳遞給團(tuán)隊的過程中可能就遺漏或歪曲了，所以讓開發(fā)團(tuán)隊針對每個核心的業(yè)務(wù)規(guī)則，舉些例子出來。
這樣可以進(jìn)一步澄清模棱兩可的需求，確保開發(fā)對需求的理解是準(zhǔn)確的。
Test case map review
拆 Story 和 Example Mapping 一般發(fā)生在 Backlog Refinement Meeting上。Story 進(jìn)入開發(fā)后，QA 繼續(xù)精化那些 Example。
注意這里不是設(shè)計完整的 Test Case，而是
- 用腦圖的方式列出所有的場景。
- 跟開發(fā)去 Review，大家商量好，這些場景哪些用單元測試覆蓋，哪些用集成測試覆蓋，哪些用手工測試。
上圖是我司一個例子。這就是 Test First，本質(zhì)就是以終為始。
總結(jié)
工匠級的團(tuán)隊首先有好的工程實踐，所謂工程，就是做事的方式方法。
我們是解題人，所以我們的工程實踐是：
- 理解問題 （Event Storming）
- 分解問題 （開發(fā)拆解 Story）
- 不斷確定對問題的理解 （Example Mapping）
- 不斷確定對問題的衡量 （Test Case Review）
代碼只是這些工程實踐的副產(chǎn)品。
后記
開頭說過，這是管理者或者 Scrum Master 可以去主導(dǎo)的實踐，它們都是非技術(shù)實踐，也都是團(tuán)隊實踐，不是個人實踐。它們背后共同的原則是：反分工，反傳遞。共識是共創(chuàng)出來的，不是傳遞來的。
業(yè)務(wù)把問題“傳遞”給PO，PO把需求“傳遞”給開發(fā)，開發(fā)把代碼“傳遞”給QA。這些都是敏捷的敵人，你的團(tuán)隊還有哪些“傳遞”？
備注
一種精簡版的 Event Storming 玩法：
- 按時間先后，團(tuán)隊腦暴出重要的 Domain Event。
- 對每個 Domain Event， 腦暴它是怎么發(fā)生的？可能是誰需要做點事情( Command)，可能是另一個 Event 直接觸發(fā)，也可能是 Time。
- 從這些 Event 和 Command 中識別出業(yè)務(wù)對象（Business Object）。
- 把 Business Object 歸類，識別出 Aggregate （和Aggregate Root）。
- 把 Aggregate 歸類，識別出 Sub-Domain，它基本上就是一個 Bounded Context，很可能對應(yīng)一個 Micro-Service。
