本文由薄玉桴發(fā)表于云+社區(qū)專欄

今天你敏捷了沒(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è)趺疵簦?/p>

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月的 《Manifesto for Agile Software Development》里你可以找到幾十種語(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è)趺疵簦?/h2>

一個(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è)?tapd 上建迭代,，建需求,，研發(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 前置部分的小紙條

U I設(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ì)?！?/p>

十幾個(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)耸忠环?，定期更新?/p>

長(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)所有）