交付时间细分

​

什么是交付时间细分

​

我们如何计算

• 编码时间：活跃开发时间（第一次提交到最后一次提交）
• 拾取时间：最后一次提交和创建 PR 之间的时间
• 审查时间：从 PR 创建到合并的时间

• 第一次提交之前的时间（规划、设计）
• 合并后的时间（部署等）
• 失败或放弃的 PR

编码时间 = (最后提交时间) - (第一次提交时间)
拾取时间 = (PR 开启时间) - (最后提交时间)
审查时间 = (PR 关闭时间) - (PR 开启时间)

​

为什么重要

• 编码时间：显示开发效率
• 拾取时间：揭示工作流程瓶颈
• 审查时间：指示审查过程的有效性

​

如何改进

​

减少编码时间

• 清晰的需求：确保开发者了解要构建什么
• 更小的功能：将大型更改分解为可管理的部分
• 结对编程：协作更快地解决复杂问题
• 代码重用：利用现有模式和组件

​

减少拾取时间

• 立即创建 PR：完成代码后立即创建 PR
• 工作流程自动化：使用工具简化 PR 创建
• 清晰的完成定义：确切知道代码何时准备就绪
• 减少上下文切换：专注于一次完成一项任务

​

减少审查时间

• 审查指南：为审查者设定清晰的期望
• 自动化检查：使用工具在审查前捕获问题
• 审查轮换：在团队中分配审查工作负载
• 快速响应：及时响应审查评论

​

常见瓶颈

​

编码时间

• 不清晰的需求：开发者不知道要构建什么
• 复杂的功能：太大或太复杂的更改
• 技术债务：围绕现有代码问题工作
• 依赖关系：等待其他组件或服务

​

拾取时间

• 工作流程低效：减慢流程的手动步骤
• 上下文切换：在多个任务之间移动
• 缺乏自动化：手动 PR 创建和设置

​

审查时间

• 大型 PR：太大而无法快速审查的更改
• 审查者可用性：没有足够的人可以审查
• 不清晰的更改：难以理解的 PR
• 审查积压：太多 PR 等待审查