趨勢從傳統(tǒng)到敏捷

趨勢從傳統(tǒng)到敏捷第一頁，共六十一頁，2022年，8月28日趨勢1970年軟件開發(fā)瀑布模型發(fā)布 1975年《人月神話》第一版1984年SEI成立 1987年《人件》出版

1991年CMM體系發(fā)布 1991年Scrum首次命名1995年ISO/IEE12207發(fā)布 1995年Scrum論文首次發(fā)表1996年RUP首次提出 1996年第一個正式XP項目1999年準CMM2.0完成－未發(fā)布

2000年持續(xù)集成方法被提出2002年CMMI1.1發(fā)布 2001年敏捷聯(lián)盟成立第二頁，共六十一頁，2022年，8月28日CONTENTS軟件項目管理Scrum框架介紹》》行業(yè)和市場變遷自組織項目團隊和敏捷第三頁，共六十一頁，2022年，8月28日軟件項目管理項目管理起源：第四頁，共六十一頁，2022年，8月28日傳統(tǒng)項目管理代表性技術(shù)：關(guān)鍵性途徑方法（CriticalPathMethod）和項目評估和反思（PERT）技術(shù)。CPM美國杜邦公司和蘭德公司，1957年聯(lián)合研究提出它假設(shè)每項活動的作業(yè)時間是確定值重點在于費用和成本的控制。PERT美國海軍特種計劃局和洛克希德航空公司，1958年用概率的方法進行估計的估算，重點在于時間控制被主要應(yīng)用于含有大量不確定因素的大規(guī)模開發(fā)研究項目。軟件項目管理第五頁，共六十一頁，2022年，8月28日1986年11月，美國卡內(nèi)基.梅隆大學軟件研究所（SEI）受美國國防部的委托1987年9月開發(fā)了一套軟件能力成熟度框架和一套軟件成熟度問卷，用來評估軟件供應(yīng)商的能力。1991年，SEI自己總結(jié)了軟件過程能力成熟度模型（CapacityMaturityModel-CMM）成熟度框架和初版并以此為基礎(chǔ)推出CMM1.0版。1992年4月，SEI舉行了CMM一個的研討會，參加研討會的有大約200名富有經(jīng)驗的軟件專家。1997年，美國聯(lián)邦航空管理局（FAA）開發(fā)了FAA-iCMMSM（聯(lián)邦航空管理局的集成CMM）1997年11月，CMM2完成改進版，99年完成準CMM2.0，1999年，美國國防部辦公室要求SEI推遲發(fā)布CMM2.0版本，而要先完成一個更為緊迫的項目CMMI。（即能力成熟度集成模型，他們想把現(xiàn)在所有的以及將被發(fā)展出來的各種能力成熟度模型集成到一個框架中去2002年，CMMI1.1發(fā)布軟件項目管理－SEI的研究3/10/2023第六頁，共六十一頁，2022年，8月28日軟件項目管理－能力成熟度模型第七頁，共六十一頁，2022年，8月28日軟件項目管理－能力成熟度模型CMM中的關(guān)鍵過程域第2級(可重復級)，6個過程域

需求管理(RM)、軟件項目計劃(SPP)、軟件項目跟蹤與監(jiān)控(SPTO)、軟件子合同管理(SSM)、軟件質(zhì)量保證(SQA)、軟件配置管理(SCM)第3級(定義級)，7個過程域

組織過程焦點(OPF)、組織過程定義(OPD)、培訓程序(TP)、集成軟件管理(ISM)、軟件產(chǎn)品工程(SPE)、組間協(xié)調(diào)(IC)、同級評審(PR)第4級(管理級)，2個過程域

定量過程管理(QPM)、軟件質(zhì)量管理(SQM)第5級(優(yōu)化級)，3個過程域

