敏捷是什么？為什么要使用敏捷項目管理？

分享嘉賓：大懶

大家晚上好，有幸接受這個邀請，去給大家說一說，就是關(guān)于敏捷的事情，敏捷這點兒東西呢，我其實也是一個失敗者。但是呢，在失敗的過程里面也找到了一些正確的方法，希望能通過這個機會呢，把更多的信息告訴大家。

1、什么是敏捷

很多老板在選擇用怎樣的開發(fā)模型去開發(fā)，特別是開發(fā)軟件的時候，總有這樣一個誤區(qū)。我們使用了敏捷方法之后，可以更快的去交付產(chǎn)品，可以縮短產(chǎn)品研發(fā)的生命周期，可以節(jié)省成本。這個理解是有偏差的。

首先給大家說明這個問題，敏捷不一定會很快。

為什么不一定會很快呢？假設(shè)我們是一種迭代開發(fā)的模式，我們用很多的迭代去開發(fā)同一個產(chǎn)品，大家想象一下，是不是每一個迭代里邊都會有一個小瀑布呢，那么在每一個迭代里面的測試，開發(fā)，設(shè)計，這些環(huán)節(jié)是不是都要重新再來一遍呢，所以說敏捷，它不是一個能夠更快交付的模型，而是一個能夠更頻繁交互的模型。

第二，敏捷不一定會節(jié)省成本。

其實明確的說，敏捷這件這種行為是非常昂貴的，這與他的研發(fā)模式和行為方式有關(guān)系。待會講到敏捷需要一個什么樣的團隊，敏捷會需要什么樣的測試方法，或者是成本核算方法。包括風(fēng)險識別方法，包括需求控制的方法，對這些方法的使用過程里面可能會產(chǎn)生額外的成本。而這些成本會造成敏捷的成本相對增加。

但是呢，敏捷不是為了節(jié)省成本和快速開發(fā)縮短開發(fā)周期而誕生的。

2、為什么要使用敏捷

我介紹一下這個敏捷模型，這個模型能很好的告訴我們，為什么要使用敏捷去解決問題。

這個東西就叫Stacey矩陣，或者叫Stacey模型。

這個模型里面分四個部分，一部分叫Simple，just do it。第二部分叫Complicated，然后空白的部分叫complex，右上角那個我把它叫混沌，混沌的問題咱們不去討論，實際上我們在軟件開發(fā)里面，要做的事情就是三體里面講的，叫降維打擊。

在這個過程里，我們將復(fù)雜的東西劃到一個相對簡單的區(qū)域去解決。然而呢，對于一些很復(fù)雜的情況，比如說，我們需求很不確定，我們也不確定用什么方法去做這些事，我們就用敏捷方法去做。敏捷方法是什么呢，就是持續(xù)學(xué)習(xí)，持續(xù)迭代，持續(xù)規(guī)劃這樣一個方法。

這是一個實用的非預(yù)定義過程。

有同學(xué)問，敏捷項目和傳統(tǒng)項目的區(qū)別，如何進行混合應(yīng)用，相互取長補短？傳統(tǒng)項目即預(yù)測型項目。

我們在預(yù)測性的項目里，做的事情是這樣的。首先有一個發(fā)起人，然后我們做一個詳細的計劃，然后強制團隊，或者說責(zé)令團隊按計劃去進行，然后在中間控制變更，按規(guī)定測試，結(jié)項等等，最后交付產(chǎn)品。

然而，敏捷不是這樣的，一個敏捷軟件的開發(fā)往往在敏捷初期，是不會預(yù)見到幾個迭代之后的軟件需求的。它往往是，以最小可行性產(chǎn)品，MVP，去交付給客戶。也就是說我們用最基本的模型，最基本的能用的東西給客戶去用，從而不斷的得到客戶的反饋，不停的迭代，改進，或者重構(gòu)。這就是擁抱變化，或者叫檢查和適應(yīng)，敏捷和傳統(tǒng)項目的一個比較好的區(qū)別的詮釋。

