試想，項目已啟動，團隊卻并不了解整個系統(tǒng)、功能的目標(biāo)和范圍，未對系統(tǒng)、功能的需求達成共識，那么項目開發(fā)的方向隨著時間的推移而逐漸偏離。明明需求要的是一個蘋果，最終卻做了個梨出來。要讓團隊達成共識，就離不開團隊各個角色的溝通與協(xié)作。
經(jīng)常聽到同行朋友、軟件工程師吐槽需求又變了，在地鐵里面也常聽到程序員們聊天吐槽說需求的變動。是的，現(xiàn)實中客戶的需求并不是一成不變的，客戶的需求也不是一開始就生長在那里，就好像在茫茫森林中的一棵樹木，等待我們?nèi)ァ鞍l(fā)現(xiàn)”它。
相反，客戶需求最開始可能只是一個idea，一個想法，它就比好一粒種子，需要土壤、陽光與水分，在人們的精心呵護與培植下才能茁壯成長。因此，我們無法“發(fā)現(xiàn)”需求，而是要和客戶一起“培育”需求，并在這個培育過程中逐漸成熟。
今天簡單聊聊敏捷開發(fā)也是現(xiàn)在企業(yè)內(nèi)用得比較多的研發(fā)方式，思想強調(diào)個體和團隊的協(xié)作與溝通，強調(diào)快速反饋與及時響應(yīng)。
盲人摸象，由于每個人獲得的信息不同，知識背景不同，又因為角色不同因而導(dǎo)致設(shè)想的上下文也不相同，諸多的不同使得我們在對話交流中好像被蒙了雙眼的盲人，我們共同捕捉的需求就好似一頭大象，各自只獲得局部的知識，卻自以為掌控了全局?；蛟S有人會認(rèn)為客戶提出的需求就應(yīng)該是全部，我們只需理解客戶的需求，然后積極響應(yīng)這些需求即可。
比如，我們與客戶聊需求的時候并不是一遍就能聊清楚、聊明白。需求方想要的結(jié)果與我們理解的可能不一致，因此，在“培育”需求的過程中需要雙向的溝通、反饋。如果沒有正確的溝通與交流方式，團隊達成的“需求一致”不過是一種假象。比如，我們最近在做的“裂變活動”，與需求方溝通了一天后的結(jié)果形成腦圖，下午團隊內(nèi)部溝通，團隊成員就提出了不一樣的問題與疑問。然后結(jié)合這些問題再次與需求方溝通確認(rèn)，然后再反饋到研發(fā)團隊。通過這樣反復(fù)的溝通與反饋，將需求達成一致。
在《用戶故事地圖》中作者給出了一副漫畫來描述共識達成的問題。
這幅漫畫形象地表現(xiàn)了如何通過可視化的交流形式逐漸在多個角色之間達成共識的過程。
敏捷開發(fā)思想強調(diào)個體和團隊的協(xié)作與溝通，強調(diào)快速反饋與及時響應(yīng)。我們?nèi)绾瓮ㄟ^敏捷思想來減少目標(biāo)共識不一致問題呢？在游戲規(guī)則里，主要有計劃會議、例行會議、評審會議和回顧會議四項主要活動。
計劃會議，計劃會議標(biāo)志著開始，所有利益相關(guān)成員都需要參加，目的是和利益相關(guān)人的溝通，來確定系統(tǒng)的業(yè)務(wù)與愿景。另外可通過分析、評估已有的產(chǎn)品清單或者功能，能否滿足客戶的需求。比如，我們最近做裂變分享的活動，通過梳理當(dāng)前產(chǎn)品的功能板塊，將裂變流程拆細(xì)后，發(fā)現(xiàn)已有的領(lǐng)取優(yōu)惠券、核銷、查看等一系列功能已經(jīng)滿足，通過將優(yōu)惠券作為原子服務(wù)，只需要滿足裂變規(guī)則即可。
在此次計劃會議中需要確定最有價值的目標(biāo)，或者緊急重要的工作事項，將功能進行拆分到人并以人為單位列出來計劃表，從而形成整體計劃表。
例行會議，敏捷思想則要求大家每天站著開，也就是晨會。這個會議的主要目的是明確目標(biāo)，也就是我現(xiàn)在在哪里，我們將要去哪里？會議中主要回顧昨天，做了什么？今天，要做什么？也就是回顧昨天，與今日目標(biāo)。站立會中可以很清晰的知道團隊的進展，同時知曉研發(fā)團隊的理解是否存在偏差可及時的進行調(diào)整。
評審會議，我們沒有實際上的評審會議，我們產(chǎn)品功能首先是程序員自測，很多人說自測會降低研發(fā)的時間，個人認(rèn)為研發(fā)開發(fā)完后即可對其進行測試，或者產(chǎn)品、測試等角色立即進行測試，這樣軟件開發(fā)人員便能夠快速響應(yīng)，大大的降低修改Bug 的成本。因為無數(shù)研究與實踐證明了，修改Bug 的成本會隨著時間的推移而增加。
因此，我們是程序員自測，因為我們沒測試，然后再由產(chǎn)品進行測試查看，通過在線文檔記錄反饋到研發(fā)進行調(diào)整。
回顧會議，我們將該會議作為周例會進行放在了周五，回顧本周工作完成的情況，總結(jié)工作中的經(jīng)驗與教訓(xùn)。會議的核心的總結(jié)，總結(jié)錯誤并總結(jié)解決方案，避免再相同的業(yè)務(wù)邏輯上犯相同的錯誤。
自我管理，敏捷思想并沒有特定的工程實踐慣例，團隊成員通過自我管理朝著產(chǎn)品的研發(fā)進展方向規(guī)劃自己的計劃、日計劃，并主動完成工作。敏捷思想強調(diào)個體和團隊的協(xié)作與溝通，強調(diào)快速反饋與及時響應(yīng)。
很多人會陷入快速的誤區(qū)，以快速就等于“敏捷”，實則不是。上文提到的程序員吐槽需求又變了的問題，大多數(shù)是想到哪里設(shè)計哪里，不和客戶保持溝通，只要客戶說的不論成熟與不成熟都扔給軟件開發(fā)團隊。這就會造成產(chǎn)品、功能三天一小改、一星期一大改的局面，導(dǎo)致程序員們吐槽并且敏捷團隊也不知道所措，剛做完又改。
因此，完善業(yè)務(wù)需求設(shè)計環(huán)節(jié)很重要，也就是第一環(huán)節(jié)計劃會議，計劃會議中要明確目標(biāo)與落地執(zhí)行計劃，成員嚴(yán)格按照此計劃進行，中間有問題及時反饋與溝通。
總結(jié)，敏捷思想強調(diào)個體和團隊的協(xié)作與溝通，強調(diào)快速反饋與及時響應(yīng)。只有頻繁的溝通，才能就業(yè)務(wù)需求達成整個團隊的共識。團隊良好的協(xié)作，才能有助于大家建立統(tǒng)一的語言，實現(xiàn)統(tǒng)一目標(biāo)。