敏捷的壞態度
雖然所有軟件開發的專業人士都會對這篇文章感興趣，但是經理、CIO以及軟件架構師會對它最感興趣。這個話題可能會引起許多爭議，但我寫這篇文章是為了讓你了解在敏捷運動中看起來正在日益增長的問題。
你為什么在這？敏捷不需要經理。
以前聽過這種說法嗎？ 想象一下，如果你聽到開發人員認為你這個職位根本就不應該存在，你會感到多么震驚，就好像是你特意為自己搞出經理這么個職位似的。這個話最常應用在項目經理第一次與將要和他一起工作的開發團隊碰面的時候。的確，最初的敏捷宣言絕對沒有提到項目管理，并且后來的敏捷理論家更進一步，建議調整項目經理的角色變成更多是教練或者支持的角色。
然而，這個觀點忽略了現實情況。
的確，小的、非集成的、從屬開發項目中可能不需要任何類型的管理，只要你擁有有資質、有經驗并且能干的團隊就好。然而，越是大規模的項目，越是高度集成的從屬項目，越是開發集中度低的項目越是需要一位項目經理去協調、溝通和把握這個整體目標。一個開發部分只占總預算百分之十的項目，可以允許由一位scrum專家來領導開發，但也要向項目經理匯報。
再者，開發團隊幾乎根本不知道或者根本不擅于管理預算。軟件開發需要的時間量讓開發團隊沒有時間顧及其它事情。這使得一些開發人員產生了小盲點，似乎他們開始認為：他們所做的一切就是這個項目，其他任何人都是多余的。
這里的壞態度是指認識不到其他角色和職業的價值，并且嚴格遵守哲學解釋，而意識不到現實需要靈活變通。如果走向極端，在它的陳述中通過把這種觀點延伸到所有條件下的一切管理的話，這種態度就幾乎能被理解為就是工會主義或者新共產主義。顯然，接受這樣包含一切的、大規模的企業文化削減以及組織結構扁平化的個人是極端分子。雖然他是對周圍環境發出的觀點，但是如果他恰恰是這樣一個人（一位領導）他的觀點能夠起作用并且會使開發團隊和管理部門之間的關系變得更糟那么就會使項目完成的目標變成管理部門與工人之間的階級斗爭。
是團隊運作這個項目，而非經理......我們將決定該完成什么。
這種觀點通常是不再需要管理角色這種觀念的產物。這種觀點是違反事實的：許多決定需要公司中的眾多元素一起合作，而不僅僅是開發團隊......這也包括軟件設計和架構。
在另外的例子中，有這種觀念的開發人員恰恰沒有意識到項目有其它方面。甚至更糟糕的是，在某些可察覺的故障發生之前，被一次不愉快經歷傷得很重的開發者會覺得需要控制這個項目。
無論如何，敏捷變成了這樣一種態度的前文和基礎，這種態度提出開發團隊之上的大多數（即使不是全部的）管理結構都沒有用，應該立即剔除掉。依據我的經驗，如果讓這種態度生根的話，那么通常會導致無休止的重組架構會議、應付預算超支、沒有真正結束日期以及因自己使命的幻想破滅而精神分裂的團隊。
在敏捷中不存在到期日或者時間表。
我們這些深入了解資本預算和公司財務的人會知道這是多么愚蠢。然而，如果你讀過Ken Schwaber寫的關于Scrum的書，就會看到那里面談到為了燃盡圖而拋棄甘特圖。事實上，燃盡圖是一個干凈利落的、經過深思熟慮的創新，但有些人卻認為這就意味著交付沒有時間表......即錢永遠花不完。
這對我來說是一次痛苦的經歷。 我見過一位能力很強且富有領袖魅力的領導人（我們都向他匯報）帶領的團隊，為了給客戶產出項目管理工作產品，而放棄了基本的時間目標。 任何時間界限都沒有了，這個團隊到處傾斜。 職業精神極大衰減，或者可以說是蕩然無存了。 那些想讓產品獲得成功的人喪失了動力和干勁。 客戶變得不知所措，為什么如此多的重點強加到各種技術架構之上，而特性和產品變更需求卻不知所蹤？ 燃盡圖讓他們更迷惑。 他們只想知道的是：這個產品什么時候才能完成？ 而這個團隊卻只回復說：我們沒有時間表。 我們會一直開發，直到我們做完為止。
當有人嘗試著設定現實目標時，他們會因反對敏捷而立即被打倒。 當這個團隊被告知他們的項目無可救藥地超過預算時，他們的雙眼充滿了困惑和不解。 他們正在做的事情、時間以及最終的花費之間的聯系已經消失在那些他們用白板記錄的抽象設計樣式中了。
現實是......不論是明確的或者模糊的，總是有一個到期日和交付時間表。如果這個開發項目的觀念是它永遠都不會完成，那么就沒有人會把錢投給它。更現實的是，我發現甘特圖在協調深度集成或者非敏捷團隊與敏捷團隊之間非開發方面還是非常有用的。
這種沒有時間表態度的產生，主要是因為敏捷技術提出了這樣的觀念：項目應該繼續添加新特性直至把錢花光。這是不切實際的，并且忽略了當開發團隊連預算內最低限度的功能都沒有完成時會發生什么，此時描述這樣的要求毫無益處。這種態度不好的方面是用（敏捷）這種新技術來追蹤團隊進程、問責并且把這種新技術扭曲成不對交付負有責任的原因。
敏捷編碼是自動文檔化的。它不需要需求、架構圖或者技術規范。
如果你是一位軟件架構師或者技術經理，這種態度通常會讓你眉頭緊鎖。這種輕微的、隱藏的攻擊是想質疑你的角色、經驗以及有人來協調那帶來百分之七十八公司收益的兩千八百萬行軟件程序的技術設計的必要性。
當然，提出這種想法的通常是出于無知。可能開發人員構建的兩千行web應用近期需要非常少的源碼外的再加工，但那是因為規模的關系。你知道，你的管理部門也知道，但是這種不好的敏捷態度取代了你的角色，卻不是為了像Scrum那樣領先于開發技術。大多數的軟件系統需要少數人來監督方向、協調技術愿景，而需要成百上千人來創造。
依據我自己的經驗，說來頗具諷刺意味，這種態度來自于那些想成為架構人員的開發者。 通過評論、與技術領導爭辯以及介紹他的敏捷技術知識，他感覺領導應該更加尊重他，應該給他那個他夢寐以求的職位。 然而，領導卻把他當作令人討厭的麻煩制造者。 此外，因為他缺少介紹敏捷概念的經驗，從而讓那些資深的技術領導一想起任何敏捷的事情就會不舒服。
敏捷快速地擁抱變化；所有變化。
我對這一態度的經歷來自于一位經理而非一位開發者。原來他把快速擁抱變化解讀成了各種各樣的變化......而不僅僅是原來敏捷締造者設想的業務需求。所以，基礎的、架構的變更成為了家常便飯，不同開源技術間的不斷改換被視作好事，即便這意味著把這個團隊帶離他們（熟悉）的技術，以及月復一月地推遲項目交付。組織結構方面的實驗以及把人們快速放入某個角色并又被快速地從這個角色中拿出也變成了快速擁抱變化。最終的結果就是混亂。
顯然，接受來自于客戶的變更很重要，但是如果對那些變更沒有系統的管理，那么你就是自找麻煩。你需要保存所有需求、變更的軌跡，以及他們對項目交付的影響，以便把這些信息傳遞給客戶。這對于做出有效的項目決策是必須的。如果你不那樣做，客戶會不切實際地認為，他們要求的東西都會包含到產品中我們都知道這會導致什么樣的情況。
所以，這里的壞態度是不加管理的接受變更。對所有事情都絕對自由只能導致虛幻的希望和無法達到的期望。變更是好的，但極端的變更只能是混亂。
敏捷使用的是通才；我們測我們自己的軟件。這里不需要測試組。
又是這樣，這種觀點在哲學解釋上是準確的，但我在這個問題上的經驗是，特別是大型的軟件開發項目，你需要第二雙眼睛來盯著開發人員干了什么，干得怎么樣。手藝人的自尊很重要，并且應該培養，但有時自尊會變成盲目的接受和防御。這第二雙眼睛會讓堅強的、很誠實的人認識到他們自己的局限并找出方法來減輕這些問題。
使用通才著重于確認你在一個由具備多種技能的個人組成的敏捷團體中。如果更深入地思考，你會發現這認可了軟件開發更多的是手藝而非流水線作業。然而，作為軟件開發的領導者，我們不能假設人力資源是完美的，并且忽略事實。我們最好能夠看到風險并為此作好計劃，歷史也證明開發者不會找到他們自己所有的錯誤。
以我個人的經驗，有這種觀念的人不喜歡任何人測試他的代碼，對建設性的批評也很敏感。 在特殊的情況下我們發現，這里潛在的原因是開發者真的不擅于編碼。 我們給了他培訓和指導，但經過幾個月的努力后，卻發現很顯然他是入錯了行。
所以，使用通才是好的，但如果因為喜歡哲學上的純粹，而忽略了幾十年來的實際情況的話，這種態度就會變得毫無新意。
總結
總之，這些問題在前敏捷世界中也能找到。但是根據我的經驗，這些壞態度在這種新的技術中找到了避難所和辯護。而孤立地看，這種新技術可能從來沒有打算在這樣一個臨時的演講臺上演講。作為軟件開發領導，我們在人們掌握敏捷的方法論之前演說這些觀點是危險的，并且可能把一場好好的運動給搞糟。敏捷有一個重要的信息，那就是簡單化，在產品開發的過程中讓客戶參與，取得所有權，并且保持聯系。如果丟失了這個信息，那將是非常令人失望的事情。因此，你們怎么想的？這些態度在你們那存在嗎？你們怎么評論這些態度?希望你們能告訴我。
關于作者
Christopher R. Goldsbury是一位軟件開發專家，在他的職業生涯中，擔任過的角色有：開發者、架構師、scrum專家、開發經理、項目經理以及質量保證經理。Chris把他的經歷和想法都寫在了他的博客上。
留言列表
