RUP敏捷开发

Thursday. December 13, 2018 - 1 min

目的

主要是想抛砖引玉，改进我们的软件开发过程

敏捷开发

只要符合敏捷宣言和敏捷原则的方法实践就是敏捷开发

敏捷宣言

• 个体和交互 胜过 过程和工具
• 可以工作的软件 胜过 面面俱到的文档
• 客户合作 胜过 合同谈判
• 响应变化 胜过 遵循计划
• 虽然右项也有价值，但是我们认为左项具有更大的价值。

敏捷开发的原则

1. 快速迭代
2. 让测试人员和开发者参与需求讨论
3. 编写可测试的需求文档 开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上， 而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。
4. 多沟通，尽量减少文档
5. 做好产品原型
6. 及早考虑测试 及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。 较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。

Scrum敏捷方法

强调团队人员的”全栈”能力，每个人都必须参与每一个过程，都应该了解每一个过程使用的技术。

RUP简介

RUP(Rational Unified Process)Rational统一软件开发过程，是一种面向对象的程序开发的方法论。

RUP三大特点

1. 软件开发是一个迭代过程
2. 软件开发是由Use Case驱动的
3. 软件开发是以架构设计（Architectural Design）为中心的

RUP敏捷开发

RUP + 敏捷开发

面向对象的分析和设计（OOAD）流程图

Use Case驱动

prd阶段编写好Use Story -> Use Case

• 谁来维护？

Use Story应该由产品经理编写和维护

Use Case应该由相关的开发人员编写和维护

• 优点

  1. 项目的相关人员都能读懂这些文档，更好地进行相关的工作
  2. 项目的新成员可以通过Use Case快速地了解和上手
  3. 我们是站在用户的角度上分析需求，会更贴近用户真实想法
  4. 如果用例编写得得当的话，我们还可以归纳总结成用户的使用手册（存疑）

必要的用例建立可视化文档

• 领域模型（建立）

• UML的顺序图

• 谁来维护？

原则上来说可视化文档只是辅助我们理解Use Case和代码的对应关系的，如果没有必要（开发人员自己判断）不需要维护

• 优点

  1. 图比晦涩难懂的代码更容易理解

必要的用例编写测试用例（XP推荐的TDD）

• 优点

  1. 我们进行重构的时候可以快速地了解，我们的代码是不是符合用例

参考

• 《Applying UML and Patterns》(美) Craig Larman
• 《编写有效用例》(美) Alistair Cockburn
• RUP和SCRUM方法有什么区别？
• RUP与Scrum的对话

Dawson Lee

A man who loves to watch Korean dramas

如果你在中国大陆地区，则需要连接外网才能进行评论

comments powered by Disqus