Scrum框架但凡接觸過一點(diǎn)敏捷的小伙伴，一定會(huì)聽過 Scrum 的大名，為啥呢？因?yàn)楦鞔蠡ヂ?lián)網(wǎng)公司確實(shí)都在應(yīng)用很多 Scrum 的實(shí)踐。比如我學(xué)習(xí)過的網(wǎng)易云課堂的項(xiàng)目管理微專業(yè)課程，里面的講的基本上就都是 Scrum 的各種東西。 許多其他頭部大廠的項(xiàng)目管理部門相關(guān)的公眾號(hào)，也經(jīng)常會(huì)分享一些 Scrum 的經(jīng)驗(yàn)，這一切都說明一個(gè)問題，Scrum 是現(xiàn)在最流行的敏捷框架。 Scrum的由來這個(gè)由來嘛，大家可以自己百度一下，Scrum 這個(gè)名詞是在誕生于 橄欖球 運(yùn)動(dòng)的。但是在這里，我們只說一個(gè)重點(diǎn)問題，那就是 Scrum 的誕生是為了解決什么問題。 在項(xiàng)目管理領(lǐng)域，有兩種項(xiàng)目類型，一是非常確定各個(gè)步驟流程細(xì)節(jié)的項(xiàng)目。就好像我們傳統(tǒng)的工程制造或者蓋樓。雖然也可能有各種臨時(shí)問題的出現(xiàn)，但經(jīng)過少則1、200年，多則幾百上千年的發(fā)展，其實(shí)很多工序都已經(jīng)非常成熟了。對(duì)于這類項(xiàng)目來說，傳統(tǒng)的 PMP 那種計(jì)劃式的項(xiàng)目管理其實(shí)并沒有什么太大的問題。在面對(duì)突發(fā)事件的時(shí)候，只要是有經(jīng)驗(yàn)的項(xiàng)目經(jīng)理，都會(huì)運(yùn)用各種儲(chǔ)備來解決。當(dāng)然，最主要的就是很多東西都已經(jīng)很成熟而且不會(huì)有太大的變化了。 但是，進(jìn)入信息爆炸的互聯(lián)網(wǎng)時(shí)代后，傳統(tǒng)項(xiàng)目管理的弊端就暴露出來了。科技進(jìn)步太快，時(shí)代風(fēng)向的轉(zhuǎn)變也太快。就像之前我們說過的，你完整的計(jì)劃完，再按步驟一步一步地開發(fā)出來，或許風(fēng)口早就過了。這個(gè)時(shí)代需要的是什么？快速驗(yàn)證，盡早試錯(cuò)，持續(xù)更新。這不就是敏捷的理念嘛！ 另外，現(xiàn)代軟件的復(fù)雜性或許對(duì)于不太了解軟件開發(fā)的人來說可能是一個(gè)未知的領(lǐng)域，充滿著神秘感。其實(shí)真實(shí)的情況是，不管是軟件還是硬件，都在向越來越復(fù)雜的方向發(fā)展。硬件知識(shí)我不太了解，但是現(xiàn)在 CPU 的技術(shù)想想都很可怕，而軟件方面 Windows 系統(tǒng)的源碼就算是一個(gè)超級(jí)高手，可能用一輩子的時(shí)間也讀不完。更別提各種大數(shù)據(jù)應(yīng)用中存儲(chǔ)的各類數(shù)據(jù)，每天都是以海量在遞增。量級(jí)大小決定了一個(gè)嚴(yán)重的問題，那就是 熵增 的不斷增強(qiáng)。熵增 就是說物質(zhì)總是在從有序變得無序，你之前以為的有序也是更早前有序所演化成的無序混亂，事物就是在一步步地向更復(fù)雜、更混亂的情況下發(fā)展。軟件技術(shù)如此，軟件開發(fā)的管理也是如此，就拿員工職位來說，早十來年，哪有什么前后端分離，而現(xiàn)在呢？前端都早就已經(jīng)成為一個(gè)工程化的部門了，人員越來越多，管理呢？當(dāng)然越來越混亂。 Scrum 就是為了應(yīng)對(duì)這兩種情況而出現(xiàn)的，它要解決的問題也無非就是這兩個(gè)：變化和混亂。而且它不局限于你使用什么方法，也就是說，它也是一個(gè)包容性很強(qiáng)的框架。你可以在 Scrum 中應(yīng)用 XP 的理念，但是，你要遵循一些 Scrum 的內(nèi)容，這些內(nèi)容就是一些流程、計(jì)劃、模式的應(yīng)用，遠(yuǎn)沒有 XP 那么詳細(xì)的偏向于軟件開發(fā)。也因此，Scrum 的應(yīng)用范圍會(huì)更廣一些。 與 XP 的不同
一般來說，Scrum 的迭代時(shí)間要求會(huì)比 XP 長(zhǎng)一些，XP 會(huì)更傾向于比較極限的 1-2 周的迭代時(shí)長(zhǎng)，而 Scrum 會(huì)更傾向于 2-4 周的迭代時(shí)長(zhǎng)。當(dāng)然，這個(gè)東西還是看我們的組織情況和項(xiàng)目情況來定的。
XP 是允許在迭代中修改需求的，如果在迭代未結(jié)束前，發(fā)現(xiàn)需求有問題，XP 是可以考慮替換、添加、刪除需求的。而 Scrum 則會(huì)在迭代開發(fā)結(jié)束前鎖定需求，在這個(gè)過程中，不能添加新的需求，由 Scrum Master 把關(guān)，防止其他人干擾團(tuán)隊(duì)的工作。
XP 在開發(fā)的過程中，會(huì)要求按照需求的優(yōu)先級(jí)來做。但是 Scrum 不同，它會(huì)在每次迭代計(jì)劃會(huì)議的時(shí)候，根據(jù)團(tuán)隊(duì)的速率，以及項(xiàng)目的進(jìn)度、要求，由團(tuán)隊(duì)來決定這一次迭代要做的東西。
Scrum 沒有這方面的強(qiáng)制保證，完全是信任團(tuán)隊(duì)的狀態(tài)，最多就是有一個(gè)迭代結(jié)束之后的評(píng)審會(huì)議。而在 XP 中，會(huì)要求 TDD 、持續(xù)集成、結(jié)對(duì)編程、簡(jiǎn)單設(shè)計(jì)、重構(gòu)等一系列的保證措施。 雖說有這么些不同，但是，在每個(gè)迭代的具體開發(fā)過程中，Scrum 是歡迎使用這些 XP 中的良好實(shí)踐的。因?yàn)檫@些并不影響整個(gè)流程，甚至運(yùn)用得當(dāng)還會(huì)對(duì)整個(gè)流程有益。因此，Scrum 更像是一種偏管理的實(shí)踐，而 XP 則更像是偏開發(fā)的實(shí)踐。兩者并沒有絕對(duì)的利益沖突。 Scrum的三大支柱和流程圖在 Scrum 中，有三個(gè)重要的支柱支撐著 Scrum 的各個(gè)方面，它們也是我們后面要講的 Scrum 實(shí)踐的理論基礎(chǔ)。
透明其實(shí)很簡(jiǎn)單，就是對(duì)于影響交付成果的各個(gè)方面，對(duì)于所有參與交付的人、管理生產(chǎn)成果的人來說，都應(yīng)該是清晰透明的。對(duì)于交付成果，所有人都已經(jīng)有一個(gè)統(tǒng)一的認(rèn)識(shí)，所有人也能理解現(xiàn)在的交付是不是我們想要的成果。這一點(diǎn)是不是很像 XP 中的 集體擁有代碼 ，前面就說過，XP 是更偏具體的技術(shù)實(shí)踐的，而在 Scrum 中，則擴(kuò)展到了全局范圍。所以，不管是代碼，文檔，概念，進(jìn)度，成本，指標(biāo)，總之一切與項(xiàng)目有關(guān)的東西，都是透明的。
在項(xiàng)目的開發(fā)過程中，各個(gè)方面都要做到充分的檢驗(yàn)，確保能夠及時(shí)發(fā)現(xiàn)整個(gè)開發(fā)過程中的重大偏差。通過定期的，一般是迭代后的檢驗(yàn)，也可以使團(tuán)隊(duì)發(fā)現(xiàn)需要改進(jìn)的地方。這個(gè)我不多說了，大家想想是 XP 哪些實(shí)踐的擴(kuò)展。
如果在檢查之后，發(fā)現(xiàn)有一個(gè)或多個(gè)方面不滿足驗(yàn)收標(biāo)準(zhǔn)，并且最終產(chǎn)品都有可能是不合格的，那么，我們就必須對(duì)整個(gè)過程進(jìn)行調(diào)整。調(diào)整過程必須要盡快實(shí)施以減少偏差。這個(gè)又是對(duì)應(yīng)著誰呢？大家仔細(xì)想想哦。 從這里也可以看出，其實(shí)這三大支柱也就是我們敏捷整體思想的一個(gè)簡(jiǎn)要概括。萬變不離其宗，最主要的依然還是要把握敏捷宣言以及那 12 條敏捷原則。 最后，我們?cè)賮砜纯?Scrum 的整個(gè)過程圖。 在這個(gè)過程圖中，又出現(xiàn)了一些沒聽過的名詞，別急，后面我們要講的東西就全在這張圖里面了。 總結(jié)今天的內(nèi)容其實(shí)就是 Scrum 的一個(gè)入門講解，我們了解到了 Scrum 誕生的原因，看到了 Scrum 與 XP 的不同，最后還點(diǎn)出了 Scrum 的三大理論支柱。當(dāng)然，最重要的是最后這張圖，因?yàn)槲覀兒罄m(xù)馬上就要來講這張圖上的內(nèi)容了，期待還是興奮呢，我想你應(yīng)該和我一樣，準(zhǔn)備全力沖向 Scrum 了吧。 參考文檔： 《某培訓(xùn)機(jī)構(gòu)教材》 《用戶故事與敏捷方法》 《高效通過PMI-ACP考試（第2版）》 《敏捷項(xiàng)目管理與PMI-ACP應(yīng)試指南》 |
|
|
