产品开发流程 🚀
本指南涵盖了 Ultralytics 产品的产品规划、开发周期和发布流程。
产品理念 🎯
核心原则
- 快速交付,快速学习:2 周迭代周期,MVP 优先方法
- 以用户为中心:打造用户最需要的功能,通过数据进行验证
- 开源第一:公共开发、社区反馈推动路线图
- 性能是一大特色:推理时间低于毫秒,内存占用极小
- 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 测试)
- [ ] 绩效基准达到目标
- [ ] 文件完整准确
- [ ] 更新了更改日志,包含面向用户的更改
- [ ] 迁移指南(如果出现重大变更)
- [ ] 已记录的回滚计划
- [ ] 已配置监控和警报
释放过程:
- 合并到主文件:已批准的 PR 自动合并
- 版本升级:语义版本(major.minor.patch)
- 标签发布:创建带更新日志的 GitHub 发布版本
- PyPI 发布:自动部署到Python 软件包索引
- Docker 更新:构建并推送新的容器映像
- 文档部署:文档网站自动更新
启动通信:
- 博客文章:主要功能的技术深度挖掘
- 社交媒体: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 包已发布
- [ ] 公告已准备好
紧急修复流程
对于严重错误:
- 创建
hotfix/
从最新的发布标签创建分支 - 修复问题,添加测试
- 快速审查
- 立即发布补丁版本
- 如果需要,向后移植到主分支
功能优先级排序 📊
高优先级
- 影响用户的严重错误
- 性能改进
- 安全问题
- 高需求功能(10个以上社区请求)
中优先级
- 生活质量改进
- 新的导出格式
- 扩展的平台支持
- 改进文档
低优先级
- 锦上添花的功能
- 小优化
- 边缘情况处理
已取消优先级
- 针对单个用户的功能
- 过于复杂的实现
- 维护负担重的添加
- 超出核心任务范围
指标与成功 📈
关键指标
- GitHub Stars: 社区兴趣
- PyPI Downloads: 采用率
- Issue Response Time: 支持质量
- PR Merge Time: 开发速度
- 性能基准:速度/精确度提升
功能成功标准
构建前定义:
- 使用指标(下载量、API 调用)
- 性能目标(速度、准确率)
- 用户反馈(GitHub 反馈、评论)
- 采用率(使用该功能的百分比)
沟通交流 💬
内部
- GitHub Issues: 功能建议和错误
- Slack: 快速讨论和更新
- 团队会议: 每周同步优先级
外部
- GitHub Discussions: 社区反馈
- Discord: 用户支持和互动
- 博客文章: 主要功能发布公告
- 文档: 发行说明和指南
产品路线图 🗺️
当前重点
未来领域
长期愿景
- 世界最佳开源目标检测
- 跨所有平台的无缝部署
- 全面的计算机视觉工具包
- 社区驱动的创新
最佳实践 ✅
功能开发
- 从小处着手: 首先是 MVP,然后逐步扩展
- 用户测试: 尽早获得反馈
- 性能至上: 从一开始就进行优化
- 完善文档: 在构建时编写文档
发布管理
- 彻底测试: CI + 手动测试
- 清晰的变更日志: 变更了什么,为什么重要
- 平稳升级: 尽可能向后兼容
- 快速修复: 不要让错误滞留
社区参与
- 快速响应: 在 24 小时内回复问题
- 透明: 分享路线图和决策
- 感恩: 感谢贡献者
- 包容: 欢迎所有技能水平的人
资源 📚
📅 1 个月前创建
✏️ 9 天前更新