缺陷預(yù)防(DP)、技術(shù)變更管理(TCM)、過程變更管理(PCM)第八頁，共六十一頁，2022年，8月28日軟件項目管理9項目計劃WBS分解工作量估算、規(guī)模估算關(guān)鍵路徑設(shè)定業(yè)務(wù)類子計劃：架構(gòu)、開發(fā)、測試；過程類子計劃：配置、質(zhì)量保證；協(xié)作類子計劃：評審、溝通、……項目跟蹤持續(xù)度量、糾偏工作量投入、產(chǎn)出變更項目總結(jié)項目度量項目考核和評價第九頁，共六十一頁，2022年，8月28日CONTENTS軟件項目管理Scrum框架介紹》》行業(yè)和市場變遷自組織項目團隊和敏捷第十頁，共六十一頁，2022年，8月28日IT行業(yè)的變化－80年代前信息技術(shù)（InformationTechnology）傳感技術(shù)這是人的感覺器官的延伸與拓展，最明顯的例子是條碼閱讀器；通信技術(shù)這是人的神經(jīng)系統(tǒng)的延伸與拓展，承擔傳遞信息的功能；計算機技術(shù)這是人的大腦功能延伸與拓展，承擔對信息進行處理的功能。主要客戶

大型企業(yè)和政府：軍工、制造、能源、金融、政府管理核心價值

縮短信息處理時間

減少信息處理的人力投入

提高信息處理的準確率信息的創(chuàng)造者和使用者：

政府機構(gòu)人、企業(yè)人3/10/2023第十一頁，共六十一頁，2022年，8月28日IT行業(yè)的變化－00年代后互聯(lián)網(wǎng)技術(shù)（internetTechnology）硬件技術(shù)－主要指數(shù)據(jù)存儲、處理和傳輸?shù)闹鳈C和網(wǎng)絡(luò)通信設(shè)備；軟件技術(shù)－搜索、網(wǎng)絡(luò)傳輸、網(wǎng)絡(luò)安全、通訊、流媒體、網(wǎng)站部署、電子交易……主要客戶

客戶和用戶分離

向用戶提供軟件和服務(wù)；并銷售用戶訪問流量

典型例子：搜索引擎，向所有人提供無差異的搜索服務(wù)，并向所有客戶出售廣告位。核心價值

消費信息－－普遍的、無差異的信息服務(wù)－－長尾經(jīng)濟信息的創(chuàng)造者和使用者：

自然人、法人、社會人、機器人、……長尾(TheLongTail)：圖中所示黃色的部份第十二頁，共六十一頁，2022年，8月28日軟件供應(yīng)商的變化－業(yè)務(wù)領(lǐng)域3/10/2023定制信息服務(wù)

為單一/相似客戶提供信息化實現(xiàn)服務(wù)，依托計算設(shè)備硬件更新、提供配套軟件，改善企業(yè)或機構(gòu)數(shù)據(jù)處理效率。

以項目/施工形式運作，一攬子交付制度（客戶安裝、調(diào)試、培訓、觀察和穩(wěn)定、附送維護期）

典型例子：美國國防部70年代廣泛的不靠譜項目為行業(yè)提供解決方案

當信息計算在各企業(yè)普及后，為某個明確的領(lǐng)域或行業(yè)提供廣泛的技術(shù)解決方案 IBMPC和WindowsPS的大量普及，軟件供應(yīng)商在定制服務(wù)中積累了大量行業(yè)知識，結(jié)合各專業(yè)領(lǐng)域研究機構(gòu)的理論，逐漸形成全行業(yè)通用的解決方案、IT技術(shù)和方法得以大規(guī)模復制。

典型例子：依據(jù)生產(chǎn)管理理論提出的MRP、ERP等解決方案第十三頁，共六十一頁，2022年，8月28日軟件供應(yīng)商的變化－角色定位銷售許可

為企業(yè)/行業(yè)提供業(yè)務(wù)邏輯、計算、存儲等方案，以軟件銷售為主要業(yè)務(wù)。

典型案例：WindowsOS、MSOffice、OracleDB基礎(chǔ)設(shè)施即服務(wù)（InfrastructureasaService，IaaS）

向客戶提供處理、儲存、網(wǎng)絡(luò)以及各種基礎(chǔ)運算資源，部署與執(zhí)行操作系統(tǒng)或應(yīng)用程式等各種軟件。

