Ruddy Lee 分享空間

Emergent Design 演化設計

手頭上的工程師效能不彰,如何是好?

leave a comment »

* 如果可以加人的話,在你感覺到專案有壞味道出現,也就是負責開發的工程師程度不佳時該如何是好?最單純的做法是,配一個資深對這些技術熟悉的工程師去協助開發,這應該是較簡單的解決方案了。

還記得下面的Stacey Matrix 嗎? 加入資深做過這件工作的工程師,能夠有效降低技術的危險性,成功的將Technology縱軸向軸心拉攏,使的專案趨向簡單易成功的區塊。但,萬一專案已經進入尾巴也正在趕工亟需要收斂的時期時,此時加人反而會增加開發的時間,又該如何是好?  這時候,只能做的就是守住整合測試再加上針對每個模組進行單元測試及code review,遇到了!累人啊.

image_thumb

Stacey Matrix

越早發現問題可以當下就立即加以處理最好,一旦錯過黃金處裡期之後,大部分專案就只能依照專案的特性,死守測試案例囉! 然後眼巴巴的期待他能有達到水平的驗收標準(當然,先做風險評估! George Fairbanks 所寫的 恰如其分的软件架构 ,請特別留意,輕易的妥協與降低驗收標準只會延長對需求者的折磨,這是下下策)。

※    沒有放諸四海皆準的答案,但若能從專案的技術面來思考這個問題會更有價值,因此把問題從新的描述如下:

我把困難度先放大10倍,也就是當專案開發遇到:

  1. 專案開發的技術較艱深(例如Embed system開發作業)。
  2. 開發模組多,時間又長一些(例如 1到 2年)。
  3. 開發工程師多到數百人,而大部分為二到三年經驗的工程師,而離職率又十分頻繁時(每個月都有舊人離職,新人報到)。
  4.  技術難以銜接,交接時間過長,開發進度難以掌控。

身為管理人員在遇到這樣的情境時,當如何是好?

從降底每個程式的複雜性做起,針對問題運用架構來解決它

有時乍看下,工程師效能不彰與較大專案開發團隊不易管理好像都是管理上的問題,也好像與技能不太相干。但是我們如果由技術層面來解題(替換老是想用管理層面解題的思維),換一個思考的角度反而可以解決許多的問題。基本上我覺得,程式開發若是能變簡單了,維護也變容易了,用架構將上面的問題難度下降後再交給管理方法就更容易克服了。因此降底程式撰寫的複雜性或許才是治本之道。

Ripple Theory 漣漪理論

一、較不靈光的工程師適合處理較簡單的問題,較成熟的工程師適合處理較複雜的模組。

這就有如漣漪(Ripple)一般,在中間的部分較深有如專案開發技術較困難的部分,這部分宜由較有經驗的工程師負責。而逐漸向外擴張之後,波紋變淺時就好比較小較簡單的程式模組開發一般,適合經驗較不足的工程師處裡。

ripple

二、 核心部分假設由工作流程引擎來負責(虛擬引擎的概念稍後再談,也就是說我們可以跟開發 GAME的程式一樣,先假設有一個適合開發平台使用的工作引擎存在,老實說 WF4.5 又快又好用),其餘外圍的部分就都是所謂的工作模組(關卡),真正執行流程是交由工作流程引擎依照工作流程來進行。以一種模組化的開發模式來進行程式開發,程式員只負責開發模組,而模組則有小有大,這將大大的降低開發的複雜度,使得維護變得容易,對工程師的經驗素質要求也就跟著下降了許多,此時較不靈光的工程師適合處理較簡單的模組,較成熟的工程師適合處理較複雜的模組。如此也就減少了工程師頻繁離職的負面影響。

因為它具有Ripple的味道,所以我把它取名為漣漪效應(說來話長,當年在寫完第一本工作流程引擎的書之後,就深深被模組化能夠相當程度的降低程式coding的門檻所吸引,但敏捷度不佳…沒想到今天它又復活了!)。

Agile Model Driven Development (AMDD) 敏捷模型驅動開發法

我想先說明一下,這裡討論到的AMDD開發方法,並不是我要開始大勢鼓吹這種開發法(純粹是為了解題,但誰又能說它不可行呢?!),就好比接下來要談到的核心部分的工作流程引擎一般,它也可能是虛擬的,我們純脆只是用這種模組化的方式來解題。我只是想假借這種模組式的程式架構方式,拿它的架構模式來解題,適度的降低程式開發的困難度,達到解題的效果。千萬要記得Brooks 大師所說的話,這世界是沒有銀子彈的。

模組式的開發方式本來就具有明確化並可以相當程度的降低開發複雜性問題的能力,但模型驅動開發MDD是一種一開始花時間把問題想清楚了的傳統開發方式(先畫流程再寫程式的專案開發方式),是一種一旦遇到需求有較大的變化時一切便要重來的開發方式。這種開發方式對運用過工作流程引擎來撰寫程式的人都很熟悉,它能把複雜的問題適度的抽象化了。

AMDD 不錯用的幾個理由

1. “project planning needs”

  • 正好補上了Scrum在設計上對前置時間未能提前做設計的缺陷。
  • 讓衍生式設計有一個起始基礎。

2. 提前看到 Technical risk. 

花一點時間建置流程及模組,可以適度的看到一些技術上的風險。

3. 對需求抽象化的巨觀審視

運用模組化的技巧,讓抽象化的思維適度的降低解題的複雜度。

4. 提升問題的品質 

模組化可以讓問題更加明確。

5. 提升使用者與開發團隊對產品有相同的了解

簡單的工作流程可以作為使用者與開發團隊之間良好的溝通依據。

我想在這裡先打住,接著我想把"衍生式設計“與"漣漪效應“之間的關係說明一下,再加上 Mary Shaw 的抽象解題法,應該對大家比較有幫助 … 陽光露臉了: 騎車,待續!"

Written by ruddyllee

2014 年 01 月 11 日 於 09:13:45

張貼於未分類

Tagged with , ,

發表迴響

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

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 位部落客按了讚: