上面一篇介紹的原則, 都是比較小的的原則, 接下來的原則, 基本上都是一精深的學問, 市面上都有很多書在說明, 因此只針對 LeSS 所需要的部分加以解釋

(7) System Thinking

現在世界變化快速, 並且有很多事情是想都想不到, 像是 CVOID-19 所帶來影響, 你很難事先規劃, 也很難用過往的知識來處理. 那要怎麼辦呢? 在 1999 年Dave Snowden 創造了 Cynefin 框架, 當你遇到問題時, 可以用這個框架來判斷你遇到問題的種類, 然後 Cynefin 框架就會推薦你該用哪種類型的解法.

我們現在遇到的問題就是屬於 Complex 類型的問題. 情況不斷變化, 很難做出什麼預測, 也沒有所謂的正確答案. 你只能不斷探索, 感知其反應, 然後做出相對的因應. 需要有耐心, 因爲這是要時間來思考, 運用群體的力量來找出解答.

圖片來源: https://thinkinsights.net/strategy/cynefin-framework/

這樣的狀況就很適合系統思考 (System Thinking) 來幫助你. 系統思考是以整體、動態去思考問題的一種思維模式, 幫助你將複雜的動態系統化繁為簡. 一般我們會利用 Causal Loop Diagram (CLD) 來進行系統思考. 但 CLD 這個東西不在我們這次討論的範圍, 大家可以自行去翻閱相關書籍來了解.

系統思考可以帶給我們以下幫助：

a. 觀察系統動態

可以利用 CLD 來描述目前系統的動態, 讓大家了解系統的全貌是怎樣.

b. 理解心智模型

從這個模型中, 觀察出我們內心深根蒂固的想法. 例如上圖中, 是有關於工作一直進來後團隊的處理狀況. 在最上面的圓圈中, 我們可以發現當團隊接越多工作後, 管理層會覺得團隊能力很好, 應該可以再多接一些工作. 這樣的一個想法聽起來合理, 但是不是錯誤的假設呢?

c. 找到根源

當我們找到一些內心思維後, 便可以來討論為什麼會形成這樣的想法, 來了解問題到底是怎樣發生的. 這時候可以利用 5 why, 因果圖, 魚骨圖等等, 來發現真正的 root cause 是什麼.

例如: 為什麼團隊做很多就可以多給他一些事情去做? 可能他們過往能力很好, 產出很有品質, 所以就會都給他一點. 那為什麼過往做很好, 在同時做很多事情時還可以做很好? …. 可以這樣一直問 why 來找出可能的盲點.

d. 發現局部優化

所謂局部優化, 通常都是大家想把自己的事給做好, 導致整個系統的產出還是下降. 動機是好的, 但是方向卻是錯誤了. 這樣的事情在日常中常常發生, 可是卻很難發現, 因為本意都是好的. 通常需要有人可以指出, 並且大家有開放的思維, 願意接受各種想法, 然後利用實驗來看看是否新方法有幫助. 當然啦, 根據系統思考的名言：今日的問題產生於昨日的解決方案. 所以你需要不斷重複這樣的過程, 不段實驗調整, 才有機會能讓系統漸漸好轉.

LeSS 在很多地方都有落實系統思考的想法, 例如：

a. Feature Team

由跨職能成員所組成, 希望可處理大多數的需求. 這就是希望你能看的是整體, 避免因為只做單一元件或功能, 在視野上會受限.

b. Sprint Planning

在第一部分時進行時, 會請所有成員或團隊代表參加, 有相關時在第一時間就能提出. 在第二部分時, 需求如果和一些團隊有關時, 就一起來討論, 讓大家的考量就有被照顧到

c. Overall Sprint Retrospective

除了每個團隊自己召開回顧會議外, 也讓所有團隊一起反思, 一起思考整體的問題, 一起考量對整體有幫助的解法.

(8) Lean Thinking

