来自一位网友的对于敏捷开发实践的评论

来自一位网友的对于敏捷开发实践的评论

原图：

目前参与过公司的项目，公司专业从事敏捷开发，也比较成熟，可以分享下其中的细节。

1、概念，可以参考敏捷宣言，强调适应变化，四句指导

个体和互动 高于 流程和工具（动员每个人积极交流，相互之间可以 battle，头脑风暴）；
工作的软件 高于 详尽的文档（好的代码是不需要注释和文档的，顶多有一些规范指南一类的在线协作文档）；
客户合作 高于 合同谈判（真心实意为客户创造价值，而不止于眼前的功能交付，这个很难，由此还专门有一个角色去 control 这件事）；
响应变化 高于 遵循计划（计划是赶不上变化的，随时改需求随时变动迭代计划，有迭代的概念）；

基于于右边，而更注重左边的价值，并不是说完全抛弃传统的瀑布式开发。

2、人员架构

因为公司没有所谓的各种领导，这里就说下交付组里，我所见的一些角色，也是每天在一起工作的小伙伴：

PM：项目管理者，这里不是项目经理，负责和客户签合同，各种会议的组织者，没有项目经理那种权利
BA：业务分析师，专门和客户谈需求，超强的交流和控制客户的能力，几乎每天都和客户泡在一起开会过需求，疯狂开会，驱动客户（我们组的BA是御姐型的，气场极强）
QA：测试人员
DEV：开发人员，其中有掌握技术话语权的 TL

PO：比较特殊，是客户某的部门领导人，一般和 PM 单独沟通，几乎没出现过，网友一样的存在

一个团队一般 1 PM、1 BA、1 QA 、6 DEV (三前三后，至少两个TL)

这里没有 MS，所以每个人都是 SM，233333

IPM：迭代会议，每个迭代开始之前开一次，主要是排下个迭代的故事卡，并给每张卡估点，我遇到的是两周一个迭代（一般会有卡墙，有物理的，也有线上的）
Showcase：开发成果展示，每个迭代结束开一次，一般是BA或QA给客户演示上个迭代做的功能，当然也是优化和新改动提得最多的时候
Retro：回顾会议，每个迭代结束开一次，讨论上个迭代团队做得好和做得不好的事（不是针对和人，不含人身攻击），并给出改进方案，在下个迭代中执行
Stand Up：每天早上的站会，大家站成一圈，一般由 PM 主持，轮流阐述自己的昨天工作内容和工作进度，和今天要完成的工作，以及遇到的一些问题，及时反馈出来（我们组有个小龙猫的毛绒玩具，大家挨个传递，挨个阐述）

每天还有 Code Review，动态安排时间，我们团队一直坚持，刚开始是前后端一起过昨天每个人写的代码，后面时间太长，就前后端分开。大家一起来找茬，你的命名和代码逻辑划分，代码风格，都有个能会被挑刺。在相互找茬的过程中，坚持下去，对个人的成长有很大很大的帮助。

4、写代码

DEV 要做开发，就要先领故事卡，俗称开卡，自己选好一张故事卡，拉上BA和QA去过其中的细节，理清细节，然后才能上手开发，开发完后再拉上BA和QA去结卡，检查卡中的功能是不是都完成了，有问题就被打回去改，直到BA和QA觉得完善了，才能关卡。。。

代码质量要求很严格，遵循 TDD，前端有 lint，有单元测试（不能偷懒，而且有覆盖率要求），有 e2e 测试（必须写，和QA一起看），当你的代码走过这三个流程，提交到公共仓库，CI 自动构建会拉你的代码，再走一遍测试（挂了就要修代码），然后自动发布新版本到 Dev 环境。

你以为这就完了？还有代码嗅探器，时刻在扫描代码仓库，有两个重复的函数不行、重复率太高不行、使用了骚代码去做类型转换之类的不行、空间内有命名重叠不行。。。。这一套下来，再加上 code review，菜鸟开发每天一半的时间都在改昨天的代码。

项目还有规定，CI 不能红过夜，当天的问题当天要修好。。。。

以上这些，小公司就别说什么没时间，项目吃紧，然后就没做，自求多福吧