Ruddy Lee 分享空間

Emergent Design 演化設計

如何做任務分解?

leave a comment »

任務分解Task Breakdown這是執行SCRUM的「計畫會議」裡第二階段所要進行的工作重點。會議進行的狀態: 一般是工程師依靠過去工作所累積下來的工作經驗,看一眼使用者故事的需求目的之後,便大膽的開始進行Breakdown了,完全是用經驗來進行任務拆解的工作。很直覺,適合經驗豐富的團隊,但團隊要是有一大堆新鮮人的時候,建議採用以下的步驟,先做分析之後再以漸進的方式去拆解故事,會很有幫助的。

步驟一、先定義問題

步驟二、質疑要如何做驗證測試

步驟三、由架構面來做審視(上下文)

步驟四、定義完成(含追加佈署的文件)

.

首先定義問題

使用者故事最棒的地方,就是容易讓大家一起來討論,試著弄清楚這麼做是不是可以解決真正的問題? (千萬別因為覺得麻煩,就省略了這個步驟,我在很多地方都看過它的驚人效果,尤其是對非功能性的需求,在執疑之後;找一個範例走它一遍,相信我,這個發現會很有價值的)定義一下問題所在。定義問題可以讓大家在基本上有一致的認知,可以做為後續討論的基礎。

.

問一下如何測試

習慣上;我會運用倒過來的方式,先問作完了以後要如何驗證呢? 條件是甚麼? 然後就依據這些測試的條件來進行拆解這個使用者故事。這個動作也稱為最初的「定義完成」 DOD: definition of done(但它實際上充滿了未知與期望,與這真正可工作的軟體的定義還有一段距離)。

.

接著你要由架構面來做審視

如果事先開過 workshop之類的會議,已經產出有「使用者故事地圖」的話;則由使用者故事地圖做審視上下文之間的關係,是一個不錯的方式。這麼作的一個重要目的是,倒過來看使用者故事是否需要修正(透過工程師來描述故事,講給客戶或團隊的其他成員聽)。我習慣上會說: 「大家聽我描述一下,看看我有沒有說錯…」,這種做法可以確保大家都上車了,不會有人掉隊。

使用者故事拆解的動作通常結束在我們拆解出來的任務(task)都已經夠小了(一般由3到13個小時,謂之為剛剛好的大小) 就可以停止了。反之;就必須繼續向下去拆解它。團隊一起作拆解的工作,是一件耗時,但卻具有相意義的工作。因為在會議中會有人嘗試努力的來解題,而對問題不了解的人則會從中吸取到相當的經驗,一般來說是值得的。

拆解任務的最後一個步驟 – 定義何謂完成

Scrum對定義何謂完成,指的是已經可以交付給客戶的功能。你可能會質疑都還沒做使用者的驗收測試(也就是 UAT),怎麼能說它是可交付的功能呢? Scrum的解釋是我們的目標是 Ready to ship,因此常常稱此為「潛在可將交付的軟體」。

一般DOD所指的是:

  • 這個功能的程式已開發完成。

  • 已經可以作自動化測試。

  • 相關的文件已經更新

  •  或是可以進入打包作佈署的動作了。

.

會不會沒完沒了

這樣的考量,常常會讓你一再追加幾個可以列入正常工作的任務(task),例如設計、撰寫自動化測試的程式或是追加應該交付的可支援佈署的文件。不用擔心這樣子改來改去,會沒完沒了,如果你有這樣子的感覺,就先去做做看,回頭再來進行檢討審視的動作,總之;試著找出團隊可以工作步調就對了! 控制會議的時間,以時間為限制,有足夠開工的Tasks就可以趕快去做了,大可用事後檢討的方式來做好檢核點,沒有必要開太長的會議,它是一種最常見的浪費,能避免最好。

廣告

Written by ruddyllee

2015 年 08 月 23 日 於 09:51:46

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s

%d 位部落客按了讚: