Categories
程式開發

大規模敏捷已經開始,再不成為這樣的管理者就晚了 | 極客時間


寫在前面

你好,我是宋寧,現在在IBM做敏捷教練和諮詢顧問。今天想和您聊聊“如何用敏捷開發打造一支無往不勝的團隊?”

從一線工程師到管理者,從項目經理、Scrum Master,到現在的敏捷教練、諮詢師,我經歷過研發管理從無序狀態到瀑布模式、敏捷模式,對各個管理模式的優劣深有體會,也從各個角度體驗過敏捷。

有競爭力的開發者是什麼樣子的?

我最早接觸敏捷,是源於一位做開發的朋友。他就屬於那種效率極高的,大家一個禮拜的任務他2-3天就能做完,代碼質量高 bug 少。最主要的是,他除了寫代碼以外,有足夠多的時間研究新技術,指導其他同事,在團隊中口碑極好,後來還研究上了管理,聽說這傢伙後來做了首席架構師,還兼任團隊Leader。

他有個習慣,每次寫代碼之前都會仔細想一想需求,想好後先寫測試用例代碼,再動手寫代碼。一旦寫代碼就特別快,一氣呵成。

那時我偷偷問他,“你寫代碼之前還要寫測試,多麻煩啊,怎麼還能寫那麼快那麼好?”他眨巴著眼睛,一臉坏笑:“代碼寫得快靠得是思考快,而不是敲字敲得快,構思好了再寫不就是記錄自己想說的話嗎?再者,我先寫測試後寫代碼,磨刀不誤砍柴功,好多問題在前面都解決了。”

我再看他寫的代碼,簡潔優雅,頓時羨慕得不得了。他告訴我,“這就是測試驅動開發,敏捷的核心技術實踐之一。”他改變了我對程序員的認知,也改變了我對這項工作的認知,原來厲害的程序員不只是擼代碼啊。

我一直熱衷於探索研發管理的效率、效益和精髓。帶著疑惑,加之當時公司也確有敏捷方面的需求,我從此開始研究和實踐敏捷開發。剛接觸的時候我覺得理念很好,但有些理想化,那時我並沒有從內心接納敏捷。

隨著過程推進,我逐步感受到了敏捷帶來的好處,尤其在團隊管理方面,敏捷為我省去了大量的時間

以下內容出自極客時間《說透敏捷》,👉點擊試讀

如何打造一支活力與戰鬥力並存的敏捷團隊?

團隊是整個敏捷實踐活動的根基,只有團隊能有條不紊又高效率的執行敏捷實踐中的每一項工作,敏捷才能發揮出它最大的效用。如果團隊氛圍不好、執行力不高,那即便導入了敏捷實踐活動,團隊也很有可能做不好。

在做試點準備工作時,我們已根據最適合團隊交流協作的方式,對團隊的組織結構進行了重組,那麼重組後的團隊就可以成為一支無往不勝的團隊了嗎?當然不是,你還需要想辦法來喚醒、激發團隊,讓整個團隊更有活力和戰鬥力。

敏捷試點中最重要的一步便是:打造一支活力與戰鬥力並存、無往不勝的團隊。學好了這關鍵一步,不管你和你的團隊採納的是哪種敏捷實踐,你都能在推進時得心應手、運籌帷幄,你的團隊管理能力也會因此更上一層樓。

一起制訂社會契約

我先來講一個做法,叫做“社會契約”(Social Contract)。

什麼是社會契約?它本指一個社會裡的全體成員,為了更好地生活,定義了一些基本準則,大家一起來遵守。用在團隊中,指的就是團隊裡的行為公約,也就是為了讓團隊中每個成員都能加強協作、發揮價值,一起來約定的一些基本準則。在工作中,如果有任何成員的行為影響了團隊協作,其他成員都可以拿出這個契約來約束他,這樣就可以“對事兒不對人”,在處理不良行為的時候更有說服力。

落地社會契約的過程,其實就是團隊內部相互認可、磨合和協作的過程。那具體怎麼來做呢?我認為可以將團隊所有成員都聚到一起,大家一起來製定,只有這樣,才能夠充分徵求每一個人的意見,讓大家一致認可,並有充分理由一起執行。

首先,給大家分發一些貼紙,並給所有人5分鐘的靜默時間,讓每一位團隊成員思考這一個問題:你認為加強協作、達成團隊目標,需要哪些行為準則?每一個人都要把自己認為重要的準則寫在貼紙上,且一張貼紙只寫一條準則。

