zxu
/
its-gen1
1
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity
its-gen1/docs/project/TEAM_CULTURE_AND_DEVELOPMEN...

6.5 KiB
Raw Blame History

智能挂车AI-Box团队文化与开发规范

1. 新成员入门知识

1.1 必须了解的项目背景

  • 项目目标: 开发商用AI-Box Demo，验证智能挂车方案原型
  • 硬件平台: H100核心板（深明奥思Fellow 1芯片，132TOPS算力）
  • 工作温度: -40℃ ~ 85℃ 极端环境适应性要求
  • 尺寸限制: 60mm × 60mm，重量50g的严格约束

1.2 核心配置工具

1.3 团队成员角色

  • 产品经理: 猪小杰 (emb-system) - 需求定义和PRD管理
  • 软件架构师: 孙大圣 (emb-arch) - 技术架构和设计方案
  • 项目经理: 唐小僧 (emb-pm) - 项目协调和进度管理
  • 开发团队: 功能开发和代码实现
  • 测试团队: 质量保证和验证测试

1.4 历史知识获取路径

  1. 飞书共享文件夹: 查看现有需求和设计文档
  2. Gitea仓库: 查看代码历史和设计文件备份
  3. 工作群消息: 了解项目讨论和决策过程
  4. 项目配置规范: 阅读《项目配置目录结构和管理规范》

2. 开发流程规则与设计指导

2.1 双轨配置管理规则

  • 设计文档: 飞书为主，Gitea为备份（24小时内同步）
  • 源代码: Gitea为主存储，必须有完整版本控制
  • 需求变更: 必须同时更新飞书和Gitea两个位置

2.2 代码开发规范

  • 分支策略:
    • main: 生产发布分支（受保护）
    • develop: 开发集成分支
    • feature/*: 功能开发分支
  • 提交规范:
    • 格式: [类型] 描述 (feat/fix/docs/style/refactor/test/chore)
    • 关联任务ID和详细说明
  • 代码评审: 所有代码必须通过Pull Request评审才能合并

2.3 设计指导原则

  • 极端环境适应性: 所有设计必须考虑-40℃~85℃工作环境
  • 资源优化: 在60×60mm/50g限制下做极致优化
  • 多框架兼容: 支持TensorFlow/PyTorch/ONNX/OpenAI API
  • 电源管理: 实现四种电源模式（运行/待机/低功耗/关机）
  • 实时性要求: 大模型推理必须满足低时延需求

2.4 文档编写标准

  • 格式: Markdown为主，便于版本控制
  • 内容: 必须包含接口定义、模块说明、使用示例
  • 更新: 代码变更必须同步更新相关文档
  • 归档: 按照Gitea目录结构规范存放

3. 详细开发计划与风险管理

3.1 项目里程碑计划

第一阶段：需求与架构（1周）

  • 任务: PRD确认 + 系统架构设计
  • 负责人: 猪小杰 + 孙大圣
  • 交付物: 正式PRD + 架构设计方案
  • 风险管控: 需求变更控制，架构评审

第二阶段：核心开发（2周）

  • 任务: 驱动层 + 框架层开发
  • 负责人: 开发团队 + 孙大圣
  • 交付物: 核心功能模块 + 单元测试
  • 风险管控: 技术难点攻关，代码质量保证

第三阶段：集成测试（1周）

  • 任务: 系统集成 + 端到端测试
  • 负责人: 开发团队 + 测试团队
  • 交付物: 集成测试报告 + Bug修复
  • 风险管控: 集成问题快速定位，回归测试

第四阶段：Demo交付（1周）

  • 任务: Demo优化 + 客户演示准备
  • 负责人: 全体团队
  • 交付物: AI-Box Demo + 演示文档
  • 风险管控: 演示稳定性，客户反馈处理

3.2 分工与职责矩阵

任务 产品经理 架构师 项目经理 开发 测试
需求分析 ✓ 主导 ✓ 评审 ✓ 协调
架构设计 ✓ 评审 ✓ 主导 ✓ 协调
代码开发 ✓ 指导 ✓ 跟踪 ✓ 主导
测试验证 ✓ 验收 ✓ 评审 ✓ 协调 ✓ 配合 ✓ 主导
文档编写 ✓ 需求 ✓ 架构 ✓ 计划 ✓ 技术 ✓ 测试
风险管理 ✓ 识别 ✓ 技术 ✓ 全面 ✓ 执行 ✓ 质量

3.3 风险识别与应对策略

技术风险

  • 芯片兼容性问题: 提前进行技术验证，准备备选方案
  • 极端温度稳定性: 增加环境测试，强化错误处理机制
  • 性能不达标: 优化算法，合理分配计算资源

进度风险

  • 需求变更频繁: 建立变更控制流程，评估影响后再实施
  • 人员技能不足: 提供技术培训，安排经验丰富的开发者指导
  • 外部依赖延迟: 提前识别依赖项，制定应急计划

质量风险

  • 代码质量不高: 严格执行代码评审，增加自动化测试
  • 测试覆盖不足: 制定详细的测试计划，确保关键路径覆盖
  • 文档缺失: 将文档作为交付物的一部分，纳入验收标准

3.4 进度管理机制

日常机制

  • 每日站会: 上午9:30，15分钟同步进展和阻塞问题
  • 进度跟踪: 使用飞书表格实时更新任务状态
  • 问题升级: 阻塞问题2小时内升级到项目经理

周度机制

  • 周计划评审: 每周一制定本周详细计划
  • 周进度汇报: 每周五总结本周完成情况
  • 风险评估: 每周识别和评估新风险

里程碑机制

  • 里程碑评审: 每个阶段结束进行正式评审
  • 质量门禁: 达到质量标准才能进入下一阶段
  • 客户同步: 重要里程碑向客户汇报进展

4. 团队协作文化

4.1 核心价值观

  • 客户导向: 始终以客户需求和体验为中心
  • 技术卓越: 追求高质量的技术实现和创新
  • 透明沟通: 信息及时共享，问题主动暴露
  • 责任担当: 对自己的工作负责，对团队目标负责

4.2 协作原则

  • 尊重专业: 充分信任各领域专家的专业判断
  • 主动沟通: 发现问题立即沟通，不等待问题恶化
  • 互相支持: 团队成员互相帮助，共同解决问题
  • 持续改进: 从每个任务中学习，不断优化流程

4.3 沟通规范

  • 工作群: 日常沟通和紧急问题
  • 文档: 正式决策和详细说明
  • 会议: 重要讨论和决策制定
  • 一对一: 敏感问题和深度技术讨论

本规范自发布之日起生效，所有团队成员必须遵守。项目经理负责监督执行，并根据项目实际情况进行适时调整。