【51CTO專稿】敏捷開發方法的流行正是因為大家發現了傳統瀑布方式無法適應從改變，革新而驅動企業的動態管理。如何在項目開發中能持續滿足不斷變化的用戶需求讓越來越多的開發和管理者受到了重視。敏捷開發成為了眾多團隊的制勝之道。下面，我們專訪了北京迅思威爾科技有限公司的資深敏捷教練袁斌老師給網友們分享了敏捷在項目實踐中的一些經驗。

[[68701]] 

袁斌，工學碩士、MBA， Scrum、AUP、Agile modeling、XP、kanban等資深實踐者，資深敏捷教練。近20年中就職于全球性公司從事軟件和產品的開發。曾任Anoto產品和Mino產品中國區軟件開發總監，利用Agile & Lean實現產品快速交付，應對變化的需求。超過8年敏捷開發&精益開發的實踐過程中，在電信行業、外包團隊、互聯網產品等多個行業積累了豐富的經驗。

以下是視頻采訪文字實錄：

記者：51CTO的網友大家好，今天我們請到的嘉賓是北京迅思威爾科技有限公司的資深敏捷教練袁斌老師。跟我們講解敏捷開發項目實踐中一些主要問題，以及對未來幾年敏捷發展這一塊的一些看法進行分享。首先請袁老師跟網友們做一下自我介紹。

袁斌：大家好，我是袁斌，來自迅思威爾，我自己有超過八年的敏捷的實踐經驗，所以我對自己的定位是一個資深的敏捷實踐者。OK，謝謝。

記者：那么在敏捷當中，很多人都看到了它的成本控制，它能夠降低項目開發中的一些浪費。但是往往適得其反，不但沒有降低，反而增加了開發成本。在開發成本控制這一塊，你怎么去理解？

袁斌：其實對于成本來言，每一種新的方法一定會有它的學習曲線和學習成本，往往在開始的時候，它的結果會比現有的情況還要糟糕，它會有一個U形的曲線。所以這里面更多的是怎么樣降低你的學習成本和學習曲線。如果在最開始使用敏捷的時候全盤采用整個敏捷開發實踐集合，較高的學習成本和學習曲線會使實施敏捷的效果大打折扣。所以我這里的建議是，對成本控制而言，首先找你在研發過程中間最大的痛點，在痛點的基礎上，然后在敏捷開發的眾多實踐里面去找針對這個痛點的實踐集合。這個實踐集合的原則就是學習成本要低，而且它能夠持續改進，對你的痛點起的效用最好。這樣的話，不斷地改進，持續控制成本，就可以獲得讓人滿意的投資回報率。

記者：在敏捷實踐過程當中，是否使用到一些敏捷工具，能否推薦一些比較好的工具？

袁斌：敏捷工具是這樣考量的：看你產品的周期，如果你產品周期相對比較短，比如說你兩三個月，那么我個人并不建議用敏捷工具來考量、管理你的敏捷開發的過程。如果是周期比較長的話，我是建議用敏捷管理工具。因為原因主要在于，第一，你要去積累很多數據，這些數據會有利于分析你的過程中間，哪些是好的？哪些是不好的？，然后有針對性的改進；第二，對于整體的需求管理，包括你一些技術方案的管理，需要一個工具能把它整體管理起來。

記者：在項目當中，敏捷測試人員的職責和一些技能的要求是什么樣的？

袁斌：我覺得在敏捷的開發過程中間，測試人員更多的是能夠幫助團隊，幫助團隊最后的交付能夠有一個保證。所以說敏捷的測試人員首先應該是盡早測試，更早地在測試周期的前面進入。比如說在一個迭代開始的時候，在計劃會議他就能夠介入，他給出很多從用戶層面對需求的看法，能夠幫助團隊更好的了解需求。同時通過把握測試的風險，盡早的給研發團隊“bug出現風險高”以及“用戶使用頻率高”兩個層面的用例，幫助團隊控制研發過程中間的風險。

