使用者故事：卡片、對話和確定；基於三個步驟進行開展。
舉例：專案：a公司是一家檢測裝置公司下的子公司，主要服務物件是製造業，由於早起軟體系統陳舊，導致客戶滿意度很低。公司決定，面向製造業的痛點，重新開發一款迎合當下市場的軟體，應包含：企業基礎架構、生產作業管理、生產質量管理、生產過程監控、能耗管理等等，需要在3個月內上線。幸運的是，客戶願意指派對接人員與研發人員一起規劃系統。
在某周的早上，客戶、產品負責人、研發小組、scrum教練在乙個單獨的環境中，展開對系統需求的研討和系統功能的確定。
識別客戶：
1.每人面前擺放一堆空白卡片，接下來，所有成員開始絞盡腦汁在卡片上書寫使用者角色卡片：
2.直到所有人無法再想起其他角色，下一步將所有使用者角色卡片進行彙總，去除相同的角色，過程略…
又過了許久…
角色確定為：
基於上面的團隊對每個角色卡片討論，他們覺得有必要更新一下使用者角色卡片：
有了上述的使用者角色卡片及延展性的備註後，scrum教練向組員建議建立使用者畫像，並解釋使用者畫像可以使使用者角色更豐滿立體，不再是冰冷的需求代號，而是真實存在。
於是，廠長葉海龍這一畫像，就這樣誕生了：（基於真實存在的人員）
通過這張畫像，是否對系統某乙個使用者的形象更為具體？組員是否更清晰產品所要面向的具體使用者，那麼系統功能就會相對清晰明了，避免了基於客戶/研發人員頭腦中」理所當然的需求「；
有了這些最初的故事列表，團隊進入下乙個步驟」編寫故事作坊「，於是成員又開始進行一次頭腦風暴：
** 第一種方式：**
使用者不能註冊系統，需要管理員在系統進行配置；
管理員給使用者設定角色，不同角色在系統中擁有不同的角色許可權；
使用者可以看到產線實時生產數量；
使用者可以打卡上崗；
不良品禁止流向下乙個工位；
來料需要檢測；
裝置需要點檢；
可以制定生產計畫；
可以對接考勤系統；
檢測模板可以上傳到系統中;
可以編寫生產計畫；
生產實時看板…
第二種方式：
葉海龍：
可以檢查排產是否合理，由系統根據每條線的產量進行自動計算；
可以看到產線實時的生產數量；
可以檢視某個**商的來料彙總資訊，已決定是否驗收付款簽字；…結束
直到組員無法再寫出新的故事卡，然後將所有故事卡進行彙總，除去重複的，組員終於可以松一口氣，喝杯咖啡。別高興的太早，活還沒有幹完。接下來要做什麼呢？各位思考一下…
總結：使用者畫像可以簡單理解成是海量資料的標籤，根據使用者的目標、行為和觀點的差異，將他們區分為不同的型別，然後每種型別中抽取出典型特徵，賦予名字、**、一些人口統計學要素、場景等描述，形成了乙個人物原型 (personas)。
巨集觀 – 構建具象認知，構建戰略、戰術方向:為了讓團隊在核心使用者上達成統一且具象的認知，方便在後續投入上有的放矢；根據使用者畫像的資訊做產品設計，必須要清楚知道使用者長什麼樣子，有什麼行為特徵和屬性，這樣才能為產品提出戰略和戰術層面的指導。
微觀 – 構建底層資料基礎，如第二條所講，可以讓產品更符合使用的真實需求，從而更好的貼合客戶；一切只為客戶滿意度，否季度kpi又泡湯了。
微觀 – 方便資訊的處理:有了標籤後組員可以方便地處理各個量化需求並進行分類，評估迭代週期。
07 精益敏捷專案管理 敏捷發布計畫
00.如果有什麼事情是必然的，改變就是一種必然。我們今天制定的計畫將在明天發生改變。菲利普.克羅斯比 01.在為戰鬥做貯備的過程中，我常常發現計畫本身其實沒有什麼用處，但制定計畫是絕對必要的。德懷特.d.艾森豪威爾 02.對鏡益 敏捷軟體開發來說，企業轉型的乙個主要原因是為了能做出可預見且準備發布計...
敏捷專案管理之計畫撲克遊戲
有效的估算是軟體開發人員在工作中面臨的最嚴峻挑戰之一。無論團隊規模如何，他們都需要在整個團隊中定義，評估和分配工作。隨著團隊的擴大，圍繞計畫和評估工作養成良好的習慣變得越來越重要。缺乏計畫和估計會降低對程式的信心，破壞團隊與業務之間的關係，並使每個人的開發工作更加困難。根據對軟體專案實驗中個人和小組...
計畫估計 敏捷流程 專案經理和使用者場景
專案 魚類識別輔助系統 此專案源於我參加的乙個大創專案，現已基本完成 專案計畫 現在人們的生活多種多樣，有時候我們會選擇去水族館海洋公園這些地方。在觀賞這些海洋生物時，我們普通人很難辨認出這些生物的基本資訊。本系統是為適應於的魚類識別而開發的軟體。從魚的識別其種類，幫助客戶獲得魚類資訊，提供全面資料...