《快速軟體開發》學習筆記 之一 轉摘自cnblogs

文章目錄

• 第1章 軟體開發策略
• 第2章 典型錯誤

第1章 軟體開發策略1.1 軟體開發中的四維

http://www.cnblogs.com/lijia821130/archive/2012/03/04/2379610.html

任何軟體項目，都有四個重要的維： people、process、product和technology。為使項目能順利進行，軟體經理必須充分發揮這四維的作用。下表是對這四維的總結。

表 1-1 軟體開發中的四維

維度

如何最佳化

People

l 為團隊挑選勝任稱職的成員

l 選擇合適的團隊結構

l 使用恰當的人員激勵措施

Process

l 採用標準的軟體工程實踐，避免開發過程失控

l 做好風險管理

l 為項目選擇合適的生命期模型

l 形成良好的品質保證機制

l 選擇客戶導向的開發方法，使開發的產品真正滿足客戶需求

Product

l 較準確地估算product size（產品規模）和effort（工作量），以便制定出現實的進度安排

l 採取恰當措施防止軟體開發過程中product size或product scope失控

l 為產品設定合理的product characteristic（如記憶體佔用、穩定性、可靠性等）。

Technology

l 選擇恰當的、能確實提升生產率的工具（包括新的程式設計語言、新的開發實踐、新的程式碼程式庫等）

許多軟體經理傾向於只關注這四維中的某一維而忽視其它維度，而高水平的軟體經理卻努力做到同時最佳化項目的四個維度。

1.2 軟體開發的總體策略

一個軟體進行的軟體項目應該遵循如下的4點策略：

1. Avoid classic mistakes. （避免典型錯誤）

2. Apply development fundamentals. （採用軟體開發的基礎性實踐）

3. Manage risks to avoid catastrophic setbacks. （管理風險，以避免災難性的結果）

4. Apply schedule-oriented practices. （採用面向進度的實踐）

這4點策略可以 用來形象地表示。

這4點策略就像是4根支柱，共同支撐起一個成功的軟體項目。尤其是前面3點策略，是每個軟體項目高效進行的關鍵。

第2章 典型錯誤

邁克爾·傑克遜曾唱過：“孩子，一個壞不要壞了整筐蘋果”。但在軟體開發領域，一個壞蘋果是可以毀掉一筐蘋果的！軟體經理必須記住：一個軟體項目只要犯了一個典型錯誤，就會滑向慢速開發的深淵；要實現快速開發，就“必須”避免所有的典型錯誤。

軟體經理怎樣做到避開這所有的典型錯誤呢？使用“典型錯誤清單”。

最佳實務：典型錯誤清單

1. 以表2-1作為初始的典型錯誤清單。

2. 從投入到某個項目的第一天起，每天在下班之前檢查一遍典型錯誤清單，反省自己或團隊有沒有犯典型錯誤。如果有，思考一下怎麼改變。

3. 在每個項目結束之後，分析總結在項目中所犯的典型錯誤。如果是典型錯誤清單中不存在的，把它加入到典型錯誤清單中，供下個項目使用。

表 2-1 典型錯誤清單

相關維度

典型錯誤

解決辦法

People

1. Undermined motivation. （挫傷積極性）

激勵開發人員，詳見第10章。

2. Weak personnel. （人員不能勝任）

招聘可勝任的人員，詳見第11章。

3. Uncontrolled problem employees. （對問題員工失去控制）

儘快處理問題員工，詳見第11章。

4. Heroics. （英雄主義）

團隊領導或成員對自身能力過於自信。

客觀認識自身能力，避免盲目自信。

5. Adding people to a late project. （向已落後進度的項目增加人員）

不向落後進度的項目增加人員。如果實在要增加，可增加行政人員，協助技術人員處理雜務。

6. Noisy, crowded offices. （辦公環境擁擠嘈雜）

營造安靜、整潔的辦公環境，詳見第10.3.1節。

7. Friction between developers and customers. （開發人員與客戶之間產生摩擦）

維持良好的客戶關係，詳見第9章。

8. Unrealistic expectations. （不現實的預期）

進行準確的軟體估算，制定合理的進度計劃，詳見第7章和第8章。

9. Lack of effective project sponsorship. （缺乏高層對項目的有效支援）

請求高層對於項目的支援。

10. Lack of stakeholder buy-in. （干係人沒有全身心投入項目）

請求干係人的全身心投入。

