写作驱动学习

本周在公司做了一次内部分享,主要目的是鼓励大家写作。但是作为一个建的博客比写的博客还多的人,心里实在是没什么底气讲这个题目,所以就搜罗了大量的资料,看能不能从前人的智慧中吸取一些灵感,显得不那么无知,结果做下来,收获破多。

众所周知,写作有很多的好处:可以记录和巩固学到的知识、扩大自己的影响力、提升和推销自己等等,甚至很多人通过写作出书,成名,改变了人生的轨迹,这种例子很多很多。至少我每次听到这类的故事都会陷入深深的自省,痛恨自己没有早一天开始行动,然后痛定思痛,立即新建一个博客或是把之前落满灰尘的博客打扫打扫,重新发一篇《新的开始》,然后……就没有然后了。周而复始,自己也慢慢失去了对自己的信心。

所以问题的关键不在于我们不知道写作的好处,而在于我们做不到,就像大多数的鸡汤文一样,要知道“总有一天”是不靠谱的。对于放弃我们总能找到很多理由:没有时间,总有更重要的事情;反正知识已经掌握了;不知道写什么;觉得自己想写的东西不值一提,怕被人笑话等等。后来我想清楚了,归根到底就是四个字:觉得不值,假如有人给我500万让我写篇博客,我想上边那些理由就都不再是任何问题了。

那么什么样的事情是我们心甘情愿想去做的呢?为什么我们喜欢玩游戏而不喜欢写作业?那些我们根本不需要”坚持”就能一直做下来的事情都有什么样的特点呢?想来想去我认为一般要符合两个条件:快速的正向反馈、相对容易

我就曾经疑惑过学习与玩的区别到底在哪?玩游戏可以让我们相对容易的就能短时间内满足生理或是心理上的需求。但是学习首先不容易,有好处但反馈周期都相对较长,我们很难获得比较快的正向反馈。可是有些好学生就非常喜欢学习不是么?因为他们可以从每次考试,每次回答问题,从老师家长赞赏的同学羡慕的眼光中中得到很多正向反馈,而更重要的是这种反馈足够快,所带来的收益已经抵消甚至大过了在学习上投入的成本,这就是为什么好学生会越来越喜欢学习的原因。

我们常说要培养孩子的兴趣,这样他就能某一方面作出成就。我认为这个逻辑反了,应该是先促使或是找到或是暗示孩子在某方面的成就,让他觉得自己在这方面比别的小朋友强,他就能在这件事情上持续获得更多的正向反馈(例如夸奖,奖励,其他小朋友的羡慕),就会越来越喜欢做这件事情,兴趣自然而然的就形成了。

所以说学和玩本质上没有什么大的区别,主要是付出成本和短期收益的差别,甚至通过调整这两个维度学与玩是可以相互转换的。例如每个电子竞技选手每天都要在一个游戏(竞技项目)上玩(训练)超过10个小时,对每一个操作细节都要反复练习,而每提高一点点都非常的困难,每天要被教练训,在比赛中还很难获胜,需要承受着家庭和社会的压力,对于他们来讲,这已经不是在“玩游戏”了,虽然外人看起来没有什么差别。

很多牛人可以通过心智自我管理,推迟幸福感,用长远利益来驱动限制自己的行为。不过那是需要天赋和训练的,对于我等凡人,如果一定要坚持做一件事情我们认为需要坚持才能做到的事情,我认为可行的办法就是:能否找到一种适合自己的鼓励方式能让我们自己在做这件事情的时候能够得到持续快速的正反馈,并尽量把这件事情变得容易。

回到写作这件事情,抛开那些“总有一天”才能实现的好处外,眼前的好处无外乎就是帮助我们记录理解消化沉淀学到的知识了。不过我们的内心里总有一个声音反复出现:反正书看了,Session听了,感觉知识已经学会了,那还值得花时间写么?我用这个时间多学点东西不更好?

