環境、現狀與反思

1 咱們今日的窘境

1.1 環境

　　咱們所處的環境是一個追求「革命性技術」的業界。公司追求着多、快、好、省地解決問題的捷徑，管理者關注的只是軟件進度、發佈版本、成本和利潤，在他們背後，軟件缺陷已經埋了下來。專一代碼質量的程序員每每不受青睞，由於他們思考的更多，在開發進度方面每每不盡人意。當項目負責人沒法評估或不關注代碼質量時，客戶只會獲得一堆調試不良的代碼。

1.2 人才流失

　　今天的程序員大多數都不會長期從事某一種技術，這與收入緊密掛鉤。程序員會傾向與轉型爲更高收入的技術隊伍，或者退出IT業。隨着市場供求關係，各個陣營市場佔有率，利潤等多種因素左右着程序員的收入。即使是在某個技術上十分出衆的程序員，面對經濟上的現實差距，也沒法抵抗金錢的誘惑而轉投其餘技術隊伍。如今的市場，再也不尊重那些資深從業者，而是迎合「現學現賣」的投機者。歸其根本在於，對代碼質量的低要求，使得技術硬手無用武之地。

1.3 系統交互複雜

　　今日的信息化系統已經不能由獨立的公司或軟件產品承擔，而是趨於多公司，多平臺的相互協做與交互。現實的挑戰就是，更大的系統，更多的平臺，更繁瑣的流程，更復雜的整合需求，以及更多的標準。

1.4 技術快餐

　　與以前不一樣，現今的開發者更爲大膽。他們勇於將未經驗證的新技術應用與產品或項目。開發者可能通過短暫的學習（一週或者幾天）就將學到的並不熟練的技術應用於項目，以後的風險所有轉嫁的測試或者客戶身上。而此後也再也不對這些新技術繼續安排學習。程序的可靠程度和可維護性大大下降。

1.5 產品團隊不堪重負

　　與項目不一樣，產品的代碼版本及分支路線更爲複雜，其生命週期更長。當你進入某個產品項目，你極可能面臨的是，缺失或低質的項目文檔，多種風格並存的代碼以及潦草的少的可憐的註釋。那些最早搭建系統的前輩可能已經離職，開發團隊組成也許已經通過幾代，你聽到的最多的是抱怨。面對那些延期的bug和新的需求，沒人通曉這些堆積如山的代碼，牽一髮每每動全身。閱讀和理解代碼佔據工做的大部分，面對客戶的各類要求每每不堪負重。

2 一些成功的經驗

2.1 提升代碼質量 

• 改進QA流程 多數QA僅僅依靠大範圍的人工測試來評價項目質量，即多數公司的QA依靠的是測試團隊。理想狀況下，大範圍的測試並不會有很高的錯誤檢出率。（若是你的團隊，每次發佈版本，大家的新建和從新打開的bug數量仍然很高，我只能說大家的公司尚處於軟件做坊階段，真正成熟的團隊，是不會容許交付測試團隊一堆調試不良的代碼的，即使是在趕工時。）檢查缺陷最有效，同時也是檢出率最高的方法，就是——代碼審查。所以，必須在計劃階段，就爲代碼審查預留時間，以便讓開發人員參與進來。
• 激勵手段 在績效結構中，應該與質量、進度、複雜度等掛鉤，而不是單純地只看進度。
• 測試每個關鍵里程碑 理想狀況下，測試每一個版本，測試用例作到100%的覆蓋率。但現實中，出於時間、成本等因素，測試不可能細化到邊邊角角。但對每一個里程碑進行全面迴歸測試是最低的要求，這樣軟件的bug更少，開發團隊更能受到激勵（例外是測試報告不盡如人意）。
• 樂觀的對待錯誤 不要把測試當成是對代碼的雞蛋裏面挑骨頭，不要埋怨爲何測試如今才測試出以前某個版本的缺陷。PM必定要避免開發團隊和測試團隊之間的相互指責。
• 要求清晰、簡潔、明清的測試報告 測試報告應該言簡意賅，不要過於追求樣式華麗，技術型文檔可以用一句話說明白就別囉嗦。
• 使用缺陷覈對表 「缺陷覈對表」我也想不起它的出處了，也或許是個人主觀創造，但從項目實踐角度講，「缺席覈對表」可以有效下降缺陷數量。下列顯示了一種簡單的缺陷覈對表：

