这次我们来聊聊 “正确的做事”。现在大家都在聊敏捷，虽然都遵循着敏捷的基本理论和价值观，但外在的实践形式不尽相同。有人的地方就有江湖，江湖的一大特色就是流派众多，敏捷实践也例外，KANBAN、Scrum、XP、DSDM（动态系统开发方法）、FDD（特征驱动开发）等等百花齐放。团队在落地实践这些敏捷内容时，表现也各不相同。有的只是蹭概念，有的把大瀑布变成了小瀑布。也有的团队做得很好，真的把 DevOps 实践出自己的道路来，进而提升了团队效率。如何识别自己团队的是否真的在往这方面在走呢？
DevOps 官网上有一篇关于实践 DevOps 的 6 个指标，大家可以参考下。
部署完全自动化：高度关注流程自动化是以 DevOps 为中心的组织应该持有的核心信念。自动化可提高组织的效率并减少错误。
频繁而快速地发布周期：不断部署新功能和错误修复以保持竞争优势，这对组织来说是有益的
使用正确的工具和平台：用于部署功能和修复的工具应该使构建应用程序和测试变得简单易行。通常，你应该能够构建、测试和部署到生产环境而不会出现任何问题。如果你花费大量时间修复发生的任何问题，那么你可能没有合适的工具或流程
有一个持续的反馈循环：你必须有一个持续的反馈循环系统来检测何时何地出了问题。拥有监控流程并在发生错误时快速通知你的软件工具将使修复弹出的问题变得更容易和更快。
开发和运营团队协同工作：开发、测试和 IT 运营团队之间的沟通对于 DevOps 的成功至关重要。这些不同团体之间的合作可确保流程顺利运行。
目标明确：明确定义每个人都在努力实现的目标，团队成员应该了解实现目标需要满足的精确要求，而不是做出假设或任其偶然。
原文地址：https://devops.com/6-signs-youre-doing-devops-correctly/
我会从一个小角度来观察。如上图，表示的是某两个团队在一个迭代周期内（2 周），测试人员发现 BUG 的新增数量。你感觉哪个团队真的敏捷？
团队 1：在迭代的前一周都没有 BUG 产生，直到第 9 天，BUG 猛增。可能的情况有两种：第一周交付的需求质量很高，第二周交付的需求质量很差，才导致了 BUG 增加曲线是这样的。还有一种情况是直到第二周开始，才有需求移测，然后出现 BUG 爆发的情况。你觉得会是哪一种？？所在团队 1 中，你的需求拆分得再好，CICD 做得再好，又有什么用呢？本质上不还是小瀑布么？为了敏捷而敏捷。
团队 2：在迭代的前期，就有 BUG 生成，从侧面说明需求至少可以做到按需测试，需求的拆分也比较到位，测试可以很早就介入针对某个需求进行验证，快速反馈。在迭代的末期，BUG 已不再新增，迭代内容消化得差不多了。测试人员可以抽身为下个迭代做准备，或者进行一些探索性测试。如果每个迭代都能做到类似的曲线。那这样的团队多半是真敏捷的。因为想要按需交付，需求必然会被拆解得比较合理，想要在迭代的第 2、3 天就有东西可提测，CICD 怎么可能做得不好呢？
大家觉得有没道理呢？贴几张我们团队的真实 BUG 曲线图。它们共同的特点就是 BUG 发现的比较早，在迭代的后期基本上没有 BUG。
运用前面两篇需求管理的知识，对需求进行有效地拆分，通过实践 Scrum 中的几个会议，研发团队共同对卡片的内容负责，并按承诺的进行交付，并适当地保障质量。测试人员持续跟进，不断的进行功能测试及集成测试。以保证需求最终的交付质量。那我们是如何做到的呢？需要团队的每个角色（某个团队成员可能会兼任多个角色，人少，没办法）按照共同制定的迭代日历进行按时交付内容。
上图反馈的就是我们的迭代发布日历，什么角色在什么时间段内需要完成什么任务，相对都比较清晰。这是一个比较典型的 Scrum 实践，具体的就不展开说啦。图应该比较好理解。
看板：看板方法的内容相对较少，核心只有三大原则：可视化、限制在制品、管理流动。引入看板不需要改变任何流程，只让流转规则可视化，让每个人的分工透明化，不会给团 队带来新的负担；通过看板的可视化，让团队决策的可视化，当我们关注看板反馈出来的 “味道” 时，很容易让成员理解团队的决策以及要解决的问题；最后，看板活动不需要增加额外的角色。现有的团队成员就足够完成。关于看板，可以参考我之前的文章（关于看板的思考与总结）
*Scrum *是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个 Sprint，每个 Sprint 的建议长度是一至四周。在 Scrum 中，使用产品 Backlog 来管理产品的需求，产品 backlog 是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum 团队总是先开发对客户具有较高价值的需求。在 Sprint 中，Scrum 团队从产品 Backlog 中挑选最高优先级的需求进行开发。挑选的需求在 Sprint 计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为 Sprint backlog。在每个迭代结束时，Scrum 团队将递交潜在可交付的产品增量。
以上文字来源于 Scurm 中文官网。有兴趣的可以看看。
https://www.scrumcn.com/agile/scrum-knowledge-library/%E4%BB%80%E4%B9%88%E6%98%AFscrum.html
结对编程（Pair Programming）是极限编程（Extreme Programming，简称 XP）的十二个实践之一。它指的是两个软件开发人员共用一台计算机其中一个人负责具体细节工作而另一个人关注整体，但这两个人的角色可以随时互换。这是一种轻量、高效、低风险、柔性、可预测、科学而充满乐趣的软件开发方式。结对编程可改进设计质量、减少程序缺陷、降低人员风险、提高技术技能和团队合作精神。结对编程对人员的素质要求较高，比较推崇 TDD。
敏捷的实践还有很多其他的实践方式，如 Lean（精益）、DSDM（动态系统开发方法）、FDD（特征驱动开发）等等，有兴趣的朋友可自行查阅相关资料。
今天就聊到这啦，接下来，我们聊点什么呢？聊聊专项测试那些事，敬请期待。
原文链接：https://mp.weixin.qq.com/s/qIiqc1qchQ8zP0mlVzN06A