我覺得還有一個很重要的是持續地測試，能夠去幫助團隊，特別是研發團隊，不但是說我能夠盡早，而且不斷地持續地進行這些測試，及時的把風險反饋給研發團隊。

記者：據我了解，很多朋友說你在測試這一塊，好像是他們不需要專門的測試人員，你覺得這樣的公司對于開發一個項目的時候，有沒有什么影響？

袁斌：有一些公司會有，比如說像Facebook，它會說我沒有專職的測試人員，它是工程師文化。但我個人認為在我看到的很多項目里面，測試人員是必要的。我說一下我的觀點，我覺得如果沒有測試人員對工程師的要求非常高，因為他要承擔專業測試人員的技能。

記者：對他個人的一些技能，什么要求都會高。

袁斌：對，我覺得術業有專攻，測試人員更多的從用戶的場景對產品進行測試，特別在非功能性需求的測試，這方面的專業技能要求也是很高的。

記者：做到敏捷開發，每個團隊都要經歷一個轉型期，在轉型期還需要每個團隊根據自身的不同找出合理有效的解決方法，一般是如何處理這個問題？

袁斌：團隊在做轉型的時候，我們看到的很多團隊，包括我們自己的客戶，最大的問題在于，敏捷開發有很多的實踐，如果把所有的實踐都拿過來。然后全部用在團隊中間，但是每個實踐都有學習成本。所以說都拿過來以后，團隊很抵觸，而且也不能解決團隊的實際問題。因為太多了實踐以后，大家覺得很疲憊，有時候適得其反。我個人的建議是這樣子，在轉型期的時候，用痛點驅動的方法。所謂痛點驅動就是，找到團隊目前一個很嚴重的痛點，在敏捷實踐中間，找一些實踐集合，不要全都找，是找一些實踐集合，去把痛點解決掉。然后再看下一個迭代的時候，繼續找目前最大的痛點，然后再用一些實踐集合把它解決掉。你不斷地這樣去做的時候，團隊抵觸很小，他覺得OK，把我的實際問題解決掉了，他會很愿意采納敏捷。

記者：您剛才說痛點驅動，能否解釋一下？

袁斌：所謂痛點驅動，痛點其實就是最大的問題，是我在研發過程中間碰到的最大問題。比如說我可能在這個過程中間，我最大的問題是迭代交付延期。

記者：延期？

袁斌：對，我延期了，也有可能最大的問題是對需求了解很差，或者說人員流動是一個最大的問題。那么比如說人員流動是一個很大的問題，這個時候敏捷實踐里面，你不見得非要用測試驅動開發，要用用戶故事描述需求，可能是結對編程，可能是團隊的代碼負責會更有效。也可以強調計劃會議里面整個團隊都要參加討論，減少學習債務。這些實踐可能是對你當下的痛點會有更大的幫助，建議首先采用這些實踐，我的觀點是這樣的。

記者：敏捷過程當中，我認為最重要的是一個需求、拆分與分工，你能談談如何進行它需求合理地拆分，以及分工嗎？

袁斌：我的觀點是，如果是需求的話，盡量采用一種拉的方式，所謂拉的方式是說，我們研發的流程就是從需求分析、再到設計、編碼測試、然后交付客戶。我的觀點是，我們應該是從客戶這一端開始，客戶這邊認為，他最需要的是哪些需求，然后對這些需求做比較詳細地拆分。所以這樣在Scrum里面，它有一個叫做Product Backlog，翻譯過來叫需求列表。

這個需求列表里面高優先級，一定是客戶最想要的，所以需求拆分我建議從高優先級的，對用戶價值最大的需求拆分會比較好一點。

記者：在敏捷開發過程當中，Scrum和XP，也就是說我們說的直線編程，在國內據我了解，使用Scrum占了大部分。

