作者：薄玉桴，騰訊產(chǎn)品經(jīng)理，關(guān)注項(xiàng)目管理。靈魂畫(huà)手。

?

今天你敏捷了沒(méi)有？“敏捷”在互聯(lián)網(wǎng)和軟件開(kāi)發(fā)領(lǐng)域從涓涓細(xì)流逐漸演變?yōu)樾袠I(yè)潮流，往小了說(shuō)是改進(jìn)了開(kāi)發(fā)方法，往大了說(shuō)是革了瀑布流式的命——把產(chǎn)品開(kāi)發(fā)引向了快速迭代、小步快跑的路線上。

我們使用tapd寫(xiě) feature，流轉(zhuǎn)、跟蹤任務(wù)，言必談敏捷，然而我們是否真的走對(duì)了敏捷？

編輯注：tapd 是騰訊內(nèi)部的敏捷項(xiàng)目管理系統(tǒng)。

1.朋友，你聽(tīng)說(shuō)過(guò)敏捷么？

2.離開(kāi)敏捷工具，我們?cè)趺疵?#xff1f;

3.設(shè)計(jì)也要介入敏捷流程？

4.敏捷跟文檔是對(duì)立的？

5.我這有個(gè)幾百億的大項(xiàng)目，怎么敏？

6.盡信書(shū)，不如無(wú)書(shū)。

一、朋友，你聽(tīng)說(shuō)過(guò)敏捷么？

程序員說(shuō)，要有敏捷

從敏捷的濫觴看去，比起方法，這玩意貌似更像一個(gè)宗教（笑）。

千禧之初，美國(guó)在計(jì)算機(jī)行業(yè)已經(jīng)走了幾十年，瀑布流、螺旋模型、快速迭代...各種各樣的軟件開(kāi)發(fā)流程雨后春筍各領(lǐng)風(fēng)騷一段時(shí)間。雖然不斷變化和完善，但互聯(lián)網(wǎng)的加速發(fā)展讓傳統(tǒng)方法顯得笨重，難以快速適應(yīng)變化。有十七個(gè)程序員（程序員改變世界）在美國(guó)猶他州的一個(gè)風(fēng)景區(qū)開(kāi)了個(gè)碰頭會(huì)，找到了一個(gè)團(tuán)隊(duì)耦合度高，流程極其靈活的方法，他們把它稱為agile program development。

這十七個(gè)人如同開(kāi)宗立派的長(zhǎng)老，在會(huì)議之后給自己起了個(gè)名字“敏捷聯(lián)盟”，他們不僅賦予了新方法名字，還有宣言，甚至綱領(lǐng)。

鹽湖城-snowbird（敏捷聯(lián)盟成立地——雪鳥(niǎo)滑雪場(chǎng)）

中文版的“敏捷宣言”。在建立于2002年3月的?http://agilemanifesto.org/?里你可以找到幾十種語(yǔ)言的“敏捷宣言”。

另外，長(zhǎng)老們還制定了12原則，作為福音傳播。

顯而易見(jiàn)，敏捷是絕對(duì)的結(jié)果導(dǎo)向，去文檔化，去流程化，高效溝通和合作是究極奧義。

看起來(lái)是個(gè)很不錯(cuò)的方法，文檔不重要了，流程不重要了，大家聚在一起說(shuō)一說(shuō)就可以了不是嗎？太棒了，感覺(jué)可以從繁重的文書(shū)工作中解脫出來(lái)了呢。

失之東隅收之桑榆。一處的方便一定意味著另外什么地方以其他方式運(yùn)行著簡(jiǎn)化掉的部分。

去文檔，敏捷管理者需要維護(hù)更為精細(xì)的需求池；去流程，口頭溝通成為常態(tài)，對(duì)團(tuán)隊(duì)的耦合度要求更高。

胖友，這里有一份教義，你要不要聽(tīng)一下。

初識(shí)敏捷，有一些概念需要了解，如果你是老司機(jī)，跳過(guò)這部分，阿敏。

