银行移动产品从团队敏捷走向产品敏捷

中国银行业的数字化转型刚刚拉开帷幕,移动产品成为了中国银行业的新战场。为在新战场占有一席之地,各家银行开始纷纷尝试自己移动产品的敏捷转型,更有甚者开始重新组建IT团队,用敏捷的方式重做原有的手机银行产品。

但这些转型往往在6-12个月后显示出明显的疲态。基本的实践都已经导入了,团队似乎已经“敏捷”了,但产品的响应速度并没有变快多少(想法的提出到上线的时长),产品的线上月活也没有显著的提升。那么敏捷转型到此就结束了吗,敏捷转型的下一步我们又该做什么?这篇文章作者将以多个实际案例出发,为大家揭晓银行业的移动产品如何从团队敏捷走向真正的产品敏捷。

团队敏捷是必要的,它是产品敏捷的必经之路

银行移动产品的敏捷转型很难一蹴而就,团队已经适应了“慢节奏”,习惯了阶段式的开发方式,敏捷的导入,无疑是一场变革。大规模的灌入标准化实践,最后的结果只会是“有形无实”,就像办公室中贴满五颜六色便签纸的白板,最后都沦为装饰品(数周也不更新)。

团队敏捷作为敏捷转型的第一步,以了解团队、分析痛点为前提,定制化的导入实践,让团队从传统向敏捷的开始转变。转型团队敏捷聚焦IT研发团队内部,包含产品、研发、测试人员,目标是:

  • 打造出一支敏捷迭代运作的IT研发团队
  • 建立团队级的敏捷流程及工程方法
  • 以及初步形成内部改进的种子力量

以50人的手机银行团队为例(4个全功能团队),团队敏捷从开始转型到稳定运作会持续4-8个月的时间。具体的转型过程就不在这里多做论述了。如果您的团队已经满足了以上的3个目标,那么恭喜您,您的团队已经迈出了敏捷转型的第一步。

产品敏捷的目标

“创业像开车,而不是发射火箭” ——埃里克 莱斯(精益创业的作者)

做产品也是一样。环境变化太快,产品很难像发射火箭一样,经过长时间缜密准备再发射验证。产品要像开车一样,有一个前进的方向,之后在行驶过程中根据外界的变化快速做出调整并验证,产品敏捷的目标也将聚焦于此。

  1. 帮助产品构建像“开车”一样,可以根据外界变化做出快速响应的能力;
  2. 在产品演进的过程中,帮助产品选择相对正确的“行驶”方向,帮助产品实现“弯道超车”。

很显然,团队敏捷,主要聚焦于研发团队内部的改进,对以上两点的影响并不大,更像是敏捷的萌芽和生长阶段。产品敏捷是以上述两点为目标,端到端(想法的产生到功能的上线)的分析及改进整个产品的实施过程,像是敏捷的开花结果。

走向产品敏捷的三个关键点

一、构建产品快速响应的能力

产品TTM(Time To Market)的长短体现了产品的响应能力的高低。以TTM的持续缩短为目标,是整体转型的关注点从“资源效率”到“流动效率”的改变,分析“流动单元”在产品端到端的实施过程中的流动情况,找到瓶颈点并加以改进,来持续提升“流动效率”,是转型的关键,主要分为3个步骤:

  1. 分析并定义产品端到端的实施过程;
  2. TTM的相关数据采集;
  3. 基于VSM的持续改进。

步骤1:分析并定义产品端到端的实施过程

团队敏捷中我们聚焦IT研发团队内部的迭代运作,在产品敏捷,我们需要以版本为维度,以需求为“流动单元”去梳理并定义端到端的研发过程,关键点是将产品版本与研发迭代融合

如下图,以某金融产品按月发版,研发双周迭代为例。需求分为Epic,Story两个层级,Epic为解决一个用户问题,Story为实现Epic的功能拆分。在版本迭代,我们关注的是Epic的流动(一个版本会包含多个Epic),从想法的提出,到最终的上线。在团队迭代来研发产品,我们关注于Story的流动,从Sprint Backlog的确认,到功能的持续交付(SIT环境)。端到端的实施过程覆盖了所有活动、产出件及流程流转,每一项都有自己独特的意义,每个产品的运作方式都有可能不同,重点是加强各个角色间的协作,使得团队适应该种运作方式,可以稳定的运作。

