所謂的精益思想的價值和原則非常多，這里引用ThoughtWorks同事Jonny Schneider即將出版的《Understanding Design Thinking, Lean,and Agile》诵棵， 通過日常軟件開發(fā)實踐來補充這些看起來很虛的價值和原則两蟀，以此推廣“精益”成為更好的軟件開發(fā)指導(dǎo)思想。這是下篇碧注，上篇在這里嚣伐。
我們來簡單回顧一下上篇：
價值一：學(xué)習(xí)和適應(yīng) 優(yōu)于 分析和預(yù)測
- 通過實踐驗證假設(shè)，而不是分析和計劃
- 延遲決策到最后一刻
- 刻意練習(xí)科學(xué)思維
價值二：賦權(quán)的人更快樂并容易取得更好的成果
- 定義清晰的目標(biāo)应闯，信任團隊并給予自主去取得成果
- 去中心化決策
價值三：成果優(yōu)于輸出
- 衡量交付的價值纤控，而不是做了多少工作
- 明確價值并經(jīng)常度量
本篇將繼續(xù)講述價值四和價值五。
價值四：管理流動優(yōu)化價值
- 減少批次大小
- 管理隊列
- 交付速度
- 減少浪費
- 響應(yīng)客戶的需求 優(yōu)于 創(chuàng)造庫存
減少批次大小
如果要我說軟件開發(fā)管理中最重要的工作是什么碉纺，我覺得應(yīng)該是減少批次大小船万。
軟件管理中存在很多問題刻撒，比如需求不明確、需求易變耿导、開發(fā)估算不準(zhǔn)確声怔、難測試、上線后發(fā)現(xiàn)沒有真實價值等舱呻。
這些問題其實都可以靠減少批次大小來解決醋火，我一般建議把User Story分解到1~2人天(當(dāng)然還是要用故事點的方式，不能直接用人天來估算)箱吕，這樣的好處是：
- 故事小對應(yīng)的需求范圍也小芥驳，比較容易明確；
- 又因為需求小茬高，變了也不可惜兆旬；
- User Story小更容易暴露開發(fā)過程中的問題，比如把計劃一天的任務(wù)分派給新人做怎栽，即使超出原計劃的100%工作量其實也就是多了一個人天丽猬，這樣團隊可以及時干預(yù)；
- 只有一兩天的工作也更能消除“一天完成90%熏瞄，剩下的10%需要一個星期完成”的進度報告問題脚祟。或者是一個人同時做很多事情强饮，但都沒法交付由桌；
- 需求小也更容易測試，能更快上線給真實用戶邮丰。
微服務(wù)架構(gòu)更加強化了減少批次大小的訴求和價值沥寥，達到更小的需求、更快的響應(yīng)柠座、更穩(wěn)定的交付流速。
管理隊列
批次大的時候片橡，一個人好像只在處理一個事情妈经。但實際上人腦容量有限，還是會把一件大的事情分解成多個小事情做捧书，只是無意識的做而已吹泡。Scrum的管理方式比較粗暴，看上去只有Sprint backlog一個隊列经瓷，因為在迭代會議的時候把事情都分配給開發(fā)人員了爆哑。所以對于Scrum這樣的管理框架來說看不到什么隊列，這樣有什么問題嗎舆吮？
因為人腦的局限揭朝，事情總是會溢出在外面队贱，實際上就造成有個隱形的隊列存在，只是沒人刻意去管潭袱，這就造成有些人盲目的忙柱嫌，有些人井井有條的干活，純粹看個人意識屯换。
隱形任務(wù)隊列的壞處：
- 任務(wù)間穿插编丘、相互影響效率。一個人最佳的工作效率產(chǎn)生于同一時間聚焦做一件事情彤悔。但由于事情過大嘉抓，看起來是在做一件事情，其實是還是處理多個事件晕窑，然后思路在不同的事情上面跳躍穿插抑片，造成做事效率低下；
- 不分任務(wù)輕重緩急幕屹。其實很多看似緊急的事情蓝丙，都是因為一開始不做，到需要了才開始做就沒時間了望拖，搞得壓力很大渺尘。比如客戶突然過來問XXX事情進行得怎么樣了，想明天看一下说敏。你心里立刻開始跑馬鸥跟，“你們咋不早說啊，這事還沒開始做呢盔沫！” 但從客戶的角度講医咨，這個事情在兩個星期前就安排了啊，而且說了很重要架诞。但因為隊列是隱形的拟淮，大家都只是腦子過一下，或嘴上說一下就過去了谴忧，全靠個人意識去處理很泊。
- 掩蓋問題。一個人或團隊手上一堆事情沾谓，然后有些出現(xiàn)了問題阻塞進展委造，但因為是隱形隊列，很容易導(dǎo)致大家都“忽視”問題均驶，直到所有的任務(wù)都遇到同一個阻塞點昏兆。隱形的隊列越大，掩蓋的問題也越大妇穴。這個問題特別嚴(yán)重也最常見爬虱，我們經(jīng)常會聽見客戶說自己沒有問題隶债，因為表面上大家都在做開發(fā)沒遇到問題，只是到了一個月交付的時候拖延一個星期才能交付出去而已饮潦，已經(jīng)是習(xí)慣了燃异，這也很正常啊。但是稍微聊一下就會發(fā)現(xiàn)需求不明確继蜡，溝通不順暢回俐，缺乏自動化測試，質(zhì)量不穩(wěn)定稀并，手工運維經(jīng)常出點“小”問題等等仅颇，這些問題其實每天都在發(fā)生，但都可以一直掩蓋到最后一刻才暴露出來碘举。
所以首先應(yīng)該把任務(wù)隊列顯性化忘瓦，要用團隊的能力和意識來管理隊列，而不是讓個人去隨便搞引颈。
然后才是隊列管理技巧耕皮，比如優(yōu)先級調(diào)整，任務(wù)依賴關(guān)系管理蝙场，阻塞點識別和清除凌停。
在精益里面有個很重要的原則，叫限制在制品數(shù)量售滤，意思是要嚴(yán)格限制正在進行的任務(wù)隊列大小罚拟，這樣就能很容易的識別阻塞點，及時處理完箩，并且更容易控制交付流速赐俗。
交付速度
在講TDD特有價值的時候我提出其中了兩個：
- 質(zhì)量
- 可維護性
但怎么衡量這兩個指標(biāo)呢，尤其是可維護性弊知。我覺得可以歸到“交付速度”一個指標(biāo)上阻逮。我們不把修bug當(dāng)做價值而是當(dāng)作浪費，這樣質(zhì)量差的軟件開發(fā)秩彤，必然導(dǎo)致交付資源會被修bug擠占夺鲜，從而影響交付速度。
軟件的可維護性也會體現(xiàn)在交付速度上呐舔，做的好的軟件交付速度會越來越快。因為該做的基礎(chǔ)工作都逐漸完善慷蠕，開發(fā)人員的領(lǐng)域知識和開發(fā)技能也逐漸提高珊拼。
然而很不幸的，能逐漸提升交付速度的團隊很少流炕，理由往往是需求越來越復(fù)雜啊澎现，以前都沒提有這樣的需求現(xiàn)在要大改啊什么的仅胞。而且沒人正在度量交付速度，所以只是開發(fā)人員和客戶都抱怨罷了剑辫。
減少浪費
以前西方流行的精益觀念認(rèn)為“減少浪費”是精益思想的精髓干旧，然后有非常全面的識別和消除浪費的方法。
我覺得減少浪費是精益思想的很小一部分妹蔽，就像我們想增加收入要做開源節(jié)流椎眯。不能認(rèn)為節(jié)流能增加收入就當(dāng)做主要手段用，導(dǎo)致影響開源胳岂。但很不幸的是節(jié)流比開源要容易很多编整，所以很多企業(yè)在危機時刻很容易選擇節(jié)流而導(dǎo)致開源不利。
比如只從業(yè)務(wù)功能角度講乳丰，搭CI/CD所花的時間是浪費掉的掌测，因為沒有直接產(chǎn)出業(yè)務(wù)價值。
減少浪費的觀念確實非常有用产园，能有效指導(dǎo)消除不必要的工作汞斧。
響應(yīng)客戶需求 優(yōu)于 創(chuàng)造庫存
我發(fā)現(xiàn)開發(fā)團隊很喜歡創(chuàng)造庫存，有一些原因：
- 庫存帶來安全感什燕；因為開發(fā)團隊總是被客戶挑戰(zhàn)粘勒，手上拿幾個已完工的需求會覺得到時候有貨交差會很好。
- 庫存里的東西不用馬上驗證秋冰，自己認(rèn)為總是對的仲义；
- 庫存里面堆什么可以自己決定；人總是會傾向做自己熟悉或感興趣的事情剑勾，而總是響應(yīng)客戶需求的話可能會被迫出舒適區(qū)埃撵。比如很多業(yè)務(wù)系統(tǒng)一上來就做個用戶管理模塊旬盯，雖然看起來這些基礎(chǔ)模塊是必須的行剂，但在一開始的時候?qū)蛻魳I(yè)務(wù)人員來說真的是必須的嗎，如果只有一兩個用戶明顯可以工作嫩海，那硬寫在代碼里就可以了捂刺。
- 管理者不想讓開發(fā)人員閑著谣拣；盡管當(dāng)前沒有明確的客戶需求，管理者為了不讓開發(fā)人員閑著族展，也會要求做一些有的沒的需求森缠，號稱以后用的上。
- 客戶不愿意頻繁接收需求仪缸；這種情況多是因為客戶接低質(zhì)量的需求接怕了贵涵，所以拒絕頻繁接，以為讓完工的軟件在庫存里多呆一會質(zhì)量會自動提高；第二是可以一鼓作氣去應(yīng)對低質(zhì)量的需求宾茂，集中時間處理麻煩事瓷马。
敏捷宣言用了很大的比重來強調(diào)擁抱變化響應(yīng)客戶需求，很好地改變了軟件開發(fā)團隊和客戶之間的信任關(guān)系跨晴。但是并沒有什么方法很好的去響應(yīng)客戶需求欧聘，要不然Scrum這種固定時間盒的方法也不會大行其道了。
精益的拉動式流管理是完全面向客戶的端盆，利用客戶需求驅(qū)動團隊工作怀骤。而且只有需求交付到客戶手上才算是完成了，使得軟件盡早產(chǎn)生業(yè)務(wù)價值爱谁，這也是MVP思想的來源晒喷。
價值五：質(zhì)量是結(jié)果而不是活動
- 內(nèi)建質(zhì)量
- 持續(xù)學(xué)習(xí)和改進
- 追求完美
內(nèi)建質(zhì)量
內(nèi)建質(zhì)量就不多說了，是我們倡導(dǎo)的實踐口號访敌，只是需要配合質(zhì)量度量和持續(xù)改進凉敲，不然就只是口號了。
持續(xù)學(xué)習(xí)和改進
除了交付客戶所需的價值寺旺，對我們來說更重要的是團隊個人能力的提升爷抓。因為軟件交付給客戶價值后，對我們的價值(錢)也就結(jié)束了阻塑，唯有團隊個人在交付的過程中不斷提升蓝撇，才能提升公司的整體價值和競爭力。
在敏捷管理里面設(shè)置回顧會議以支持持續(xù)改進陈莽，而且更關(guān)注問題和解決問題渤昌。為什么要等一個月或兩個星期才做一次回顧會議呢？ 固定時間走搁、固定任務(wù)独柑、做固定的事情好處是能有一種儀式感，容易協(xié)調(diào)不同人的時間和工作內(nèi)容私植。但因為反饋周期太長忌栅，算不上持續(xù)，只能說是斷斷續(xù)續(xù)的學(xué)習(xí)和改進曲稼。
其實最好的學(xué)習(xí)和改進機會是做到on demand索绪，發(fā)現(xiàn)問題及時處理問題，如果處理不了及時提出來引起團隊的注意贫悄。另外每日站會和每日code review都是固定的時間點瑞驱，可以用來做學(xué)習(xí)和改進。
學(xué)習(xí)和改進的內(nèi)容不僅僅是軟件代碼窄坦、架構(gòu)設(shè)計钱烟、需求質(zhì)量晰筛，還有協(xié)作方式、甚至座位安排拴袭、客戶對接方式、價值排序原則等曙博。
追求完美
可能對于一個商業(yè)組織來說拥刻，追求完美是最正確又是最錯誤的事情。因為很容易陷入閉門造車父泳，導(dǎo)致投入產(chǎn)出比失衡般哼，造成虧損。
但精益思想并不是一個點惠窄，而是一組蒸眠。我總結(jié)的精益思想的哲學(xué)是以客戶為中心，持續(xù)自我改善杆融，追求長期利益(完美)楞卡。
每個人或組織心中應(yīng)該有個對“完美”的定義，以此為愿景進行長期可持續(xù)追求脾歇，但由于是企業(yè)蒋腮，所以要以客戶為中心。當(dāng)然基礎(chǔ)還是富有激情的個人在每時每刻進行持續(xù)學(xué)習(xí)和改進藕各，以達到個人的完美池摧。
文／ThoughtWorks 吳雪峰