李光磊在《知行合一》中将知识划分为信息,知识和智慧。这解开了我很多对于学习的疑惑:为什么我看了很多书还是不会用某项技术?为什么我们听了很多Session,但是感觉却没什么用?为什么同一本书不同人看或是同一个人不同时期看会有不同的收获?原来我们之前所认为的学习只是获取信息而已,如果不思考,不行动,这些信息将一文不值,随时间消失,而浪费掉的却是宝贵的时间。而同样的信息,不同的人或是人的不同时期通过思考转化为的知识也是天壤之别的,所以说书只是一面镜子,我们读的看的其实是我们自己而已。

所以为了真正的学到知识,而不单单的是收集信息。我们需要用行动来将获取的信息加工吸收变为自己的智慧的一部分,而写作算是比较简单廉价的方式了,所谓写作驱动学习,正是如此。就像测试驱动开发中的测试一样,写作一旦完成,理论上就可以丢掉了,发不发布,有没有人看,写的好不好,都已经不是那么重要,它已经体现了它的价值。相信只要能体会到这种好处,不断地用写作来驱动学习,注重积累和推广,那些长远的好处也会自然而然的在某一天突然到来。

最后,不论你觉得上面这段文字有没有道理,它对你来讲只是一段信息,如果没有思考,没有行动,那就只是在浪费你的时间而已了。

Share

说起BDD,你会想到什么?

706-林冰玉-说起BDD你会想到什么

在刚接触BDD(Behavior Driven Development,行为驱动开发)的时候,我以为就是用Cucumber这样的工具来编写场景用例,从而实现自动化测试,甚至很长时间分不清BDD和ATDD(Acceptance test driven development)到底有什么区别。那么,BDD真的就是用来做自动化测试的吗?本文就来跟大家分享一下我理解的BDD。

 

为什么要BDD?

开发软件系统最困难的部分就是准确说明开发什么” (“The hardest single part of building a software system is deciding precisely what to build” — No Silver Bullet, Fred Brooks) 。

场景一:业务分析人员觉得自己分析的需求已经写的很清晰了,并且跟技术人员进行了足够的沟通,可是开发完sign off的时候,发现所开发的功能还是跟期望有差距。

场景二:开发团队辛辛苦苦开发完一个功能,满怀信心的去给客户展示的时候,才发现原来客户需求的功能不是这样的。

这些场景是不是似曾相识?为什么会这样?第一个场景是开发团队内部技术人员跟需求分析人员的理解有偏差,导致大家理解的需求其实是不一样的;第二个场景是开发团队没有真正理解产品经理/客户所提出来的真实需求,导致开发的产品跟需求不一致。其实,产生这两个不一致的真正原因是因为不同角色有着不同的领域知识,说着不同的语言,大家在沟通的时候,如果都用自己领域语言,必然会产生沟通代沟,导致理解的不一致性。

领域知识不同、语言不通导致沟通障碍,这个客观存在的问题该如何解决呢?BDD正是为此而生。

 

BDD是什么?

BDD的提出者Dan North强调BDD不是关于测试的,它是在应用程序存在之前,写出用例与期望,从而描述应用程序的行为,并且促使在项目中的人们彼此互相沟通。

要给BDD下个清晰易懂的定义很难,包括大师们也这么认为,这里试着总结以下几点:

  1. 关注的是业务领域,而不是技术:BDD强调用领域特定语言(DSL, domain specific language)描述用户行为,定义业务需求,而不会关心系统的技术实现。
  2. 不是工具,强调的是一种协作方式:BDD要求各个角色共同参与系统行为的挖掘和定义,以实现对业务价值的一致理解。
  3. 不是关于测试的:BDD源自TDD,但重点不是关于测试,所强调的沟通与协作可以指导更好的做自动化测试。
  4. 全栈敏捷方法:BDD促使团队所有角色从需求到最后的测试验证,进行高度的协作和沟通,以交付最有价值的功能。

 

BDD怎么做?

用例场景的描述格式“GIVEN… WHEN… THEN… ”对大家都不陌生,但用这个格式写出好的用例却是非常的难,尤其是新手。这里总结几点供大家参考:

1.业务层抽取,业务语言描述

根据业务层的数据流,在每个数据停留点进行纵切,抽取出一个个用例场景。描述语言一定是业务领域可懂的,不要涉及任何实现相关的技术细节。所描述的场景一定是从业务层抽象出来,体现真实业务价值的。

2.技术人员可懂,自动化友好

