我心中的敏捷

我心中的敏捷(1)----首先不应该是噱头

引言：

这是继“作团队感悟”之后，转载自我网易博客的又一个系列文章，在这个系列文章里，主要记录和描述了我对于敏捷开发、敏捷团队以及敏捷公司的理解。我认为，敏捷和迭代，已经是一种世界观和方法论，而不仅仅是一种技术手段或者工具。融汇贯通敏捷和迭代的深层次思想，不仅仅能帮助我们提高研发水平和研发质量，更重要的，它可以更好的帮助一个团队或者一个公司走向成功。下面，引出第一篇文章内容。

 

正文：

"敏捷开发", 对于2007年的业界来说, 早已不是一个新鲜话题, 若干年前, "敏捷"和XP就已经成为业界的流行词汇,无数开发团队和研发型公司将之奉为神圣如葵花宝典一样的物件. 而直到今天, 不知道那些每天口上都含着这个词的从业者们是否真正明白了敏捷,理解了敏捷, 融会贯通了敏捷.

我也是很早就听说了这种开发方式, 而, 真正有所感悟的,是在2006年8月后决定我们项目生死成败的这一年不到的时间. 在这一年不到的时间里, 我用心用所有的精力来理解, 改进我们的开发方式,而现在采用的方式, 说不上到底还是不是所谓的正统的敏捷, 但, 这种方式, 确确实实带给我更多的踏实感和安全感,认为作一款成功的产品不再那么难, 也不再是一种奢望, 至少, 成功会更近一点, 希望会更大一点.

回忆和品味, 是一点一滴慢慢累积的, 所以, 作为对这种开发方式, 开发哲学, 以及开发者人际关系的理解与应用, 都是非常非常广的话题, 不可能一两句话就说完, 对于有兴趣的读者来说, 就请跟着我的思绪来慢慢品味, 时时思考吧.

可能有人会觉得, 软件开发嘛, 无非就是写写文档, 编编程序, 调试调试BUG, 是一种纯技术性的工作. 但, 在现在的我看来, 开发本身,是有一套自己的哲学体系的, 虽然这种哲学未必象传统哲学那样条条是道, 逻辑紧密, 但是, 也确实存在一套前人的经验和体会,以及若干种被屡试不爽的简单方法. 我把能理解并已经具备这种开发哲学的人, 称之为具备"开发世界观"的人, 这种人,已经建立起了自己的一套开发理论, 他们知道如何更好更合适的选择一个技术方案, 知道如何更好的在产品质量和开发效率之间作平衡,他们已经建立了软件开发的大局观, 所以, 他们无论作什么内容的开发, 都能够由大到小的将任务分解, 都能够由粗到细的将难点细化与突破,都能够很好的团结开发团队向着共同的目标前进, 从而充满信心的,有条不紊的将任务完成. 对产品质量和进度能够完全把控的感觉,是世界上最美妙的事情.

有很多人很羡慕网易的技术研发水平, 但, 不知道是不是我太孤陋寡闻了, 在06年8月之前,我并没有看到网易有多么好的开发方式, 其产品质量更多的时候, 还是依靠开发团队里一两个人的技术水平和开发状态,经验的成份占了很大的一部分比重, 这样很多的时候, 就导致了多次的产品返工或大架构调整, 一遍又一遍的推倒重来,也进一步加剧了项目本身的风险. 从这一点上来说, 我并不觉得在研发方式上, 我从网易传统的开发团队里学到多少有益的东西. 相反,我觉得这对于一个以技术见长的公司来说, 在开发方式上如此的缺失, 是一件让人很遗憾的事.

但是, 网易的开发团队,与其他公司的开发团队, 最大的一个不同点, 就是: 务实. 而这一点, 我认为是作为一个技术出身的人所必须具备的品质. 只有务实的人,才会沉下心来认真思考自己眼前正在走的路. 浮躁的人, 是不可能以高效的方式作出高质量产品的. 我很感谢网易, 是因为, 在来网易之前,我也是一个浮躁的人, 是网易, 让我变得踏实, 让我养成了务实的工作作风, 让我学会了应该以什么样的心态去面对自己所从事的职业:尊重这份职业, 并以此为荣.

