跳至内容

产品开发工作流程 🚀

本指南涵盖以下方面的产品规划、开发周期和发布流程 Ultralytics产品的产品规划、开发周期和发布流程。

产品理念 🎯

核心原则

  1. 快速交付，快速学习：2 周迭代周期，MVP 优先方法
  2. 以用户为中心：打造用户最需要的功能，通过数据进行验证
  3. 开源第一：公共开发、社区反馈推动路线图
  4. 性能是一大特色：推理时间低于毫秒，内存占用极小
  5. API 优先设计：开发人员喜爱的简单、直观的 API

发展价值观

  • 偏向于行动：在数天内完成原型设计，在数周内发货，而不是数月
  • 数据驱动决策：GitHub 星级、PyPI 下载量、Discord 民意调查为优先事项提供指导
  • 最小可行产品：快速发布 80% 的解决方案，迭代至 100%
  • 持续部署：主分支始终处于生产就绪状态
  • 彻底透明：公开路线图、开放指标、社区意见

功能开发生命周期 🔄

1.发现与规划（第 1 周）

通过以下方式确定需求

  • 用户反馈：GitHub 问题（投票）、Discord 投票、社区调查
  • 使用分析：功能采用率、API 端点指标、错误日志
  • 性能数据：基准测试结果、推理时间、内存使用情况
  • 竞争分析：跟踪竞争对手发布的信息和市场趋势
  • 内部狗粮化：使用我们自己的工具，找出痛点

对照评估：

  • 用户影响：有多少用户受到影响？痛苦程度（1-10）？收入影响？
  • 技术可行性：工程工作量（S/M/L/XL）？依赖性？风险？
  • 战略调整：提升YOLO11 领导力？支持关键垂直领域？
  • 资源可用性：团队能力？相互竞争的优先事项？时间安排？
  • 竞争紧迫性：竞争对手会先发货吗？锁定风险？

产出：按优先顺序排列功能积压，附带工作量估算和用户影响评分

2.设计和规范（第 1-3 天）

对于主要功能（>2 周工程时间）：

  • 设计文档：问题陈述、建议的解决方案、考虑过的替代方案、成功指标
  • 技术规范：应用程序接口设计、架构图、数据模型、边缘案例
  • 成功标准：量化指标（速度、准确性、采用率）和用户反馈目标
  • 风险评估：技术风险、依赖性、回滚计划
  • 团队审查：工程、产品和主要利益相关者的反馈意见

For small features (<1 week engineering time):

  • GitHub 问题：清晰的问题描述、建议的方法、验收标准
  • 快速讨论：与相关工程师进行 15 分钟的同步讨论
  • 去/不去：经理批准进行

产出：经批准的规格，包括明确的范围、成功指标和时间表

3.实施（冲刺执行）

冲刺计划（每两周一次）：

  • 冲刺目标：每个冲刺有一个明确的目标
  • Task breakdown: Split features into <1 day tasks
  • 能力规划：会议账户、公关审查、支持
  • 依赖性：确定阻碍因素，与其他团队协调

每日执行：

  • 晨会（15 分钟）：昨天的进展、今天的计划、阻碍因素
  • 专注时间：深入工作 4-6 小时，尽量减少会议
  • 公关审查：在 4 小时内审核队友的 PR
  • 日终更新：Slack 进度更新、移动票据

开发最佳实践：

  • 功能标志：部署暗色，逐步启用
  • 测试覆盖率：在发货前编写测试（目标覆盖率 >80）
  • 文档：在与代码相同的 PR 中更新文档
  • 性能：基准之前/之后，无回归
  • 安全性：运行安全扫描，立即修复关键问题

遵循公关流程和代码标准的详细开发工作流程。

4.审查和质量保证（与实施并行）

代码审查（所有 PR 都需要）：

  • <24 hour response time: Senior engineers prioritize reviews
  • 质量检查：代码正确性、测试覆盖率、性能影响
  • 安全审查：自动扫描 + 人工审查敏感代码
  • 文档：确认文档已更新，示例已运行
  • 需要批准：合并前需要 1 个以上高级工程师批准

质量保证过程：

  • 自动测试：在每次提交时运行单元测试、集成测试和 E2E 测试
  • 手动测试：质量保证工程师验证关键用户流程
  • 性能测试：对照基准线进行基准测试，标注回归情况
  • 跨平台：在CPU、GPU 和边缘设备上进行测试
  • 用户接受度：针对主要功能对部分用户进行 Beta 测试

迭代周期：

  • 立即处理反馈，不要积累技术债务
  • 更改后重新测试，验证修复不会破坏其他功能
  • 更新工作票的进展情况，随时向利益相关方通报