精益思想是近代很重要的管理方法. 它的起源在精益製造, 也就是從豐田製造那邊來的. 當時是二次世界大戰後, 日本是戰敗國, 整體國力不如美國. 那時候美國福特汽車以大批量生產的方式, 統治全球整個工業生產模式. 那時候豐田為了能和福特競爭, 所產生出來的作法. 藉由小批量生產, 高品質, 低浪費, Just in Time 等作法, 獲得很大的成功.

因此, 很多人就想把這樣的思維和做法, 應用到自己的領域, 軟體界也不例外. 那軟體這邊會怎麼做呢? 首先, 很多人都會想到是否是消除浪費, 或者是那些看板管理工具等等. 在 The Toyota Way 一書的作者提到：

Experienced leaders within Toyota kept telling me that these tools and techniques were not the key. Rather the power behind TPS is a company’s management commitment to continuously invest in its people and promote a culture of continuous improvement.
註：人才是重點. 管理者願意持續投資培育人員, 以及持續打造改善文化. 這才是精益思維成功的關鍵

將精益思想簡單視為看板, 限制 WIP和 安燈系統(ANDON)等工具, 就如同將民主簡化為投票一樣. 投票這個作法是好的, 但是要能有民主思維以及公民意識這就困難很多.

所以 Bas 和 Craig 認為精益思維的重點在於 a. 尊重個人, b. 持續改進. 其中 b 這點我們在第 (10) 中描述.

在尊重個人這的面向上, Bas 和 Craig 認為可以做這些事情：(詳見Scaling Lean & Agile Development 中 System Thinking 一章的內容)

a. 給員工做有價值的事
不要強迫員工作浪費的事情
不要讓員工等待
不要讓員工超過負擔的工作
不要一廂情願強加事情給員工

b. 經理幫助員工成長
讓經理們當老師, 而不是主管
經理教導員工如何分析問題, 讓他們自己找到改進方法
經理們分享自己多年來在工程和問題處理上的經驗
激發員工改變, 而非要求其改變

c. 讓大家變成一個團隊
讓團隊人數不要太多
盡量一起合作, 而非各做各的
經理制定目標, 團隊自己思考和決定如何達成目標

LeSS 在這些面向上都有展示尊重個人的想法：

a. 自己選擇團隊

在成立 Feature Team時, 先由經理們制定分組條件, 在這樣的條件下, 由團隊成員自行選擇要和誰成為一個團隊, 尊重自己的想法.

b. 沒有主管角色

每個 Feature Team 沒有主管的角色, 團隊成員要自行決定如何做事情.

c. Feature Team

人數限制在 5 – 9 人, 讓凝聚向心力或是溝通可以比較容易一點.

(9) Queueing Theory

排隊是一件很常遇到的事情, 搭車需要排隊買票, 程式中要處理外界的需要需要放到 queue 中排隊處理. 在這個過程中意味需要等待, 並且也代表有些關鍵資源, 目前已經過載, 很難處理這麼多事情, 因此如何提高效率, 手法之一就是減少排隊現象, 讓關鍵資源的排隊現象沒那麼嚴重. 所以排隊理論對很多狀況來說, 是非常重要的理論基礎.

根據維基百科的說明, 排隊理論 (Queuing Theory) 是研究服務系統中排隊現象隨機規律的學科, 它被廣泛應用於電信, 交通工程, 計算機網絡, 運輸等, 各項資源共享的隨機服務系統. 那對軟體產品開發來說, 可以被拿來應用嗎?

其實在軟體產品開發中也是有很多排隊等待的現象, 例如：

a. 要投資的產品或專案
b. 產品中要被開發的新功能
c. 需求文件等待被開發人員設計
d. 設計文件等待被撰寫
e. 完成的程式碼等待被測試

除了這些之外, 還有些共享的資源或珍貴的資源, 也需要排隊等他有空. 例如：共用的畫面設計師, 昂貴的測試機器或環境等等.

根據排隊理論, 這些有排隊現象的隨機服務系統, 通常會有以下特性：

a. 利用率和排隊規模非線性關係