我们组的重大转变, 我认为应该是发生在去年8月采用scrum的开发方式后,是叮当将这个开发方式介绍给了我们, 而我们也终于没有辜负叮当的好意, 将这种开发方式引进, 改造成了适合我们自己的方式. 从这个意义上说,我觉得是叮当再一次拯救了我们组, 真的很庆幸有这样敏锐的领导者: 总在那个非常关键的十字路口告诉我们应该朝哪个方向走.

为什么说这种开发方式给我们带来了这么大的变化呢? 因为, 它绝不仅仅是一种开发方式, 它是一种开发哲学的外在表现和具体应用, 而这种开发哲学非常适合网游行业. (下篇再接着就这个问题细谈)

我心中的敏捷(2)----我们的实践

引言: 

第一篇文章，说到了敏捷方法论和世界观的问题，看似有点玄了，其实，任何一个可以坚持下去的人或者任何一件可以坚持作下去的事，它的背后，都一定有一套自己的逻辑体系在支撑，而这个逻辑体系，就可以看作是它作事作人的方法论．敏捷二字, 其含义有两层: 高效率, 高质量.其目的也绝不仅仅在于"快"研发, 它的终极目的, 是推动整个产品或者公司团队加速面向市场提供好产品的速度和质量.在这一篇文章中，将会详细谈到我们自己的具体作法，当然，这已经是一年前的文章，很多作法可能已经因应现在的形势进行了改进，但基本的思想已暗含其中。你的作法可能与此不一样，但任何已经学会驾奴开发过程的同仁应该都会明白这些作法背后的含义。

 

正文:

敏捷开发, 最最主要的, 是要理解敏捷的本质是什么?  在我看来, 敏捷的本质, 很简单: 如何快速出东西, 快速的出质量高的东西.

由此, 我认为开发过程中的所有东西, 都应该围绕着这两个主题展开: 快速, 质量.

写程序写了这么多年, 我们大家可能都有点感受: 写得越来越没感觉了, 写得越来越麻木了. 因为, 随着自身的成长和成熟, 很多开发过程中会出现的常规难题, 被我们一一攻破, 似乎在我们眼前的路, 已经没有了太多的挑战, 技术难度的挑战.

为什么会有这种感觉? 在这里, 我要毫不客气的指出: 那是因为你把自己仅仅当成了一个有任务就作, 无任务就闲的技术人员, 而非产品人员. 当你把自己定位成一个产品人员之后, 你才会知道用户需求是如此多而复杂, 我们还有如此多的事要作, 要去作得更好.

什么是技术人员? 什么是产品人员? 

我给一个狭隘的解释: 
技术人员, 就是只泡在技术的单纯世界里, 而不太注重用户感受以及用户体验的人, 他们把攻克一个技术难题当作是对自己能力最大的肯定; 
产品人员, 是指从产品出生到投放, 都一直能为用户考虑, 为用户着想, 在每一个细节上让用户爽而不是让开发者自己爽, 他们把用户口碑当作是对自己能力最大的肯定.

那么, 我们要作什么样的人? 要作什么样的技术人?

对于一个研究院所, 他可以选择成为一个单纯的技术人员. 但是, 如果放在绝大多数直接面对市场的大中小企业里, 他就必须选择成为一个从产品角度考虑的技术人员, 要让自己成为产品人员. 

我坚持认为, 技术有没有价值, 不是靠别人推荐, 不是靠专家认证, 也不是靠发了多少研究论文, 而是技术本身有没有在创造价值, 有没有很好的在创造价值. 我是一个彻头彻尾的实用主义者, 我鄙视所有的学院派.

马云说: 找人, 首先, 要找价值观相似的人. 而什么样的价值观才是相似的? 

马云, 从一个企业管理者的角度, 认为跟他价值观相似的应该是这种人: 进入阿里, 就要想着长期耐得住寂寞的作下去, 作对社会有推动的有价值的事, 不要只想着钱, 不要只想着干几个月就走人.

而我, 除了认同他的这些观点之外, 想在招技术人员方面额外加一点: 我们不要学院派. 我把这一点同样视为价值观是否相似的一个基本考核点, 单纯的学院派, 不适合来我们团队.

在网易, 我们的团队, 是一个狼性文化十足的团队, 这在现今的网易, 可能是一个非常独特的特例. 但是, 我们正用自己的成绩, 效率和质量来证明着自己. 没有狼性文化的团队, 注定无法成长; 而没有狼性文化的公司, 也注定无法壮大.