11. Lack of user input. （缺乏使用者介入）

在軟體項目的全過程都重視使用者反饋，詳見第9章。

12. Politics placed over substance. （玩弄政治）

實施有效措施保證項目和團隊成功高於個人成功，詳見第11章。

13. Wishful thinking. （充滿想象）

根據主觀願望而非客觀事實對項目狀況進行判斷。

破除一廂情願的想象，把項目執行落到實地。

Process

14. Overly optimistic schedules. （過於樂觀的進度計劃）

進行準確的軟體估算，制定合理的進度計劃，詳見第7章和第8章。

15. Insufficient risk management. （風險管理不到位）

進行充分的風險管理，詳見第4章。

16. Contractor failure. （外包承包方違約）

有效管理外包項目的風險，詳見第16章。

17. Insufficient planning. （專案規劃不到位）

完成有效專案規劃，詳見第3.1.1節。

18. Abandonment of planning under pressure. （在壓力下放棄專案規劃）

在壓力下更要堅持規劃，但需要根據項目進展狀況及時調整和重新規劃。

19. Wasted time during the fuzzy front end. （在項目前期浪費時間）

不在項目前期浪費時間，爭取儘快立項並進入執行階段。

20. Shortchanged upstream activities. （走樣的上遊任務）

草草完成需求分析、概要設計和詳細設計。

認真進行需求分析、概要設計和詳細設計，並進行technical review。

21. Inadequate design. （低劣的軟體設計）

進行高品質的軟體設計。

22. Shortchanged quality assurance. （走樣的品質保證）

取消design review、code review和test planning。

任何時候都不放鬆對軟體品質的要求，詳見第3.6節。

23. Insufficient management controls. （管理控制不到位）

加強對項目major milestone和miniature milestone的管理和監控，詳見第3.1.2.1節。

24. Premature or overly frequent convergence. （過早或過於頻繁地開展項目收尾工作）

不要過早或過於頻繁地開展項目收尾工作。

25. Omitting necessary tasks from estimates. （項目估算中遺漏必要的任務）

把項目估算中易遺漏的任務列於顯著位置，防止遺漏，詳見第7.2節。

26. Planning to catch up later. （試圖趕上進度）

進度落後之後，不要試圖趕上進度，而應該根據項目新的狀況重新制定進度計劃，詳見第7.3節。

27. Code-like-hell programming. （地獄式編程）

項目採用急就章式的、自由散漫的、“代碼寫到哪兒算哪兒”式的編程模式。

絕對避免急就章式的編程，任何代碼必須經過嚴格的品質保證措施，詳見第3.6節。

Product

28. Requirements gold-plating. （需求鍍金）

項目的需求規格書中具有使用者不需要的、複雜的需求。

不要在需求規格書中加入使用者不需要的需求。

29. Feature creep. （功能蔓延）

項目進行過程中頻繁出現需要變更（requirement change）。

採取措施防止功能蔓延，詳見第13.2節。

30. Developer gold-plating. （開發人員鍍金）

開發人員為了學習新技術而給產品加入使用者不需要的功能。

不要為了讓開發人員學習新技術而加入不需要的功能。

31. Push-me, pull-me negotiation.

軟體經理一面批准了進度拖延，一面又向拖延的項目中加入新的需求。

在項目已經拖延的情況下，必須穩定需求，不再加入新的需求，詳見第15.1.3節。

32. Research-oriented development. （研究導向的開發）

把軟體研究（如新演算法）當成工程項目來做。

不在軟體工程項目中搞軟體研究。

Technology

33. Sliver-bullet syndrome. （銀彈綜合症）

項目把解決進度問題的希望寄託在單獨某一種新實踐、新技術或新開發方法論上。

破除銀彈綜合症，詳見第14.2節。

34. Overestimated savings from new tools or methods. （過高估計了新技術或新方法帶來的收益）

對新技術或新方法帶來的收益有較理性的認識，詳見第14章。

35. Switching tools In the middle of a project. （在項目進行期間更換開發工具）

持續使用久經考驗的舊工具，詳見第14章。

36. Lack of automated source-code control. （缺少自動化原始碼控制）

必須使用自動化原始碼控制系統。

最佳實務：Source Code Control System

給整個項目乃至整個公司選擇一個source code control system。這個source code control system可以是商業軟體系統（如ClearCase，Perforce等），也可以是免費軟體。只有在source code control system就緒之後，才開始啟動你的項目。