<<互聯(lián)網(wǎng)敏捷DevOps和自動(dòng)化之2.精益敏捷>>
Scrum 是一個(gè)用于開發(fā)和維持復(fù)雜產(chǎn)品的框架 ，是一個(gè)增量的、迭代的開發(fā)過(guò)程。在這個(gè)框架中，整個(gè)開發(fā)過(guò)程由若干個(gè)短的迭代周期組成，一個(gè)短的迭代周期稱為一個(gè)Sprint，每個(gè)Sprint的建議長(zhǎng)度是2到4周(互聯(lián)網(wǎng)產(chǎn)品研發(fā)可以使用1周的Sprint)。在Scrum中，使用產(chǎn)品Backlog來(lái)管理產(chǎn)品的需求，產(chǎn)品backlog是一個(gè)按照商業(yè)價(jià)值排序的需求列表，列表?xiàng)l目的體現(xiàn)形式通常為用戶故事。Scrum團(tuán)隊(duì)總是先開發(fā)對(duì)客戶具有較高價(jià)值的需求。在Sprint中，Scrum團(tuán)隊(duì)從產(chǎn)品Backlog中挑選最高優(yōu)先級(jí)的需求進(jìn)行開發(fā)。挑選的需求在Sprint計(jì)劃會(huì)議上經(jīng)過(guò)討論、分析和估算得到相應(yīng)的任務(wù)列表，我們稱它為Sprint backlog。在每個(gè)迭代結(jié)束時(shí)，Scrum團(tuán)隊(duì)將遞交潛在可交付的產(chǎn)品增量。 Scrum起源于軟件開發(fā)項(xiàng)目，但它適用于任何復(fù)雜的或是創(chuàng)新性的項(xiàng)目。

image.png

Scrum流程如下圖：

image.png

Scrum流程

SCRUM框架包括3個(gè)角色、3個(gè)工件、5個(gè)事件、5個(gè)價(jià)值
3個(gè)角色
產(chǎn)品負(fù)責(zé)人（Product Owner）
Scrum Master
開發(fā)團(tuán)隊(duì)

3個(gè)工件
產(chǎn)品Backlog（Product Backlog）
SprintBacklog
產(chǎn)品增量（Increment）

5個(gè)事件
Sprint（Sprint本身是一個(gè)事件，包括了如下4個(gè)事件）
Sprint計(jì)劃會(huì)議（Sprint Planning Meeting）
每日站會(huì)（Daily Scrum Meeting）
Sprint評(píng)審會(huì)議（Sprint Review Meeting）
Sprint回顧會(huì)議（Sprint Retrospective Meeting）

5個(gè)價(jià)值
承諾 – 愿意對(duì)目標(biāo)做出承諾
專注– 把你的心思和能力都用到你承諾的工作上去
開放– Scrum 把項(xiàng)目中的一切開放給每個(gè)人看
尊重– 每個(gè)人都有他獨(dú)特的背景和經(jīng)驗(yàn)
勇氣– 有勇氣做出承諾，履行承諾，接受別人的尊重

