敏捷史話(四):敏捷是人的天性 —— Arie van Bennekum
敏捷是人的天性,是你與生俱來的東西。面對敏捷,Arie van Bennekum 下了這樣一個結論。
但這並不意味著人們只能透過天賦獲得敏捷,對於想要學習敏捷的人來說,敏捷絕不是僅僅靠學習僵化的框架、實踐、過程或技術就行得通的。同樣,只有真正採用敏捷思維和文化的組織才會變得更具靈活性和創新性。而
Arie,也在推動著敏捷轉型。
傳統式工作
1983年,Arie 以一名助產士的身份取得了衛生學學士學位。拿到畢業證以後,他做出了自己的職業規劃:從事女性保健行業。即使在這個當時是女性佔主導的行業中,作為一名男性的他並不佔優勢,他也確信自己可以做得很好。事實上,他確實完成得很出色。
兩年後,Arie 開始服役。在義務兵期間,由於 Arie 常常不按套路出牌,所以他的教官告誡他,如果不能循規蹈矩,就無法取得成功。但在服役結束前,不被教官看好的他卻擔任了排長,並贏得了團隊和指揮官們的尊重。這件事告訴了他:
無論在哪個領域工作,遵循既定的舊式體系並不是成功的必要條件
。
1987年,Arie 作為 COBOL 開發人員開始從事IT工作,他的職業生涯開啟了新的篇章。在這一公司中,Arie 的大部分時間都是在結對程式設計,進行短週期、有時間限制的交付。而從這家公司辭職後,Arie 加入了一家採用傳統工作節奏的IT諮詢公司,在一家著名的政府機構從事一個專案,開始了傳統式開發模式之旅。
由於工作完成得極為出色,很快,他就由開發人員晉升為技術設計師,這是對他能力的最大肯定。但在進入設計領域後,Arie 也逐漸發現了一個問題:自己離客戶越來越遠了,“這不能令我感到快樂”。這種情緒一直困擾著他,直到1994年中期,導火索出現了。當時,Arie 參與了一個耗時多年的專案,這個專案將與另外兩個為期六個月的技術設計一起交付,但在設計過程中,他發現自己在不斷地重複做一件事情:將一份檔案翻譯成另一份檔案,並將其交給能讀懂第一份檔案的程式設計師。這種死板的方式帶給了他很大的挫敗感。“這種方式幾乎抹去了我的工作的全部附加價值,簡直是在浪費時間、金錢”。他意識到,
傳統的工作模式正在阻礙著團隊的管理最佳化
。
這件事過後,Arie 冒著被辭退的風險做出了一個決定:他去同管理層解釋,說自己不想再做這樣的工作。但自己究竟要做什麼樣的工作呢?他一直在思考。直到幾周後,答案出現了。Arie 被邀請參與到一個快速應用程式開發(RAD)專案中,這個專案所涉及到的互動、迭代、原型等敏捷的元素給他帶來了一個全新的世界。令人遺憾的是,這個新世界並不是完美的:
RAD 能夠使開發人員透過簡單的構建原型,快速地向使用者和客戶展示可能的解決方案,但這種方法通常是非結構化的,這導致各個 RAD 團隊之間彼此孤立、彼此分割
。Arie 深知,RAD 方法還需要很多成長的空間。
初識 DSDM
為了完善RAD方法,1994年,業界成立了一個以“
共同開發並推動一個獨立的 RAD 框架
”為目標的
DSDM 聯盟
,DSDM(動態系統開發方法)誕生了。此時的 Arie 還在尋找更完善的方法。三年後,他加入了一家小公司,該公司擁有自組織的團隊、高度授權的成員以及創新的文化環境。也是在這段時間裡,Arie 接觸到了 DSDM。
DSDM 是一種以使用者反饋為基礎,並優先考慮快速原型和迭代的軟體開發方法,他認為,
DSDM 能夠以一種真正適合終端使用者的方式向客戶交付他們切實需要的東西
。因此,1997年以來,Arie van Bennekum 經常作為教練參與各個 DSDM 專案,積極參與 DSDM 聯盟。目前,他不僅是荷蘭比荷盧(Benelux)DSDM 聯盟的董事會成員,還擁有多個 DSDM 認證。
Arie 從 DSDM 中學到很多,對於他來說,開發過程中的各個方法論都基於不同的正規化,而成功實施的基礎,則源於這些方法論中的各種標準慣例。也就是說,如果在一個團隊中,每個人所習慣的工作方式各不相同,那麼團隊要做的第一步就是確保所有人的工作方式是一致的。但如何徹底改變團隊的工作方式,這又是一個大問題。
1998年,Arie 第一次將 RAD 引入到客戶的團隊中時,就發現了類似的問題。不論團隊是否決定轉變工作方式,亦或是無論如何轉變工作方式,總會遭遇到未知來源的阻力:管理層依然堅持著舊的工作方式,包括決策、評估、交付、接受等流程。果不其然,他將 RAD 引入團隊中,並在團隊內實施了一段時間後,整體的工作效果還是欠佳。不僅是個人,團隊也更傾向於退回到舊的工作方式中。
在 Arie 看來,每個人的觀點或看法,並不會因為學習了敏捷的各種慣例,就立刻做出改變,如果不改變團隊工作的環境和個人的看法,那麼,以高壓、強迫的方式來改變人們的工作方式只會造成大力反彈,一旦外部壓力消失,他們就會回到原來的工作方式。因此,
團隊轉型就意味著首先要從觀點、看法轉變做起
。
《敏捷宣言》
對於 Arie 來說,2001年是充滿魔幻色彩的一年,也是註定不平凡的一年。
這年秋天,Arie van Bennekum 作為英國 DSDM 聯盟的代表受邀參加雪鳥會議,來到鹽城湖,簽署了《敏捷宣言》。Arie 說,《敏捷宣言》是對當時幾種輕量方法背後的價值與原則的提煉,是這十七個人都認可的最佳實踐,而自己至今仍為會議總結出了“敏捷”——這一涵蓋所有輕量開發方法的詞感到自豪。
此後,隨著踐行敏捷的隊伍不斷壯大,業內不斷有人對《敏捷宣言》做出更新,Arie 也重新審視了自己的“敏捷宣言”,並在原來的基礎上做了一些小的調整。
首先,2001年所簽署的《敏捷宣言》的重點是:找到交付更好軟體的方法,而 Arie 認為敏捷是一種整合的企業解決方案,它適用於組織的每一個職能,包括從人力資源到技術。因此,他提議將“敏捷宣言”中的“軟體”換成“解決方案”,以滿足現今組織整體踐行敏捷的需求。
其次,將“響應變化高於遵循計劃”改為了“響應變化高於遵循死板的計劃”,這個變動主要集中在遵循什麼樣的計劃上面。Arie 認為,團隊需要有一個合適的計劃,只要不固執地遵循計劃,並記住它是靈活的,那麼當出現新的情況時,它就可以“響應變化”。
敏捷中有一個神話,就是實踐敏捷可以做任何我們喜歡做的事情。而 Arie 認為,實踐敏捷必須做需要做的事情,敏捷的成功來自質量和紀律。舉個例子,一個團隊每週只開一次早會,他們覺得每天開會就會造成時間成本的浪費,用時多、效果差,這是一個非常愚蠢的行為。只有每日更新團隊的工作進度,才能及時發現並解決日常工作中存在的問題。
大多數情況下,從事敏捷轉型的人只關注於以教條的方式實現的一個或幾個框架、實踐,卻忽略了最重要的部分,即實現敏捷和按照敏捷做事的區別。為了實現敏捷,成員、團隊必須轉換到一個完全不同的正規化,其中包括不同的思維方式、工作方式和協作方式。這種轉變反過來能夠讓整個團隊從敏捷中獲得巨大的好處。
因此,為取得成功,需“達成敏捷”而非去“做敏捷”。
Agile TM 轉換模型
Arie 始終把人作為關注的焦點、工作的中心。作為敏捷領導力諮詢公司 Wemanity 的精神領袖,他也不斷地努力在 Wemanity 內建立、加強敏捷(以人為導向)的文化,以便為 Wemanity 的客戶提供最佳價值。
為了使組織變得更加靈活、敏捷,Arie 及其團隊開發出了一套整合敏捷轉換模型 IATM(Integrated Agile Transformation Model),這是一種經過驗證的方法,無論是從個人到領導,還是從企業服務到技術,都可以透過運用它成功轉換為新的敏捷正規化。
IATM 的流程
首先是環境
,它將人們帶入到變更過程中,真正實現敏捷;
然後是團隊
,要求在一個團隊中以高質量和紀律為標準來學習;
最後是個人
的完善。為了達成最佳效果,Arie 還提出,他們會在開發中做很多簡單、定製的活動,從而幫助組織將關注點從偽敏捷轉移到真正的敏捷上面,針對某一問題進行具體分析。
如今,ITAM 已幫助財富榜單上眾多500強公司成功地完成了敏捷轉型,不論是過去還是未來,ITAM 終將繼續砥礪前行。
作為一名敏捷佈道者,Arie 多年來一直致力于敏捷轉型,如何促使敏捷轉型團隊達到最佳狀態,是他一直以來的追求。此外,他在社交媒體賬號上也非常活躍(Twitter、Facebook、Linkedln賬號:Arie van Bennekum)。在 Arie van Bennekum 的身上,我們看到的是:
打破常規,需要的不僅是“離經叛道”的勇氣,更多的是踽踽獨行的實踐精神
;
遵守規則,需要的不能是敷衍了事的態度,而是融會貫通的技巧應用
。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69982050/viewspace-2751600/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 敏捷史話(五):敏捷已逝 —— Dave Thomas敏捷
- 敏捷史話(十二):你現在接觸的敏捷也許是“黑暗敏捷”——Ron Jeffries敏捷
- 敏捷史話(八):敏捷的破局之道——Martin Fowler敏捷
- 敏捷史話(十一):敏捷宣言“間諜”——Steve Mellor敏捷
- 敏捷史話(九):用做麵包的方式做敏捷——Alistair Cockburn敏捷AI
- 敏捷史話(十五):我發明了敏捷估算 Poker —— James Greening敏捷
- 敏捷史話(十四):敏捷之峰的攀登者 —— Jim Highsmith敏捷MIT
- 敏捷史話(三):篤定前行的勇者——Ken Schwaber敏捷
- 敏捷史話(十六):我對《敏捷宣言》沒有半點貢獻—— Brian Marick敏捷
- SOA和敏捷:是朋友?還是敵人?敏捷
- 敏捷史話(十三):我被 Facebook 解僱了——Kent Beck敏捷
- 敏捷四式敏捷
- RUP是敏捷的嗎?敏捷
- 實戰規模化敏捷:從8人到百人的敏捷之路敏捷
- 神馬是敏捷?(3)——敏捷在中國的水土不服敏捷
- 歷史:敏捷宣言誕生記敏捷
- 敏捷是什麼?敏捷
- 神馬是敏捷?(4)——敏捷不能當飯吃敏捷
- 敏捷史話(十七):維基(Wiki)背後的靈感來源—— Ward Cunningham敏捷
- 敏捷開發大家談(四)敏捷
- Scrum是脆弱的,不敏捷的Scrum敏捷
- UP還是敏捷方法?敏捷
- 敏捷史話(六):也許這個人能拯救你的程式碼 —— Robert C. Martin敏捷
- 敏捷開發人員的責任敏捷
- 敏捷運動發起人馬丁·福勒認為當前敏捷運動是一場悲劇敏捷
- CORNERSTONE對話騰訊&華為敏捷專家敏捷
- 什麼是敏捷估計?敏捷
- 敏捷測試是什麼?敏捷測試
- 敏捷史話(一):用一半的時間做兩倍的事——Scrum之父Jeff Sutherland敏捷Scrum
- RUP是如何輸給敏捷Agile的?敏捷
- 敏捷和DevOps:是敵是友?敏捷dev
- 敏捷與 DevOps:是敵是友?敏捷dev
- 敏捷開發模式中的四種會議敏捷模式
- 敏捷的思考敏捷
- 敏捷的文件敏捷
- 什麼是敏捷專案管理?敏捷專案管理
- 敏捷專家認為敏捷框架SAFe實際最不敏捷敏捷框架
- 中式太極敏捷與西式敏捷的區別敏捷