淺析SCRUM開發(fā)過程

劉楊

摘要：敏捷開發(fā)過程重視團隊的交流與管理問題，其提高開發(fā)效率的成果著實明顯，一直在軟件管理學術領域保持著充分的活力; SCRUM過程無疑是目前最為成功的敏捷方法。它強調(diào)的小團隊、多交流、頻繁發(fā)布的開發(fā)模式取得了巨大成功。

本文將結合實際，對SCRUM的思想和開發(fā)過程進行詳述。

關鍵詞：軟件工程;敏捷開發(fā);SCRUM

一、SCRUM的來源和理論

SCRUM很容易被認為是某些單詞的首字母集合，但其實并不是。SCRUM是一個英文固有單詞，原意是指英式橄欖球的一種爭球活動。1986年，日本學者首次使用了Scrum來代指軟件開發(fā)過程中的如下活動：

一種以團隊為單位通過相互合作，來回傳球，向前推進的軟件開發(fā)方式。

看來，SRCUM的初衷就是重視團隊之間的交流以及頻繁的效果展示或交付。

SCRUM也推崇了增量模型的開發(fā)理念。軟件開發(fā)的增量模型就強調(diào)要在開發(fā)過程中出現(xiàn)多個交付版本。最初的版本是“核心產(chǎn)品”，可以滿足用戶基本的需求;繼而在后續(xù)多個增量中，產(chǎn)品的功能不斷得到完善。比如，要為用戶制作一款導航軟件。那么在第一階段，可以讓用戶能在軟件中先看到地圖，對軟件的充滿信心;第二個版本可以加入定位功能;第三個版本指定地點，進行測距;……最終一步步地完善產(chǎn)品的功能，使用戶不斷地對軟件的未來充滿希望，讓需求一步步地被滿足，盡可能避免了最終產(chǎn)品與需求偏差過大。這種開發(fā)過程將是十分具有成就感的。

二、SCRUM的開發(fā)過程

SCRUM推崇6至9人的小團隊模式，認為這樣能夠較大地縮短交付時間和成本。當一個軟件開發(fā)開始，其實誰都不能精確知道項目最終會做成什么樣子;對于此，SCRUM要求將項目劃分為多個里程碑。每次里程碑就相當于一個增量。每當完成一個里程碑任務，團隊應當產(chǎn)生一個最初的可執(zhí)行版本，并且及時地組織會議，對當前版本的開發(fā)情況進行探討。每日例會是SCRUM開發(fā)的核心和精髓。會議內(nèi)容大概可以分為三部分：發(fā)現(xiàn)和提出問題（展示已做的功能）、檢查和修正開發(fā)方向、制定下一步的開發(fā)計劃。

會議開始時，各個成員或者小組向大家講述上一階段的目標以及完成的情況，并展示相關功能或者出具組內(nèi)設計和討論的結果;接著，“檢查和修正開發(fā)方向”，這一步是最為重要的，因為這一步和用戶的需求直接掛鉤，影響著整個產(chǎn)品的質(zhì)量好壞，也決定著項目的成敗。這里就要提到SCRUM中PO和SM兩個角色。

SM，即Scrum Master，這個角色需要1～2名成員，它們需要在開發(fā)過程中一直保持頭腦清醒，牢牢把握住項目的需求以及需求變更，以能夠在每次里程碑會議上正確地判斷當前項目的前進方向是否符合當前的項目需求，如果設計有跑偏的跡象，則要及時對項目的理念提出修改建議?？梢哉fSM決定著項目的“生命”。

PO，即Project Owner，其任務是在每次討論中綜合大家提出的BUG或者改進意見，在會后能夠將更新修改的部分整合到項目中，并根據(jù)SM的指導意見整理出團隊的下一階段目標。PO的存在保證了項目的完成質(zhì)量。在較小的項目開發(fā)中，PO和SM兩個角色也可以由同一人擔任。

雖然最終的開發(fā)方向由SM來指導，但是SCRUM是鼓勵每個成員在會議中積極發(fā)表意見，最好能形成頭腦風暴，經(jīng)常能產(chǎn)生一些極有價值的觀點，最終可以被記錄到階段目標中，并將其逐步實現(xiàn)。

就這樣，通過每次里程碑的團隊會議，在糾正項目方向的同時保證產(chǎn)品的功能質(zhì)量，逐漸地完成軟件的增量。

三、功能設計要求

在設計軟件的功能上，強調(diào)User Story（用戶場景）和Acceptance Criteria（接受條件）。

用戶場景是指，用戶為了完成某一項操作，而要使用的一系列功能集合。這里可能牽扯到一個角色轉換的問題。開發(fā)人員并不容易從用戶的角度去考慮使用的問題，尤其是在面對自己做的功能時，很難發(fā)現(xiàn)一些使用戶體驗差的問題。而嘗試編寫一個用戶場景能夠較容易地將開發(fā)員人帶入到用戶的角色中思考問題。假如要設計一款具有定位發(fā)布簽到功能的軟件，那么從用戶角度設想一下，為了發(fā)布簽到，用戶可能經(jīng)過如下步驟：

1.點擊發(fā)布簽到按鈕;2.設置簽到名稱;3.設置簽到開始時間;4.設置簽到結束時間;5.設置簽到中心點;6.設置簽到范圍;7.點擊發(fā)布按鈕。

那么以上七步就是一個完整的User Story。User Story能夠很有效地讓開發(fā)人員盡早地發(fā)現(xiàn)用例設計的不足;或者是在測試時能夠感覺到一些設計上對用戶不友好的地方。

在考慮軟件功能設計時，還可以通過考慮其接收條件來確保功能的完整性。也就是考慮AC-Acceptance Criteria。AC是User Story的一部分。它要求開發(fā)者考慮在執(zhí)行User Story之前用戶所必須已做的一些操作。

參考文獻：

[1] [美] Roger S. Pressman，等.軟件工程：實踐者的研究方法（第8版）[M].鄭人杰，等，譯.北京：機械工業(yè)出版社， 2016： 32， 53-54.

[2] 葉俊文.基于Scrum敏捷方法的標準研制項目管理優(yōu)化研究[D]. 廣州： 華南理工大學， 2018.