敏捷開發使用者故事系列之六 使用者故事的產生與組織結構

2022-09-06 10:18:10 字數 2332 閱讀 8022

這是使用者故事系列的第六篇。(之一,之二,之三,之四,之五,之六,之七,之八,之九)

一條需求敢跳出來,基本上就能被化成一條使用者故事,看完一二三四五,上山打老虎都不怕,這個似乎已經不太難了。

難的是,專案或產品的第一天,給一張白紙:「請列出有哪些故事」。那個時候其實不是大腦空空,而是有千言萬語就是說不出。

前年做另外一件事情的時候偶然得到一種方法,去年到今年用在乙個敏捷專案上,果然很舒服地列出了大量故事,後來的開發過程證實它們都滿足獨立交付、可測試、耦合低等特點,屬於好故事之列。

這件事情其實在之前的部落格中已經多次提到了,就是軟體專案的造價管理。注意這裡提到的是專案,而非產品研發。專案就是那種一手交錢一手交貨的甲乙方專案。

之前曾經提到過:無論有多少種方法對優先順序進行排序,作為產品而言,都永遠應該把最體現差異化價值觀的功能置於萬事之前。

這裡要說的則是:無論有多少管理方法,作為專案而言,都永遠應該把造價估算置於萬事之前。

這個前不是一般的前,最好能用幾張a4紙的篇幅就搞定,因為一般老闆剛去簽訂合同的時候,手裡沒有需求,沒有設計,沒有故事,就這麼幾張紙。當然另乙個尷尬的事情則是:即使有很厚的需求文件了,也仍然沒有方法知道要多久才能完成專案,真的很愁人。

其實這兩件事說的是一件事:如何在早期列出具有某種表徵意義的需求列表

在之前的部落格詳細描述過了,這裡只從產生和組織使用者故事的角度談談,詳情請看文末的鏈結。

在我們的開發工作中一共有兩類東西要開發,一種是資料,一種是操作。

所謂資料,就是比如要編寫乙個crm,其中有「使用者、角色、許可權」這三種東西,就是要管理的資料,這裡權且記下使用者有「3個史詩故事」要管理。

所謂操作,就是對使用者,應該有增、刪、改、查、加入角色……這些稱之為操作,這裡權且記下對使用者,使用者會有「5個使用者故事」。

史詩都是名詞,都是要被管理的核心資訊,而且是使用者可以理解的資訊;

故事都是動詞,都是使用者平日裡使用軟體產品所進行的業務操作;

最後乙個小貼士是每個史詩故事平均有7個左右的故事,少於4個要懷疑是不是史詩,多於10個要懷疑是不是應該拆分新的史詩了。

最後這條是nesma 20年來的經驗資料,很值得參考但莫較真。比如上面例子分為使用者/角色/許可權3個史詩對19個故事(平均6.3個),你可以試試再拆拆或合合,效果肯定不如這三個乾淨。只能說他們20年真沒白幹。

這個方法聽起來很水很模糊,但因為開過幾次造價估算培訓課,在我經手的3次培訓中,通過短短1天培訓後,4~5個小組的(最大-最小)/平均 誤差只有正負12%,而誤差的很大**,是乙個模擬問答環節總是比較嘈雜,很多團隊沒有注意聽答案!@¥#…%!核對需求後,誤差可迅速降低到大約一半。課堂練習只有一張a4紙,裡邊很模糊地隱含了多達90多個使用者故事,練習時間只有1小時,能達到如此的一致性已經很滿意了。

最早我們在史詩之上,就是無意義的層級式目錄結構了,但就像太陽系外有銀河系,銀河系外有超星系,超星系外有超星系團一樣,事情還沒有完。

本來以為在史詩之上沒有有實際邏輯意義的結構了,但發現「使用者角色許可權」這三個故事的距離,遠遠近於其他故事,應該還有一種具有邏輯意義的東西來描述;其他一些史詩故事也發現了這種內聚性,但尚無合理的劃分方法將其定義下來。

筆者暫時創造了「故事群」這個概念來描述他們,但沒有找到合理的定義,讓不同的人可以一致性地劃分故事群。

之所以借用功能點分析的概念來產生和組織使用者故事,是因為關於使用者故事,一直沒有非常標準的顆粒度和組織方法;而對於資料、操作,則在接近40年前就開始嘗試標準化定義,當前有5個國際標準之多,中國的國家標準也馬上出來了。在接受這些標準培訓後,不同個體對資料和操作的計數差異,只有不到10%;尚沒有任何使用者故事的定義能達到如此一致性。

敏捷世界一向有封閉的特性,比如cmmi在嘗試擁抱敏捷,但從來沒聽過敏捷擁抱cmmi的。

不否認創造和使用敏捷開發的一線員工在定義需求、制定計畫、每日跟蹤中的經驗和權威性,但在大尺度上掌握使用者故事的組織結構,以及在甚早期判斷專案範圍的方面,則正是這一人群的弱項。

敏捷方法需要借鑑已有的外界方法。

為什麼不用uml方法?因為本人很不熟悉uml。uml比較適合在大尺度上組織使用者故事,但很難在甚早期開展(一張a4,隱含90個故事,1小時估完)。

當然這不會抹殺uml在分析使用者故事中的作用,日後或許會請另外一位老師寫篇文章《使用者故事與uml》,我**過來作為其中一篇,以求完整。

早期功能點估算1:

早期功能點估算2:

敏捷開發使用者故事系列之六 使用者故事的產生與組織結構

這是使用者故事系列的第六篇。之一,之二,之三,之四,之五,之六,之七,之八,之九 一條需求敢跳出來,基本上就能被化成一條使用者故事,看完一二三四五,上山打老虎都不怕,這個似乎已經不太難了。難的是,專案或產品的第一天,給一張白紙 請列出有哪些故事 那個時候其實不是大腦空空,而是有千言萬語就是說不出。前...

敏捷開發使用者故事系列之五 使用者故事的分類

這是敏捷開發使用者故事系列的第五篇。之一,之二,之三,之四,之五,之六,之七,之八,之九 在之一 之二 之三中,我們曾經提到了 作為乙個 可以 以便 的使用者故事描述方式,還提到應該如何描述使用者故事,才能更好地反映客戶價值。下面請嘗試一下描述這兩個故事 1.如果把 儲存按鈕 統一放在頁面上端而非下...

敏捷開發使用者故事系列之一 何為使用者故事

這是敏捷開發使用者故事系列的第一篇。之一,之二,之三,之四,之五,之六,之七,之八,之九 全系列將涉及何為使用者故事,面向客戶價值編寫故事,使用者建模,產品待開發項的分類,故事顆粒度,故事的組織結構,等等若干問題,力求將此中問題盡量解決乾淨。按 作為乙個 可以 以便 樣式和思路寫成的使用者需求,就是...