愿景

我是在今年3月底参加了PMI-ACP考试，这是关于敏捷项目管理的一个考试。4月17日成绩出来，我拿到了7A（Above Target），就是所有的小项都拿到了优秀，这个结果我自己也是相当的满意。

在这里，给所有在准备考试的小伙伴们分享一个诀窍。其实在备考的过程中，我常常在想“等我考过了，我会多么开心，我要如何去庆祝”，“如果得了7A那该多好啊，我要发朋友圈告诉所有的人”“项目管理真的是很底层的能力啊，里面的很多理念和其他管理是相通的，我考完试一定要写文章记录下来”。那时候我还不清楚这样的白日梦到底有什么用。知道后来在《GTD-搞定》书中的看到这么一段话，我才发现原来我做的就是书写愿景，描绘未来的蓝图。

1957年5月出版的《科学美国人》（Scientific American）杂志刊登了一片文章，介绍了科学家在人类大脑中发现的一种网状组织。这种组织是连通自身意识的途径，如同电源开关一样，能启动你对思想和信息的感知活动。

你的大脑就像一台电脑，具有搜索（筛选）功能，但是比电脑效率更高。而搜索的对象恰恰就是我们平时关注的事物。一般来说，我们只会注意到那些符合我们内在需求或者吸引我们注意力的事物。

当你的大脑产生了一个清晰的镜像，描绘出你所渴望的事物，并且专注于这个事物时，你的大脑会自动帮助你捕获生活中的相关信息了。

因此，《GTD》就提到说，“在知识工作的领域中，最有效的生活技能之一就是创造清晰可见的结果，这也是我们为了实现职业和个人成功需要进行艰苦磨练的重要技能之一”。

所以当我们复习感到疲惫无力，不想继续进行下去的时候，不妨花一点时间去畅想一下，如果你考过了，你会是什么心情呢？老板同事们会不会对你大为佩服呢？会不会是升职加薪的一个砝码呢？对于你的工作有助益吗？对于你的家庭有没有帮助呢？能不能增进亲子关系，或者夫妻关系呢？

当我们从各个不同的角度对目标进行精确的描绘，我们就创造出那个清晰可见的结果。这样学习就不仅仅是显意识上的事情，我们的大脑潜意识都一起来帮忙，可不就是事半功倍了嘛。我觉得这和时间管理读书会上云姐分享的“先相信，再看到”也是相通的，当我们深深的相信我一定会处在那么一个场景之下，带着这样坚定的信念去披荆斩棘，或许连老天都会来帮我们吧。

敏捷团队的愿景

在敏捷项目管理中，一个敏捷团队在创立之初需要创建团队的共享的愿景。做法是这样的：

每个人先建立自己的愿景，也就是当这个项目结束时我希望能够获得什么。可能是技术上的提高，也有可能是获得一项品质，每个人把自己的愿景写下来贴到白板上。所有人完成以后，大家分别把自己的句子大声朗读出来。对于所有人的愿景，都询问其他的团队成员“你们同意支持他的目标吗？”带着对彼此目标的清晰认识和对彼此的支持的承诺，来到下一个环节。

建立团队的共享愿景。团队的每个人去问自己，我们作为一个团队意味着什么？团队对于公司意味着什么？团队对于世界又意味着什么？基于这些问题，用简洁并且意义明确的话写下团队的共享愿景。这个愿景将成为整个团队的指路明灯，当困难发生时，大声的念出团队的愿景，提醒我们曾经做出的彼此支持的承诺。这会给大家带来思考和交谈，如何才能实现团队的愿景，我们如何才能作为一个团队更好的合作。最终的结果通常是引导每个人做回更好的自己。

敏捷最吸引我的地方就在这里，以人为本，尊重每个人的价值。通过把团队成员的个人目标与整个团队的目标相结合，建立起共同的愿景。这共同的愿景则拉动着整个团队进行自我管理，因为我再也不是为了老板干活了，也不是为了那点薪水，我是要去实现自己的梦想，甚至是要去改变世界的呀。这样找到了每个人内在的驱动力，自然都会努力的去追求卓越。同时，每个人再也不是一颗螺丝钉，而可以开始做一个扳手了。

什么是敏捷项目管理，和传统瀑布模型的区别

言归正传，我们来看看什么是敏捷项目管理。敏捷开发是上世纪90年代末期开始逐渐引起广泛关注的一种新型的软件开发模式，他与传统的瀑布开发模型相比最大的优势是能够快速的适应变化。在我国，敏捷的发展是随着互联网行业的繁荣而兴起的。

我们先来看看传统的瀑布的开发模式是什么样子的。瀑布模式开发是一种“预定义过程控制”。它是用已知的方法解决已知的问题。特点是过程是可重复的，适用于大规模的批量生产。它的缺点在于，一旦某个环节出现了问题一定会对后面环节造成影响，而返工对于瀑布来说花销巨大。