我先介绍一下我们的作法. 在我们这整个项目中, 配备了接近10名程序, 5位QC(质量测试), 近10位策划. 根据项目内容, 分成了五个小组:A, B, C, D, E. 平时的工作, 是将整个项目内容拆解, 各个小组平行推进. 这是我们总体的人员分配.

我所在的组,是D组, 我们的程序有两位, 一个客户端, 一个服务端, 其他人员: 一个QC, 一个策划. 我们组共计四人. 我们小组, 从7月份开始,接手作游戏内的一个比较大的群体系统: 势力系统. 这是比公会系统更为庞大和繁杂的系统, 是将来带动玩家互动的主要系统之一.在接手这个新系统时, 我就在尝试一种新的开发方式.

原来的开发方式是:
策划人员出策划案, 程序将策划案实现, QC对已经实现的系统进行测试.

我们现在的方式是:
策划人员出策划案, 所有人员对策划案进行流程模拟, 找问题, 程序开始带着QC一起设计, 程序将系统进行实现, QC对系统可行测试.

而更具体的步骤是:

1. 策划出案子;

2. 所有人员(程序,QC)通读案子, 各自模拟流程进行推导, 看有没有破绽及断层之处, 提交策划人员进行修正; 修正完后, QC开始进行测试用例设计.

3. 程序制定数据包协议, 对协议进行走读: 向其他程序, QC以及策划讲解这个数据包过来之后会如何进行处理,包括要进行的判断, 要作的逻辑, 以及广播包要发的玩家对象范围. 这一步, 最大的好处, 是让每个参与者都明白我们的逻辑底层到底是如何走的.

4.程序设计关键数据结构, 这一步, 是带着QC一起作. 一个程序功能, 就两点: 数据结构+算法. 而首先,最主要的是决定采取什么样的数据结构, 数据结构进一步决定了采取什么样的算法. 这个数据结构, 其意义已经超出程序代码本身,这个数据结构会牵涉到QC, 牵涉到策划. 在我们这个项目中, 数据结构最主要的内容就是各种各样的配置表, 这个表的内容应该含有哪些内容,这些内容应该如何组织和约定, 就成为提高程序,QC和策划工作效率的一个重要环节.

5. 程序对功能进行逐块实现.但在这里的实现, 也会有多种不同的方式. 我们的作法是: 先实现最基本的功能, 让客户端和服务器端能尽快联调起来,然后各自发布一个基本流程版本给对方: 客户端给服务器端发布一个可用的客户端, 服务器端发布一个可用的服务器给客户端,两个人分别用这个可用的版本进行各自的细节完善.

6. 程序实现功能后, 按照QC之前设计的测试用例对自己作的程序进行自测. 由于时间及专业有限, 这种自测, 主要是测关键逻辑及易错部分, 全面的覆盖性测试还需要依赖QC人员自己完成.

7.程序自测完成后,  带QC及策划人员进行代码走读, 将产品正式交付QC进行测试. 之所以在这个环节加入代码走读这一项, 其目的也只有一个:让项目的每一个参与者, 都能非常清楚程序底层到底是如何实现的. 这一点, 对QC进行全面测试非常非常重要, QC在进行代码走读之后,可能会对当初的测试用例进行修正. 当然, 这里的代码走读, 还是具有一定技巧的, 因为QC和策划毕竟不是专业的技术人员,对于算法和太深层次的技术细节可能并不容易理解, 所以, 这里的走读, 要作到既能让他们能理解关键逻辑,也要让他们不要因为无法理解众多技术细节而出现过多的懊恼情绪, 这也会影响工作效率.

8. QC第一轮测试完成后, 策划人员对已经实现的功能进行游戏体验, 提出修正和完善意见.

以上, 就是我们在实际开发中所采用的一套完整的方式. 其核心思想有几点:

1. 让项目的每一个参与者, 都成为项目本身的主人. 这种主人翁思想的植入, 是通过让他们每个人都参与到项目的各个环节中, 让他们每一个人都仔细了解项目的每一处细节实现来体现.

2.将QC的优势发挥在开发设计期, 而不是后面的交付期. 因为到了交付期, 其实, 产品已经出来了, 如果到那时发现问题要进行修改,其带来的代价将远远大于开发期的修改. QC的测试用例, 以及"测试式思维", 是对程序人员固有思维方式的一个非常有利的促进和监督.

