感謝我老婆，大周六自己在家帶孩子，讓我參加了一整天的敏捷Scrum Master 培訓。我想如果這個培訓是
工作日在公司內部，大家是否還有如此的積極熱情呢？今天只達到預期人數的一半，參與程度卻非常高，結束之后大家都圍著杜偉忠教練不斷問問題。我切實的感覺到這些人真的是公司內愿意
學習新知識，對
敏捷，對改進有極大熱情的人。我想無論是培訓還是其他交流活動，想甄別出南郭先生還是真正熱情的粉絲，選擇周末舉辦是個不錯的辦法。
拋開現實，在敏捷實踐的活動中，我們可以組成自組織的小團隊，頻繁溝通、持續改進。但是真正討論到敏捷落地，有些人一聲嘆息說“理想與現實還是有差距的”，也有些人覺得“有心問鼎，無力回天”，還有一大部分人抱著樂觀而又被動的心態想著“總有人來幫助我們做出改變的”…
世界的大環境都是一直在改變的，又何況我們所處在的小環境，面對變革，要么被淘汰，要么被改變。被動改變是痛苦的，想主動改變卻又覺得無從下手干著急是更痛苦的。反正都要痛那么一下子，就好比打針，我們預期到針要扎在哪個屁股上，會事先做好心理準備的。所以我想可以先來分析下敏捷轉型會扎到我們個人和組織的哪些痛處？
持續學習之痛
組織中一部分人已經習慣了現有的工作方式，雖然有問題，但是憑著個人的經驗也能夠處理的游刃有余。
作為開發，每天要應付很多的各種來源的任務，有的是產品經理和開發經理定的，有的是總監拍的。已經習慣了領導驅動的工作方式，也已經逐漸摸索出了一套“上有政策，下有對策”的應對措施。我已經習慣于通過google來解決問題，偏偏現在只能用
百度，就忍了。你還要讓我學習“重構”、學習“
測試驅動開發”，學習“實例化需求”，學習“持續集成”？我只想說“我是寫代碼的，干嘛要管你們那么多事情”。
作為測試，隔三差五的上線個小需求啥的，等待部署環境一個小時，等待數據同步三個小時，抓緊在午夜十二點之前完成十來個用例的線上驗證，好回家睡覺。我上班不能學習吧，我要點頁面，我要找開發，找產品，下班我還要加班啊，什么時間來學習呢？
我已經好久不碰代碼了，
自動化測試我怎么學的會呢？測試最牛逼的還是手動測試，專家都這么說了。
作為產品，我都忙得找不著北了，我不主動去找開發人家也不搭理我，我天天要開會、要溝通，要寫PRD，還要天天被測試纏著確認各種需求問題。我一直希望深入的掌握業務，可是我TMD也就是個公司業務方的代言人，就是你們天天說的“二道販子需求”。別給我提什么Product owner是決定一個產品成敗的關鍵所在，我只想著老老實實把領導關注的業務都給實現嘍，敏捷啊，是你們研發自己的事情。
組織架構之痛
組織結構是職能部門橫向劃分的，產品經理屬于產品部門、開發屬于開發部門、測試屬于測試部門、項目經理屬于
項目管理部。每個部門的團隊都要實現各自不同的價值，這樣難免會出現“各掃門前雪”的情況。如果要敏捷，倡導跨職能的團隊，原來獨立職能團隊積累的一些經驗需要打破重來，原來的經理們需要重新找到自己的位置。這都是不容易的。
首先從測試部門說起，目前測試團隊的價值體現在什么地方？常常團隊中認為發現足夠多的
Bug，編寫足夠多的
測試用例，及時得反饋問題，這樣就夠了。可是真是這樣嗎？每每開發完成了提交測試，后期又出現項目周期延誤，大家或多或少的心里嘀咕“測試時間這么拖這么長，能力不行嗎？”有時線上出了問題，開發熬夜改bug到凌晨3點，他也會抱怨一句“這個問題怎么測試沒發現？”。測試肯定覺得很冤，我們Bug和用例的數據都在那呢，最后處理問題的結果可能是開發測試各打五十大板了事。如果要敏捷轉型，追求全能型工程師，測試部門獨立存在的必要性就很小了，敏捷團隊中的每個人無論是開發、產品、還是測試都會參與到測試中去，打破了對測試工程師自身的局限以及這個title的局限。面對組織架構的重構，測試部門及團隊成員必須浴火重生，在提升業務能力和技術能力的同時才能體現出自身的價值。
目前的開發部門，負責前臺頁面的不管后臺Server的問題，負責單獨模塊開發的不負責公共部分問題的修改，開發主管一般作為Product owner來掌控項目。這樣看起來，專業化、精細化的分工是能夠把職責劃分得更清晰，可是確常常會出現接力失誤，導致接力棒掉在地上的情況。有些劃分不清的區域，誰也不愿意也沒有責任去主動承擔。開發主管以小組成員利益的角度出發，在平衡客戶需求和團隊訴求時是非常困難的。可是，如果轉型，必然需要調整組織結構，要重新打破舊有的平衡，已經到嘴邊的“蛋糕”也需要重新分配。
產品上面已經吐槽了，這里就說說項目管理部門。尷尬的項目經理沒有考核項目成員的權利，卻要承擔著項目質量控制、進度控制、風險控制的責任，需要協調產品、研發、測試各個部門。可以不斷的反饋問題，推動起來卻重重阻礙。出現問題匯報領導，項目組成員覺得你愛打小報告，若是不匯報，出現問題，又要承擔沒有及時反饋的責任。因此只能說這個戰場比拼的是情商和個人魅力，這樣才能夠順利周旋于多個角色之間。那么，轉型敏捷后，項目經理要面臨什么樣的角色轉換呢？Scrum master 還是 product owner，還是重新開始寫代碼，成為一名團隊成員呢？
渺小的個人VS強大的影響力
渴望改進的人，絕不是消極的，抱怨是無解的。敏捷的思想是要相信團隊，無論是自己所在的小團隊，還是公司這個大團體。還要相信個體的力量，通過不斷學習提高自己的能力，發揮“日拱一卒”的精神，抱著一顆同理心，幫助他人，與團隊內外的成員共同進步，去建立自己的影響力。做好心理和技能的準備，不斷的實踐嘗試，一步一步實現改進的愿望。
說起來是這個道理，可是有人會說了，我作為一個普通員工，我甚至只是一個測試工程師，處于項目流程的下游，我感覺自己什么也做不了。即使領導支持敏捷了，我們作為測試，不會直接的交付產品，我們也無法單獨敏捷啊。或者作為一名開發工程師，或者產品經理，個人都是沒法一下子去推動敏捷改進的。還有人說，那就等吧，你不用操那么多心，你所想的遲早有一天公司都會幫你實現的。。。
不只是我們自己相信，敏捷思想是經過驗證的能夠提高交付價值，提高團隊效率的有效工具。因此，我們要相信好的東西，大家是沒有理由不喜歡的。就好比美味的螃蟹，大家不去吃，是因為不知道它的美味，不同的人看到的是不用的角度，有的人只看到了張牙舞爪的鉗子，有的人只看到了硬硬的殼子，在沒有品嘗到美味的蟹肉和蟹黃之前，大家都不可能欣然接受，更何談去主動參與，積極推動呢？
杜偉忠教練也給我們分享過一個實例，原來他還沒做敏捷教練，是熱心敏捷的愛好者。他的辦法就是鼓勵身邊的同事或領導和他一起去參加敏捷的社區或者交流分享活動，讓大家逐漸都感受到敏捷的魅力，大家都覺得好了，自然推動起來就沒什么阻力了。這只是一種影響他人的方法。我們也可以從自身做起，不斷學習，去掌握敏捷的精髓，提煉出真正提高生產力對團隊有益的實踐，先小范圍應用到實際工作中，身邊的人自然會看到你做的一切，自然會感受到敏捷的力量。
這是
互聯網的時代，按照互聯網思維，每個人都是一個節點，通過建立連接可以發揮無窮的影響力，方法就是不斷的 學習、實踐、溝通、分享 ，循環往復…
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters