一個軟件項目從開始到結束，由于資源、人員、管理、方法學等等各方面的因素，往往不可避免的會存在一些問題，如需求不明確、項目管理失敗、溝通問題等等，今天無意中看到老外寫的關于這方面的一篇文章，總結的比較全面，翻譯過來結合自己的一些經驗做了點補充和修改，存檔以備時常可以告誡一下自己。
1、不能很好的理解用戶的需求，缺少與用戶之間的溝通。
2、錯誤的預估項目的大小和難易度。
3、沒有計劃就匆匆開始編碼。
4、沒有在項目初期就開始做測試，一直拖到項目后期才做，或者根本不做什么測試。
5、選擇時下最cool的技術還是已經被團隊使用比較成熟的技術，往往不能做出很正確的選擇。
6、不采用任何軟件過程或者方法學。
7、沒有一個真正的項目經理，讓開發(fā)人員無計劃的主導項目。
8、拖延計劃，把進度壓力留在后期。
9、不做版本控制，混亂的代碼庫和開發(fā)環(huán)境。
10、在項目過程中隨意的更換開發(fā)工具和環(huán)境。
11、客戶的任何需求都答應下來，需求會永無止境，記得學會說“不”。
12、只有一個大的計劃，沒有把計劃分割成一個個更小的任務，要知道，大的計劃如果不分割成任務很難落實和具體實施。
13、對開發(fā)團隊的管理不足。
14、在項目后期增加人員來加快開發(fā)速度，很多時候往往適得其反。
15、開發(fā)人員不做單元測試。
16、一旦項目中遇到問題，就把壓力拋給開發(fā)人員。
17、不關注軟件實際的運營環(huán)境和硬件條件。
18、沒有命名規(guī)范和代碼規(guī)范。
19、到處都用全局變量。
20、遇到問題的時候往往不請教別人，而是一個人悶頭搞，到最后還是不得以還是通過別人來解決。
21、沒有寫代碼注釋的習慣。
22、對輸入輸出的數據不做驗證。
23、不做壓力測試，到實際環(huán)境中往往就會出現更多的跟環(huán)境和性能相關的問題。
24、項目內部溝通不暢，每個成員只是埋頭做自己的事情。
25、沒有很好的bug管理規(guī)范和系統，往往用word、email、excel等文本方式來跟蹤bug，將會導致整個項目的bug管理陷入混沌。
|