SCRUM理論基礎(chǔ)
Scrum以經(jīng)驗(yàn)性過(guò)程控制理論（經(jīng)驗(yàn)主義）做為理論基礎(chǔ)的過(guò)程。經(jīng)驗(yàn)主義主張知識(shí)源于經(jīng)驗(yàn), 以及基于已知的東西做決定。Scrum 采用迭代、增量的方法來(lái)優(yōu)化可預(yù)見性并控制風(fēng)險(xiǎn)。
Scrum 的三大支柱支撐起每個(gè)經(jīng)驗(yàn)性過(guò)程控制的實(shí)現(xiàn):透明性、檢驗(yàn)和適應(yīng)。Scrum的三大支柱如下：
第一：透明性（Transparency）
透明度是指，在軟件開發(fā)過(guò)程的各個(gè)環(huán)節(jié)保持高度的可見性，影響交付成果的各個(gè)方面對(duì)于參與交付的所有人、管理生產(chǎn)結(jié)果的人保持透明。管理生產(chǎn)成果的人不僅要能夠看到過(guò)程的這些方面，而且必須理解他們看到的內(nèi)容。也就是說(shuō)，當(dāng)某個(gè)人在檢驗(yàn)一個(gè)過(guò)程，并確信某一個(gè)任務(wù)已經(jīng)完成時(shí)，這個(gè)完成必須等同于他們對(duì)完成的定義。
第二：檢驗(yàn)（Inspection）
開發(fā)過(guò)程中的各方面必須做到足夠頻繁地檢驗(yàn)，確保能夠及時(shí)發(fā)現(xiàn)過(guò)程中的重大偏差。在確定檢驗(yàn)頻率時(shí)，需要考慮到檢驗(yàn)會(huì)引起所有過(guò)程發(fā)生變化。當(dāng)規(guī)定的檢驗(yàn)頻率超出了過(guò)程檢驗(yàn)所能容許的程度，那么就會(huì)出現(xiàn)問(wèn)題。幸運(yùn)的是，軟件開發(fā)并不會(huì)出現(xiàn)這種情況。另一個(gè)因素就是檢驗(yàn)工作成果人員的技能水平和積極性。
第三：適應(yīng)（Adaptation）
如果檢驗(yàn)人員檢驗(yàn)的時(shí)候發(fā)現(xiàn)過(guò)程中的一個(gè)或多個(gè)方面不滿足驗(yàn)收標(biāo)準(zhǔn)，并且最終產(chǎn)品是不合格的，那么便需要對(duì)過(guò)程或是材料進(jìn)行調(diào)整。調(diào)整工作必須盡快實(shí)施，以減少進(jìn)一步的偏差。
Scrum中通過(guò)三個(gè)活動(dòng)進(jìn)行檢驗(yàn)和適應(yīng)：每日例會(huì)檢驗(yàn)Sprint目標(biāo)的進(jìn)展，做出調(diào)整，從而優(yōu)化次日的工作價(jià)值；Sprint評(píng)審和計(jì)劃會(huì)議檢驗(yàn)發(fā)布目標(biāo)的進(jìn)展，做出調(diào)整，從而優(yōu)化下一個(gè)Sprint的工作價(jià)值；Sprint回顧會(huì)議是用來(lái)回顧已經(jīng)完成的Sprint，并且確定做出什么樣的改善可以使接下來(lái)的Sprint更加高效、更加令人滿意，并且工作更快樂(lè)。

