1. 不提升非技術技能
我們認為非技術技能是專案成功的主要因素。這些非技術技能也可以稱之為“軟技能”，總體上來說，它已經被公司證明為能夠駕馭企業和客戶之間的長期商業關係，因此也能決定公司的成長髮展路徑。一些關鍵的軟技能指標包括：
a.紀律——這是最重要的特徵之一，缺乏紀律，最終會讓這個開發團隊在開發能力上“缺乏自信”。解決這一問題的矯正方法就是每天制定詳細的to-do清單：兌現你的承諾、完成你開始做的事情、避免多重任務，因為這些往往會讓你的生活產生混亂。
b.顧客的聲音——不把客戶置於決策的核心地位只會跟你們業務的原始目的相沖突。如果客戶不高興，即使你擁有世界上一流的專業知識和資源也不會起什麼作用。保持符合客戶期望的解決方案、及時交付才能體現出專案的真正價值。
c.溝通——尤其是當客戶和供應商並不在同一地點的時候，明確而及時的溝通是填補服務空白的極好措施。主要集中在這三個方面你就能克服問題——進行主題討論、清晰表達、乾脆簡潔。
d.瞭解需求——在整個開發生命週期過程中，決定成功和失敗的之間的一個至關重要的區別將會給人留下深刻的印象。通過最初的頭腦風暴法瞭解問題狀態，以及後續的交貨程式，這其中都要和客戶完美配合。只有這樣，客戶才會讚賞你的工作，給你好評。
2. 對編碼不理智
古人云：善泅者溺，善騎者墮。但估計絕大多數 的程式設計師都認為自己的程式設計技術絕對的牛。而同樣真實的是，每一個程式碼，讓不同的程式設計師去實現的話都會不可避免地發現它所存在的缺陷。所以說，只有通過在一 個專案上的合作，程式設計師之間必然有的摩擦才能證明誰是最好的。健康的競爭是好事，但它不應該成為一個本來可以成功的專案的負擔。
另一個創意阻礙是無法將預定義的模板使用在對你有利的開發專案裡。幾乎所有的程式語言有一個很好的線上 /內建的程式碼片段儲存庫，可以修補程式碼，防止重新程式設計。然而，如果因為不理解需求或缺乏接觸各種可用庫/模板的話，這就意味著程式設計師最終會無意間將一開始 就建立的程式碼付之東流。這不僅增加了開發時間，也提高了總體成本。另外一點就是，釋出了的程式碼已經經過了質量檢測，所以只有將它用作模板才能發揮它更大的 價值。
3. 不一定什麼都要被理解
如果你是剛調到這個團隊來的程式設計人員，對於手頭的工作並不是很熟悉，那該怎麼辦？肯定是先看一些前任留下來的工作計劃，要是他寫的詳細倒也沒什麼，如果寫的不詳細，估計會讓你更加的撓頭。
因此，推己及人，在需要交代的工作上，最好是把任務寫的儘可能的詳細。這麼做也是非常現實的原因：能夠把程式設計問題解決掉，最好是保證使用解釋性的語言和英語發音來表示變數。一些基本的指標可以讓你的程式更容易被理解，包括：
- a. 把所有引數、引用、方法和變數名稱儘可能接近英語表達。保持檔名簡短但有助於理解的功能。
- b. 使用++包裝文字是一個好辦法，能讓程式碼和註釋更加清晰。
- c. 將編寫的程式保持在一個連續的流程上，尤其是在使用OOP基礎上的語言：C#、C 和 C++。
- d. 對於不同的程式碼塊使用不同的描述名稱。
4. 不使用經過驗證的工具和技術
程式設計師的好壞從他使用的程式設計工具和除錯工具上就能看出。在異常情況的跟蹤上，下面就是程式設計師經常會出現的常見錯誤。
- 對一些可能會對其它程式碼有影響的常見案例進行捕捉，處理這些比較常見的異常情況（而不是特殊的異常）意味著無意中除除掉了會抑制整個程式的殘留部分，因此並不會影響他人的程式碼。
- 也許程式設計師可能帶有惡意的意圖來捕捉所有的異常情況，但即使是捕捉到了也不實施採取措施，這就是常說的“虛假安全閥”，這種異常處理手段是對整個軟體的穩定和安全的一種妥協方式。
5. 較差的控制版本
在任何涉及多個團隊的專案裡，當談到版本控制的時候不去介紹使用最佳實踐都是一個十足的罪過。版本控制的目的是確保由一個人執行的編輯或修訂不去影響另一個人的工作。
版本控制不僅有助於將由兩個或兩個以上的程式設計師的編輯工作合併到一起，還有助於跟蹤程式的更改歷史。所以說，任何開發團隊都應該做一些好的改進措施以確保強大的版本控制，這其中就包括：
- 為每個解決方案建立一個“邏輯單元”
- 給解決方案制定描述性的名稱
- 確保你所使用的都是最先進的檔案
- 頻繁的向團隊分享你所做的各種改變
6. 擁有最新資訊的個人代表不了團隊
這是相對有趣的一點，所有的商業產品都想要以自身的敏捷技術和產品文化來給客戶留下深刻的印象，但是現 實中很少有廠商會花時間去磨練他們員工在介紹產品特點上的技能。許多公司只是簡單地提供了一些基本的培訓，並且抱希望與員工在真實的日常專案裡學到更多的 技能。所以部門經理和專案的直接領導可以通過以下兩個辦法來提高員工的業績：
- 一旦有新員工加入，就立刻強制安排他參加專業培訓，讓他知道他的角色是用來幹什麼的，儘早產生創造力。例如一個測試人與加入之後，就應該向他介紹程式設計的理念，之後將培訓重點放到測試實踐上，而不是繼續闡述程式設計的重要性。
- 現階段的技術的進化程度比以往任何時候都要快，，所以要記住，定期培訓是必不可少的，這是在給團隊創造價值。例如一個Web 設計師需要知道響應式設計，提供給設計師大量的使用者日常使用的移動裝置的不斷擴張的樣品，希望他們能獲得靈感。
7. 不恰當的測試
測試作為整個系統開發生命週期（Systems Development Life Cycle，簡稱SDLC）的重要一個要素，通常不需要開發團隊給出太驚人的結果。但是如果在測試環節沒有付出恰當的、相應的努力的話，這是說不過去的。 下面的一些方法或許對你的測試團隊有用，至少在你們交付產品的時候能夠給使用者一個好的交代。
- 單元測試
- 實物模型
- 綜合測試
8. 注意安全漏洞
有的時候在軟體開發過程中，就會遇見如下這樣的安全漏洞：
A、不同元件之間意想不到的互動作用：a、輸入不正確的驗證資訊；b、SQL資料隱碼攻擊；c、跨網站指令碼；d、命令植入攻擊；e、跨站請求偽造（CSRF）；
B、難以實施的資源管理，包括：a、不尊重可用記憶體緩衝區；b、對外控制；c、使用有潛在危險的功能；
9. 和客戶交流
最初的合同簽訂後，開發公司通常會忘記每天與客戶進行產品上的資訊互動，以至於在交貨的時候還需要進行升級。兩大關鍵的交流點可以讓你和客戶保持更好的、更長的關係：
- 在客戶開問之前，開發方應該和客戶進行交流溝通。
- 和客戶保持週期性的交流。
10. 避免標準實踐面臨的迫在眉睫的最後期限
通 常情況下專案都會遇到進度延誤的現象。然而，這不是說你有理由去偷工減料或者是在開發或測試階段耍花招，未經測試的模組絕對是一個隱患，會讓你的開發團隊 名譽受損的。一個更好的方法來管理延遲是提前告知客戶並且積極執行延遲計劃。只要延期的理由是有效的，客戶應該會理解，也會給你額外的時間來解決這個問 題。
顯然，在專案的最後期限內，急急忙忙完成程式設計的質量肯定不是特比保險，所以在交付之後開發團隊整體上會 花更多的時間和努力來進行跟蹤維護，這樣的成本也是很巨大的，最好的辦法就在一開始就制定完美的執行計劃。專案再造所耗費的資源或許是專案本身的成本的好 幾倍，任何一個公司寧願花更多的時間在初始開發上，這樣最終的產品一定會符合SDLC標準，並在缺陷和不良問題上有足夠的話語權。對於顧客來說，時效性不 能以犧牲質量為代價，永遠都不能。
評論(1)