所描述的用例场景要能驱动开发,必须要让技术人员易于理解;要指导自动化测试,还得要求对于自动化的实现是友好的。这一点似乎是跟第一点有些矛盾,但我们严格遵守BDD的格式要求还是可以做到的。其中,GIVEN从句描述的是场景的前提条件、初始状态,通常是一种现在完成时态;WHEN从句是采取某个动作或者是发生某个事件,一定是动词,通常是一般现在时;THEN从句用“应该…(should be…)”来描述一种期望的结果,而不用断言(assert),后者与测试关联更紧密。

3.数据驱动,需求实例化

抽象的业务语言描述的需求,往往由于太抽象而缺失掉很多关键信息,导致不同人员对需求理解的不一致。想要既抽象又能包含细节信息,就需要采用需求实例来描述。简单说来,就是给场景用例举例说明。举例就会需要列举数据,如果在场景用例描述里边直接添加数据实例,那样的用例将会很混乱,可读性和可维护性都非常差。如果我们能够在描述场景的用例里边用一些变量来代替,把变量对应的值(数据)提取出来存为一个表格或者独立的文件,这样将会使得用例的可读性很好,而且也不会缺失细节信息(数据),后期的维护和修改也较为方便。这就是数据驱动的方法来描述实例化的需求。

看几个例子,大家体会一下:

场景一:检查收件箱,可以看出第三个清晰明了且能体现业务价值,比较符合上面的要求。
Scenario: Check Inbox
  Given a user "Tom" with password "123"
  And a user "Jerry" with password "abc"
  And an email to "Tom" from "Jerry"
  When I sign in as "Tom" with password "123"
  Then I should see one email from "Jerry" in my inbox
Scenario: Check Inbox
  Given a user "Tom"
  And a user "Jerry"
  And an email to "Tom" from "Jerry"
  When I sign in as "Tom"
  Then I should see one email from "Jerry" in my inbox
Scenario: Check Inbox
  Given I have received an email from "Jerry"
  When I sign in
  Then I should see one email from "Jerry" in my inbox
场景二:限制非法用户查看某些受限内容,BDD强调什么(What),而不是怎么(How),第二个写的比较好。
Scenario: Redirect user to originally requested page after logging in
  Given a user "Tom" exists with password "123"
  And I am not logged in
  When I navigate to the home page
  Then I am redirected to the login form
  When I fill in "Username" with "tom"
  And I fill in "Password" with "123"
  And I press "Login"
  Then I should be on the home page
Scenario: Redirect user to originally requested page after logging in
  Given I am an unauthenticated user
  When I attempt to view some restricted content
  Then I am shown a login form
  When I authenticate with valid credentials
  Then I should be shown the restricted content
场景三:添加图书到购物车并计算总额
Scenario: Books add to shopping cart with correct number and total price
  Given a book "BDD" with price "30.5"
  And a book "Cucumber" with price "25.8"
  When I select "BDD"
  And I click the add to shopping cart button
  Then I should see one "BDD" in my shopping cart
  And the total price is "30.5"
  When I select "Cucumber"
  And I click the add to shopping cart button twice
  Then I should see two books "Cucumber" in my shopping cart
  And the total price is "82.1"
Scenario Outline: Books add to shopping cart with correct number and total price
  Given book <name1> with <price1>
  And book <name2> with <price2>
  When I add <number1> book <name1> and <number2> book <name2> to shopping cart
  Then I should see book <name1> and <name2> in my shopping cart
  And the total price should be <total>
  Examples:
  | name1    | price1 | number1 | name2    | price2 | number2 | total |
  | BDD      | 30.5   | 1       | -        | -      | -       | 30.5  |
  | Cucumber | 25.8   | 2       | -        | -      | -       | 51.6  |
  | BDD      | 30.5   | 1       | Cucumber | 25.8   | 2       | 82.1  |

BDD的工具有Cucumber、JBehave、Twist、Concordion等,工具的优缺点和使用方法,网上都有丰富的文档可参考,在此不作介绍。

BDD有什么好处?

BDD的作用是把利益关系人、交付团队等不同方面的项目相关人员集中到一起形成共同的理解共同的价值观以及共同的期望值。它可以帮助我们:

  • 关注用户行为
  • 交付最有用的功能
  • 在团队内部维护一致的术语
  • 探究需求实例
  • 编写和维护需求
  • 创建活的文档
  • 消除协作与沟通障碍

 

