--- title: "敏捷开发实践" description: "以下仅是我本人在敏捷方面的实践经验，仅供参考。。" date: 2020-08-23T15:08:53Z canonical: https://xiaobox.github.io/p/2020-08-23-min-jie-kai-fa-shi-jian/ author: 小盒子 categories: ["行业与思考"] tags: ["缓存", "架构"] source: https://mp.weixin.qq.com/s/omYuwryIoCGrJ55-rYBw5Q license: CC BY-NC-SA 4.0 license_url: https://creativecommons.org/licenses/by-nc-sa/4.0/ --- # 敏捷开发实践 ![Image](https://pub-f29bf2b53160470c9a85250116509a24.r2.dev/post/2020-08-23-min-jie-kai-fa-shi-jian/001-5dadb956.png) **以****下仅是我本人在敏捷方面的实践经验，仅供参考。。** ### ### 方法论先进性问题 来源https://insights.stackoverflow.com/survey/2017#development-practices![Image](002-1152f5f8.png "image.png") ### ### 每日站会（一直在践行） - 昨天为冲刺做了什么 - 今天为冲刺要做什么 - 遇到什么阻碍冲刺的事情了 ### ### sprint == 迭代周期 ==冲刺 每一个迭代周期一般时间固定。 我们在第一次使用Scrum进行项目管理时，并没有看Scrum的规则，从直觉上做了以下几件事，巧合的是，跟Scrum中项目的前期准备sprint0 很多地方是一致的，这让我们后期切到Scrum更加顺滑。 ### ![Image](003-82b8c26a.png "image.png") 我们在准备阶段，分别让 - 前、后端包括UED进行了架构设计，产品设计文档 - 进行了一些技术难点和问题点的调研 - 也有了第一个release的发布计划 - 初步的backlog - 和测试、产品一起同步数据的抓取方案 不过还缺少审核检查表等。（缺的不多） ### ### ### 与产品梳理故事，并对故事的优化级进行了排序 ### ### 将不同故事安排在不同的sprint中 ### ### 评估时间 第一次评估故事和开发时间，是用计划扑克，将故事点和开发人天设置为一样，这样做是为了大家方便理解，先试用一次，并且是我自己将story拆分成task的。从第二次开始，将故事点和开发时间分开评估，由大家一起将story拆分成task,然后由大家认领task，交给最适合做这个task的开发同事。再根据task，每人分别评估开发时间。 ### ### 与测试一起制定测试与开发周期的结合点，这块并没有完全按照scrum的方法做，我的做法是想尽量让测试与开发并行，将测试与开发的工作周期拉开一周，原因是在早期项目的开发节奏较快，任务比较多。 ### 与UED一起制定了UED与开周期的结合点，UED整体早开发一个周期，这样当开发进行到一定任务时，UED已准备好。 ### ### 通过 以上两点 设计、开发、测试 的工作周期能够比较好的咬合在一起，当然实际效果要在日后的工作中持续检验。 ### ### 产品可以持续在backlog中添加待办事项，同事们就可以排sprint来进行一个又一个周期的安排。然后开发的同事们来具体实施完成。 ### ### “鸡”在scrum中不能说话。 鸡可以观察每日Scrum，但不能够参与 参考文章：https://cloud.tencent.com/developer/article/1073880 ### ### 在开发中发现很多细节问题，这些问题都是在需求及设计阶段没有讲清或更新不及时导致的，所以在流程中又加入了评审过程。 评审分两块： 1：需求+设计 ，这部分的评审我们将需求和设计结合起来一起做，因为产品和UED是在开发的前一个周期的，所以时间上是有的，另外，二者合起来对于开发接收的信息更完整，更利于开发的顺利介入。评审时间是在开发拆分story之前。 2：测试评审，具体就是针对测试用例进行评审，主要目的是使开发和测试对所做的东西有一个一致的认识，让不同角度的双方进行一轮信息的交流，达成共识。评审时间是在开发的中前期，具体时间由测试负责人决定。 ### ### 加入了验收人和验收时间，在每一个sprint结束后需要验收人来进行验收，我们并没做全员的成果演示，简化些流程，只做产品的验收。但是会在大版本发布前做一个多功能的成果演示。目的是让全员对产品成果有概念，让参与的同事有成就感。 ### ### 验收人员由产品改为 产品+UED ### ### 在提测前加入了UED走查，这样UED在评审、走查、验收三个环节都有机会介入校验开发的成果是否和设计一致。 ### ### 召开了敏捷回顾会议，通过总结 - KEEP（做的好的，要保持的） - CHANGE（做的不好的，需要改进的） - TRY（可以尝试的） 产出了 action list ,为后面每一个sprint的行动 keep change try 每人每项最多列举三项，然后大家匿名贴在白板上（反过来贴，字在里面）可以消除大家的心理障碍。开会时，主持一张一张的读出来，然后大家发言讨论下，直到最后一张讨论完，总结出ACTION LIST。 ### ### 将bug fix的修改周期和提测周期粒度拆细，由原来的按sprint算，改为在一个sprint中分功能多次提测，在重要sprint中，按照当时项目的情况灵活掌握，具体来说就是:bug按优先级灵活处理,重要的先处理，排进当前sprint故事中，不重要的暂时搁置。 ### 调整了故事和任务的粒度 因为经过了几次迭代后，大家对开发的模式很清楚了，在互相信任的前提下， 我们提高效率，减少了录入整理和频繁的看板操作，将任务的粒度变粗，而故事的任务变粗可以方便拆分成有意义的任务，否则如果故事太细，任务不好拆分，就算拆分了也意义不大。比如一个关注功能，虽然可以拆分成数据库设计、缓存设计、接口契约制定、实现，前端实现，后端逻辑实现，但如果所有故事都这么干，任务量太大和对任务的管理就会比较麻烦。 ### 有关敏捷的思考 敏捷开发不是偷工减料，不是贪图速度。只是因为每一个人相对独立后，减少了沟通成本，从效果来讲变快了。如果在工作中，不做防范（写文档，测试，测试用例），一味降低成本。后来人走了，接不上，成本更高。 ![Image](https://pub-f29bf2b53160470c9a85250116509a24.r2.dev/post/2020-08-23-min-jie-kai-fa-shi-jian/004-683106fa.jpg) 关注公众号 获取更多精彩内容