袁斌：沒錯。

記者：你能介紹一下Scrum和其他幾件方法最大區別在哪里？如果是Scrum，它的優勢在哪里？

袁斌：其實Scrum最主要的特點在于說，它是個輕量級的框架，通過短周期的迭代，交付最有價值的產品，可以從容應對變化的需求。它最大優點我認為是，它沒有介紹很多的實現細節，具體要做到怎么樣去交付一個很有價值的東西，它沒有想洗介紹。我認為這可能是它最大的缺點，也是最大的優點。它可以包容很多其他的方法，比如說像極限編程（XP）。它可以把XP里面很多的工程實踐融進來，幫助它提高交付質量，而且它可以包容像精益軟件開發，消除研發過程中的浪費。所以Scrum，我認為它最大的優點，是個輕量級的框架，易于包容。而且從另一個方面說，在國內能夠很好地流行得益于它是一個管理型的方法。其實Scrum是偏向于敏捷的項目管理，項目管理在國內很容易獲得認可。所以我覺得它在國內能推的比較好，這兩點是比較重要的。

記者：極限編程比較注重細節方面的一些問題，可以這么說嗎？

袁斌：極限編程中的工程實踐很有借鑒性，但是對于工程師本身的要求相對比較高。Scrum相對而言對工程師的要求沒有那么高。

記者：就是說一般我們國內一些創業型的公司，它的項目都可以用Scrum的方式。

袁斌：一般而言是可行的。同時Scrum不但用在軟件產品的開發，還有很多其它的行業都可以用Scrum。

記者：就是說不僅僅限制在軟件開發這個行業里面？

袁斌：沒錯，是這樣的。

記者：那么如果能得到準確的數據支持，敏捷實施能夠更好地發展下去，敏捷實踐下的員工，程序員的工作指標如何衡量？

袁斌：我明白你的意思。我們的實踐中間是這樣子，把程序員的工作指標分為兩個部分，一個部分是團隊，我們首先不關心每一個人工作量多大，我們想要關心這個團隊的每次交付，是不是可以接受？這樣大家會有一個團隊的概念，整體的概念。另一個部分，我們需要關注個人，關心個人的時候，一般會關注四個層面，第一個是工作質量；第二個是工作量；第三個是主動性，因為敏捷開發里面，短周期的迭代，對風險地控制要非常高，要求主動溝通的意愿要很強，有助于風險前移；第四個我們認為是幫助，就是幫助團隊，

記者：當一個敏捷團隊工作時，有時候他的項目流程會暴露出來，也就是我們常說的項目透明化，這是不是可以稱為敏捷開發流程的一個過失，或者是說你對于項目透明化有什么見解？

袁斌：首先項目的透明化在敏捷開發里面，他要求的非常高，在我們的實踐中間會發現，如果你把這個項目透明了，你會減少很多溝通的成本和障礙，現在我們能看到的項目透明化方式更多的是白板。

無論是物理白板還是電子白板，大家把這個項目放在透明的環境里。很多的團隊會做一個項目墻、任務墻，把所有的狀態在墻上布置下來。還有一種方式就是電子白板，電子白板有很多的工具。

這兩種方式都可以把你的項目風險暴露出來，項目透明化以后，其感興趣的項目干系人都會來幫助我們這個團隊，發現項目可能潛在的風險，同時會幫你解決掉。

記者：對，在Scrum會議的實踐實際上是實踐控制當中最重要的一件事件。

袁斌：沒錯。

記者：這更是團隊做改進最佳的時機，那您認為Scrum會議在團隊當中如何建立起來？在Scrum這塊非常看重它有一個回顧會議，這個如何進行？

袁斌：回顧會議其實在Scrum里面起到了持續改進的最用，敏捷非常強調持續改進。