典型案例：域服務(wù)、云存儲、電子郵件等軟件即服務(wù)（SoftwareasaService，SaaS

）

向企業(yè)、行業(yè)提供遠程計算、信息存儲、數(shù)據(jù)交易等服務(wù)，按照使用時間或次數(shù)等收費費用。不需要安裝，客戶直接注冊購買服務(wù)。

典型案例：

S第十四頁，共六十一頁，2022年，8月28日軟件開發(fā)團隊的變遷（一）從作坊到車間

作坊：人數(shù)較少，簡單的組織結(jié)構(gòu)、粗放的管理方法，以項目為驅(qū)動，缺少工程方法支撐、過程控制基本沒有。

車間：人數(shù)增多，從單一開發(fā)工程師，逐漸分離出測試人員，設(shè)定了一定的規(guī)則，引入測試缺陷管理工具等，從游擊隊到正規(guī)軍

游擊隊：開發(fā)工具簡單，作業(yè)流程就是拿到需求開發(fā)，工程師在戰(zhàn)斗中學會戰(zhàn)斗，都是自學成長型戰(zhàn)士，缺乏組織系統(tǒng)化的培訓，團隊整合靠緣分。組織方式以職能部門為主。

正規(guī)軍：組織使用專業(yè)工具、專人維護，具備穩(wěn)定的作業(yè)流程、組織有明確的工程師職業(yè)培訓制度，注重工程師的績效和激勵，項目管理制度化、系統(tǒng)化。組織方式以矩陣制為主。第十五頁，共六十一頁，2022年，8月28日軟件開發(fā)團隊的變遷（二）大規(guī)模軟件集成開發(fā)

決策：決策周期相對更長，考慮更多，更保守

分工：規(guī)模越大、專業(yè)越細分、單一職能工程師類型越多

組織：管理層金字塔結(jié)構(gòu)明顯，管理崗位增加

工具化：更廣泛使用專業(yè)工具，更嚴密地過程控制

矩陣：職能管理者掌握更多人力資源，項目管理者需要持續(xù)爭取資源

團隊：通常距離市場都非常遙遠，向行政上級匯報的趨勢明顯第十六頁，共六十一頁，2022年，8月28日互聯(lián)網(wǎng)時代的挑戰(zhàn)不談技術(shù)

無論客戶、還是用戶，對技術(shù)的關(guān)心越來越少，對他們而言，提供什么樣的服務(wù)比使用了什么樣的技術(shù)更靠譜耐心有限

可供選擇的產(chǎn)品和服務(wù)越來越多

所需要投入的學習和轉(zhuǎn)換成本越來越低

不再關(guān)注功能是否足夠多

比質(zhì)量更重要的是更新速度第十七頁，共六十一頁，2022年，8月28日CONTENTS軟件項目管理Scrum框架介紹Scrum實踐之旅》》行業(yè)和市場變遷自組織項目團隊和敏捷第十八頁，共六十一頁，2022年，8月28日探索的趨勢企業(yè)關(guān)注的

標準：盡可能讓工程師做有標準的工作，這樣看起來更容易評估成果。

數(shù)據(jù)積累：更多的數(shù)據(jù)積累有助于形成標準，并進而為管理提供易操作的判斷依據(jù)。

效率：從管理要效益，采用合適的管理方法，幫助管理者更透明的了解團隊的工作，并做出最佳決策。團隊關(guān)注的

戰(zhàn)斗力：保持持久的團隊戰(zhàn)斗力，不干擾團隊成員的工作，不當?shù)墓芾頃绊憫?zhàn)斗力。

經(jīng)驗：有經(jīng)驗的工程師可以更快的解決問題，他們的經(jīng)驗上升為把握風險的直覺，工程師有能力判斷風險并采用自己的方法來避免更出現(xiàn)更糟糕的結(jié)果

效率：采用更新的技術(shù)工具和方法，把工程師從簡單勞動中解放出來，做有價值的事情，避免管理活動上消耗工程師精力第十九頁，共六十一頁，2022年，8月28日趨勢－傳統(tǒng)VS敏捷傳統(tǒng)

