0. 背景

上士聞道，勤而行之铸本；中士聞道肮雨，若存若亡；下士聞道箱玷，大笑之怨规。不笑不足以為道。--《道德經(jīng)》

之前聽到锡足、看到波丰、用到敏捷的時(shí)候就直接根據(jù)其中的敏捷規(guī)范、規(guī)則進(jìn)行實(shí)踐舶得。遵循了：勤而行之規(guī)則掰烟。軟件工程從原始的作坊式工作方式，到現(xiàn)代化的敏捷工作方式在這個(gè)過程中經(jīng)過了哪些思考沐批、哪些方案的試探纫骑、在不斷地嘗試與改善后才走到現(xiàn)代化的工程過程。深入的體會(huì)在升級(jí)的道路上經(jīng)歷了哪些挑戰(zhàn)九孩，針對(duì)這些挑戰(zhàn)做了哪些方案對(duì)于真正的踐行敏捷工作方式有著深入的指導(dǎo)意義先馆。這里對(duì)比一下作坊式的過程與敏捷過程的區(qū)別，以實(shí)例的方式具體舉例說明這兩個(gè)過程管理中有哪些點(diǎn)的提升躺彬。

1. 作坊過程方式（無組織式）

作坊

在具備一般規(guī)模的公司來說都有一套完整的研發(fā)流程煤墙，以支撐公司的研發(fā)體系。這樣做的最主要優(yōu)點(diǎn)是可以保證各個(gè)團(tuán)隊(duì)的行為規(guī)范基本一致宪拥，從而保證質(zhì)量仿野、速度、規(guī)范性都是比較一致的她君。而作坊式的過程管理一個(gè)很大的特點(diǎn)就是各個(gè)團(tuán)隊(duì)之間沒有統(tǒng)一的研發(fā)流程脚作，從而導(dǎo)致更多細(xì)節(jié)性的問題。

闡述過程分先后犁河，但作坊式的過程管理的問題并不是先后出現(xiàn)的鳖枕。而是并發(fā)發(fā)生的魄梯，所以這里的陳述順序不影響問題的優(yōu)先級(jí)和問題發(fā)生事件桨螺。下面討論一下作坊式的過程管理中會(huì)遇到的問題。下文中以抽象總結(jié)出的結(jié)論作為章節(jié)標(biāo)題酿秸，再以實(shí)例來說明標(biāo)題灭翔。

1.1 邊界模糊

邊界模糊說明兩件事：業(yè)務(wù)邊界模糊，時(shí)間邊界模糊。這兩個(gè)模糊邊界會(huì)導(dǎo)致投入的人力未知肝箱、質(zhì)量問題收斂速度未知哄褒。所以，項(xiàng)目管理鐵三角缺一項(xiàng)就會(huì)影響質(zhì)量煌张，作坊式過程中會(huì)缺三項(xiàng)可以說是沒有做過程管理呐赡。

1.1.1. 業(yè)務(wù)邊界模糊

業(yè)務(wù)邊界模糊可以從幾個(gè)方向說明：

• 業(yè)務(wù)需求過大導(dǎo)致的邊界模糊
  在做過一個(gè)從零到一的OAM（Open Application Model）的迭代過程中，需要對(duì)OAM建立GUI骏融，YAML配置链嘀，版本過程，發(fā)布過程等等档玻。每個(gè)過程都有無數(shù)的細(xì)節(jié)怀泊，例如：在控制應(yīng)用下的副本數(shù)的時(shí)候不填代表什么？填0代表什么误趴？填數(shù)有代表什么霹琼？再比如：在OAM中邏輯概念有十幾個(gè)，每個(gè)邏輯概念可以作為一個(gè)邏輯實(shí)體凉当。邏輯實(shí)體之間的關(guān)系會(huì)形成三聯(lián)實(shí)體（三個(gè)實(shí)體之間的特定關(guān)系）枣申，有甚者會(huì)有四聯(lián)實(shí)體。
  在這樣復(fù)雜的場(chǎng)景下總會(huì)漏一些在前期需求澄清時(shí)總有未想到的細(xì)節(jié)點(diǎn)看杭，最終都遺留到線上才發(fā)現(xiàn)也是有的糯而。

• 業(yè)務(wù)澄清模糊導(dǎo)致邊界模糊
  在做業(yè)務(wù)澄清時(shí)，因?yàn)槭荁A/產(chǎn)品給研發(fā)/測(cè)試進(jìn)行講解總會(huì)遇到澄清過程中基于現(xiàn)有的需求理解為某個(gè)特性確定為一個(gè)方向泊窘。但在開發(fā)過程中或業(yè)務(wù)上線后會(huì)意識(shí)到這個(gè)問題不應(yīng)該在這個(gè)方向上熄驼，而應(yīng)該在另外一個(gè)方向。例如：K8s的資源管理器Helm界面上支持環(huán)境管理不需要支持依賴中的values文件作為指定文件烘豹，但后來需要支持瓜贾。

