南方的三月，乍暖還寒，我決定暫緩一下那匆匆的腳步，給自己的的心靈放個假，參加為期兩天的精益研發管理培訓課程。一方面可以充充電，另外也可以讓心靈得到舒緩，畢竟和忙碌的工作相比，再緊張的學習生活也是“舒服和休閑”的。
寫在前面的話
對待培訓，我的態度是，放空身心去學習，獨立思考去吸收。不管你對于某個主題有多少認知，既然決定了要去參加這個或者那個學習的過程，那么就該先放下自己的戒備，放松心態去擁抱。學習的過程當中，可以選擇質疑，可以提出自己的看法，獨立思考吸收自己覺得對的有用的部分。認識的牛人越多，越常常感慨自己學得不夠多，也常常感慨了解這一點太晚，現在時間與我就是個稀缺資源，所以不得不像海綿一樣去汲取呀。這篇作為培訓后感，不會涉及太多的培訓內容，更多的是個人對培訓內容的一些思考?？偠灾?，這個課程對我有用，所以也推薦給你。但具體你該不該去參加，還是要獨立思考的。吳博的風格是，溫和的娓娓道來，講的時間占比很高，對學生比較照顧，各種安排都很舒服。我原本預想著體力上會很累，其實并沒有。
本課程講了什么？
具體講什么，有心人可以去找一下吳穹博士發的相關的朋友圈。我這里就簡單地用吳博的培訓大綱分享下。大綱中的很多關鍵字，相信各位都并不陌生，但如何將這些概念融匯在精益的理念里闡述出來，在參加培訓前，我是有些小疑問的。好在，兩天如行云流水般的課程結束后，我的疑慮就沒有了。
為什么會參加？
培訓很多，很多都想參加，時間和機會都有限的情況下，沖著講師來的。知道吳博是在兩年前，有那么一位前同事，總是在轉各種看板的文章，其中就不乏來自吳博的文字。認識吳博是在一年半前的敏捷之旅，當時他談的關于軟件開發擁堵的話題，本人很有興趣。只可惜當時的時間比較短，想要和講師交流的人又很多，所以接觸還是很有限啦。再后來，我加入了精益創新中國社區微信群，群里挺多牛人的，作為群主，吳博給我的印象是“慷慨”，特別大方的分享各種資源，特別豪氣的發紅包。我是個對紅包不那么執著的人，但還是會為錯過了吳博的紅包感到心痛。哈哈。所以這次的兩天課程，我不打算錯過，因此我就來了。
大綱中我感觸比較深的幾點內容：
敏捷和精益
雖然，我們公司算得上國內實施敏捷相當早的一家公司，但我接觸敏捷很晚。前面這半句話不是我自己瞎說的，是TW的XR跟我提到的，原來敏捷圈的男神也在我們這“潛伏”過相當長的一段時間。但當年因為自己在另外的項目，加上那會個人的重心不在這塊，我是到了2014年才開始比較系統的接觸敏捷的。這里也要特別感謝下Daniel Teng，他的三天CSM課程狠狠地幫我刷新了三觀。為何說狠狠地，上過他課程的都知道，那是個相當自虐的過程。接著天時地利人和，當時的團隊領導給了我們相當高的自由度去實踐敏捷，因此后來很長的一段時間，我和其他小伙伴們就在組織內心甘情愿的做著推動敏捷的工作。再后來，因為工作的轉變，我和敏捷的距離又遠了那么一點點。直到最近，我的感受是，走到哪里，都有人在說敏捷，這個詞從IT圈火到了各個領域。已經有好幾撥人在跟我打聽敏捷相關的培訓，看到的各種咨詢機構的預測性文章，也是反復強調Agile。
敏捷是一種價值觀，我個人很認同這個說法。就像吳博說的，這個詞大概和健康一樣，單獨看都很正確，放哪都挺合適的。人人都想要健康，人人通往健康的路卻不一樣，畢竟每個人的體質差別很大。所以為了更好地實施敏捷，又產生了各種給予具體指導的框架。要采用哪一種，或者哪幾種，那么就要去挑選或者剪裁。拿來主義在軟件開發的場景是不適用的。因為這個領域要解決的問題很復雜，很多不確定因素，很多人的因素。關于人的因素，我傾向于帶著更開放的態度去看這件問題，畢竟每個人生而不同，即使每一個人的出發點是好的，要在一起合作也不簡單。
至于精益，它強調快速試錯，其實軟件開發過程就該是如此，對于不確定的需求，除了試，似乎也沒有更好的方法。至于對精益的了解，不得不提到本人鬧的一次笑話。前同事跟我提不如咱們也試試kanban吧，我說是豐田的kanban嗎？他。。。我僅有的精益知識來自于OM（Operation Management）課程，當年老師推薦了各種讀物，其中不乏帶著精益這個關鍵字的書， 比如《精益解決方案:公司與顧客共創價值與財富》。正因為如此，把精益的理念放到IT領域，對我來說是新鮮的。鬧出當年的那個笑話后，我讀了《The Lean Startup》，但除了精益創業，我也想更多的了解精益管理，所以這次的課程對我來說吸引力很大的。
需求不確定性管理
做了很多年的需求工作，我的一個感受是，成為好的需求工程師也是個試錯的過程，因為存在太多的不確定性因素。一個好的需求工程師，就是盡量將不確定控制在一個相對小的范圍，將相對確定的內容傳達給后續的團隊。沒法去界定這個小到底該多小，但這個范圍有多大，確實和需求分析師的能力有很大的關系。這個能力的建立過程可能很艱辛，也可能很漫長，可能是你自己跌跌撞撞摸索出來的，可能你從他人失敗的教訓中學習到的，當然也可能有悟性極好，你相信的就是對的，比如喬布斯。
敏捷和精益的方法，很好的將需求分析工程師從這種艱辛的工作中解脫了出來，不敢說是全部，至少是部分吧。大家放下堅信做出來的功能一定有人用的神話，回歸到一個更理性的角度去看待軟件過程這件事。與其苛求需求分析工程師一定要對，不如大家一起接受需求的不確定性。當然也不要因此走到了絕對的反面，覺得需求分析師的能力就不重要了，而是用一些方法來控制這個不確定性。我看到的各種敏捷方法無一不是在為此而努力的。比如用戶故事，產生的前提就是用冗長的需求文檔來界定到底該做什么并不科學。User Story夠簡短，可以在人們的思考和記憶力更容易接納的范圍內闡述需求。比如各種Scrum會議，可以讓團隊充分溝通，明白短期，中期和長期的目標是什么，將理解差異的不確定性盡量減少。當然，敏捷從來不是說有用戶故事就夠了，如果你對此有疑問，課程中會就此展開探討。
這次的課程前，我對實例化需求的作用是有些疑問的。很早就看完了《Specification by Example》這本書，并嘗試在工作中應用，但我發現加了一些實例后，相對于用文字展現需求，例子在某些時候更便于和用戶達成共識，便于測試人員了解某些情況的expected result，甚至可以幫到程序員理清實現的邏輯關系，但卻無法做到替代需求文檔。對于實例多大程度上可以幫到自動化測試，我的疑問更大。我的理解是，例子可以幫助復雜業務邏輯的闡述，但需求本身并不只有復雜的業務邏輯，所以實例更多的只能是一個好的補充吧。課程中，吳博對此的闡述，讓我的疑問釋然了。下圖來自課件，版權不歸我 :-).
測試
對這個話題的感觸是很深的，不少人都說，測試這個環節就是一個necessary waste，這么多年大家都接受并允許的一個存在。可是當前的趨勢似乎是，減少專門測試人員，讓開發人員自動自覺保證質量。這個愿望是美好的，道路卻顯然是曲折的。下面幾個觀點，來自我的筆記：
- 與其談自動化測試，不如談分層自動化。
- 先了解團隊的成熟度情況，再看如何應用自動化測試。
- 自動化測試是防彈衣，不是解決所有質量問題的靈丹妙藥。
- Pre-production的成本越來越高，難以負荷，與其追求流程上的完美防止出錯，不如多考慮灰度測試。
協作不確定性
為了更好地協作，所以需要可視化?？梢暬梢园褑栴}透明化，可以觸發共情。怎么說呢，做了需求工作這么多年，我常常發現，即使是一個需求的重要性，從用戶傳導到需求分析師，再傳達到團隊的相關人員，這都不是一件容易的事情。將所有信息寫在郵件里，不管你寫的多么直白，后續的各種相關人士也可能是不知道的，因為他們可能根本就不看郵件。開發人員不愛看文檔，也不愛看郵件。因為改變總是突然發生，我以前的一個常用的做法是，會集體溝通，也會分別去和各個party溝通，確保大家都明確了需求的優先級或者需求的變更。這種方法的好處立竿見影，但溝通成本巨大，一個字累，而且無法適應scale up，因為一個人的時間是有限的。好在Kanban可以很好地可視化這些東西。我覺得Scrum中的站會強調的也是相同的作用，創造一個好的可視化環境。
精益看板方法是可視化的重要武器。但也不要把看板做成任務板，因為那不是價值的有效流動。鑒于本人并沒有kanban的實踐經驗，這塊就不贅述了，但這理念我是認同的。掩蓋問題是不能解決問題的，可視化讓大家看到擁堵，讓LD參與排優先級，讓大家回歸到理性的合作方式，這才是通往成功交付的可循之路。
吳博此處有金句：互愛而不是互相傷害模式。這點，我非常認同。項目的成功才是大家所有人的共同追求，在這個前提下，互愛才能更好的包容與合作。項目成功了，是大家的Credit，項目不成功，一切的努力都是白費，即使那個過錯真的和你一點關系也沒有，又如何呢？
最后
兩天的課程，想分享的還是很多的，比如motivation知識工作者的方式、方法。走上管理者這個崗位后，這些都是非常重要、必須要面對的問題。這篇培訓后感，就當拋磚引玉，期待看到更多同學們的分享。也借此謝謝吳博的分享，學者的態度和風范，令人印象深刻。我想從每一位講師身上獲取知識固然重要，借鑒他或者她分析研究問題的方法，也是相當重要的。