所以敏捷，其實是一種輕量型的，最開始確實是用在軟件上的，軟件開發(fā)原則。它是一種方法，一種思想，是一種迭代的研發(fā)模式，而且是增量的，是一種一定時間盒的，以價值為中心的。

敏捷是一種適應(yīng)復(fù)雜情況、不靠譜客戶的，一種持續(xù)學(xué)習(xí)，持續(xù)增量的迭代模型。

敏捷有一個特別著名的東西叫做敏捷軟件開發(fā)宣言，這個當(dāng)時在2001年發(fā)布的時候，推動了硅谷的一個改革。

http://agilemanifesto.org/iso/zhchs/manifesto.html

敏捷宣言里面提到了四點價值觀，這四點價值觀大家看看就行了。他最重要的一句話，盡管右向有其價值，我們更重視左向的價值。說白了就是，你一切從客戶出發(fā)，一切從變化出發(fā)，一切從成果出發(fā)，一切從價值出發(fā)，比你那些花里胡哨，按規(guī)定來的這些東西，更有價值。

它是一種價值觀，也代表了這一幫人的一種處事方式。

3、 敏捷Scrum框架

下面介紹一些敏捷的方法，因為它是一種價值觀，是一種思想，所以說有很多大牛，開發(fā)了一系列敏捷框架。

目前有有記載的，著名的敏捷框架有30多種，非著名的那可能好幾百種都有。今天主要介紹就是那朵云彩，Scrum框架。

Scrum框架是在當(dāng)今的軟件開發(fā)界里面應(yīng)用得比較廣的一種框架，也是國內(nèi)能看到的，大多數(shù)的敏捷在線項目管理工具的范本。

目前這個框架呢，有一個叫Scrum聯(lián)盟的組織，在負責(zé)維護和管理。這個組織，每年會有一些認證，每年開一些會議，會定期地去更新這個框架。最新的這個框架A4紙打印出來只有27頁。大家可以看到其實沒有什么內(nèi)容，里面寫的就是一些原則和方法。

Scrum框架的思想來源于一個著名的思想叫精益思想，這個思想是豐田在上世紀80年代提出來的。這個思想有兩個重點，一個叫，respect people，尊重人；另外一個叫Continuous improvement，也就是持續(xù)改進。實際Scrum框架也是秉承的這樣的原則。

Scrum框架大概是長這個樣子的。它里面有一個3355的原則，就是三種角色，三種工件，五個會議，五條核心價值觀。

1.第一個"3"

左上角這三個圈兒就是我們所說的這個3355中的第一個3就是三種角色，在Scrum這個框架里面我們會給團隊分配這三類角色，第一類叫Scrum master，不是一類啊，這是一個人；第二類叫產(chǎn)品負責(zé)人Product Owner；第三類叫團隊，Team。

Scrum master在這里不是項目經(jīng)理的意思，他更像是這個團隊的保姆，他要負責(zé)整個團隊的鼓勵工作，為團隊服務(wù)，給團隊提供理論支持，引導(dǎo)團隊。更像是教練的一個工作。

Product Owner是這個Scrum團隊里邊兒一個經(jīng)過授權(quán)的人，他負責(zé)的是整個產(chǎn)品。整個產(chǎn)品開發(fā)做什么，不做什么，哪一部分在哪個時間點交付的這個工作，也就是說，負責(zé)構(gòu)建產(chǎn)品待辦列表。

在Scrum里頭，這個團隊是近似于全功能的跨職能團隊，其實敏捷對團隊的要求是非常高的，這也是他成本高比較貴的原因之一。

舉個簡單的例子，我們可能會在敏捷團隊里面要求產(chǎn)品開發(fā)人員去編寫測試用例，甚至是去執(zhí)行這樣的測試用例。甚至是我們測試人員也要去寫這種行為分析用例，要寫代碼。所以說最理想的Scrum團隊的Team，每一個人都應(yīng)該是通才。

