丨敏捷開發(fā)到底是想解決什么問題

敏捷開發(fā)就是ScrumSprint（字面意思是沖刺，可以理解為迭要理解敏捷開發(fā)，我們先要了解其誕生背景。在2001年那會，瀑布模型還是主流，我們知道，瀑布模型是一種“重型”的開發(fā)模式，整個流程走完通常周期很長，少則數(shù)月，多則數(shù)于是由瀑布模型衍生出很多模型，試圖去改善瀑布模型存在的問題，我已經(jīng)在上一篇文章中給你介紹了一些。不過除了介紹的那些以外，在當(dāng)時還有一些不怎么有名，而現(xiàn)在卻如雷貫耳的輕量級開發(fā)方法，例如極限編程（ExremeProramming，XP）、Srum等。2001初，17位代表上述各種輕量級軟件開發(fā)過程流派的領(lǐng)物在一起，討論替代（來源：敏捷開發(fā)具，能幫助團(tuán)隊“敏捷”起來，但它們和敏捷開發(fā)之間的關(guān)系，更像是“術(shù)”和“道”的關(guān)敏捷開發(fā)中流行的站立會議，主要目的是為了保證團(tuán)隊成員充分的溝通，遇到可以及時尋求幫助。但是如果每天的站立會議流于形式，并不能起到有效的目的，則應(yīng)該減少頻度，甚至取消換成其他方式。如果你讀仔細(xì)讀了敏捷，你會發(fā)現(xiàn)，中右邊的內(nèi)容其實都是瀑布模型的內(nèi)容：比如說，我們開始做一個新項目，需要從客戶那里收集整理需求，如果按照傳統(tǒng)的軟件開發(fā)模式，我們需要在開發(fā)前獲得所有需求，然后和客戶簽訂合同，在發(fā)布前都不會輕易修改需求。施工人員根據(jù)用戶故事和客戶進(jìn)一步溝通（客戶合作高于合同談判），然后對用戶故事進(jìn)每個用戶故事開發(fā)時，還要給一個測試機(jī)器人編寫測試，讓機(jī)器人可以自動測試（大每個Sprint四個星期時間（時間盒子，迭代時間固定第一個Sprint（Sprint），屋頂還在漏水（SprintSprint（Sprint故事，還會修復(fù)Bug）；Sprint（敏捷推崇自動化測試，但可能會測第四個Sprint升級成了磚瓦房，窗戶也開好了，客戶可以入住。但是這時候客戶發(fā)現(xiàn)一家三口的話，完全不夠用，需要擴(kuò)建到3個臥室。于是決定下個迭代改成3個臥室（響第五個Sprint，升級成了3個臥室，升級過程中把廚房下水道弄壞了（迭代過程中可能第六個Sprint，修復(fù)了下水道的問題，房子也裝修好了（迭代中不斷完善）；用敏捷開發(fā)的方式，不再像瀑布模型那樣有嚴(yán)格的階段劃分，會在迭代中不斷完善；不再寫很多文檔，而是和客戶一起緊密合作；不再需求變更，而是即時響應(yīng)變更；不再等到測試階段才發(fā)布，而是隨時發(fā)布，客戶隨時可以看到東西。由于我大學(xué)時學(xué)軟件工程，那時學(xué)的就是瀑布模型，畢業(yè)后很多年的項目開發(fā)都是以瀑布模型為主的，所以我在剛開始去看敏捷開發(fā)，總會以瀑布模型的方式類比敏捷開發(fā)，實踐的時候也難以擺脫瀑布模型的影響?！癝crum我將基于Scrum瀑布模型的一個重要階段就是需求分析，要有嚴(yán)謹(jǐn)?shù)男枨蠓治?，產(chǎn)生詳盡的需求分析文檔。而敏捷開發(fā)的需求，主要是來源于一個個小的用戶故事，用戶故事通常是寫在卡片上的一句話，在Sprint的開發(fā)中，再去確認(rèn)需求的細(xì)節(jié)。完整的用戶需求開發(fā)，每個Sprint只做一部分需求，所以是一種漸進(jìn)式的架構(gòu)設(shè)計，當(dāng)前Sprint只做適合當(dāng)前需求的架構(gòu)設(shè)計。瀑布模型在編碼完成后，會有專門的階段進(jìn)試，以保證質(zhì)量。在敏捷開發(fā)的Srint中，并沒有專門的測試階段，這就依賴于開發(fā)功能的同時，要編寫單元測試和集成測試代碼，用自動化的方式輔助完成測試。微軟的Windows就是個很好的例子，在Windows10之前，Windows的開發(fā)模式是傳統(tǒng)的類瀑布模型，有很長一段測試的時間，質(zhì)量有很好的保障，Windows10開始，采用在敏捷開發(fā)中，這種持續(xù)構(gòu)建、持續(xù)發(fā)布的概念叫持續(xù)集成，因為整個過程都是全自動化的，每次完成一個任務(wù)，提交代碼后都可以觸發(fā)一次構(gòu)建部署操作，會拿的代碼做一次全新的構(gòu)建，然后運(yùn)行所有的單元測試和集成測試代碼，測試通過后部署到測試環(huán)境。敏捷開發(fā)的Sprint捷開發(fā)（Scrum），一個迭代/Sprint的時間周期都是2周（10個工作日）。迭代模型所在的團(tuán)隊，產(chǎn)品經(jīng)理會先花2332再看敏捷開發(fā)的團(tuán)隊，ProductOwner（類似于產(chǎn)品經(jīng)理）會把需求拆分成了幾個簡單的用戶故事：用戶登錄、用戶、找回、修改資料，然后放到當(dāng)前Sprint的BacklogAProductOwner功能完成后，同時程序員A還寫了單元測試代碼和集成測試代碼，對登錄的功能寫了自動A4繼續(xù)選取“找回”的用戶故事來做，4天時間也完成了。其他程序員也和程序員A一樣，他們也會從Backlog1BugBacklog，程序員們在完成用戶故事后，開始著手修復(fù)這些Bug，正好在最后2天都修復(fù)SprintSprintSprint 其實，敏捷開發(fā)無論國內(nèi)還是國外，大廠還是小廠，都已經(jīng)有無數(shù)成功案例。這些年，軟件工程中一些好的實踐，像持續(xù)集成、測試驅(qū)動開發(fā)、結(jié)對編程、看板等都來自于敏捷開發(fā)。可以肯定，敏捷開發(fā)是一種非常好的軟件開發(fā)模式。軟件開發(fā)，最的是人，而不是用什么方法，以前沒有敏捷開發(fā)只有瀑布模型的時候，也一樣誕生了大量偉大的軟件，像Windows、Office?，F(xiàn)在有敏捷開發(fā)，的是讓我們多實施敏捷開發(fā)能給你的項目帶來哪些好處？如果要實施，你打算從什么地方入手？如果已經(jīng)實施了敏捷開發(fā)，你覺得用法對嗎？有哪些做的好的或者不好的地方？歡迎在留言區(qū)與我分享討論。 不得售賣。頁面已增加防盜追蹤，將依法其上一 04|瀑布模型之外，還有哪些開發(fā)模型下一 06|大廠都在用哪些敏捷方法？（上純潔的憎 11作者回復(fù):又是一篇高質(zhì)量的 白發(fā)青 8你把所有求拆分用戶故，對用故事進(jìn)打（了解下劃類的打方案）然pri北有池 不再回 … 3 白），此外能從回復(fù)中看出來老師的鼓勵和引導(dǎo)（這個老師的一些留言回復(fù)龍 3阿 2王二 2 ??（rmr） 2 謝禾急 1我沒有經(jīng)歷過完整的敏捷開發(fā)，但是體驗過站立會議。我感覺站立會議有以下好處：1確當(dāng)天目標(biāo)；2.了解團(tuán)隊成員的工作進(jìn)展和：3.有可以及時得到同事的幫助。 1作者回復(fù):敏捷說的：“工作的軟件高于詳盡的文檔。盡管右項有其價值，我們更重視左項梁中 目都并發(fā)，大吐量的求，如果省了這個步，一般開人員估摸著就開始開發(fā)了，這塊的技術(shù)債會越來越多，甚至一上線就要重構(gòu)。我感覺候，