2020年2月25日00:11:54

转型前夜

 2 月 14 日夜匆匆的做了一个简单的计划后，将计划上交给副总 X，周日 2 月 15 日和副总 X 简单的沟通了一下，核心思想是，不改变现有的大多数流程，把前期拆分故事，故事拆分任务，评估任务等等操作全部线下去做，不要大张旗鼓的去做，做能做的改变。其实我也懂，一个非互联网企业，想要立刻接受新思想想彻底改变，是需要时间的。2 月 17 日，复工！再次沟通，结论不变。
 哦，忘了最重要的一条，马上开始推动！
 这个 “马上” 十分突然，2 月 19 日，项目 S 启动会突然召开（为了方便这个项目，我们叫它 S），副总 X 在项目组内宣布开始采用敏捷管理的方式，然后我被推倒了推行人的角色，就这样，“敏捷” 开始了。
 其实，这个团队规模也不大，实际参与者产品 1 人，前端 2 人，后端 1 人，测试 1 人和我。还有个幕后的产品负责人，副总 X。

伪故事拆分

 恩。。。鉴于上面推进的各种前提，计划先在项目内推进可视化看板管理，不是 Scrum。我的目的是让产品（不要反驳我说是客户啥啥的）能感觉到交付的东西一直有。
 首先先协助产品进行用户故事的拆分，当天下午，我和产品们一起进行了分析，然而产品需求已经给开发和测试讲完，如果严格的划分了用户故事的情况（就是为了啥啥，我想要个啥啥啥这种），似乎重新讲解故事需求产品也不接受。退而求其次，进行功能拆分，按优先级去排，尽量拆分到 0.5-2 天内完成的小的独立的产品可接受上线的功能。2 小时后，由产品向开发和测试进行简单的说明，开发进行线下的工时评估。

特殊说明：当时给产品讲故事拆分的原则就 2 点：

1. 接受每个 “故事” 独立上线
2. “故事” 要足够小，船小好调头

选择项目的风险

 在和副总 X 沟通时，我尝试了几次说服不要在 S 项目尝试。原因有三：

• 第一，S 项目在目前 3 个项目中，是最重要且紧急的项目，而推进尝试敏捷，一旦失败，会让大家更加不认可敏捷。
• 第二，一般敏捷要在 4-6 个迭代才会有明显的效果，在这过程中，大佬们很可能毙掉这种管理模式。
• 第三，产品负责人一直期望可以用加班来保证进度（虽然加班不一定能保证进度），他觉得敏捷太慢了。