Blog

Blog

PHODAL

新项目检查清单

无论是向新人介绍项目,又或者是上到一个新的项目,我们都需要事无巨细地列出一个个的关注点。既然如此,那么为什么创建一个检查清单,用来帮助我们一个个的检查一遍呢。

在过去的日子里,经历了几个不同的项目,每个项目都有自己特有的特色。它们往往也包含了一些不同的背景,在成功的交付项目之后,有的还要解决技术难题,有的要的是解决业务难题,有的复杂的部分在于跨团队的协作。正是因为这些情况,也导致了在不同的时候,我们需要着重考虑这些不同的因素,上一个业务复杂的项目,需要重点关注业务问题;来到一个项目团队结构复杂的项目,则重点解决团队复杂问题。

可是呢,对于每个项目来说,它们都存在一些相似的共同点。而这些共同点,即是我们开始一个新项目要做的,也是我们来到一个新的项目时,所需要了解的。于是,当我看到一篇 Tech Lead 的新项目检查清单时,我也想写一个面向开发人员的新项目检查清单

清单设计

在那篇《项目初期的最优技术实践》中,我总结了项目的三步曲:技术准备期、业务回补期、成长优化期。而后在那篇《迈向 Tech Lead 之路》里,我将 Tech Lead 要做的事情,结合到了三步曲中。

为此,我们将一个 Tech Lead 要做事情分为了三个部分,即:Process、People、Programming。 这一点对于新项目的检查清单来说,也有些类似。稍有不同的是,我们需要在其中加入关于业务的维度。此此,我们可以划分为四个维度:

  • Process,关注于从权限管理、获取代码、部署上线、代码集成等的流程。
  • People,连接利益相关者、第三方合作伙伴(组织外)、协作团队(组织内)、团队成员等相关的人。
  • Tech,包含了技术远景、文档(文档即代码)、项目代码、技术栈、软件库管理等。
  • Business,涵盖了业务远景、业务需求、跨功能需求等业务相关功能的需求。

作为检查清单的第一个版本,它的维度设计可能并非那么完善。但是随着时间的改进,我们可以一起把它变得更好。

新项目检查清单

Tech

0. 技术远景

说明:在技术上,我们有什么追求?

1. 文档 - Path to Production - 上线及发布日记 - 项目相关的 wiki 和文档记录

说明:文档即代码——好的文档应该是版本管理的。

2. 架构 - 系统相关的架构图,如 C4Model 方式描述 - 现有的技术栈及其关系

3. 代码库 - 搭建指南。 - 架构决策记录。放置在代码库的 docs/adr 目录中。 - 编辑器配置和代码风格规范。 - 模式和风格指南。 - 分支管理模式。GitFlow 或者 master,或者 Feature Branch。 - 代码提交风格。

4. 测试 - 测试层级。 - 测试策略。

5. 项目演进 - 未来的技术栈 - 系统的演进方案

6. 安全 - 安全标准。安全更重要,还是体验更重要? - 代码中的数据加密。 - 代码安全。

Process

0. Project Process

  • 项目的 Roadmap?时间长短,上线时间等。
  • 项目功能的生命周期。如敏捷中的故事卡工作流
  • 沟通方式?如 IM,邮件,还有敏捷的每日站会,远程会议,Retro 等

1. Path to Development

  • 开发机申请及网络等权限准备
  • 代码库权限管理
  • 编辑器和相关的工具申请

说明:不同的的组织包含自身特别的情况,如 PC 端口、网络权限、代码库权限等的开通都需要一定的流程。

2. Path to Production

  • 上线每一步的流程
  • 相关的关键人
  • 每一步所需要的工具
  • 每一步所需要的流程。如 QA 测试流程,上线流程

说明:代码中的 Path to Production 只是一份说明——针对于开发人员的,而这里的则需要一个更详细的说明。

3. Path to Roll Off

说明:换一个项目时,需要哪些东西?

People

1. 团队成员

  • 非技术问题找谁?
  • 团队成员的技术栈及水平
  • 每个人的技术水平,应该怎么带:Coach(教练式), Pairing(结对式), Teach(教学式)
  • 项目无关的技术,可以找谁一起“娱乐”?
  • 1 to 1 Meetings

2. 利益相关者

  • 了解各个相关者(Level 1)。如作为一个开发人员,大部分时间并不会和利益相关者有直接的沟通。
  • 和相关者保持沟通(Level 2)。适当沟通,可以帮助项目更好地进行。

3. 跨团队协作

  • 相关的合作方有哪些,各自的接口人是谁?
  • 同组织、项目下的其它团队。

4. 用户

  • 用户是谁?我们是否与他们直接接触?
  • 反馈环。一个用户的反馈是如何变成需求的?

Business

0. 业务远景

说明:我们在做什么,我们要去哪里?

1. 业务需求

  • 有没有接近全的需求列表。在一定的时间(如迭代内),需求应该是稳定的。
  • 需求是如何从口头到待办列表的?中间是不是存在不规范的问题
  • 业务是如何进行变更的?

2. 跨功能需求

  • 运行质量。在系统运作时观察到的质量,例如保安性及易用性等
  • 演进质量。软件系统结构及开发过程有关的质量,例如软件可测试性、可维护性、可扩展性、可伸缩性(scalability)等

在线工具

为了方便我未来在新项目使用它,我创建了一个项目来更新这个清单:https://github.com/phodal/new-project-checklist

与此同时,创建了一个 Web 应用来检测。

结论

如果我们的清单不是那么完善,那么作为一个 Tech Lead 又或者是一个额外的关键角色,我们应该完善相关的部分。

未来,我们是否还会有这样的工具,来帮助我们更好地做相关的工具呢?


或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Engineer, Consultant, Writer, Designer

ThoughtWorks 技术专家

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 最新技术分享

标签