我是谁？
读了九年理论物理，忽而迷上数据科学，无奈做了研发组长。
东渡异国他乡，初心不忘，拾起旧日梦想。
一直迟迟不愿写下新年计划，怕落空、怕让自己失望。回顾过往，貌似没有一次新年计划是成功完成的，总是抱着巨大的欣喜开篇，最终却伴着更大的失落收场。
今年也会重复这轮回般的宿命吗？要说认命，我并不甘心，所以还是鼓起勇气，再一次挑战新年计划。今年，2017， 我怀着谦卑的心态，没有雄心勃勃，没有一腔热血，而是冷静的思考，思考着如何让计划可以执行，并且足够健壮以应对不确定的未来。
正当苦苦冥思之时，脑海中先后跳入了两个词：SMART 和 SCRUM。 对，就是你们了！ SMART用于解决计划的可行性问题，而SCRUM框架则可以保障计划的顺利执行。
SMART 让计划落地
SMART原则是检验一个计划是否可行的标准，它可以让悬浮于空中的愿望落地，成为一个切实可行的目标。
先说一下我在数据分析方面的学习目标：以Udacity中的课程为主线，辅以其他在线课程和书籍，在2017年上半年完成数据分析纳米学位，2017下半年完成机器学习纳米学位。
那么下面就用SMART原则分析一下我上半年的目标吧。
• 【Specific（明确）】 是的，目标中定义了具体的活动，学习一系列课程（包括统计、数据处理查询、机器学习、可视化等），而不仅仅是说我要学数据分析。
• 【Measurable（可衡量）】是的，只要完成这一系列课程和项目实践，我就能达成目标了。
• 【Attainable（可实现）】根据课程中给出的300学时的建议，考虑要补充其他课程和书籍，我将这一时间乘上系数2，就是实际需要付出的学习时间。在半年内完成600学时，且在一周休息一天的情况下， 我需要平均每天准备4小时来学习。这是我目前可以实现的。
• 【Relevant（相关性）】是的，这与我的长期职业规划是一致的。
• 【Time-based（时限）】计划半年完成，最多乘上20%的浮动，也就是最迟7月底之前完成。同时我也为课程中的每个项目设置了里程碑，相当于预测了一个进度条。
○ 项目P1 - 统计学 - 2月15日
○ 项目P2 - 分析入门 - 3月15日
○ 项目P3 - 数据预处理 - 3月31日
○ 项目P4 - 数据探索 - 4月15日
○ 项目P5 - 机器学习 - 5月15日
○ 项目P6 - 数据可视化 - 6月15日
○ 项目P7 - A/B测试 - 6月30日
好了，通过SMART原则，可以安心的知道我的目标至少是可以实现的。但问题来了，这只保障了目标是没问题的，但并没有保证我能完成啊？
我意识到，我们管理的对象不应该只是计划本身，而应该是我们自己。
SCRUM 保障计划的执行
互联网产品大多采用敏捷开发的方式，来保证产品的快速迭代。我们是否可以用这一套方法来管理自己呢？你也许会问，人又不是机器，怎么能用开发软件的方法开发人呢？可是，你看他们是那么的相似：
• 我们的认知 -- 操作系统
• 我们在某领域的系统知识 -- 软件产品
• 对知识的学习 -- 产品的迭代开发
• 个人学习管理 -- 敏捷开发流程
敏捷开发正是指导一个团队如何高效协作，通过一次次迭代的过程，最终完成一款好的产品。其实每一个人都可以是一个团队，我们时刻扮演着各种角色，所以我相信这一套方法用于个人身上也是可行的。
之前我在做项目管理时，研发组内采用了SCRUM的敏捷框架，所以我打算将SCRUM在自己身上做一项为期一年的实验。至于什么是SCRUM，维基百科的解释是“一种敏捷软件开发的方法学，用于迭代式增量软件开发过程“。好吧，还是不知所云？盯着定义看是没用的，让我们实践一下就知道了。
SCRUM的整个流程在时间轴上是由N个Sprint构成的，每个Sprint需要完成一次产品的迭代。Sprint的原意是：在一段短距离上全力奔跑，有点像100米冲刺的场景。通常人们会把它翻译成“冲刺”或“迭代”，为了保证它的原汁原味，下面还是采用Sprint这个词。
与传统的计划方法相比，SCRUM更适应这个不确定的时代。传统的计划方法方法总是试图做一份完美的计划，然后认为只要根据计划执行就可以把事情做好了。可这依赖于一个前提，就是我们把要解决的问题定义的足够清楚了，并且对整个过程能够准确的预测，且不会遇到任何变化。可这几乎是不可能的！我们没有办法精确预测到未来可能的变化。
可为什么说SCRUM更能适应各种可能的变化呢？这是因为SCRUM对产品需求清单的掌控能力，应用到个人身上就是对学习阶段任务的可控。
首先，SCRUM实施中会有一个总的任务清单（也就是本文所要做的年度计划）， 这个清单中的每一项的详细明确程度不一定一样，远期的任务会比较模糊，而近期的任务则更细化。这个总清单并不是一成不变的，随着一次次Sprint的执行，我们可以根据实际情况进行调整，比如可以执行新建、删除、更改优先级等操作，对近期任务进行细化分解和工作了估算。
尽管每一个Sprint中的任务是不能变的，但是由于整个过程是有很多Sprint构成，我们可以不断的根据现状来调整下一个Sprint的实施情况。
Sprint的周期一般为1周到1个月不等。每个Sprint的的目的是将一些精细化的产品需求开发成一个潜在可交付的产品赠量。在每个Sprint周期中都包含计划、执行、评审、回顾几个环节。
我的SCRUM实践
下面就让我用我的学习计划来定义一下这些环节吧。
SCRUM总清单，即是我上面表格中列出的学习计划，可以看出还是比较模糊的。没关系，随着一次次Sprint的进展，我会慢慢细化和调整。
Sprint周期，定在1-2周左右，会根据实际学习任务的难易来调整。在每个Sprint周期中，我会进行如下四个环节，每个环节需要有明确的输入和输出。
【Sprint计划】
对总任务清单分析和估算，明确本次Sprint中需要完成的任务。
输入：总的学习任务清单
输出：本周期中需要完成的任务清单，并细化分解到每个任务怎么执行。
【Sprint执行】
这是Sprint的主要部分，就是按照Sprint计划中列出的任务清单逐一完成。
除了完成任务，每天早晨都要进行“每日站会“，问自己三个问题，分别是：
1. 昨天完成了什么？
2. 今天准备做什么？
3. 遇到什么困难？
输入：Sprint 学习任务清单
输出：新知识增量，包括完成的作业、实践的项目以及课堂笔记等。
【Sprint评审】
将目标和完成情况比较，检查是否需要调整总任务，并将学到的知识和实践进行整理。
输入：Sprint 目标 和 新知识增量
输出：梳理调整总任务清单；将新学到的知识增量写成文章和大家分享
【Sprint回顾】
相当于围棋中的“复盘”，检视本次Sprint周期，问自己三个问题：
1. 这个Sprint周期中，哪些是做的好的？
2. 哪些是没有做好的？
3. 有那些地方是需要改进调整的？
输入：回忆本次Sprint的过程
输出：回顾小结；对自己进行阶段性奖励
评审和回顾都是在单个Sprint结尾做的，乍看有些相似，但是它们的对象是不一样的。评审是针对产品本身（新知识）来说的，看看都学到了哪些东西，对自己的知识体系有没有升级；而回顾是针对SCRUM流程本身来说的，看看这个流程是否可行，如何能更好的执行下去。
好了，到目前为止我对我的新年计划更有信心了。接下来，就是需要一些意志力和耐心，将计划付诸行动了！