相比之下，敏捷开发是一种“经验型控制过程”，它的特点就是不能够被事先定义好，结果也无法预知，过程无法复制。我们只能在项目的进行过程中不断地获得真实的反馈，进行适应和调整，保证最终的输出结果符合我们的期待。

从瀑布模型到敏捷模型，一个很大的改变就是思维模式的转变。从瀑布模型的“固定的需求，弹性的资源/时间”变为“固定的资源/时间，弹性的功能”。

在这个快速变化的互联网时代，用户的需求可能每一天都会有新的变化。范围很难被明确定义下来，既然如此，那不妨将资源和时间固定下来，专注实现最具有价值的那一部分需求。这和我们在时间管理里经常会提到的“二八法则”是一致的，20%的任务会产生80%的价值，那我们就去找到那最有价值的20%，集中所有的资源去完成最具这部分工作。

敏捷下包含了很多很多的不同的框架去解决不同的问题，比如Scrum，极限编程，精益，水晶。我今天打算聊一聊Scrum和精益的管理方法中一些方法和原则，还有它们给我带来的启发和思考。

Scrum开发

Scrum是目前非常流行的一个敏捷开发框架。它的原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。从下面的图片也可以看到，整个团队作为一个整体在进行争球。相比以前一环做完再做下一环的接力式的开发模式，这种方式会更适应当前这样竞争激烈的市场环境。

Scrum的流程如下图。简单来说，就是一个项目开发过程被分成了很多小阶段，每一个小阶段都是一个完整的闭环，在一个阶段结束时必须输出用户可以直接使用的功能。

                                       

Scrum的四个事件

在每一个小阶段（Sprint）中都会包含下面这些重要的事件。

    - Sprint规划会议：目的是确定即将开始的这个Sprint的目标和满意条件，确定需要完成的需求，并将需求细化成任务；
    - 每日站会： 要求非常的简短，在15min之内。在会上每个人只回答三个问题：我昨天做了什么，我今天计划做什么，碰到了什么问题。如果有问题，可以私下再重新hold会聚集相关人员讨论。在这个会议上可以看到每日目标的实现情况，对项目进度进行一定程度的监控。
    - Sprint评审会议：当Sprint即将结束时，向干系人展示当前这个Sprint开发的真正的产品。关注的重点在产品，目的是为了及时从干系人那里获得反馈和改进的建议。
    - Sprint回顾会议：同样是当Sprint即将结束时，整个敏捷团队聚集到一起开的会。它主要是要回头看看刚刚过去的Sprint的工作是如何完成的，工作流是否顺畅，有出彩的瞬间吗，下一个Sprint能否变得更好呢。它关注的重点是团队成员。

Scrum的这个小循环给我最大的感受就是节奏感，抑扬顿挫，张弛有度。前有筹划布局的计划时间，中间有专心冲刺的项目开发时间，最后还有回头总结反思的喘口气的时间。

因此我们学习任何东西，首先应该弄明白我为什么要学。把目标定下来之后，再分割成小的目标，之后在一小段时间里使用“单点突破法”一个个去击破它们。单点突破法是在张萌的《人生效率手册》中提到的时间管理的一个方法，简单的记录时间的开销并不能让自己的时间变得更高效，重要的是要形成“计划-实施-总结-评估”的闭环，这样才能够看到自己的问题，才能找到方法真正去改进和解决它。这也提醒了我们低头匆匆赶路的同时，必须得不时抬头看看前方的路，看看是否已经不知不觉走偏了。

此外，也要给我们的生活来点小乐子。像我自己之前在学习的时候，常常会犯得一个错误就是，总担心时间不够用，一上来就抡板砖拼命，还没玩儿两把呢，先把自己累趴下了，然后就没有然后了。我在讲敏捷方法的《看板实战》看到的：只工作不玩耍，聪明的孩子也变傻。所以我们一定要给自己一点游戏娱乐的时间。这也是学习可持续进行下去的一个动力呀。

Scrum中的两个角色

Scrum中有两个特别的角色，Product Owner（PO）和Scrum Master（SM）。

PO就是产品经理，或者叫产品负责人。他的主要职责是定义团队要完成的工作内容，将所有的客户的需求按照价值高低进行排序。端午节划龙舟的时候我们经常会看到在船尾都有一个掌舵者，控制着整艘船的航向，PO就是这个掌舵者的角色。

SM则是一个服务型的领导者角色。他要确保团队遵循敏捷的理论，实践和规则，帮助团队扫除前进路上的一切障碍，让整个团队持续高效的产出。SM的作用就像是龙舟上的打着鼓决定划船节奏的击鼓者。当时我们在上课的时候，老师举了个关于SM的例子很有意思，如果路上有个坑，SM要立刻躺平了去把这个坑给填上。