(某金融产品 产品端到端实施过程)

步骤2:TTM相关数据的采集

数据采集的前提实施过程梳理清晰且团队稳定运作。根据实施过程,我们可以清晰的得出Epic和Story的两条价值流,如下图。TTM是每个Epic从概念到上线的平均时间(如果Epic都是运营类的小需求,建议做合并成一个Epic)。当然Story的大小我们是可控的,Story的产生到集成测试完成的时间我们也要关注。

(某金融产品 Epic、Story的价值流)

数据不是通过WorkShop的问问答答就能得出的,需要借助电子工具的辅助,做准确的分析。首先作者对于电子工具的态度是:工具是辅助运作,而不能影响运作,不能出现由于电子工具的限制而改变运作结构。电子工具的目的是便于过程管理及可视化。

作者推荐的工具是Jira,Jira的优势在于可以通过配置实现高度的定制化,以及开放API数据接口(商用版)。作者建议抛开Jira中大部分的预定义好的模板及元素,根据现有的运作方式,做深度的定制(例如Story元素的重新定制)。从Jira中“问题属性”、“字段”、“界面”、“工作流”、“权限”等的自定义,到Jira Agile中的“看板”,“阶段”,“移动规则”等自定义。由于是相对于底层的定制,所以配置起来比较复杂,这里要保持开放的心态。

如下图,根据运作方式,在关键节点引入Jira做管理,并且根据运作方式,确定Jira的使用规则。

(某金融产品 配合运作方式的Jira使用)

在上线了2-3个版本后,我们就可以尝试做数据的采集及分析,Jira提供了方便的API接口供我们提取数据,要注意数据清洗及公式的配置,最后得出每个版本的TTM时长。

步骤3:基于VSM的持续改进

我们使用的实践是精益中的VSM(Value Stream Mapping)价值流图,来做持续的改进。通过Jira中的数据,建立Epic和Story的价值流图。以Story为例,如下图,数字为Story在该阶段的平均停留时长(天),按照迭代做分组。分析数据找到可能的问题点,很明显前4个迭代“待联调”和“测试中”的用时很长,之后去做该阶段的原因分析并尝试改进,再分析新的数据(第5个迭代的数据提升),以做到团队的持续改进。

当然了这里面的问题点是多样的,组织、需求、管理、技术等因素都可能成为问题的原因,这里的重点是找到核心问题,拿着数据证明去尝试解决,最终也可通过VSM也来体现我们的转型成果,这也是真实的量化的数据。

(某金融产品 前5个迭代,Story的VSM)

电子Dashboard。持续的Excel取数很难做到实时。尝试做电子Dashboard,做到价值流实时可视化,便于信息的透明化及持续改进,为提高产品的响应力打下坚实的基础,详见下图。

(某金融产品 价值流Dashboard)

到此阶段,您的团队已经有一套端到端的稳定运作方式及电子管理平台,可视化的VSM来体现问题点及成果展示。剩下的就是大胆去做瓶颈的原因分析及改进,来持续的提升产品的响应能力。

二、帮助产品实现“弯道超车”

金融科技企业对中国银行业的冲击是巨大的。多家传统银行直面差距,定义自己的移动产品策略是“追赶”,产品经理的惯性思维,“XXX有这项功能,做了这项优化,我们的产品要把它加上”。当然了如果落后,追赶固然没错,但在追赶的过程中我们也要制定赶超的策略。

金融需求无处不在,衣食住行娱每个细分场景都有金融需求出现,对于传统银行,信誉,数据、网点、存量用户等都是自有的优势。那么结合用户的需求与自身的优势实现金融产品创新,才是“弯道超车”的关键

利用设计思维的方法来获取、定义及实现用户的需求。扭转业务、产品、研发等角色的本位思维,从提出需求走向了解用户痛点,从实现需求走向为用户创造价值。

(设计思维的双钻模型)

建立产品内部的创新机制,抛开传统银行自身的限制,鼓励全员创新。如下图,从一个创新想法,到MVP的制作验证,最快只需要3周的时间。立项通过的想法进行2-3个月的孵化验证,最终有望形成新的商业产品。过程中给予创新者创新教练、团队资源的专项支持,内部创新的同时也在培养团队产品思维,提升团队的产品能力。

(某银行的内部的创新机制)

三、培养内部教练队伍

这个是敏捷转型的基础,需要进行管理、技术、产品、创新等内部教练的梯队建设。组织中缺少的是经验积累及专有人才,而不是流程规范。之后作者会以专文来讲述企业内部教练的体系建设。

总结

在移动金融产品的新战场上,银行的移动产品需要从“发芽生长”的团队敏捷,走向“开花结果”的产品敏捷。

三个关键点助力产品迈向产品敏捷:

  1. 通过产品开发过程端到端的梳理与定义,电子工具的引入,基于VSM的持续改进,来持续缩短产品的TTM,构建产品快速响应的能力;
  2. 使用设计思维打造产品,并建立产品内部的创新机制,来实现金融创新,帮助产品实现“弯道超车”;
  3. 建立企业内部的教练体系,注重人才培养及积累经验,来推动敏捷的发展,促使产品持续进步。

最后,希望中国银行企业把如今市场中的不确定性,看做是产品的新机遇。对于这种新机遇的驾驭的能力,将成为产品优胜劣汰的关键。


更多精彩洞见,请关注微信公众号:思特沃克

Share

一名ThoughtWorks咨询师的心路历程

还记得2015年初我在红螺寺许下的新年愿望:事业顺利、家庭和睦。验收标准分别是:

  • 事业顺利:我能够加入ThoughtWorks
  • 家庭和睦:“造人”计划顺利进行

如今,我已加入ThoughtWorks一年半,宝贝女儿澄澄已经七个月大。

PS:笔者每年都会去红螺寺还愿、许愿。

缘起

在加入ThoughtWorks前,笔者在互联网企业里做内部教练,同部门的同事们中有几位是ex-ThoughtWorker,他们和周围的同事实在太不一样,他们太优秀、太任性、太奇葩…跟他们的合作颠覆了我对于软件开发的认知以及整体的思维习惯。

被颠覆的我之后也加入了ThoughtWorks,加入了咨询团队。还记得刚进公司时,每当我碰到一个HR,都会得到善意的提醒,“这里的人都是奇葩,你要做好准备”,当时我心想,“老子都已经跟奇葩们一起工作3年了,还有什么可准备的,老子也是奇葩…”。

后来我被事实打脸,事实告诉我,由于企业文化和团队环境的不同,我遇见的ex-ThoughtWorker们还是压抑住了自己的天性,而在ThoughtWorks的文化下、在咨询团队中,你会获得最大程度的自由。同时由于你做的是咨询工作,在多重压力下,你的能力会得到极速的提升。这种成长和文化是我之前从未见到过的,我希望可以用我的文章带领读者们走进神秘的ThoughtWorks咨询团队。

PS:这里不得不提一下,2012年ThoughtWorks被评为全球面试最难的IT公司,第二名是Google。(此为科技博客Business Insider撰稿人Julie Bort依据美国雇主评价网站Glassdoor.com提供的数据所评)。

咨询?

ThoughtWorks是一家服务型的IT公司,交付和咨询是中国区的两项核心业务,分别用一句话介绍两个业务:交付的核心是帮助客户解决问题,而咨询的核心是为客户赋能。

由于工作性质的不同,咨询多以单兵作战或pair为主,交付则以团队协作为主,在ThoughtWorks中国区的近1000人中,咨询团队不到100人,其余的多数是交付团队的同事。

在咨询团队中,分管理、技术两类咨询师。管理咨询以企业战略层面的投资组合管理\创新管理、产品及组织层面的结构治理\需求管理\设计思维、以及团队层面的运作管理框架为主。

技术咨询则以技术架构治理、DevOps、“黑科技”的研究以及技术实践为主。当然这两者并非完全独立,管理和技术实际上会有很多交叉,同时ThoughtWorks也不会约束你的工作范围,笔者是管理咨询师,最近在带领客户做CI Dashboard(当然过程中受到了很多技术教练的帮助)。

入门

初入咨询团队时,新咨询师会有一段适应时期,这期间会有一位老员工来充当你的buddy,buddy的目标是协助你顺利度过6个月的试用期,他主要的职责是帮你融入团队及提高自身专业技能。

之后你可以在内网上阅读并学习相关资料,可以去国内交付项目了解最佳敏捷实践的运作方式,也可以通过shadow老咨询师去了解ThoughtWorks咨询的套路。这个时间大概是3个月左右。ThoughtWorks十分鼓励员工持续学习,甚至可以在工作时间去学习(看书、看视频等),这在我之前的公司是很难看见的。

