Ruddy Lee 分享空間

Emergent Design 演化設計

精實原則: 盡快交付 Deliver as Fast as Possible

leave a comment »

在製造業中交付產品越快的公司必定越受客戶青睞,軟體業也是如此。但在製造業裡對手很快就能掌握到你快速生產的秘訣, 所有的廠商都會開始模仿,一下子大家就都會了,優勢很快就又沒有了。而軟體業就很難做到這一點。

為什麼要快速交付?

客戶喜歡快速交付。因為快速可讓他擁有更多的準備時間,也就是延遲決策的機會(你一定想到了,盡快交付原則正是對盡量延遲決策原則的補充。當你能夠越快交付,則相對的可以得到延遲決策的時間就越長)。對於其他一些客戶而言,快速交付意味著更快的滿意。對軟體業而言,他能帶來業務上更高的靈活性,也就容易得到客戶的信賴,當然也就間接獲得客戶更高的配合度。老闆、客戶都喜歡快速交付,但工程師要如何處理呢? 如果你 一向單打獨鬥的話,為了做到快速交付,可能必須發上一番功夫來設定一套較完整的交付流程,這是可行的作法也是很好的練習,但太辛苦了! 而且這麼做只是治標的做法,對工程師而言是好的練習,但很辛苦(維護就更辛苦了),如果能由開發方法的角度來看這個問題,實行治本的理論遠比治標要划得來多了。以下便是精實軟體開發的做法:  採用看板方法來實踐拉動系統

拉動系統 Pull System

被動交付工作: 一種運用排定日期的工作方式,當時間到了就被"推動“去工作的工作方式。另外;自動交付的工作方式: 你也可以將需求規劃成一種事件,由事件來"拉動“你去工作。對採用微軟視窗的工作的人而言應該都十分熟悉這種事件的處理方式,讓事件去觸發相對應的行為方式稱為事件驅動模式,是一種即時性(JIT)的處理方式。系統可以省去一個一個輪流查看是否有工作要處理所耗掉的時間及CPU浪費的效能。在製造業裡由看板來作為啟動JIT即時生產的自動化機制 (這便是看板又被稱為Signal Board的原因,當有信號進來時就去拉動下一個工作的項目。而無須由工頭做決策,下達面令指揮工人該做甚麼。也就是說管理者不必吩咐工人該做些甚麼,工作本身就能起到引導作用)。

複雜的軟體開發工作也存在同樣的基本問題,專案經理PM所依靠的日常進度表,將很難去描述許多細微粒度的工作分配,拉動系統無疑的是最有效的安排。這就是讓團隊成員自己去做有效的時間安排方法。

※ 員工知道在上班時間如何有效的安排自己的時間表嗎?

複雜的軟體開發無法像製造業一般採用細粒度的排班表,但對知識工作者而言;在辦公時能夠採用自我引導應該是最為有效的方法,員工在自我管理的情境之下容易為自己的行為負責,也就能主動負責,專案的成功率自然有保障。運用看板實施拉動系統是最能做到這種直觀式管理的方法之一。看板上有大家的工作狀態,團隊工作的進度、效能及瓶頸能一目了然,這樣的透明度是最適合自我引導的狀態。

善用排隊理論 Queuing Theory  — 看板方法尋找瓶頸的基本技巧

缺人手! 你可能缺少分析人員或是找不到人手來幫忙測試…,當資源出現短缺的現象時,排隊的狀態便會很自然的發生了。 它是最浪費時間的東西了。看起來是單純的資源不足所造成的現象,但不容易改進(事實上它是我們在運用看板上發現問題跟解決問題的最佳機會)。排隊理論的出現實質上是有太多地方可以來進行改善的一種徵兆通知。舉例: 拿飲水機的例子來做說明。 排隊是按照每一個人到達的時間順序,而不是每一個人的口渴程度來作調整。所以當散步過來喝水的人排在剛跑完步的選手前面時,可以依需要水的程度大小來定義服務的效能,便可以定義它是低效能的,相反的則是高效能。這時候當我們以增加效能為考量時,就可以讓跑步的選手先排到前面來。簡單的區分可以讓服務滿足真正的需求,這就是看板想要作到的事: 暴露需求或者是瓶頸所在,然後修正它來達成真正的需求。

在開始講述排隊理論的運作方式前,有必要在作一下上下文的描述: 在排隊時,你總是希望能夠盡量縮短等待的時間。畢竟,加入排隊是為了達成某種目的。之所以讓你無法達到目的的唯一原因是,達到目的所要的資源受到限制(也就是資源不足),因此便形成排隊的現象,增加了時間的浪費。所以之資源的限制才是最主要的原因。但有時候也可能是設計者為了保護系統資源所做的限制設計(常見於雲端應用程式的設計)。

限制理論(Theory of Constraints,TOC)是由高德拉特所發展出來的一種全方面的管理哲學(尤其在生產理論上有著重大的影響),主張一個複雜的系統隱含著簡單化。即使在任何時間,一個複雜的系統可能是由成千上萬人和一系列設備所組成。但是只有非常少的變數或許只有一個,稱為限制,它會限制(或阻礙)此系統達到更高的目標。強調優化組織的最佳途徑是強調組織的吞吐量,因為它是獲利的關鍵。而增加吞吐量的方法便是找到阻礙工作進展的瓶頸並對它進行修正。這一點在網路的時代更是明顯,因此我們可以預見雲端將是這個時代企業的必然戰場所在。

(看板方法受到限制理論極大的影響,David J. Anderson 原先把自己的理論稱為"鼓-緩衝-繩" Drum-Buffer-Rope,一直到在微軟的專案試行這個理論的成功,並逐漸發展出自己的架構後,才改稱之為"看板方法“。)

是否值得投資購買新的開發工具

籃球賽的抄截快攻,是翻轉戰局最佳的方法。原因是;這一來一往的差距是 4分不是 2分。

開發人員可能會向你提出採購一種新的開發工具,因為他們認為可以加速開發的速度。而你會估算一下省下來的開發時間是否值得購買這個工具。這種經濟模式的決策,往往都容易忽略了無形的、大於成本效益的影響。所以較正確的作法是,採用風險管理的概念,將不購買新的開發工具所可能造成的延誤成本加到損益表內來評估,會合理的多。

(我曾經做過四家軟體研發部門的經理,深深知道投資在購買新開發工具的價值,絕對不是它表面上的金額大小,它對開發團隊的影響才是真正的價值所在。)

Written by ruddyllee

2014 年 10 月 05 日 於 14:45:52

張貼於未分類

發表迴響

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

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: