框架

背景

个人是不太愿意使用用户体验差的软件来做项目管理，行业内，要找到这么一款软件，又要符合自己的需求，着实不容易。要免费，易用性要好，要安全，要有数据统计。而程序员的世界，SVN 之后，可能没有人会拒绝 github，gitlab。从开发的角度出发，基于此平台作自我迭代和研发，则应当是最接地气，最容易推广的事情。

从代码开始迁移到 gitlab 到最终完成项目流程的改造，花费了大概两年时间。中间经历了，BUG管理系统的迁移，测试流程的迁移，进而影响到产品流程的迁移。后续又完善了文档管理，存储，pipline的CICD的自我构建。打通了项目流程的同时，也完成了 DevOps 的使命。

团队内部项目管理有三大默契(原则)：

1. 一切是在线协同的
2. 一切内容是透明的
3. 一切行为是自主的

1. 项目管理

• 敏捷管理
  • 看板管理：Backlog -> to do -> doing -> close
  • 燃尽图：plan -> burning -> prediction -> addition
  • 进度：项目进度、进度监控
  • 报告：日报、周报
  • 评价：项目评价、个人评价
• 状态：milestone、label
• issue：可关联、状态同步、闭环
• 任务交接流程管理

用此作项目管理，主要围绕以下几点来作改进。

• 按照上面的原则第3点，我们所有任务安排妥当后，每个人任务都是由具体的执行人来评估、添加、移动。PM 只承担指导、监控、收集问题、并改进的责任。
• 解放写周报的政治性任务：只要任务规划好，并每天自行拖动任务，报表自动生成。

关于燃尽图的指引，由另外的文章给出。

2. 权限管理

• 权限分组
• 防止外泄，只有在公司内网才能访问

3. 存储管理

• docker 镜像
• 文件存储：图、文件(rar/word/excel/pdf etc.)、视频
• 其他

4. 文档管理系统

• 在线协作
• 模板管理
• markdown
• PPT
• 甘特图
• yaml
• WIKI
• 文档中心：接口、方案、总结

5. 需求管理

• 需求原稿
• 需求指派、受理
• 需求讨论、变更
• 需求跟进

6. 开发管理

• 代码托管
• 分支管理
• 版本管理 -> tag
• static code-review
• UT/UT coverage
• gomock
• build
• CI

7. 质量管理

• 提测需求&进度管理
• BUG管理：bug分类、等级
• 用例管理
• 用例审核

使用 gitlab 作 bug 管理，采用 label 进行 bug 标记和分类，分类包括了 bug 等级、bug 的质量高低等信息。标签可以用脚本统一增删查改。

bug 跟随项目 project 而走，便于回溯。我们的要求是：任何一次代码提交是可溯源的。 是因为 bug 修复还是需求更新而更新代码，merge 时，必须能够 mention 到具体的 issue。根据需求版本建立 milestone，并且将 bug 归属于 milestone 中，心作质量管理和分析。

bug 是跨项目存在的，例如我们有100多个project，是不利于 bug 管理的。于是写了一个调用 API 的脚本，定时和手动将 bug 导出为 excel 用于分析。

单元测试，mock测试用例能够更好的与被测代码融合，即便开发线上修改，也能够将测试代码在线上运行。

8. 上线管理

• pipeline：CD
• 与 TDC DevOps 关联
• 上线 issue
• 运维可参与

9. 日志管理

• history
• comments
• status
• changes

10. 消息通知

• todo lists
• email push
• 钉钉

优缺点

项	优点	缺点
统一平台	无系统切换成本资源复用权限统一管理	二次开发需开发维护
项目管理	敏捷管理自研个性化定制需求开发测试有独立池管理	对于项目管理资源融合要求更高
issue	囊括产品需求、提测需求bug、上线、方案讨论	需要统一整理，否则不便于查找
BUG提交	与项目相关联，利于追踪溯源BUG重现可提交视频	不便于统计，需跑自研脚本定时下拉
维护	公司级团队维护备份无需额外投入人力全面日志管理与历史记录	无
安全	离职人员带不走资料不需要查邮件回顾	公司外无法访问但可事先pull到本地