對于軟件項目經(jīng)理來說，要求盡早交付產(chǎn)品，他們的面臨的壓力往往是巨大的，那么，在巨大的壓力面前，項目經(jīng)理們該怎樣做速戰(zhàn)速決，完成任務呢，下面是一點建議。
假設你的團隊有兩名程序員，伯尼和羅布。兩人都很能干，知識面相同，編程語言技巧也相當。你發(fā)現(xiàn)在開發(fā)過程中伯尼實現(xiàn)軟件功能的速度遠遠超過羅布。當伯尼著力于快速完成編程時，羅布正花時間寫代碼并對其進行重構(gòu)。羅布對變量和方法的命名更擅長。一旦寫的程序能夠運行起來，他就把這個程序分成幾小塊?，F(xiàn)在他要寫測試來確保該程序的每一塊都能按照他的意圖運行。當他覺得結(jié)果比較滿意時才宣稱實現(xiàn)了功能。
但是假設你并不知道上述這些細節(jié)。如果你只看他們誰先宣稱實現(xiàn)了功能，那么很明顯伯尼表現(xiàn)得更好，對嗎?
幾個星期之后，你向客戶演示這些功能。像往常一樣，顧客喜歡你已經(jīng)完成的功能，但現(xiàn)在需要你做一些改動和完善。你讓軟件開發(fā)人員修改這些代碼。當你把新改進的功能帶回給客戶時，他們試用了羅布實現(xiàn)的功能，對他做出的改動十分滿意。
遺憾的是他們發(fā)現(xiàn)伯尼實現(xiàn)的功能有些奇怪。當伯尼編寫好新的功能后，一些以前能使用的功能現(xiàn)在卻不能用了?？蛻舭堰@些作為缺陷標記出來，然后你讓伯尼來修改。客戶又一次測試這些功能，結(jié)果后來新增的功能也不能用了。這到底是咋回事呢?
如果你有孩子，就會知道發(fā)生了什么。伯尼創(chuàng)建的是一個打地鼠式的應用程序。打地鼠是一種游戲，孩子們拿著一個木棒敲打幾個孔中隨意彈出的地鼠，他們會很驚奇接下來是哪個地鼠彈出來，而且還樂此不疲。然而，在修改應用程序的時候如果總有壞代碼不知從何處隨意彈出，那可不是好玩的事情。那會令人沮喪，結(jié)果也難以預料，并且它會減慢產(chǎn)品開發(fā)速度。伯尼一開始就全速沖刺，只是南轅北轍了。
從短期來看，這似乎是一種損失，然而它帶來的卻是長期收獲。寫高質(zhì)量的代碼和測試都需要花時間。當估計某一功能的實現(xiàn)時間時，不要只考慮最初寫代碼所花費的時間，還要加上提升、調(diào)整和改進這些代碼所需的時間?！ ?/span>
盡管羅布從一開始就表現(xiàn)得較慢，但實際上他編寫的代碼更勝一籌。事實證明，他的節(jié)奏是可持續(xù)發(fā)展的。由于最初編寫的代碼就有較好的質(zhì)量，所以，他才能更快地做出可行的改動。而且他早期編寫的測試能隨時帶給他反饋信息，讓他了解自己新寫的代碼是否與原有應用程序的其他部分兼容。