寫完之後,每個人把自己手中寫好準則的貼紙貼到白板上,然後將白板劃分為不同區域,把內容相似的貼紙歸在同一個區域。

接著,會議的組織者逐條給大家讀貼紙上每個人寫的準則,詢問大家是否同意,如果有人不同意,就停下來就此討論一番,如果討論的結果還是有人不同意,就放棄它;如果大家都同意,就將該準則保留下來。

這樣進行一遍,把大家都同意的行為準則留下來,就形成了團隊的“社會契約”。

你要注意的是,“社會契約”做完以後要張貼到所有團隊成員都可以看到的地方,以便整個團隊時時可以看到它,感受它帶來的激勵和約束。如果把它束之高閣,那就失去了它應有的效用,你的團隊的協作也可能因此出現問題,進而導致敏捷推進的失敗。

回顧會議,引導團隊的自主性

在試點推進前製定“社會契約”,可以讓你的團隊形成一個約束和激勵機制;那麼在試點推進過程中,通過開展回顧會議,你的團隊會形成一個引導機制,來引導團隊的自主性。

在評估診斷階段的調研訪談中,你已大體了解到團隊的痛點,也根據痛點選擇了相應的敏捷方法。那問題來了,敏捷方法裡既有管理實踐又有技術實踐,推進順序是怎樣的呢?

一般而言,作為敏捷教練,我們自己會有一個自認為“正確”的推進順序。但敏捷實踐方法是團隊來用的,行為和習慣轉變也是團隊要做的,而且我們也要打造自組織團隊,所以相比你自己單純地做口頭宣講,按自己的想法推進敏捷,引導團隊自行選擇和決定推進順序會比較好,這更容易讓團隊認可和接受。所以重要的不是“你想”而是“團隊想”,回顧會議正好可以完美地做到這一點。

怎麼開展回顧會議?其實也很簡單。

首先,要選一個大家都方便的時間,把會議時間固定下來。前幾次的回顧會議可以由敏捷教練來引導,等大家對會議流程都熟悉了,就可以由團隊的組長來組織。

會議開始後,先說明會議目的,接著讓大家討論三個條目:

  • 團隊工作中做得好的地方是什麼?
  • 做得不好的地方又是什麼?
  • 除此之外,有沒有什麼其它疑問?

和製定契約的會議一樣,先用五分鐘時間讓大家靜默思考,然後把每一個點子都只寫在一張貼紙上。將白板劃分不同的區域,把相似內容的貼紙分區域貼到白板上。

接著一一討論這些問題。做得好的地方我們在接下來的迭代中就可以保持下去,做得不好的地方大家可以一起頭腦風暴到底怎麼去改善,並做一些行動計劃。對於有疑問的地方大家也可以互相提問,有些是敏捷教練需要闡釋的,有些則是團隊成員需要解釋的。

這裡你要注意,回顧會議是有時間盒的,一般不會超過1個半小時。在前幾次回顧會議中,團隊會提很多關於敏捷實踐的問題,但我們的時間有限,所以如果問題幾句話就能解釋明白,通常我會當場解釋清楚,否則我會安排專門的時間來和團隊解釋他們的疑惑,而不會把會議拖得過長,佔用過多時間。

你可以看到,這個會議其實也有查漏補缺的功能,可以讓你察覺團隊成員在哪些方面有疑惑,或者哪些敏捷知識儲備不足,後面你可以安排其它時間來幫助團隊專門補齊。

以我帶過的一個手機銀行團隊為例。在第一次回顧會議時,團隊針對做得不好的地方提出“項目透明度差,只了解自己的工作而不了解其他團隊成員的工作”,我就這個問題引導團隊思考其背後的原因,之後團隊一致認為主要原因是“沒有地方和機會了解別人的工作”。我就勢引導團隊說:“大家覺得可以做些什麼事情來改善這個問題呢?”最後大家討論認為,不如約一個時間,每天定時定點地開個短會來共享一下彼此的工作內容和狀態,這不就是“站立會議”嗎?我們又一起給這件事情定了一個時間段:下個迭代。我領取了這個改進任務,在下一個迭代中為團隊導入“站立會議”。

說到這你發現了沒有,通過回顧會議來引導團隊思考,所有的敏捷改進就不是我作為“敏捷教練”安排給團隊來改進的,而是團隊自己思考出來的行動。身為敏捷教練,我只需要將專業的敏捷知識和做法示範給團隊即可,團隊會更願意踐行自己主動思考出來的行動,這樣,整個團隊的行為和習慣就會轉變得非常順暢。