• 版本發(fā)布導(dǎo)致的業(yè)務(wù)邊界模糊
  私有化部署要做版本化，然后在發(fā)布Saas產(chǎn)品的時(shí)候又要?dú)w到版本中携悯。在這個(gè)過程中Saas線上用戶報(bào)的工單祭芦，Saas線上用戶的簡(jiǎn)單需求。到底應(yīng)該在哪個(gè)版本來同步到私有化部署的版本中憔鬼。因?yàn)镾aas線上客戶的需求龟劲，工單是需要放在當(dāng)前線上的版本中的。這樣就導(dǎo)致線上需求會(huì)上多個(gè)版本轴或，如果版本會(huì)有一點(diǎn)不同那么就會(huì)造成版本差異問題昌跌。

1.1.2. 時(shí)間邊界模糊

時(shí)間邊界模糊可以從幾個(gè)方向說明：

• 不做工作量評(píng)估，或以人員能力來做工期評(píng)估
  作坊式過程管理是將工作交給某個(gè)人或者交給兩個(gè)人去做即可照雁，具體什么時(shí)間做完做成什么樣就沒人去管了蚕愤。
• 因?yàn)闃I(yè)務(wù)邊界模糊導(dǎo)致，交付時(shí)間不確定。
  任何時(shí)候都可以插入新的工作萍诱，導(dǎo)致每個(gè)人手中的工作越堆積越多悬嗓。然后再推導(dǎo)出插入進(jìn)來的工作先做，前面接手的工作又被延后了裕坊。從而導(dǎo)致手中重要的工作一直向后延期包竹，而又無法推動(dòng)上線。
• 過大的開發(fā)量籍凝，導(dǎo)致評(píng)估不準(zhǔn)確
  過長(zhǎng)的開發(fā)周期直接上線映企，導(dǎo)致很多點(diǎn)未測(cè)試完全，問題遺留到線上解決静浴。問題定位都有可能忘了細(xì)節(jié)在哪里堰氓。
• 團(tuán)隊(duì)協(xié)作
  私有化部署與Saas服務(wù)不同，私有化部署必須在某個(gè)時(shí)間點(diǎn)對(duì)齊功能之后再打版本苹享。這樣就會(huì)形成團(tuán)隊(duì)間協(xié)作双絮。一般作坊式工作坊中不會(huì)在團(tuán)隊(duì)間形成時(shí)間對(duì)齊理念，因?yàn)闆]有PMO來對(duì)齊與跟蹤這部分得问。

1.2 獨(dú)立個(gè)體大于團(tuán)隊(duì)協(xié)作

在作坊式過程的團(tuán)隊(duì)形式比較恰當(dāng)?shù)谋扔魇菆F(tuán)隊(duì)是一個(gè)職能型組織囤攀。職能型組織最大的特點(diǎn)是相互獨(dú)立，專業(yè)化團(tuán)隊(duì)宫纬。在作坊式過程中這樣做其實(shí)會(huì)發(fā)生更多的問題焚挠，例如：某部分工作再一直堆積而又沒有辦法加快進(jìn)度、信息不足導(dǎo)致開發(fā)過程的驗(yàn)證不足從而導(dǎo)致質(zhì)量飄忽不定漓骚、同時(shí)開啟的工作事項(xiàng)越來越多失去重點(diǎn)蝌衔。

1.2.1 協(xié)作過程不通暢

團(tuán)隊(duì)關(guān)系以單個(gè)成員獨(dú)立完成為主，不評(píng)審蝌蹂，不檢查噩斟，不回顧。在這個(gè)過程中就會(huì)發(fā)生信息同步不通暢孤个，無法說明的工作內(nèi)容與進(jìn)度剃允，單個(gè)成員負(fù)責(zé)特定業(yè)務(wù)的問題。

