1、瀑布式開發(fā)

流程	關(guān)鍵詞	關(guān)鍵人員	輸出
立項(xiàng)	簡(jiǎn)述、周期、預(yù)算	領(lǐng)導(dǎo)	立項(xiàng)申請(qǐng)表、立項(xiàng)評(píng)審表
策劃	計(jì)劃	項(xiàng)目經(jīng)理、QA、CM	各種計(jì)劃書（項(xiàng)目、配置、測(cè)試等），評(píng)審
需求	功能	項(xiàng)目經(jīng)理	功能列表、需求規(guī)格書、需求開發(fā)計(jì)劃等，評(píng)審
設(shè)計(jì)	UML	開發(fā)	設(shè)計(jì)（概要、詳細(xì)、數(shù)據(jù)庫）、分析、評(píng)審
編碼	寫代碼	開發(fā)	源碼、單元測(cè)試、安裝包、產(chǎn)品集成、代碼審查
測(cè)試	測(cè)試	測(cè)試	需求測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、缺陷跟蹤、評(píng)審
手冊(cè)	使用文檔	項(xiàng)目經(jīng)理	安裝手冊(cè)、操作手冊(cè)
驗(yàn)收	發(fā)布、驗(yàn)收	客戶	確認(rèn)表、驗(yàn)收單
結(jié)項(xiàng)	評(píng)價(jià)	領(lǐng)導(dǎo)	總結(jié)報(bào)告
質(zhì)保	維護(hù)	QA	檢查表、問題跟蹤表

2、Scrum

2.1 簡(jiǎn)述

Scrum是迭代式增量軟件開發(fā)過程，是敏捷方法論中的重要框架之一
百度百科：https://baike.baidu.com/item/Scrum/1698901?fr=aladdin
推薦博客：https://blog.csdn.net/a715167986/article/details/128716292

2.2 術(shù)語

角色

產(chǎn)品負(fù)責(zé)人 Product Owner： 負(fù)責(zé)維護(hù)產(chǎn)品訂單的人，代表利益相關(guān)者的利益。
Scrum主管 Scrum Master： 為Scrum過程負(fù)責(zé)的人，確保scrum的正確使用并使得Scrum的收益最大化。一般不翻譯。
開發(fā)團(tuán)隊(duì) Team: 由負(fù)責(zé)自我管理開發(fā)產(chǎn)品的人組成的跨職能團(tuán)隊(duì)。

工件

產(chǎn)品列表 Product Backlog：根據(jù)用戶價(jià)值進(jìn)行優(yōu)先級(jí)排序的高層需求。
沖刺訂單 Sprint Backlog：要在沖刺中完成的任務(wù)的清單。
產(chǎn)品增量 Increment：最終交付給客戶的內(nèi)容

活動(dòng)

計(jì)劃會(huì) Sprint Planning Meeting：在每個(gè)沖刺之初，由產(chǎn)品負(fù)責(zé)人講解需求，并由開發(fā)團(tuán)隊(duì)進(jìn)行估算的計(jì)劃會(huì)議。
每日立會(huì) Daily Standup Meeting：團(tuán)隊(duì)每天進(jìn)行溝通的內(nèi)部短會(huì)，因一般只有15分鐘且站立進(jìn)行而得名。
評(píng)審會(huì) Review Meeting：在沖刺結(jié)束前給產(chǎn)品負(fù)責(zé)人演示并接受評(píng)價(jià)的會(huì)議。
反思會(huì)/回顧會(huì) Retrospective Meeting：在沖刺結(jié)束后召開的關(guān)于自我持續(xù)改進(jìn)的會(huì)議。

其他

沖刺 Sprint: 一個(gè)時(shí)間周期（通常在2周到1個(gè)月之間），開發(fā)團(tuán)隊(duì)會(huì)在此期間內(nèi)完成所承諾的一組訂單項(xiàng)的開發(fā)。

2.3 用戶故事

用戶故事（user story）是從用戶的角度來描述用戶渴望得到的功能。一個(gè)好的用戶故事包括三個(gè)要素：

角色：	誰要使用這個(gè)功能。
活動(dòng)：	需要完成什么樣的功能或目標(biāo)。
商業(yè)價(jià)值：為什么需要這個(gè)功能，這個(gè)功能帶來什么樣的價(jià)值。

用戶故事通常按照如下的格式來表達(dá)：
英文：

As a <Role>, I want to <Activity>, so that <Business Value>.

中文：