所以刚加入咨询团队的新咨询师在这3个月左右的时间里需要抓紧时间去学习,去融入团队。

出师

通过3个月左右的持续学习,作为咨询师的你已经可以选择合适的机会出师了。ThoughtWorks咨询的rate很高,客户请你来一定是解决复杂问题的,在他们眼里你是一个上通天文下晓地理的专家,而且客户一般在同一领域只会请一个人(单兵作战)。

所以在去之前,你需要做好充分的思想准备,对于复杂问题的解决,不是固定套路就能搞定的,需要不断的根据客户期望以及现状,调整你的计划甚至目标。在整个敏捷转型的过程中你一定会遇到很多问题,这些问题多数是需要咨询师独立去解决,但ThoughtWorks是你坚实的后盾,要充分的利用公司内网、咨询群、buddy,快速学习及成长,带领客户一起攻克难题。

在这个过程,思路一定要清晰,首先我们做的是咨询,做的是赋能,不是用自己的专业技能去为客户做事,而是用自己的专业技能辅导客户自己做事,否则你的影响面以及精力都会受到很大的限制。

其次,一定要充分的自信,公司内网中有无数的案例和资料,咨询群中有一百多名咨询师为你答疑,还有一个与你亲密无间的buddy,没有什么问题是解决不了的。记得当初我上第一个项目,前两周每天晚上都会给buddy去电话,请他为我“指刀”,buddy从未感到厌烦。

出师项目我定位的目标是“生存”,能“生存”的前提是让客户满意。当然了,客户投诉的情况也不少,每个客户的习惯不同,咨询团队对待投诉的态度更多的是反思、总结、提升,ThoughtWorks没有KPI,不会因为你的投诉多了,工资就没了,公司更看重的是你的成长以及客户的满意。

沉淀

在ThoughtWorks咨询团队,每名咨询师的风格/套路都不同,“拍砖型”、“儒雅型”、“教授型”等等风格都可以在这里找到。我们需要去总结并定位出自己的套路及特点(擅长的领域)。还记得我刚进咨询团队时,Team leader给我的第一封邮件是一份书单,外加希望我之后能总结出自己的套路及特点。

套路不是做一两个项目就能有的,也不是可以从别的咨询师那里直接“抄”来的,而是在你做了大量项目,收集了大量老咨询师的经验及反馈后,从中总结提炼出来的最适合自己的套路。而特点取决于你的兴趣与经验,找到自己感兴趣的领域深入下去,形成自己的知识体系。

这个过程我认为有三点最重要:不断总结、刻意练习、主动学习。

不断总结

套路源于总结,在不断总结的过程中清晰自己习惯的套路。在咨询过程中给客户的方案和汇报是少不了的,虽然说很多资料可以通用,但在还没形成自己完整的套路时,我一直坚持原创。这些内容从哪来?从每个活动的总结甚至每天的总结中去汇总,这种频繁的总结对我们的知识积累以及对提升客户体验都是有很大好处的。当然,你也可以先让客户总结,再自己总结。这里手段会有很多,关键点在于是否去做。

刻意练习

刚做咨询时,我们并不是“八面玲珑”,都是有明显的技能短板,例如沟通\演讲能力、危机处理能力、某些敏捷专业能力等等,这些短板如果我们知晓,我们会在客户现场刻意避免,但如果我们不知晓,让客户发现,会直接影响到客户的信任以及咨询的效果。发现短板的方式一般是自己总结以及向周围的同事要feedback,重点是提升自己的短板,方式就是刻意练习,持续集成中有一句话让我印象深刻,“如果做一件事让你觉得痛苦,那么就要更频繁的去做这件事”。

刻意练习就是这样,你需要频繁的去练习你的短板技能,当然这个练习多数是在你非客户现场的时候,你需要抓住时机甚至创造时机去不断练习。但不得不说这一点很难,人的天性并不是这样的:P

主动学习

在咨询团队中有很多的内部活动,大家平常在不同项目中,难以相见,就会抽出晚上或周末的时间进行内部碰撞,例如读书会、实践集、以及各项专题的研讨等等,这些都是完全开放的,自由报名,都是很好的学习平台,相信只有高手过招才会擦出别样的火花,而在这些活动中,我们是真的在“过招”(拍砖),所以大家都在飞速成长,这种活动并不是所有公司都有的,而这个机会,你一定要把握住。