agile：迅速，敏捷。這是敏捷的理念也是精髓：迅速響應(yīng)需求，快速反饋結(jié)果。agile的引入像一股活水沖擊著老氣橫秋的瀑布流模型，速度上跑贏幾條街。

sprint：字面意思是短跑沖刺，一個(gè)開(kāi)發(fā)階段被認(rèn)為是一次沖刺，一個(gè)個(gè)sprint首位相連，構(gòu)成一個(gè)項(xiàng)目。

Scrum:指的是英式橄欖球中一股腦爭(zhēng)球這一戰(zhàn)術(shù)或行為。

scrum 即為這樣一種方式，大家一擁而上，團(tuán)隊(duì)是球員，球是產(chǎn)品目標(biāo)，人員環(huán)環(huán)相扣，圍繞著產(chǎn)品目標(biāo)進(jìn)行工作。這里面多少有點(diǎn)“統(tǒng)籌法”的影子，人員深入?yún)f(xié)作以達(dá)到最優(yōu)化效果。

Product Backlog:

backlog 即需求池。待辦事項(xiàng)列表。

Backlog里面寫(xiě)什么：

1.待開(kāi)發(fā)任務(wù)。

2.任務(wù)優(yōu)先級(jí)。

敏捷需要維護(hù)一份詳盡的需求列表。這份列表常常要求scrum持有人（一般是產(chǎn)品經(jīng)理）對(duì)所有待開(kāi)發(fā)事項(xiàng)有深入了解，并且能夠把待開(kāi)發(fā)事項(xiàng)分解成更為細(xì)致的任務(wù)（或者跟敏捷教練一起，后面我們會(huì)再次提到敏捷教練）

story board:

很多領(lǐng)域都有故事板的概念，交互領(lǐng)域里，用故事板表述用戶場(chǎng)景、電影領(lǐng)域里故事板用來(lái)更具體地描述分鏡。在開(kāi)發(fā)領(lǐng)域，故事版是任務(wù)流轉(zhuǎn)的可視化窗口，一般有“待開(kāi)發(fā)”“開(kāi)發(fā)中”“待測(cè)試”“返工”“待發(fā)布”幾個(gè)區(qū)塊，所有任務(wù)由任務(wù)操作者負(fù)責(zé)流轉(zhuǎn)至于下一個(gè)步驟，這樣任何一個(gè)人項(xiàng)目成員都能看到任務(wù)的完成情況。

一個(gè)app使用情景故事版

在開(kāi)發(fā)中，故事板展現(xiàn)所有需求的工作流

burn down chart：

燃盡圖

一個(gè)sprint內(nèi)，人/時(shí)是一個(gè)比較固定的值。在這個(gè)時(shí)間框架充分安排開(kāi)發(fā)任務(wù)，每天進(jìn)行時(shí)間結(jié)算，繪制時(shí)間燃盡圖。項(xiàng)目成員通過(guò)燃盡圖獲知時(shí)間進(jìn)展，若項(xiàng)目燃盡所用時(shí)間與預(yù)期時(shí)間契合，則需求時(shí)間預(yù)估和安排合理，若不契合則需要在下一個(gè)sprint進(jìn)行調(diào)整。

名詞聽(tīng)起來(lái)都玄乎乎的，很符合開(kāi)宗立派的氣質(zhì)。這些概念定義了敏捷各個(gè)環(huán)節(jié)的工作，這些流程和節(jié)點(diǎn)是敏捷開(kāi)展的基礎(chǔ)和保障。

二、離開(kāi)敏捷工具，我們?cè)趺疵?#xff1f;

一個(gè)誤區(qū)：我們用了敏捷管理工具，就敏捷了

隨著敏捷在行業(yè)內(nèi)的不斷融入，各種工具產(chǎn)品層出不窮。國(guó)外jira、redmine，Axosoft ，國(guó)內(nèi)的leangoo、禪道，三大家則都有自研的工具，百度的icafe，阿里的aone，我鵝自研tapd。

（數(shù)據(jù)來(lái)源：“2016中國(guó)開(kāi)發(fā)者白皮書(shū)”）

我們?cè)趖apd上建迭代，建需求，研發(fā)、測(cè)試等著收到需求流轉(zhuǎn)的郵件之后開(kāi)始干活...任務(wù)在測(cè)試和研發(fā)之間流轉(zhuǎn)，bug提給研發(fā)，研發(fā)解決bug.....我們宣稱：我們敏捷化了！

我們習(xí)慣于敏捷軟件的便利，拉群解決一切，然而卻喪失了敏捷的初衷，scrum的本意。

Jira的名字來(lái)自于哥斯拉

假設(shè)我們沒(méi)有任何項(xiàng)目協(xié)同軟件，敏捷怎么實(shí)施？

設(shè)定一個(gè)環(huán)境，現(xiàn)在沒(méi)有任何協(xié)同工具可用，但是所有人都坐在一起。有人站起來(lái)說(shuō)，既然這樣，我們不如敏捷吧！

敏捷工具消失了

敏捷路徑里必須有一個(gè)項(xiàng)目持有者，制定規(guī)劃并把握項(xiàng)目走向。這位產(chǎn)品汪我看你骨骼驚奇，你就擔(dān)負(fù)起這個(gè)責(zé)任吧。

另外還有一個(gè)關(guān)鍵人物SM（別想歪）。SM全稱scrum master，中文稱敏捷教練。一般說(shuō)來(lái)，SM需要由對(duì)技術(shù)開(kāi)發(fā)以及當(dāng)前項(xiàng)目明晰的技術(shù)經(jīng)理?yè)?dān)任。

雖然缺少線上工具，但至少要準(zhǔn)備一些簡(jiǎn)單材料：一卷雙面膠+白紙或一沓便利貼；筆，一面平坦的墻或一塊黑板。

如果還有電腦可用，excel或者word，甚至寫(xiě)字板都可以，沒(méi)有電腦那就白紙好了，總之你得找個(gè)地方寫(xiě)下你的需求池（backlog）

需求池示例(任務(wù)名稱、平臺(tái)、詳細(xì)描述、優(yōu)先級(jí)按照P0-PX逐漸遞減)

確定一個(gè)sprint周期的自然天。可以用月/旬/周等時(shí)間概念作為周期，我們選擇一周（五個(gè)工作日）作為一個(gè)sprint周期。

按照優(yōu)先級(jí)，從需求池中拉出你認(rèn)為應(yīng)該加入你們一窮二白的第一個(gè)sprint里面去的需求，別太貪心，大概覺(jué)得差不多一周左右的開(kāi)發(fā)量就夠了。拉上SM桑單獨(dú)開(kāi)一次小會(huì)。

當(dāng)然不是讓你倆傻站著，你倆要開(kāi)會(huì)

你們一起通覽需求，SM桑根據(jù)經(jīng)驗(yàn)對(duì)需求先行分解一遍，比如某需求在開(kāi)發(fā)層面需要分解為ABC三部分，這三部分就形成三個(gè)開(kāi)發(fā)任務(wù)。

分解完成后，你得到了一個(gè)比較詳細(xì)的待開(kāi)發(fā)列表。

正式開(kāi)始一個(gè)sprint開(kāi)始之前，產(chǎn)品、研發(fā)、測(cè)試需要一同開(kāi)一次scrum會(huì)議，共同討論本次sprint的功能點(diǎn)。

會(huì)上討論什么：

1.需求討論或技術(shù)討論；

2.成員預(yù)估需求所需開(kāi)發(fā)時(shí)間；

3.需求是否match人力時(shí)間，需求排入sprint；

4.交流一下感情。

每個(gè)任務(wù)的預(yù)估時(shí)間在最后由敏捷教練綜合判定

scrum會(huì)后你的工作：

1.整理這個(gè)sprint內(nèi)的需求列表；

2.整理每個(gè)需求的預(yù)期開(kāi)發(fā)時(shí)間；