虽然看上去SM要做的事情并不像PO那么的清晰，但是SM的好坏能够决定敏捷实践的成败。SM（敏捷教练）他需要要用自身的言行并对团队成员和整个组织产生深远的影响。我在学习时常常觉得他和很多的角色有相通的地方，像是心理医生，新时代的父母。他和团队之间需要保持好界限。他不能再像传统的项目经理一样，试图帮团队解决所有的问题。他要充当一面镜子，让成员们通过他可以看到问题真正的所在，从而自己去寻找答案。因为相比一城一池的得失，他们更关心的是团队长久的成长。

精益

精益思想是源自丰田生产方式的一种管理方法，敏捷也吸收了它的一些方法来进行软件项目管理。给我最大启发的就是可视化和限制在制品。

可视化

可视化管理是精益管理中非常重要的一个工具，在敏捷中则将可视化提炼成使用看板来对软件开发的过程进行管理。将工作流程/规则显示在一个处于公共区域的看板上，这不仅能够促使大家更高效的沟通，通过将规则的显示化提前将冲突和矛盾暴露出来，避免出现问题之后引起的冲突。而且还能够及时的发现问题和瓶颈，消除浪费，让整个工作流更加顺畅的往下进行。

下面就是一个看板的例子。从这个图中可以很直观的看到，在“Doing”这一列有了瓶颈，同时在做7件事情，而它的下一个环节“Testing”里面只有1件事情在进行。那就可以在真正的问题发生之前，去寻找一下原因，能不能不要同时做那么多事情，而是几个人齐心协力先做好一件事情，让事情更快的流动到下一个环节而不是堵在某个环节。

而我们自己的学习中是不是也有这样的可视化的环节呢？我们最近都在学理财和时间管理，最开始都有一个环节就是整理当前的现状，那其实就是一个将问题可视化的过程。就拿理财来说吧，我一直以来大脑中隐约有个感觉，家庭开销有点多欸，一年都攒不下什么钱？为什么呢？我没买什么呀？钱都花到哪里去了？不知道，迷茫焦虑恐惧。可是当我学习理财之后，通过整理当前家庭的资产/负债，还有坚持每个月记账，所有的内容都非常直观的显示在我们面前，这样才有思路去发现哪些是被我浪费的，哪一块是需要提高的，自己也有努力的方向了。其实啊，很多时候让人害怕的不是问题本身，而是对未知的恐惧。

限制在制品

某一天在群里面和大家一起互相种草挖坑的时候，当时正好在看《看板实战》这本书，于是我分享了书中的一张图：”停止启动，聚焦完成”。这也是精益方法里很重要的一个原则“限制在制品”。

什么是在制品呢？简单来说就是任何已经开始但是还没有完成的事情。

那为什么要限制在制品数量呢？从软件项目管理的角度来说，在制品数量增多会带来各种各样的问题。首先最简单一点，当同时进行的事情比较多的时候，每件事情做完所需要花费的时间就变长了。其次，当同时进行做几件事情时，在不同工作之间切换也会带来额外的消耗。此外，当手头上的事情比较多的时候，很多问题无法及时被发现，或者发现了也无法很快反馈，这可能会导致更多的工作，甚至影响到最终输出的产品的质量。当然也不能整个团队只做一件事情，这样虽然每件事情都能够用最快的速度完成，但是会造成人员的闲置，这也是需要去平衡的。

对于咱们群的小伙伴，是不是也很有启发意义呢？咱们互相种的草挖的坑真的不少了，我自己常常会陷入一种对知识的焦虑中，这也想学，那也想学，怎么办呢？我们的大脑会试图记下来所有未尽的事宜，然而却没有办法在正确的时间提醒我们。常常是当我们在思考一件事情时，另一件事情突然冲进脑海中，吸引了我们所有的注意力。我们的大脑就这么被这些此起彼伏的事情分散着注意力，自然会压力倍增，疲惫不堪了。谈何高效的输出呢？

所以，还是要停下来，问问自己为什么要学这个东西呢？想达成什么效果呢？它真的这么重要吗？把目标想清楚了，就很容易可以将事情分个轻重缓急，一次专注在少数的几个事情上去突破它。其他的先放在待办清单里面，虽然缓慢但是坚定的一件一件的去完成它们就是了。

学习知识和培养技能真的不是一朝一夕可以速成的事情，需要我们持续的学习，不断的将学习到的知识运用到实践中，并且加以反思总结，去琢磨事情的本质和真相，在时间的打磨下它们才能真正成为我们自己的东西。

后记

其实敏捷里面还有很多很多非常好的思想，我只恨自己没有足够好的文采能够把内心的的波澜描绘出来。这里分享一篇文章是讲Scrum的心路历程，我觉得写的特别的好：http://www.ituring.com.cn/article/115702

作者从儒家的角度去分析Scrum的思想，尤其是文章中关于王阳明的心学的部分，是我自己感触特别深的部分。当我们从心出发，发自内心的认同和拥抱我们要去追求的那个目标，那个愿景，那么行动起来开始做一些改变就是一件顺理成章的事情。