現(xiàn)在軟件領(lǐng)域三大俗，說(shuō)的是敏捷、大數(shù)據(jù)、云，說(shuō)的越多的往往也是處于成熟中，或者需求強(qiáng)調(diào)的，我所遇到的項(xiàng)目有幸?guī)缀醵加|及到這些俗氣的元素。
不得不說(shuō)，市場(chǎng)競(jìng)爭(zhēng)和各廠商客戶意識(shí)的提升，現(xiàn)在的用戶已經(jīng)被寵壞了，以前我們叫挖掘需求，也就是客戶是有自己需求的只是表達(dá)傳遞的完整性問(wèn)題，通過(guò)一定的需求工程的方法把這些需求給定義出來(lái)，變成軟件需求就好了?，F(xiàn)在客戶往往是不知道自己想要什么的，他們往往會(huì)提出"高大上"的需求，比如："我要一款軟件，使我的業(yè)務(wù)管理水平達(dá)到行業(yè)的標(biāo)桿，至少這個(gè)軟件具體應(yīng)該有什么功能我也不知道，我們預(yù)算是要多少有多少，關(guān)鍵是要做好，要在最短時(shí)間內(nèi)最好是明天交付出來(lái)，否則后續(xù)取消與你們的合作。"，相信很多開發(fā)人員聽到這些"需求"都會(huì)感到無(wú)所適從。
不幸我就遇到類似的一個(gè)項(xiàng)目，客戶需求就是一句話："在國(guó)家批下來(lái)的預(yù)算范圍內(nèi)，給我們做一個(gè)本行業(yè)標(biāo)桿性的軟件，需求嘛你們自己研究研究，我們就看效果，但必須在 1 個(gè)月內(nèi)上面領(lǐng)導(dǎo)下來(lái)參觀前完成"，經(jīng)過(guò)初步分析，參考這個(gè)行業(yè)的同類軟件，至少涉及到集群數(shù)據(jù)存儲(chǔ)與分布式檢索、廣度爬蟲、自然語(yǔ)言識(shí)別，當(dāng)然還有面向客戶的業(yè)務(wù)應(yīng)用系統(tǒng)。而且作為公司的戰(zhàn)略項(xiàng)目，關(guān)系公司后續(xù)的市場(chǎng)開拓，老板發(fā)話："必須成功，還要注意成本"。
大家現(xiàn)在知道了，又遇到有中國(guó)特色的項(xiàng)目了，"需求范圍不確定，資源限死、時(shí)間限死"，大家會(huì)說(shuō)不是戰(zhàn)略項(xiàng)目嗎，資源怎么會(huì)限死呢？但是請(qǐng)大家想想，客戶預(yù)算是一定，根據(jù)財(cái)務(wù)核算，老板要拿的利潤(rùn)也是剛性的，還能剩多少，大家可以發(fā)揮想象了?？紤]該如何實(shí)施這個(gè)項(xiàng)目時(shí)，似乎傳統(tǒng)的項(xiàng)目管理從計(jì)劃來(lái)分配資源模式以及采用瀑布型的開發(fā)方式，根本行不通。就在我焦頭爛額之際，我想起了解過(guò)的一種開發(fā)模式：
Scrum 開發(fā)模式使得我們能夠?qū)Ｗ⒂谌绾卧谧疃痰臅r(shí)間內(nèi)實(shí)現(xiàn)最有價(jià)值的部分；
Scrum 開發(fā)模式使得我們能夠快速的經(jīng)常的監(jiān)督實(shí)際產(chǎn)品發(fā)展的狀況；
Scrum 開發(fā)模式使得團(tuán)隊(duì)按照商業(yè)價(jià)值的高低先完成高優(yōu)先級(jí)的產(chǎn)品功能，并自主管理，凝結(jié)了團(tuán)隊(duì)智慧創(chuàng)造出最好的方法因而提高效率 ；
Scrum 開發(fā)模式使得每隔一兩周或者一個(gè)月，我們就可以看到實(shí)實(shí)在在的可以上線的產(chǎn)品。此時(shí)，就可以進(jìn)一步的決定是繼續(xù)完善功能實(shí)現(xiàn)更多需求或者直接發(fā)布了 。

這正是我想要的管理方法，也是敏捷界被采用最廣泛的管理方法，但一般的 Scrum 顯然也無(wú)法有效的應(yīng)對(duì)此種情況了，還得自己完善和擴(kuò)展。
項(xiàng)目開發(fā)過(guò)程的設(shè)計(jì)
圖 1. 開發(fā)過(guò)程

開發(fā)過(guò)程