上面這一段就解決了“常用的敏捷架構(gòu)是什么樣的，團隊是什么樣的”這個問題。其實我覺得任何一個團隊都有可能會去變?nèi)マD(zhuǎn)化成自己的團隊，只要你有合理的配置，然后一個足夠能引導(dǎo)你進入敏捷開發(fā)空間的這樣一個人就可以了。

2.第二個"3"

Scrum的3355的第二個3也就是三個工件。

①第一個工件，叫產(chǎn)品待辦列表（Product Backlog），它其實有點兒像我們現(xiàn)在產(chǎn)品開發(fā)中講的需求池的概念，通常來講，我們會把所有需求一股腦的扔到這個列表中去，但是這個列表會有一個與傳統(tǒng)的需求池不一樣的地方。這個列表里面所有的需求，都是有價值的，有次序的。

②通過我們價值的體現(xiàn)，包括我們對它的排序。我們就會得出這樣一個結(jié)論，我們應(yīng)該先做什么，后做什么，于是就有了第二個東西，我們叫做Sprint backlog，這個東西，翻譯成中文就是沖刺待辦事項。

③然后我們看第三個工件，在那個大圓圈右邊兒，叫潛在可交付產(chǎn)品增量，這個東西大致的意思是，我們在做產(chǎn)品的時候，是一個迭代增量的過程。

比如說我的需求是通行，從A地到B地，我們傳統(tǒng)的做法是定一個需求，這個需求可能會很大，比如造一輛汽車去進行通行，通常在傳統(tǒng)里面，我們會先造一個輪子，再造一個底盤，然后再造一個殼兒，再往里面填充起來。

但是對于敏捷來講，不是這樣操作的。增量交付一個很好的例子就是這個通行問題，我們先造一個滑板車，先能滿足這個用戶的需求，然后我們再造一個自行車，更加的便利。然后我們再造一個摩托車，最后我們再造一個汽車，最終交付給客戶。

從這一點上我們來看，這個敏捷實際上在交付用戶的使用價值，或者說在交付用戶的價值。

3.第一個"5"

我們在這個敏捷里邊兒有五個會，

①第一個叫Scrum計劃會議，把產(chǎn)品待辦事項列表里面的東西決定哪些可以在Scrum計劃會議里邊兒解決掉。

②第二個會議，我相信很多的企業(yè)，很多的團隊在做，叫做每日站會。

這個站會通常都問什么問題呢，我昨天做了什么，今天我要做什么，我遇到了什么問題，通常都是這樣的對吧。但是我想告訴大家的是，大多數(shù)團隊開這個會的時候，問的這三個問題都是不正確的，我們?nèi)タ丛模?/p>

第一個問題：What did I done yesterday that helped the Development Team meet the Goal?

第二個問題：What will I done today to help the Development Team meet the Goal?

也就是說在敏捷開發(fā)這個環(huán)境里面，我們不會講我做一件事情，做了百分之多少，在敏捷的世界里沒有百分之幾這個概念，它只有零和一。沒完成就是零，完成了就是一。所以他的問題會說，我為了我們團隊的目標，昨天做了什么；我為了我的團隊目標，今天我要完成什么。

③第三個會議叫做Sprint評審，Scrum review。這個會議就是來評價你迭代的這個產(chǎn)品，是不是可以納入到潛在可交付的產(chǎn)品增量，這還是個潛在的，還是不可交付的，經(jīng)過了這個會，你能不能交付這個事兒就能定了。

④第四個會議叫Scrum回顧。希賽發(fā)過一篇文章，里面有一部分講回顧（文章后附該篇文章的鏈接）。那就是敏捷回顧的一部分，叫做帆船工作法，或者帆船回顧，有興趣可以翻回去看一看。敏捷回顧對敏捷這種活動來講是非常重要的，應(yīng)該說是在這幾個敏捷Scrum的活動里面是最最重要。通過回顧，我們不但能夠找到過去的一些缺點和失誤，還能發(fā)現(xiàn)一些優(yōu)點，并持續(xù)的改進下去，這對于敏捷團隊尤為重要，為什么呢，因為敏捷這件事，第二個原則就是要持續(xù)的改進。

