今年很多好友的公司都開始要導入 agile, 他們花了不少錢去上課, 很積極地想把 scrum 實施好. 在上完課程後, 他們都不約而同問了這個問題: 如何開始在公司內推廣 agile?
這確實是一個很常見, 也很難回答的問題. 每家公司環境不同, 文化不同, 很難有相同方法. 不過, 在Fearless Change 一書中有些建議, 大家可以參考一下.
1. 找到傳教者
首先, 要找到一個有熱情的, 願意對這個新的東西有承諾的人, 要利用他來燃起興趣的火花. 就像 91 在 Yahoo 內扮演的角色.
很多時候推廣一個新東西會失敗, 通常是一開始找錯的人. 因為他對這個東西沒有信心, 並且也對這東西不是這麼有興趣, 所以一旦遇到了挫折, 或者是各式各樣的問題, 他很快就會放棄, 然後就走回回頭路.
2. 瞭解環境
一開始, 你不是要把所有東西都推給大家, 這是不切實際的. 你要做的是先了解, 大家願意接受什麼. 或者大家對什麼有興趣, 或是對什麼問題比較痛.
3. 按部就班
如果找到要推的點話, 也是要循序漸進來進行. 譬如, 如果要做 continuous integration. 至少要先有 auto build 的流程. 如果沒有, 就不用談下一階段了, 不要去談 TDD, 那一點意義都沒有. 老子說: "千里之行, 始於足下”, 正是這個道理.
4. 近程勝利
推行一個新的東西, 要能成功達陣, 是件不容易的事情. 因此, 你可以從近程目標開始, 每當你一個小的里程碑時, 你就可以大方慶祝, 好讓大家都知道你有進展.
一方面, 你可以藉此機會推銷你的推的東西, 讓大家知道你在做什麼. 另一方面, 也讓內外的人了解, 你這個東西是有搞頭的, 是可以做到些什麼的.
5. 即時檢討
本來變革就不容易成功, 因此, 一開始就要檢討, 目前哪些做得好, 哪些需要做些調整. 在這個過程中, 我們學習到什麼等等. 老中很努力工作, 可是卻很少改善自己的做事方法.
當談到 Scrum 時, 會要求團隊要是一個跨職能的團隊 (cross functional), 好讓之後工作可以進行得比較順利和有效率.
很多人就會對跨職能很有意見, 因為在他們的心中, 所謂的跨職能, 就是要會很多東西. 我想這是不正確的, 基本上, 術業有專攻, 不太可能做到精通每件事情.
那它倒底是指什麼, 讓我們看看幾種可能:
1. 全棧工程師 (Full Stack)
最近國內外很流行 full stack. 所謂 full stack 應該是指他會很多技能, 並且每項技能都還滿厲害的. 他可獨立作戰, 可以 end to end 打通關.
是很神沒錯, 但是可遇不可求. 就算遇到了, 一個人還是做不完 5 個人的工作.
2. T 型人
所謂 T 型人, 就是有某項專長, 但是他對某些東西也略懂略懂. 例如他精通後端程式, 但也會點前端, 像是會些簡單的 javascript, angularJS 可能就不行了.
有狀況時, 他們可以幫些簡單工作. 可是對於太難的事情, 他們就使不上力了, 但是有人願意教的話, 或許可以學得比較快.
3. 應變的心態
他不見得要會什麼, 但是他不會想說只做原先工作範圍的事, 如果別的人有狀況, 或是有突發事件時, 他願意挺身而出, 試著思考一些方式去幫忙解決問題.
大家覺得 scrum 這邊想要的是哪種類型?
我覺得第三種最重要. 如果你有前面兩種的工程師, 恭喜你, 你找到菁英. 如果他還是第三種, 那他就是精英中的精英.
但是現實生活中, 大多數不會是前面兩種人. 那該怎麼辦?
至少你要試著當第三種. 並且試著把團隊培養出第二種和第三種人.
有些人會說 scrum 需要的是 full stack 的人, 這樣太難了, 然後就放棄不用. 這樣的人大多不是第三種人. 任何別人可行的解法, 到他手上很容易就是不可行.
須知每種方法到來, 都需要點客製化, 很少有完全可以套用的. 如果你無法有應變的心態, 那很難找到仙丹 …...
而實施或是學習 agile 時, 很多人是把它當作一項新的技術來看待, 認為只要了解實施細節或是流程, 自然就可以在團隊中使用.
事實上, 並沒有那麼簡單....
就算你要導入 TDD, 持續整合, 持續發佈等等這麼技術性的東西, 都還是跟人和文化有關.
如果老闆個性很硬, 喜歡 command and control, 不太喜歡聽別人的意見. 總覺得自己想得最好, 其他的人都還太菜, 這樣 agile 會不 work.
如果經理的技術很好, 是個大神, 大家喜歡叫他大大, 每次他一出聲, 別人就不太敢說話了, 這時候要敏捷也有難度.
如果公司文化是多說多錯, 或是專打提出問題的人, 那這樣也不適合用 agile.
如果團隊成員覺得多一事不如少一事, 只想把自己分內做好就好, 不是很想去在乎別人做了什麼, 這樣 agile 的精神就沒有了.
如果大家都覺得自己做得很好, 沒有什麼東西需要改進, 這樣也很難要導入 agile.
agile 是希望在面對各種變化時, 大家能有應變 change 的能力. 因此他提出的解法 - 敏捷宣言, 都是以改變價值觀為出發點的:
個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計劃
要有做到這些價值觀才算是 agile. 並且第一條的個人與互動, 就明明白白的告訴你, 人和文化是最重要的.
所以, 我很少看過那些執行 agile 很好的團隊, 是在強調用了 Redmine/Jira, 或者是是裡面有某位大神, 或是因為誰在這個團隊中.
通常是大家覺得團隊氣氛很好, 願意去嘗試一些改變, 然後大家會互相幫忙鼓勵, 不是老闆在主導, 是大家願意做得更好.
如果有爭吵, 也是為了把東西做得更好, 也是對事不對人. 不會在私底下做些小動作, 或是在背後放話. 不會刻意去維持皇城內的祥和, 可是也不會吵到失去控制.
所以, 了解 scrum 的流程, 或是知道 TDD/CI 要怎麼做, 這些都很重要. 但是前提是, 你要好好把人搞定, 建立一個大家願意面對 change 的環境, 否則要推 agile 是有點奢談.
作者：David Ko
作者簡介：David具備Certified Scrum Master以及Certified Scrum Product Owner的認證，也是台灣最早期 Agile 社群（AgileCommunity.tw）發起人之一。 為了推廣Agile知識，還擔任過「Scrum and XP from the trenches」這本書繁體中文的翻譯者。目前在趨勢科技擔任資深研發主管，並從2008年開始在專案中實施Scrum。 八年間累積了非常多的實務心得 - 有針對Agile精神的核心體悟、理解方法的限制、也理解很多教科書上知識更深層的執行方向、當然更多對這方法可能產生的副作用以及解法。
文章出處：David Ko的學習之旅
原文連結：
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
