案例討論：傳統 vs 敏捷

一個 FAQ：傳統和敏捷有何區別？有根本的區別。讓我們先來看一個案例。

dearchloe（國內一家交通行業 IT 公司的專案經理）at itpub:

http://space.itpub.net/index.php?uid-13353915-action-viewspace-itemid-610417-php-1

首先說一下這個專案成員。不算其他邊邊角角的人員，專案組主要有4個人。這4個人裡，有三個都是很強勢的人。最不強勢的人就是專案經理了。為什麼專案經理會這樣呢？因為他對業務和技術都不懂，而且他自己還很清楚這點，所以他平時就什麼都不敢說也不敢管（不過我覺得他也缺乏帶專案的經驗）。並且，我們3個人都不是全職做這個專案。這個專案涉及的技術我們都沒有人用過。

接下來說一下工作安排。由於我是專案開始後加入，所以需求分析我沒有參加。然後詳細設計，大家討論，然後每個人分一塊來寫，專案經理收齊後合併成一份文件，交給領導審批。開發時，再打亂分下來一人開發一個模組。由於，我們部門今年內增加了很多規章制度，要求文件要齊全，格式要標準，並且要經過技術委員會審批。因此當這一切做完，已經到年中了。

然後架構師開始搭開發框架（一邊摸索一邊搭）。我們開始開發。開發時碰到一些問題：1）對使用的新技術我們都不熟；2）詳細設計文件不夠詳細（文件其實就是為了應付領導），需要不斷地詢問；3）專案經理不統一專案開發標準和管理專案事項。4）每個人都有其他事情不斷地打斷開發。

作者分享的這個案例非常好，在國內還是非常典型的。感謝她的實話實說，提供了這麼好的一個案例，下面我也實話實說。

從軟體工程專業的角度看，這個專案失敗的概率非常高，可謂又一個 death march 專案，而且正好可以作為敏捷過程的反面教材。在她的介紹中，我看到的全都是些不利因素、障礙或者風險，我沒看到能使它成功（高質按時交付）的有利因素。

我覺得這家公司的問題是比較嚴重的（希望不是積重難返），這看上去更像是一個人浮於事的官僚機構，而不是一個有競爭力、效率至上的當代軟體研發機構，當然更不是學習型組織了。所有人（包括領導、專案經理、“強勢”的技術人員在內）都不知道當代軟體工程已經取得了哪些進展，歷史上有哪些經驗教訓，他們還在用農耕時代的思維和方法開發當代軟體、管理當代專案。只緣身在此山中吧。

造成這些現象的原因可能有很多，我覺得最大的問題首先在於領導的管理能力和意識沒有與時俱進，其次是落後的公司/組織管理制度，以及存在嚴重缺陷的開發過程規範。

您對這個專案有何看法和評價，是否在平時工作中也遇到過類似的情況，敏捷方法又該如何做呢？歡迎參加討論！

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13633641/viewspace-610597/，如需轉載，請註明出處，否則將追究法律責任。