《领导软件开发团队》-软件项目流程管理(转载)
需求获取与分析
a)不要在需求获取和分析过程中吝啬你的时间，对需求的明确可以减少你以后设计和开发的改动，提高你所开发软件的可用性。你对它的轻视只可能换来对你的产品修改、计划延迟等方面的惩罚。
b)要使尽各种办法，尽量多的获取客户的需求，主要的方法包括：仔细阅读合同标书和市场资料、与客户直接的谈话交流、让用户观看或使用原型界面提出意见。另外不要忽略内部客户的一些合理需求如测试人员等。
c)进行正规的需求管理，如建立需求文档或使用需求管理数据库等。在文档或数据库中要保留每个需求的详细描述及其来源，最好还能记录一些其他细节信息（如用户的一些原始描述等），另外别忘了确定每个需求的优先级。
d)在设计前组织你的设计人员开会进行需求理解和讨论。由于阅读文字性的信息容易造成一些误解和歧义，最好让需求制定者组织会议，给相关人员（如各子系统设计人员）讲解需求并进行设计讨论。这样做有两个好处，一是避免设计与需求出现偏差，二是激发设计人员产生初步的设计想法。
确定结构及系统设计
a)顶层设计必须要有多人及专家参与。一个好的设计方案不可能完全出自一个人的脑袋，它往往是经历多次讨论甚至争论、多次改进与融合而最终形成的一个有创造性的妥协产物。但你要避免争论的过分激烈而导致的负面效果。
b)一个好的设计应包含简单的框架，细节隐藏其下。组块和模块是一个好的设计所具有的特征，在顶层设计里人们看到的是简捷的框架和功能明确的组快，在每个组快内部又能发现一个简单的框架和其他一些自包含的的组块或模块。
c)在系统设计时想想你的用户将怎样使用你的软件工作。很多时候设计人员会习惯性地从技术角度考虑系统地布局和划分，可这种技术上地合理有时可能跟使用上的合理是冲突的，所以此时考虑一下你的用户将降低你今后修改的风险。
有关详细设计
a)详细设计没有必要过于精细准确。目前对有关底层详细设计是否需要以及它该详细到何种程度还存在一定的争论，但认为可以不要和必须写得非常精确这两种极端思想都是有害的。详细设计的作用在于开发人员编码前整理思路，同时让别人通过审核详细设计文档检验你的思路是否正确，防止出现错误。
测试问题
a)繁杂但极富成效的单元测试。如果想将你的软件质量提高到一个新的档次，对开发的软件模块进行完整的单元测试是一个很好的途径，它能使开发者对自己的代码成果更加有信心。虽然一些软件项目单元测试做的很少甚至没有，并且产品在最终测试后也运行的不错，但它只能保证在与最终测试环境类似的环境中运行是安全的，超出这样一种环境范围则可能充满雷区。
b)必不可少的最终测试。如果你的项目受时间、人力等资源影响没法进行过多的单元测试，那最终测试就成了你软件产品的唯一质量保证，千万别把这一保证也丢了，没有它你的软件产品就毫无质量可言。最终测试的另一大用处是通过它可以发现一些单元测试的漏洞，完善单元测试用例。
c)根据你的软件特性选择自动测试。自动测试如果能在你的项目中使用上，将是个不错的消息，虽然目前的自动测试工具对一些特殊情况和特殊数据的细节处理略显笨拙，但用它来检验产品的基本可用性和代码修改的影响却是高效的。有时自动测试还可能帮你发现手工测试几乎不可能出现的错误情况，例如极短时间内触发多个操作造成的冲突等。
有关重构
a)顶层结构的重新设计。通常当你的项目出现这种情况是非常不幸的，出现的原因一般是由于原来的结构不能支持新补充的特性而不得不进行修改。这种重新设计要注意两点，一是时机最好选择在一个大的工作阶段开始时，二是在新结构中尽量移动原有代码而不是编写新代码。
b)底层模块的改进。由于当初编写时的仓猝或考虑不周使得现有模块存在这样或那样的问题并且难于理解，这种情况下进行重构改进是很有必要的。修改的方法通常为对已有代码进行整理和注释，增加模块的封闭性和稳健性。
新技术的运用
a)评估新技术，确定它是否可以给项目带来好处。合适的新技术可以提高产品开发效率和质量，判断某一新技术对你的项目是否合适通常需要派专人或一个小组进行小范围考察和验证。采用新技术的时机最好选择在项目开始时或项目的某些重要阶段开始时，另外千万别忘了培训你的开发人员使用它。
b)避免几种使用新技术的动机。一是为了学习新技术而在项目中使用新技术，这样只能使你的项目变成一个实验田，项目产品最终也成了实验产品。二是不要指望使用新技术能拯救陷入困境的项目，如果一个项目陷入困境，它通常需要的是清晰和稳定，未知的新技术很可能导致更大的混乱。
a)不要在需求获取和分析过程中吝啬你的时间，对需求的明确可以减少你以后设计和开发的改动，提高你所开发软件的可用性。你对它的轻视只可能换来对你的产品修改、计划延迟等方面的惩罚。
b)要使尽各种办法，尽量多的获取客户的需求，主要的方法包括：仔细阅读合同标书和市场资料、与客户直接的谈话交流、让用户观看或使用原型界面提出意见。另外不要忽略内部客户的一些合理需求如测试人员等。
c)进行正规的需求管理，如建立需求文档或使用需求管理数据库等。在文档或数据库中要保留每个需求的详细描述及其来源，最好还能记录一些其他细节信息（如用户的一些原始描述等），另外别忘了确定每个需求的优先级。
d)在设计前组织你的设计人员开会进行需求理解和讨论。由于阅读文字性的信息容易造成一些误解和歧义，最好让需求制定者组织会议，给相关人员（如各子系统设计人员）讲解需求并进行设计讨论。这样做有两个好处，一是避免设计与需求出现偏差，二是激发设计人员产生初步的设计想法。
确定结构及系统设计
a)顶层设计必须要有多人及专家参与。一个好的设计方案不可能完全出自一个人的脑袋，它往往是经历多次讨论甚至争论、多次改进与融合而最终形成的一个有创造性的妥协产物。但你要避免争论的过分激烈而导致的负面效果。
b)一个好的设计应包含简单的框架，细节隐藏其下。组块和模块是一个好的设计所具有的特征，在顶层设计里人们看到的是简捷的框架和功能明确的组快，在每个组快内部又能发现一个简单的框架和其他一些自包含的的组块或模块。
c)在系统设计时想想你的用户将怎样使用你的软件工作。很多时候设计人员会习惯性地从技术角度考虑系统地布局和划分，可这种技术上地合理有时可能跟使用上的合理是冲突的，所以此时考虑一下你的用户将降低你今后修改的风险。
有关详细设计
a)详细设计没有必要过于精细准确。目前对有关底层详细设计是否需要以及它该详细到何种程度还存在一定的争论，但认为可以不要和必须写得非常精确这两种极端思想都是有害的。详细设计的作用在于开发人员编码前整理思路，同时让别人通过审核详细设计文档检验你的思路是否正确，防止出现错误。
测试问题
a)繁杂但极富成效的单元测试。如果想将你的软件质量提高到一个新的档次，对开发的软件模块进行完整的单元测试是一个很好的途径，它能使开发者对自己的代码成果更加有信心。虽然一些软件项目单元测试做的很少甚至没有，并且产品在最终测试后也运行的不错，但它只能保证在与最终测试环境类似的环境中运行是安全的，超出这样一种环境范围则可能充满雷区。
b)必不可少的最终测试。如果你的项目受时间、人力等资源影响没法进行过多的单元测试，那最终测试就成了你软件产品的唯一质量保证，千万别把这一保证也丢了，没有它你的软件产品就毫无质量可言。最终测试的另一大用处是通过它可以发现一些单元测试的漏洞，完善单元测试用例。
c)根据你的软件特性选择自动测试。自动测试如果能在你的项目中使用上，将是个不错的消息，虽然目前的自动测试工具对一些特殊情况和特殊数据的细节处理略显笨拙，但用它来检验产品的基本可用性和代码修改的影响却是高效的。有时自动测试还可能帮你发现手工测试几乎不可能出现的错误情况，例如极短时间内触发多个操作造成的冲突等。
有关重构
a)顶层结构的重新设计。通常当你的项目出现这种情况是非常不幸的，出现的原因一般是由于原来的结构不能支持新补充的特性而不得不进行修改。这种重新设计要注意两点，一是时机最好选择在一个大的工作阶段开始时，二是在新结构中尽量移动原有代码而不是编写新代码。
b)底层模块的改进。由于当初编写时的仓猝或考虑不周使得现有模块存在这样或那样的问题并且难于理解，这种情况下进行重构改进是很有必要的。修改的方法通常为对已有代码进行整理和注释，增加模块的封闭性和稳健性。
新技术的运用
a)评估新技术，确定它是否可以给项目带来好处。合适的新技术可以提高产品开发效率和质量，判断某一新技术对你的项目是否合适通常需要派专人或一个小组进行小范围考察和验证。采用新技术的时机最好选择在项目开始时或项目的某些重要阶段开始时，另外千万别忘了培训你的开发人员使用它。
b)避免几种使用新技术的动机。一是为了学习新技术而在项目中使用新技术，这样只能使你的项目变成一个实验田，项目产品最终也成了实验产品。二是不要指望使用新技术能拯救陷入困境的项目，如果一个项目陷入困境，它通常需要的是清晰和稳定，未知的新技术很可能导致更大的混乱。