作為一個(gè)<角色>, 我想要<活動(dòng)>, 以便于<商業(yè)價(jià)值>

舉例：

作為一個(gè)“網(wǎng)站管理員”，我想要“統(tǒng)計(jì)每天有多少人訪問了我的網(wǎng)站”，以便于“我的贊助商了解我的網(wǎng)站會(huì)給他們帶來什么收益?！?

需要注意的是用戶故事不能夠使用技術(shù)語言來描述，要使用用戶可以理解的業(yè)務(wù)語言來描述。
關(guān)于用戶故事，Ron Jeffries用3個(gè)C來描述它：

卡片（Card） - 用戶故事一般寫在小的記事卡片上。卡片上可能會(huì)寫上故事的簡(jiǎn)短描述，工作量估算等。
交談（Conversation）- 用戶故事背后的細(xì)節(jié)來源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通。
確認(rèn)（Confirmation）- 通過驗(yàn)收測(cè)試確認(rèn)用戶故事被正確完成。

用戶故事的六個(gè)特性- INVEST

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable獨(dú)立性  可協(xié)商性  有價(jià)值  可以估算性  短小  可測(cè)試性

• 獨(dú)立性（Independent）— 要盡可能的讓一個(gè)用戶故事獨(dú)立于其他的用戶故事。用戶故事之間的依賴使得制定計(jì)劃，確定優(yōu)先級(jí)，工作量估算都變得很困難。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性。
• 可協(xié)商性（Negotiable）— 一個(gè)用戶故事的內(nèi)容要是可以協(xié)商的，用戶故事不是合同。一個(gè)用戶故事卡片上只是對(duì)用戶故事的一個(gè)簡(jiǎn)短的描述，不包括太多的細(xì)節(jié)。具體的細(xì)節(jié)在溝通階段產(chǎn)出。一個(gè)用戶故事卡帶有了太多的細(xì)節(jié)，實(shí)際上限制了和用戶的溝通。
• 有價(jià)值（Valuable）— 每個(gè)故事必須對(duì)客戶具有價(jià)值（無論是用戶還是購買方）。一個(gè)讓用戶故事有價(jià)值的好方法是讓客戶來寫下它們。一旦一個(gè)客戶意識(shí)到這是一個(gè)用戶故事并不是一個(gè)契約而且可以進(jìn)行協(xié)商的時(shí)候，他們將非常樂意寫下故事。
• 可以估算性（Estimable）—開發(fā)團(tuán)隊(duì)需要去估計(jì)一個(gè)用戶故事以便確定優(yōu)先級(jí)，工作量，安排計(jì)劃。但是讓開發(fā)者難以估計(jì)故事的問題來自：對(duì)于領(lǐng)域知識(shí)的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時(shí)需要把故事切分成小些的）。
• 短小（Small）— 一個(gè)好的故事在工作量上要盡量短小，最好不要超過10個(gè)理想人/天的工作量,至少要確保的是在一個(gè)迭代或Sprint中能夠完成。用戶故事越大，在安排計(jì)劃，工作量估算等方面的風(fēng)險(xiǎn)就會(huì)越大。
• 可測(cè)試性（Testable）—一個(gè)用戶故事要是可以測(cè)試的，以便于確認(rèn)它是可以完成的。如果一個(gè)用戶故事不能夠測(cè)試，那么你就無法知道它什么時(shí)候可以完成。一個(gè)不可測(cè)試的用戶故事例子：軟件應(yīng)該是易于使用的。

2.4 史詩、特性

敏捷中需求通常被分為史詩、特性、用戶故事三大類別，逐層往下，粒度越來越小。需求直到被分解至用戶故事時(shí)，才能放入Scrum迭代。

史詩：由多個(gè)較小的故事組成的史詩。
特性：一組相關(guān)的故事，有價(jià)值的單方向功能集合。
用戶故事：獨(dú)立的較小用戶的價(jià)值交付單元。有可能不足以單獨(dú)發(fā)布。

2.5 豬與雞

2.5.1 雞和豬的故事

一天，一只雞散步時(shí)遇見了豬。
雞對(duì)豬說：“嗨，我們合伙開個(gè)餐廳吧?！?豬說：“好啊，那準(zhǔn)備取什么店名呢？”
雞說：“要不，就叫火腿和雞蛋吧?！?豬直接拒絕了：“那可不行。我要割肉，你只要下蛋。這樣下去，我遲早要完蛋。”

2.5.2 保護(hù)“豬”，兼顧“雞”

