什么周期模型最基础，最核心的就是瀑布模型。所有的增量，迭代，螺旋，原型等各种生命周期模型都来源于瀑布模型。如在敏捷方法论中常见的迭代模型，在每一个迭代周期中就是一个小瀑布模型，如果连瀑布模型都用不好这很难用好其它什么周期模型。生命周期含义就是产品演化和事物的发展有气必然的阶段和顺序，因此各种什么周期模型都不能跳过程。在这里再解释下TDD测试驱动开发，为什么没有设计开发就已经在测试了，注意这里不是在执行测试，而是在写测试用例，并通过测试用例来进一步明确需求的How to Test部分的内容，这和测试里面的V模型是一致的。

　　需求分为业务用户需求和系统软件需求两个重要阶段，当时我们做系统的时候往往是直接进入到了软件需求。用户需求阶段重点是业务建模和流程建模，重点是搞清楚业务主题域和业务场景;软件需求阶段重点是需求用例分析和功能分析，重点是搞清楚需求细节以支持可实现性。在这里前面关于SERU需求方法论的博文有专门的描述，总之要重视业务建模环节，不要跳过该环节直接进入到了软件需求，导致功能实现不能真正解决业务问题。

　　需求要条目化，在FDD和SCRUM等各种敏捷方法论中都可以看到需求条目化的例子。条目化的需求即用户故事，是实现业务价值的一个最小单位，是业务目标驱动的需求，条目化的需求为后续项目细粒度的进度跟踪和进度可视化打下了坚实的基础。同时条目化的需求方面了后续一系列需求，实现和测试的追踪过程。

　　不要想着需求不变化，或者把项目延期的责任归咎到需求变化大上面。软件项目经理应该更多考虑如何更好的去适应变化，如果让需求变化导致的影响最小。这就涉及到需求优先级和迭代内容划分，架构可扩展性等一系列内容。举例来说，如我们装修房屋，最后主人要求在卧房床边增加一个壁灯，这个时候我们如果原来预留了插座则该新需求带来工作量是相当小的，反之如果当时什么都没有考虑，这可能影响到已经完成的管线等隐蔽工程，这个代价就会相当大。但是如果到处留插座带来的管线工程成本和复杂性也是相当大的，因此项目经理就应该和架构一起来考虑这个问题，如何去适应变化。

　　原型法+迭代的短周期版本是为了适应变化的重要方法和工具，通过原型法可以更好的和用户沟通和确认需求，通过短周期迭代可以尽快的拿出系统的第一个正式版本，让用户尽快使用系统，并在使用基础上挖掘更进一步的需求。

　　对于架构，一定要注意的就是软件项目经理往往还需要承担部分的架构设计和评审的职责，对于全新的产品必须进行架构设计而不适合采用敏捷开发的方法论。因为架构的重点就是通过分解和组件化将复杂的系统实现简化，最后再按照预ding的接口进行集成。架构师不适合多人共同进行，架构最好掌握在一个人手中以保证概念完整性，即我们所的即时架构存在一定的问题也可以保证整体上还是一致的而不是五花八门。对于数据库设计应该纳入到架构设计的内容，架构的重点就是通过分解进行系统组件化，在组件化后又开始考虑复用，同时考虑各个组件间的接口和集成。对于全新产品的开发架构起到至关重要的作用，架构不仅仅是要熟悉纯技术架构，同时还需要熟悉该系统所在的业务领域知识。原来我们谈的系统分析员更应该是业务架构+技术架构。

　　源代码就是设计，对这句话我还是相当认同的，特别是在架构设计和数据库设计完成后，真正的详细设计内容完全可以体现到源代码的代码框架上面。在这种情况下没有概要设计，概要设计是一个很模糊的词语，简化的流程应该是将概要设计中重要的内容升级到架构设计中，将概要设计非核心内容下移到详细设计和源代码中。写代码的过程就是设计的过程，当时往往很多程序员是没有理清设计思路就开始写代码，写到哪里算到哪里，这是一个很不好的习惯。要知道设计的中间环节越多，这些中间输出的一致性就越无法保证。而我们花费了大量时间编写的设计文档，到了最后往往自己都不会再拿出来看一眼。

　　对于测试而言，在敏捷方法论中对传统的测试V模型有很大的改进。即我们所的每日构建和冒烟测试，以达到敏捷里面谈的持续集成的作用，只有持续集成才谈得上开发进度的可视化。通过冒烟测试是很好的建议开发人员工作是否完成的方法和工具，在2009年我曾经翻译过软件开发中的进度游xi一系列的文章，其核心就在讲没有得到最终验证的进度都是虚假的进度。一项工作完成了90%花费了一个月，而完成剩余的10%往往还会花费掉你一个月的时间，这在软件开发中是经常出现的场景，即个人对进度的评估是不合理的。

　　评审是贯彻了软件生命周期模型的重要过程，重点的评审包括计划评审，需求评审，架构评审和代码评审。评审的目的不仅仅是提前发现和纠正缺陷，同时要认识到通过评审是团队共同学习的机会，是团队形成通用词汇表的重要方式。

　　交互设计和易用性，往往是软件产品成败的另外一个关键内容，易用性过程贯彻整个软件生命周期模型。从前期的UI设计，交互流程设计，用户行为分析，到后期的易用性测试和易用性评估改进等。这些都是为了真正让产品符合用户的需要。需求挖掘和需求开发是解决能用的问题，而易用性才能够真正的解决产品好用的问题。