记录一下以前的敏捷工作流程

最近在看《Google工作法》,我觉得我们以前的工作方法也有一些不错的地方，在此做个记录，看到的人也许可以做个参考。

敏捷TEAM中的角色：PM（开发经理），PO（产品经理），SM（敏捷教练），开发和测试，DevOps。其中SM和DevOps有可能是其中一个固定的角色的一部分角色，也就是说SM和DevOps并不是专职的，而可能是开发，测试，PM中的一个人兼具这个角色。

敏捷流程中的会议:  迭代计划会，每日早会（其实是每日站会，因一般在早上，就说成每日早会了），迭代演示会，迭代回顾会，需求澄清会，之前我们的这些会议一般是在固定的时间开。迭代从迭代计划会开始，到迭代回顾结束，每日站会是跟进每天的进度，是否遇到了困难需要帮助，是否出现了风险需要应对？需求澄清一般是一周一次，看需求的具体情况了。大概了解了这些之后，接下来我们从用户故事开始。

环境：开发环境（每次提交代码自动构建一套完整的环境），测试环境（当开发的分支merge到master之后由DevOps更新），生产环境（当开发的分支merge到master之后，手工测试和自动化测试都通过后由DevOps更新）

用户故事的两个阶段：计划阶段，实现阶段。

计划阶段是指PO在公司的wiki上创建一个用户故事，描述用户故事的背景，并且给定故事优先级以及交付期限。之后开发人员对这个用户故事进行学习研究并做设计，最长一般是三天时间，他研究的输出是：实现这个用户故事对现有架构的影响，改动范围，要实现的核心数据结构，类图，接口，UI，有哪几种实现方式，每一种的优缺点对比，需求验收条件。当开发人员把这些输出都填入wiki之后，开发人员要找架构师和PO给他做review，以确定对架构的影响会不会有什么风险，应该用哪种方案更合理。PO方面也要确定开发人员的设计是不是他想要的。直到PO，架构师和开发人员达成了共识，流程才进入下一步。

&nb