简单总结下,这个阶段我认为的目标是总结并定位自己的套路及特点(当然它不是一成不变的,是个持续改进的过程)。

当你有了自己的套路及特点后,你需要励志做出自己的“金牌案例”,以提升影响力及帮助新人。下面说一下咨询团队的特点及挑战。

团队的特点

自由

咨询团队中的大师(吴雪峰)曾说过“牛人是不需要管理的”,我十分认同这句话。在咨询团队中你所受到的约束很小,这里没有强制的职责划分,以你的兴趣导向为主。没有强制的命令安排,会尊重的你的建议。没有KPI的约束,大胆去做你认为正确的事情,等等。

互相伤害&互相关爱

互相伤害:咨询团队的咨询师在客户现场常常大杀四方,在团队内部也免不了带着这种杀气,这让团队内部的很多活动都“刀光剑影”,就像前文中所提到的,高手过招才会出现别样的火花,团队中很多创新的点子或创意都是在这样的环境下产生的。

互相关爱:咨询团队又是一支极度团结的团队,我们都是一群怀揣相同梦想的“奇葩”,当某一个咨询师遇到困难(各个方面),在咨询群中、电话中、邮件中都可以寻求到别的咨询师的帮助,而大家都毫无保留。

面临的挑战

学习能力

在客户,团队的多重压力下,你需要具备快速的学习能力,你会快速成长。在客户现场你需要短时间内了解客户业务和背景,永远走在客户的前面。在团队中,大家都在跑步前行,就算摔倒了你也要快速的爬起来,用更快的速度赶上队伍,因为你是ThoughtWorks咨询团队中的一员。

纪律性及健康

在咨询团队中,你会有50%以上的时间在出差。你每天会承受很大的工作压力,如果没有良好的纪律性以及生活规律,你的健康将受到威胁。还记得当初出差到深圳,南北的气候差异让我很不适应,家人给我的评价是,“你一放假回家就在养病,养好了出差,回来又一身病…”之后我每天坚持跑步并保证睡眠,情况才有了好转。所以纪律性的好坏会直接影响你的健康以及你的职业生涯。

总结

最后用团队中部分咨询师的语录作为总结:

道长(伍斌):“高手如林,左右逢缘。”

姚安峰:“进入ThoughtWorks咨询团队是一次幸运的选择,和一群充满理想、激情和务实精神的人同路,思想火花和异见碰撞让人快速成长,1年所学胜过过往6年职场。这里也是极具挑战的地方,全球软件领域最顶尖的人才,最前沿的理念,国内最规模化的客户,以及一年近百次启航。”

宇宙青(刘玉青):“自从加入ThoughtWorks咨询这只‘奇葩’团队,便开始了指数级的野蛮生长。在这里人人怀揣梦想,每天都在身体力行,用心改变世界!”

袁大师(袁英杰):“在ThoughtWorks做咨询师最大的优势就是你可以不断面对新的问题、新的客户、新的产品、新的文化、新的人。这会迫使你不断思考,时刻保持状态。你的经验,视野,能力也随之不断变得广阔。”

Share

敏捷宣言到底有几句?

“Hi,A同学,敏捷宣言有几句?”

“4句呀,分别是个体和互动…”

如果你的答案和A同学一样,也认为是4句,那么请你继续往下读,相信此文章会对你有所帮助;

如果你的答案和A同学不一样,认为不是4句或者不知道,那么可以选择性阅读,它不一定会对你有所帮助:)

为什么写此文

当我还是一名敏捷实践的试行者,接触到的第一个信息就是敏捷宣言(非4句),虽然不能完全领悟,但当时的教练让我把它熟记于心,说这个就是敏捷。我想:我终于知道敏捷了;

当我还是敏捷教练时,向大家介绍敏捷,询问都有谁知道敏捷宣言的时候,有部分同学举手,他们的答案和A同学一样。我想:有的喷了;

现在我是敏捷咨询师,接触到了一些企业内部的敏捷实践者,问他们同样的问题,他们的答案也和A同学一样。我想:你该请我们做咨询了;