這個(gè)故事實(shí)際上反映了軟件開發(fā)過程中的2種不同角色，即需要完全投入的“豬”和只要部分投入的“雞”。真實(shí)項(xiàng)目過程中，往往會(huì)發(fā)生這樣的現(xiàn)象，產(chǎn)品經(jīng)理或領(lǐng)導(dǎo)，喜歡臨時(shí)往項(xiàng)目中新增任務(wù)，打亂原先的開發(fā)節(jié)奏，導(dǎo)致程序員壓力倍增，士氣低落，項(xiàng)目延期。

而Scrum，就是為了保護(hù)“豬”這種角色，兼顧“雞”的感受，從而確保整個(gè)項(xiàng)目正常交付。它是一套敏捷開發(fā)流程。

2.6 Scrum用到的工具

• 用戶故事。迭代計(jì)劃會(huì)議用到，Product Owner以用戶的角度去描述需求。如，作為一個(gè)學(xué)員，我希望能在做完一份試卷后，系統(tǒng)能針對(duì)我的薄弱點(diǎn)提供相應(yīng)的指導(dǎo)及練習(xí)。
• Product Backlog。迭代計(jì)劃會(huì)議用到，Product Owner事先將所有的用戶故事按優(yōu)先級(jí)排好，放到一個(gè)列表內(nèi)，這個(gè)列表就是Product Backlog。
• Sprint Backlog。迭代計(jì)劃會(huì)議用到，整個(gè)開發(fā)小組通過估點(diǎn)將用戶故事按優(yōu)先級(jí)移入到迭代計(jì)劃內(nèi)，迭代計(jì)劃中待完成的用戶故事列表即為Sprint Backlog。
• 估點(diǎn)。主要用于評(píng)估用戶故事的大致工作量。下一篇文章會(huì)額外介紹估點(diǎn)。
• 燃盡圖。主要用于迭代進(jìn)度的管控。下一篇文章會(huì)額外介紹燃盡圖。

2.7 Scrum標(biāo)準(zhǔn)流程

2.7.1 Scrum標(biāo)準(zhǔn)流程之Sprint Planning Meeting

迭代計(jì)劃會(huì)議中，整個(gè)小組通過估點(diǎn)的方式，按優(yōu)先級(jí)將用戶故事從Product Backlog中移入到Sprint Backlog，表示整個(gè)小組承諾本迭代要做完的任務(wù)。做完的標(biāo)準(zhǔn)是測(cè)試通過，除非此任務(wù)不可測(cè)試。

2.7.2 Scrum標(biāo)準(zhǔn)流程之Daily Stand Up Meeting

迭代計(jì)劃會(huì)后，小組成員按個(gè)人喜好領(lǐng)取自己的任務(wù)，并在每天的站立會(huì)議上講一下自己昨天做了什么，今天準(zhǔn)備作什么，大概什么時(shí)候完成，以及遇到了什么問題。當(dāng)有人提出遇到難題時(shí)，Scrum Master需要在會(huì)后安排人幫忙解決，而不是在會(huì)議上直接解決。每個(gè)人大概30秒-1分鐘，整個(gè)會(huì)議一般不超過15分鐘。每一個(gè)工作日結(jié)束后，需要畫燃盡圖（下一篇文章會(huì)額外介紹）。

2.7.3 Scrum標(biāo)準(zhǔn)流程之Review Meeting

一個(gè)迭代開發(fā)階段結(jié)束后，進(jìn)入內(nèi)部演示會(huì)議，工作成果給整個(gè)小組演示（包括Project Owner）。EduSoho的做法是，bug及小優(yōu)化不演示，點(diǎn)數(shù)較大的功能點(diǎn)做演示。

2.7.4 Scrum標(biāo)準(zhǔn)流程之Restrospective Meeting

內(nèi)部演示結(jié)束后，整個(gè)小組（包括Project Owner）召開一個(gè)迭代回顧會(huì)，回顧本迭代中大家哪些做的好，哪些做的不好，每人各列舉3個(gè)好的以及不好的，列的時(shí)候只講現(xiàn)象，不分析原因，不找解決方案。然后整個(gè)小組投票選出3個(gè)不好的，分析原因，尋找解決方案，并指定執(zhí)行者。

為什么只解決3個(gè)不好的？每個(gè)小組的精力有限，如果要一個(gè)迭代內(nèi)解決全部問題，不太現(xiàn)實(shí)，先優(yōu)先解決3個(gè)最重要的，多次迭代后，會(huì)發(fā)現(xiàn)整個(gè)小組的變化越來越明顯。