3.撰寫(xiě)故事版上的小紙條；

4.把小紙條貼到故事版上；

5.制作一個(gè)燃盡圖。

一個(gè)改良版的小紙條，寫(xiě)明開(kāi)發(fā)者、任務(wù)描述、預(yù)估時(shí)間和每日燃盡時(shí)間

故事版布局如下：

一個(gè)標(biāo)準(zhǔn)的故事版：最開(kāi)始所有的小紙條都在“待開(kāi)發(fā)”一欄

到此為止，你可以開(kāi)始run起一個(gè)sprint。

以為這就完事了？天真。

接下來(lái)你必須來(lái)參加每日舉行的項(xiàng)目短會(huì)。這個(gè)環(huán)節(jié)在agile中非常關(guān)鍵，是agile的日常修煉。為了縮減會(huì)議時(shí)間，我們一般站著開(kāi)——所以也叫“站會(huì)”，早上上班后或晚上下班前，抽出十到十五分鐘時(shí)間，完成它。

每日站會(huì)

站會(huì)都有什么人參加：

1.你（項(xiàng)目持有者）

2.SM

3.其他scrum成員

站會(huì)干什么：

1.昨天大家分別做了什么事，遇到了什么問(wèn)題，如何解決或?qū)で蠼鉀Q方案；

2.昨天任務(wù)的完成狀態(tài)，剩余多少時(shí)間，是否需要進(jìn)行時(shí)間修正（增加時(shí)間或減少時(shí)間），把已完成的任務(wù)流轉(zhuǎn)到下一環(huán)節(jié)（把紙條從一個(gè)item內(nèi)撕下，貼到下一個(gè)item里去）；

任務(wù)進(jìn)行中，小紙條的示例

3.功能測(cè)試后是否有返工；

4.交流一下感情。

站會(huì)之后你的工作：

繪制燃盡圖。

一個(gè)燃盡圖的示例：正常的sprint的任務(wù)時(shí)間是隨著sprint的進(jìn)程逐漸減少的

周而復(fù)始，完成了一個(gè)sprint后，你們開(kāi)了第二次scrum會(huì)。這時(shí)議題多了一項(xiàng):復(fù)盤(pán)上一個(gè)sprint。

任務(wù)未能燃盡；研發(fā)返工過(guò)多；測(cè)試需求淤積.....

針對(duì)問(wèn)題討論解決方案，根據(jù)實(shí)際情況進(jìn)行下一個(gè)sprint的任務(wù)安排。

自此，我們?cè)跊](méi)有任何敏捷工具的幫助下，開(kāi)始了敏捷的旅程。

說(shuō)起來(lái)agile developing本來(lái)就是排斥文檔的作業(yè)方式，為一個(gè)小輕快的方法制作一套嚴(yán)謹(jǐn)龐大的工具，基本也算違背了元老們的初衷了吧，科科。

三、設(shè)計(jì)師在敏捷中如何介入？

我們正在使用或者聽(tīng)過(guò)的一些流程方法——不單敏捷，瀑布流，迭代式，結(jié)對(duì)開(kāi)發(fā)，精益開(kāi)發(fā)....似乎都不關(guān)設(shè)計(jì)師什么事。既然開(kāi)發(fā)團(tuán)隊(duì)抱團(tuán)敏捷了，設(shè)計(jì)，這個(gè)在產(chǎn)品流程中必不可少而工作內(nèi)容相對(duì)獨(dú)立的角色，要怎么介入敏捷呢？

一種思路是，設(shè)計(jì)擁有自己的敏捷流程。設(shè)計(jì)師作為一個(gè)scrum存在，以從上游獲取的需求進(jìn)行sprint。

另一種思路，是把設(shè)計(jì)和測(cè)試完全納入到團(tuán)隊(duì)中來(lái)，一起進(jìn)行scrum的合作。

這樣的話，UI工作至少要比開(kāi)發(fā)工作前移至少半個(gè)sprint。

