【新项目检查清单】帮你规范开发流程

prtyaa 2023-12-25 14:00:54  65372

分类专栏：资讯

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

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

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

清单设计

在那篇《项目初期的最优技术实践》中，我总结了项目的三步曲：技术准备期、业务回补期、成长优化期。而后在那篇《迈向 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 应用来检测：

欢迎试用：https://phodal.github.io/new-pr

网站声明：如果转载，请联系本站管理员。否则一切后果自行承担。

本文链接：https://www.xckfsq.com/news/show.html?id=30338

赞同 0

评论 0 条