BB-Talk 002回顧 敏捷實踐,你可以繞開一些彎路

前言

BB-Talk 是什麼?

BB-Talk 是由Worktile 特別推出的線上分享活動,聚焦互聯網時代更高效的工作流,橫跨TMT、電商、律師、教育等各行業,覆蓋研發、產品、設計、市場、運營、HR、行政等各職業。

每期邀請一位相關領域的大牛嘉賓,通過微信群內的語音、文字、圖片等形式,分享乾貨、自在交流。

本文為7月5日BB-Talk 第二期嘉賓分享與互動提問的總結。

本期嘉賓

特里斯譚,時代光華大數據團隊負責人。

企業內部分享達人,連續三年優秀員工。

CSPO認證,3年時間從0到1完成團隊敏捷轉化,打造了兩個不同的敏捷團隊。

內容概要

BB-Talk 第一期之後,大家了解了Scrum 的框架,清楚了敏捷開發的主旨。這些聽上去都很有道理,But 實踐起來卻未必輕鬆。老闆和高層,PO 和 SCM 對敏捷成功到底有重要的影響?你真的需要拆分並估算出每個任務的工作量嘛?在向敏捷轉型的過程中,工具應該扮演什麼角色?Worktile 在實施敏捷的過程中發揮了怎樣的作用?

本次分享嘉賓特里斯譚經過幾年和團隊的打磨,希望通過若干個大大小小的項目實踐經驗和你分享敏捷實踐的點點滴滴,給你一些啟發,幫助你走上正確的實踐敏捷之路!

分享內容

大家好,我是上海時代光華的特里斯譚,也是Worktile 的深度用戶。最近Worktile 針對研發行業打造了從 研發流程管理到 工作效率評估 的一站式研發解決方案,其中就包含了敏捷開發管理。我作為一個敏捷的信仰者,今天就想跟大家聊聊自己的敏捷實踐經驗。

我的觀點

實踐敏捷,實際上真的是需要大家重視、並真正去身體力行的一件事情。有意義的敏捷實踐一定是圍繞人這個因素展開的、是以提高用戶價值為目的的迭代式的活動。人、用戶價值、迭代,這三個詞幾乎可以代表著敏捷的核心的理念和觀點。

我的經歷

我大概是13年底開始接觸敏捷,到現在為止近3年的時間。

初次嘗試敏捷,公司想要把整個研發中心轉型到敏捷的過程當中,主要是為了解決加班、團隊人員不穩定、團隊質量不好等一系列問題。這一次的嘗試最終以失敗告終。

第二次嘗試是2014年5月至2015年2月,我帶著一個七、八個人的團隊實踐敏捷,初期我們有一定成果,但最終結果仍然是失敗的。

經歷了這個前兩次的失敗和教訓也好,然後就迎來一次機會。在15年3月份,我帶領一個15人左右的團隊,開始使用一些敏捷的方式,形成一些團隊規則。我們大概用了兩個月的時間,完成了公司戰略級移動端版本的迭代。

15年11月,我們再次做了內部轉型。我們開始用電子看板,嘗試拆分一些主板的團隊。團隊成員漸變成自組織,這些事情貫穿起來,就是我的敏捷實踐之路。

我眼裡的敏捷

其實敏捷實踐就如談戀愛一樣,你和你的團隊關係,或者你的團隊在實踐中的關係,就像是兩個人的戀愛關係,我把它分為三個階段。

第一階段,初戀期(將敏捷導入團隊)

在從0到1實踐敏捷的前提下,大家會發現成員對敏捷的認知是不一的。敏捷千萬不要自己玩,不要覺得我是開發,我把開發帶進來就能玩好了,我建議大家把更多角色都帶進來。不管是研發、測試、產品或者是設計師,所有的相干者都需要達成一致之後再開始做。否則的話,這件事情最終達到的結果就會與預期相距甚遠。