什么样的项目适合BDD?

  • 简单的一次性项目,沟通交流成本都较低的情况下,没有必要使用BDD;
  • 业务比较轻量,重在技术方面的项目,可以只使用TDD,或者简单的白板上的BDD,不需要在BDD工具记录需求用例文档;
  • 业务复杂、团队成员较多的项目,沟通成本高,BDD很有必要。

 

常见疑惑

1.BDD与TDD/ATDD

TDD是测试驱动开发,ATDD是验收测试驱动开发,都是关于测试的,是与所开发的系统紧密联系的。而BDD则不同,前面提到过BDD不是关于测试的,着重关注需求、关注客户的业务价值,所描述的需求用例是可以独立于软件系统存在的,因为客户的业务是始终存在的,不取决于是否有软件系统来支撑。

2. BDD与SBE

SBE(Specification By Example,实例化需求)是在BDD之后由Gojko提出来的,也是关于需求的,主要强调通过列举实例发现需求中的缺失概念。BDD也是关注需求的,同样会使用实例来描述行为。两者的本质没有区别,只是概念的差异。

Share

在ThoughtWorks做BA是怎样一种体验?

BA,英文全称Business Analyst,也称业务分析师,或需求分析师。Linkedin上BA相关的职位不到产品经理或项目经理的四分之一。到本土的拉勾网、智联招聘等网站上,BA的职位就更少了。那么,

  • BA究竟做什么,有没有必要设置BA这一岗位呢?
  • BA具体会做哪些工作?一天会是什么样?
  • BA有哪些能力要求?BA的职业发展如何?

下面我仅就个人在ThoughtWorks的经历做些分享,可能不能代表所有BA,给大家一点参考。

 

BA做什么?为什么需要BA?

BA顾名思义,就是做业务分析。具体说来,就是能够把业务需求和用户需求转化为软件需求,保证最终的软件能满足用户需求,并带来业务价值。举个例子,

01

在软件开发过程中,大家都知道,需求信息要在很多角色中流转。没有BA的团队,需求大概是这样传递的:

02

大家知道,信息每传递一次就会衰减;况且在图上的每一个节点上,往往不是一个人,多人参与更容易失真。根据《组织行为学》中的相关数据,这样跨五层的传递,大约60%左右的信息能被完整无误地传递了。

而有BA的团队,需求则是这样传递的:

03

BA和每个角色都保持无缝的沟通,尽量在每一个节点向前验证需求,保证沟通的每个环节都是闭环,最大程度地减少需求失真。

目前在ThoughtWorks,90%的团队都会配置专职的BA, 只有少量规模很小的团队(如人数<=5个人),则会由其他角色兼任。

 

BA的一天,大概什么样?

