說起精益軟件開發，這絕對算是一個老生常談的話題了。所以在這里，我不想去談論諸如“精益軟件開發的幾大原則”或是“精益軟件開發的最佳實踐”等陳詞濫調；只是最近在同事的推薦下，拜讀了一本有關IT運維方面的書籍(《鳳凰項目》)。書中的故事十分有趣，同時又引人深思，細細品味后頗有感悟，對工作和生活上有了許多新的想法，于是便按耐不住寫下此文。
寫在前面
布倫特是一個有著十年以上開發及運維經驗的高級工程師，無論是服務器宕機，發布失敗還是線上出現bug等緊急情況，他總是第一時間著手處理，雖然有時并不按照公司的正常流程去提交變更申請，但他總能在大家一籌莫展時漂亮的完成任務。于是整個IT部門的領導和同事都非常的喜歡他，甚至其它和IT相關的部門有需要幫助時，也很愿意找他，布倫特也照樣能夠快速并且出色的完成。直到有一天，問題堆積的越來越多，布倫特終于忙不過來了，而除了他，在沒有其他同事知道問題的來龍去脈，導致許多一級緊急事故無法及時處理，從而讓公司損失慘重。這時，大家的態度驟變，都將矛頭指向他，認為他沒有盡力，并且開始抱怨他總是不按公司流程處理問題從而引發了許多其他問題。老板也不在賞識他，甚至覺得應該在他身邊安排幾個同事去取代他，而后辭退他。
什么是制約點
開篇的故事來源于《鳳凰項目》，其實不難看出，故事中的布倫特對于整個IT部門來說極其重要，由于他掌握了大多數人所沒有的資源，技術以及處理問題的上下文，并且沒有及時與他人分享，從而讓自己成為了問題的核心，事故的焦點以及部門的制約點。
而事實上，布倫特就是布倫特，他一直都在出色的完成任務，他一直都獨享著所有一切的上下文，是“一直”讓他變得無法取代，也是“一直”讓他成為了那個制約點。
制約點總是那么的讓人琢磨不定：一開始，它必定是一個舒適點，大多數人并不會在意它，因為總有那些或那個人去悄悄的關注它；慢慢地，你也許很需要它，你才發現束手無策，不得不求助于你身邊那些悄悄的人，它又變成了一個痛點；最后，你還是在舒適點和痛點之間選擇了前者，隨著時間的沉淀，它終于成為了一個制約點。
尋找制約點
忘記是什么時候，耳邊聽到了一句“其實一切的一切，只是我們（devs）做的不夠快，不夠好”，此話雖然有些極端，但細細想來，似乎也頗具有幾分道理。
但我覺得這不僅是一個個人問題，同時也涉及到了一個團隊的運作方式。所以我也時常在想: 如果你是一名身處Agile Team，并且保持求知欲，富有激情，喜歡激辯的dev，那么怎樣才能把交付做的又快又好呢？
問題的答案肯定不是諸如“多看書，多學習”等唐塞之言，因為我相信一個能問出如此問題的dev，并且“保持求知欲，富有激情，喜歡激辯”，那么他一定遇到了自身難以察覺的制約點。
所以，不妨從發現身邊的痛點開始，學著在組內尋找自己的制約點吧。
解決制約點
如果將制約點看做是一個樹根的話，那么起初它只是一個點，而后慢慢成長，具有枝干，漸漸的新的枝干上又有了其他的分枝，直到枝繁葉茂時，你才發現無法從根部去找尋任意一片葉子的路徑，因為，它的層級已經太深。
因此解決它的最好辦法就是將層級扁平化：當你發現并且解決了一個只有你知道的問題時，不要讓自己成為那個制約點，學著share出去；當你發現在你所處的團隊里有你的知識盲區時，不要讓它成為你的制約點，主動求助，消除盲區；當你發現組內有共同的痛點時，及時的提醒，集思廣益，避免它成為大家的制約點。
尋找下一個制約點
但我并不認為有制約點的存在就是壞事：人與人本身在能力偏好方便面就有差距，這就決定了每個人的知識體系大相徑庭，所謂“術業有專攻，技術有偏好”是也。所以，制約點某種程度上代表著你的一個目標或者方向，解決制約點的過程就是拉平它對你的制約層級，彌補自身的不足，這就是進步。所以沒有制約點就是原地踏步，為了更進一步，就得尋找下一個制約點。
因此，解決完“所有”（也許你認為的所有）的制約點并不意味著萬事大吉，你應該繼續尋找下一個制約點。
寫在最后
受“精益軟件開發”所啟發，個人覺得所謂的精益思想，XP（極限編程思想），Agile（敏捷思想）都只是一種方法論，甚至可以說由它們衍生出的所謂的最佳實踐也都是方法論。畢竟，具體到每一公司，每一個項目，每一個團隊，這些準則都不可能完全匹配和適用，但若以此作為思想參考，就會不僅在工作中，而且在生活中感受到它的導向價值作用，從而事半功倍。
