協助工程師Breakdown Task 的方法

.

ipo breakdown

IPO breakdown法: 將工作描述成輸入-處理-輸出三個區塊

.

掌握了流程,就掌握了時間。將作業流程劃分的越細,工作內容就越明確,思路就更清晰。

-倍速心得

.

當你發現下午的辦公室特別吵雜時,原來是團隊成員在透過一上午的程式開發後有了很多疑問需要釐清的,因此在午餐之後便引發了討論潮,這種現象是好事,也能增加團隊協作,但一旦頻率偏高的時候就變成是一種浪費了(辦公室過分吵雜是一種浪費),你會疑惑為什麼有這麼多問題沒有在 Refinement 或 Planning meeting 時被提出來呢? 答案是:「因為有很多細節通常需要做了才會發現。」敏捷不像傳統開發需要有冗長的系統分析階段來弄清楚細節,因此就變成做到的時候在來解決的方式 ,但其實當需求明確到不會在變化時,就是可以開工的時候,仔細的分析是不能少的,上面這個方法是我被委派去帶領加速團隊開發速度時所常運用的工具。

 

因為描述需求的使用者故事對工程師Breakdown成Task的協助太少了,使用者故事擁有足夠的抽象度來涵蓋客戶的需求,向上沒問題(對確認需求而言)。也運用問答的方式來協助工程師了解要開發的功能。但在將故事 Breakdown成為任務(Task)的過程就沒有太多幫助了(向下,細節分析的部分)。以下是一個運用結構化思維的古老方法,它不但對開發工作有幫助,對一般追求效率的人士也很有用(註1)。

.

二倍速的開發速度 – IPO Breakdown

IPO是一種結構化的分析方法,它的理念是來自IBM系統360的功能描述文件(IPO: Input-Process-Output,在加入階層式的功能說明,就叫做 HIPO了,整個360的文件都是這麼寫的),IPO的優點是運用把輸出入分離,用很簡單的圖表描述了某個特定模塊內部的處理過程和輸入/輸出關係(即便沒有實做任何文件,這種IPO的思考方式也具有弄清楚程式功能結構,降低事後溝通的功能)。如上圖,首先將功能區分成三個區塊來考慮,把process 的區塊看成是黑箱,先把輸出入弄清楚了,再來考慮怎麼做細節處理,這是典型的結構化思考模式(將資料與流程分開考慮),步驟是這樣的:

.

資料】的部分

從介面開始,由定義輸入端是什麼資料格式開始,先從會拿到什麼樣的資料格式開始考量,再接著思考要轉成什麼樣的格式做輸出,弄清楚呼叫來源(上游)是誰,輸出的承接者是誰,把IO先搞定。

邏輯】的部分

考慮完I/O的邊界之後(分開來的介面部分),就比較容易去界定程式模組的範圍,也就是預估出程式應該具有那些功能模組,如果還是太大,應該在區分成那些更小的功能區塊呢,大小如何?

—-

程式結構化的基礎,是讓任何程式邏輯僅有一個輸入與一個輸出,這時候程式的邏輯「結構」便可以簡化成:循序(sequence)、選擇(if-then-else)與重複(do-while)。當程式太過複雜時就用階層的方式再呼叫下一層模組的方式來降低複雜性(這便是著名的 HIPO,也就是階層式的IPO了)

.

hipo-chart

範例1. function diagram + IPO chart

—–

接著需要考慮動態的部分,要考慮進來的資料速度嗎?需要Queue嗎? 有同步處理的要求嗎? 該如何處理額外的錯誤(exception)呢?等等細節考量。

.

服務】的部分

考量我是不是需要呼叫到外部的服務,萬一它出現錯誤時怎麼處理呢?如果它沒有回覆時,又該如何處理呢?

.

填寫完這份資料表時就等於思考好如何寫這個功能的框架了,接著便是實做它了(當然不能忽略簡單的原則,別忘了總是可以在簡單一點)。一般在處理較單純的功能時,工程師會隨意的畫個草圖就開始開發工作了,但一旦遇到較複雜的功能時,就會發覺他們認真的做起分析文件的作業,這時候二倍的效能便誕生了。為什麼?

 