就在前不久,我听了一些敏捷培训,讲师提到敏捷宣言的时候,竟然都介绍的也只是4句敏捷宣言,之后我饶有兴趣的百度了下“敏捷宣言”的关键字,也询问了周围的敏捷实践者,得到的答复是敏捷宣言就是4句呀,大家都知道的…我忽然意识到此事的严重性。我想:该写篇文章了。

宣言到底有几句

让我们来看一下原版的敏捷宣言。以下是官方的翻译:

敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

也就是说,尽管右项有其价值,我们更重视左项的价值。

数一数有几句?6句。此文并不想纠结于数字,你也许会说敏捷宣言中有4句价值观,这似乎也没错,但问题是你了解其余2句吗?敏捷宣言流传至今,我们心中似乎只记住了那4句,其余的2句被我们天然的屏蔽了,甚至我们还一直在做“敏捷宣言只有4句”这样的知识传递!难道那两句不重要吗?答案肯定是否定的(不重要为什么要写在宣言里…),两句的偏差带给我们的是敏捷转型方向上的错误。让我们来看一下这两句告诉我们了些什么。

我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观。

通过这句我们了解到敏捷宣言是通过不断实践总结出的价值观。价值观不是具体详细的目标及实践,它是在我们心里的一种根深蒂固的思维取向,它会影响我们做出的每一件事情。所以有团队会说,我们现在已经敏捷了,因为我们做了迭代开发,这种单纯的实践=敏捷是不成立的,我们需要多维度的去了解团队的价值观是否符合敏捷的价值观。

虽然右项也具有价值,但我们认为左项具有更大的价值。

这句是敏捷宣言里最重要的一句话。如果你丢了第一句,说宣言有5句,这个还可以原谅。但如果你丢了这一句,那绝对是个错误!在做敏捷转型的过程中常遇到这样的现象:“敏捷说了不需要文档,太好了,我们以后就不用写文档了”,“敏捷说了不需要计划,我为什么要给你计划”,这样实施的后果可想而知,这样的案例比比皆是,这就是敏捷转型方向上的错误。

为什么会有这样的错误呢?原因就是忽视了宣言中的最后一句话。宣言的价值观中英文用了“over”中文翻译是“高于”,A高于B,多数人的理解就是A比B好,那么为了敏捷转型我们就只用A舍弃B,这似乎是字面上的正常的理解,但这不是宣言中要表达的意思。想必当初17位大牛早已预见了这样问题,他们用最后这句强调,给大家正确的引导。告诉大家宣言中的价值观不能理解为取A舍B这样的二分。敏捷的价值观是承认右项是有价值的,不过我们要更重视左项的价值,这不是二分!当初软件开发在不断发展的过程中,大家越来越的重视右项的价值,这时敏捷站了出来,提出在这个过程中我们要更加重视左项的价值,它并不是让我们要放弃右项实施左项。

在我们实际做敏捷转型的过程中,左右两项通常情况下也是共存的,不过我们更重视左项。例如你在帮一个团队在做敏捷转型,你发现产品把需求都录入系统中,告诉大家他的任务已经完成,之后研发按照系统中录入的需求进行研发,期间他们无任何沟通。这时你应该做的是加强他们之间的互动,例如让产品给研发对着系统的需求讲一遍,研发在过程中发现问题立刻和产品沟通,不过度的依赖系统中的描述等,你不能认为宣言里说了互动比工具更重要,就让他们停止使用系统只靠互动,这样团队会“手忙脚乱”,就算团队勉强坚持下来了(且不说效果好坏),最后你会发现数据统计的工作如果没有工具,对团队来说就是一场噩梦。这样的例子还有很多。

总结

作为敏捷实践者、教练、甚至咨询师。敏捷宣言作为基础,我们不能“断章取义”的只记住那4句,甚至还在做只有4句这样的知识传递,我们需要把敏捷宣言中的6句话都“掰开了揉碎了”去理解清晰,尤其是最后一句,来给自己给别人树立正确的敏捷价值观。所以敏捷宣言到底有几句?6句,一句都不能少!

最后我想到了两句话:“天才就是99%的汗水+1%的灵感”和“知识就是力量”,这两句作为的名言警句被流传至今,但如果你只记住了这两句,恐怕无法正确的理解爱迪生及培根当时想表达的意思,因为它们都有后半句:)

ps:感谢我刚接触敏捷时候的教练,他对我正确的引导。他曾也是一名ThoughtWorks的咨询师。

Share