• 信息同步不通暢
  一個(gè)很簡(jiǎn)單的例子：OKR的拆解過程需要從團(tuán)隊(duì)的KR拆解為團(tuán)隊(duì)成員的O齐鲤，在用團(tuán)隊(duì)成員的O進(jìn)行具體的KR的拆解斥废，這樣會(huì)形成KR又下層的O來支撐這個(gè)過程。但是在作坊式的團(tuán)隊(duì)中雖然使用了比KPI更加現(xiàn)代化的OKR來完成團(tuán)隊(duì)目標(biāo)的制定给郊，但是沒有做拆解過程牡肉，沒有目標(biāo)來源的講解過程。那么團(tuán)隊(duì)的目標(biāo)就沒有辦法落地到每個(gè)團(tuán)隊(duì)成員中丑罪，這樣就造成信息不通暢問題荚板。
  另外凤壁，信息是一種非常重要的資源吩屹。當(dāng)之后某幾個(gè)成員掌握特定的信息后跪另，他們就可以把信息作為利益交換資本。這樣特定成員手里就多了籌碼可以跟他人做利益交換煤搜。這樣的事情多了是不是就很像傳統(tǒng)的國(guó)企做事風(fēng)格免绿，要給某些不舔上級(jí)的團(tuán)隊(duì)成員穿小鞋的時(shí)候這個(gè)信息差就可以做到一些不利的事情。這是一種在作坊式工坊中的生存方式擦盾。

• 無法說明的工作內(nèi)容與進(jìn)度
  只在業(yè)務(wù)上說明一個(gè)大概要做的事情嘲驾，再加上業(yè)務(wù)模糊問題。在不進(jìn)行評(píng)審與設(shè)計(jì)迹卢，工作拆分的情況下就無法說明具體工作內(nèi)容辽故，無法跟蹤工作事項(xiàng)中的進(jìn)度「睿可以在開發(fā)過程中來整理是否做過設(shè)計(jì)誊垢，設(shè)計(jì)評(píng)審，工作拆分症见，工作量評(píng)估喂走，工作跟蹤等事項(xiàng)既可知道是否已發(fā)生這個(gè)問題。

• 單個(gè)成員負(fù)責(zé)特定業(yè)務(wù)
  職能型組織一個(gè)特點(diǎn)就是特定的團(tuán)隊(duì)完成特定的業(yè)務(wù)谋作。而在作坊式團(tuán)隊(duì)中一個(gè)成員負(fù)責(zé)一塊業(yè)務(wù)芋肠，然后如果這塊業(yè)務(wù)最近不需要開發(fā)或維護(hù)則負(fù)責(zé)這塊的團(tuán)隊(duì)成員就閑下來了。了解最多的業(yè)務(wù)模塊的成員永遠(yuǎn)最忙遵蚜。無業(yè)務(wù)備份團(tuán)隊(duì)成員概念帖池。

1.2.2 同時(shí)開啟的工作事項(xiàng)越來越多

在開發(fā)過程中不設(shè)置階段（里程碑）、不設(shè)置目標(biāo)吭净，從而把團(tuán)隊(duì)工作作為一個(gè)任何內(nèi)容都可以插入的碘裕，都有必要插入的。在這樣的情況下一個(gè)團(tuán)隊(duì)不管是two pizza團(tuán)隊(duì)還是更大的團(tuán)隊(duì)攒钳，只要是根據(jù)這樣的規(guī)則就會(huì)一直開啟新的工作項(xiàng)帮孔。作者在工作過程中見過一個(gè)團(tuán)隊(duì)同時(shí)開啟十幾項(xiàng)事務(wù)。例如：線上問題修正不撑，KA客戶支撐文兢，代碼安全掃描問題修正，性能優(yōu)化焕檬，客戶小需求幾個(gè)等等都同時(shí)開啟姆坚。

在這樣的情況下，主要特征是規(guī)劃與執(zhí)行有問題实愚。規(guī)劃過程與執(zhí)行過程無法對(duì)齊導(dǎo)致了只做了緊急不重要的事兼呵，而做不了規(guī)劃中的事項(xiàng)兔辅。

1.2.3 丟失焦點(diǎn)（這里就是為什么叫沖刺的根因）

前面說到時(shí)間邊界模糊，再加上上一節(jié)說到同時(shí)開啟多想工作項(xiàng)击喂。再加一個(gè)無周期的環(huán)境中又開啟多個(gè)事項(xiàng)维苔，而不是團(tuán)隊(duì)專注于一件事在固定周期內(nèi)解決這一件事來保持階段的專注性。這樣導(dǎo)致團(tuán)隊(duì)成員都很忙懂昂，但是又沒有完成更多的事情介时。從而降低成員成就感，并對(duì)職位晉升有較大的阻礙凌彬。因?yàn)槁毼粫x升需要闡明在一個(gè)周期內(nèi)為團(tuán)隊(duì)沸柔、為公司做了哪些貢獻(xiàn)，在作坊式過程中做事既瑣碎有誤目標(biāo)總結(jié)為貢獻(xiàn)就會(huì)很難铲敛。