因為,減少了頻繁的溝通,來來回回的詢問變少了,速度就變快了,由於事先運用了結構化分析的動作,有不清楚的問題已經在填表的時候問完了,減少了頻繁的溝通這才是快起來的主要原因。我稱它為「IPO Breakdown法」。

WIP.png

運用WIP(半成品)的理念來消除瓶頸

.

打破學習瓶頸: 以Task為單位作回饋,快速學習

Scrum 的回顧會議已經成為五大會議中最重要的會議了,原因是它提供了團隊共同學習的效果,價值非凡。我們可以從會議中檢討出好的行為(繼續保持),不好的行為,拿來做為改善的依據。這是團隊學習持續壯大的最好的時機。但對於個人而言,當做完一個任務的時候,測試人員的回饋,正是最適合檢討的時機,也是個人學習的最好時機點。當你希望一個開發團隊在同一個專案之下越跑越快的時候,最好的做法便是每天都作一次回顧,讓成員快速的講一下自己今天做了什麼,學到了什麼? 下來要怎麼作,把細節說出來,學到了下回就不會在犯了,有成長自然越作越快了,團隊也自然越來越堅強了。(這不正是code review嗎? 是的;是加了驗證的code review)

 

打破起步慢的瓶頸: 讓工程師以完成較大的工作進行規劃,而不是每天作規劃

目的是工程師不用每天都重新規劃工作,而是持續的投入工作,這會讓每天的起步工作都快上許多。讓工程師養成還沒來到辦公場所就已經清楚自己準備從哪裡開始做起了。這會養成一種持續的思維方式,也能避免受到不經意的誘惑而偏移了目標,跑去做其他的事。

 

.

結論

如何增加開發速度呢?若以精實的原則來考量,就是找到「瓶頸」的地方然後消除造成浪費的障礙(瓶頸:就是流量障礙,它讓流量值減緩,造成效能下降。IPO Breakdown是用來協助開發人員在開始工作前先弄清楚一些規劃上的細節,以減少開始工作時的頻繁溝通而產生浪費的方法,不是作文件也不是要求作文件,雖然它是製作敏捷文件的好方法,但不要忘了我們的初衷,增加開發速度。

如果你的團隊經常在每日的站立會議裡追加工作單,在 Sprint 中甚至追加的工作量超越了原先的計劃中的工作量,那表示你的 Breakdown 出了問題,明顯的你需要多花一點時間作分析工作。但最簡單的作法是在進行Breakdown作業時,先把輸出入寫下來,好好的弄清楚。

.

捨棄不作來加快工作的起步速度。

-最快的加速法

.

 

註:

所謂的結構化分析與設計,基本上是將資料與流程分開來考慮,主要可分成三大部分:資料塑模、流程塑模與使用者介面塑模。

  • 資料塑模主要是針對資訊系統的知識子系統;
  • 流程塑模主要是針對問題處理子系統;
  • 使用者介面塑模主要是針對資訊系統的使用者介面子系統。

這三種塑模活動並沒有一定的進行順序,也就是說任何一種塑模活動均可視需要而先進行或以其他塑模活動交互進行。

 

 

註1. 《從此不加班的 IPO工作術》 by: 清水久三子

註2. HIPO

HIPO(hierarchy plus input-process-output)

是IBM公司於70年代中期在層次結構圖(structure chart)的基礎上推出的一種描述系統結構和模塊內部處理功能的工具(技術)。

 

如何做任務分解?

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

步驟一、先定義問題

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

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

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

.

首先定義問題

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

.

問一下如何測試

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

.

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

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

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

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

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

一般DOD所指的是:

  • 這個功能的程式已開發完成。
  • 已經可以作自動化測試。
  • 相關的文件已經更新
  •  或是可以進入打包作佈署的動作了。

.

會不會沒完沒了

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