今天早上坐車，偶遇到一個兄弟公司的開發人員。聊到了他們的日常開發模式。頗有感觸，特此記錄下來供諸位參考

注：所有對話均為真實內容，部分敏感信息略過

甲：最近還好吧？這么遲才上班的
乙：還好，今天算早的了。要趕去參加今天的standup meeting。

甲：Standup meeting ？ 你們在用敏捷管理啦？
乙：是啊。推行幾個月了。

甲：為什么突然推行敏捷管理啊？印象中你們是很嚴格的RUP流程啊
乙：唉，你不知道。原來那個項目，做了2年，上頭投資了2億美金，光是開發就有80號人在做。結果2年來都沒有什么明顯的成果。上面決定把這個項目交給其他公司來做。

甲：為什么會這樣啊？
乙：因為搞產品設計的人，一開始就把產品想象和設計得非常完美。于是投入了大量的人力，物力，時間來開發。但是這個產品實在太復雜了，中間反復改了很多次，等他們開發出來后人家客戶早就不要了。根本賺不到錢，但又不能扔掉所以只能外包給第三方公司維護。

甲：哦，這樣啊。是啊。電信行業的變化實在太快了，傳統的方法有點跟不上。尤其是你們這種很注重過程、文檔的研發部門。
乙：因為這樣，原來這個項目組解散，所有人要么轉到其他項目組，要么走。最近走了很多人！

甲：那你呢？
乙：我現在轉到另外的項目組，這個項目組采用的是敏捷開發。和原來完全不一樣

甲：那你們都采用了哪些敏捷實踐？
乙：迭代式開發，站立式會議，結對測試(自己發明的)，扁平式的組織結構

甲：你們的Scrum master是自己培養的還是空降的？
乙：沒有Scrum master，是大家按照對敏捷的理解來進行的。

甲：你對敏捷的感覺如何？
乙：怎么說呢....有好有壞。好處就是靈活很多，省去很多繁冗的流程。壞處就是很容易失控。

甲：此話怎講？？
乙：就拿我們組來說，我們組的規模是10個人，每個人都是“全功能角色”(：這是Scrum里面提倡的全功能團隊的一種方式)。

甲：然后呢？這樣不好嗎？
乙：不！因為每個人的能力不同，有新同事能力很一般，根本無法承擔“全功能角色”的要求。

甲：那不是還有“結對編程”嗎？
乙：這樣也有問題。兩個水平相差很遠的開發人員一起結對。高水平的很忙，水平一般的無事可做。

甲：嗯，結對編程的一個前提條件是水平相當
乙：是啊。要不就變成帶新人了。而且如果兩個人對需求的了解不同的話，那就更麻煩了。

甲：怎么會出現這種情況，你們在迭代開始階段和每天的站立式會議中沒有統一好認識嗎？
乙：因為上面說是“敏捷”，所以很多時候我們在迭代開始階段只有一個PPT，描述一個簡單的原型就開始動工了

甲：汗~~~，敏捷提倡面對面的交流勝過文檔。但也提到要合理的文檔。你們這樣做我覺得曲解了敏捷了
乙：是啊！一個PPT叫人怎么干活啊，所以我們劃分任務的時候都是按照“縱向”的功能模塊劃分，生怕“橫向”劃分后各種接口定義溝通太麻煩了。

甲：嗯....可是這樣看起來，我完全看不到敏捷的任何好處啊
乙：嗯。實際上，我更喜歡RUP，雖然麻煩但很清楚

甲：那你們連文檔都沒有，測試的時候怎么保證：
乙：我們有結對測試

甲：結對測試？有這個嗎？
乙：是我們自創的。因為我們的組是5個開發人員對1個測試人員，所以測試人員經常應付不過來。所以我們讓測試在工作時拉上開發，一起過流程。

甲：那你們有持續集成嗎？
乙：沒有。我前面說了嘛，我們都是按模塊劃分的，都是每個模塊自己做內測。然后進行集成測試。

甲：那不是很容易在集成測試出問題？
乙：是啊，經常需要反復

甲：你們一個迭代通常要多久？
乙：大概一個月吧

甲：我感覺我們國內對“敏捷”的理解有點流于紙面。都是重形式輕本質，甚至有點糾枉過正。
乙：是的。尤其是文檔這塊，很不習慣！對后進來的新人要求很高，因為沒有文檔，所以只能看代碼，很郁悶

甲：那不懂就問啊，難不成從頭看到尾，你們的業務那么復雜
乙：大家都忙啊，很多時候新人問問題大家都不怎么理睬

甲：我實在看不到任何敏捷的優勢，從你們這里。
乙：就說嘛，我還是喜歡RUP。現在組里的氣氛有點和以前不同了，以前很活躍的，現在有點沉悶

聊到這里時已經到了公司。可是我的思維沒有停下來，腦海里一直在思考他說的問題：

作為一個嚴格的研發中心(拿過不少總部的大獎)，為何于出現這種情況？我印象中3年前我在那個辦公室時，很羨慕他們那群技術大拿天天開技術大會，那個項目是一個非常大的項目，而且具有很大的后續潛力。可是現在被同行打得找不到北，據說現在每年只能掙幾十萬！這個數連繳每個月的水電開支都不夠。

為什么為什么？？？如果是傳統的RUP流程和大公司那種對產品無限制的完美要求，把這個項目拖垮的話，那么為什么在實行了敏捷開發和管理后，還有人愿意回到原來的RUP流程中去呢？

我的腦海里冒出無數個疑問：

 A. 敏捷是不是站立式會議，是不是把項目切分成幾個小階段就是迭代了？
 
 B. 敏捷的團隊規模要多大？10個人還是4，5個人？

 C. 敏捷團隊中的人員如何配置？是不是要水平相當，經驗相當？

 D 當團隊中出現短板時，敏捷的結對編程會不會變成致命的缺陷？

 E 敏捷團隊中全功能團隊和去角色化(尤其是沒有PM這個角色)，會不會讓項目失控？

 F. 敏捷不是完全拋棄文檔，但是文檔要去到什么級別？ 和傳統的文檔又有什么區別？

 G. 敏捷開發扁平化的結構，如何保證不會出現扯皮和糾纏不休？

 H. 站立式會議如果避免淪為流水賬匯報，如果讓大家清楚得知道你在干什么，遇到什么問題？

 I. 敏捷開發究竟適合哪些業務場景？項目or產品？(同行傾向于項目，說是產品經常要改，可是敏捷的宣言不就是擁抱變化嗎)

 J. 敏捷開發中，成員分工要如何進行？橫向劃分或者縱向劃分？

 K. 敏捷開發和管理中，如何讓后進來的新人盡快熟悉產品和架構？