#2 PMP & IPMP

项目管理 2021-08-15

在软件开发领域，最知名的项目管理证书应该就是 PMP 了。与之对应的有 IPMP, CPMP。

PS：此外还有 6Sigma 等。
PS：PMI 协会除了 PMP 认证之外，还有 ACP 敏捷项目管理认证，PgMP 项目集管理认证。

PMP

项目管理专业人士资格认证 Project Management Professional

组织单位：美国项目管理协会 Project Management Institute (简称PMI)
费用：大概 3800 人民币
要求：3 年以上担任项目经理经历

IPMP

国际项目经理资质认证 International Project Manager Professional

  • A 级 (IPMA Level A) 证书：特级项目经理 Certified Projects Director
  • B 级 (IPMA Level B) 证书：高级项目经理 Certified Senior Project Manager
  • C 级 (IPMA Level C) 证书：项目经理 Certified Project Manager
  • D 级 (IPMA Level D) 证书：助理项目经理 Certified Project Management Associate

其中 C 级对应 PMP 认证。

组织单位：国际项目管理协会 International Project Management Association (简称 IPMA)
费用：大概 1200 人民币
要求：3 年以上担任项目经理经历（C 级）, D 级没有要求。

CPMP

中国项目管理师 China Project Management Division

组织单位：人社部

  • 高级项目管理师（一级）
  • 项目管理师（二级）
  • 助理项目管理师（三级）
  • 项目管理员（四级）

如果不是专门查这一块资料，我应该都不知道有这个东西。

参考资料与拓展阅读

#1 Git 分支管理策略（工作流）

Git 项目管理 2021-04-07

Git Logo

Git Flow

荷兰程序员 Vincent Driessen 2010 年提出。

Git Flow
PDF 下载

  • master 主干
  • develop 开发分支
  • feature/xxx 功能开发分支（临时）
    基于 develop 创建，开发完成之后：合并到 develop 分支，删除
  • release/xxx 预发布分支（临时）
    基于 develop 创建，测试通过之后：合并到 master 分支，打 tag，合并到 develop 分支，删除
  • hotfix/xxx 问题修复分支（临时）
    基于 master 创建，问题修复之后：合并到 master 分支，打 tag，合并到 develop 分支，删除

特点：基于版本交付

PS: 作者于 10 年后，也就是 2020 年，更新了一次，表示：对于互联网应用的开发应该考虑更加简单的工作流，比如 GitHub Flow。但不管怎样，应该结合自身的实际情况，不能盲目照搬。

GitHub Flow

GitHub Flow

  1. 从 master 拉分支，提交，推送
  2. pull request
  3. 评审，测试
  4. merge 到 master

特点：基本不涉及项目的分支管理，主要是对多人协作方式提出建议：Pull Request。适合多人参与的开源项目，由项目管理员负责维护主干。

中间可以借助自动化工具来静态分析、部署、测试，提升开发速度。但这些工具不是 GitHub Flow 专有，或者说不是它的特色。

这套逻辑看似非常简单，但要硬套到企业项目开发流程中可能会非常复杂，水土不服。
PS: 虽然 git 新增了一个 request-pull 子命令，但可能很鸡肋，不可能脱离 Web 来参与讨论、评审代码。

GitLab Flow

GitLab Flow

分不同环境：

  • master 开发分支，管理方式就是 GitHub Flow，不过就是 Pull Request 改名为了 Merge Request
  • pre-production 预发布分支，只能从 master 合并
  • production 发布分支，只能从 pre-production 合并

如果需要发布：

  1. 从 master 拉分支，比如：20-04-stable，创建语义化版本号。
  2. 如果后期有严重 BUG，可以从 master cherry-pick 过来。

特点：比 GitHub Flow 更进一步，对项目的发布和部署提出了建议，并支持多个环境。

主要是其中有一点特别好的就是: Upstream First, 上游优先。所有环境以及维护分支的提交必须来自 master 分支。

我的思考

当然，还是那句老话：适合自己的就是最好的。
项目分支管理流程要和项目自身的特点，以及团队成员的技术水平相匹配。

Git Flow 的整套流程挺完备的，符合一般开发的习惯，只是对其作出规范而已。
GitHub Flow 也好，GitLab Flow 也好，都可以看做是 Git Flow 的补充。

GitHub Flow 和 GitLab Flow 都假定 master 分支是可发布的，而 Git Flow 从 master 拆分出了一个 develop 作为缓冲，我认为这个设计比较合理。

Git Flow 有几个需要注意的问题：

  1. 合并的时候保留之前的合并记录，谨慎快进 (--no-ff)
  2. hotfix, release 分支推送到 master 发布之后，切记还要同步推送到 develop 分支
  3. 必须坚持 master, develop 上不随意推送（还是得靠 Pull Request 机制）
  4. 如果有不属于当前发布周期需要的开发，不要合并到 develop
  5. 临时分支必须快用快销，不要长时间保留，且合并之后理解删除

我设想中的开发流程

1，基本参照 Git Flow (借助工具)

上游优先原则：master 分支作为所有可发布环境的上游

2，自动化测试：

  • develop, release, master: 只要有变更就触发一次自动化测试
  • 此外, master 应该保持一定频率的定时自动化测试

3，老版本需要维护就在 tag 上拉分支。

现实场景中，可能要为 abc 环境上的某个老版本 v1.0.0 修复 BUG、加功能，或对已有功能进行一些调整。

git branch maintain/abc v1.0.0 # 一旦分叉，就需要长期保留该分支
# maintain/abc/develop
# maintain/abc/feature/xxx
# maintain/abc/hotfix/xxx
# maintain/abc/release/xxx
# 视情况，可以简化处理，不用上面这些分支

PS: 最后需要重新发布的时候可以对版本号加上附加的标识 v1.0.0.1.abc

5，如果是 OEM，针对客户有关的信息、资源应该留给打包系统来统一处理

此外：

  1. 项目应有明确的 roadmap
  2. 代码评审
  3. 数据库设计统一管理
  4. 项目文档，需求库，用例库
  5. 版本号基本上遵循语义化版本规范
  6. 提交记录遵循 git commit message 规范 (借助工具)
  7. CI/CD + 自动化测试

参考资料与拓展阅读