⑤第五個會議是一個持續(xù)的活動，這個活動叫產(chǎn)品列表梳理。說白了就是收集需求。因為敏捷相對于傳統(tǒng)開發(fā)，這個需求不是那么穩(wěn)定。但是我們講擁抱變化，我們擁抱變化，不是為了讓需求蔓延。擁抱變化，也不是為了讓項目鍍金，擁抱變化的意思是要讓項目符合用戶的價值，要讓項目達成既定的目標或持續(xù)改變著的目標，我們要對這個需求做調(diào)整，這件事才叫擁抱變化。

4.第二個"5"

對于Scrum來講還有五條價值觀，專注，公開，承諾，勇氣，尊重。

4、敏捷實踐

另外給大家介紹一下敏捷實踐，敏捷實踐是很有意思的，其中有一個叫結(jié)對編程，是極限軟件開發(fā)里面的一個活動，兩個人用一臺電腦去編，一個人寫，一個人看。

這個事兒從敏捷的角度來講，是一個代碼review的過程，實際上是替代了代碼評審。

但是同時還有一個更大的價值，我們把一個初級工程師和一個高級工程師放在一起，這兩個人的水平會無限趨近，水平低的會往水平高的趨近。

Scrum指南的網(wǎng)址有很多版本，大家可以去下載看一看。https://scrumguides.org/

5、QA

Q：敏捷這一概念是否像咱們?nèi)旱目谔栆粯樱阂磺薪皂椖?，是否敏捷這一概念一切都適用？

A：這個不盡然，因為，就比如說我們學(xué)PMP^®，有個事業(yè)環(huán)境因素，意思就是每一種情況，都不一樣，團隊也不一樣，項目也不一樣，實際上我們現(xiàn)在有很多的很多敏捷框架，好像可以解決各種各樣的問題。在敏捷開發(fā)的早期，布道的老師們包括敏捷宣言的翻譯者，給人講課的時候，他說敏捷可能會適用于產(chǎn)品開發(fā)項目和小團隊開發(fā)項目。所以說最初的Scrum文檔里頭，他會講你的團隊規(guī)模要保持到七加減二。

為什么是七加減二呢，因為這個是有一個臨界值，大家學(xué)過溝通管理里面團隊溝通的項目公式N*(N-1)/2。所以七加二，正好是一個臨界點。但是對于現(xiàn)在的項目來講，使用小團隊，小迭代已經(jīng)不能滿足很多企業(yè)的要求。比如說，網(wǎng)易阿里騰訊，大家都在用敏捷的方法開發(fā)大型項目。所以現(xiàn)在有很多的敏捷理論，比如說LeSS啊，比如說SAFe啊，這種理論會支撐著他們?nèi)プ龃笮晚椖康拿艚荨?/p>

敏捷團隊有個行為叫自組織，就相當(dāng)于團隊七個人，每個人都是項目經(jīng)理，每個人都是干活的，每個人都是測試，每個人都是各種各樣的角色。所以說對于敏捷這件事兒來講，質(zhì)量是由整個敏捷團隊來負責(zé)，不是有哪個人去負責(zé)，成果也是有整個團隊去負責(zé)的。

Q：敏捷項目如何做到過程文檔規(guī)范？

A：這個事情我給大家講一個故事，我們在第一次CMMI三級評估的時候，我們把快速模型，也就是敏捷基于Scrum模型的方法融入到了CMMI的方法里面，然后對它進行文檔規(guī)范化。但是這件事兒呢，失敗了，失敗的原因第一個團隊問題，第二個就是他與當(dāng)時的CMMI一些理念，是有沖突的。

那么，對于文檔規(guī)范化的問題呢，敏捷里面有一個這樣的思想：我們所有的敏捷開發(fā)團隊都應(yīng)該有一個信息源。這個信息源應(yīng)該是所有敏捷團隊成員及其相關(guān)的所有成員，包括你的領(lǐng)導(dǎo)們，都能看到。信息源上應(yīng)該有項目里面的能夠展示的所有信息。