命令型

顯式知識（依賴文檔）

計劃驅(qū)動

自上而下

控制為主要手段敏捷

自組織

隱式知識（經(jīng)驗）

變更驅(qū)動

自上而下

應(yīng)變?yōu)橹饕侄蚊艚莶皇切迈r事物第二十頁，共六十一頁，2022年，8月28日趨勢－20年軟件工程標志性事件摘錄1970年軟件開發(fā)瀑布模型發(fā)布 1975年《人月神話》第一版1984年SEI成立 1987年《人件》出版

1991年CMM體系發(fā)布 1991年Scrum首次命名1995年ISO/IEE12207發(fā)布 1995年Scrum論文首次發(fā)表1996年RUP首次提出 1996年第一個正式XP項目1999年準CMM2.0完成－未發(fā)布

2000年持續(xù)集成方法被提出2002年CMMI1.1發(fā)布 2001年敏捷聯(lián)盟成立第二十一頁，共六十一頁，2022年，8月28日敏捷宣言22第二十二頁，共六十一頁，2022年，8月28日敏捷宣言個體和交互

勝過

過程和工具可以工作的軟件

勝過

面面俱到的文檔客戶合作

勝過

合同談判響應(yīng)變化

勝過

遵循計劃服務(wù)的對象始終是用戶責任導向成果導向第二十三頁，共六十一頁，2022年，8月28日敏捷的意識《人月神話》-1975第5章畫蛇添足在開發(fā)第一個系統(tǒng)時，結(jié)構(gòu)師傾向于精煉和簡潔。他知道自己對正在進行的任務(wù)不夠了解，所以他會謹慎仔細地工作。

在設(shè)計第一個項目時，他會面對不斷產(chǎn)生的裝飾和潤色功能。這些功能都被擱置在一邊，作為“下一個”項目的內(nèi)容。第一個項目遲早會結(jié)束，而此時的結(jié)構(gòu)師，對這類系統(tǒng)充滿了十足的信心，熟練掌握了相應(yīng)的知識，并且時刻準備開發(fā)第二個系統(tǒng)。

第二個系統(tǒng)是設(shè)計師們所設(shè)計的最危險的系統(tǒng)。

第15章另外一面面對那些文檔“簡約”的程序，我們中的大多數(shù)人都不免曾經(jīng)暗罵那些遠在他方的匿名作者。因此，一些人試圖向新人慢慢地灌輸文檔的重要性：旨在延長軟件的生命期、克服惰性和進度的壓力。但是，很多次嘗試都失敗了，我想很可能是由于我們使用了錯誤的方法。第二十四頁，共六十一頁，2022年，8月28日敏捷的意識《人件》－1987第5章重新研究帕金森定律帕金森定律表明：只要還有時間，工作就會不斷擴展，直到用完所有的時間。帕金森定律認為給一個項目多少時間，它總能將之消耗完。這個定律給了他們（經(jīng)理）可能最堅強的信念：把工作做好的唯一方法是制訂一個不可能的、樂觀的交付時間。帕金森定律幾乎肯定不適用于你的員工。當一個項目完全不合理或不現(xiàn)實的時候，不能再加班加點。項目組的成員會產(chǎn)生憤怒的情緒并在內(nèi)心滋生一種挫敗感——并且士氣會降到谷底?！ㄅ了埂き偹梗–apersJones）公司繁忙的工作有膨脹填滿工作日的趨勢。注：帕金森定律（Parkinson'sLaw）是官僚主義或官僚主義現(xiàn)象的一種別稱,源于英國學者C.N.帕金森所著《帕金森定律》一書的標題第二十五頁，共六十一頁，2022年，8月28日敏捷的意識《人件》－1987第6章苦杏仁苷軟件管理的七個不真實的期望：有使你的生產(chǎn)力劇增的新訣竅，你已經(jīng)錯過了。其他經(jīng)理的成效是正100%、200%或者更多。技術(shù)正飛快發(fā)展，而你正在被淘汰。改變語言將使你收獲巨大。因為待做的項目堆積如山，你需要立即加倍地提高生產(chǎn)力、其他任何事情你都順其自然，是不是你對手下的軟件開發(fā)人員也放任自由。如果將你手下的人置于很大的壓力下，他們會工作得更好。第二十六頁，共六十一頁，2022年，8月28日敏捷的12條原則（一）我們最重要的目標，是通過持續(xù)不斷地及早交付有價值的軟件使客戶滿意；我們歡迎需求變化，即使在開發(fā)后期也一樣。為了客戶的競爭優(yōu)勢，敏捷過程掌控變化；經(jīng)常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期；業(yè)務(wù)人員和開發(fā)人員必須相互合作，項目中的每一天都不例外；激發(fā)個體的斗志，以他們?yōu)楹诵拇罱椖?。提供所需的環(huán)境和支援，輔以信任，從而達成目標；不論團隊內(nèi)外，傳遞信息效果最好效率也最高的方式是面對面的交談；第二十七頁，共六十一頁，2022年，8月28日敏捷的12條原則（二）可以工作的軟件是進度的首要度量標準；敏捷過程倡導可持續(xù)開發(fā)。責任人、開發(fā)人員和用戶要能夠共同維持其步調(diào)穩(wěn)定延續(xù)；堅持不懈地追求技術(shù)卓越和良好設(shè)計，敏捷能力由此增強；以簡潔為本，它是極力減少不必要工作量的藝術(shù)；最好的架構(gòu)、需求和設(shè)計出自自組織團隊；團隊定期地反思如何能提高成效，并依此調(diào)整自身的行動。第二十八頁，共六十一頁，2022年，8月28日自組織團隊特征（一）開放性