針對(duì)這類客戶應(yīng)該是提供業(yè)務(wù)的解決方案然后再提供軟件系統(tǒng)，因此整體的開發(fā)過(guò)程不能直接從用戶需求開始，而應(yīng)該從業(yè)務(wù)研究開始，如上圖 1 的開發(fā)過(guò)程來(lái)實(shí)施。
在敏捷開發(fā)中對(duì)于需求的假設(shè)是認(rèn)為，需求是涌現(xiàn)出來(lái)的，但我們知道架構(gòu)設(shè)計(jì)能夠開始是基于關(guān)鍵需求已經(jīng)確認(rèn)的情況下，而且在國(guó)內(nèi)的環(huán)境下如果在需求不確定的情況下就開發(fā)，客戶更可能隨意的修改需求，而工期又限死的情況下，項(xiàng)目必然是會(huì)失敗的。因此在中國(guó)的客戶成熟度情況下，最好還是書面確認(rèn)大部分關(guān)鍵需求后再開始做，否則，很多情況下會(huì)成爛尾樓。
為了能加快前期需求階段的進(jìn)展，必須有業(yè)務(wù)架構(gòu)師來(lái)分解業(yè)務(wù)模塊，不同的 PO 來(lái)負(fù)責(zé)各自業(yè)務(wù)模塊的需求分析。當(dāng)關(guān)鍵需求確認(rèn)后，開始技術(shù)架構(gòu)的設(shè)計(jì)，同時(shí)在技術(shù)架構(gòu)的基礎(chǔ)上進(jìn)行迭代的開發(fā)。因此，整個(gè)團(tuán)隊(duì)的結(jié)構(gòu)如下圖 2：
圖 2 .大型項(xiàng)目的組織結(jié)構(gòu)

圖 2 .大型項(xiàng)目的組織結(jié)構(gòu)

由于需求與開發(fā)團(tuán)隊(duì)是異步進(jìn)行，而不是從一開始就緊密運(yùn)作的。開發(fā)團(tuán)隊(duì)與規(guī)劃組之間，開始并沒(méi)有團(tuán)隊(duì)意識(shí)，還是按瀑布的階段交付的思維來(lái)對(duì)待。所以，項(xiàng)目組開會(huì)時(shí)，開發(fā)團(tuán)隊(duì)與需求團(tuán)隊(duì)就經(jīng)常發(fā)現(xiàn)摩擦。
開發(fā)要求需求人員將需求描述的非常細(xì)，否則不予接受。而需求人員由于在局方現(xiàn)場(chǎng)，要將需求描述的很細(xì)的情況下就需要耗費(fèi)很多文檔時(shí)間，而用戶時(shí)間有限，所以希望能將需求描述簡(jiǎn)單一點(diǎn)，關(guān)鍵是需求人員將需求寫的很細(xì)的情況下，開發(fā)人員在開發(fā)過(guò)程中任然還是需要不斷的去溝通需求，畢竟靠文檔完整表述還是有困難的。而測(cè)試團(tuán)隊(duì)先等待開發(fā)做完，再開始測(cè)試。于是開發(fā)、需求之間經(jīng)常就需求文檔細(xì)致問(wèn)題無(wú)法高效協(xié)同，測(cè)試介入很晚，到測(cè)試時(shí)對(duì)業(yè)務(wù)不熟悉，只能希望開發(fā)出相關(guān)的設(shè)計(jì)文檔來(lái)進(jìn)行測(cè)試，效果很差。由于團(tuán)隊(duì)之間對(duì)立情況，反而加劇了對(duì)文檔傳遞的依賴，項(xiàng)目進(jìn)度慢了下來(lái)。
對(duì)此，我們認(rèn)為這個(gè)是因?yàn)轫?xiàng)目實(shí)踐出來(lái)偏差，沒(méi)有真正領(lǐng)悟，敏捷開發(fā)中為什么需求必須是討論出來(lái)，而不能是通過(guò)一個(gè)詳細(xì)設(shè)計(jì)文檔去傳達(dá)，使得每個(gè)成員都對(duì)需求來(lái)負(fù)責(zé)，而不是僅僅被動(dòng)的接受。
對(duì)此，項(xiàng)目要求各團(tuán)隊(duì)的 PO，不再寫詳細(xì)的需求文檔，而是出需求列表。強(qiáng)制要求，需求的傳遞必須通過(guò)需求澄清方式完成。
也就是需求、開發(fā)、測(cè)試人員，同時(shí)參與需求的分析工作。步驟如下：
需求人員列出所有的 product backlog 的 story，并進(jìn)行排序；
開發(fā)、測(cè)試人員，聽 PO 對(duì)每個(gè)用戶故事進(jìn)行講解，注意 PO 不再提供詳細(xì)需求的文檔了，然后開發(fā)、測(cè)試人員可以要求 PO 對(duì)每個(gè)需求講解清楚，直到聽懂理解并能開始進(jìn)行設(shè)計(jì)工作為止；
開發(fā)人員將 PO 講解的需求給記錄描述出來(lái)，需要包括基本的業(yè)務(wù)流程圖以及接口說(shuō)明，同時(shí)要求測(cè)試人員將需求的驗(yàn)收條件給寫出來(lái)，整合成針對(duì)每個(gè) story 的需求澄清文檔；
由 PO 確認(rèn)需求澄清文檔內(nèi)容的準(zhǔn)確性，如果無(wú)誤可以開始進(jìn)入開發(fā)過(guò)程了。