我舉個例子啊，如果非要把過程文檔化，我的建議是用系統(tǒng)去做，一個管理系統(tǒng)去做，用看板去做，然后呢，不要太追究這個形式，要看你文檔規(guī)范化管理的目的是什么，是要管控流程，還是要管控某一件事兒，所有的這些東西在信息源上做相應(yīng)的展示就可以了。

Q：敏捷項目和傳統(tǒng)項目的區(qū)別，如何進行混合應(yīng)用，相互取長補短？傳統(tǒng)項目即預(yù)測型項目。

A：這個是很多團隊，包括我在內(nèi)也在不停研究的一個事兒，我的觀點是這樣的，我們適當(dāng)?shù)脑趫F隊內(nèi)推行一些敏捷的行為和活動，從而引導(dǎo)團隊去用敏捷的思想?；蛘哒f相對敏捷的思想去思考問題，在團隊層面上先建立一些敏捷或者敏捷行為的習(xí)慣。

當(dāng)然，在這個過程里面可能會比較痛苦，可能會造成效率的下降，但是這是敏捷轉(zhuǎn)型的一個必經(jīng)階段。在敏捷轉(zhuǎn)型中，授予團隊的首先是行為，然后是理論基礎(chǔ)，然后再是架構(gòu)和方法。我覺得這樣推廣比較好，團隊也能很嚴謹，比較能夠接受。

Q：敏捷項目中的風(fēng)險如何識別和把控？

A：首先從傳統(tǒng)意義上來講，這些風(fēng)險的來源在哪兒，作為一個項目來講，我們風(fēng)險來源無非就那幾項。首先你的風(fēng)險來源肯定會有一個歷史數(shù)據(jù)的風(fēng)險對照表。

那對于敏捷來說，這是什么呢，還記得我們敏捷有一個回顧活動嗎，在回顧活動中，我們會識別一些阻礙，會識別一些暗礁，不知道暗礁是什么同學(xué)，可以補個課https://mp.weixin.qq.com/s/wvnw56ENY0wHYLkUM6yd2Q

這是其中一個來源，另外一個來源呢，我們之前講了敏捷有個sprint計劃會議，在計劃會議里面有很多活動，其中一個活動，就是討論需求的價值。因為敏捷活動需要交付價值，我們在需求層面上要充分討論需求的價值，那么需求的風(fēng)險會降到，怎么說呢，需求變動的風(fēng)險其實很大，但是他可能會降到零概率。

然后就是一些其他風(fēng)險來源，比如說人的風(fēng)險，設(shè)備的風(fēng)險，資源的風(fēng)險。。。這些風(fēng)險，應(yīng)該是能在團隊內(nèi)部消化的。對于控制這樣的風(fēng)險，作為一個敏捷團隊來說，應(yīng)該自己能夠去識別，能夠去控制，而且能夠在會議里面解決掉。

站會要提三個問題，第一個問題：what did I done yesterday；第二個問題：what l will down today；第三個問題：我遇到了什么樣的阻礙和困難。

Q：敏捷項目里面有哪些活動是可以推廣的？

A：最簡單的就是站會，另外一個覺得比較值得推廣的就是用戶故事和用戶故事地圖。

用戶故事從根本上來講就是一個需求，就是作為一個什么樣的用戶，需要一個什么樣的東西，以解決我什么樣的問題。對于敏捷來講，他的需求是有一個invest（要求）的，看下圖

用戶故事有一個3C原則，第一個叫card，也就是說寫在卡片上；第二個叫conversation，對話；第三個叫confirmation。它實際上是寫在卡片上，用來激發(fā)產(chǎn)品或者需求討論，從而達成各方一致的行為。