作為自組織團隊，體現(xiàn)開放性的最基本活動是與外界的信息交換，信息互動溝通的模式和效果，不但影響自組織團隊的工作效率，而且會決定自組織團隊的演變過程和涌現(xiàn)結(jié)果;自主性

自組織就是沒有外界特定的干涉。換句話說，就是自己決定自己的事情，不需要外界的干預(yù)。作為自組織團隊，其行為決策完全由自己決定，而不受外界干預(yù);適應(yīng)性

自組織團隊具有適應(yīng)性，是指它能夠與外界交流，通過交流來學習或積累經(jīng)驗，并利用學到的經(jīng)驗改變自身的結(jié)構(gòu)和行為方式，推動團隊的發(fā)展和進步。3/10/2023第二十九頁，共六十一頁，2022年，8月28日自組織團隊特征（二）復雜性

“適應(yīng)性造就復雜性”。從自組織團隊定義、自組織團隊形成過程、自組織團隊演化方面呈現(xiàn)出復雜性；非線性

非線性表現(xiàn)在團隊成員之間的相互關(guān)系上，使團隊成員形成復雜的關(guān)系網(wǎng)絡(luò)，非線性也使團隊中的成員能夠依一定規(guī)則或程序而相互制約和相互監(jiān)督，使團隊中每一個成員不至于做出超越管理權(quán)限的行為而損害整個組織。動態(tài)性

