敏捷开发实践

0 方法论先进性问题：来源https://insights.stackoverflow.com/survey/2017#development-practices

image.png

1 每日站会（一直在践行）

• 昨天为冲刺做了什么

• 今天为冲刺要做什么

• 遇到什么阻碍冲刺的事情了

2 sprint == 迭代周期 ==冲刺

每一个迭代周期一般时间固定。

我们在第一次使用Scrum进行项目管理时，并没有看Scrum的规则，从直觉上做了以下几件事，巧合的是，跟Scrum中项目的前期准备sprint0 很多地方是一致的，这让我们后期切到Scrum更加顺滑。

image.png

我们在准备阶段，分别让

1 前、后端包括UED进行了架构设计，产品设计文档

2 进行了一些技术难点和问题点的调研

3 也有了第一个release的发布计划

4 初步的backlog 

5 和测试与产品数据的抓取方案

不过还缺少审核检查表等。（缺的不多）

3 与产品梳理故事，并对故事的优化级进行了排序

4 将不同故事安排在不同的sprint中

5 第一次评估故事和开发时间，是用计划扑克，将故事点和开发人天设置为一样，这样做是为了大家方便理解，先试用一次，并且是我自己将story拆分成task的。从第二次开始，将故事点和开发时间分开评估，由大家一起将story拆分成task,然后由大家认领task，交给最适合做这个task的开发同事。再根据task，每人分别评估开发时间。

6 与测试一起制定测试与开发周期的结合点，这块并没有完全按照scrum的方法做，我的做法是想尽量让测试与开发并行，将测试与开发的工作周期拉开一周，原因是在早期项目的开发节奏较快，任务比较多。

7 与UED一起制定了UED与开周期的结合点，UED整体昼早开发一个周期，这样当开发进行到一定任务时，UED已准备好。

8 通过 6，7 设计、开发、测试 的工作周期能够比较好的咬合在一起，当然实际效果要在日后的工作中持续检验。

9 产品可以持续在backlog中添加待办事项，同事们就可以排sprint来进行一个又一个周期的安排。然后开发的同事们来具体实施完成。

10 “鸡”在scrum中不能说话。鸡可以观察每日Scrum，但不能够参与 参考文章：https://cloud.tencent.com/developer/article/1073880

11 在开发中发现很多细节问题，这些问题都是在需求及设计阶段没有讲清或更新不及时导致的，所以在流程中又加入了评审过程。评审分两块：

   1：需求+设计 ，这部分的评审我们将需求和设计结合起来一起做，因为产品和UED是在开发的前一个周期的，所以时间上是有的，另外，二者合起来对于开发接收的信息更完整，更利于开发的顺利介入。评审时间是在开发拆分story之前。

   2：测试评审，具体就是针对测试用例进行评审，主要目的是使开发和测试对所做的东西有一个一致的认识，让不同角度的双方进行一轮信息的交流，达成共识。评审时间是在开发的中前期，具体时间由测试负责人决定。

12 加入了验收人和验收时间，在每一个sprint结束后需要验收人来进行验收，我们并没做全员的成果演示，简化些流程，只做产品的验收。但是会在大版本发布前做一个多功能的成果演示。目的是让全员对产品成果有概念，让参与的同事有成就感。

13 验收人员由产品改为 产品+UED

14 在提测前加入了UED走查，这样UED在评审、走查、验收三个环节都有机会介入校验开发的成果是否和设计一致。

15 召开了敏捷回顾会议，通过总结

• KEEP（做的好的，要保持的）

• CHANGE（做的不好的，需要改进的）

• TRY（可以尝试的）

  产出了 action list ,为后面每一个sprint的行动

  keep change try 每人每项最多列举三项，然后大家匿名贴在白板上（反过来贴，字在里面）可以消除大家的心理障碍。开会时，主持一张一张的读出来，然后大家发言讨论下，直到最后一张讨论完，总结出ACTION LIST。

16 将bug fix的修改周期和提测周期粒度拆细，由原来的按sprint算，改为在一个sprint中分功能多次提测，在重要sprint中，按照当时项目的情况灵活掌握，具体来说就是:bug按优先级灵活处理,重要的先处理，排进当前srint故事中，不重要的暂时搁置。

17 调整了故事和任务的粒度，因为经过了几次迭代后，大家对开发的模式很清楚了，在互相信任的前提下， 我们提高效率，减少了录入整理和频繁的看板操作，将任务的粒度变粗，而故事的任务变粗可以方便拆分成有意义的任务，否则如果故事太细，任务不好拆分，就算拆分了也意义不大。比如一个关注功能，虽然可以拆分成数据库设计、缓存设计、接口契约制定、实现，前端实现，后端逻辑实现，但如果所有故事都这么干，任务量太大和对任务的管理就会比较麻烦。

18 有关敏捷的思考

 敏捷开发不是偷工减料，不是贪图速度。只是因为每一个人相对独立后，减少了沟通成本，从效果来讲变快了。如果在工作中，不做防范（写文档，测试，测试用例），一味降低成本。后来人走了，接不上，成本更高。