工作中，尤其是采用敏捷方法的团队，看似平常琐碎的小事，团队中每个人的理解可能都不一样，

在我 Thoughtwork 经历的诸多项目中，曾经一个团队整理过一份团队工作方式（way of working）的文档。文档约定了故事卡如何流转，感觉这个实践对工作效率提高非常有帮助。

借鉴于此，整理了一份敏捷团队中常见的实践和方法，除了故事卡的流转外，拓展了站会、codereview等内容，以供新的团队参考。

不过这只是用来帮助团队成员做的更为专业的参考文档，并不是行为准则，特殊情况灵活处理，也不赞成使用惩罚类措施来执行。

故事卡的生命周期

每个团队的故事卡墙上的列有一些不同，但是一般来了说都会有这6个: Backlog，Ready for DEV，In DEV ，Ready for QA ，In QA ，Done，一些团队有系统集成、PO sign off相关的阶段。

下面就来聊聊故事卡的生命周期，在TWI、TWU我们也有相应的课程，但是具体到可以执行的Action，每个团队还是不同的。

我会在后面的内容中尽量采用谁在什么条件下做什么事这种模式描述Way of working。

一般故事卡的流转

1. Backlog 阶段
   • 这里的Backlog指的是当前Sprint上Backlog列，而不是类似JIRA有专门的Backlog模块
   • 理想情况下 BA/UX 可以提前一个迭代开始分析和设计工作，并在下个迭代开始前，BA组织IPM（Iteration Plan Meeting）
   • BA、PM或IM 根据IPM的粗略估点，并结合团队的速率（velocity）放入点数总量合适的故事卡
   • 原则上迭代开始后不加入新卡，影响迭代的Scope
   • Ready for Dev 阶段
   • BA/UX 完成分析工作和设计后，移动故事卡到 Ready for Dev
   • 移动到Ready for Dev的卡需要按照优先级排序，清空assign的头像
2. In Dev 阶段
   • Dev 根据优先级和卡的依赖的关系选择故事卡准备开卡（kick off），开卡前需要了解业务、技术、设计上下文
   • Dev 提前30分钟发起预约开卡，需要通知到 BA、UX、QA （如果分前后端需要通知前端/后端） 预约示例：@王小二 @John 预约开卡 10:00 用户权限
   • Dev 主持开卡，阅读AC
   • BA、UX需要回答Dev和QA的疑问澄清业务和交互方式。业务澄清后，BA需要修改到AC上；设计变动，UX需要修改到设计稿中；QA可以在评论中补充测试用例，提供给Dev结 前自测
   • 开卡完成后。BA 添加相关干系人到评论，便于后期跟踪；Dev 需要移动电子卡、物理卡到In Dev 中
3. Ready for QA 阶段
   • 开发完成后，Dev 需要联系BA QA 结卡（sign off）
   • 结卡前，Dev 需要找UX做一个简单的Desk check 并准备测试数据
   • Dev 提前30分钟发起预约结卡，需要通知到 BA、UX、QA （如果分前后端需要通知前端/后端） 预约示例：@王小二 @John 预约结卡 10:00 用户权限
   • 结卡时，BA和QA验证AC是否满足
   • 不存在缺陷时，可以直接移动到Ready for QA
   • 存在缺陷时，确认是否在业务和设计上清晰无误。如果需要做业务或设计变动，不应该结卡；如果业务和设计达成共识，待Dev修复完成后和QA标记结卡成功
   • 结卡完成后。BA 添加相关干系人到评论，便于后期跟踪；Dev 需要移动电子卡、物理卡到Ready for QA中
4. In QA 阶段
   • QA期间出现缺陷不额外增加bug卡，应就当前故事卡修复
   • Done 阶段
   • 当故事卡被标记为完成，如果在其他故事卡的Scope中或者回归测试中发现缺陷，单独创建Bug卡

特殊故事卡的流转

上面是一般故事卡的流转情况，不过存在一些特殊工作也需要建卡，例如技术债务、Bug、非功能需求等

1. 技术债

   • 团队成员在工作中发现需要重构或修正的问题，以及在codereview中发现的问题，需要建技术卡
   • 原则上所有团队成员都可以建技术债卡，但需要告知TL和BA，并决定是否移动到当前Sprint
   • 如果是正在开发的工作中造成的，不额外建卡
   • 对技术债务分级，优先处理重要且收益高的技术債
   • 技术债视情况估点

2. 缺陷

   • 所有团队成员均可以创建技缺陷卡
   • 缺陷卡应遵从一个缺陷一张卡的原则
   • 缺陷卡应标注重现方式、测试数据、发生的环境等信息
   • 缺陷推荐使用录屏或者录制GIF动画
   • 提交缺陷应告知QA
   • 缺陷卡不估点

3. 非功能需求

   • 故事卡中存在共同需求的可以单独创建一张非功能需求卡，例如文案
   • 非功能需求卡需要链接到故事卡中
   • 非功能需求卡不估点
   • 在开卡和结卡过程中的信息及时汇总到非功能需求中
4. 外部反馈
   • 第三方测试团队或者用户的缺陷报告，首先需要分类、筛选，和BA、QA确认是否在Scope内
   • 对需要处理的问题单独建卡，尝试低环境重现，尽可能保存错误信息和报告人联系方式
   • 如果缺陷信息来自生产环境需要特别标注，禁止使用生产数据进行写操作

站会