1.2.4 任性的成員越來越多

團(tuán)隊(duì)目標(biāo)缺失導(dǎo)致團(tuán)隊(duì)成員沒有行為規(guī)范褐澎。沒有行為規(guī)范各個(gè)成員就會(huì)按照個(gè)人理解對(duì)代碼，開發(fā)規(guī)范進(jìn)行實(shí)施伐蒋。在開發(fā)過程中就會(huì)發(fā)現(xiàn)A想這樣工三，B想那樣最終就看誰更強(qiáng)硬。而不是看團(tuán)隊(duì)整體的目標(biāo)輸出價(jià)值咽弦，還是穩(wěn)固質(zhì)量就開始做自己的事情徒蟆。導(dǎo)致各做各的，由此任性的成員就從這里出來型型。

1.2.5 獨(dú)立個(gè)體大于團(tuán)隊(duì)協(xié)作

事情堆積如山段审，再來新的事情必須排隊(duì)進(jìn)行。因?yàn)槭马?xiàng)同時(shí)開啟過多闹蒜，導(dǎo)致每個(gè)成員要做的事情都是不一樣的寺枉。每個(gè)人頭上都是一堆事要做，而每個(gè)事情都有不同的頭需要去牽扯出來再做绷落，所以姥闪，沒有辦法去做。

1.3 無過程CheckPoint

因?yàn)闆]有里程碑的制定砌烁，就沒有辦法check計(jì)劃執(zhí)行情況筐喳。無法跟進(jìn)進(jìn)度的情況下很容易造成相互職責(zé)，相互不信任的過程函喉。進(jìn)入負(fù)反饋循環(huán)之后就會(huì)造成團(tuán)隊(duì)在泥沼中越陷越深避归，再加上作坊式過程無法完成自我改善。

• 無視風(fēng)險(xiǎn)
  技術(shù)風(fēng)險(xiǎn)管呵、進(jìn)度風(fēng)險(xiǎn)梳毙，在前期識(shí)別過程中沒有過程與方法來提出。在中期沒有CheckPoint進(jìn)行識(shí)別捐下。后期進(jìn)行無回顧與總結(jié)更無法在后期回顧風(fēng)險(xiǎn)账锹。從而在整個(gè)研發(fā)過程中無法進(jìn)度測(cè)量和結(jié)果評(píng)估需要不同的方法萌业。

• 無視質(zhì)量
  在作坊式工作過程中，工作事項(xiàng)會(huì)堆積如山奸柬。而在這個(gè)時(shí)候質(zhì)量的劣勢(shì)就更加凸顯生年，在質(zhì)量的效果不可顯示展示出來。所以鸟缕，就會(huì)極力的壓榨質(zhì)量的投入晶框。例如：開發(fā)完成測(cè)試用例編寫排抬，開發(fā)完成測(cè)試工作懂从，開發(fā)完成驗(yàn)收上線工作。
  這樣很容易造成陷入固有思維陷阱蹲蒲，導(dǎo)致問題在線上暴露番甩。

• 運(yùn)動(dòng)式管理
  作坊式管理就是沒有規(guī)矩，想一出是一出届搁。例如：前兩天發(fā)現(xiàn)線上問題比較多缘薛，然后就開始問質(zhì)量人員為啥沒測(cè)出來。過兩天線上問題少了就又忘了這一出卡睦。再跟上沒有過程改進(jìn)宴胧，復(fù)盤又無法做到根因分析。所有的過程管理都流域表面無法解決根本性的問題表锻。

1.4. 結(jié)論：

初步總結(jié)一下作坊式過程恕齐，其實(shí)還有很多事情無法深入討論。例如：這樣的團(tuán)隊(duì)中的成員對(duì)于過程管理的認(rèn)知是什么樣的瞬逊？這樣的團(tuán)隊(duì)中文化是什么樣的显歧？

1.4.1 難以響應(yīng)外部變化

永遠(yuǎn)在響應(yīng)變化，那就是沒有響應(yīng)變化确镊。因?yàn)橛肋h(yuǎn)響應(yīng)變化那就沒有時(shí)間去做自己應(yīng)該做的事情士骤，例如OKR，KPI事項(xiàng)蕾域。而在根據(jù)OKR引申到要支撐的業(yè)務(wù)方向的變化就更難進(jìn)行支撐拷肌。

1.4.2 質(zhì)量信心缺失

因?yàn)闊o視質(zhì)量，所以新開發(fā)的內(nèi)容上線旨巷，線上什么時(shí)間出問題都保持迷惘狀態(tài)巨缘。從而需要時(shí)時(shí)刻刻都要保持警惕，然后以人力的方式老保證系統(tǒng)上線故障的解決契沫。