如前所说,BA的工作主要围绕需求来展开。在ThoughtWorks的敏捷团队里,使用User Story(用户故事)来表达需求,所以具体的工作就是用户故事的发现、捕捉、拆分、设计、定义、Kick-off、预验收、演示和验收、上线及反馈等,这个过程中会与客户、用户、设计师、开发和测试沟通协作,确保大家做的是有价值的需求,并且对需求的细节有一致的理解。比如我现在的一天:

  1. 早上8:50到公司,看邮件,理一下今天的todo-list, 可能包括如下项(我当前这个组很特殊,会同时负责2个项目
  • 准备项目A在下周一的Showcase
  • 项目B下个迭代的故事卡 – 需要与另外一个BA再过一遍,确保卡上的细节准确无误
  • 项目A的两个故事卡Kick-off
  • 到客服中心去做用户访谈
  • 跟踪下昨天测试报告的外部服务接口好没好
  • 需要与设计师碰一下,把项目B涉及的UI改版的需求再梳理一下
  • ……
  1. 9:15和客户、团队一起站会
  • 更新自己负责的项目需求状态和变更信息
  • 认真听其他人的更新,及时发现有没有需要自己要澄清或跟踪的需求问题
  1. 9:30-9:45 给组里的新同事解答业务相关的疑问
  2. 9:45-10:15 处理一下紧急的客户邮件
  3. 10:15-11:00 与其他BA过项目B下个迭代的卡;
  4. 11:00-12:00 主持迭代计划会议 (怎么做,昨天已准备好)
  5. 12:00-13:00  午饭+休息,刷朋友圈
  6. 13:00-13:40  约到开发、测试,一起kick-off项目A的两张卡
  7. 13:40-16:00  出发去客服中心,用户观察和访谈
  8. 16:00-17:30  准备项目A的showcase讲稿,拉测试做一遍演练、检查外部服务接口是否好了
  9. 17:30 迭代计划会时发现了两个需求问题,发邮件跟客户确认一下
  10. 18:00 查看早上整理的todo-list,还好高优先级已经处理完

 

在ThoughtWorks做BA,跟在其他公司做BA有什么区别呢?

04

我之前也在一家通信企业工作过,属于PM兼BA的角色,对比下来,觉得区别主要在下面几个方面吧:

  • 在TW,我最常用到的工具是白板,PPT,卡片,便利贴;以前最常用的是Word和Visio。
  • 在TW,墙上贴得花花绿绿的,各种需求相关信息,开发测试问到需求,我也是随时随地都能解释;以前都是要翻出需求规格明书,对照着看,才能知道到底做什么。
  • 以前,基本上是做系统分析,到我手上的都是功能需求,有时候明知道做好了没有用户真正用这个功能,还是硬着头皮对照需求规格说明书逐条实现;现在在TW,会真正关注业务问题,用户场景,基本每一条在我手上经过的需求,知道它为什么要做,有什么价值。
  • 以前,几乎从来看不到客户,也不知道用户行为是什么样的;现在几乎天天跟客户打交道(只不过有时是在视频里),还有机会做真正的用户观摩和访谈、用户测试。
  • 以前,一年几乎只能看到1-2次产品上线;现在在这个组,每月都要有很多次产品上线,时不时能得到客户发的巧克力,T恤衫,还是挺受鼓舞的。

 

BA的职业发展怎么样?目前ThoughtWorks中的BA是不是仅能在内部发展?

以我自己的经验来看,BA是个综合技能要求很高的岗位,需求大局到细节的把控、提供业务方案建议、引导决策等等,尤其是大型的产品团队中,更需要综合的影响力和领导力。

之前的BA同事离开ThoughtWorks之后, 有的去做了产品经理,有的去做了数据分析,到其他大型公司里面做BA教练,还有的去创业等等。

在ThoughtWorks内部,有的BA想精专在某一产品领域,比如O2O, P2P还有金数据,实际上承担产品经理的职责,做需求分析的同时,还做售前、看市场和运营;有的则深钻某一个行业,去更多地做业务咨询、解决方案设计、数据分析师等。也有一部分,因为综合影响力和领导力得到了极大的锻炼,横向发展成为管理人员,比如目前我们的全球CEO办公室负责人,我所在组的大客户经理等。

ThoughtWorks是一个人才观非常开放的公司,在内部会鼓励大家“不设限”,主动去尝试很多不同的工作,创造新的“岗位”。

 

在ThoughtWorks做BA,觉得最好的一面和最坏的一面是什么?

最好的一面,是可以接触到各种类型、各种行业的客户,每次都能发现新鲜东西去学习去尝试;最差的一面,其实也是这个,因为有时候要短时间学习很多技能,压力很大。当客户老板说“五分钟之内把图画好”,我们说“好”的那一刻,万分紧张和忐忑;最终把事搞定之后,又是酣畅淋漓,痛与乐并存吧。

 

去TW做BA有什么具体要求呢?

还真没有硬要求,不讲专业,不需资历,也不需软件背景。大致说来,有这四点:

  • 有需求转换的能力
  • 逻辑思维好,清晰有条理
  • 沟通好,复杂的事情也能三言两语说清楚
  • 爱挑战,爱学习

还有的一些不是必须的,但如果能做到,就是加分项了:

  • 喜欢琢磨研究行业市场
  • 善于图形化表达信息
  • 懂敏捷和精益

 

以前没做过BA,但想试试,有书推荐吗

 

最后,以我们内部训练营的BA宣言结尾:

“Skill-set over Role; BA is Business Analysis rather than Business Analyst

角色不重要,真正有两把刷子才重要。大家共同学习,多多增长技能,才是重点。

Share

“鱼变慢”还是“技术债”:适合国人口味的比喻

为什么十几年前当私家车刚刚进入中国家庭时,国人那么喜欢三厢车?我想大概是因为在国人心目中,三厢车能比两厢车表现出更高的社会地位。想想看,历史上中国领导人们所坐的车——比如红旗、上海、大众——都是三厢的。而那些工程车、抢险车、救护车大多数是两厢的。当时的中国家庭买辆车不容易,要买就买有面子的三厢车。于是国外汽车厂商为了迎合国人这个心理,纷纷把国外畅销的两厢车改造为三厢车在国内销售。我家当年买的第一辆私家车,就是一辆经过这番改造的三厢赛欧。

与之类似的是,在国外软件开发行业很流行的一些比喻,比如“技术债”(Technical Debt),要想在国内软件开发团队中发挥作用,也需要根据国人的口味改造一下。

“技术债”这个比喻最早应该出现在美国程序员Ward Cunningham在1992年撰写的一篇博客[1]中。它的概念可以用下面微软Word的故事来很好地进行诠释。

早在1983年,微软就在其Windows上演示运行了后来大名鼎鼎的Word。2年之后,微软推出了Windows 1.0。但在此之后又过了4年,微软才发布了运行在Windows 1.0上的第一版Word,比原定计划晚了好几年。

30多年前微软开发第一版Word时,管理层有两个观念:1)估算不是估算,而是承诺;2)经理不应看代码(因为如果这样做,就犯了“微管理”的大忌)。

