- 如果你发现自己在"迭代"项目中出现开发前确认大多数需求，编程前试图创建完整、详细的规格说明或UML模型和设计，那么说明瀑布思维已经在无情的折磨着这个项目了。无论如何声称，这都不是正常的迭代或UP项目。
- 软件通常不是可预知的或可以大规模制造的。因此，变更对于软件项目来说是永恒的，反馈和改写是成功的关键要素。
- UP提倡风险驱动（risk-driven）与客户驱动（client-driven）相结合的迭代计划。这意味着早期的迭代目标要能够识别和降低最高风险，并且能构造客户最关心的可视化特性。风险驱动迭代开发更为明确地包含了以架构为中心（architecture-centric）迭代开发的实践，意味着 早期迭代要致力于核心架构的构造、测试和稳定。因为没有稳固的架构就会带来高风险。
- 采用敏捷方法并不意味着不进行建模，这是错误的理解。
- 建模和模型的目的主要用于理解和沟通，而不是构建文档。
- 只需对设计空间中不常见、困难和棘手的一小部分问题建模和应用UML。简单的设计问题可以推延到编程阶段，在编程和测试过程中解决这些问题。
- 尽可能使用简单的工具。因为不需要耗费精力在精美的文档上。
- 建模的目的是发现、理解和共享大家的理解。因此，不要单独建模，小组成员要轮流画草图，以使每个人参与其中。
- 并行地创建模型。即同时开发类图和交互图，不断交替。
- 使用简单常用的UML元素。
- 所有模型都可能是不准确的，将其仅仅视为一种探索的过程。
- 开发者应该为 自己进行OO设计建模，而不是交给其他编程者实现。瀑布方法才会这样做。
- UP核心思想：短时间定量迭代、进化和可适应性开发。对于整个项目不应有详细的计划。应该制定估计结束日期和主要里程碑的阶段计划，但是不要对这些里程碑详细定义细粒度的步骤。只能预先对一个迭代制定更为详细的计划（迭代计划）。详细计划是由一次次迭代的调整而完成的。
- 不断地验证质量，提早、经常和实际地测试。
- 在适当的地方使用用例。
- 认真管理需求，实行变更请求和配置管理。
UP的四个阶段：
- 初始（Inception）：大体的构想、业务案例、范围和模糊评估。
- 细化（Elaboration）：已精化的构想、核心架构的迭代实现、高风险问题的解决、确定大多数需求和范围以及进行更为实际的评估。
- 构造（Construction）：对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署。
- 移交（Transition）：进行beta测试和部署。
不符合敏捷精神的做法：
- 在开始设计或实现之前试图定义大多数需求。同样，在开始实现之前试图定义大多数设计；试图在迭代编程和测试之前定义和提交完整的架构。
- 在编程之前花费数日获数周进行UML建模，或者认为在绘制UML图和进行设计时要准确完整地定义极其详细的设计和模型。并且，认为编程只是简单机械地将其转换为代码的过程。
- 认为初始阶段=需求阶段，细化阶段=设计阶段，构造阶段=实现阶段（瀑布模型的典型做法）。
- 认为细化的目的是完整仔细地定义模型，以能够在构造阶段将其转换为代码。
- 坚信合适的迭代时间长度为三个月，而不是三周。
- 认为采用UP就意味着要完成大量可能的活动和创建大量的文档，并且认为UP是需要遵循大量步骤的、正规和繁琐的过程。
- 试图对项目从开始到结束制定详细计划；试图预测所有迭代，以及每个迭代中可能发生的事情。
没有评论:
发表评论