有請(qǐng)產(chǎn)品經(jīng)理（項(xiàng)目持有者）出場(chǎng)。

很好，我們有了一個(gè)設(shè)計(jì)師

項(xiàng)目持有者將需求分為“UI支持”和“非UI支持”兩類(lèi)。我們將小紙條擴(kuò)展一下。

多出來(lái)UI前置部分的小紙條

UI設(shè)計(jì)師參與到scrum會(huì)中。對(duì)于需要UI支持的需求，設(shè)計(jì)師給出一個(gè)UI制作的時(shí)間預(yù)估。項(xiàng)目持有者將這部分時(shí)間加到擴(kuò)展小紙條上去。在一個(gè)sprint中，設(shè)計(jì)師的工作跟研發(fā)的工作分別進(jìn)行。

當(dāng)設(shè)計(jì)師將某一需求完成時(shí)，將小紙條的UI部分撕下，匯入到“”待開(kāi)發(fā)”中去。

一個(gè)已經(jīng)完成了UI設(shè)計(jì)的小紙條示例

四、敏捷不需要文檔嗎？

一切為快服務(wù)的敏捷特別適合初創(chuàng)團(tuán)隊(duì)使用。它能把團(tuán)隊(duì)人員緊密結(jié)合在一起，高效而有序地輸出產(chǎn)能。而常規(guī)高效的版本輸出往往是初創(chuàng)團(tuán)隊(duì)高速發(fā)展的第一要?jiǎng)?wù)。

敏捷了一段時(shí)間之后，產(chǎn)品進(jìn)入正軌，項(xiàng)目拿到撥款，公司拿到投資，你們要擴(kuò)大團(tuán)隊(duì)規(guī)模，新入職的同事想了解下產(chǎn)品和技術(shù)細(xì)節(jié)，你告訴TA：

你要不翻下backlog看看？這個(gè)實(shí)現(xiàn)你要不看一下代碼？這個(gè)字段我也不記得有沒(méi)有了....你抓包看下？

新同事一臉懵逼，難道咱們沒(méi)有文檔嗎？你自豪地指出：

“我們是敏捷團(tuán)隊(duì)。”

十幾個(gè)人八九條槍的階段之后，產(chǎn)品趨于穩(wěn)定，團(tuán)隊(duì)逐步擴(kuò)大。無(wú)論從內(nèi)部協(xié)調(diào)還是外部溝通上對(duì)產(chǎn)品流程的正規(guī)化和文檔化要求與日俱增。

從短期收益上看，文檔對(duì)于敏捷開(kāi)發(fā)是非必須品，并且很有可能會(huì)拖慢進(jìn)度。在一個(gè)sprint中，口頭溝通顯然效率更高，每個(gè)人都有精確到工時(shí)的任務(wù)，沒(méi)人有等待文檔更新的時(shí)間。強(qiáng)調(diào)文檔就等于放棄靈活性。

從長(zhǎng)期和宏觀上看，文檔對(duì)于敏捷團(tuán)隊(duì)和敏捷的實(shí)施利大于弊——節(jié)省在一些常規(guī)問(wèn)題上的溝通成本，同時(shí)降低錯(cuò)誤的發(fā)生概率。對(duì)于一個(gè)將要長(zhǎng)期實(shí)施敏捷的 團(tuán)隊(duì)來(lái)講，文檔讓后續(xù)的工作效率更高。

一個(gè)以訛傳訛的過(guò)程

這樣一個(gè)功在當(dāng)代利在千秋的好事，當(dāng)然要做。那么——

誰(shuí)來(lái)維護(hù)文檔，怎么維護(hù)？

我們挑選幾個(gè)重要的文檔：產(chǎn)品文檔、概要設(shè)計(jì)、接口文檔

產(chǎn)品文檔：不好意思內(nèi)個(gè)產(chǎn)品經(jīng)理你過(guò)來(lái)下。雖然你要維護(hù)backlog、跟SM分解需求、開(kāi)scrum會(huì)、寫(xiě)小紙條、開(kāi)站會(huì)、畫(huà)燃盡圖、還有什么外部溝通啊，寫(xiě)PPT啊，絞盡腦汁想規(guī)劃啊......你還得認(rèn)真把這個(gè)文檔維護(hù)好。