回顧會議在Scrum里面是持續改進的一個非常好的機會。但是現在能看到的是，回顧會議有很多時候團隊流于形式了，覺得開的沒有必要。更多的情況下我認為是，這時候回顧會議沒有起到應有的作用。我認為一個回顧會議開的比較好首先是數據驅動，所謂數據驅動就是，我們通過數據去得到這個迭代里面哪些是最大的問題。找到問題以后，團隊去分析它的根本原因，再去找到它的解決方案。然后把兩三個好的解決方案，在下一個迭代里面去把它固化。回顧會議最核心的是根本問題的發現，所以我個人很推薦使用數據的方式。比如說Bug分類，計劃和實際的偏差。比如說你每天八個小時的工作時間，你是三個小時有效工作，其他的五個小時我們可能會分析浪費在哪里？這些點都會把問題暴露出來。

記者：在Scrum會議中，除了回顧會議以外，還有沒有其他的一些會議？

袁斌：就是Scrum里面？

記者：對，Scrum里面。

袁斌：Scrum里面其實有幾個比較重要的會議，第一就是它的計劃會議。在一個迭代開始的時候進行。計劃會議是怎么樣保證在迭代過程中間能夠把所承諾的東西高質量的交付。第二個推薦的會議是每天早上的一個站立會議，15分鐘。這個站立會議可以和我們前面你提到的白板一起使用，做到項目透明化。站立會議如果想開的好，最好所有成員在白板前面來開。這時候每一個成員都會把各自的工作狀態和風險在白板上暴露出來。

還有一個會議是評審會，在迭代要結束的時候，我們來看這個迭代的交付是否能夠滿足迭代最開始的目標。然后就是回顧會議，回顧會議是最后我們要看哪些做的不好？哪些做的好？在下個階段如何改進。

記者：在目前國內出現很多敏捷教練這個角色，您是一位資深敏捷教練，你認為敏捷教練在一個團隊中，他主要的工作有哪些？而且敏捷教練在Scrum工作中建立起一個角色的轉換。

袁斌：我覺得是這樣，一個教練在一個團隊里面，他最關鍵的是隨時能夠幫助敏捷在團隊里面能夠落地，包括敏捷的思想，敏捷的實踐，能夠讓它落地。如果再細里說的話，它是能夠幫助團隊，通過敏捷的思想和實踐解決團隊現有的問題，這個也是我自己實際中的做法。也就是說，敏捷教練和團隊一起來工作，通過敏捷的一些實踐，也包括其它開發模式的優秀開發實踐，來幫助團隊解決問題。這時我認為敏捷教練最應該做的。

記者：在項目中他是一個不斷持續改進地過程，不能按部就班地說，敏捷是怎么樣就怎么樣去要求他們這么做。

袁斌：對，因為很多敏捷實踐背后是有假設的，它假設團隊成員的技能達到什么程度，假設公司的文化會如何支持尊重、平等，但是這樣的假設如果在項目中并不存在，如果我們把這些實踐照搬過來，一定會有很多的沖突。

記者：在對未來幾年敏捷開發的發展希望看到哪一些方向？

袁斌：我覺得未來幾年，我的希望是，敏捷可以來落地，它可以真正幫助團隊解決實際問題，提高他的質量，提高他的效率，提高他交付的商業價值，這是希望看到的。第二個就是說，我非常希望大家忽略敏捷這個詞，不再是說，我用敏捷了，或者說我沒用敏捷，而是說把敏捷這些實踐和它的思想，甚至于說，我們基于它的思想，同時基于我們這個團隊的現狀，做一些定制化，形成我們自己企業和團隊的一套方法。然后我把它落地了，給團隊帶來實際的好處，我們不再談是否敏捷，而是實實在在地在持續改進。

記者：好了，我們今天的采訪就到這里，今天非常感謝袁斌老師跟網友們進行分享了一些，敏捷開發在項目實踐過程當中的一些主要問題。謝謝袁斌老師。

袁斌：謝謝師授，也謝謝51CTO這個平臺。