敏捷,就像是一場改革,需要一個推動者來推行改革的環節。而且這個推動者的職位越高越好辦事。我看到很多公司CTO或者是老闆,直接就說我們把敏捷實踐的非常好。如果從開始就有一個非常好的環境的話,往下推行這件事情相對來講會變得順利。

第二階段,熱戀期(磨合、並且逐漸走向成熟的階段)

如果你挺過了第一個階段,會發現在這個時候你的團隊會對敏捷有一定的認識、開始嘗到甜頭,並逐漸形成固定模式。

其實大多數的成員已經對敏捷的框架方法有了一定的了解,並且開始執行起來。其實大多數的團隊只要做兩、三個月之後,可能就會進入到這樣的階段,或者說他們更順利的話,很快就可能達成一致。這跟團隊的規模是有關的,團隊人員少就越好控制。敏捷實施的效果和團隊成員默契度有非常大的關係,若團隊關係非常好,就越快趨於成熟。

另外,在新人加入的時候,是對這個團隊的一個考驗。如果新人加入你的團隊後,能夠非常迅速的過渡到成為這個團隊的成員,這證明你的團隊是一個良性的團隊。而且敏捷在這個階段會開始有一定的影響力,你會漸漸的發現,大家的抵觸情緒慢慢消失,並且團隊成員的敏捷精神開始相互傳染。

第三階段 —— 穩定期(形成團隊默契):

進入這個階段可以說是一個成熟的標誌,也是大家都很嚮往的一個理想的狀態。在這裡其實要注意的是,如果你一直管或者一直來維護這個團隊的話,在我看來這並不是什麼好事。應該要不斷的給團隊成員更多的自主權。如果團隊磨合得好,盡量去適當放權,讓他們自主去做決策、做優化。

每個人都是渴望成長,每個團隊成員都是渴望挑戰的。他們不喜歡去做重複的意志。而你需要更宏觀的站在團隊的組織者,甚至一個領導者的心態去看整個團隊的發展。達到這個階段,你是需要為團隊爭取一些更好的利益,這是走向下一步的基礎,比如選擇一款合適的工具來幫助團隊更好地實施敏捷。

這裡給大家分享一下我們團隊Worktile 看板。我們在敏捷實踐中逐漸由實體看板轉到電子化的看板,Worktile 給到我們團隊一個非常好的輔助作用。

依據Worktile 本身看板管理的特性和任務驅動的方式,可以很好的將一些進度和概要信息展示出來。通過這個看板大家可以看見我們團隊的工作流程,大致分為「待開發」、「進行中」、「已演示」以及「待發布」。整個流程對我們團隊的所有成員而言都是清晰可見的。項目看板上的列表直接就能展示我們團隊的進度和階段,也能很好地實現整體進度和個人進度的統計。

同時,Worktile是一個非常靈活化的工具,它的自定義設置留給我們很多實現團隊個性化特色的空間。在敏捷實踐當中,選擇合適的工具能有效提升整個團隊的工作效率。

我的敏捷實踐心得:

很多人可能會問到底什麼才是敏捷?我們是否敏捷了?其實敏捷就是從最小的事情開始。比如說你一開始沒有每日站會的時候,突然開始做站會了,大家一起每天來探討自己的工作,而且在固定的時間裡,給大家互相交流的一個機會。這就是敏捷的一個開端。

敏捷的成功實踐一定是十餘人的,你要搞定的是你的團隊文化和領導,這件事情是需要你去一點點做的,否則你會碰到很多困難。

另外,我的經驗告訴我,其實敏捷一開始真的是不需要扁平的。很多時候我們會疑問公司職能化太嚴重了是不是不能做敏捷?其實不一定。當敏捷開始做起來、並且讓團隊成員享受一些甜頭之後,你會慢慢的發現,你的團隊自然就扁平了。你的部門、你所管轄的這個領域也就扁平了。

