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