第一版Word发布延期好几年的原因,可以从下面这幅因果回路图(Causal Loop Diagram)[2]中找到答案。

01

0. 项目的目标是遵循原定计划按时发布第一版Word;

1. 项目的目标越大,试图遵循原定计划的压力就越大;

2. 试图遵循原定计划的压力越大,经理就越愿意使用速效方法(QF, Quick Fix),来劝告、贿赂和威胁程序员跟上计划;

3. 经理越愿意使用速效方法来劝告、贿赂和威胁程序员跟上计划,程序员使用“秘密工具箱”(快速地写烂代码)的百分比就越高;

4. 程序员使用“秘密工具箱”(快速地写烂代码)的百分比越高,从短期来看,添加新feature的时间越短、工作量越小(O, Opposite,即箭尾所连接的因素越多,箭头所指向的因素越少);

5. 添加新feature的时间越短、工作量越小,管理层就越认为“劝告、贿赂和威胁能让工作做得更快”;

6. 管理层就越认为“劝告、贿赂和威胁能让工作做得更快”,经理就越愿意使用速效方法,来劝告、贿赂和威胁程序员跟上计划,从而形成了恶性循环(即Positive Feedback Loop,正向反馈回路);

7. 程序员使用“秘密工具箱”(快速地写烂代码)的百分比越高,从长期(箭头上的双竖线表示“慢性发作”)来看,添加新feature的时间越长、工作量就越大;

8. 添加新feature的时间越长、工作量越大,工作进度变慢从而与原定计划的实际偏差就越大;

9. 工作进度变慢从而与原定计划的实际偏差越大,经理就越愿意使用速效(QF, Quick Fix)方法,来劝告、贿赂和威胁程序员跟上计划,从而形成新的恶性循环。

如果用“技术债”来描述上面的两个恶性循环,那么可以这样来解释:为了省时间赶进度快速地写烂代码,好比钱不够就向银行借钱而欠债;手上拿到借来的钱,自然能在短期让工作进展更快;但是随着时间的流逝,欠债所产生的利息会越来越高,如果不连本带利地归还欠债,就会令工作进度变慢从而与原定计划的实际偏差越大。

在社会信用体系相对健全的西方社会,把“快速地写烂代码”比喻为“欠债”,确实能令讲求信用的西方软件开发团队的管理层开始重视“偿还欠债”的代码重构工作。