問題描述	根本緣由	缺陷類型	嚴重程度	出現次數	解決方法
修改下拉列表內容後，進行操做會觸發未處理異常。	數據完整性約束被破壞，阻止操做。	設計缺陷	嚴重	4	禁止修改下拉列表選項。
上傳大文件報錯。	服務端限流。	配置缺陷	通常	2	修改配置文件的消息大小限制。
...	...	...	...	...	...

　　這份表格是否好用，在於其更新的頻率與用戶羣。它可以幫助PM及時發現bug集羣，並能夠經過例會或郵件打預防針，防止缺陷覈對表上的bug蔓延。

2.2 爲人才流失作準備

• 注重文檔的積累並注重代碼註釋和編碼規範
• 推進團隊內部的交叉培訓
• 在某些共識的環節上推進自動化
• 創建健全的僱員框架

2.3 一些成功的系統整合經驗

• 組建跨職能團隊 公司各個智能部門都有義務參與進系統整合，經過關鍵用戶來平衡各部門的需求。
• 制定合理的進度計劃 PM可以頂住壓力，制定現實的計劃，而不是經過削減範圍或質量來迎合公司。
• 認真評估資源 不少項目須要外部開發人員參與，因此須要對這類資源進行能力評估，以便合理安排進度。
• 並行上線 在新系統沒有經過最終審覈以前，請保證舊系統的良好運做，同時維護好舊系統的數據。
• 作好打持久戰的準備 不一樣於製做網站或OA，整合項目牽扯到更多的需求，更復雜的系統和業務流程，所以，請作好需求頻繁變動以及打持久戰的準備，並讓團隊瞭解現狀，防止團隊由於長時間的開發和過少的里程碑而造成挫敗感。

2.4 有效下降產品的維護成本

• 建立並維護文檔 文檔如代碼同樣是寶貴的組織過程資產。雖然敏捷軟件開發注重能夠工做的代碼，可是，也不能打着敏捷的旗號來抵制文檔。一些必須有的文檔，好比：需求說明書、軟件規格說明書、開發計劃、設計文檔、測試報告、變動控制等，須要歸入到配置管理中去，而且在維護過程當中進行同步。
• 嚴格遵照編碼規範 編碼規範必須在項目組內部達成共識，因此開發人員必須嚴格遵照，有條件的推薦進行自動化的編碼規範審查。
• 作好配置管理 請參考本人博文 SVN與SCM。
• 推進自動化 推進測試、發佈、代碼審查的自動化。
• 推進交叉培訓 不要等到人員即將離職才分享他的經驗，要在工做間隙，利用暗時間，推進團隊造成交叉培訓的習慣，使關鍵技術不會侷限在單點。
• 快速處理產品問題 對於延期的bug要儘快處理，越晚處理，其修復成本越高，一旦開發者離職，讓其接任人員來修復這些延期bug則有些強人所難。
• 對新技術提升警戒 評估新技術帶來的風險與收益，選擇那些知足企業宏觀目標的技術，儘可能不要在高風險項目上引入未經實踐的技術。對於技術探索項目，範圍不要太大，並且，一次不要引入兩個以上的新技術（也有保守的公司，規定技術探索項目，只能引入一個新技術點），以便能有效地評估收益和影響。在引入新技術的過程當中，通常用1/3的項目時間快速學習和吸取，用1/3的的世界培養團隊自立，最後1/3的時間讓團隊成員徹底掌握。
• 完善項目管理 創建完善的項目管理流程，可以造成以客戶爲中心的，有完善體系的產品團隊，即有效地協調需求、開發、測試、質管、實施等不一樣資源，快速應對來自不一樣客戶的需求。

2.5 讓團隊成員參與項目管理

　　若是團隊成員沒能參與項目管理，則項目管理將大打折扣。爲了讓團隊的每位成員都參與到項目管理中去，有如下建議：

