技术
0 % 技术 items are ✓
- Path to Production旨在通过可视化的方式来展示项目的上线流程，并优化过程中的瓶颈问题。
- 上线及发布日记
- 项目相关的 wiki 和文档记录
- 开发规范
- 系统相关的架构图如 C4Model 方式描述
- 现有的技术栈及其未来方案
- 搭建指南这份指南应该随项目的代码一起分发。
- 架构决策记录放置在代码库的 ``docs/adr`` 目录中
- 编辑器配置和代码风格规范使用诸如 editorconfig 这样的工具，来统一规范化代码，并采用 Lint 工具来分析代码 。
- 模式和风格指南在项目中融入系统架构，如 Clean Architecture 和风格，并有明显的指引。
- 分支管理模式GitFlow 或者 master，或者 Feature Branch。
- 代码提交风格业务风格或者是开源软件风格？
- 测试策略测试层级, 测试金字塔
- 自动化测试
- 技术风险点即需要提前 spike 调研的内容
- 未来的技术栈
- 系统的演进方案
- 安全标准安全更重要，还是体验更重要？
- 代码中的数据加密
- 代码安全
- 项目质量跟踪
- 代码质量可视化
- 应用质量策略
人
0 % 人 items are ✓
- 非技术问题找谁？
- 团队成员的技术栈及水平
- 每个人的技术水平包含应该怎么带：Coach（教练式）, Pairing（结对式）, Teach（教学式）
- 项目无关的技术，可以找谁一起“娱乐”？
- 1 to 1 Meetings
- 了解各个相关者（Level 1）如作为一个开发人员，大部分时间并不会和利益相关者有直接的沟通。
- 和相关者保持沟通（Level 2）适当沟通，可以帮助项目更好地进行
- 相关的合作方有哪些，各自的接口人是谁？
- 同组织、项目下的其它团队。
- 用户是谁？我们是否与他们直接接触？
- 反馈环。一个用户的反馈是如何变成需求的？
流程
0 % 流程 items are ✓
- 项目的 Roadmap项目 Deadline，关键时间节点，项目规划等
- 项目功能的生命周期如敏捷中的故事卡工作流
- 沟通方式?如 IM，邮件，还有敏捷的每日站会，远程会议，Retro 等
- 开发机申请及网络等权限准备
- 代码库权限管理
- 编辑器和相关的工具申请
- 上线每一步的流程
- 相关的关键人
- 每一步所需要的工具
- 每一步所需要的流程如 QA 测试流程，上线流程
业务
0 % 业务 items are ✓
- 需求列表有没有接近全的需求列表？在一定的时间（如迭代内），需求应该是稳定的。
- 需求管理需求是如何从口头到待办列表的？中间是不是存在不规范的问题
- 业务是如何进行变更的？
- 运行质量在系统运作时观察到的质量，例如保安性及易用性等
- 演进质量软件系统结构及开发过程有关的质量，例如软件可测试性、可维护性、可扩展性、可伸缩性（scalability）等
Report and navigation
- 0/14 ✓ high priority
- 0/3 ✓ medium priority
- 0/2 ✓ low priority
X