一个软件项目的健康有两个方面，一个是内部成员的进度把控，一个是对外部成员的进度公开。
一个软件项目的进度有两个角度，一个是看项目本身需求的完成情况，一个是看每个开发人员的工作内容。

目标

我们最终想要的是什么？

目标1：交付质量

• 保证让用户满意，用的爽
• 适度超出预期

目标2：项目进度

• 能按预定进度稳步推进
• 紧随用户需要，及时把控进度

目标3：连接用户

• 保证用户反馈问题时，能及时响应

目标+1：避免常态化加班

• 常态加班会透支团队战斗力
• 稳定的节奏，稳定的状态，才能稳定的输出
• 那怎样避免呢？

如何有节奏的开发

使用一定规律的冲刺迭代来

• 既保证大功能的输出
• 又保证小细节的修补
• 也让开发团队保持良好的节奏感

一个实际运作过的节奏

- 注：此节奏是用于管理一个项目，作参考，请举一反三

每个月规划一个大迭代(Iteration), 必须大版本更新，需发布更新日志

• 其中每周一轮冲刺(Sprint)，一共四轮，分别为ABCD轮
• 前三轮ABC轮只做新功能和重大紧急修复
• 最后一周D轮做发布，以及小修复，和下一个迭代规划

图例

月度Iteration: 至少一个大亮点的版本更新

• A轮Sprint：新功能/紧急修复
• B轮Sprint：新功能/紧急修复
• C轮Sprint：新功能/紧急修复
• D轮Sprint：发布/小修复/团队调整/规划下一迭代
• 4轮下来只有28天，一般还多出1~3天用于团队调整或者Hackday

开发节奏第一步：管好issue

• 录入规划的功能点（以1个人时为粒度）
• 录入自己想到的/用户反馈的点（后续整理）
• 用好label做好分类（比如高中低优先级）
• 用好评论里，加入所有想到的东西作备忘

第二步：还是管好issue

• 每周review一次issue列表, 及时安排调整
• 用好git commit:
  • 直接操作issue, 如：close #8
  • 或者关联到issue，用于备忘，如：#2
• issue可以和issue,commit,PR,milestone等进行关联，方便未来有据可查。

基于Milestone管理节奏

• 使用Milestone建立每周Sprint
• 提前建好下个月的所有Milestone
• 使用PullRequest建好发布计划，并与Milestone关联

辅助性的做法

• Standup: 每天早上5分钟走廊快速碰面，聊聊今天要做的
• 编写开发迭代周报
  • 由团队成员轮流管理迭代，保证迭代进度，并发送周报
  • 周报的接收者为部门领导，开发团队，用户以及项目特别关注人

参考开发管理工具： Github/Gitlab

• 支撑了无数的开源大项目
• 三个代表：issue/milestone/wiki
• 程序员友好的接口：Git Commit/PullRequest

探讨1:如何同时管多个项目？

• 以上方式只实践于单个项目
• 如果手上项目好几个甚至几十个呢

探讨2：如何做团队整体进度汇报

• 不可能点开每个项目的Milestone进行查看
• 可尝试使用一个专门的团队上帝视角项目，来专门从业务上而不是代码上来管理所有项目