我们的开发方式还在不断的总结和完善中, 还有很多很多我认为非常有效的方法和感悟想和大家分享, 在下篇文章中再接着谈.

我心中的敏捷(3)----两种世界观

引言：

“实践、总结，再实践，再总结”，我的很多研发观念，都是在这样的过程中不断形成和改进的，而我之所以能坚持这样不断作下去，是因为我想把一件事不断的作得更好，一直逼近我自己想要的极致。而事实上，因为每位开发者所在的领域、所掌握的工具、所面对的客户都可能有所不同，采用不同的开发方式本身就是非常自然而然的。其实，我的这个系列文章，有一部分是在说研发，而更重要的一部分是在说我们应该以什么样的思想、什么样的态度，以及什么样的方法来作事，而无论“这件事”是研发，还是销售，是产品，还是公司，我想，很多的东西，都同样适用。经过前面一虚一实的两篇文章后，下面引出的这篇文章仍然偏向于“虚”，仍然偏向于方法论，至于对大家有没有用，要看大家思考的深度和探索的力度。

 

正文：

"敏捷开发"中的"敏捷"二字, 其最本质的含义是: 对用户需求的快速响应. 而其产生, 发展乃至壮大的前提是:随着信息化进程的不断推进, 有信息化需求的企业和用户, 也在不断提高自己提出IT需求的能力, 他们的需求不仅越提越专业, 而且, 也越提越快,经常变化和更新. 作为一个系统实现者, 作为这个商业生态圈的服务提供者, 你无法否决用户提出的需求, 你所能作的, 很多的时候,也最多是建议用户多给你点时间来完善, 让用户多交点钱. 而你, 该作的, 还是要作. 推而论之, 在这种情况下,谁家能更快更好的响应用户不断变化的需求, 谁就能争取到用户.

从本质上说, 敏捷开发, 是一种非常务实的开发方式. 这种"务实"可以通过以下方面表现出来:

1. 它强调对于用户不断变化的需求一定要尽快的快速响应, 虽然用户需求的频繁更改是让开发者最为恼火的, 但是, 没办法, 作为一个商业行为, 无论你的用户提出什么修改需求, 你都要尽量满足, 只有这样你才能争取到用户, 才能让项目带来利润. 

用户关注的是"他自己是否能用这个系统给自己带来好处", 用户始终不会关心"开发者因为这项修改将付出多大的代价". 虽然不近人情, 但作生意就是这样.

2. 敏捷开发的兴起, 是因为创建者们发现很多用户的很多需求在很多的情况下是无法事先全部预想好的, 是在开发过程中不断完善起来的. 传统的瀑布开发模型, 强调在开发之前先建立完整以及完备的开发计划和开发内容, 强调"先规划再开工", 是一种先全部计划好了, 然后再按步就搬进行操作的方式. 而敏捷开发, 更相信世界上根本不存在多么周详的计划能把所有的事情在事前全部计划好, 它相信, "需求变更本身就是需求存在的一种形式". 

所以说, 传统的瀑布开发模型与敏捷开发模型相比较, 在形式上, 可能是一个先全面计划再执行, 而另一个是先计划一部分然后即刻开工, 在开工中不断完善; 但是在本质上, 这两种开发模型却代表了两种完全不同的开发世界观, 甚至就是开发者的世界观的反应: 

前者假设世界太美好, 假设自己太强大, 假设团队太牛B, 一切都能搞得定, 所以, 他们设想着所有的东西只要列得出来, 就能按计划完成; 

后者假设自己并不强大, 假设团队也不是万能的, 假设用户需求肯定是会变化的, 假设用户本身还需要不断学习和提高,假设用户自己可能都搞不清自己想要什么样的系统, 假设要想作出用户想要的系统只有在作的过程中与用户不断交流与确认,假设这种交流是不可能一次性完成而是一项长期的任务, 长期到甚至在软件交付了以后也仍然需要不断追踪用户需求的最新变更. 

瀑布开发, 假设世界是无限美好的, 一切尽在掌控中; 而敏捷开发, 则假设世界本身是有缺点的, 而且, 有不少东西是我们只能影响但掌控不了的. 相比较而言, 敏捷开发的开发思想就要来得更为务实和坦率.