通過(guò)這樣的方式，可以節(jié)省 PO 詳細(xì)需求文檔的時(shí)間，同時(shí)將需求的責(zé)任分擔(dān)到每個(gè)角色的身上。因?yàn)?，即使再詳?xì)的文檔，研發(fā)和測(cè)試人員 還是需要閱讀消化同時(shí)也需要多次找 PO 確認(rèn)。直接通過(guò)講解確認(rèn)，我們也稱為"需求的三次握手"過(guò)程，開發(fā)、測(cè)試、需求人員，實(shí)際完成了對(duì)需求的傳遞、需求驗(yàn)證規(guī)則的統(tǒng)一，這時(shí)測(cè)試就可以再前期介入到項(xiàng)目中，對(duì)業(yè)務(wù)理解與研發(fā)處于同一水準(zhǔn)，可以在業(yè)務(wù)層面幫助研發(fā)來(lái)糾正需求理解的偏差，考慮對(duì)異常場(chǎng)景的處理。
通過(guò)這種方式，研發(fā)的詳細(xì)設(shè)計(jì)文檔基本可以省略，但對(duì)于復(fù)雜性比較高超過(guò)實(shí)現(xiàn)需要 8 人時(shí)以上的 story 還是需要給出簡(jiǎn)要的設(shè)計(jì)文檔，需求詳細(xì)文檔可以裁減掉，而且測(cè)試用例通過(guò)驗(yàn)收準(zhǔn)則可以很快就轉(zhuǎn)換出來(lái)。通過(guò)需求的澄清過(guò)程，而不是需求文檔的傳遞來(lái)溝通，大大提升了項(xiàng)目前期的進(jìn)展。
缺陷的處理
通過(guò)厘清需求的過(guò)程，整個(gè)團(tuán)隊(duì)開發(fā)比較順暢了，但是在迭代中我們發(fā)現(xiàn)對(duì)于缺陷的處理存在問(wèn)題。有一次項(xiàng)目整體的回顧會(huì)，各特性團(tuán)隊(duì)，均順利完成了各自的 sprint 的任務(wù)，但有個(gè)團(tuán)隊(duì)卻沒(méi)有完成而且是 0 完成率，但是我們發(fā)現(xiàn)他們遺留的問(wèn)題并不多，那么是什么原因?qū)е碌哪?？?jīng)過(guò)分析我們發(fā)現(xiàn)，他們?cè)?sprint 中對(duì)缺陷的處理確實(shí)是缺乏處理策略。如圖 3 所示，story 遺留缺陷對(duì)應(yīng)圖
圖 3 .某 Sprint 的 story 與缺陷的對(duì)應(yīng)關(guān)系

圖 3 .某 Sprint 的 story 與缺陷的對(duì)應(yīng)關(guān)系

