Agile - Planning with GitHub Projects
前言
结合工具，聊聊软件开发的流程管理
阶段管理
对于产品开发的管理，分为以下几个阶段：
- Opportunities Backlog - 机会待办
- Program Overview - 项目概览
- Feature Overview - 功能概览
- Other Backlogs - 其他待办
工作流程
Work Flow 1. 需求识别，真实需求，放入Backlog 2. 当backlog中的任务决定开始做之后，Program Overview 里创建对应的task
- 一个task可能包括多个feature
- 可能跨多个team
- 也可能涉及不同的role
- 将上面的task分解归属到不同的team和role,即feature Overview里创建对应的task（可以设置子task，父task 做关联）
- Other Backlogs 放置其他辅助工作或者探索性工作，又或者tech debt
这种分配方式，每一级的 project 都和上一级有所重复。这方便特定团队的工作的同时，也可以让更大范围的团队知晓每一项的进度
Opportunities Backlog/ Others Backlog
Agile Planning
关心的问题：
- 哪个团队适合负责？
- 能实现哪些目标？
- 当前进展如何？
在 Github，这个阶段的 project 名字叫 Planning & Tracking Pitches
Task 流转，表面进展high level, 比较粗的粒度
Draft -> Ready to pitch -> Under review -> Done
使用者：所有关心整个产品进展的人
重度使用者: 管理者/产品经理
Program Overview
当上面的backlog被接受后pitched(如Under review)
Agile Planning
关心的问题：
- 进度如何？
- 风险如何？
- 负责人是谁？（team/ic）
- 下一阶段是什么？
从 Github 分享的截图中可以看到，他们使用不同的栏（Field）来回答使用者的问题。
比如 Trending 这一栏，让使用者知道进度和是否有延迟交付的风险，而 Target Changelog 可以让使用者知道这个事项最终会在哪一版发布。
他们也会用不同的视图，比如 Next/Later 就可以看到下一步的计划 - 这里使用kanban是更直观的表达（增加view）
使用者：所有关心整个产品进展的人
重度使用者: 管理者/产品经理
Feature Overview
Aglie Dev
现在规划阶段已经完成了，接下来，就要转到 Feature Overview 阶段
- 不同的team 单独的project
- 不同的feature，单独的project(考虑epic级别放入不同的project，比较省力)
关心的问题：
- 为了完成某个功能，一共需要做哪些工作？
- 当前被分配了什么工作？
- 工作的先后顺序是什么？
- 我可以开始做哪些工作？
- 团队成员之间的工作分配是否合理？
类似于敏捷kanban，可以按照迭代来划分
使用者：所有关心整个feature实现进展的人
重度使用者: 产品经理/研发团队
总结
- 每一个project 关联人和team，feature，便于统计分析任务分布和迭代用时
- 也可以增加changelog 记录需求的变动频率
- 更多的updates 记录执行过程的重要信息
缺点是，有不同的projects记录相同的任务的繁琐，可以通过简化的方式来进行
如：
- 在program overview 记录链接doc，如PRD/UI prototype等，high level描述 task
- 在feature overview 按照user story维度拆feature task，分工task可以作为feature task的子任务进行
best practices 都是根据team自身情况不断调整的，没有银弹
多年的经验总结，在工具中，如何设计项目管理模式：
- 确定使用者是谁
- 确定使用者关心的问题是什么
- 在不确定的情况下，先尝试，迭代改进
参考
From disarray to delight: planning with GitHub Projects - Universe 2022