• PM須要從團隊成員角度思考某些問題 PM須要理解和接納程序員的某些工做風格和激勵因素。
• 適度的受權 對有能力的成員受權，不只能提升其積極性，也能讓PM能專一於其餘業務。
• 常開會，開小會 常常與成員溝通，瞭解項目現狀，但不要開那種冗長的會議。
• 對於團隊性決策力求達成共識 PM不要以權壓人，對於如編碼規範這類影響較大的規定，須要促成團隊成員的共識，而不是自個人專斷專行。若是PM搞獨裁，那團隊成員也會玩非暴力不合做。
• 在員工入職培訓時強調項目管理 在入職培訓課程中，明確項目組的各類規定，流程以及工做各類輔助管理軟件的使用。

3 IT治理

　　IT治理就是要明確有關IT決策權的歸屬機制和有關IT責任的承擔機制，以鼓勵IT應用的指望行爲的產生，以聯接戰略目標、業務目標和IT目標，從而使企業從IT中得到最大的價值。

3.1 IT治理成敗20條

10條有效運用資源的方法：

1. 針對IT治理價值，與開發者保持坦率的溝通，解決其中問題而不是壓制言論。
2. 組建公司級跨職能IT治理委員會，保證治理順利推行，保證技術體現客戶最大利益。
3. 創建量化指標，利用公認的指標評估治理進度。
4. 保證IT基礎設施各部分的透明。
5. 將公司IT治理策略延伸到外包商。
6. 創建能表現業務目標的全景視圖。
7. 將IT治理視爲促進企業成長的基石，利用獎金引導員工的正確行爲。
8. 對公司員工和團隊內跟不上變化，相關技能欠缺等等跡象多加註意。
9. 在軟件開發週期的每一個環節都實施IT治理，以防留下盲區，致使差錯。
10. 推動自動化，但不拋棄人工評審流程。

10種白白揮霍資源的行爲：

1. 未經解釋就強制推行的官僚流程。
2. 架屋疊牀的監督層級。
3. 無人能懂的報表。
4. 被隔離於代碼以外的開發者。
5. 僅限於單個部門的努力。
6. 企圖一切盡善盡美的緊張神經。
7. 僅在一兩個方面實施IT治理的開發流程。
8. 缺少跟蹤IT管理的支出和效果評估。
9. 重複創造的策略。
10. 對IT治理資源充足程度的盲目自信。

3.2 衡量IT治理和相關投資成效的10個問題

1. 管理層是否支持和實施IT治理？
2. 開發者是否參與其中？
3. 是不是公司的主動戰略行動？
4. 是否增長了企業透明度，使部門和員工權責分明？
5. 是否讓引入新技術和企業合併時的基礎設施融合更加容易？
6. 可否幫助員工改進行爲？
7. 是否給全部干係人提高價值？
8. 可否作到極盡精益和高效？
9. IT基礎設施能否隨時抽檢，而保證沒有問題？
10. 是否減小了軟件缺陷？

4 雜談——終結IT業七大流言

1. 信息技術是精確的科學 現實是， 創建應用依靠的是程序員的代碼，而編碼是一門藝術，程序員是匠人，信息技術一樣須要工藝。
2. 下一個版本能解決這些問題 軟件開發商的經常使用伎倆。
3. 開箱即用 企業級軟件每每很難達到開箱即用，這每每是軟件廠商的吹噓。
4. 代碼文檔完善 現實是，開發人員被進度和變動壓榨了120%的時間，無力維護文檔。
5. 文檔說明一切 文檔質量良莠不齊，有時不得不聘請外部顧問。
6. 團隊不須要「黑客」和「牛仔」 前者指那些擅長安全技術的人員，後者則指那些技術強硬但特立獨行的人員，他們的共同特色是技術過硬，工資不菲。其實開發團隊中若是有掌握安全技術的成員，能使你開發的系統更安全；而若是能駕馭牛仔，他將能幫助團隊衝破圍城。
7. 最大的安全威脅在公司外部 現實是，絕大多數攻擊源自公司內部。

 

參考文獻：

　　《差錯 軟件錯誤的致命影響》