我來到凱捷已有一年時間,結識了許多可愛的伙伴...期間作為開發(fā)者參與了兩個敏捷項目,過程中有可貴之處,也有沒做好的地方, 所以我很自然的經(jīng)歷了一個反思過程. 我想把它們拿出來說一說——當身邊的隊友遇到困難,你總是急迫地說出自己的想法,哪怕它未必成熟合理.

本文主要討論的是我在項目中作為開發(fā)者實際經(jīng)歷的情況,但反思的過程是從各方角度出發(fā)的,主要是聊一聊我參與的敏捷項目中的用戶故事在面對一些復雜需求時出現(xiàn)的問題,問題的根本所在,我們又該做些什么.

在甲項目中,我們要開發(fā)的是產(chǎn)品生命周期管理系統(tǒng),系統(tǒng)一部分需求相當復雜.我們使用用戶故事卡片管理需求,通常的做法是在卡片中粘貼原型圖,加入一些需求描述以及AC.簡單的增刪改查通過這些卡片得到了良好的表達,然而面對復雜的需求時,這些卡片中總是缺失了一些致命的信息: 角色, 業(yè)務規(guī)則, 需求對于客戶的原始價值等... 這些隱含的信息隨著開發(fā)過程逐漸顯露,不停影響開發(fā)的進行,甚至產(chǎn)生推倒重做的情況. 我們用這些卡片追蹤了需求的生命周期,但卻沒能清楚地表達需求.

用戶故事與上下文

當我們用系統(tǒng)思維來理解,世界是上圖的樣子,由系統(tǒng)及其子系統(tǒng)構成.每一個系統(tǒng)都有自己的上下文, 系統(tǒng)A,B的上下文限制著C,但當我們進入C的內(nèi)部,又更注重C的上下文,而不至于迷失在龐大的B,A中.我認為以系統(tǒng)思維來理解、記錄、管理需求,明確各部分的上下文內(nèi)容,是我們完全沒有認識到的,用戶故事的本質(zhì)之一, 也是面對龐大需求時團隊內(nèi)統(tǒng)一需求理解的關鍵.

通常描述一個卡片的最佳形式為: 作為[角色], 需要進行[操作], 因為[價值]. 其實這種形式,目的就是要清楚表達卡片的上下文環(huán)境. 有了清楚的上下文,才能清晰認識一張卡片,對其業(yè)務規(guī)則進行足夠的思考,不至于出現(xiàn)上文中提到的隱含信息在實現(xiàn)階段不斷浮現(xiàn)出來的情況.在眾多被丟失的信息中,原始價值是概率最高的,然而我們要交付的即是價值,缺失價值信息很容易導致團隊對需求的誤解!

沒有層級的上下文是很難被理解的.在甲項目中我們的每張需求卡片都包含一個頁面的原型和描述.對于一個復雜的需求,信息量非常大,包括各種角色,復雜的業(yè)務規(guī)則與邏輯等.我從來不能通過這樣一張卡片來認清其上下文.要想清晰表達上下文,我們需要明白:

1. 作為需求的最小單元,用戶故事卡片的上下文應該是簡單明確的.比如應該只包含一個角色.

2. 有人會說有些卡片的需求本身就是不簡單的,那是因為他們忽略了上下文是有層級的,沒有層級結構是絕對無法管理好上下文信息的.在上圖中,如果系統(tǒng)C是用戶故事卡片,那系統(tǒng)B即是Epic.我們應當使用這些概念表達需求上下文的層級結構,從而有效管理需求的復雜度.

一個項目的全局上下文是非常重要的.上圖中沒了A的限制,我們便無法認清B,C.甲項目出現(xiàn)的一些需求誤解中,一部分便是由于團隊沒有對整體上下文完成統(tǒng)一: 有的時候團隊成員對一些領域術語各有自己的見解,有的時候把某一個卡片放到整個系統(tǒng)中到底是為什么困惑著團隊成員.團隊非常需要對整個系統(tǒng)有統(tǒng)一的認知,即使我們面臨用戶需求不確定的情況,也應該力求達成統(tǒng)一的認知(一種假設的認知也遠遠好過沒有).因為當團隊沒有對整個系統(tǒng)統(tǒng)一認知,那么為了理解各個卡片,團隊成員一定對整體上下文做出了某種假設(常常是無意識的).這種未統(tǒng)一的假設是致命的,在如領域驅(qū)動設計以及事件風暴等一些著作中,作者都在強調(diào)統(tǒng)一領域語言對于理解全局上下文的重要性.

我們應該為每個項目建立領域術語表,包括領域的各種角色之類的領域名詞等,它是全局上下文非常重要的一部分.? 同時用戶的整體旅程也將幫助團隊統(tǒng)一對系統(tǒng)價值的認知,它也是全局上下文中非常重要的一部分. 使用用戶故事地圖可以清晰表達這種旅程.

從理解價值到交付價值,我們需要設計的力量

在業(yè)內(nèi)常常有這樣的情況: 企業(yè)在快速持續(xù)向客戶交付價值,響應變化.然而實際情況正如那張漫畫,不停工作的印鈔機內(nèi)部,其實是不停工作的人類.勞動力的有限性沒有寫在敏捷價值觀中,但我們?nèi)プ粉櫭艚莘椒ǖ臍v史便會發(fā)現(xiàn),正因為西方工程行業(yè)將勞動力的有限性作為基本原則,才促使科學、工程水平的不斷提升,敏捷方法也正由此而生.那么為什么目前業(yè)內(nèi)響應變化的常用辦法,是不斷的加班呢?這也是一個值得反思的問題.

