協助工程師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)的基礎上推出的一種描述系統結構和模塊內部處理功能的工具(技術)。