在瀑布模型中, 一旦发生需求变化, 给项目带来的风险是巨大的. 而如果不变, 那很可能作出来的东西就不是用户想要的东西,那这个东西对于用户而言还有什么意义? 所以, 在瀑布开发模型中, 不管开发团队愿意不愿意接受需求变更,这种变更的客观事实已经给项目本身带来太多的风险.

而敏捷开发呢? 是不是就没有瀑布模型的那些开发步骤: 需求提出-->需求冻结-->需求实现-->实现评估? 答案是否定的, 敏捷开发当然也会有这些过程, 但是, 敏捷开发对于瀑布模型最大的改进在于: 把瀑布模型中的大版本切成敏捷开发中的一个个小版本, 从而大大缩短软件发布小版本的时间周期, 始终坚持尽最快速度向用户提交一个最新功能的版本, 让用户在体验中不断与开发团队共同完善. 

而不是象瀑布开发模型那样, 用户提出了需求后, 开发团队闷头作一两年, 发布一个很大的很全的但可能是不合用户本意的系统. 敏捷开发的发布周期通常是两周到两个月, 它不要求每次都要发布很多的内容, 但它要求最好要向你的最终用户频繁发布你的最新版本. 

所以, 从这一点来看, 敏捷开发与传统开发, 最大的不同点正是在于"敏捷"二字, 而其对用户的具体表现就是: 用户可以拿到新版本的周期由一两年大大缩短到了两周到两个月.

我心中的敏捷(4)----多样的形式与不变的本质

引言：

前面几篇文章中，都在不断重复着＂敏捷＂二字的真正内含，是的，如果要说起这些所谓的内含，应该没有人会反对，但是，如果把这个问题再引申一步：如何理解各种各样的敏捷开发形式与敏捷方法论之间的关系？如何把书本上总结的各种各样的敏捷理论用于我们的开发实践？这些问题，可能就不再是那么容易回答的了．在本篇文章中，将会阐述我对这些问题的理解以及我的实践解决之道．

 

正文：

事实上，当大家把软件当作一件“工程”的事来作的时候，很多东西就开始变味了。按理说，软件开发是一件极具创造力的事，而写程序的我们自己也应该是每天生活在充满想象和幸福感的氛围里，而现实恰恰相反，我们总被这样那样的需求折磨得人不人、鬼不鬼，不断的修改设计方案，不断的调试代码，我们甚至变成了连打字员都不如的一类人：因为打字员只管快速击打就行了，而我们还需要不断地在既有的方案和新产生的需求里走钢丝，尤如穿针引线般地通过各种让我们自己和后来人都痛苦的所谓“技巧”来实现新的需求以及保持既有框架的稳定。

 

当需求变得越来越不可控，当软件开发变得越来越依赖个人经验之时，我们希望能有一根稻草将我们这些受苦受难的ＩＴ技术人解救出去。于是，软件生命周期，软件工程化管理，瀑布开发模型，敏捷开发模式等等等等，在实践与理论的交织过程中，我们发明了一个又一个新方法来不断适应真实的业务开发需求。从这个意义上来说，敏捷开发模式，可以称得上是软件开发领域的一件具里程碑意义的大事件，因为，它把开发本身还原成它本来所应该具有的那个样子，它承认了现实的复杂性，它也务实的提出了很多具有指导意义的具体开发方式。

 

在国内IT技术翻译界里，对“敏捷”一词的翻译，我想，是为数不多的几个好词之一，仅凭这一个词，就已精确表达了这一方法论下所有开发方式的起始和归宿，那就是：以“敏捷”的开发方式，带来“敏捷”的产品交付速度，最终带来“敏捷”的公司发展速度。

 

不管是XP，SCRUM，Crystal，ADD，FDD，还是DSDM或者RUP，形式可能多种多样，但其本质从未变过，那就是：让不可控的产品研发，变成可控的；让慢如蜗牛的开发，变成快速的；让杂乱无序的开发，变成秩序井然而让人心情愉悦的。

 

我们自己的开发框架，采用的是SCRUM为主体，但会根据需要临时在某个阶段或者某些同事之间采用XP的方式。“某个阶段”，是比如：我们想让某一块的关键代码，能被两个人以上的同事了解、熟悉并掌握，那么对这一块代码的开发，我们就会鼓励大家采用XP的方式来完成。而当这块任务完成后，就又恢复成既有的方式。

 

