2020年2月18日1:12:55

继续做功课

• 敏捷选择：选择看板方法，不是 Scrum。最最重要的原因是对于经常被领导拍脑门的需求插入，每个 Sprint 风险太大，估计没搞多久就被掐死在摇篮里了。

• 原则：

  • 以交付用户价值为依据
  • 不打乱原来流程和组织结构
  • 采用随机或者固定周期迭代，不采用 Sprint 的方式
  • 消除浪费环节，保障团队不被打扰，减少冗余环节

• 人员组成：
  部门领导（需要支持敏捷，需要参加各种例会），产品负责人（对产品有决策权），开发团队，PMO（临时，推动敏捷） 规模：5-9 人

• 第一次起动敏捷的宣传会，目的：

  • 动员参与人
  • 说明看板敏捷工作方式
  • 商议工作协议（也可以第一次迭代之后再协商）
  • 确认一下之前非增值环节（继续改进的环节），想办法在第二次迭代时优化，或者过程中优化

第一个迭代，只引入看板方法。在第一个迭代结束的回复会议上，总结哪些问题可以改进。引导引进其他的解决问题的办法。

• 看板计划样式：
  

• 备注：
  故事点不好理解，可以先采用人/天

• 可改进点：

  • Backlog 里可划分泳道：新功能、维护优化、线上 bug 等
  • 也可加上 UED 设计，前后端联调之类的
  • 线上 bug 尽量不走产品验收 。

• 设想流程
  原本还有个假设流程，再次整理时还是选择阉割了。。。