什么是迭代开发？

在敏捷开发中，强调的是增量交付的开发模式，即在很短的时间内开发出一些功能，然后交付给客户或产品负责人，每一次的交付就是需求的修正，把修正的需求放到下一个迭代中，以此反复，最后拿到的成品距离客户想要的基本八九不离十。

在传统模式下，每一次先历经一个很长时间的开发周期，或许1年，或许6个月等等，基本上每一次的交付都会引起大改动，或者推翻重做。

就好比你边玩手机边走路，传统模式就好比一路看着手机一直走，等突然抬头的时候，你走的方向和你的目标已经偏离了很长一段距离，那你不得不推翻重新走；敏捷开发模式就好比走两步抬头看看方向是否正确，发现方向的偏差也不过那一两步，很容易修正。

如何安排迭代周期

一般来说，每一次迭代是2周，这是最常见的，具体的自己学习《敏捷开发》相关的知识。从某个版本的截止时间来反着推算，比如今天是2019年4月1日，项目v1版本的上线时间是2019年7月1日，总共是3个月的时间，那就差不多需要6个迭代周期（1个月是2个迭代）。

回到 Azure DevOps 中，我们需要事先配置好迭代。

先点击【项目设置】，然后【项目配置】



根目录是不让修改的，就是你项目的名称。它是一个父子级关系。


先配置好 1.0 版本的起止时间

在这里插入图片描述
然后添加你的迭代数量，然后再给每个迭代设置一个起止日期，鼠标移动到迭代上，旁边会有一个【设置日期】
在这里插入图片描述
在这里插入图片描述
系统会根据你上一个迭代设置的日期周期，自动推算你这个迭代的周期，比如是2周
在这里插入图片描述
他自动给我推算出起始日期是从15号开始的。当你选择好开始日期后，会自动给你填充结束日期。

在这里插入图片描述
现在都设置好了。

这个日期在功能上并没有什么作用，但它会在统计上自动计算出速率、燃尽图、累计流图等等，这些图表都是帮助团队更好的提高效率。

配置团队（区域）

很多时候，我们要完成一个项目可能需要几个团队来配置，比如 Web 团队，IOS 团队等等
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述
把刚才项目中配置好的迭代，从这里一一匹配出来，否则你在产品积压（backlog）里看不到你配置的迭代
在这里插入图片描述
然后我们回到【产品积压（backlog）】
在这里插入图片描述
右边就可以看到这些迭代了，这里称之为【规划】。

当你有足够多的故事时，你就要开始考虑哪些故事要放在哪个迭代去做，只需要拖拽到迭代中即可。
在这里插入图片描述
或者打开某个任务时
在这里插入图片描述
开始迭代的工作

当这个迭代开始了，点击【冲刺(Sprint)】
在这里插入图片描述
在这里插入图片描述
这里就列出了当前迭代的所有故事，以及相关任务。
如何看冲刺面板

冲刺面板是用来 跟踪故事下的任务的进度 的。在敏捷开发中，完成一个故事可能会细分为各种各样的任务，比如需要设计的图纸，前端页面，服务端逻辑，数据库的设计等等。为什么会有这样的规则在里面呢？因为用户故事必须是独立的，请参考《故事与估算》里“如何写用户故事”。在开发过程中，某些任务是需要有前置条件的，比如前端必须得有设计图才可以做，服务端可能需要先完成数据库的设计才可以开始编码。

在这里插入图片描述
通过这样的方式就能知道，一个故事需要哪些人员的协助才可以完成。
分任务的工作是由这个故事的所有人来决定。

好啦，敏捷中的每日站会也可以使用该面板来可视化跟踪任务的进度，可以更新每一个任务的剩余时间
在这里插入图片描述
这是剩余时间，表示这个故事还剩下多少小时可以完成。
总结

通过这一个章节，基本就能掌握 Azure Board 的使用情况了，接下来就需要你们自己去学习有关敏捷开发的知识体系，毕竟 Azure Board 是基于敏捷开发的工作方式的一套产品。当然目前可能用的最多的是 JIRA，随着你对敏捷开发的深入理解，你会发现 JIRA 已经慢慢不适合了，这也是我转向 Azure Board 的原因，其次自然是收费问题啦，JIRA 配套不是一般的贵。