最近對敏捷比較感興趣,正好翻看了《高效程序員的45個習慣-敏捷開發修煉之道》,頗有些感觸,倒不是對敏捷的實施方法,而是文中所提的一些習慣之處,覺得習慣的養成可能比具體的敏捷實踐要重要得多。所以這里借用下文中標題,談談對高效程序員習慣的理解。
<h2>一、做事優先</h2>
在項目團隊開發過程中,出現問題時最高優先級應該是解決問題,而不是找到責任人并進行指責。當然在問題解決之后,可以找到責任人一起分析問題產生的原因,盡量在后期避免再次發生。在團隊還是能看見一些成員喜歡“推卸責任”或者“事不關已,高高掛起”,這往往不可取。
<h2>二、欲速則不達</h2>
必須得承認人是有惰性的,如果個人對自身的要求不高或者項目的進度比較緊的情況下,就容易為了完成任務而“趕進度”,這樣造成的后果就是質量太差而花了更多的時間去修復問題。又或者是解決bug的時候只是解決“淺層次”的問題,比如可能存在類似問題的地方不做檢查解決、可能只是解決了單個場景的問題等等,結果沒有從根本上將問題解決。所以這里要提倡重速度更要重質量,“為了看起來完成任務”的思想要切換成“為了有效地完成任務”,“解決單個問題”要切換成“解決一類問題或根本問題”。
<h2>三、對事不對人</h2>
在與人溝通具體事情的過程中盡量要保證客觀公正,避免夾帶過多感情色彩。因為這樣才能更好地讓大家關注在事情本身,而不至于因為個人情感表達造成對當事人的傷害。這里一方面需要注意對不同的聲音持有一個開放的態度,另一方面也需要在溝通過程注意方式方法,比如對事情有不同看法時最好以提問的方式提醒當事人,這樣在情感上更加容易接受。
<h2>四、有問題要溝通</h2>
程序員喜歡鉆研問題,但容易陷入死胡同。比如問題比較棘手的時候,往往喜歡悶頭研究而不愿求助,最后可能有些問題就會一直比較糾結而得不到很好的解決。而實際的經驗一次又一次的告訴我們往往求助之后可能立即豁然開朗或者得到新的解決思路。所以在實際遇到問題時,當然首先需要自己想辦法解決,然而在黔驢技窮的時候一定不能將問題捂住,一定要尋求溝通與幫助。另外如果是發現別人的問題,那更加需要及時地提醒,更進一步還可以提供解決方案以供參考。
<h2>五、終身學習</h2>
信息技術的發展可謂是日新月異,所以需要大量的學習才能保證對知識的敏銳度。書中提到的幾個方法值得對待:(1)迭代和增量式的學習:即花固定的不需要太長的時候持續學習;(2)了解最新行情;(3)參加本地的活動:比如講座或者培訓;(4)參加研討會議;(5)如饑似渴地閱讀。總之就是生命不止,學習不息。這方面我有個自認為的最佳實踐:學習一方面需要考慮興趣,喜歡的才高興去學;另一方面需要考慮整個行業的發展方向,跟著大勢起碼不容易過時;另外最好能“學以致用”或者“解惑”,這樣可以更快地實踐檢驗和得到反饋。
<h2>六、投資團隊</h2>
“教會徒弟,餓死師傅”這樣的話經常被當做玩笑話講,不過實際情況中確實也有不少人存在這樣的想法,但是這種想法是非常危險的。如果這樣的人做為領導,團隊的實力會很難提高,另外自身的水平也會受到很大的局限性。另外現在是個崇尚開源的技術世界,不論是做為領導還是普通的一員,都要樂于分享,保持一個開放的心態,多聽多講必有所獲。如果在公司可以定期組織一些分享交流會或者坐談會,而且形式也不用過于死板,可以輕松愉快點。
<h2>七、打破砂鍋問到底</h2>
凡事多問幾個為什么,對于問題要不滿足于簡單地解決,更進一步要了解問題產生的原因?遇到類似問題怎么解決?怎么解決更好等等。總之重要的不是問題本身,而是問題背后深層次知識的掌握和解決類似問題的方法。
<h2>八、客戶為大</h2>
程序員做為項目的實施人員喜歡從實施的角度考慮問題,而忽視用戶的角度,這樣往往就造成對需求的理解與用戶存在偏差,更有甚者有些程序員直接閉門造車,最后交付的時候與用戶所想千差萬別。所以程序員一定要多注意以客戶(業務)的角度考慮問題,在需求不明確的時候不要埋頭若干或想當然地實施,一定要及時與需求方進行溝通確認。
<h2></h2>
我這里沒有講到太多的編碼細節相關的習慣,原書其實提到了很多,還有大量的講解與示例,而且都有一些實踐的技巧講解。我更多地是談了些個人的體會,不及書中萬一,所以這里推薦下這本書,值得一看。
同步發表于CSDN博客:http://blog.csdn.net/qiubabin