軟件開發(fā)與交通阻塞的相似之處 -管理資料

管理資料 時間:2019-01-01 我要投稿
【clearvueentertainment.com - 管理資料】

    Ken Delong解釋了他認為軟件開發(fā)“超級困難”的原因:

每個人都知道編寫軟件很難,但是我想探討一下為什么軟件開發(fā)這么難,

軟件開發(fā)與交通阻塞的相似之處

。

    軟件開發(fā)受本身四個特性之困,而這些特性也將其推到了“復(fù)雜的自適應(yīng)系統(tǒng)”之境地,并且更將其逼入混亂之困局(至少足夠接近)。這些特性是:

非線性

反饋

時間延遲

變化

    以上并不是什么新鮮的發(fā)現(xiàn),而且我們很多人都已經(jīng)對其習以為常。也許有些人雖然聽說過,但卻不能理解背后的真正含義。這也使得Ken的博客文章有了用武之地:

在高峰期時,公路上車流密集,也許大家的行駛速度都還不慢。突然,某個人想看看車外的風景,將時速降至30英里,而且只維持了幾秒鐘。這會帶來什么后果?交通大堵塞。曾經(jīng)經(jīng)歷過堵得一輛接一輛的路況吧,卻沒想到突然可以時速70英里前進?之前的狀況,是因為出現(xiàn)了變化——有人想游車河,非線性因素摻雜在一起,造成堵車。很多類似復(fù)雜系統(tǒng)都是可以自我維系的,交通堵塞正是其中一例。最后還是暢通了,但是其恢復(fù)速度卻遠低于任何人的直覺。

    一個人減速——這并非偶然事件——卻造成全線大塞車!問題的關(guān)鍵在哪里?軟件既難而又危險,最微小的事情也有可能導(dǎo)致全盤皆輸。難道就這樣束手就擒么?

要想在流量有限的高速公路上避免嚴重塞車,就得讓大家都把尾燈打開,這樣可以讓整個交通系統(tǒng)的利用率保持在安全的水平,一些正常的變化也就不會被無限放大、造成問題。我們在處理生產(chǎn)系統(tǒng)服務(wù)器的CPU占用率問題時,采用了同樣的方式。我們會讓CPU的占用率不超過30%,這樣就可以防止峰值流量對服務(wù)器造成過大沖擊。

    因此,系統(tǒng)中必須提供反饋機制,使得它可以應(yīng)對變化,不至于因此而崩潰:

在敏捷中,可以調(diào)整一個sprint接受的故事點數(shù),以使sprint中的所有任務(wù)都能在sprint之內(nèi)抵達“完成”狀態(tài)。這就是“尾燈效應(yīng)”。

    Jurgen Appelo在《敏捷項目時間管理10原則》一文中提出的十項原則,可以視作敏捷軟件開發(fā)的調(diào)整和“尾燈”:

    定義“完成”條件

    使用時間盒管理工作

    不要為任務(wù)估算添加松懈時間

    推遲決策

    減少周期時間

    讓處理管道短小而狹窄

    保持紀律

    減少任務(wù)切換

    防止長時間連續(xù)加班

    分離“嚴重程度”和“緊急程度”

    Jurgen詳細闡述了這十條原則,并提供了各自深入閱讀的參考資料。軟件開發(fā)之難,很大程度上因為其過程類似于復(fù)雜的自適應(yīng)系統(tǒng)。敏捷,如果可以正確實施,將會提供穩(wěn)定的反饋。

    查看英文原文:Software Developer:A Traffic Jam Waiting To Happen


    在英文站文后的評論中,讀者Karl Scotland指出:利用“看版”系統(tǒng)限制在制品,可以“讓整個系統(tǒng)的利用率保持在安全的水平,一些正常的變化也就不會被無限放大、造成問題,

管理資料

