——有關於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.程式設計師估算時，客戶也可以參加，但是他不能提供他人人的估算或者在聽到自己不贊成的估...