前幾天和乙個剛換工作的同事溝通，他告訴我他所在的新公司領導不喜歡敏捷開發模式，原因是他們領導覺得敏捷開發對工程師素質的要求太高了。我覺得這個想法很新穎，值得討論一下。
1 我常說，敏捷開發模式的基礎是**要敏捷，即如果工程師生產出來的**本身不夠「敏捷」，那也無所謂談何種開發模式了，從這個角度看，敏捷開發確實對工程師素質有很高的要求
2 對於素質高的工程師，哪個專案經理不喜歡呢？敏捷開發模式也好，傳統瀑布開發模式也罷，作為專案的管理者，總是希望專案的開發工程師素質越高越好，從這個角度看，高素質工程師總是受歡迎的，並不是敏捷開發模式特別偏愛
3 現實的專案中，在專案管理者看來，所謂的高素質工程師總是不夠的，或者說，素質不高的工程師總是佔大多數的，那既然敏捷開發對工程師素質又有那麼高的要求，因此，領導們對敏捷開發敬而遠之好像也有那麼點道理
4 一般而言，敏捷開發模式的推崇者宣稱敏捷有著更多的優點，表現出來就是更好的響應變化的需求、更快的開發進度和更高的質量等等，就我個人的體會，敏捷還有乙個很突出的優點就是如果某個專案注定要失敗，那麼敏捷可能可以更早的把這一不幸的結果暴露出來，這個優點有時候我甚至覺得這是敏捷最大的優點
5 敏捷號稱的那麼多優點，僅僅是因為參與敏捷開發的工程師素質高嗎？
6 來看乙個實際的例子：某個專案經過任務分解，一共有十個子模組需要開發，在傳統的開發模式下，專案經理把這些子模組往開發工程師處一扔，要求他們評估出工作量和制定研發計畫，開發工程師做完評估預估和制定完計畫後，接下來就開始進入實際開發階段了；開頭幾個子模組進展很順利，每個周的週報都很好寫，專案經理也很樂觀；開發到最後兩個子模組或者是所謂系統聯調階段時，開始出現各種狀況了，各種質量問題、各種發布計畫 delay，專案經理開始糾結了，專案失敗的苗頭開始顯現了。為何會出現這種情況？我是這樣認為的：從人情上而言，開發工程師在拿到10個子模組開發任務後，他會選擇那些比較熟悉、比較有把握的模組開始先做，而比較麻煩、不太熟悉的子模組會相對的放到最後做。而正是這樣的一種開發順序選擇，很容易導致上述例子中的狀況
7 在敏捷開發模式 scrum 中，上述狀況是可以得到避免的，因為開發模式把子模組開發順序的權力明確賦予了產品經理，而非研發人員，這樣一種職能的分配，可以有效的降低專案的風險
8 當然，如果某乙個子模組確實開發難度高，敏捷並不能幫程式設計師把開發難度降低，程式設計師在傳統模式下無法完成的某些演算法的開發，在敏捷模式下依然無法完成，但是，敏捷的好處是，它可以讓產品經理或者專案經理很快發現這個事實，再了解到該事實後，他可以暫停或者取消該專案，也可以再增加一些資源的投入，確保技術困難得到解決，這是敏捷乙個很大的優點之一
9 從上面的例子可以看到，所謂的傳統模式對工程師要求低的看法，其實是以傳統開發模式的專案失敗率上公升為代價的，即如果工程師能力不夠完成某專案，在傳統模式下，這個專案依然可以立項和推進，直到某一天這個專案走向失敗；而在敏捷開發模式下，這個專案可能很快就被公司給暫停或者取消，因為他們很早的就可以發現工程師素質不足以完成工作的事實，而這個事實，工程師自己很可能是知道或者疑慮的，但是工程師自己是很可能不會告訴產品經理或者專案經理的
10 我的看法是，在投入同等資源（人員、時間、其他部門配合等）的情況下，敏捷開發模式的效率更高，即產出的產品功能更多、質量更好；而在完成特定指標（功能點、質量水平等）的情況下，敏捷對資源的要求可能比傳統的方式更低
優秀工程師的素質
1.責任感 責任感是一種自覺主動履行分內分外一切有益事情的精神狀態。責任感作為心理學概念，屬於社會道德心理的範疇，是思想道德素質的重要內容。也是工程職業道德的基礎。2.人際交往能力 工程上的成功必定是團隊努力的結果。成功的工程師往往具有良好的人際交往能力。他們不僅需要和受教育程度高的工程師同行以及其...
測試工程師VS開發工程師 打敗開發工程師
測試空間旗下大頭針 出品 今天賀老師組織了一次內部培訓，目的是為了使我們帶領的兩位測試人員盡快的進入公司的專案組 參加部門會議的大多都是新員工，他們公司剛剛找了乙個專門開發 的程式設計師。首先賀老師給我們講解了dms的體系結構。公司產品結構挺有意思的，有終端機 支援gprs的sim卡，gis卡,gp...
Golang 開發工程師
golang 開發工程師 go語言是谷歌2009發布的第二款開源程式語言，go語言專門針對多處理器系統應用 程式的程式設計進行了優化，使用go編譯的程式可以媲美c或c 的速度，而且更加安全 支援並行程序。為什麼會出現 go語言 谷歌首席軟體工程師羅布派克 rob pike 說 我們之所以開 發go，...