讀書筆記4 《使用者故事與敏捷方法》之Scrum

2021-07-05 08:45:07 字數 2195 閱讀 7846

——有關於scrum

scrum是乙個迭代遞增的過程。

一輪迭代的過程是一種持續改進的過程;

乙個遞增的過程是指按照功能點開發和發布軟體。每乙個功能點(功能增量),代表乙個完整的功能子集。每乙個功能增量都能被完整地實現以及測試通過。

scrum和極限程式設計都是基於遞增和迭代方式的過程。這兩種過程都在一輪新的迭代開始之前為迭代做計畫。並在後續迭代中改進以前的交付,而且總是在每輪迭代中把當前迭代所計畫的工作做完,貫穿整個專案總是可以持續地交付。

實施scrum過程的專案往往採用30天為週期的迭代,稱為sprint。

在每個sprint開始時,團隊需要確定這個sprint需要完成的工作;所有的工作內容放在乙個稱為產品backlog的排好優先順序的列表中;團隊根據自己的經驗從產品backlog中選擇下個sprint能夠完成的任務放入乙個稱為sprint backlog的列表中;團隊每天會有乙個簡單會議,稱為daily scrum。

(乙個scrum團隊通常遊4~7個開發人員組成。團隊裡通常沒有區分角色的說法,二是根據實際情況,自主決定怎樣完成剩餘的任務。另外,團隊裡還有兩個特殊角色人員,產品負責人和scrummaster。產品負責人主要負責管理product backlog的內容以及排列優先順序。scrummaster 的只能類似於專案經理,不過這個角色不是管理者,更像乙個領導者。但由於scrum團隊本身是自組織方式,由團隊成員自己決定如何完成當前任務,因此scrummaster更多的是為團隊服務,排除障礙保證團隊按照scrum的規則進行開發。

產品backlog,是所有待開發產品功能的列表。在專案初期,不需要投入大量精力寫出所有功能。

sprint計畫會議流程:產品負責人把待開發的高優先順序功能介紹給團隊,團隊成員針對這些功能提出問題,對於有足夠把握的某乙個功能就可以將其從產品backlog移到sprint backlog。

(注意點:

1.產品負責人只需要在此會議上,根據產品backlog內容的多少和團隊的速率(乙個sprint能夠完成的工作量),介紹高優先順序的條目,較低優先順序條目放到以後的sprint計畫會議中討論。

2.sprint開始時,召開sprint計畫會議。

3.每個sprint必須發布可以鞏固走到,經過測試的**,這些**能夠完成對最終客戶有價值的一些功能。

4.管對一起決定一輪迭代完成多少故事。

5.在任何時候都可以向產品backlog中新增故事,或重新排列優先順序。

6.在sprint結束時的sprint評審會議中,團隊會演示完成的成果。

7.團隊演示的是可以工作的軟體,而不是幻燈片。

8.準備sprint評審會議的時間不得超過兩小時。

9.只有在團隊覺得自己已經把sprint中承諾的所有任務都完成的前提下,才可以向sprint中增加新故事。此時,由團隊向產品負責』詢問要求新增一兩個使用者故事。

10.如果有十分重要的事情發生,組織發現需要做出調整,則是重新開sprint計畫會議,啟動乙個新的sprint,取消現在的sprint。

sprint評審會議,通常是演示在sprint中完成的工作,是新功能的演示。需要有意保持其非正式會議性質,盡量不用幻燈片,準備時間不要超過兩小時,以免讓團隊感覺它是一種干擾或負擔。

每日scrum簡會,每個團隊成員要求回答:①你昨天做了什麼②你今天打算做什麼③有什麼困難;該會議的乙個重要目的是讓成員在團隊面前作出承諾,同時也讓團隊成員了解到專案的進展。

如何在scrum中使用使用者故事?

比如scrum的backlog條目用使用者故事進行描述。scrum和極限程式設計一樣,產品負責人不需要一開始就確定所有需求,也不建議盡早維護很大的產品backlog,不過盡可能記錄更多的故事還是有一定好處。所以,首先確定使用者角色,然後根據角色來收集故事,在scrum中應用十分有效。

又比如在sprint計畫會議中使用使用者故事,團隊討論產品backlog中的高優先順序條目,然後確定在下乙個sprint需要完成的條目,記下來,然後把這些故事劃分成曉得任務,方便程式設計師認領。

又比如在sprint評審會議使用使用者故事,好處就是容易評估sprint中哪些部分已經完成。因為使用者故事本身的描述方式就是對客戶有價值的,同時也不涉及什麼技術任務、需求問題、缺陷這些細節的描述方式,所以也很容易向產品負責人演示。

又比如每日scrum簡會中使用使用者故事,能夠幫助團隊確定是否已經完成某乙個特定故事的足夠功能

《使用者故事與敏捷方法》讀書筆記

1.採用使用者故事這一方法,是從寫下兩條資訊開始的 每乙個系統需要實現的目標和實現那個目標所需要的大致成本。2.3c原則 card conversation confirmation 任務卡片 交流 確認 3.大量預先的需求收集和文件會議很多方式導致專案失敗。最常見的是需求文件變成軟體開發的目的。應...

敏捷讀書之使用者故事 《使用者故事與敏捷方法》解讀

本期分享mike cohn 使用者故事與敏捷方法 精益思想五步 價值,價值流,流動,拉動,盡善盡美。使用者故事是精益思想五步的核心載體。首先,使用者故事是價值載體,是承載使用者價值的基本單元。使用者故事要承載價值,而價值也要承載在使用者故事這種歸一化的載體中。其次,使用者故事是節拍器。故事有節奏的流...

08 使用者故事與敏捷方法 估算使用者故事筆記

00.估算故事最好方法 無論什麼時候獲得有關故事的新資訊,都允許我們改變之前的想法 適用於史詩故事和小故事 不需要花很多時間 提供進度和剩餘工作的有用資訊 不太精確的估算也不會有太大問題 可以用來制定發布計畫。01.程式設計師估算時,客戶也可以參加,但是他不能提供他人人的估算或者在聽到自己不贊成的估...