中式軟件開發(fā)現(xiàn)狀之我見-這就是敏捷？
歷史的車輪滾滾向前，當代互聯(lián)網(wǎng)也早已過了而立之年。
各種優(yōu)秀的理念，各種優(yōu)秀的實踐，提出，興起，推廣，衰落。你方唱罷我登場。
而這其中，最為人津津樂道的當屬--敏捷開發(fā)。
嘮一嘮敏捷
2001年，當時軟件領(lǐng)域的多位大佬在一起開了個會，大家聊得很開心，各種理念碰撞交匯，意趣相投，相見恨晚。
于是這幾位好朋友在一起把討論的結(jié)果總結(jié)為一份“敏捷宣言”。寥寥數(shù)語，包含4條價值觀和12條原則，奠定了敏捷開發(fā)的基調(diào)。
12條原則
我們遵循以下原則：
01.我們最重要的目標，是通過持續(xù)不斷地及早交付有價值的軟件使客戶滿意。
02.欣然面對需求變化，即使在開發(fā)后期也一樣。為了客戶的競爭優(yōu)勢，敏捷過程掌控變化。
03.經(jīng)常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期。
04.業(yè)務(wù)人員和開發(fā)人員必須相互合作，項目中的每一天都不例外。
05.激發(fā)個體的斗志，以他們?yōu)楹诵拇罱椖俊Ｌ峁┧璧沫h(huán)境和支援，輔以信任，從而達成目標。
06.不論團隊內(nèi)外，傳遞信息效果最好效率也最高的方式是面對面的交談。
07.可工作的軟件是進度的首要度量標準。
08.敏捷過程倡導可持續(xù)開發(fā)。責任人、開發(fā)人員和用戶要能夠共同維持其步調(diào)穩(wěn)定延續(xù)。
09.堅持不懈地追求技術(shù)卓越和良好設(shè)計，敏捷能力由此增強。
10.以簡潔為本，它是極力減少不必要工作量的藝術(shù)。
11.最好的架構(gòu)、需求和設(shè)計出自自組織團隊。
12.團隊定期地反思如何能提高成效，并依此調(diào)整自身的舉止表現(xiàn)。
是的，我承認貼上宣言的內(nèi)容是為了占篇幅的，你可以直接跳過，這樣我的歉意也會少一些。
但是我仍舊想讓你看一下它的四條價值觀的內(nèi)容。
4條價值觀
我們一直在實踐中探尋更好的軟件開發(fā)方法，身體力行的同時也幫助他人。由此我們建立了如下價值觀：
- 個體和互動高于流程和工具
- 工作的軟件高于詳盡的文檔
- 客戶合作高于合同談判
- 響應(yīng)變化高于遵循計劃
也就是說，盡管右項有一定的價值，我們更重視左項的價值。
寥寥數(shù)語，道出了敏捷的核心價值。
流程和工具固然重要，但作為工具而言他們的目的在于「調(diào)動個體，提升成員間的互動」； 文檔詳盡對加深理解和解釋清楚問題而言的確意義非凡，但是「能夠交付可工作的軟件」才是更高目的； 開會，溝通，交流，是弄明白需求的重要步驟，這其中不免發(fā)生博弈，大概率會出現(xiàn)觀點的交鋒，刁難，疑問，甚至情緒化。但是不同角色間的合作更為重要，圍繞著解決問題本身觸發(fā)的交流才是更為有價值的交流，而這種就事論事、「善意的交流」也體現(xiàn)了團隊價值和尊重； 只要有需求，先聊排期，先列計劃。這是避免犯錯、把控節(jié)奏的有效措施，但是變化會導致計劃調(diào)整，變化會使得計劃失效，擁抱變化不僅僅是裁員時候才反復強調(diào)的口號，更應(yīng)當在平時的工作中體現(xiàn)出來，它不是一種“恐嚇”，「它應(yīng)該是一種人文關(guān)懷」。
那么中式敏捷團隊的特點是什么？
中式軟件開發(fā)團隊，尤其是互聯(lián)網(wǎng)開發(fā)團隊，喜歡吸收年輕血液，樂于引入先進的經(jīng)驗和實踐。這是好事。
于是我們看到，看板用起來了，泳道列出來了，迭代跑起來了，站會也開起來了。
工作開始，第一件事，每日站會，大家機械式的發(fā)言，我今天要做ABCD這幾件事，如果精力足夠，我將繼續(xù)做EFGH這幾件事；
進入工作狀態(tài)，又一個需求過來了，哦，天哪，這是啥，沒聽過啊。看看多會兒上線，wow，產(chǎn)品說要倒排，明天就評審，今天就得給排期。
只能硬著頭皮用經(jīng)驗去估計了，沒辦法，咱也沒參與需求討論，咱也沒參與預評審，但是我們是一個敏捷的團隊。敏捷的團隊從來都是扁平化的，每個人都是資源池中的一個可自由調(diào)度的資源，輪到你做就得你做，當仁不讓。
一天時間了解下需求背景，產(chǎn)品說發(fā)布時間是兩周后，那就是說還有10個人日的時間，開發(fā)3天，單側(cè)1.5天，聯(lián)調(diào)1天，測試3天，預發(fā)1.5天。
先這么排吧，你問為啥單測要1.5天？我只能說這叫經(jīng)驗。
我們采用了業(yè)界領(lǐng)先的TDD模式，要編寫完善的測試用例，指令覆蓋率要達到90%以上，分支覆蓋率要達到70%以上。
?這都是套話，實際上是因為你不得不寫這么多用例，否則代碼提交都提交不上去，流水線直接卡住你。到時候耽誤了代碼合并，影響提測，就等著復盤吧。關(guān)于復盤，也是一個有意思的事情，我們下一篇文章再說。
?
吭哧吭哧寫了一通設(shè)計文檔，編碼，單測寫了一通，又自然地迎來了敏捷開發(fā)團隊的每日必修課：晚會站會。
此時，看板出場了。
看板里，井井有條地羅列著A B C D E ... 等一堆事項，每個事項下又有著1 2 3 4 5...個任務(wù)。每個開發(fā)像勤勞的螞蟻一樣，將任務(wù)從一個泳道，搬到了另一個泳道，并戰(zhàn)戰(zhàn)兢兢地在任務(wù)進度上小心翼翼地增加了若干百分比。
會議上，所有參與者挨個介紹著自己所負責任務(wù)的進度，嗯，一片和諧。
看啊，多么精干的敏捷團隊，多么高效的工作方式。
?聽啊，這件事情和我有多少關(guān)系？這個百分比有多少可信度？哎呀，又有一個會要參加了 得嘞，飯點兒快到了。
?
我們不禁提問，這樣的節(jié)奏是敏捷的么？這樣的team是敏捷的么？
相信你自有答案在心中。
用了看板/jira/站會就是敏捷了？
這里其實是一個哲學問題，神與形的邊界在哪里。
哲學里有一個“忒休斯之船”的概念，說的是有一艘叫做“忒休斯”的木船，工人們每天更換一個船上的零件，日復一日，直到有一日，船上最后一個零件被更換掉了。
那么問題是，此時這艘船，還是忒休斯嗎？
我們說，在水手的心中，它還是忒休斯。
人有其魂，船有其神。
這艘船的信念和意志不滅，于是在水手的心中，忒休斯永存。
將目光收回，我們問，是否用了看板/jira/站會，乃至所謂TDD，就是在實踐敏捷開發(fā)了？
明確回答，不是。
敏捷宣言的價值觀中，有這樣一條
?個體和互動高于流程和工具
?
如果僅僅是引入了工具鏈，即便再先進，投入的資源再多，也不過是流于表面。
真正的敏捷是要調(diào)用個體之間的互動，而這種互動必然是良性的，平等的，沒有信息差的，友好共享的。
你知道我在說什么。
于是我們可以多聊幾句，我們聊聊層級官僚制，或者說科層制。
科層制在人類發(fā)展中，被認為是最為理性的組織結(jié)構(gòu)。
一個理想的科層制架構(gòu)，命令從上往下，層層傳達，職責層層細分，每一層的人都知道自己要干什么，井井有條。像是一個精密的儀器，永不出錯。
這里我只說幾句，畢竟這個話題不能聊深。
我想說的是，在傳統(tǒng)的zz領(lǐng)域和傳統(tǒng)實體行業(yè)，科層制尚存在低效、長臂管轄、信息丟失等現(xiàn)象，試問在講究效率與變化的互聯(lián)網(wǎng)/IT行業(yè)，它就能保證不出查錯，高效運轉(zhuǎn)嗎？
我想，沒有人敢站出來，拍著胸脯說，你是錯的，這是對的。
人是有思想的動物，信息越透明，人的思想越廣闊。反之，信息差越多，越激發(fā)誤解與不滿情緒，而這種不透明，絕對多數(shù)是來自自上而下的，而這種自上而下往往會在基層集中體現(xiàn)。
我不談什么皈依者狂熱，那太絕對化，我只想表達一個觀點，基層的公平性與信息的透明性應(yīng)當如何體現(xiàn)？
聊回資源池。
?所謂資源池，是指對于一個團隊的成員而言，每個個體都是可調(diào)度的資源單位。理想情況下，若團隊中每個個體的認知水平相差不多，原則上，凡是涉及到該團隊的需求和問題，任意調(diào)度團隊中此時有時間投入新需求/新問題的個體，都能夠cover。
?
資源池可以說是中式軟件開發(fā)，在多年迭代與探索中，為了提高人力資源利用率而總結(jié)出的一套可行手段。
那么，保證這個模式能夠健康良性運行的前提，便是消除信息差。
敏捷與信息差之間的矛盾是否可調(diào)和？
自然地，我們提出這樣一個問題。
兩者矛盾，是否可調(diào)和？
我們說可以，解決方式在于消除信息差。
有人可能要站出來反對了，你這意思是直接取消基層的調(diào)度管理節(jié)點嗎？
兄弟，坐下說話，別激動。
那我們聊聊，基層調(diào)度節(jié)點的設(shè)立吧。
設(shè)立基層調(diào)度節(jié)點，無外乎因為人多了，一級管理節(jié)點精力有限，難以顧及方方面面，因此需要設(shè)立基層的調(diào)度節(jié)點來協(xié)調(diào)工作。
這沒問題，這不正是經(jīng)典的分治法么。
那問題在哪里？問題在于，將原本繁瑣的事情進行某個維度的劃分，再分擔給基層調(diào)度節(jié)點，就萬事大吉了么？
對于一級管理節(jié)點，的確減輕了壓力，但是對于基層的資源池角色呢？
要知道，基層調(diào)度節(jié)點可是從資源池里選出來的，也就是說，在全局上，能夠切實干活兒的實際資源池角色減少了。這是一方面。
另一方面，將新增的調(diào)度節(jié)點去作為對接任務(wù)的分發(fā)器，對于真正干活兒的資源池角色而言，何時介入需求，變成了該調(diào)度角色決定的事情。
何時介入，以及介入何種需求，都是黑盒子。
我們分開說。
何時介入有影響么
當然有，一個需求，或者說一個問題，前期溝通不是你，前期討論你沒參與。直接喪失了接觸第一手資料的機會；這其中有多少信息丟失？
進一步，等你介入的時候，都已經(jīng)到了切實的落地環(huán)節(jié)，怎么做已經(jīng)有人幫你想好了，甚至可能連設(shè)計大綱都寫出來了。
你要做的就是照著這個圖紙，修房子。與戴著鐐銬跳舞，何其相似。
對于解決一個具有一定規(guī)模的問題而言，這種基于他人的思路解決問題的方式，從根源上就限制作為一個獨立個體的思考能力。
萬事俱備，就差一個程序員了。
魔幻現(xiàn)實主義。
寫代碼，或者說，軟件開發(fā)，是一種創(chuàng)造。如果你要創(chuàng)造，那就從頭到尾都是你作為核心在創(chuàng)造，你的想法，你的設(shè)計，你的代碼。一氣呵成。
當然，對于復雜問題，多人參與也是應(yīng)該的，但是至少這其中至少存在這么一個角色，他參與了整個問題的生命周期，我想這對于少犯錯，提升健壯性，意義巨大。
為何要你的想法，你的設(shè)計，再變成我的代碼？這其中要損失多少個腦細胞，換來多少句親切的問候？不敢多想。
那，如何破局？
?山人有補藥和苦藥兩劑，且聽山人道來。
?
「補藥」，溫順，我們的目的是為了減少信息差，提高參與度與個體互動，那不妨在問題早期討論階段就讓可能的參與者參與到討論中，在這其中，挑選時間、精力、能力均能勝任的一人或多人參與后期的設(shè)計和編碼。
你會發(fā)現(xiàn)，作為調(diào)度節(jié)點，每個問題上，都不再是單打獨斗，總有人會和你一起分擔來自問題/需求的壓力；作為資源池中的角色，有想法，有一手知識，有你的設(shè)計，最后你將自己的想法和設(shè)計付諸落地，一件美事。
補藥如此精妙，那苦藥又如何？
既是「苦藥」，怕不會太好下咽。從資源池中來，回資源池中去吧。
足下可否明示？
?我是說，去TMD的調(diào)度節(jié)點吧。
?
調(diào)度節(jié)點，本質(zhì)上還是資源池中的一員，選出來作為調(diào)度節(jié)點，是為了更好地協(xié)調(diào)復雜事項，做好問題的預調(diào)研，預分配。
但是實際上呢？好像，調(diào)度成了主要職責了，dispatch各種事項給資源池中的executor，在各個上下文中靈活切換，然后不時回調(diào)一下，看看進度如何，以便靈活組織語言進行匯總上報。
「精彩，精彩，精彩。」
作為調(diào)度節(jié)點，你可能委屈，“我的精力都被各種事項占滿，再讓我去負起資源池角色的責任，臣妾做不到啊”。
可以理解，但是請讓事情的透明度更高一些，讓executor們的參與度更高一些，停止你的所謂好心行為，你設(shè)計，你討論，為什么要executor來買單？
你設(shè)計，你討論，那就你來開發(fā)。畢竟，我們是一個敏捷團隊，而這，是最敏捷的，最少上下文切換的。
除此之外，作為調(diào)度節(jié)點，別忘了自己的基類還是一個executor，本質(zhì)上是executor implements Dispatcher，那么，請繼續(xù)保持作為executor的公平性。
「該值的班，該復的盤」，請不要躲避，聽我說謝謝你。
不患寡而患不均，這其中的利弊，我想作為資源池中的翹楚，調(diào)度節(jié)點比我更清楚。
如何更好地發(fā)揮資源池的優(yōu)勢，提升敏捷度？
資源池這種實踐模式，確實被實踐驗證為能夠切實解決問題，落地想法的模式，雖然存在不合理之處，但是不掩蓋它的光芒。
那么基于資源池模式不改變的前提，如何發(fā)揮它的優(yōu)勢，更好服務(wù)于敏捷軟件開發(fā)流程呢？
這里提供一個場景，供君品鑒。
產(chǎn)品同學有一個好的點子，想為系統(tǒng)添加一個新的產(chǎn)品線，該產(chǎn)品線能夠帶來日PV增加百分之5的效果。于是產(chǎn)品同學編寫prd，并向需求池中投遞需求，并期望支持的人力資源。
資源池中進行調(diào)度的開發(fā)同學，根據(jù)自己在甘特圖上的排期及任務(wù)分配情況，對需求池中的需求進行主動揀選，并進行預排期。
一旦鎖定了該任務(wù)，該同學便會成為該需求的owner，后續(xù)的討論、設(shè)計、開發(fā)、測試均需要參與，并負責到上線。
有會必邀，邀必參與，自己想，自己參與溝通，自己落地，自己追結(jié)果，自己負責。出問題，自己復盤，問心無愧。
康威定律的啟示
康威定律告訴我們，設(shè)計系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設(shè)計的組織的溝通結(jié)構(gòu)。也就是說，產(chǎn)品必然是其（人員）組織溝通結(jié)構(gòu)的縮影。
你的組織架構(gòu)是什么樣的，如如何運作的，基本上你的業(yè)務(wù)架構(gòu)也是這么運作的。
業(yè)務(wù)架構(gòu)，技術(shù)架構(gòu)在迭代，組織架構(gòu)也需要迭代，否則滯后冗贅的組織架構(gòu)必然帶來畸形低效的業(yè)務(wù)架構(gòu)、技術(shù)架構(gòu)。
一個敏捷的團隊，是自革新的，是自迭代的。
讓前線的特種部隊能夠呼喚集團炮火。這是日漸銷聲匿跡的中臺遺留下的一句經(jīng)典。
你可以說中臺是失敗的，但是你不能否認這句話的積極意義。
與業(yè)務(wù)交互的團隊，尤其是自詡敏捷的團隊，一定是一個精悍的特種部隊，扁平化，高效化，信息透明化，專家化。
如果這個團隊把整個后勤部門都攜帶在身邊，那么行軍效率一定不會很高。
讓后勤待在后勤的位置，讓部隊前出偵查。這才是現(xiàn)代化戰(zhàn)爭的作戰(zhàn)形態(tài)。這也是康威定律給我的啟示。
擁抱變化，不是自上而下的指示，而是推己及人的感悟，是整個團隊所樂于擁抱的態(tài)度，是歷史螺旋上升的坐標。
結(jié)語：敏捷之于個人又如何？
之于個人，敏捷的背后，也許是內(nèi)卷。
關(guān)于內(nèi)卷，我不想多聊，我不反對內(nèi)卷，這是一種選擇，它也許是一種無奈，也許是一種隨波逐流，也許是發(fā)自內(nèi)心的自我鞭策。
都無所謂，只要是自己的想法，自己的選擇，內(nèi)卷或者躺平，無關(guān)風月。
紛繁的會議里，你知道哪個是重要的；瑣碎的事務(wù)中，你知道優(yōu)先級是如何排列的。
并行的需求中，你能夠把握結(jié)果走向；復雜的問題里，你知道問題就在那里，答案就在那里。
你知道，你有一群好隊友，你知道，你有一個好team。
你知道，你有一顆清醒、獨立的內(nèi)心；你知道，你知道。
你知道，你不知道。
心存敬畏，踏實向前，不迎合所謂的文化，不沉溺于所謂的氛圍，不抱怨所謂的現(xiàn)狀，不停止思考的大腦。
敏捷，發(fā)乎于內(nèi)心，行乎于個人，成乎于群體。
中式軟件開發(fā)的現(xiàn)狀，已經(jīng)是世俗化的，利益導向化的，實用主義化的。對于敏捷團隊而言，始終是服務(wù)于業(yè)務(wù)增長的，要深知，當代中式互聯(lián)網(wǎng)軟件開發(fā)，幾無技術(shù)驅(qū)動型，放眼望去，皆為業(yè)務(wù)驅(qū)動型。
那么想明白這個道理，再去實踐，就會少一些壓力，多一些豁達。
不妥協(xié)，不偏激，不隨波，不逐流。
有想法，便會踏實，不輕易追逐內(nèi)卷節(jié)奏；
有目標，便會沉穩(wěn)，不停止自我迭代腳步。
其實，軟件開發(fā)里，根本沒有敏捷。