我們?cè)诙x story 的驗(yàn)收條件，是要求每個(gè) story 不能遺留一般級(jí)別以上的缺陷。但該團(tuán)隊(duì)對(duì)缺陷的處理是：
先處理嚴(yán)重級(jí)別的缺陷；
缺陷集中到迭代后期再進(jìn)行修復(fù)。

所以，當(dāng)他們進(jìn)行缺陷修復(fù)的排序時(shí)，將所有的嚴(yán)重缺陷都進(jìn)行了修復(fù)，但是導(dǎo)致最后卻是一個(gè) story 都不能交付。因?yàn)?，每個(gè) story 都還剩一個(gè)一般級(jí)別的缺陷。而且，由于不是立即處理缺陷，導(dǎo)致缺陷處理周期變長(zhǎng)，修復(fù)缺陷占用較大比例時(shí)間。等嚴(yán)重缺陷都修復(fù)完，已經(jīng)到迭代結(jié)束期。導(dǎo)致所有的 story 都無(wú)法交付。
在此次，我們必須要認(rèn)識(shí)到一點(diǎn)，我們每個(gè)迭代都要進(jìn)行增量的價(jià)值交付，作為研發(fā)團(tuán)隊(duì)?wèi)?yīng)該考慮如何在一個(gè)迭代中盡可能多的交付，而不是為了修復(fù)缺陷。所以，如果研發(fā)團(tuán)隊(duì)，在進(jìn)行缺陷修復(fù)時(shí)，考慮先把一個(gè) story 的缺陷全部修改完，再修訂其他 story 的缺陷，應(yīng)該可能交付 2 個(gè) story 的，雖然對(duì)軟件整體而言，缺陷沒(méi)變，但是交付的商業(yè)價(jià)值卻是更多的。
因此在后期，我們確定在迭代過(guò)程中：
必須樹立盡量多交付價(jià)值的觀點(diǎn)；
缺陷必須在發(fā)現(xiàn)時(shí)立即修復(fù)，不建議集中進(jìn)行修復(fù)，因?yàn)槿毕莸亩ㄎ粫r(shí)間會(huì)隨時(shí)間逐漸加長(zhǎng)的，立即修復(fù)才是對(duì)進(jìn)度、質(zhì)量最有利的方式；
實(shí)在無(wú)法修復(fù)或確實(shí)需要時(shí)間修復(fù)的 bug，需要進(jìn)行分析和規(guī)劃，不能僅僅以故障的級(jí)別為修復(fù)的優(yōu)先項(xiàng)，而是增量交付為核心關(guān)注點(diǎn)。
在團(tuán)隊(duì)中增加一個(gè)專職的 bug 修復(fù)人員，就是一旦 bug 出現(xiàn)，由專職的 bug 修復(fù)人員進(jìn)行修復(fù)，其他人員繼續(xù) story 的開發(fā)，這個(gè)人員可以在不同迭代輪換。起初是在一個(gè)團(tuán)隊(duì)中采用，后來(lái)發(fā)現(xiàn)，這種方式也取得了很好的效率，所以，在所有特性開發(fā)團(tuán)隊(duì)中都采用起來(lái)。

Story 的切分
見下圖 4，一般的業(yè)務(wù)系統(tǒng)都是按如下的方式進(jìn)行橫向的切分，也就是我們常說(shuō)的流式結(jié)構(gòu)，當(dāng)某一層發(fā)生變動(dòng)時(shí)，其他層可以保持不變。
圖 4 .常見業(yè)務(wù)系統(tǒng)的結(jié)構(gòu)

圖 4 .常見業(yè)務(wù)系統(tǒng)的結(jié)構(gòu)

當(dāng)?shù)矫艚蓍_發(fā)中隊(duì) story 的切分是基于縱向的切分如圖 5 所示，也就是每個(gè) story 都可以方便的從系統(tǒng)中整合與拆并。
圖 5 .敏捷開發(fā)的縱向切分

圖 5 .敏捷開發(fā)的縱向切分

