今天你敏捷了沒(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ā)引向了快速迭代衷恭、小步快跑的路線(xiàn)上扰付。

我們使用 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ì)耦合度高，流程極其靈活的方法良姆，他們把它稱(chēng)為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)域里推姻，用故事板表述用戶(hù)場(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è)趺疵簦?/p>

一個(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 .....我們宣稱(chēng)：我們敏捷化了！

我們習(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 全稱(chēng) scrum master，中文稱(chēng)敏捷教練绝葡。一般說(shuō)來(lái)深碱，SM 需要由對(duì)技術(shù)開(kāi)發(fā)以及當(dāng)前項(xiàng)目明晰的技術(shù)經(jīng)理?yè)?dān)任。

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

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

需求池示例(任務(wù)名稱(chēng)刊侯、平臺(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 的合作兄春。

這樣的話(huà)澎剥，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ì)勾效∴诘浚”

十幾個(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ì)成員能夠更加緊密地配合完成工作，線(xiàn)上的的流轉(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)所有）

原文地址：https://cloud.tencent.com/developer/article/1004881