我们采用SCRUM方式时，并没有机械照搬它本身的多种职位设定以及人员设定，最主要的，我们是学习到了它的“神”：那就是，我们讲究充分授权，同时，强调关注结果，只对结果负责，且，结果要是明确的，可达成的，以及可周知的，逐渐的，要作到结果是可控的。而，作开发的人都会了解，对于一个经常变换需求且对发布周期要求苛刻的项目来说，“结果可控”是多么重要。可以这么说，如果“结果不可控”，那这种项目，只有死路一条，而这种团队，其最终结局必然是解散。

 

老实说，如果是一个新团队，一开始就采用我们现在这样的作法，那可能会遇到比较大的阻碍，因为，在我们的开发方式里，对个体的专业素质要求比较高，“独挡一面”几乎是团队成员的基本要求。也就是说，无论你原来作的是哪方面的内容，在既有的框架下，把你放在新的任务环境下，也要求你能马上适应，快速在新环境里出成果。

 

但是，不是每一个人，以及每一个团队，都能达到这种状态的。很多的团队，特别是初创团队，需要面临的，首先是团队成员专业素质不高的问题，而这一点，如果试图通过教育、辅导的方式来提高，其效果是比较缓慢的。所以，比较好的方式，是由老人来带，把一些作事的正确方法，一些良好的专业习惯，通过言传身教的方式传递给新人，最终把他们一个个都培养出来。我们的最终目标，是让团队里的每一个人，都能在某一方面独挡一面，当我们跟他们中的任何一位一起作战时，我们都可以放心的把自己的后背交给他。

 

我们自己的团队，也是这样一步步走过来的。刚开始，我们也是一群毫无经验的初生牛犊，我们比别人幸运的是，有比较好的公司背景和资源可以支持我们在这么长的时间里去失败、摸索与提高，而我们比别人优秀的是，在这个过程中，我们从没有退缩和逃避，也没有得过且过，而是在这将近四年的时间里，不断寻求着精益求精的方法，不断改进着我们每一天的工作，甚至，我们对自己在质量、安全和稳定方面的要求，已经到了刚来的新人不可理解的BT程度。是的，只要影响到安全、稳定和质量的再小的细节，我们也不会让步，更不会得过且过，放这些代码的丝毫一马。这，是我们的底限，不可逾越。

 

“效率，效率！质量，质量！”，每当我们在审视自己的实践与书本上的理论貌似“脱节”之处时，这两个词就会不断的出现在我们的脑海中，这也成为了我们作出正确选择的最主要的两个参考坐标。

 

有很多人，工作没激情，没效率，是因为他们的项目没有压力感，他们的工作没有生存的压力感，作好作坏不会对自己的前途造成太大影响，作多作少不会对自己这个月的工资带来多少波动，他们总说项目没前途，公司没前景，他们总想着，混点时间出来骗点所谓的“时间积累出来的经验”，然后跳槽换个大一点的公司，找一个工资更高一点的工作，如此往复。

 

而事实上，我想说的是，无论你换到哪一家你想换到的“大一点的、待遇好一点”的公司，你最终能从这个公司里获得的东西，永远只是因为你对公司贡献了多少价值，而我相信，你那些没有太多有价值经验而浪费掉的时间，对于这些新公司来说，也同样是没有价值的。

 

而如果，你想让自己将来更有价值，就应该马上从现在起，让自己每一天的工作开始有效率起来，不要总想着用在公司的时间作更多公司外的事，不要总想着在上班时间看更多与当前项目无关的技术书籍，你所最需要作的，就是把每一天你的老大，你的老板安排给你的事，作好，作到极致！人，总要先有付出，而后才会得到回报的。不要再抱怨待遇不好，不要再抱怨公司没前景，如果你想找个有前景的公司，那你自己就要首先成长为一个看起来有前途的家伙。

 

扯远了，本来是想说敏捷来着，竟然谈起了理想和人生，汗！好吧，其实，我是想说，我们现在在谈的，绝不仅仅只是一种写代码的方式，或者一种作软件的方式，更深一层次的，它会关联产生其它很多很多的效果，而这些效果，可能是现在的你连想都不曾想过的。千里之行，始于足下。如果想让自己变得更有价值，就让自己每一天的工作更有效率起来，而真正属于你自己的“敏捷”，其实是你自己在思考和分析了自己当作工作流程、工作环境的情况下，作出的真正符合你自己实际情况的解决方案，绝不是那些书本上所说的各式各样的理论。