對(duì)又是你

產(chǎn)品文檔包括：

1.需求；

2.加入日期；

3.開(kāi)發(fā)版本；

4.呈現(xiàn)和詳細(xì)方案

在非敏捷開(kāi)發(fā)流程中，文檔在評(píng)審會(huì)后完善并更新，形成一個(gè)給研發(fā)參考的實(shí)現(xiàn)目標(biāo)。在敏捷中，需求本身在sprint周期內(nèi)不斷完善，你可以在一個(gè)sprint之后將文檔補(bǔ)全。

概要設(shè)計(jì)：敏捷的常規(guī)迭代中，概要設(shè)計(jì)不是一個(gè)必須的文檔。但全新項(xiàng)目、重構(gòu)以及重大新功能則必須輸出概要設(shè)計(jì)文檔。研發(fā)leader責(zé)無(wú)旁貸，這個(gè)落你身上了。

接口文檔：必要且重要。包括接口說(shuō)明、字段定義、字段類(lèi)型、值定義、數(shù)據(jù)上報(bào)、錯(cuò)誤碼等。一般來(lái)說(shuō)約定之后由接口開(kāi)發(fā)者更新文檔，如果你們沒(méi)有云端存儲(chǔ)的能力，至少咱們?nèi)耸忠环?#xff0c;定期更新。

長(zhǎng)久來(lái)看，文檔是提高效率的一大利器

雖然《宣言》中明確地放低了文檔的地位（“工作的軟件大于詳盡的文檔”），敏捷強(qiáng)調(diào)互動(dòng)和變化，以及對(duì)變化的及時(shí)響應(yīng)。誠(chéng)然文檔恰恰做不到如此靈活。但敏捷真的完全排斥文檔嗎？

文檔的時(shí)效性和靈活性遠(yuǎn)低于口頭溝通，但卻有它實(shí)在的好處。

1.空間上，文檔傳播范圍更廣。規(guī)范化和常規(guī)化的內(nèi)容形成文檔可以大大減少溝通成本。尤其在多個(gè)系統(tǒng)協(xié)作的情況下，跨scrum、跨團(tuán)隊(duì)甚至跨部門(mén)的溝通時(shí)有發(fā)生，文檔的重要性和便捷性不言而喻。

2.時(shí)間上，文檔流傳性更好。團(tuán)隊(duì)不是一成不變的，有人離開(kāi)有人加入。更新?lián)Q代中，新人快速了解系統(tǒng)，老兵傳承研發(fā)理念；在更大的時(shí)間跨度上，團(tuán)隊(duì)可能成為忒修斯之船，文檔的存在就是對(duì)產(chǎn)品歷程的完整追溯，你將不用他人幫助就可以了解到產(chǎn)品的大部分面貌甚至全貌。

五、大項(xiàng)目怎么引入敏捷？

看起來(lái)敏捷方法特別適合產(chǎn)品常規(guī)迭代。有一種可能性是，你的產(chǎn)品需要插入一個(gè)巨無(wú)霸模塊，與其說(shuō)是模塊倒不如說(shuō)它幾乎可以成為一個(gè)產(chǎn)品了。你想了想，這么大個(gè)項(xiàng)目怎么說(shuō)產(chǎn)品、設(shè)計(jì)、研發(fā)、測(cè)試全情投入也得個(gè)一兩個(gè)月。

還能走敏捷嗎？

注意你的項(xiàng)目時(shí)間。有deadline的scrum是帶著鐐銬跳迪斯科，時(shí)間節(jié)點(diǎn)關(guān)乎sprint的大小。

大項(xiàng)目敏捷之前，先得不敏捷幾步。

可能會(huì)發(fā)生一到多次需求討論會(huì)。