很多時候老闆以為要把你利用到 100%, 你才是真的很忙. 如果是 70% 的狀況, 你應該還有餘力. 但是你想想高速公路塞車的狀況, 只要有 50% 的車陣, 整個高速公路的速度就成指數下降. 同理, 你處理事情的品質和時間也是如此.

b. 清理排隊比造成排隊要花更多時間

由高速公路塞車你可以知道, 要等到不塞會需要更多時間.

c. 排隊形成的原因很隨機

需求或是 bug 進來的頻率也是很隨機, 或者需求被描述的品質也是每次都不一定. 寫程式或是測試也有同樣的隨機性.

那我們可以怎樣處理排隊問題呢? LeSS 的作法會是這樣的：

a. 改變系統以消除排隊

a.1 Feature Team：將所需職能都放進來, 大家以搭擋編程方式一起工作, 而不是一個角色傳過一個角色, 讓等待某個角色的排隊消失

a.2 持續整合和持續部署：每次開發一些代碼後, 立即使用持續整合, 確認是否對其他造成影響. 當功能開發完畢後, 可利用持續部署, 自動驗證並放到 staging 或 production. 減少運維團隊的負擔.

b. 減少可變性

b.1 利用 PBR 將需求釐清：Sprint 之前頻繁利用 PBR 確認要做的功能是什麼, 並找出驗收條件. 可以避免在開發時期有太多意外的驚喜, 開發完畢後也比較接近客戶想要的

b.2 Feature Team：團隊成員固定, 減少彼此適應的時間.

c. 限制排隊的長度

c.1 利用 PBR 將需求釐清：需求太大或是不清楚, 往往會導致做不完, 進而讓各個部分都在排隊. 因此 LeSS 希望花時間在源頭處理好, 後面就可以讓排隊程度不會太嚴重.

(10) Continuous Improvement Towards Perfection

敏捷之所很會有彈性, 可以因應各種突發狀況, 最主要的原因是它利用 Sprint, 先做一點, 得到回饋後, 調整再出發. 因此可以越來越好. 敏捷一開始不是要做到完美, 而是藉由 PDCA 的手法, 持續改善來邁向完美. 所以怎樣持續改善, 也是 LeSS 所努力的. 在這邊介紹常見的作法：

a. 實地查看 (Go See)

在 Toyota Way 一書中多次提到實地查看, 所有人尤其是經理們, 不應該把時間花在座位上或是會議中, 或是只是寫寫報告回回郵件. 而應該是利用時間去考清楚實際狀況, 盡最大可能地親身接近實際工作的最前線, 去了解問題和探討可能改進的方法.

b. 改善的文化 (Kaizen)

Kaizen 是思考模式, 也是實踐方式. 它通常是這樣進行的
1). 選擇願意要嘗試的團隊, 直到他們徹底掌握該技巧
2). 不斷地進行試驗, 直到找到更好的方法, 然後把它視為臨時的標準
3). 一直重複上述動作

首先, 學習是需要時間和耐心, 不太可能一下就學會, 需要耐心, 不要一下就遺棄這些新學的東西. 需要照表操課一段時間.

在武術中有一種漸進的學習方法：

守：先遵守規則直到充分理解原理, 並且已經養成習慣.
破：對規則進行反思, 尋找出規則的例外, 並打破規則
離：在精通規則之後, 就不被規則所束縛, 而是抓中其精髓, 讓行動符合其精神

這個精神就跟Kaizen 是一樣的.

然後記得注重分享而不是強迫. 豐田提倡橫向學習 (yokoten), 知識的傳播不該是從中央從上向下推廣. 應該像樹木接枝一樣, 從不同地方匯集進來, 讓這個過程是有機演化的.

c. 實踐社群 (Community of Practice, COP)

實踐社群是由一群人所組成, 這群人對於某件事情有共同的關注與熱情, 並且會定期聚會, 互相討論學習, 如何可以做得更好. 它可能會利用 Coding Dojo, Code Retreat 的方式, 非某個人教導, 或是某一個大神從頭帶到尾, 而是大家都要貢獻和投入的方式來進行.