我發(fā)現(xiàn)我們在實現(xiàn)需求(主要是復雜需求)之前,缺少了極其重要的一步: 建模設計. 為了應對逐漸復雜的系統(tǒng),對象建模范式取代了過程范式, 為了實現(xiàn)對象建模, Java語言代替了C語言. 而如今我們使用Java語言構建復雜企業(yè)應用,卻在以過程范式來進行邏輯展開... 我們用一個個過程開發(fā)極其復雜的業(yè)務邏輯,當需求變化, 這些代碼難以修改,于是我們鼓勵重構.在重構時,有經(jīng)驗的同事向比較新的同事傳授思想:“把通用的部分抽取成一個方法”...? 我們一直在使用過程思維,然而過程思維無法面對復雜系統(tǒng),要響應變化,我們必須要使用對象建模,必須要具備對象建模能力.這不是新生的方法,而是長期的取巧造成的債務.

那么對象模型到底是如何從容應對變化,與領域知識共同進化的?在甲項目和乙項目中,我都在對復雜業(yè)務進行對象建模實踐,這里我舉出在乙項目中的一個需求作為例子: 項目需要與某外部系統(tǒng)的接口進行數(shù)據(jù)同步(要求通過rest 接口完成),但是面臨著需要同步的次數(shù)和時長不固定(達到過數(shù)個小時之久),數(shù)據(jù)量不固定(單次HTTP返回數(shù)據(jù)達到過幾百Mb之多),數(shù)據(jù)的過濾過程不固定(一條數(shù)據(jù)只有一部分字段是有意義需要保留的)等問題. 轉(zhuǎn)手過幾人的代碼邏輯都無法應對這些變化, 因為這些代碼都在使用過程思維. 在足夠了解需求的確定部分及不確定部分后,我對此作出了如下圖的對象建模:

上圖的各組件均使用Java語言提供的對象建模能力建造.Spider負責與外部接口進行交互,應對請求次數(shù)、時長和數(shù)據(jù)量的變化,可以實現(xiàn)單線程或多線程的Spider. Spider抓到的數(shù)據(jù)總是流經(jīng)DataBus,在這里,可以通過向DataBus添加不同的Plugin應對變化的數(shù)據(jù)過濾過程. 流經(jīng)DataBus后數(shù)據(jù)暫存入DataBuffer中,當數(shù)據(jù)量較少,DataBuffer可以直接在內(nèi)存中;當數(shù)據(jù)量很大,DataBuffer可以是Redis;當有核對需要,DataBuffer也可以是Excel.抓取過程完成后Spider遵循事件模型,發(fā)起完成通知,此時系統(tǒng)經(jīng)由類似的DataBus從DataBuffer不斷取出數(shù)據(jù)并存入DB.這樣遵守基本的設計原則,加上一些最佳設計實踐以及從各種框架學到的設計經(jīng)驗,我就建造了這個模型,此模型跟隨著需求共同變化,快速響應需求并積累領域經(jīng)驗.

我們常在面試中談論技術,框架的原理,但結合目前的形勢,我們最迫切需要的不是這些原理,而是它們是如何被設計出來的. 很多同行對框架原理,技術方案夸夸其談,卻連幾十年前已經(jīng)成為基礎能力的對象建模能力都不具備.當然這不是同行的錯誤,我們能力的落后有多嚴重,這需要具備更高視角的角色去思考.

關于對象建模能力的構建,我想我們的架構師應該具備足夠的對象建模能力, 并傳遞給開發(fā)者. 建模應該在實現(xiàn)之前進行,如果我們想開始做這件事,我想一開始應該是架構師來負責的,隨著能力建設的深入,開發(fā)人員將可以拿出建模結果供團隊評審.

戰(zhàn)略意義

一直以來我們在軟件領域解決問題最重要的方式都是透支勞動.回首過往,這為我們帶來了長足的發(fā)展.然而禍根也由此埋下: 我們使用Java語言,卻千篇一律地進行過程式開發(fā),這樣的問題產(chǎn)生的根源,便是我們不具備更新思維和能力的基礎條件——我們有更便捷的方式,又何必自討苦吃呢?

我們都知道,這種便捷的辦法只能使用一段時間,只是潛意識覺得它會很久罷了.而展望未來我認為這一段時間很快將迎來它的終結. 可悲的是很多管理者從未思考過此事,透支勞動解決問題是他們的致勝真理.這讓人不敢去想拐點到來的景象.

人間正道是滄桑, 透支勞動不是最好的辦法, 能力建設才是未來的鑰匙. 若我們在拐點到來之前忍受陣痛,積極進行能力建設, 如對象建模之類的能力,都將成為我們的核心競爭力,幫助我們應對困難,實現(xiàn)理想.

同時作為咨詢公司,我們常常面對一些同事是初次接觸某個業(yè)務的情況.建造準確深刻反映業(yè)務的領域模型,并長期將其積累到公司的知識庫,可以使我們的整個敏捷團隊從中獲益,甚至幫助客戶衍生新的價值.

一年來,我看到的凱捷是一家非常優(yōu)秀的公司,對過去一年的相處有很多地方需要感謝.然而保持進步是不變的真理,直言我所見到的問題,這是我最大的真誠,也是對你包容度的信任.將這真誠與肺腑獻給朋友,愿我們攜手走過更多的路.