2020年2月15日01:04:44

前言

 我是一个工作 10 年的测试，更准确的说是 3 年 Java 开发 7 年测试。现在是一个几个人团队的测试经理，如今也是尴尬的中年危机阶层。而今年新冠肺炎肆虐，似乎让互联网的寒冬更冷更长，某个很好的测试基友给我说：“2 月份 100% 的合同基本工资，3 月份 80% 的合同基本工资，看来 3 月也不用上班了”。合同基本工资多少？2k 多点！
 好吧，这发生在敏捷契机之后，让我更坚定了参与尝试敏捷转型的决心。

契机

 不知道算不算契机，起码在我现在记录这一切的时候，我对未来还一无所知。
 2019 年年终的部门总结会上，副总 X 让我有时间给产品讲讲产品需求拆分，看看如何可以开展敏捷项目管理。虽然当时感觉眼前看到了希望（之前项目乱的不像话），但是说实话没有太往心里去。2020 年在家办公的第一天，X 再次提到这个事情，并且周四直接给我打了电话，他期望我可以去做这次敏捷管理的推动人。X 是我的领导的领导，之后的一天，我和我的领导 Y 提及了此事（其实这是满满的求生欲），Y 很中肯的给我建议：“做好你自己，并且这也是你一直想尝试的，别被逮到沟里就行”。
 好吧，就是这样的一个大环境。

开始干了

 敏捷项目管理，虽然之前参加过各种形式的敏捷项目，但那大都数都是被阉割过的，更直白的说可能叫迭代小瀑布。现在真正自己去推动，我做了计划准备的列表：
 1）明天先和 X 沟通一下，了解想通过敏捷未来期望达到什么样的状态。
 2）《猎豹行动》看着已经入门，抓紧看完《敏捷转型》
 3）确定敏捷项目人员组成（暂定）
   人员构成：部门主管（需要每次参加例会）、产品负责人（具有产品决策权）、敏捷教练（本来也没有项目经理）、开发团队
   规模：5-9 人
 4）说服 X，选择期望项目团队做试点
 5）指定敏捷原则
  ● 消除浪费环境，保障团队不被打扰，减少冗余环节（每日各种 XX 需去掉）
  ● 必须开展 sonar 或者单元测试，提高交付质量
  ● 当天 bug 当天闭
  ● 每件事闭必反馈
  ● 每日早会前先移动看板
  ● 1 周修复 bug、2 周交付功能
  6）其他沟通需要接受情况
  ● 敏捷探索性测试 bug 的遗漏
  ● 4 个迭代之后才会有明显的效果

  最后也是最重要的一点，第一个迭代，只引入 Scrum 或者看板方法。在第一个迭代结束的回顾会议上，总结哪些问题可以改进。

  夜深人静，继续看会书。