小團隊需要注意的是,不管多小,每個人都需要有跨職能的能力,每個人都應該具備多種技能。最後一點是團隊成員必須要保持學習心態,有奉獻精神和責任心。

Q&A

Q1:寄快遞的問題有些像福特創造的流水線模式,雖然模塊之前是相關的,但是盡量分拆然後降低模塊之間的耦合,每個人專心做一個小模塊。敏捷就是小而快,是這樣嗎? @REVEES

A:寄快遞的故事就是告訴大家,每個人分工做不同的事情會增加溝通成本,反而阻礙整體效率的提升。如果我們每個人獨立負責,信息透明,那在工作執行的過程中會更加清楚地知道工作進展以及問題所在,這樣反而能快速解決問題,完成工作任務。

小蝸提示:Worktile 企業版所具備的任務看板、日曆、網盤等功能,可以確保公司每個人在需要信息的時候都知道去哪裡查找,都知道可以向誰諮詢。它能幫助公司成員消除一切在交流和獲取信息中可能存在的障礙,讓團隊更加開放透明。

Q2:請問敏捷實踐中,您認為搞定人是第一關鍵因素,那麼僅次於它的因素是什麼?可否簡要談談? @邵智康

A:搞定了「人」這個最重要的因素之後,就需要合理使用工具和方法來更好地實現團隊的敏捷,從細節問題著手,保證整個團隊的有效溝通。

Q3:敏捷團隊的考核方法是怎麼樣的,如何避免考核對團隊成員的「傷害」? @zwtforward

A:每個團隊定好目標之後,一定會有燃盡的,每天更新迭代燃盡圖就是一個很好的考核標準。想要避免傷害,我認為最好的方法就是把醜話說在前頭,儘早提出執行規則和懲罰措施。

小蝸提示:以往我們需要通過Excel 的記錄生成燃盡圖,或者是在一張白板上手工繪製燃盡圖。但是在Worktile 中,系統會根據項目中任務的新增和完成狀態,自動生成燃盡圖。Worktile 所具備的強大的項目可視化統計功能就是在「不傷害」團隊成員的前提下把目標過程進度展示給所有人。

想要詳細了解,可以點擊 一站式研發解決方案

Q4:驅動敏捷團隊前進的動力是什麼,僅僅是畫餅是不夠的? @zwtforward

A:畫餅是沒有用的,高效的協作和實現個人成長才是驅動敏捷團隊前進的動力。

Q5::我發現對於每日站會而言,用實際的白板大家關注度和默契會高些,電子白板的使用過程中感覺有些流程化了。不知道您對這個怎麼看的,能都分享下你的團隊如何使用電子白板來默契地開站會的? @劉易鑫-知康-產品

A:看板是非常有用的,從短期來講能增加團隊的儀式感,這個儀式感對於敏捷實踐來講是非常重要的,從實體看板轉為電子看板實際上是讓這項流程更加高效。

Q6:對於定製項目,可以談談敏捷團隊里如何在項目簽合同前評估成本和報價,執行中如何控制成本?

A:關於評估成本和報價,其實它真的不是敏捷解決來的,而更多的是依賴於整個的環境。 @養貓的-鏟屎官

Q7:敏捷開發過程,如何做詳細設計呢? @戴小冬

A:詳細設計和概要設計一般都是PM 或者項目管理里的概念。敏捷跟設計詳細流程實際上是沒有關係的,它更多強調的是讓大家互相形成一個高效溝通的模式,它並不依賴於詳細的文檔。用戶想要的東西更多是在迭代過程當中慢慢形成的,這個過程一直是變化的。


推薦閱讀:

敏捷管理初期出現的常見問題
如何能讓開發效率快10x倍?
如何看待重型敏捷管理框架?
敏捷實際是迭代的瀑布模型的變種,這種觀點對嗎?

TAG:敏捷 | 敏捷认证 | 团队协作 |