是否應該為技術債建立使用者故事?

2021-09-17 07:52:44 字數 2405 閱讀 1563

敏捷團隊有時也會為純技術性任務而掙扎,比如必須處理技術債。雖然這種任務對系統使用者沒有直接價值,但要交付可以工作的軟體又不得不處理。那麼,是不是應該建立使用者故事來應對這樣的技術性任務或技術債呢?

\ 在博文《像「作為開發者……」這樣的表達並非使用者故事》中,bill wake談到了他所遇到的對客戶沒什麼價值的使用者故事。作為例子,他提到了「作為開發者,我想配置jenkins,以便進行持續整合」這個使用者故事。bill解釋了為什麼我們不應將其稱作使用者故事:

\

\

我不是說這些活動不好,或者說不重要,它們也是面向這個團隊的,不過將其當作使用者故事會誤導團隊及其客戶。把與使用者無關的東西以使用者故事的形式寫下來,這是沒抓住要領。

\

\

他的觀點是,應該稱其為任務,而非使用者故事。根據精益思想,他認為這些活動其實是種浪費:

\

\

從精益思想的角度看,團隊所做的很多活動都可以視作浪費,但我們又不知道如何避免這些活動從而有效地進行軟體開發。精益團隊稱其為「不增加價值,卻又必不可少」,因為這是不得已而為之的事。

\

\

bill建議,如果某些使用者故事的角色不是來自實際軟體使用者,而是來自於開發之中,這時一定要慎重。可以嘗試將這樣的使用者故事重新組織為功能行為或質量特性,然後換種描述方式;如果行不通,再考慮將其看作任務。作為任務,開發團隊需要跟蹤,但又不應將其作為使用者故事放在產品backlog上,因為它們並不交付價值:

\

\

(……)承認你的團隊有時面對的只是任務。可以內部跟蹤這些任務,但是不要將其看作所開發系統的直接進展,更不要將其當作直接進展來跟蹤。

\

\

關於如何在產品backlog中處理技術性任務,mattias marschall在其博文《技術上很重要的事物,怎樣表達出「業務價值」》中提出了一種方案。他首先解釋了如何看待使用者故事與技術性任務之間的關係:

\

\

使用者任務應該描述使用者想讓系統做的事情。純粹的技術性任務通常實現為使用者故事的一部分。

\

\

但如何處理與具體的使用者故事沒有直接關聯的技術性任務呢?mattias建議把它們放到產品backlog上:

\

\

要把技術性任務按優先順序放到產品backlog中,那就為每一項建立乙個使用者故事。等等,這不是弄虛作假嗎?不,如果你能回答如下兩個問題,那就不是:

\ 誰能從其結果中受益?\

為什麼這個任務是必要的?\

\

利用他的解決方案,我們既可以把所有的技術性任務包含到產品backlog中的使用者故事裡去,也可以將其作為面向客戶的使用者故事的一部分,還可以使用乙個專為技術性任務建立的使用者故事來應對:

\

\

如果你能將技術性任務明確地表達為一種使用者故事,那麼利益相關者就能理解它們的必要性,並將它們與其他使用者故事一起優先考慮。

\

\
\

開發者了解技術債,也能意識到面對這種問題的重要性。

\ 產品所有者往往不理解減少技術債的必要性和收益所在,因此他們不會考慮甚至不允許把技術性專案或使用者故事列入他們的產品backlog和發布計畫中。

\

\

他建議由產品所有者負責減少技術債。團隊成員應該與產品所有者討論技術債,並共同努力,讓技術債在產品backlog中具有正確的優先順序:

\

\

團隊應該記住,產品所有者是團隊的一分子,他的痛苦就是大家的痛苦,反之亦然。他不是團隊的客戶、買主或老闆,而更像是來自不同利益相關者的主題專家(sme,subject matter expert)和產品需求管理者/分析員。

\ 團隊向產品所有者保證產品成長,這仍然是最重要的——不管從短期的績效還是從長期的健康來看,都是如此。

\

\

bastian建議把所有的技術性問題收集到使用者故事中,評估投入和產出。他將收益稱為「報酬」,因為解決了問題能減少技術債:

\

\

(……)針對我們定義的每一項任務,我們在jira中建立標記為「technicaldebtitems」的使用者故事。為了安排這些專案的優先順序並得出正確結論,我們建立乙個圖表來將投入與回報的相互關係視覺化。

\

\

視覺化有助於產品所有者和團隊協作減少技術債。

\

\

通過將技術債和可能的回報視覺化,(……)現在團隊可以把精力集中在最重要的步驟上。還有乙個重要的***:這也是與產品所有者和利益相關者協同工作的乙個極好工具,因為它使技術債對他們也有很好的透明度。

\

\

檢視英文原文should you create user stories for technical debt?

建構函式和析構函式是否應該為虛函式

建構函式不能是虛函式。因為建立派生類的物件時,將呼叫派生類的建構函式,而不是基類的建構函式,然後,派生類的建構函式將使用基類的乙個建構函式,這種順序不同於繼承機制。因此,派生類不繼承基類的建構函式,所以將類建構函式宣告為虛的沒什麼意義。析構函式應該是虛函式,除非類不用做基類。例如當e為基類,s是派生...

在校大學生應該為創業準備什麼

又到了每年一度的畢業季了,一部分高校畢業生走出校門,進入社會。有的人是選擇了自己心儀的公司,開始工作 一部分人則是選擇考研深造,繼續求學之路 另一部分人則是選擇創業。現在的大學生都很有想法,準備創業的大學生不在少數。那麼作為在校大學生,如果有創業的打算,需要提前做好準備。第一 關注國家政策 國家一直...

是否應該跳槽?

這不是android程式設計師的問題,而是所有行業的共同問題。樓主估計是覺得自己的工作沒意思,看著別的工作好像很牛的樣子,或者看見別的人公升遷快,於是見獵心喜了吧。但這個問題很難一概而論。我和樓主不熟悉,所以不敢說樓主現在是不是真的該換工作。權且問幾個問題,當拋磚引玉了 你是不是把所有手邊的工作都做...