新项目检查清单 - Phodal | Phodal - A Growth Engineer

标签: | 发表时间:2019-03-14 05:59 | 作者:
出处:https://www.phodal.com
Posted by: Phodal HuangMarch 13, 2019, 8:07 p.m.

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

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

可是呢,对于每个项目来说,它们都存在一些相似的共同点。而这些共同点,即是我们开始一个新项目要做的,也是我们来到一个新的项目时,所需要了解的。于是,当我看到一篇 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 又或者是一个额外的关键角色,我们应该完善相关的部分。

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

相关 [项目 检查 清单] 推荐:

新项目检查清单 - Phodal | Phodal - A Growth Engineer

- -
无论是向新人介绍项目,又或者是上到一个新的项目,我们都需要事无巨细地列出一个个的关注点. 既然如此,那么为什么创建一个检查清单,用来帮助我们一个个的检查一遍呢. 在过去的日子里,经历了几个不同的项目,每个项目都有自己特有的特色. 它们往往也包含了一些不同的背景,在成功的交付项目之后,有的还要解决技术难题,有的要的是解决业务难题,有的复杂的部分在于跨团队的协作.

项目健康状况检查

- - CSDN博客研发管理推荐文章
项目天天救火,疲于奔命,项目健康状况到底如何呢. 我总结了11个问题,供大家自测一下. 当然要诊断项目的健康状况,11个问题是远远不够的,但这11个问题应该有足够的代表性,希望对大家有帮助. 下面有11个问题,请根据感觉打分(1-5分). 问题1:客户向公司领导投诉软件的问题,你们的领导很火,要兴师问罪,要在项目组中找出责任人,你估计你们项目组会出现怎样的状况.

Web软件测试中数据输入的检查清单

- - InfoQ cn
检查清单(Checklist)可以帮测试人员节省时间,因为很多有效的方法并不需要每个测试人员重新发现,前人已经有了充分的总结,并做了大量的有效性验证,其次,检查清单可以帮助测试人员避免遗漏,人的记忆是有局限的,难免会有遗漏的地方,通过检查清单检查可以有效的防止遗漏. 最近,IBM工程师苏京刚 总结了Web软件测试中数据输入的检查清单,对Web测试人员提供了很好的参考.

Web开发者必备:Web应用检查清单

- - ITeye博客
想做一个高质量的Web应用,前前后后要做的事情非常多. 国外开发者 Ata Sasmaz 为 Web 开发者制作分享了一份检查清单,包括应用开发、性能、安全、分析、可用性、可靠性、转换策略、竞争策略这些方面需要注意的事项. 清单内容可能不全面,欢迎大家在评论中补充. JavaScript 允许捕获异常.

医生,你为什么让病人做那么多检查项目?

- Aaron Xu - 译言-每日精品译文推荐
译者 flyingheart. One afternoon when I was running later than usual, I recognized a familiar face among the patients waiting to see me.   一天下午,我匆匆走进诊室,但还是较往常晚了一些.

reCAPTCHA项目

- - 四火的唠叨
文章系本人原创,转载请保持完整性并注明出自 《四火的唠叨》. 要说reCAPTCHA,就要先说一说CAPTCHA,全称是Completely Automated Public Turing test to tell Computers and Humans Apart,即全自动区分计算机和人类的图灵测试,也就是通常说的“验证码”,目的就是要把计算机和人区分开来.

Java Code Review清单

- - ImportNew
使用可以表达实际意图(Intention-Revealing)的名称. DRY(Don’t Repeat Yourself)原则,(拒绝重复). 用代码来解释自己的做法(译者注:即代码注释). *参考自: http://techbus.safaribooksonline.com/book/software-engineering-and-development/agile-development/9780136083238.

LoadRunner检查点实战

- - 码农博客
久到我都不记得上一次更新博客是什么时候,久到我们博客主机都过期了,一度我还想停掉这个博客. 好在有simon的坚持才决定博客继续整下去. 2013年对我来说是一个比较折腾的一年. 找工作的时候才发现理想与现实之间的差距是如此的巨大. 期间经历了落差、失望、彷徨……. 最近一段时间给我们组成员培训LoadRunner,我自己也有所收获,也就有了这篇文章.

C++检查内存泄露

- - CSDN博客推荐文章
说明,我使用的ide是vs2008. 内存泄露的检测一般在debug模式下进行. 2.在需要检查内存泄露的cpp头部加上. 4.然后就可以在输出中看泄露情况了. 举个例子,例子中我用newEx表示的上述宏定义中的new. 输出中显示的内容(debug下运行程序,然后点叉叉关闭程序).   Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD .

Solr4.2.1 拼写检查组件

- - 寒江孤影
在做搜索时一般可以在用户输入检索条件时使用suggest,而在点击完搜索时,使用拼写检查,二者结合给可以用户带来比较好的用户体验. suggest与spellcheck看似功能一样,出发点是不一样的,使用条件也不一样,spellcheck是在没有搜索出结果时才有的功能,搜索词正确是没能spellcheck结果的,而suggest是任何情况下都有结果的.