文/秋之川
这是《落叶》文集里第 64 片落叶，希望你能喜欢，不为别的，只为这份坚持。
第一次真正触电敏捷好像是2010年，那时候公司要求所有项目转向敏捷研发模式，选用的就是在国内如火如荼的SCRUM模型，这里附上一张经典的模型图，就不展开详细说了，以后会有专题去整理总结我这些年在敏捷之路上摸爬滚打出来的经验和方法。
Scrum 模型图
从开始学习敏捷到敏捷的实施，一直跌跌撞撞，因为之前的瀑布式研发模式已经在大家的身上根深蒂固了，所以想从思想上去改变困难重重。
我作为第一批参加培训的SCRUM MASTER，在学习和实践的过程中，慢慢发现，改变别人的思想很难，但自己在这个过程中发生了较大的转变。
大概在2007年，我因为工作中角色发生了一些变化，所以开始学习并使用时间管理的一些方法。我那时候的玩法大概是这个顺序：
1. 挑一个良辰吉日，安排半天甚至一天的时间；
2. 设定3～5年的大目标，包括了工作、学习、生活、健身和财务等几个方面；
3. 将各个领域的大目标分解到季度、月、周的颗粒度；
4. 再制订一个非常“完美”的 Daily Schedule；
5. 按照计划开始执行；
这整个过程是不是很像瀑布式的研发模式，从出需求到开始设计，到写代码，呈一条线性轨迹。
我再说说我每次的执行结果吧，那几年可以说做过很多类似的计划，最长的一个计划大概执行了有两个月吧，大多数都是主动放弃或被动中断，为什么呢？我当时一直都很困惑和焦虑，因为我觉得自己陷入了一种做计划就是为了放弃的怪圈。
直到我开始学习敏捷，我突然发现我之前总是失败的真正原因了。
就是我一直要求自己在做计划时就力求完美，然后在执行阶段就要求自己靠毅力去坚持，哪怕计划完美到执行起来疲惫不堪时，也一直跟自己说，要对自己狠一些，坚持，坚持，再坚持……一直到一个计划被放弃，下一个计划又会如此。
但我从未想过，在制订计划时少花点时间，先基于一个小一些的目标开开始执行，一边做，一边总结分析，针对执行过程中遇到的问题去改进计划，去修订目标。
在对SCRUM有了较多的理解认知之后，我开始将其应用于自己的工作生活之中，新的玩法是这样的：
1. 还是先选定几个领域各自的目标，只是不会再象之前那样想齐头并进，一口气全部实现了，而是会分解成阶段性的目标任务，形成一个 Goal Backlog；
2. 设定迭代的长度为一个月，结合目标正北理论和当前迭代可用人时，从 backlog 中选取合适的任务，形成 Sprint Backlog；
3. 将 Monthly Sprint 里的任务分配到每周待办事项清单里；
4. 每天早晨浏览一下每周待办事项清单，挑出一件任务开始执行，完成一件再选出一件继续执行，每天晚上回顾一下当天待办事项的完成情况，记录下每件已完成任务的实际花费时间，分析每件未完成或未开始任务的原因；
5. 根据当天未完成的任务情况，调整第二天的待办事项清单，一周结束的时候，根据这一周的记录，总结分析计划执行中的问题，并针对性的进行改进，但不对计划做大的改动，直到这个迭代周期结束才做大的调整；
采用这种敏捷的方法之后，我完成的目标越来越多，计划越来越合理了，更重要的是计划的可执行性越来越高了，而且不会象原来那么累了，也不会产生很多的挫败感了。原因我也总结了一下，就是SCRUM的精髓：小步快走，持续改进。
这就是我的敏捷生活：每年12个迭代 + 每年52次改进 + 每年365天的点滴进步。
作者简介：14 年测试经验 + 11 年项目管理经验 + 11 年团队管理 = 一个测试老兵
网友评论