性能要求；
日志記錄；
工作流；
全文搜索；
多數(shù)據(jù)庫(kù)支持；
搜索引擎優(yōu)化；

因此，在每個(gè) sprint 的 backlog 的安排上，不同的整合和考慮會(huì)對(duì)項(xiàng)目的進(jìn)展速度產(chǎn)生很大的影響。PO 與架構(gòu)師，必須經(jīng)過(guò)深入的整合梳理與排序，而不是簡(jiǎn)單的對(duì) story 進(jìn)行羅列。如果說(shuō)需求決定了軟件的價(jià)值，那么設(shè)計(jì)包括對(duì)需求的安排決定了軟件的成本。
目前敏捷開發(fā)中對(duì)于 story 的拆分也提到很多方式，一般來(lái)說(shuō)如下幾種：
第一種，按工作流進(jìn)行拆分

第二種，從簡(jiǎn)單到復(fù)雜

第三種，按原子操作，如分解成：Create, Read, Update, Delete；
第四種，針對(duì)公共功能的系統(tǒng)，

大家可以參考這幾種方式來(lái)靈活的處理 story 的切分問(wèn)題，但注意，還要有全局觀。

跨團(tuán)隊(duì)的處理
我們?cè)谝粋€(gè)大型項(xiàng)目中的架構(gòu)如下圖 6：
圖 6 .某項(xiàng)目的軟件架構(gòu)圖

圖 6 .某項(xiàng)目的軟件架構(gòu)圖

由于有大量的底層技術(shù)結(jié)構(gòu)，所以，我們?cè)谔匦詧F(tuán)隊(duì)劃分時(shí)，分成 3 個(gè)業(yè)務(wù)特性團(tuán)隊(duì)，這個(gè)團(tuán)隊(duì)主要是實(shí)現(xiàn)業(yè)務(wù)邏輯。而底層的，大數(shù)據(jù)存在和公共平臺(tái)，是由另一個(gè)團(tuán)隊(duì)來(lái)獨(dú)立完成的。這個(gè)時(shí)候，在任務(wù)的安排上和人員協(xié)同上就需要注意。
如：在界面上有一個(gè)查詢功能，其中有部分?jǐn)?shù)據(jù)，必須通過(guò)大數(shù)據(jù)平臺(tái)來(lái)獲取，又有部分可以直接通過(guò) oarcle 數(shù)據(jù)庫(kù)獲取，還有部分通過(guò) ES 集群就可以獲取，這個(gè)時(shí)候就要注意。Story 可交付的定義，應(yīng)該是系統(tǒng)能夠集成交付，而不僅僅是上層業(yè)務(wù)可交付。
圖 7. 團(tuán)隊(duì)中 story 與人員的對(duì)應(yīng)

團(tuán)隊(duì)中 story 與人員的對(duì)應(yīng)

建立多個(gè)敏捷團(tuán)隊(duì)關(guān)聯(lián)協(xié)同團(tuán)隊(duì)

這樣可以很好進(jìn)行某個(gè)具體交付特性的協(xié)同，保證交付的完整性。
結(jié)束語(yǔ)
敏捷開發(fā)的實(shí)踐，一直都聚焦在單一團(tuán)隊(duì)運(yùn)作，但當(dāng)往往很多系統(tǒng)規(guī)模，并非 10 個(gè)人團(tuán)隊(duì)可以在 要求時(shí)間內(nèi)交付的。當(dāng)團(tuán)隊(duì)規(guī)模大后，原來(lái)單團(tuán)隊(duì)的管理，并且團(tuán)隊(duì)間部分需求考分的交叉，原來(lái)的單一敏捷團(tuán)隊(duì)的管理方式會(huì)遇到一些麻煩。我給出了自己在大團(tuán)隊(duì)和技術(shù)復(fù)雜性團(tuán)隊(duì)的實(shí)踐的經(jīng)驗(yàn)，希望對(duì)大家有所幫助。