迭代0: 启动开发之前，你应该准备什么？-软件工程课程教学网

返回
顶部

修改密码

* 旧密码：

* 新密码：

* 确认新密码：

首页 > 知识摘要 > 开发方法 > 正文

迭代0: 启动开发之前，你应该准备什么？

2023-09-18 15:42:25

来源：极客时间

阅读量：

为什么叫迭代 0 呢？在“敏捷”已经不是新鲜词汇的今天，软件团队对迭代的概念已经不陌生了，它就是一个完整的开发周期，各个团队在迭代上的差别主要是时间长度有所不同。

是这样的，事实上这已经是一种常见的实践了。今天，我们就来谈谈在一开始就把项目准备好的实践：迭代 0。为什么叫迭代 0 呢？

在“敏捷”已经不是新鲜词汇的今天，软件团队对迭代的概念已经不陌生了，它就是一个完整的开发周期，各个团队在迭代上的差别主要是时间长度有所不同。
一般来说，第一个迭代周期就是迭代 1，然后是迭代 2、迭代 3，依次排列。从名字上你就不难发现，所谓迭代 0，就是在迭代 1 之前的一个迭代，所以，我们可以把它理解成开发的准备阶段。既然迭代 0 是项目的准备阶段，我们就可以把需要提前准备好的各项内容，在这个阶段准备好。事先声明，这里给出的迭代 0，它的具体内容只是基本的清单。在了解了这些内容之后，你完全可以根据自己项目的实际情况，扩展或调整这个清单。好，我们来看看我为你准备的迭代 0 清单都包含了哪些内容。
# 需求方面
##  1.细化过的迭代 1 需求
一个项目最重要的是需求，而在迭代 0 里最重要的是，弄清楚第一步怎么走。当我们决定做一个项目时，需求往往是不愁的，哪些需求先做、哪些需求后做，这是我们必须做的决策。迭代 0 需要做的事，就是把悬在空中的内容落到地上。
在需求做好分解之后，我们就会有一大堆待开发的需求列表。注意，这个时候需求只是一个列表，还没有细化。因为你不太可能这个时候把所有的内容细化出来。如果你做过 Scrum 过程，你的 backlog 里放的就是这些东西。
然后，我们要根据优先级从中挑出迭代 1 要开发的需求，优先级是根据我们要完成的最小可行产品（minimum viable product，MVP）来确定的，这个最小可行产品又是由我们在这个迭代里要验证的内容决定的。一环扣一环，我们就得到了迭代 1 要做的需求列表。
确定好迭代 1 要做的需求之后，接下来就要把这些需求细化了，细化到可执行的程度。前面讲用户故事时，我们已经说过一个细化需求应该是什么样子的，这里的关键点就是要把验收标准定义清楚。
所以，我们要在迭代 0 里，根据优先级来确定迭代 1 要做的需求，然后进行细化。
## 2. 用户界面和用户交互
如果你的项目是一个有用户界面的产品，给出用户界面，自然也是要在迭代 0 完成的。另外，还有一个东西也应该在迭代 0 定义清楚，那就是用户交互。
我见过很多团队只给出用户界面，然后，让前端程序员或者 App 程序员根据界面去实现。程序员实现功能没问题，但定义交互并不是程序员这个角色的强项，它应该是需求的一部分。
如何让用户用着舒服，这是一门学问。我们在市面上看到很多难用的网站或 App，基本上都是程序员按照自己习惯设计出来的。现如今，我们可以很容易地在市面上找到画原型的工具，某些工具用得好的话，甚至可以达到以假乱真的地步。如果能再进一步的话，甚至可以用一些模拟服务器的工具，把整个交互的界面都做出来。作为 Moco 这个模拟服务器的开发者，我很清楚，一个原型可以达到怎样的高度。
所以，一个有用户界面的项目需要在迭代 0 中给出用户界面和用户交互。
# 技术方面
## 1.基本技术准备
技术方面，需要在项目一开始就准备好的事比较多。其中有一些是你很容易想到的，比如：在进入迭代 1 开始写代码之前，我们需要确定技术选型，确定基本的技术架构等等。也许你还能想到，数据库表结构也是这个阶段应该准备的。
确实，这些东西都应该是在一个项目初期准备的，也是大家容易想到的。接下来，我来补充一些大家可能会遗漏的。
- 持续集成
对于持续集成，我们通常的第一反应是搭建一个持续集成服务器。没错，但还不够。这里的重点其实是构建脚本。因为持续集成服务器运行的就是构建脚本。那要把什么东西放在构建脚本里呢？最容易想到的是编译打包这样的过程。感谢现在的构建工具，它们一般还会默认地把测试也放到基本的构建过程中。但仅有这些还是不够，我们还会考虑把更多的内容放进去，比如：构建 IDE 工程、代码风格检查、常见的 bug 模式检查、测试覆盖率等等。持续集成还有一个很重要的方面，那就是持续集成的展示。为什么展示很重要？当你的持续集成失败时，你怎么发现呢？一个简单的解决方案是：摆个大显示器，用一个 CI Monitor 软件，把持续集成的状态展示在上面。更有甚者，会用一个实体的灯，这样感官刺激更强一些。在“以终为始”这个模块中，我们提到集成的部分时，只讲了要做持续集成，后面我们还会再次讲到持续集成，和你说说持续集成想做好，应该做成什么样子。
- 测试
-测试是个很有趣的东西，程序员对它又爱又恨。一般来说，运行测试已经成为现在很多构建工具的默认选项，如果你采用的工具没有这个能力，建议你自己将它加入构建脚本。让你为一个项目补测试，那是一件非常痛苦的事，如果在一开始就把测试作为规范加入进去的话，那么在边开发边写测试的情况下，相对来说，写测试痛苦度就低多了，团队成员也就容易遵守这样的开发规范。
把测试当作规范确定下来的办法就是把测试覆盖率加入构建脚本。大多数团队提起测试，尤其是开发者测试，多半想到的都是单元测试和集成测试。把整个系统贯穿在一起的“端到端测试”却基本上交给其他人来做，也有不少团队是交给测试团队专门开发的特定程序来做。在今天的软件开发中，有一些更适合描述这类测试的方法，比如 BDD，再比如 Specification by Example。你可以简单地把它们理解成一种描述系统行为的方式。还有一点做得好的地方是，有一些软件框架很好地支持了这种开发方法，比如 Cucumber。如果你有这种测试，不妨也将它加入构建脚本。
## 2. 发布准备
- 数据库迁移
如果你做的是服务器端开发，多半离不开与数据库打交道。只要是和数据库打交道，强烈建议你把数据库变更管理起来。管理数据库变更的方式曾是很多团队面临的困扰。好在现在已经有了很多工具支持，比如，我最近喜欢的工具是 flyway，它可以把每一次数据库变更都当作一个文件。这样一来，我们就可以把数据库变更放到版本控制工具里面，方便进行管理。管理变更有几种不同的做法，一种是每个变更是一个文件，一种是每一次发布是一个文件。各有各的好处，你可以根据需要，自行选择。发布技术团队擅长做功能开发，但上线部署或打包
- 发布
却是很多团队在前期最欠考量的内容，也是很多团队手忙脚乱的根源。如果一开始就把部署或发布过程自动化，那么未来的生活就会轻松很多。如果你采用的是 Docker，就准备好第一个可以部署的 Dockerfile；如果是自己部署，就编写好 Shell 脚本。其实你会发现，上面提到的所有内容即便不在迭代 0 做，在项目的各个阶段也会碰到。而且一般情况下，即便你在迭代 0 把这些工作做好了，后续依然要不断调整。但我依然建议你在迭代 0 把这些事做好，因为它会给你的项目定下一个基调，一个自动化的基调。日常工作

上一篇：一起练习：手把手带...

下一篇：向埃隆·马斯克学习...

已有0条评论

0/150

提交

热门评论

查看更多评论

目 录

目录