1.4.3 進(jìn)度對(duì)齊工作無處可做

進(jìn)度對(duì)齊包括團(tuán)隊(duì)內(nèi)部對(duì)齊带猴，團(tuán)隊(duì)間對(duì)齊。一方面因?yàn)樾畔贤ú粫承竿颍硪环矫嬉驗(yàn)椴贿M(jìn)行規(guī)劃拴清，再加上每項(xiàng)事都是單個(gè)成員獨(dú)立完成靶病。幾乎各個(gè)點(diǎn)都有可能影響進(jìn)度墅诡，而這些點(diǎn)又沒有對(duì)齊所以風(fēng)險(xiǎn)更高湿刽。

1.4.4 導(dǎo)出結(jié)論：不要合作，想怎么干就怎么干

從上面的現(xiàn)象描述過程中可以看到羹奉，軟件開發(fā)的團(tuán)隊(duì)合作幾乎沒有沪停。為了不守規(guī)矩想怎么干就怎么干煤辨。

2. 敏捷方式

在這樣的團(tuán)隊(duì)中既無輸出有無成果還每時(shí)每刻都要提心吊膽的盯著線上是不是有問題。而且不會(huì)有張弛有度木张，只會(huì)一直的在做緊急的事情众辨。看完上面的內(nèi)容是不是感覺很無力舷礼，很不理解怎么做成這樣鹃彻。
從軟件開發(fā)領(lǐng)域的基本規(guī)則作者推導(dǎo)出一個(gè)更一般性的規(guī)則：理清事物之間的關(guān)系，描述清楚事物的邊界妻献，剔除不必要的內(nèi)容蛛株，添加必要內(nèi)容；遵循這個(gè)規(guī)則才能更好的做成事育拨。

2.1. 自組織團(tuán)隊(duì)

• 代碼使用團(tuán)隊(duì)所有制
  而不是獨(dú)立個(gè)人對(duì)業(yè)務(wù)這種形式谨履，應(yīng)該是以團(tuán)隊(duì)所有制的形式來管理代碼所有制。
• 最好的架構(gòu)熬丧、需求和設(shè)計(jì)出自自組織團(tuán)隊(duì)
  更多的團(tuán)隊(duì)自主權(quán)笋粟，團(tuán)隊(duì)群體決策。這樣的方式可以提升團(tuán)隊(duì)整體凝聚力與責(zé)任心锹引。

2.2. 小步快跑

將大的無法評(píng)估的工作矗钟，拆分成小的工作。并以明確小工作的目標(biāo)嫌变，以小工作來組成項(xiàng)目吨艇。這樣即設(shè)置了里程碑，又可以進(jìn)行check腾啥。這就是完成沖刺的第一個(gè)概念周期东涡。

2.3. 目標(biāo)明確

由Sprint Backlog來明確迭代目標(biāo)，以Product Backlog來明確產(chǎn)品目標(biāo)倘待。這樣就有了沖刺的另一個(gè)概念目標(biāo)疮跑。

2.4 結(jié)論

其實(shí)最簡(jiǎn)單的事才是最難做的。就像以敏捷方式來解決作坊式的問題其實(shí)就很簡(jiǎn)單凸舵。但是祖娘，要理解敏捷，并以敏捷的方式去解決作坊的問題必須理解為什么敏捷是這么做的啊奄。

3. 總結(jié)

軟件工程是以工程化方法規(guī)范軟件開發(fā)渐苏，按步驟和流程進(jìn)行軟件開發(fā)掀潮，保證軟件項(xiàng)目成功交付。上世紀(jì) 60 年代琼富，IBM 開發(fā) OS/360 操作系統(tǒng)仪吧，這是第一個(gè)超大型軟件項(xiàng)目，非常復(fù)雜鞠眉。當(dāng)時(shí)薯鼠，共有 1000 名左右的程序員參與了項(xiàng)目研發(fā)，花費(fèi)了 5000 個(gè)人年械蹋，最終卻無法運(yùn)行出皇。而項(xiàng)目負(fù)責(zé)人 Brooks 博士后來撰寫了一本軟件工程的經(jīng)典書籍《人月神話》。

而現(xiàn)在還在討論這些基本的過程管理方式朝蜘，其實(shí)可以說明現(xiàn)在業(yè)內(nèi)的一些問題恶迈。

4. 參考

2022年涩金，走出軟件作坊谱醇！
The 2020 Scrum Guide #The Sprint
Scrum 指南
五大過程組|十大知識(shí)領(lǐng)域|47個(gè)過程組