用戶故事實際上就是這個用戶行為的一個集合，就像這張圖里面，左上角是一個客觀條件，是一個人物畫像，女人30歲，一條狗。然后她起床會做哪些事兒，洗漱整理會做哪些事兒，照顧家人會做哪些事兒，然后哪些事兒是按順序做的。這對于用戶行為需求一樣也適用。

我們擁抱變化的同時，我們就要去適應(yīng)這種變化的發(fā)生，在這個時代很多不確定因素會使你的需求變得越來越不穩(wěn)定。

作為產(chǎn)品經(jīng)理，你的責(zé)任是盡早的去識別變更。而作為研發(fā)團隊，你的責(zé)任是需要使用更靈活的框架，或者不斷的減少你的技術(shù)債，去適應(yīng)這樣的變化。

Q：敏捷項目如何估算確定項目交付期？

A：通常來講，我們做傳統(tǒng)的估算，無非就是經(jīng)驗估算法，Delphi估算法，功能點估算法。我們估算出來的結(jié)果是一個絕對的值，也就是說，我估算的東西，要么是我工程的規(guī)模，要么就是完成這個工程使用的工作量（人·天）。

但是對于敏捷來說，通常來講估算的都是故事點，或者說是一個相對的變量。我會在一個敏捷團隊的內(nèi)部定義一個叫“1”的東西作為一個標桿，然后針對這“1”去做相對估算。

比如說我有一個“1”，我有一個功能，可能是1.5，可能,2，可能是4，可能是8，通過這樣的估算，我們能估算出來我這一些的需求，這一堆的故事需要幾個“1”。

在迭代的初期，我們會試著把幾個這樣的東西放到一個迭代里頭，通過迭代的不停的迭代，兩個，三個迭代之后，這個“幾”能夠放在迭代里頭的這個“幾”，就相對穩(wěn)定了?？赡芪覀兊谝粋€迭代能做八個，放了十個進去，我們只做了八個；第二個迭代我們只往里放八個，我們發(fā)現(xiàn)八個相對也挺高，我們只能做七個；第三個迭代我們做了七個，第四個迭代我們也做了七個。那么，這個團隊的迭代速率就是七。

那對于一個穩(wěn)定的敏捷團隊來說，你知道了你的速率是多少，同時，你也能知道你產(chǎn)品規(guī)模的這些點是多少，那你的交期就可以確定了。

Q：敏捷項目如何快速、準確評估項目預(yù)算？

A：我們用的敏捷估算方法都是很好玩兒的方法，比如說有撲克估算法，T恤估算法，大小杯子估算法等等。

這種敏捷估算撲克是專用的，在網(wǎng)上可以買到。第二個叫T恤估算法，就是用大小來估算，具體方法比較復(fù)雜，大家有興趣的可以去查一查。

話說回預(yù)算的問題，對于敏捷團隊來講，不會做一個初始的預(yù)算，規(guī)定我的預(yù)算是多少，通常來講，我們在項目的初期會訂一個預(yù)算目標。這個目標是一個用經(jīng)驗值來做出來的，或者大家共同認同的一個目標。

那你在敏捷迭代活動中或敏捷開發(fā)活動中，你的所有活動可能就要圍繞著這個目標去做。

Q：敏捷開發(fā)的缺點？

敏捷開發(fā)的缺點很多，我挑重點的說。

①敏捷開發(fā)對于某些團隊是絕對不適應(yīng)的。比如說，一個臨時的團隊，敏捷團隊最好是相當(dāng)?shù)姆€(wěn)定。如果我的團隊里面有個人很不穩(wěn)定，他隨時都可能會離開。那么這個團隊就不適合做敏捷，甚至說我覺得應(yīng)該把這個人提前踢出團隊，再去考慮敏捷這個事情

②然后敏捷對團隊的要求是非常高的，首先這個團隊里面所有人都得水平相當(dāng)，然后所有人的溝通能力和協(xié)作能力都要非常強。