團(tuán)隊(duì)必須不厭其煩地理解需求或修正產(chǎn)品經(jīng)理“天真的幻想”，產(chǎn)品經(jīng)理使用不斷完善的原型同團(tuán)隊(duì)進(jìn)（tao）行(jia)溝(huan)通(jia)。在最后的產(chǎn)品評(píng)審之前，至少敲定產(chǎn)品框架和大部分細(xì)節(jié)。這次評(píng)審邀請(qǐng)項(xiàng)目成員和所有協(xié)同團(tuán)隊(duì)，除了敲定的產(chǎn)品功能，技術(shù)上需要得到一些初步結(jié)論（比如“能不能做”。事實(shí)上，產(chǎn)品經(jīng)理應(yīng)該在產(chǎn)品規(guī)劃階段就知會(huì)協(xié)同團(tuán)隊(duì)將要做什么）。接下來(lái)進(jìn)行概要設(shè)計(jì)（新產(chǎn)品、重構(gòu)、重大新功能必須進(jìn)行概要設(shè)計(jì)）。技術(shù)評(píng)審邀請(qǐng)除設(shè)計(jì)以外的項(xiàng)目成員和協(xié)同團(tuán)隊(duì)參會(huì)。

大項(xiàng)目敏捷中：

1.將deadline之前的時(shí)間分解為多個(gè)sprint。（deadline之前必須留出一定“出血時(shí)間”用以解決時(shí)間預(yù)估不足的任務(wù)、返工任務(wù)以及bug)

2.將所有需求分解成任務(wù)，開(kāi)一次全局scrum會(huì)。預(yù)估時(shí)間之后，分散任務(wù)到各個(gè)sprint中。在時(shí)間較緊的情況下，sprint的容量就要相應(yīng)增加。

一個(gè)需要加班的sprint

3.進(jìn)入敏捷流程，常規(guī)scrum會(huì)、站會(huì)，燃盡圖，故事版。未完成任務(wù)在scrum會(huì)上重新預(yù)估時(shí)間，滾入新sprint內(nèi)，以此類(lèi)推（按時(shí)完成sprint內(nèi)的任務(wù)是目標(biāo)。實(shí)在不行我們還有“出血時(shí)間”呢）

4.別忘了文檔。

雖然被推崇備至，但敏捷并不是完美的開(kāi)發(fā)方法。敏捷的最大的優(yōu)勢(shì)是靈活，而造成敏捷問(wèn)題的根源也正是靈活。

文末再總結(jié)本文重點(diǎn)：

1.敏捷是一種流程、方法、理念，甚至信仰。

2 用了敏捷管理軟件不一定就是敏捷。敏捷的初衷是團(tuán)隊(duì)成員能夠更加緊密地配合完成工作，線上的的流轉(zhuǎn)如果削弱了這種配合性，反倒背離了敏捷的本意。實(shí)際上只要有白板紙張和筆，你的團(tuán)隊(duì)就能開(kāi)始敏捷。

4.我們敏捷了，不是不要文檔了。在外部交流多、世代跨度長(zhǎng)的情況下，文檔的必要性顯而易見(jiàn)。長(zhǎng)期的面對(duì)面溝通最終會(huì)導(dǎo)致低效，這也是敏捷缺陷的根源。

5.設(shè)計(jì)師可以完全介入到敏捷流程中，只需要做一些細(xì)心的安排。

6.大項(xiàng)目開(kāi)發(fā)中可以走敏捷，具體問(wèn)題具體分析，需要根據(jù)項(xiàng)目特點(diǎn)制定敏捷計(jì)劃。

（文章所有插圖為筆者手繪，版權(quán)所有）

?

原文出自騰訊云技術(shù)社區(qū)
原文鏈接https://www.qcloud.com/community/article/766331

轉(zhuǎn)載于:https://www.cnblogs.com/hongge66/p/6782897.html

總結(jié)

以上是生活随笔為你收集整理的你大概走了假敏捷：认真说说敏捷的实现和问题（手绘版）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。