動態(tài)性是指自組織團隊從形成、成長、成熟到消亡的整個生命周期過程是動態(tài)變化的，即使在每一個階段，也是動態(tài)變化的。遠離平衡態(tài)，新情況和新問題隨時都可能發(fā)生。如果沒有變化，該團隊就離消亡不遠了3/10/2023第三十頁，共六十一頁，2022年，8月28日自組織團隊VS管理慣性1、團隊人員無所適從，不知道該做什么。很多開發(fā)人員對敏捷方法不能適應(yīng)，他們已經(jīng)習慣了聽從命令與安排的方式 2、任務(wù)安排不平衡，團隊成員在開發(fā)過程中偷工減料。耽于安逸的開發(fā)人員或許會利用管理的漏洞或管理人員對他的信任，胡亂估計任務(wù)的工作量，或者夸大任務(wù)實現(xiàn)的難度；3、自由失去節(jié)制，無論是技術(shù)方案的討論和評審，還是任務(wù)工作量的評估，因為沒有絕對權(quán)威，很容易失去控制，因糾纏于細節(jié)而讓大量的討論浪費時間第三十一頁，共六十一頁，2022年，8月28日CONTENTS軟件項目管理Scrum框架介紹》》行業(yè)和市場變遷自組織項目團隊和敏捷第三十二頁，共六十一頁，2022年，8月28日什么是SCRUMScrum是唯一的敏捷項目管理方法Scrum是一個框架，在這個框架中人們可以應(yīng)對復雜的適應(yīng)性問題，同時也能頗有成效地和具有創(chuàng)造性地交付最高價值的產(chǎn)品。Scrum是：輕量級的容易理解的極難駕馭的Scrum框架包括角色事件工件規(guī)則第三十三頁，共六十一頁，2022年，8月28日SCRUM框架第三十四頁，共六十一頁，2022年，8月28日SCRUM框架角色ProductOwnerDevlopmentTeamScrumMaster第三十五頁，共六十一頁，2022年，8月28日SCRUM角色ProductOwner負責最大化產(chǎn)品以及開發(fā)團隊工作的價值是管理產(chǎn)品待辦事項列表的唯一責任人。清晰地表達產(chǎn)品代辦事項列表條目對產(chǎn)品代辦事項列表中的條目進行排序，最好地實現(xiàn)目標和使命確保開發(fā)團隊所執(zhí)行工作的價值確保產(chǎn)品代辦事項列表對所有人可見、透明、清晰，并且顯示Scrum團隊的下一步工作確保開發(fā)團隊對產(chǎn)品代辦事項列表中的條目達到一定程度的理解第三十六頁，共六十一頁，2022年，8月28日SCRUM角色DevlopmentTeam開發(fā)團隊包含了專業(yè)人員，負責在每個Sprint的結(jié)尾交付潛在可發(fā)布的“完成”產(chǎn)品增量。只有開發(fā)團隊的成員才能創(chuàng)造增量。開發(fā)團隊由組織構(gòu)建并授權(quán)，來組織和管理他們的工作。所產(chǎn)生的協(xié)同工作能最大化開發(fā)團隊的整體效率和效力。開發(fā)團隊有以下幾個特點：自組織的跨功能的每個成員可以有特長和專注領(lǐng)域，但是責任歸屬于整個開發(fā)團隊開發(fā)團隊不包含如測試或業(yè)務(wù)分析等負責特定領(lǐng)域的子團隊。第三十七頁，共六十一頁，2022年，8月28日SCRUM角色ScrumMaster負責確保Scrum被理解并實施。幫助Scrum團隊外的人員了解他們?nèi)绾闻cScrum團隊交互是有益的。通過改變這些交互來最大化Scrum團隊所創(chuàng)造的價值第三十八頁，共六十一頁，2022年，8月28日SCRUM角色ScrumMaster之對于PO找到有效管理產(chǎn)品代辦事項列表的技巧清晰地和開發(fā)團隊溝通愿景、目標和產(chǎn)品代表事項列表條目教導開發(fā)團隊創(chuàng)建清晰簡明的產(chǎn)品代表事項列表條目在經(jīng)驗主義環(huán)境中理解長期的產(chǎn)品規(guī)劃理解并實踐敏捷按需推動Scrum事件第三十九頁，共六十一頁，2022年，8月28日SCRUM角色ScrumMaster之對于DevelopmentTeam指導開發(fā)團隊自組織和跨功能教導并領(lǐng)導開發(fā)團隊創(chuàng)造高價值的產(chǎn)品移除開發(fā)團隊進展過程中的障礙按需推動Scrum事件在Scrum還未完全被采納和理解的組織環(huán)境下指導開發(fā)團隊第四十頁，共六十一頁，2022年，8月28日SCRUM角色ScrumMaster之對于組織領(lǐng)導并指導組織采用Scrum在組織范圍內(nèi)計劃Scrum的實施幫助員工及干系人理解并實施Scrum和經(jīng)驗性產(chǎn)品開發(fā)觸發(fā)能增長Scrum團隊生產(chǎn)力的改變與其他ScrumMaster一起工作，來增加組織中Scrum應(yīng)用的效力第四十一頁，共六十一頁，2022年，8月28日SCRUM框架Scrum事件SprintSprint計劃會議每日立會Sprint評審Sprint回顧第四十二頁，共六十一頁，2022年，8月28日SCRUM事件SprintScrum的核心是控制在一個時間盒單元中，產(chǎn)出“完成”的、可用的、潛在可發(fā)布的產(chǎn)品增量。Sprint在整個開發(fā)過程中的周期一致。新的Sprint在上一個Sprint完成之后立即開始。Sprint包含并由Sprint計劃會議、每日例會、開發(fā)工作、Sprint評審會議和Sprint回顧會議構(gòu)成。Sprint中不能做出影響Sprint目標的改變開發(fā)團隊的組成和質(zhì)量目標是不變的隨著知識的增加，產(chǎn)品負責人和開發(fā)團隊可以澄清或者重新商談開發(fā)范圍第四十三頁，共六十一頁，2022年，8月28日SCRUM事件Sprint計劃會議分成兩部分第四十四頁，共六十一頁，2022年，8月28日SCRUM事件每日立會保證24小時內(nèi)的計劃立會不是進度匯報不超過15分鐘每人描述三個問題，保證增量目標從上次會議到現(xiàn)在都完成了哪些工作；下次每日例會之前準備完成什么；工作中遇到了哪些障礙。第四十五頁，共六十一頁，2022年，8月28日SCRUM事件Sprint評審會檢驗增量交付引發(fā)反饋主要因素產(chǎn)品負責人確定哪些工作“完成”了，哪些工作沒有“完成”開發(fā)團隊討論在Sprint中哪些工作進展順利、遇到了什么問題、問題是如何解決的開發(fā)團隊演示“完成”的工作并解答關(guān)于所交付增量的問題產(chǎn)品負責人和與會人員按現(xiàn)實情況討論產(chǎn)品待辦事項列表，并基于當前的進度推測可能的完成日期整個團體就下一步的工作進行探討，這樣，Sprint評審會議就能為接下來的Sprint計劃會議提供了有價值的信息。第四十六頁，共六十一頁，2022年，8月28日SCRUM事件Sprint回顧會Scrum團隊檢驗自身并創(chuàng)建下個Sprint改進計劃的機會Sprint回顧會議的目的是：對前一個Sprint周期中的人、關(guān)系、過程和工具進行檢驗識別并排序做得好的和能潛在改進的主要條目創(chuàng)建實施改進Scrum團隊工作方式的計劃第四十七頁，共六十一頁，2022年，8月28日SCRUM框架Scrum工件ProductBacklogSprintBacklogIncrement(增量)第四十八頁，共六十一頁，2022年，8月28日SCRUM工件ProductBacklog字面意思：積壓的工作、待辦事宜PO負責ProductBacklog的維護和更新常見的待辦事宜包括但不局限于需求，可能的類型：功能特性缺陷技術(shù)工作知識獲取Backlog的維護只要產(chǎn)品活著，Backlog就會持續(xù)更新僅僅就已知的事情來組織Backlog不假裝知道“我們了解產(chǎn)品所有的需求”第四十九頁，共六十一頁，2022年，8月28日SCRUM工件ProductBacklogScrum中主流的方法是用戶故事作為……（角色定位）我希望…………（訴求和期待）這樣可以……（目的和價值）用戶故事類型史詩：產(chǎn)品重要的里程碑主題：若干個Sprint完成的一組功能策劃故事：產(chǎn)品功能，一個Sprint周期內(nèi)實現(xiàn)第五十頁，共六十一頁，2022年，8月28日PRODUCTBACKLOGProductBacklog史詩級：作為一個手機控我希望能夠很方便地使用手機制作、收藏、分享gif文件這樣本身就很有趣第五十一頁，共六十一頁，2022年，8月28日PRODUCTBACKLOGProductBacklog故事級：作為一個手機微博控我希望能夠很方便地把我制作和收藏