最近在一個業(yè)務(wù)邏輯很復雜的項目上工作宫纬，這個項目第一期大概做了半年時間，過程中遇到了很多問題锻狗，印象最深刻的就是大部分的故事卡(小feature)經(jīng)常在快做完的時候楷掉，developer才發(fā)現(xiàn)有一些原來沒有意識到的一些業(yè)務(wù)場景。
分析了一下原因:
1）我們的BA(Business Analyst)能力不達標：故事卡里面的acceptance criteria不夠詳盡烁兰，沒有深入思考所有相關(guān)的user journey
2）在這樣的故事卡的背景下耐亏，作為developer，如果你沒有事先思考整個user journey的意識沪斟，那么就會發(fā)現(xiàn)好多問題都是當你接觸到了你才會去思考广辰，結(jié)果卻發(fā)現(xiàn)是一個大坑，需要各種角色來討論主之，然后才能繼續(xù)做择吊。
3）如果developer在做卡時候沒有思考清楚各種類型的業(yè)務(wù)場景，只是完全follow 不全面的AC來做的話槽奕，會產(chǎn)生很多bug几睛。如果這些bug僅僅出現(xiàn)在測試人員測試這張卡的情況下，問題還小點粤攒，可以回爐重做所森。但常常測試人員也只會follow AC 來去測試，這樣這張卡就會被當成已經(jīng)做完夯接，merge回你的主分支焕济。這樣一來，這些bug就會在更晚的時間暴露出來（真實數(shù)據(jù)測試情況下）盔几，你又不得不創(chuàng)建新的故事卡去track晴弃，嚴重的話，甚至可能影響到整個項目的發(fā)布逊拍。
這樣導致的結(jié)果是：一張故事卡從開始開發(fā)到完成花費的時間是原來估計的兩倍上鞠，整個team交付效率極低，組內(nèi)成員也會很suffer芯丧。
在這種情況下芍阎，作為開發(fā)人員，我們所能做的就是在我們這一環(huán)節(jié)盡可能的去解決這樣的問題缨恒。這個時候最有效的就是：將故事卡分解成一個一個小任務(wù)了谴咸。
最早接觸到這個概念是在學習TDD的時候度硝，當你想實現(xiàn)一個功能時，你可以先把它拆成一個個更小的任務(wù)寿冕。
舉個例子：除法運算
你的tasks可以為：（1）除數(shù)不為0，取整 （2）除數(shù)為0椒袍，打印錯誤日志
只要你的功能滿足了這兩個task驼唱，就算是完成。
同樣的驹暑，這種概念也可以應(yīng)用故事卡上玫恳，步驟為
（1）列出所有tasks，可以由易到難优俘，這樣能快速實現(xiàn)京办，讓人有成就感：
? ? ? ? 這個過程能幫你理解故事卡的整個業(yè)務(wù)流程，找出隱藏的業(yè)務(wù)場景帆焕，缺失的需要業(yè)務(wù)人員提供的信息惭婿。同時，developer也會去思考大概要怎么實現(xiàn)這個功能叶雹，能快速幫你理清實現(xiàn)思路财饥。這種類型的task更像是checkpoint。
? ? ? ?關(guān)于如何分解task折晦，我一般會借助金字塔原理按層次結(jié)構(gòu)來分钥星。在故事卡中，通過user journey分應(yīng)該是最簡單直接的了满着。
（2）如果功能性比較復雜的話谦炒，可以把每個task再次拆細，拆成功能性的task：
? ? ? ?一般這種純功能性的task不用拆的過細风喇，記錄重要的點即可
（3）重構(gòu)：第一次列出的tasks不一定全面宁改，邊做邊補充邊改善
當業(yè)務(wù)場景過多的時候，第一步比重會過大响驴。但當故事卡偏功能性時透且，可以省略第一步，直接開始第二步豁鲤，同時把一些簡單的UI change作為task秽誊。
其實，這種方法就是把你從開始做這張故事卡到做完這個過程的思維模式提前總結(jié)琳骡，讓你能更早的發(fā)現(xiàn)問題锅论。無論是開發(fā)，BA還是測試都是很適用的楣号。和生活中的TODOLIST理念一致最易。
最后附上一張用戶行為表展示功能的task圖：
