你的Scrum迭代夠精益嗎？看完就全明白了
Scrum與產品創新
VUCA時代的產品
產品（Product）是用來滿足人們需求和慾望的物體或無形的載體(服務)。虛擬產品和服務將會越來越多佔據人們的時間。然而產品研發中，需求文件永遠沒法完全被理解，實際使用者在看到實物之後可能都不知道自己要什麼，充滿互動的系統（軟體系統，以及近在眼前的AI人工智慧、VR虛擬現實）永遠無法被精確定義和測試。產品及產品研發從來都是創新，沒有哪個產品會和昨天完全一樣，那樣的話只要複製就行了。既然難以複製，所以如果太過關注於效率，就很難有好的效果。在充滿變化和不確定性的情況下，產品研發工作會迅速地進入Cynefin框架中的複雜和混沌領域並不斷進化。
enter image description here
VUCA和網際網路時代，問題、方案、人員、環境很多都越來越難以琢磨，昨天的成功不可重複，甚至昨天的經驗可能是明天的阻礙。所謂不確定性，其實是沒有加上時間維度。學會做時間的朋友，從不確定中找到確定性，一切就容易多了。在物理學中，單獨測量一個光子的偏振方向，每次得到的結果都是隨機的，但是結合時間維度長期來看，測量結果是有規律的、符合概率的，於是人類就可以“控制”量子了，從不確定中獲取確定的收益了。大家也可以看看《反脆弱》這本書，期權投資獲利也都是這個道理。
“尊重人”與“持續改進”
30年前，流水線製造是工業社會主流，成本效率優先。兩位學者Takeuchi和Nonaka於1986年在“哈佛商業評論”發表論文
enter image description here
作者在研究了包括富士施樂，佳能，本田，NEC，愛普生，IBM，兄弟，3M，施樂和惠普（注意，所研究專案是產品整體研發，研究物件都是當時的高科技產品：影印機、相機、個人電腦等，而不單純是軟體開發和交付）在內等多家美國日本的產品創新研發企業後，研究者提出了六點特徵，組合起來可以提高產品研發速度與靈活性，提高企業競爭力：
內在不穩定性（目標導向，團隊高度自主。這就是不確定性管理思維，也即《管理3.0》中講的“用複雜應對複雜”）
自組織專案團隊（強調打造團隊，發揮“人”的作用，鼓勵自我超越和”Kaizen”，異花傳粉式的人員發展）
重疊的研發階段（相對於管理密集型的傳統“順序”式階段而言，類似今天Scrum中的迭代概念。每個迭代都打破職能分工，以產出可用的成果，加速反饋。這種節奏感好比推動團隊的脈搏，加強了共同責任與合作，激發參與和承諾，銳化了解決問題的重點，鼓勵主動採取，發展多元化技能，提高對市場條件的敏感性。）
多層次學習和跨職能學習（個人不斷的讀書、觀察學習，今天有種說法叫”全棧“工程師。組織和團隊的學習，比如現場客戶調研，比如有限時間內的探索等，鼓勵在自己專業之外發展多技能。）
微妙的控制（不是高高在上的管控和精英主義，而是通過同儕壓力和愛進行“控制”，以及自我控制，進而打造自組織團隊。這就是為什麼Scrum比起其他敏捷方法，更加感性，也是Scrum與教練技術緊密結合，在組織規模化轉型發揮巨大能量的原因。CSM中文認證課程的同學，應該還記得喬布斯深諳如何去創造一個“容器”帶領大家發揮智慧之道。）
組織的學習轉移（不斷調整組織結構，將有限的優秀人才轉移到更關鍵的專案上，同時將學習到的知識和教訓分享和傳播出去，但是要小心過度的制度固化）
這些對組織的管理層提出了更高要求，高管必須首先認識到產品研發工作不會以線性和靜態的方式進行。它涉及到迭代和動態的試錯過程。為了管理這樣的過程，公司必須保持高度適應性的風格。1986年已經窺見了“不確定管理”的雛形，並完全地在強調打造團隊，而當今網際網路時代更是勢在必行。如果管理者沒有首先轉變確定性管理思維，是無法運用任何方法的達致業務成功的。
這篇論文沒有提到豐田，而與此同時的豐田早已走上了精益生產的道路，順風順水。在2001年的《豐田之道》中，“尊重人”與“持續改進”是精益價值觀的核心。 這與哈佛商評論文的觀點有著異曲同工之妙。
美國人從豐田的精益製造中提煉和學習精益思想，想弄明白日本汽車是如何大規模佔領美國本土的。可惜日文“Kaizen”這個詞被翻譯成“Continuous Improvement”，中文進一步翻譯為“持續改善/盡善盡美”。字面上看，只要有一點點進步也算是進步嘛，然而，日文原意可不是這麼鬆鬆垮垮的被動改進之意，而是“激進地挑戰一切”之意。
Scrum與精益的淵源
TL;NR
Scrum並非直接延續自精益。Scrum是繼承於CAS(複雜自適應系統)，而精益有助於向管理者解釋為什麼Scrum可以奏效。
Scrum的創始人之一Ken Schwaber受哈佛商評論文影響，從1990年代開始實踐新方法，在1993年拯救了一個瀕臨失敗的專案。
Ken在1994年建立的“控制混亂”網站中，就指出不確定性管理的必要性，他認為自己與另一位創始人Jeff Sutherland對Scrum的研究總結背後蘊含著第一性原理：“複雜性過程需要試驗性的過程控制”。在那個年代，研發型的組織一定都是走在創新之路上的，現在很多研發組織實際走向了富士康模式，但是卻無法管理好。這背後的原因是技術與管理的進步使一些東西變得確定了，然後卻有更多新的不確定因素湧現出來，“控制混亂”前路漫漫。
1995年，Jeff Sutherland應邀將哈佛商評的文章轉發給正在創立極限程式設計的Kent Beck。Jeff曾是越戰中美軍的戰鬥飛行員，對變化無常的戰場複雜形勢有著切身的體會，要想生存就必須要建立響應變化的能力，沒人能夠走直線的。
除了那篇論文，他們還借鑑了精益思想、時間盒概念、SmallTalk社群的面向物件設計思想等理論基礎，並於1995年正式在OOPSLA釋出了Scrum研發過程論文，期間也受到Mike Beedle的幫助，正式提出了Scrum研發框架。
Muri - 避免給予人員和組織不必要的壓力，現在也稱為“可持續發展”。
Mura - 消除跳變和不一致，進行整流，有助於達到超生產力(hyperproductive)。最初幾個Sprint主要是消除流動中的干擾，從而是後續的Sprint更加順暢。
Muda - 激進地消除活動中的7大浪費，持續改善。
後來Ken又注意到Scrum更多是一種管理實踐，而對於軟體開發而言，Scrum落地需要更好的技術能力實踐，於是借鑑XP極限程式設計提出了Scrum Developer訓練內容。
Scrum框架的意圖
為什麼要採用Scrum？因為商業組織往往面臨這些痛點：
產品做出來沒人用，忙的像狗卻沒有成就感
計劃趕不上變化，需求變更太快太多，無法聚焦完成一件事
業務與研發總是在扯皮，使用者總是在投訴
時間緊任務重，每件事情都是高優先順序，總是中救火之中，做不完又焦慮
所有壓力和風險都在後期集中爆發，越忙越添亂
技術和架構更不上時代，知識缺口越來越大，逐漸與社會主流脫節
好的習慣和流程堅持不下來，形同虛設
招不到優秀人才來幫忙，牛人還中不斷流失，團隊一盤撒沙
個人工作與生活失衡，從加班到辭職
Scrum框架的定義
Scrum基於試驗性過程控制理論(Empirical Process)，或稱之為經驗主義，是自然科學研究方法的基礎。經驗主義主張知識源自實際經驗，以及觀察當前已知情況下做出決定所獲得。（注意區別於教條主義，以及完全基於過去經驗進行判斷的固定思維，或者忽視理論指導的區域性經驗主義）。“透明、檢視和適應”是試驗性過程控制的三大支柱，支撐起每一個試驗性過程控制的實施。Scrum採用一種迭代、增量式的方法來優化對未來的預測和管理風險，建立組織響應變化的敏捷能力，從而達致更好的效果。Scrum借鑑了精益思想、時間盒、模組化設計等，並完整地體現了敏捷宣言和敏捷原則。
Scrum是一種通過“檢視-調整”來開發和維護複雜產品的框架，是遵循敏捷宣言和原則的一種流派，整合了3個角色、3個資產、5個事件、5個價值觀，簡稱“3355”。在這個框架中，整個開發過程由若干個短的迭代週期組成，稱為Sprint。每個Sprint的建議長度是1到4周。使用產品Backlog來管理產品的需求，它是一個按照價值排序的需求列表。每個迭代中，Scrum團隊從產品Backlog中挑選最高優先順序的需求進行工作。挑選出的需求在Sprint計劃活動上經過討論、分析和估算得到相應的迭代目標和交付計劃，我們稱它為Sprint Backlog。迭代中每天會有一個站立式的Daily Scrum。在每個迭代結束時，Scrum團隊將邀請業務和利益干係人評審潛在可交付的產品增量。 隨後，團隊進行回顧，不斷改進工作方式。Scrum不僅適用於軟體開發專案，也可用於任何複雜的或是創新性的專案和探索，以及組織變革設計。
什麼是迭代（Iteration）
Iteration英文原意是重複地做同一件事。而Scrum中的Sprint（直譯為短跑、衝刺）概念，是借鑑了XP極限程式設計中迭代產出增量的含義，要求每個時間盒週期內都要有可用的成果出來，並不是狹義地重複任務的意思，而是重複地在固定時間盒內進行PDCA改進迴圈的意思。既然是產品創新和研發，所做的任務一定沒有相同的，但是重複地踐行Scrum各種活動儀式，反覆進行改進，從這個意義上，的確是在Iteration。Sprint要求每個週期的時長是固定的，不會輕易變動，並且希望團隊在和PO確定完短期目標後全力以赴。就像短跑運動員在進行衝刺，因為百米衝刺時你不會總擡頭看成績的。
Scrum中的精益思想
精益思想，有個很形象的比喻：“關注接力棒，而不是運動員”。意思就是要關注價值的儘快流動，而資源利用率是次要的。這就引出精益的五大原則：
價值
價值流
流動
拉動
盡善盡美
下面從這幾個方面分別闡述精益思想在Scrum框架中的體現。
價值
“尊重人”的物件，除了員工、夥伴，還有客戶，不給客戶添麻煩，最大化客戶價值，就是對客戶的尊重。
產品研發最大的浪費是什麼？是做出來的東西沒有客戶願意用！方向錯了，再努力也沒用，“火車跑得快，全憑車頭帶”。
Scrum的目的是“通過迭代和增量，最短時間內交付最大價值”，而精益就在於“精”和“益”，即以最小的成本獲得最大的收益，並堅持持續改善。兩者說法不完全相同，但最終指向同一個第一性原理：什麼都想要的貪念會分散寶貴的精力。作為客戶代表的Product Owner是一個獲得授權的火車頭式的角色，帶領著大家聚焦方向和投入產出決策，牽引著交付和改進，至關重要。讓所有都朝向一個目標努力並不容易，引導(Faclitation)技術能夠有效地提到大家協作的效率。
精益是從系統全域性管理的視角思考的，然而豐田固有的“尊重人”這一點，在後來的各種精益流派實踐中，體現的都不多，更多是從上帝視角將組織當做一個機器來改進。Scrum區別於其他流派，就在於一開始就要解決WHO的問題。沒有角色定義，就像是一群喝醉的猴子在玩拼字遊戲。清晰的角色職責可以避免“龍多了不下雨”的情況。敏捷宣言第一句就是強調“個體與互動”，沒有任何一個其他的敏捷流派像Scrum這樣，將對人的尊重培養和對團隊的打造放在首位。“自組織、跨職能”的提法讓很多組織感到頭痛，因為這與傳統精英主義下，“命令與控制”、“崗位分立”的管理手段截然不同。
在每個Sprint Planning時大家一起選擇本迭代最想要完成的需求條目（PBI），這些條目已經被PO按照價值排序，團隊在最短時間內（一個迭代的時長）交付最高的價值。
Sprint Planning時PO還要與團隊一起定義本迭代的Sprint Goal，顯然那會是整體業務價值的一小部分，這個小目標可以使大家更加聚焦。價值並不等於功能範圍，關注迭代目標而給需求功能範圍留有彈性的餘地，有助於在一個迭代內進行調整，更好的朝向目標前進。
不是隻有功能性需求才有價值。迭代目標也可以是探索和學習，特別是在前幾個迭代充滿市場風險、技術風險的時候，試錯的經驗同樣是寶貴的價值。必要不增值的基礎設施搭建和工具改造，也能夠間接地、長期地為客戶帶來價值，它們也可以進入Product Backlog。
enter image description here
認領後的PBI要進一步梳理和分拆。在拆分的時候，一定要按縱向拆分原則。即使再小的需求，也能夠做到完成對利益干係人可見。好比吃蛋糕，雖然結構上是橫向一層一層的，但吃的時候永遠是豎著切，哪怕再薄的一片，也會包含水果、奶油、巧克力、蛋糕坯等。如果橫向拆分，比如只完成了前端開發的任務，這種都稱為半成品，對客戶沒有價值。
價值流
價值流必須在某個層面是閉環，才能最終給客戶帶來價值。差一點都不能讓客戶滿意。比如今年在雲南某縣，某部門製作了精美的意見箱，但是掛的太高了，群眾無法投遞，也就達不成製作意見箱的初衷，導致價值流中斷在“最後一公里”。這在Scrum中叫”Not Done”，在精益中叫WIP(在製品）浪費。
enter image description here
團隊在Sprint Planning上針對Sprint目標及所選擇的PBI，集體討論出如何完成他們的計劃，這些統稱為Sprint Backlog。任務牆、燃盡圖都是展示Sprint進展的視覺化方式，也可以將任務牆擴充套件成視覺化看板。視覺化管理有助於讓大家對價值流形成共識，關注進展，識別潛在的障礙和瓶頸，從而及時參與改進。這些都是屬於團隊自管理的工具，應該由團隊自己搭建、使用和改進，並開放給所有人。
由於產品研發的價值流不像生產製造那樣是線性系統（流水線），而是非線性價值增值曲線，所以Scrum採用非線性的DoD（完成的定義）來展示出所有必要的工序，以此來驅動質量內建而避免半成品。在實踐中，Sprint更多是時間盒概念，時間一到迭代就結束，所以Sprint沒有成不成功一說，真正要關注的是每個PBI是否完全滿足了DoD，形成了完整的價值流。這樣還不夠，每個Sprint Review是一次向真正客戶和利益干係人展示和獲取反饋的機會，配合技術實踐比如CI或DevOps做到每個Sprint都能上線就更好了，實現更大範圍的價值流閉環，為下一個Sprint的做出調整。
不光一線團隊，跨部門的管理團隊也可以成為自組織和跨職能團隊，來改進整個公司的業務，打通業務-財務-人力-研發-維護-運營全流程，這時CEO/COO就是PO。（甚至黨政一把手也是PO呢）因此，專案群或產品集層面，管理團隊也可以用視覺化的方式來展示公司運營的價值流。甚至藉助故事地圖、影響地圖來識別市場-業務-研發-運維-運營整個價值流的，成為跨多個Scrum團隊的規模化敏捷。
流動
“最短時間交付最大價值”，即儘快地讓一個可用成果真正地完成，中途的障礙越少越好。
朝令夕改的模糊決策、研發內容的複雜性、高資源利用率、僵化的組織結構與流程、人員能力不足，都是提高流動效率的障礙。
實施Scrum首先要求重新定義角色。要有明確的PO來確定優先順序，幫助大家對齊和聚焦短期目標。組建跨職能團隊，消除協作壁壘。甚至鼓勵一專多能，可以進一步，減少等待和協調工作。全新的ScrumMaster角色，輔導大家進一步理解Scrum框架，避免因為概念不清而走彎路。三個角色都為加速流動而努力。
每個Sprint Planning時候拆分PBI，儘量拆小、拆獨立，破解複雜性，破解依賴性，朝著“單件流”方向改進。降低可變性是有幫助的，但不可能每個需求都拆成一樣大小，在這個過程中，計劃撲克™和相對估算有助於團隊儘快達成共識。有的Scrum團隊還引入Product Backlog Refinement實踐，在每個迭代為下一個迭代提前進行需求梳理，避免在迭代開始後再花費時間進行需求討論，從而進一步提升下個迭代的流暢程度。這些梳理活動是一種“整流”活動，大家可以想象北京南站進站口迂迴的圍欄，雖然增加乘客進站的步行距離，但每個乘客進站的時間反而是縮短了。如果大家都搶著進入一個狹窄的入口，反而誰都走不快。
enter image description here
Sprint中承諾的PBI不變也有助於流動速度，這也是一種強行壓制可變性的手段。想象在擁堵的地方不斷有人插隊，最後就是導致整個系統都變得緩慢。對於變化非常劇烈的情況處理，請見後續章節。
管理者容易想到的是管理實踐，往往忽視了“用技術手段解決管理問題”。根據排隊論，系統資源的高利用率反而有害於工作項流動速度，這是反直覺的。在產品研發中，管理層和PO要尊重團隊的集體估算結果，量力而為，避免過大的團隊壓力，比如長期加班導致質量下降和返工，從而提升流動速度，符合俗話說“欲速則不達”。
Scrum強調打造團隊，包括人員能力提升。不同程式設計師的生產力能相差10幾倍以上，如果程式設計師掌握極限程式設計中的Clean Code、Refactoring、TDD，並善於利用版本控制工具和持續整合工具進行主幹開發的話，可以有效減少返工和缺陷，並提高程式碼的可讀性和可維護性，使得系統在專案後期也能易於變更，保持工作項流動速度在一個平穩的高水平上。在精益生產中，有”自働化”的實踐，授權給一線員工發現缺陷有權及時停止生產，也稱為質量內建。在敏捷中，借鑑為持續整合中的”Stop & Fix”實踐，促使團隊及時修復缺陷。
此外，給員工配更快的電腦，去掉上網查資料的限制，也是提高組織的靈活性和順暢度的重要手段，而且簡單可行。
以上這些都是組織領導力和管理層要關注的，各級管理者在扮演ScrumMaster角色。Scrum實踐中，敏捷教練會幫助建立Impediment Backlog或者Improvment Kata，將障礙也可視化出來，發揮群眾的力量，使更多人蔘與到改進中來。
拉動
精益生產中，拉動的表現為JIT（即時生產）實踐，根據客戶訂單情況，下游工序有需要，上游工序才會開工，實現“零庫存”。
產品待辦項清單（Product Backlog）是一個已排序的需求清單，PO通常是根據客戶價值以及投入產出比進行排序。
精益的拉動原則是基於WIP上限的，完成一個如果有空餘產能，就再拉入下一個。Scrum中有2層拉動實踐，其一是每個迭代開始時團隊基於速率來從Product Backlog中拉入一些工作項到Sprint Backlog中；其二是團隊成員基於自己手頭的情況。Scrum沒有在Doing/WIP這一列中繼續細分，而是把權力交給團隊自己決定。要不要分出更多工序階段，抑或設定每道工序的WIP上限，都是團隊自組織和因地制宜的結果。
團隊成員每天從Sprint Backlog拉入新的工作任務，並蜂擁而上（swarming）以儘快完成一個工作項，再認領下一個，只有這樣才能真正地降低平均週期時間。完成的標誌是滿足DoD，而不是Sprint時間盒結束。
然而，在一個3-9人的團隊中，2-3個PBI同時在併發進行是很現實的。拉動是基於WIP上限的，但並不意味著團隊的迭代週期(前面說了，Sprint是時間概念)可以無限縮短。在Don的《Flow》一書，對於批量大小的選擇，實際上需要在交易成本和持有成本中間取一個平衡，並不是批量為一（單件流）才是最好的。採用1-2周的迭代長度的Scrum，其實是從經濟角度最優的設計。另外，如果這個工作任務非常巨大，比如“我想做個APP”這個工作項是不能直接開工的。真正精益和敏捷的做法是要進行拆分，將任務拆散拆小，確保PO和團隊都知道預期產出是什麼，即以終為始，再分配到短的迭代週期中去完成。
enter image description here
盡善盡美
Scrum中有3個PDCA戴明環，通過不斷檢視-調整來消除影響流動的阻礙，這三個反饋環是Daily Scrum, Sprint Review, Sprint Retrospective。
精益製造的“盡善盡美”有3個含義：
使用者滿意 - 改進價值。
無差錯生產且滿足需求 - 改進產品。
企業自身的持續改進 - 改進工作方式。相信任何事物現狀都是假設，都可以去挑戰和主動提高，永遠可以做得更好！
Daily Scrum
在Sprint中，ScrumMaster每天輔導團隊開展Daily Scrum並回答三個問題。特別是每個人要講三個問題：
“昨天我完成了什麼？”
“今天我打算完成什麼？”
“今天我遇到了什麼障礙？”
隨時進行檢視-調整。這是每24小時發生一次的自組織活動，識別阻礙工作項流動的障礙，儘快解決。也是促進團隊協作溝通的一次機會。
Sprint Review
向客戶展示進展情況，會給研發人員一種成就感。用產品Demo來確保真實的進度，即Backlog的進展不是用文件而是實際成果來衡量，正是精益中關注價值和流動的體現。同時儘早地接受真實的使用者反饋以改進產品。
難道產品增量(Increment)必須在迭代結束才能給利益干係人演？紅寶書《Scrum Guide》上只是說這個活動上PO要解釋那些PBI被接受了，哪些沒有。如果PO和利益干係人有可能儘早地驗收甚至上線，為什麼不呢？沒有人攔著啊。如果PBI都已經提前驗收了，這時Sprint Review可以更多成為一個充滿儀式感的活動。善始善終，團隊文化撲面而來，提到團隊凝聚力。
小王子在馴養狐狸後的第二天又去看望它。
“你每天最好在相同的時間來，”狐狸說，“比如說，你下午四點鐘來，那麼從三點鐘起，我就開始感到幸福。時間越臨近，我就越感到幸福。到了四點鐘的時候，我就會坐立不安；我就會發現幸福的代價。但是，如果你隨便什麼時候來，我就不知道在什麼時候該準備好我的心情……應當有一定的儀式。”
“儀式是什麼？”小王子問道。
“這也是經常被遺忘的事情。”狐狸說，“它就是使某一天與其他日子不同，使某一時刻與其他時刻不同。”
儀式感對於生活的意義就在於，用莊重認真的態度去對待生活裡看似無趣的事情，不管別人如何，一本正經認認真真地把事情做好，才能真真正正發現生活的樂趣。
在《奇特的一生》中“柳比歇夫的時間事件記錄法”也值得借鑑。Sprint Review最終統計在各工作項上花了多少時間，作為反饋，團隊可以改進今後做Sprint Planning的能力，儘量更加準確地預測。
Sprint Retrospective
剛才提到的Sprint Review更多是在改善價值和改善產品本身，而Sprint Retrospective則是在改進工作方式，更新團隊約定，使得團隊在下個迭代能更有效的協作，提高工作項流動速度。這個活動是”Kaizen”精神的最深入體現。
enter image description here
所謂磨刀不誤砍柴工，但很多團隊忽視這個活動，或者開成了彙報會甚至批鬥會，結果是雖然每個迭代都有產出，但是一直在低績效水平上徘徊。有效的Retrospective需要優秀的ScrumMaster，利用軟技能引導和教練團隊，本文不做詳細展開。
Scrum超越了精益思想
Scrum體現了精益思想，同時還吸收了其他思想，並沒有將精益生產的看板直接照搬到產品研發中，而是採取了更加務實和開放的態度。Scrum中更多關注“人”，也是為什麼相比精益顧問，Scrum教練和管理者越來越多對教練技術感興趣，更少地制定規範流程，嘗試從內部驅動力和打造團隊來促進企業轉型。
Sprint固定時長的時間盒
筆者年輕時曾組過多年樂隊登臺演(Si)出(Hou)。一般搖滾樂隊最少3-5人，包括主唱、和聲、節奏吉他、主音吉他、貝斯、鼓手、鍵盤等。樂手往往需要兼職，比如主唱兼節奏吉他，貝斯手或鍵盤手兼和聲等，樂隊人員更迭也是常有的事情。大家靠什麼配合才能完成一首歌的演出？答案是“節奏”，例如歌曲是4/4拍每分鐘120拍，發出不同音符的樂器必須在同一個節拍速度上，通過節奏感大家才能形成默契，不必費心考慮什麼時候開始和結束，降低認知負擔。樂曲的音符時時在變，不變的就是節拍速度，每個小節都是一個固定時間盒作為和絃走勢變化的基礎。以演奏《夢纏繞的時候》為例，當大家在主歌之後如約停止演奏，然後心中默數12345678之後，所有樂器又同時開始巨大的轟鳴進入副歌，那種團隊配合協作產生的巨大成就感、榮譽感、幸福感是難以為外人所道的。（題外話：沉浸在音樂中是一種很好的靜心方式。這幾年作為專職培訓講師，登臺演講不怯場，也和那些年的演出經驗密不可分。）
正如著名小提琴家耶胡迪·梅紐因(Yehudi Menuhin)一次寫道的那樣:"音樂是亂中求序的，因為節奏在各行其是中加進了步調一致;旋律使相互脫節的東西前後貫穿;而和絃則從本不相同的東西中找出匹配。"
固定長度時間盒背後有很多科學理論，在各種時間管理方法中都有提到，包括《Get Things Done》和《番茄工作法》。Scrum通過固定時長時間盒作為迭代的基本單位，Sprint也稱為Scrum的心跳。團隊就像一個人，脈搏太快太慢都不好，時快時慢更不行。這樣設計的用意：
其一，降低所有人對活動儀式的記憶負擔，什麼時候計劃、什麼時候演示都不用每次商量了，到點來就行。
其二，清晰的節奏感確保大家的參與和目標一致。
其三，時間是對大家都公平的，固定時長，多個迭代的單位時間團隊績效才能進行對比。每個迭代完成的故事點稱為速率，可作為生產力度量進行檢視-調整。下個Sprint週期計劃時看看歷史速率，就可以知道團隊能承受多少工作，不要多也不要少，有助於提高今後做計劃的能力。
其四，避免像流水線一樣一個勁兒地壓榨團隊承擔更多工作，團隊的單位工作容量總是有一個相對穩定的數值，速率也就是團隊的每個迭代的WIP上限。定期停下來，擡頭望望天，緩口氣。改進措施沒有立竿見影的，需要時間的檢驗，也要考慮交易成本，所以固定長度的時間盒更多是為改進而服務的，而不是束縛工作項的牢籠。
常見的Sprint週期一般選擇1-2周，理論上並沒有最小的Sprint長度限制。一天的Sprint長度是我在產品開發中看到過的最小長度。在培訓時有時可以用0.5天作為Sprint的長度。然後，一個Sprint可以稱為Sprint的關鍵是它必須包含4個活動。
有人說“有了單件流就不需要迭代了“，這是一種誤解。單件流在生產上是指通過標準化，使每個工序耗時趨於一致，使得批量大小可以降低到1。這對智力型工作的管理有指導作用，但是，智力型研發工作的內容和顆粒度都不相同，即使通過拆分，顆粒度（工作量）仍然會有幾倍差距。而且前面說過，WIP為1從經濟角度上並非最優選擇。Scrum站在時間的維度上，基於每個迭代中團隊的速率（工作容量）大致穩定的前提，每個Sprint承諾的工作總和可以看做是一個”單件”，來達到某種意義上的管理標準化。
線性看板與非線性DoD
傳統瀑布式過程以工序作為專案的不同階段，比如”分析-設計-開發-測試”。弊端已經說過了，產品本身、研發的過程、團隊協作，這幾方面都不是線性系統，而是複雜自適應系統（CAS)。其特點是，系統是一個非線性網狀結構，存在大量迴圈往復的路徑，從來沒有過任何一個專案不是在那幾個階段之間反覆震盪的。用線性方式為線性系統建模是存在缺陷的，雖然意圖是好的，試圖簡化系統模型。
看板方法仍然在用二維線性方式建模，卡片在看板泳道的一個階段流入下一個階段，這對製造業流水線沒問題，但是對複雜的產品研發有時候會存在矛盾，很多工序內容在看板上體現不出來，而且人員共享關係也很難體現，畢竟是二維的形式。比如，Code Review與功能測試孰先孰後不一定，不同的軟體看板專家對“任務卡片能否倒流到上一階段”這個問題存在不同答案。另外，看板上一般都會分為”開發、測試“列，雖然這是從工序來劃分的而不是職能劃分的，但某種程度上