关于例会的实践计划

这目前对我来说是一件很头疼的事情，我不知道如何开始做这件事。这是需要足够的力量去支撑的，且通常情况下，大家会把例会当做无关紧要且浪费时间的形式主义事务。所以后续估计会找领导协商，找到切入点。

敏捷开发强调的例会通常以下几种：

1. 计划会议： 通过产品与研发团队充分交流得出计划。【注意，敏捷模式中要求每个人都对所有模块熟悉，可做到人员顶替】
2. 每日站会：主要是大家集中在一起汇报下进度和工作计划，并重点阐明当前需要什么帮助才能加快进度
3. 验收会议：通过展示自己的工作成果来验证自己已经完成了工作。【这是一个有价值的东西，避免各种打马虎眼】
4. 回顾会议：对当前周期内的行为进行回顾，并提出一些优化方案进行改进。

回顾会议与每日站会

后续主要是想执行回顾会议，因为计划会议和验收会议对于当前情况来说，无法执行【大家对功能模块及业务不够熟，无法互相顶替，更无法知道如何验证自己手头的工作】。

回顾会议是采用自下而上的引导。从测试流程开始，让大家集思广益，如何提高测试效率，减小测试周期。 可能会从代码质量，自动化测试，持续集成等方面着手。有了方案之后确保其执行即可。回顾会议主要是要调动大家的积极性。

针对于每日站会，这对我来说是一种很尴尬的会议。我倾向于对团队灌输有问题及时反馈及时沟通的想法，但每日站会又确实能让我快速掌握团队情况，关注到重要的问题。因此该会议会考虑进行试验，但总而言之，这个会议是越短越好。

关于敏捷开发中的工具支持（快速失败）

这个标题起得很模糊，我想不到更好的标题。敏捷开发的需要非常多的工具支持，如脚手架，持续集成涉及到的所有工具，单元测试（甚至可以说测试驱动开发乃至于领域驱动开发），团队管理工具等等等等。但所有的工具都是为了一点-fast-fail（快速失败）。这是一个非常简单但用途非常广的概念。《持续交付2.0 业务引领的DevOps精要》的长篇大论都可以浓缩成快速失败。

快速失败指的是我们用最快的方式尽早得到该思路不可行，需要换个思路的方式。就跟代码抛异常一样。这是需要我在团队中灌输的。产品做需求，如何尽快验证需求可行性，代码研发，如何尽快验证功能可行性，做测试，如何尽早验收功能。这都是不断思考的，由此才衍生出了必不可少的单元测试，集成测试，持续集成，devops套路等等广为流传的东西。

该部分的计划会从研发开始。需求审核→代码封装→单元测试→持续集成

需求审核：验证需求合理性，验证需求可行性。 不行马上打回给产品审核，切记拿到需求就做。

代码封装：封装代码是一个简单的事情，此处要强调封装的代码推广使用。我会建一个通用代码库及组件库，有更新的内容及时告知全员，并鼓励团队做代码封装且维护。

单元测试：这是一个比较遥远的事情了，因为业务开发通常意味着变动，但也有一些场景可做单元 测试，如接口入参测试，公用函数测试。 测试是持续集成中最重要的一环，没有单元测试，集成测试只是走一个过场。

持续集成：这是一个更遥远的事情了，实施起来其实很简单，但让他有意义却很难了。但这个持续继承套路（git+jenkins+k8s）还是要趁早做的，因为他确实缩短了部署周期。

这一篇和上一篇就是我对敏捷开发所有的理解，以及实施计划了。敏捷开发核心无非两个点，精益管理及快速失败。

peace and love