作者丨K L Krithika

編譯丨諾亞

在過(guò)去的幾年里，Scrum的受歡迎程度明顯下降，尤其是那些親身經(jīng)歷過(guò)該框架的低下效率的工程師們，越來(lái)越不喜歡它。

僵化的框架，在短時(shí)間的密集沖刺中執(zhí)行，每個(gè)沖刺之后都有長(zhǎng)時(shí)間的會(huì)議，正是它不受歡迎的原因。Scrum不能用于所有類(lèi)型的項(xiàng)目，這就催生了更多的敏捷方法，如看板，XP（極限編程）和精益方法(Lean Methodology)等等。

Scrum的最初設(shè)計(jì)迎合了小型團(tuán)隊(duì)，在將其應(yīng)用于更大的項(xiàng)目時(shí)導(dǎo)致了一些復(fù)雜性。某種程度上，它只適用于范圍清晰、定義良好的項(xiàng)目。

1、為什么Scrum不夠敏捷

有很多關(guān)于Scrum優(yōu)缺點(diǎn)的文章，有些人信誓旦旦地說(shuō)，“如果Scrum不適合你，那就是你做錯(cuò)了!”，其他人則指出該論點(diǎn)的謬誤。Scrum的成功案例證明,明確的職責(zé)和分工有助于更好地協(xié)調(diào)和集中注意力。

當(dāng)團(tuán)隊(duì)可以致力于框架的角色、儀式和迭代性質(zhì)時(shí)，Scrum運(yùn)行良好。當(dāng)團(tuán)隊(duì)成員、利益相關(guān)者和客戶(hù)之間需要明確的責(zé)任和溝通時(shí)，Scrum比看板工作得更好，看板的任務(wù)分配不那么嚴(yán)格。

問(wèn)題在于Scrum的使用規(guī)模。雖然對(duì)該方法的優(yōu)點(diǎn)有一些共識(shí)，但它并不適用于所有項(xiàng)目。工程師面臨的一個(gè)常見(jiàn)情況是，在構(gòu)建多個(gè)應(yīng)用程序的團(tuán)隊(duì)中，在所有正在進(jìn)行的故事完成之前，個(gè)人無(wú)法開(kāi)始一個(gè)新的故事。已經(jīng)完成任務(wù)的團(tuán)隊(duì)成員一直處于空閑狀態(tài)，直到團(tuán)隊(duì)每個(gè)人都完成了他們的故事，這完全是低效的。

長(zhǎng)時(shí)間的會(huì)議是用戶(hù)的另一個(gè)痛點(diǎn)，在計(jì)劃和會(huì)議方面投入了大量資金。大量時(shí)間被耗費(fèi)在用于討論有時(shí)只需要30分鐘即可完成的故事。只涉及兩個(gè)人的會(huì)議最終會(huì)波及整個(gè)團(tuán)隊(duì)。

圖片

2、替代敏捷方法

看板是流行的敏捷方法之一。它是一個(gè)可視化的工作流程管理系統(tǒng)，專(zhuān)注于持續(xù)交付和靈活性。工作項(xiàng)在看板上表示為卡片，通過(guò)不同的開(kāi)發(fā)階段進(jìn)行。與Scrum的固定長(zhǎng)度沖刺不同，看板允許連續(xù)的工作流程，沒(méi)有預(yù)定義的時(shí)間盒。

換言之，看板方法是連續(xù)不間斷的，而Scrum是不斷重復(fù)一個(gè)流程來(lái)達(dá)到迭代?？窗宸椒ǜm合那些需要在開(kāi)發(fā)周期中處理很多不確定的工作的團(tuán)隊(duì)，通常用于突發(fā)請(qǐng)求、售后支持和優(yōu)先級(jí)不斷變化的項(xiàng)目。與Scrum不同，看板沒(méi)有固定的角色或儀式，使其更適應(yīng)不同的場(chǎng)景。

另一個(gè)流行的是XP（極限編程），它專(zhuān)注于工程實(shí)踐以提高軟件質(zhì)量。它強(qiáng)調(diào)測(cè)試驅(qū)動(dòng)開(kāi)發(fā)、結(jié)對(duì)編程和頻繁發(fā)布等實(shí)踐。XP 鼓勵(lì)開(kāi)發(fā)人員、測(cè)試人員和客戶(hù)之間的密切合作。

顧名思義，XP專(zhuān)注于軟件開(kāi)發(fā)的技術(shù)方面，在實(shí)踐中常被那些采用其他敏捷框架的團(tuán)隊(duì)揉和在各自的框架中去最大限度地發(fā)掘團(tuán)隊(duì)成員的開(kāi)發(fā)潛力。和看板方法一樣，極限編程也在追求減少浪費(fèi)，專(zhuān)注于眼下的代碼開(kāi)發(fā)而不是考慮明天的計(jì)劃或者下個(gè)月的安排等等。

Scrum強(qiáng)調(diào)角色之間的劃分，功能驅(qū)動(dòng)開(kāi)發(fā)（FDD）更專(zhuān)注于首席程序員，開(kāi)發(fā)經(jīng)理等。它適用于可以分解為明確定義的功能的項(xiàng)目。FDD以增量方式構(gòu)建軟件為中心，專(zhuān)注于特定于客戶(hù)需求的功能或用例。它使用功能列表來(lái)指導(dǎo)開(kāi)發(fā)。

3、未來(lái)會(huì)如何

即使有種種缺點(diǎn)，Scrum仍然非常受歡迎。大約56%的公司使用Scrum作為獨(dú)立方法，其中約83%的公司將其與XP或看板或其他敏捷方法一起使用為混合模型。

最近，不得不注意到有些變化也在悄然發(fā)生。今年年初，美國(guó)第一資本投資國(guó)際集團(tuán)（Capital One）解雇了整個(gè)敏捷部門(mén)，將這些角色合并到現(xiàn)有的產(chǎn)品經(jīng)理中。Scrum Master監(jiān)督團(tuán)隊(duì)的時(shí)代很可能會(huì)悄然逝去，而企業(yè)可能會(huì)在團(tuán)隊(duì)中接受敏捷實(shí)踐，或者選擇類(lèi)似于Capital One實(shí)施的模型。

參考鏈接：https://analyticsindiamag.com/scrum-is-not-agile-enough/