同時追逐3只兔子

很長一段時間沒有過這樣在工作上產生沮喪和失去控制力的感覺了。

技術部的頭頭說：“我們要重點反展目前這個項目所代表的產品方向，我們要增加人力，我們要在項目完成的同時完成一個其他功能有部分重疊的產品，我們要在完成產品和項目的同時完成我們的基礎平臺，我們要在客戶要求的期限——5月之前完成，3月就要完成。”
我驚訝的發現自己一瞬間置身於《最後期限》所描繪的一個情景之中，一場會議之後，突然發現自己的團隊膨脹了一倍多。被一個人反覆的強調需求文檔的重要性，他卻不肯花20分鐘的時間來討論一下項目的需求究竟是怎樣的；聽着他們給我講J2EE架構怎樣天然的促使人員的分工，而事實的劃分大部分的人還是所謂“業務邏輯層”，不過要順便作一下頁面；看着主程序員與他們討論不需要專門2個人來進行數據庫設計，而這麼作的解釋是“我們要非常靈活，大部分界面上的字段都是可配置的”，奇怪的是我沒有聽過任何一個客戶提過這樣的要求，而我還沒有寫，他也未必會看的需求文檔中也不會有這麼一條。

儘管技術部的頭頭並不是像《最後期限》中的貝洛克部長那麼窮兇極惡；儘管我們也都同意需要對程序的結構進行分層和麪向對象的包裝；儘管我們都認爲項目的進行應該是迭代式的；儘管他也說3月份完成的產品不要求完全可用，而我原本的計劃也要在3月發佈第一個版本。然而，有更多微妙的區別存在，使我只能悲哀的看着項目的進程受到無端的打擾，只能希望這一切過去後還有足夠的時間來趕上客戶的進度，或者在過去之前離開這個我寄與厚望的項目。

有這麼多的相同點，爲什麼我還是無法接受？
沒有人真正來了解項目的進展情況和徵求我關於項目進度的看法。就直接來“給予幫助”，並認爲理所應當的應該有更快的進度。
雖然我們都在用“迭代”這個詞，但是他們說的卻不過是一個接一個的小瀑布而已
他們的腦子裏，軟件是設計出來的，開發人員能作的就是實現這樣的設計，他能掌握的，不過是使設計走樣的程度。
三個不同的目標由一個團隊來完成，而這個團隊對於單一的項目而言，太大了。更糟的是，領導隨時有抽回他所投入的“幫助”人員的權力和可能性。更更糟糕的是，在一上午的討論後，下午進行全體會議時我才驚訝的發現原來要組成的是統一的團隊，而不是我一直堅持的3個相對獨立的小團隊，通過定期的評審和技術交流來共享技術成果。這樣的基本分歧竟然留到的最終全員會議上才發現，我不清楚是交流的什麼環節出現的問題。

也許工作就是這樣吧，真正的敏捷就是要能夠表現出相對其他方法的競爭優勢。（雖然僅憑我的努力無法讓整個項目敏捷）不如想想有利的方面吧：
此前的實踐中我已經發現無法按照xp那樣的最精簡方式來進行項目，主要是因爲沒有現場客戶。但也還沒有調整出更加適合的中間產品的規範。目前這個項目中不斷經受來自傳統觀點的置疑和約束，可以適當的調和原有實踐中的偏差，並且真正檢驗敏捷的有效性。
由於沒有有效的推行TDD，前面已經覺得沒有足夠的精力來保證項目的質量。現在項目進度交由其他人掌握，我可以專心考慮項目的功能設計和需求驗證問題。
反覆思想鬥爭的走人問題，至少現在作出離開的決定會容易一些。