源於精益的生產節拍是否能夠適用到軟體開發？
源於精益的節拍時間是什麼？
節拍時間代表著客戶的需求進度以及隨之而來的理想中的生產進度，另外一個說法就是生產節拍，節拍一詞是來自德語中用來演奏的節奏(Takt)。精益裡面的生產節拍是指在一定時間長度內，總有效生產時間與客戶需求數量的比值，原理公式如下：
節拍時間=可用時間/每日的客戶需求。
常見具體計算公式如下：
節拍時間 = 可用工作時間（單位：分鐘數 / 天 ）/ 客戶需求（單位：件數 / 天）
舉例：以每天有且只有一個常日班來說，總計有8小時(480分鐘)。減去30分鐘午餐，30分鐘休息(2 x 15 分鐘)，10分鐘交接班和10分鐘基本維護檢查。那麼可用工作時間 = 480 - 30 - 30 - 10 - 10 = 400分鐘。當客戶需求為每天400件時，每個零件的生產時間應控制在一分鐘以內來保證客戶的需求。
根據客戶需求量與工廠可供時間所得之節拍時間，可以用來識別生產環節的瓶頸，進而進行調整，獲得更加經濟的安排，釋放多餘生產能力，進而提升生產效率。
從節拍時間的定義可以看出，節拍時間與前置時間或者響應時間不同，生產節拍實際是一種目標時間，是隨需求數量和需求期的有效工作時間變化而變化的。節拍反映的是需求對生產的調節，如果需求比較穩定，則所要求的的節拍也是比較穩定的，當需求發生變化時節拍也會隨之發生變化，如需求減少時節拍就會變長，反之則變短。
這在精益生產中已經獲得成功驗證。
為什麼一個軟體從業人員開始關心生產節拍？
在《精益的轉變》一書中，作者亞特-伯恩識別了如下4個敏捷轉變實施原則：
按節拍時間工作
創建單件流水作業
確立標準化作業
通過拉式系統把你的客戶同你的車間聯繫起來
按節拍時間工作被列為第一條，精益實踐者在談到「節拍」時想起用節拍器來形容穩健的步伐，而穩健的步伐是精益中最重要的元素。
從字面上看，這與敏捷開發當中的迭代時間箱工作方式極為接近。
而同樣在《精益的轉變》一書中，作者反覆強調了精益不僅僅適用於生產型企業，同樣使用於非生產型企業，包括服務型企業等等任何企業。按這個推論，作者顯然認為也能適用到軟體開發當中，但是作者並沒有從事或者領導軟體開發企業的經歷。是作者不了解軟體開發，進而誤判了精益適用範圍？還是作者得到的普遍規律其實是適用於軟體開發，只是還沒有充分進行探索？
在精益生產的例子中，節拍時間所使用的單位是分鐘或者秒，其相應的交付響應時間從8周降低到2天，不禁讓軟體從業人員遐想軟體開發能不能做到交付響應時間降低到數天。
本文試圖來初步探討下這個問題。
如果軟體使用節拍時間，軟體節拍時間是什麼樣？
對於軟體開發，顯然在數量級上與工廠生產是有巨大差異的。可行的一個調整方案是採用小時和月度作為節拍的計算窗口。這樣的話，計算公式如下：
Takt Time = 可用工作時間 （單位：小時/月）/ 客戶需求（單位：個數/月）。
舉例：假設普通月份有22個工作日，那麼分支是 22 * 8 = 176 小時/月。
當每月需求有20個，那麼生產節拍就是 176/20 = 8.8 小時/個。
為簡便計，以下採用「軟體生產節拍」這個提法，來區別於常見精益裡面的節拍時間。
還有一個很有意思的要點是對比精益的其它度量，節拍時間的計算是可以在沒有精益準備下處理計算的，只需回顧下過去三個月上線了多少個需求（或者講是項目，要點是對客戶有意義）。
這也是筆者看到節拍時間之後馬上感興趣的原因之一，在文末提出了一個問題，請讀者留意下，自己思考看看。
軟體生產節拍的前提是什麼？
留意上一節軟體生產節拍的計算，其中分子上的可用工作時間在軟體開發中也是存在的，而其中分母上的客戶需求卻是在傳統軟體開發中沒有的。傳統的瀑布生命模型或者軟體生存周期方法，一個軟體開發項目歷時6個月，按各個生命周期階段來開發，不進行每月需求的度量。而在Scrum裡面，有類似的概念，比如衝刺速率，一個迭代完成了多少個故事點。但與精益的生產節拍也並不完全對應。顯然的，瀑布生命周期的大批量分階段的特徵離精益生產節拍更加遙遠，為對接分析軟體開發和精益生產節拍，本文餘下採用Scrum來對比分析這樣的軟體生產節拍的前提有沒有可能滿足。首先來看差異。
比較Scrum的衝刺速率和軟體生產節拍
簡單分析
說明1：一般的，Scrum裡面的development team判斷故事的點數，PO沒有發言權，客戶可能不知道故事點數。
說明2：假設迭代長度正好是一個月
綜上表，兩者存在一些相似的地方。在精益起源的行業里，客戶需求往往是各種各樣的零件或者組裝好的零件，客戶所需要的東西與生產流水線上的工件存在自然的對應關係。而對於軟體開發而言，軟體開發團隊處理的工件在瀑布生命周期里和RUP里有各類文檔，這類比到精益，顯然更加遙遠。在Scrum裡面常見有用戶故事，體現對於用戶的價值，這看起來離客戶需求更加接近。
而兩者最大的區別在於故事和故事點是Scrum團隊自身定義的，而客戶需求是客戶或者業務方定義的。
軟體的客戶需求與生產型工廠的客戶需求存在巨大差別。除了極為少數的特殊工廠（比如火箭、太空梭），工廠的客戶需求自然而然已經劃分成了小顆粒度（比如輪胎，燈泡，鋼珠，各種各樣零件）。而軟體的一個客戶需求，既可能只需修改10行代碼，也可能需要10000行代碼，甚至更多代碼。
軟體的客戶需求能否與工廠的客戶需求那樣？
顯然的，經歷了這麼多年的紛紛擾擾，已經清楚的看到，不經過加工的客戶需求與工廠的客戶需求顯然不一樣。經過加工的客戶需求也許可以像工廠的客戶需求那樣來處理，在探討具體如何加工之前，如下問題先來，有沒有必要對客戶需求進行加工，以便獲得精益所宣稱的那些好處？
事實上，雖然生產型工廠處理的工件自然是小顆粒度，但已經發生了對客戶需求進行加工的例子。比如不惜重寫銷售條款，限制訂購三個月的需要量，比如每月最後一周只能訂購月度需求量的50%，不實行量大優惠政策，著眼於平衡訂單。
以上的做法在工廠里已經得到了驗證，明顯的好處是雙方共贏。
時基競爭時代早就已經開始
時基競爭是指產品被生產出來，運到市場，並提供給客戶的速度上的競爭。這個概念在上世紀90年代初流行，現在已經被大多數生產型企業接受。波士頓諮詢集團的喬治-斯托克和托馬斯-豪特在《與時間競爭》一書中強調了這種理論的重要性。
IT界也早就有「快魚吃慢魚」的共識，不再是「大魚吃小魚」。
有人說，敏捷已經17年，貌似也在成為傳統了，它的速度範圍標籤大概在每周到每月發布一次，但多數敏捷實踐並沒有度量實際的客戶需求響應時間，極有可能是在2周的發布間隔之後掩蓋著長達3個月的需求響應時間，某些潛在可交付物對應在精益視角里，可能就是屬於應當降低的庫存。
為了贏得時基競爭，敏捷的用戶故事是時候考慮向前到業務方去加工客戶需求了？
對於已經提出蠻多時間，但至今貌似還沒有較為完善理論整理的「業務敏捷」而言，加工客戶需求相信是業務敏捷裡面最優先考慮的重要部分。
如何加工客戶需求？
理想的情況是業務提出小顆粒度的需求，既能獨立的實現業務價值，又能夠得到快速軟體開發實現上線。但這樣談何容易？ 業務方與IT方在最近30年，已經演出了一幕幕互相抱怨的鮮活劇，業界的段子已經累積不少，產品經理作為其中的交接點，受盡了夾板氣。
是不是應當從精益節拍時間的啟發中嘗試新的方法？筆者正在採用一個方法，有初步的成效，看到了客戶需求響應時間的下降。此方法要點如下：
收集來自業務、客戶及各相關方的原始需求，也稱為客戶聲音，記錄提出日期；
初步分析後分拆、再寫和包裝這些原始需求到客戶需求（不同公司採用不同說法，有仍然叫項目，也有稱為Feature，或用Epic），要點是達成業務所需價值的最小顆粒度，這與MMF是完全一致的，這需要基於業務的判斷，因此對產品經理提出了更高要求，不再只是理解業務需要翻譯給IT團隊，這裡有個實踐是業務方和軟體開發方組成聯合產品經理團隊。這也就是集中體現了之前提出的「向前到業務方加工客戶需求」
各方聯合判斷客戶需求是否採納，判斷採納日作為採納日期
分析採納後的客戶需求得到用戶故事
根據IT方內部系統子系統和團隊劃分，為中後台團隊/系統，分析用戶故事到系統故事
協調多團隊，聯合排期
上線，記錄上線日期，減去採納日期，得到客戶需求響應時間
建立客戶需求看板，在團隊級建立故事看板，可視化上述過程
度量月度客戶需求吞吐量，以及其它所需度量
計算整體和各個團隊的節拍時間，聯合對比各項度量，以此來調整客戶需求看板的WIP，並協調各個團隊的資源能力平衡（諸如前台-中台-後台，不同系統子系統，開發-測試等等）。這裡要說明的是，軟體開發畢竟與工廠零件生產不一樣，零件生產各個環節往往是自動化過程，時間可以精確提前知道，而軟體開發不具備這樣的條件，根據節拍時間在精益裡面的應用在軟體開發中不能直接使用，需要綜合更多度量來一起觀察。
小結和展望
有一個啟示是可以得到確認的，就是以客戶需求為目標導向，真正關注到價值交付到客戶，而不是停留在價值觀和口號裡面。
利用秒級的節拍時間精確的調整具體工位和工序分工等等在精益工廠裡面發生的事情，估計在未來較長時間內不會在軟體開發中發生（未來的AI編程會不會？），那麼小時級如何？以天為計的節拍時間呢？
下面請讀者根據當前實際情況來算算看，先不管當前需求是否提前加工過，可以簡單粗略來計算下，以支持最小完整業務為範圍，這個範圍是能夠獨立完整的響應業務需求，對應IT人員規模一般少於100人，回顧下過去1個月上線了多個業務提出的要求，不計新接的要求（或者叫需求）和正在做的要求，只看上線後得到使用的要求數量，以此來計算精益生產節拍的粗略值。
如下是個簡單的例子，比如一個月交付了2個需求，簡單粗略計算可以得到的節拍時間長達11天（一個月22工作日除於2，得到11）。
這如何看，會不會擔心競爭對手基於時基優化後只需要10天？如果競爭對手只需要1天的話，如何？
而軟體生產節拍1天的含義就是每天都有業務新東西上線。
互聯網企業天生敏捷，假設某互聯網企業在其原來業務領域已經建立了節拍時間為1天的能力，如果牌照放開，或者其它原因，其進入到某個傳統領域，會不會給傳統領域企業帶來降維打擊？
這在零售領域是不是已經發生？ 其它領域如何？保險？金融？基金？
另外一個情況是業務角度出發的客戶需求雖然經過加工，但其顆粒度仍然可能是超出單個敏捷小團隊的處理範疇，比如不同系統，不同分工，這樣就涉及到多個團隊之間的協調。
早期敏捷給出了敏捷小團隊一級的不少實踐，缺失了對於多團隊協作的指導，需要參考規模化敏捷的實踐指導，而規模化敏捷領域的探索應當說還正在進行。業務敏捷與規模化敏捷必然需要結合在一起來處理。
TAG:大敏捷 |