• 站会的主持人轮流进行，主持人应提前10分钟准备接入的设备
• 主持人视情况而定选择站会方式，优先选择使用卡墙模式。
• 卡墙模式。使用电子墙或者物理墙，根据卡墙的内容发言，从Done开始到Backlog结束。优点是所有 人不得不集中精力到卡墙上，信息得到很好地同步，不会遗漏信息；坏处是这种方式比较费时间。
• Roll Call 模式，团队成员轮流发言。好处是节省时间，如果工作在多张卡上；可以快速完成站会，坏处是没有集中到故事卡的焦点，注意力非常容易丢失。
• 使用Roll Call 模式时，发言者的更新应提及卡号、故事卡内容、进度和当天的工作计划
• 主持人可以使用‘正’字记录故事卡的实际工作耗时
• PM更新内容需要包括项目健康程度、进度、关键时间节点

估点

• 国内项目和offshore项目不同之处在于，国内项目偏向于按照1人天的工作量作为一个点，而offshore项目偏向于使用复杂度来估点，这里以复杂度为例。
• 使用一个点的故事卡作为估点的基准
• 使用斐波那契数列1 2 3 5 8 来进行估点
• 一旦有故事卡超过了5个点，需要进行拆分
• bug卡的内容已经被普通故事卡覆盖，不进行估点
• 项目中遗留的缺陷（例如其他团队交接的）可以进行估点
• 技术债卡应和TL一起估点，并让BA知晓
• 估点时不计入BA的工作量
• 估点时需要考虑QA的工作量
• 估点时需要一致通过，否则应阐述分歧时，识别工作量的风险 （不使用少数服从多数，是因为估点不同的人可能了解的信息不同，应该及时识别这些信息）

Codereview

Codereview是一个特别值得讨论的话题，当然有大量文章和书籍聊这个。下面是我们目前在codereview中的实践：

• 如果没有特别重要的事务，坚持每日Codereview
• 推荐使用的Jetbrains IDE中提供的版本管理工具，可以筛选提交人和一次性diff当天所有提交，不建议逐commit diff
• Codereview 讨论实现方法、传递业务，避免逐行讲代码和现场debug
• 每人Codereview时间不超过10分钟，时间需自行控制，细节可以私下讨论
• 委托他人记录检查点

Codereview 的检查清单和语言、框架以及业务相关，下面是一份针对Vue技术栈的codereview的清单

• 单词拼写错误（Typo）和无意义、不统一的变量名
• 脏代码，无意义的注释、临时代码、console.log等
• 混用ES5/6语法特性
• 在模板中使用复杂的表达式，应该使用方法代替
• 公共组件和状态关联（Redux、Vuex）
• 嵌套三元表达式
• 大量的switch case或者If语句，应该使用Map代替
• 引入无用的依赖
• 特性滥用
• Mixin
• Ref
• Vuex
• 直接的DOM操作
• 不安全特性
• v-html
• Store 引用修改
• 大量拷贝的代码或其他不合理的设计和实现

上线

软件行业让大家感到压力最大的时候便是上线，也是事故高发地。我经历的项目中上线的方式多种多样，好在没有造成过大的事故。上线怎么严谨都不为过，并且软件行业的复杂性更需要一些检查清单来约束危险的操作。这一点需要向医疗行业和建筑行业学习，可能软件行业上线事故造成的后果要小得多，但是对客户来说也是体现我们专业和高价值的一部分。

1. 上线前
   • 提前发送业务中断信息，包括邮件和悬挂系统通知
   • 准备部署脚本 （例如 shell、ansible）和线上配置文件（例如Nginx配置）
   • 制定上线计划
   • 在低版本演练上线计划
   • 在低版本演练灾备恢复
   • 需要准备好回退计划
   • 有条件的，进行安全测试

2. 上线

   • 执行上线动作至少需要两人pair操作（大量误操作造成事故的案例），可以创建线上会议直播上线操作
   • 停服后需要监控数据流量，确保流量为0后再进行数据、配置和线上软件包的备份
   • 上线失败后使用回退计划
   • 尽量不对线上环境进行手动配置，如果无法实现自动化部署，应添加到上线计划中
3. 上线完成后
   • 使用专用的Health check接口检查系统健康状态
   • 核对线上系统的版本号是否和预期一致
   • 检查服务器负载是否在健康范围内
   • 其他授权下的线上测试
   • 检查日志平台是否有日志到达
   • 检查日志中是否有错误信息
   • 发送业务恢复邮件和系统通知
   • 上线完成后，需要当前线上环境的信息更新文档
   • 新的IP地址、服务器配置信息等
   • 最新线上的版本号、软件包、配置文件
   • 上线计划

Retrospective

Retro 这部分说的东西较少，在项目上 Retro 的形式比较简单，往往使用Well、Less well、Suggestion几个维度。

• Retro 的周期为一个迭代完成或者一个项目完成，也可以不定期进行专项Retro
• Retro 可以提前收集反馈，使用表单工具或者Retro 卡墙 https://funretro.io/
• Retro 环境应该是匿名和安全的
• 使用5-10分钟进行回顾和检查上一次Retro的Actions
• 使用10分钟左右提出反馈，一张卡片（无论是电子还是物理墙）记录一个反馈
• 收集完反馈后应进行归类
• Retro 时间不够无法完全讨论时，使用投票选出优先级高的话题
• 讨论的话题如果需要改进，应该有Action产出
• Action 需要明确的指定 Owner

Retro 的形式除了使用 Well、Less well这种维度划分方式之外，还可以使用其他的方式，例如“Anchors and Engine” 可以用来收集项目的健康状况和风险。

网站 http://www.funretrospectives.com/ 提供了各种各样的Retro形式，包括 “Anchors and Engine”。

On Boarding

• 介绍客户和项目的背景
• 介绍团队成员和项目干系人
• 介绍当前项目进度和关键时间节点
• 介绍团队中使用的文档和工具
• 权限和账号检查
• 业务上下文
• 业务场景
• 用户群体
• 技术上下文
• 技术栈
• 开发工具和环境
• 第三方依赖