但相比之下,在社会信用体系尚不健全的国内,“欠债”的比喻就不像在西方社会那样好用。一段时间以前在国内出现的“老赖”这个词就能说明这个问题。这些“老赖”们,一般是欠债的商人,他们虽然有偿还债务的能力,但就是拒不还钱。结果搞得欠债的“杨白劳”们个个儿像大爷,而借人钱的“黄世仁”们倒像孙子那样低三下四。

从上面微软Word的故事中能够看到,两个恶性循环最终导致软件交付的速度变慢了。那么在今天“快鱼吃掉慢鱼”的互联网时代,在“只争朝夕”的中国,为什么不用“鱼变慢”这个比喻来促使中国软件开发的管理层更加重视驯服烂代码而让“鱼变快”呢?

如果用“鱼变慢”来描述微软Word故事,那么可以这样解释:鱼为了省时间吃烂代码这些垃圾食品,从而中毒牺牲了健康导致再也游不快。

中国软件开发的管理层向来是很重视开发速度的,因为他们追求按时交付软件产品。但是如果了解到自己的软件产品,就像一条为了赶进度大量吃下烂代码而中毒的鱼,逐渐越游越慢,最后被竞争对手那条快鱼吃掉,那么他们肯定会感到如坐针毡。

另外,不读代码的软件开发管理者们,经常会忽视软件开发的“隐藏输入”。在他们看来,“编写代码”这个任务就是一个黑盒子。这个黑盒子只有一个输入,那就是“用户需求”。这个黑盒子也只有一个输出,那就是“准时且没有缺陷的构建好的软件”。但是实际上,这个黑盒子还有一个“隐藏输入”,那就是盒子中的“已有代码”。如果程序员们为了赶进度快速地写烂代码,那么盒子里的“已有代码”就会成为“有毒”的隐藏输入,再次输入给这个黑盒子。这就解释了为什么“程序员对工作的估算往往很乐观”,因为他们往往对这些“隐藏输入”的工作量考虑得很少。

02

在社会信用不如西方发达的国内,相比“技术债”而言,有毒的“隐藏输入”导致“鱼变慢”这个比喻,能更有效地提醒信奉“快鱼吃掉慢鱼”的中国软件开发管理者重视驯服烂代码这样的工作。

注:

[1]参见:http://c2.com/doc/oopsla92.html

[2]参见:Craig Larman, Bas Vodde著,精益和敏捷开发大型应用指南,机械工业出版社,2010年1月第一版

Share

如何培养自己的自信心

c23e73362a1f1bafc564405455850d38

self-confidence(自信心)——是一种反映个体对自己是否有能力成功地完成某项活动的信任程度的心理特性,是一种积极、有效地表达自我价值、自我尊重、自我理解的意识特征和心理状态,也称为信心。自信心的个体差异不同程度地影响着学习、竞赛、就业、成就等多方面的个体心理和行为。

当你被指派一个任务时,你会基于你目前所拥有的资源和能力做出一个评估,结果得出自己是否能胜任这个任务。自己目前能力<该任务所需能力,你却得出能胜任的结论,那就是你对自我认知不足,盲目乐观,这就是自负的表现。自己目前能力 >=该任务所需能力,而你却认为无法胜任,那就是过于贬低自己,这就是自卑。

从自负被打回原形比较容易,因为你多自负几次,多栽几个跟头,那么你就老实了。而从自卑上升到自信则难多了,因为由于自卑,你根本不会去领取任务,这意味着你不会完成该任务,从而无法提升自信,有新任务来时又主动退缩,陷入死循环。

 所以大家可能看出来了,培养自信心的关键在于,多做事,做没做过的事。不断的检验自己,校正自己对自己的认知。但是大家在面临工作中的挑战时,报的都是比较谨慎的态度,因为事情没做成,轻则挨顿骂,重则丢了饭碗,所以又陷入一个死循环,谨慎接任务->无法突破自身->自信心(能力)无法提升->谨慎接任务。

 所以培养自信心可以从生活中的事情开始。有一个很好的任务就是跑一个马拉松。如果你之前没有跑过马拉松,那么你肯定有很多问题想知道。

1. 马拉松距离有多长?

2. 跑马拉松需要什么样的装备?

3. 从现在开始训练,需要多长时间能够完成马拉松?

4. 需要什么样的训练计划?

5. 如何安排自己的训练时间?

