我們生活在一個后現代、后BPR、后裁員、后蕭條,后一切的世界里。別把員工當作小孩子,他們能洞察一切。最常見的是在管理層啟動變更前,特別是有顧問參與的變更,已經與敏捷和精簡背道而馳了。如果你想精簡人員那就裁掉他們,啟動敏捷模式吧。
就一條簡單原則:要引導、不要生拉硬拽。
當有人說“變更管理”的時候,他已經不知不覺地在硬拽變更,所以請慎用“變更管理”這個詞。
如果你身處管理層,那你需要營造一股合力來推動變更:一方面員工對于變更的熱情自下而上,另一方面來自管理層的支持自上而下,一拍即合。筆者覺得自上而下地硬拽敏捷模式無異于失敗,員工自然而然地會去質疑自上而下的強制變更。
相反,嘗試去尋找一種方法激勵每個員工和團隊,讓他們反過來向你建議采用敏捷模式,這遠比強調變更自上而下要好得多。管理者必須首先培養并點燃人們的好奇心,然后等著人們主動來問問題并尋求幫助,最后創建出自下而上的變更方案并給予支持。
想辦法點燃人們對于敏捷模式的好奇心,當他們來問的時候,給予幫助,并提供他們所需的東西:同意書本花費的支出,對講師、培訓師和教練提供預算,對會議說“是”??傊痪湓?,支持,全力地去支持! 別置身事外,即使你都了解,你也需要去學習,當團隊在形成共識時你需要在場。并且你也需要改變,學著改變你自身的行為去適應它。
7) 實施敏捷模式的動機
拋開你在敏捷體系中屬于哪個階層,工程師,測試,項目經理還是主管,問一問自己,你想要敏捷模式為你解決什么問題?搞清楚為何你想要改變并且明確你從中期望獲得什么。
不要因為趕時髦而去實施敏捷模式,讓敏捷模式幫你實現更重要的東西。去理解每個成員想要從敏捷模式中獲得什么,以至于讓他們的生活變得更美好。理解組織下想要從敏捷模式得到什么 ——是創新?是可靠的日程表?還是更少的Bug數?
問問你的團隊,問問你的老板,問一問“你認為你的老板想要獲得什么?”如果每個人都能從中受益,那每個人都愿意幫助實施敏捷模式。反過來,當人們看不到利益,變更將變得異常困難。
當你的敏捷模式進行實施的時候,你需要依靠這些問題的答案來選擇你的工具,優化你的流程并衡量你的成敗。
8) 流程與技術,兼而有之
千萬別認為你只要改變下流程,所有情況都會變得好起來。你必須同時考慮技術層面,你必須改進質量,并支持你的工程師,測試人員以及其他進行編碼實施工作的人。
我曾遇到過那些認為忽視技術層面的大公司:他們的態度似乎是“那只是技術”或者“他們將弄臟他們的手”或者“我們可以外包給低成本國家做”。如果你是這樣的態度,那你必將失敗。
“弄臟”你的手,跟工程師們談話,實施測試驅動的開發模式,實施重構,避免大規模的前端設計架構,學著接受粗略設計和演化架構,這些才是真正的反饋循環。
9) 使需求更清晰、更干凈
敏捷模式要解決的不僅僅是編程方面的問題,還包括需求分析的改進。特別是在有專職業務分析員的產品負責人或者產品經理,與開發團隊之間保持通暢的途徑。更深層次的談判將首先發生在“什么”上,然后再是“何時”上。必須有人有與需求相關業務的授權,能夠拍板兒。
太多公司沒能對此引起足夠重視,敏捷模式使需求理解更刻不容緩,需求上的瓶頸將對之后的開發產生連鎖反應。
自己跟自己做個智力測試吧:如果敏捷模式將開發人員的生產率提高一倍將發生什么? 答案是你將需要在需求分析上花兩倍多的精力。首先你可能會干掉一個長長的backlog,但你這樣做之后,你的余額價值(Marginal value)也將減少。
10) 結構變更——功能組
以功能組的方式,將所負責工作不同的員工構建成不同的團隊——例如:將數據庫開發和用戶界面開發分成獨立的團隊。這僅僅是你所要做的結構變更的第一步。但如果你在這里失敗了,你就不可能再做一次了。
但帶來的問題是團隊之間請求特殊技能支持或所需的授權將受到影響,因為其他組有另外的優先級。盡量減少這些,因為這將會拖整個團隊的后腿,影響團隊士氣,讓你的敏捷實施更為困難。
就是這樣
就這些了,其實這每一項都可以再寫一篇文章去深入討論,也許有一天我會那么做,但現有內容已足夠改變現狀。
如果說還有第十一項,那就是:忘記過去,改變無時不在,敏捷也不單純只是添加劑。如果你不勇敢地停止一些你現在正在做的事情,你永遠不會知道這樣做的后果。但你完全可以等到你有了成功的資本后,再開始轉變。
關于作者
勝任過軟件開發領域的似乎所有職位,從系統管理員到開發經理。如今他幫助團隊實施敏捷模式并將其發揮到極致,他在如何與軟件產品公司打交道及如何調整企業產品與流程使之符合公司長遠戰略上有著專長。他最新的著作《軟件開發人員的業務模式(Business Patterns for Software Developers)》已由Wiley于今年年初發行。他的Twitter是 @allankellynet.