技术

0 % 技术 items are ✓
  • Documentation

      Tools

      • VISION
      • Path to Production旨在通过可视化的方式来展示项目的上线流程,并优化过程中的瓶颈问题。
      • 上线及发布日记
      • 项目相关的 wiki 和文档记录
      • 开发规范
      • TECHNOLOGY
      • 系统相关的架构图如 C4Model 方式描述
      • 现有的技术栈及其未来方案
      • TECHNOLOGY
      • 搭建指南这份指南应该随项目的代码一起分发。
      • 架构决策记录放置在代码库的 ``docs/adr`` 目录中
      • 编辑器配置和代码风格规范使用诸如 editorconfig 这样的工具,来统一规范化代码,并采用 Lint 工具来分析代码 。
      • 模式和风格指南在项目中融入系统架构,如 Clean Architecture 和风格,并有明显的指引。
      • 分支管理模式GitFlow 或者 master,或者 Feature Branch。
      • 代码提交风格业务风格或者是开源软件风格?
      • TECHNOLOGY
      • 测试策略测试层级, 测试金字塔
      • 自动化测试
      • TECHNOLOGY
      • 技术风险点即需要提前 spike 调研的内容
      • 未来的技术栈
      • 系统的演进方案
      • TECHNOLOGY
      • 安全标准安全更重要,还是体验更重要?
      • 代码中的数据加密
      • 代码安全
      • TECHNOLOGY
      • 项目质量跟踪
      • 代码质量可视化
      • 应用质量策略
      • TECHNOLOGY

    0 % 人 items are ✓
      • 非技术问题找谁?
      • 团队成员的技术栈及水平
      • 每个人的技术水平包含应该怎么带:Coach(教练式), Pairing(结对式), Teach(教学式)
      • 项目无关的技术,可以找谁一起“娱乐”?
      • 1 to 1 Meetings
      • PEOPLE
      • 了解各个相关者(Level 1)如作为一个开发人员,大部分时间并不会和利益相关者有直接的沟通。
      • 和相关者保持沟通(Level 2)适当沟通,可以帮助项目更好地进行
      • PEOPLE
      • 相关的合作方有哪些,各自的接口人是谁?
      • 同组织、项目下的其它团队。
      • PEOPLE
      • 用户是谁?我们是否与他们直接接触?
      • 反馈环。一个用户的反馈是如何变成需求的?
      • PEOPLE

    流程

    0 % 流程 items are ✓
      • 项目的 Roadmap项目 Deadline,关键时间节点,项目规划等
      • 项目功能的生命周期如敏捷中的故事卡工作流
      • 沟通方式?如 IM,邮件,还有敏捷的每日站会,远程会议,Retro 等
      • PROCESS
      • 开发机申请及网络等权限准备
      • 代码库权限管理
      • 编辑器和相关的工具申请
      • PROCESS
      • 上线每一步的流程
      • 相关的关键人
      • 每一步所需要的工具
      • 每一步所需要的流程如 QA 测试流程,上线流程
      • PROCESS
      • PROCESS

    业务

    0 % 业务 items are ✓
      • DOMAIN
      • 需求列表有没有接近全的需求列表?在一定的时间(如迭代内),需求应该是稳定的。
      • 需求管理需求是如何从口头到待办列表的?中间是不是存在不规范的问题
      • 业务是如何进行变更的?
      • DOMAIN
      • 运行质量在系统运作时观察到的质量,例如保安性及易用性等
      • 演进质量软件系统结构及开发过程有关的质量,例如软件可测试性、可维护性、可扩展性、可伸缩性(scalability)等
      • DOMAIN

    Report and navigation

    • 0/14 ✓ high priority
    • 0/3 ✓ medium priority
    • 0/2 ✓ low priority
    X