项目管理的一些思考
现状
俗话说家家有本难念的经，每个公司的情况都不太一样，当你的团队遇到项目管理问题时，通常会怎么做？看了很多关于瀑布流、敏捷开发、迭代式开发模式的文章、讨论，没有一个能套到自己身上。
目前团队采用的管理模式类似于 scrum，以一个季度为一个迭代，每两周为 1 个 sprint。迭代第一个 sprint 通常会进行需求讨论+产品设计+技术优化，第二个 sprint 开始进行功能开发+上个sprint的质量保证+下个sprint的需求讨论产品设计。
这个流程执行下来遇到的问题有几个：
- 功能优先级高，要等产品设计敲定
- 功能复杂度高时容易跨 sprint
- 功能开发完没有总结完善过程直接进入了下一个功能开发
- 季度为单位的时间周期太长，无法做到真正的时间控制
每个 sprint 的任意功能延期就会产生蝴蝶效应，迭代末期留给 full testing 的时间会非常少，不得已就整个迭代延期。
优化
优化方案是以时间控制为目标，将需求讨论与产品设计挪出 sprint 管理流程。 sprint 作为内部管理的一个小迭代，只控制功能开发+质量保证的时间。假设 sprint 以两周为单位，那么 PM 主要抓这两周内的开发任务队列的进度，风险与功能质量就非常可控了。
优化后总体上会分为两个队列：
- 功能设计 ready 队列
- sprint 开发+质量保证队列。
功能设计好后会进入 ready 队列，按优先级进入下一个开发 sprint。产品和商务需要在下一个开发sprint之前开会定好优先级，以两周为单位后开会速度、效率也能提高，响应客户的速度、客户的满意度理论上都会提高。
功能设计队列由产品经理推进，与商务需求讨论制定功能优先级。完成设计的进入 ready 状态。
需求评审由商务与 PM、产品经理、Tech Leader参加（会上直接砍掉不合理的、不会做的）。
原型评审由产品经理、Tech Leader 参加（评估设计方案）。
设计评审由 PM、产品经理、Tech Leader参加（评估开发时间，超期砍功能、重新评估设计方案、加人力）。
sprint 开发队列的模式是从 ready 队列按时间排期进入当前 sprint
形成循环后就达到了 scrum 理想的样子。
大版本迭代还可以继续以季度为分割，可以交付给客户的就是 N - 1 个 sprint 所交付的内容，第 N 个 sprint 的交付物不会包含在大版本中，第 N 个 sprint 的时间内 QA 需要做封板测试。
那么流程改变后研发侧需要做什么
研发 leader
研发
测试
下一步
等流程跑通跑顺，就做到了 scrum 敏捷开发，抛开大版本以季度为单位的发版，每个 sprint 的交付物都应该做到可以直接交付客户，那即是理想状态。