軟件開發(fā)與交通阻塞的相似之處》(http://clearvueentertainment.com)。”

    讀者Jim Leonardo在名為“避免擁塞,保持距離”的評論中說到:

若想使用擁塞作為比喻,我建議先定義其真正含義。擁塞等同于瓶頸。團隊構(gòu)成上的問題,可能會造成有些人在忙著解決難題的時候,其他人卻處于空閑狀態(tài)。如果有這些情況發(fā)生,你應(yīng)該考慮一下因素:

    1) 團隊中人員的職責是不是劃分得太明確了?如果有瓶頸產(chǎn)生,是不是因為在跨職能方面做得不夠?趕緊多做點培訓,多進行知識分享吧。

    2) 有多少任務(wù)需要其他任務(wù)作為前置條件?如果因為前置任務(wù)沒有完成,導(dǎo)致有些人的工作限于停滯,是否有其他的任務(wù)可供這些人上手開始工作?對于團隊和項目來說,功能特性切分成任務(wù)的方式合理么?是不是可以用另外的方式進行劃分、組織開發(fā)?

    3) 簡單之極……為任務(wù)的開發(fā)準備足夠的時間了么?現(xiàn)實一點,如果總是發(fā)現(xiàn)瓶頸(擁塞),也許是因為過于低估了某些類型的任務(wù)的完成時間,或者在做規(guī)劃時沒有考慮到不同的開發(fā)速度(要注意,“速度慢”的開發(fā)者之所以慢,可能是因為他們對代碼質(zhì)量的要求比較高,所以要全面考慮問題)

    最后一點,也是我最想在infoq上反復(fù)強調(diào)的……

    4) 團隊的工作時間是不是太長了?有人陷入停滯,是不是因為他們覺得自己應(yīng)該每周工作70個小時?相反地,總是成為瓶頸的程序員,是不是也是把所有時間都投入工作的那位?倘若果真如此,這個人就像一個正在形成的火藥桶。如果它現(xiàn)在還沒有爆發(fā),將來一定會(強制對他的代碼進行復(fù)查絕對不可。。。

    作者Amr Elssamadisy引用了Flemming Funch的博客,對于complex和complicated之間的不同進行了分析:

我們每天都會用“complicated”和“complex”,不相區(qū)分。要討論復(fù)雜性(complexity)就變得困難了,比如說探討自然界中的復(fù)雜性。

    可以說我們需要復(fù)雜性的科學定義,可是科學卻給出了至少32種不同的詮釋,每種都不一樣。要是我們能擺脫迷惑的困擾,就可以發(fā)現(xiàn)下面這種可行的說法:

    構(gòu)成上的復(fù)雜性(complicated),是指某項事物包含了很多錯綜關(guān)聯(lián)在一起的組成部分,很難搞清楚各個部分之間的關(guān)系。即使能搞清楚,也不能保證這些部分是以合理的方式組合在一起的。

    系統(tǒng)上的復(fù)雜性(complex),是指某項事物作為一個系統(tǒng)出現(xiàn),它所展示的系統(tǒng)屬性并不明顯。這與一些部分的簡單疊加之和有所不同,更難以理解。構(gòu)成的部分不一定很多,但是組合在一起之后的結(jié)果卻難以搞得很明白,在某些方面以一個整體的方式呈現(xiàn)。

    一架空客380具有構(gòu)成上的復(fù)雜性(complicated)。一條水母具有系統(tǒng)上的復(fù)雜性(complex)。巴黎地鐵網(wǎng)絡(luò)具備構(gòu)成上的復(fù)雜性(complicated),人們使用它的方式具有系統(tǒng)上的復(fù)雜性(complex)。你的骨骼框架具備構(gòu)成上的復(fù)雜性(complicated),作為人的你具有系統(tǒng)上的復(fù)雜性(complex)。一棟建筑物是具有構(gòu)成上的復(fù)雜性(complicated),而一個城市具有系統(tǒng)上的復(fù)雜性(complex)。

    來自:http://www.infoq.com/cn/news/2008/08/sd-traffic-jam

最新文章
推薦文章