③另外呢，就像剛才一同學(xué)說的，如何做好敏捷文檔規(guī)范化。敏捷宣言里面有句話叫，使用的軟件勝過詳盡的文檔。敏捷對文檔的規(guī)范化或者文檔的作用，看得不是太重，但是實際上它是有一定的文檔規(guī)模的。但是就是這個文檔的不完善，對新加入敏捷團隊的人是一種挑戰(zhàn)，還是剛才那個穩(wěn)定性問題。

文檔的缺失實際上會給后期的維護，二次開發(fā)等等帶來一定的困擾。我會建議團隊去單獨抽出一個人去做這些事情。

④還有一個缺點就是，我見到的大多數(shù)敏捷團隊都有冗長的技術(shù)債要還。就是因為沒有一個足夠靈活的軟件框架來適應(yīng)足夠多的變化。

⑤最后假設(shè)我們不斷給用戶交付用戶覺得有價值的產(chǎn)品，這個時候用戶是持續(xù)滿意的。反之如果我們交付的是用戶不怎么喜歡的產(chǎn)品，用戶是不是就持續(xù)不滿意了。實際上用戶持續(xù)不滿意，還是有去改進迭代的空間。但是我們要考慮到不滿意是因為技術(shù)債，還是因為質(zhì)量崩塌，還是因為團隊不穩(wěn)定，還是因為需求等等。

⑥很多的敏捷團隊還會產(chǎn)生質(zhì)量崩塌的情況，從質(zhì)量來說，我還是覺得傳統(tǒng)的方式比敏捷的要好一些，因為他的管控力度，包括過程管理，結(jié)果驗證這些東西，還是比較好的。

但是敏捷在質(zhì)量中還是有一些辦法的，下面介紹幾個跟質(zhì)量相關(guān)的工具：

第一個叫TDD，測試驅(qū)動開發(fā)，就是先寫測試用例，然后再寫代碼，然后找到一個比如jenkins那種的持續(xù)集成工具上跑一下你的測試用例。

第二個叫行為驅(qū)動開發(fā)，這個通常來講是有測試人員去做，行為驅(qū)動開發(fā)一個比較好的工具，叫cucumber（黃瓜）。它是一種以用戶為角度的行為測試工具，這個去迎合和測試業(yè)務(wù)場景是非常好的。

Q：采用傳統(tǒng)瀑布模式開發(fā)的項目可以敏捷嗎，怎么操作？

A：先行為導(dǎo)入，然后知識導(dǎo)入，然后再價值導(dǎo)入，然后再知識導(dǎo)入，這樣一步步潛移默化的去改變他們的行為方式。

瀑布模式開發(fā)的項目可以敏捷嗎？這個東西也不盡然，這個得看項目類型和團隊行為方式。如果一個企業(yè)，一個團隊想做這種敏捷轉(zhuǎn)型，我的建議一直都是你去找一個專業(yè)的教練幫助你去做，不要自己看本書就做，很多敏捷轉(zhuǎn)型因為這個失敗，這個很容易失敗。

Q：今后敏捷是否更受企業(yè)的青睞？

A：不僅谷歌微軟在用，國內(nèi)的大廠也都在用。這個就沒有什么討論的了。

6、看板

補充一個看板的知識，看板這個東西其實也是挺重要的，在如果有同學(xué)學(xué)PMI-ACP^®，PMI-ACP^®推薦的書有一本就是看板。

看板就是我發(fā)的這張圖，這就是一個最簡單的看板?？窗逵袃蓚€作用，第一個作用叫價值流動，第二個作用叫限制在制品。

看板就是每天在開早會的時候，把各個工作改一改狀態(tài)，就是這么簡單的一個事情?？窗迤鋵嵶隽嗣艚葜械暮芏嗍?，它起到了信息發(fā)射源的作用，也就是說，團隊中的所有成員都能通過這個看板看到這個項目的進度和項目實時的情況，而且能夠知道我在這個項目的哪一列上，或者說在哪一個狀態(tài)上有遲滯了。

有興趣的同學(xué)可以去看那本兒看板方法，里面講的很詳細。

最后分享一個看板實踐這本書的讀書筆記