5.发布和启动

释放前清单：

  • 通过所有测试（单元测试、集成测试、E2E 测试）
  • 绩效基准达到目标
  • 文件完整准确
  • 更新了更改日志，包含面向用户的更改
  • 迁移指南（如有重大变更）
  • 记录回滚计划
  • 监控和警报已配置

释放过程：

  1. 合并到主文件：已批准的 PR 自动合并
  2. 版本升级：语义版本（major.minor.patch）
  3. 标签发布：创建带更新日志的 GitHub 发布版本
  4. PyPI 发布：自动部署到Python 软件包索引
  5. Docker 更新：构建并推送新的容器映像
  6. 文档部署：文档网站自动更新

启动通信：

  • 博客文章：主要功能的技术深度挖掘
  • 社交媒体：X、LinkedIn、Discord 公告
  • 电子邮件通讯：通知 50K+ 订阅者
  • 发布视频：YouTube 复杂功能教程
  • 社区参与：监控 Discord/GitHub，回应反馈意见

发射后监测（最初 48 小时）：

  • 观察错误率、延迟、采用指标
  • 在 4 小时内对关键错误做出响应
  • Hotfix process for breaking issues (<24 hour turnaround)
  • 收集用户反馈，优先考虑速赢项目

成功衡量（前两周）：

  • 采用率：升级的用户百分比
  • 使用指标：应用程序接口调用、功能参与
  • 性能推理速度、内存使用量
  • 用户反馈：GitHub 反应、Discord 投票
  • 错误报告：关键问题与次要问题的比例

发布流程 📦

版本控制

语义版本管理： MAJOR.MINOR.PATCH

  • 主要：突破性变化
  • 小：新功能，向后兼容
  • 补丁：错误修复

例如 11.0.0 → 11.1.0 (新功能）→ 11.1.1 (错误修正）

发布时间表

  • 小版本：每 2-4 周发布一次
  • 补丁发布：根据需要进行重要修复
  • 重大版本：引入破坏性更改时

释放清单

  • 所有 CI 测试通过
  • 文件更新
  • 更新了更新日志
  • 版本号调整
  • 创建了 GitHub 版本
  • 已发布的PyPI 软件包
  • 编写公告

补丁程序

对于关键错误：

  1. 创建 hotfix/ 分支从最新版本标签
  2. 修复问题，添加测试
  3. track 审查
  4. 立即发布补丁版本
  5. 如有需要，可返回主系统

特征优先级 📊

高度优先

  • 影响用户的重大错误
  • 性能改进
  • 安全问题
  • 要求较高的功能（10 个以上社区要求）

中优先级

  • 提高生活质量
  • 新的导出格式
  • 扩展平台支持
  • 改进文件

低优先级

  • 值得拥有的功能
  • 小幅优化
  • 边缘案例处理

未列为优先事项

  • 单用户功能
  • 过于复杂的实施
  • 维护繁重的新增项目
  • 超出核心任务范围

衡量标准与成功 📈

关键指标

  • GitHub 之星社区兴趣
  • PyPI 下载：采用率
  • 问题响应时间：支持质量
  • PR 合并时间：开发速度
  • 性能基准:速度/精确度提升

功能成功标准

先定义，后建设：

  • 使用指标（下载、API 调用）
  • 性能目标（速度、准确性）
  • 用户反馈（GitHub 反应、评论）
  • 采用率（使用功能的百分比）

交流 💬

内部

  • GitHub 问题：功能建议和错误
  • Slack：快速讨论和更新
  • 团队会议：每周同步讨论优先事项

外部

  • GitHub 讨论：社区反馈
  • Discord：用户支持和参与
  • 博客文章：主要功能公告
  • 文档：发布说明和指南

产品路线图 🗺️

当前重点

即将推出的领域

长期愿景

  • 世界上最好的开源对象检测
  • 跨所有平台的无缝部署
  • 综合计算机视觉工具包
  • 社区驱动的创新

最佳做法 ✅

功能开发

  • 从小做起：先做 MVP，再扩展
  • 用户测试：尽早获得反馈
  • 性能第一：从一开始就进行优化
  • 做好文档：在构建过程中编写文档

发布管理

  • 彻底测试：CI + 人工测试
  • 清除更新日志：更改内容及原因
  • 顺利升级：尽可能向后兼容
  • 快速修复：不要让错误缠身

社区参与

  • 反应迅速：24 小时内回复问题
  • 透明：共享路线图和决策
  • 感谢：感谢贡献者
  • 包容性：欢迎所有技能水平的人

资源 📚



📅创建于 6 天前 ✏️已更新 6 天前
翔宇