这么多的问题要把你淹没,自己完成一个马拉松似乎变成了一个不可能的任务。如果这时你退缩,那么我可以告诉你,你自卑了。因为据科学家研究,一个普通人,只要你没某些不适合跑步的疾病(比如心脏病等)以及肢体残疾(有些残疾人也能完成马拉松),通过训练都可以完成42公里的跑步。我说你行,你缺少的就是干劲。

虽然有这么多问题,你还是决定试试。那么首先要解决这些问题。如何解决不需要我教了吧?网上一查,资料一大把。多去跑步圣经、跑步吧里逛逛,买几本关于跑步的书,找几个身边的长跑健将聊聊天,大多数的问题都迎刃而解。小部分的问题可能会使你纠结,比如有人说跑步需要3呼3吸,有人说2呼2吸,有人说亚索800方法好,有人说MAF有奇效。不用纠结,你要进入下个环节了,实战训练,从训练中感知这些理论方法,从而找到更适合自己的方式。

 刚开始训练感觉新奇,时间久了似乎各种问题又来了。最近太忙,训练时间很难保证;跑了这么久,距离还是无法突破;到底是先练距离还是先练速度那?…….说时间紧的那我劝你不练了。因为咱们的任务就是跑一个全程马拉松,你没时间训练,那就别干了。这就好像老板喊你7天搭一个网站出来,你说对不起最近LOL正在冲击排位,没时间做。跑马拉松这件事本来就是你自己给自己定的任务,老板就是你自己,所以时间问题你看着办。其它问题好说,搞IT这行的最不缺的技能就是利用资源。多看书、多逛跑步论坛、多找过来人交流….(怎么还是老三样)再加上自己在训练中融会贯通,我就不信你不长进。

好了,经过一段时间训练了,感觉自己进步很大,但还是拿不准啥时候能跑个全马。如果你想达到“万事俱备,只欠东风”,那么对不起,你不是诸葛亮,东风啥时候来你是不会知道的。这就需要你设置个deadline了。先报名一个几个月后的全马比赛(一般马拉松比赛都是提前几个月报名),然后你的训练会更加鸡血。而且你会找到一群志同道合的基友(没找到?不知道咋找?我膝盖前叉断裂,都轻松找到了一群病友,你到底用心没?),一起集训,相互鼓励。

比赛的日子越来越近了。回想这几个月来,你为了这一目标付出了这么多实打实的汗水,肯定感慨良多。你认识了一群基友,熟悉了周边没逛过几次的公园,看到了早晨7点钟的城市,学会了跑步中对自我反思….恭喜你,这些都是跑马拉松给你带来的从来没有的体验。虽然在迎接这天的过程中,你激动的内心有些忐忑,但是你似乎已经得到了很多意想不到的东西。

 比赛这天终于到来了,站在起点前,和好几万人一起打算度过数小时的地狱旅行。这时你的心里除了激动还是激动。比赛结果其实已经不重要了,当你站在跑道上的时候,你就比以前的你强了。如果能顺利完赛,你已经不是以前的你。如果因故未完赛,放心,这绝不是你最后一场马拉松,相信你已经谋划下一次冒险了。

 好了,你已经完成了生活中的一个任务了。有没有收获?自信心有没有提升?你试一下你就知道了。可以放心的告诉你,这种感觉绝对比你考试得了全班第一的感觉还要美好。另外,跑完马拉松不是你这个任务的终点。它就像给你打开了一个潘多拉魔盒,你会发现有更多的事情你可以去做,比如铁人三项,比如越野跑……

好吧,可能有点标题党。明明讲如何提升自信心,但通篇却在讲如何完成个人首马。其实很多事情都是相通的。因为你已经发现了如何做一件没做过的事情。

首先,先答应下来。这个最关键。

然后,发动所有的资源,了解这个事情。

接下来,做吧。别忘了边做边验证,吸收过来人的经验。

最后,接受检验吧。检验结果不用担心,因为无论通过与否,你整个过程已经有了大量的收获。

 看完以后是不是有种自信心爆棚的错觉?别忘了关键两点:

1. 坚定决心要做;

2. 努力想如何做。

最后,尽情享受事情做成后带来的成功感和喜悦吧。

Share