所以說,只要掌握了正確的方法,敏捷的推進並沒有想像中的那麼難。每個團隊其實都有向好轉變的原動力,我們只需要將它激發出來,並且告訴他們正確的行為規範,加以引導就好了。

成績牆與錯題集,記錄團隊敏捷的成長

有了契約的約束和回顧會議的引導,是不是就意味著在試點過程中,會一直一帆風順呢?不會,你一定還會遇到些小波瀾。因為團隊也不會一直都正確地思考,也有犯錯的時候,比如:

  • 團隊為了趕進度,省略了部分測試,匆忙上線;
  • 迭代中間有業務人員向某個團隊成員提出了新的需求,要求加到迭代中,團隊成員不顧自己的研發產能,擅自將該需求加到了迭代中,最後卻搞不定等等。

遇到類似這些情況,該怎麼辦呢?這裡我不想教你具體的解決方案,而是想教你如何引導團隊解決問題的思維。

如果這個所謂的錯誤並不會帶來毀滅性的災難,比如導致用戶大規模投訴,或給公司帶來巨大的經濟損失,那麼我會選擇放手讓團隊去按自己的想法先做一做,即使碰個壁也未嘗不可。事後我們再坐下來認真分析到底怎麼做才是對的,引導團隊想出新的解決方案。有了這樣一個試錯的過程,團隊通常會將經驗教訓記得很清楚。

另外,配合著團隊敏捷試點,我會讓團隊通過“成績牆”和“錯題集”在敏捷推進過程中記錄自己的心情曲線,記錄自己的喜怒哀樂,記錄取得的成績和錯誤,所以這其實也記錄著團隊的成長。

團隊有任何大大小小的進步和成績,我都會讓團隊順手記錄下來,貼在一面小小的“成績牆”上。同樣,我們也將自己遇到的問題和坎坷,以及解決方案也順手記錄下來,貼在另一面小小的牆上,構成一個“錯題集”。這樣團隊成員時不時經過它,都會很生動地想起在我們敏捷實踐的過程中都發生過什麼。在敏捷試點結束的時候,我們也會把試點總結裡成功的經驗和失敗的教訓寫到這裡。

這樣做有很多好處,首先團隊會一直感覺到敏捷氛圍的存在,有精氣神兒;其次,以後有團隊請我們去宣講時,我們很快就能找到素材,也能繪聲繪色地傳達給大家;再次,團隊記錄的心情曲線、“成績牆”和“錯題集”,這些都是試點結束後在做總結時,記錄團隊敏捷成長歷程的鮮活的素材,是團隊敏捷實踐的軌跡。

另外我自己在深入進行敏捷實踐的同時,接觸了很多國內的研發團隊,這些團隊的規模不等。他們的共同特點是很努力,但也存在很多問題。比如:

  • 初創團隊,沒有任何成熟的管理實踐,想到哪裡做到哪裡,研發管理相當混亂;
  • 有的團隊已經經歷了前期的混亂,想著要正規一些,就傾全公司之力引入 CMMI,導入瀑布流程,導致整個公司流程過重,交付速度受限制,三個月甚至半年才上一個版本,業務部門相當不滿意,項目團隊成員也怨聲載道;
  • 有的團隊聽說現在流行的方式是敏捷,於是拿書來看,自己琢磨,炮製了一套敏捷流程,結果根本不適合自己團隊的業務模式。

作為敏捷諮詢師,我給上百家公司做過分享和敏捷教練,目睹了各種各樣公司在推進敏捷開發過程的疑難雜症,我一直想把自己的經驗總結出來,幫助敏捷團隊和個人真正解決實踐中的痛點,於是我和極客時間團隊決定打磨一個把敏捷講透的課程。

現在市面上有很多關於敏捷的書,會講一些基礎知識和理論,但是敏捷畢竟有很強的實踐性,只了解理論是不夠的。以我個人的經歷來講,想要真正理解並接納敏捷,你需要真實的案例來輔助你對它的理解。

鑑於此,我和極客時間團隊一起打磨了你現在看到的《說透敏捷》專欄,我將結合實際案例來揭示這些年來自己對敏捷的研究和實踐,手把手幫你定制敏捷實踐計劃。

👉點擊「鏈接」,立即全方位了解敏捷開發。