打造你自己的技术雷达

我们缺少的是一个技术雷达:一份评估既有技术与新生技术的风险和利益的动态文档。我相信你会需要两个雷达:一个自己的雷达,用来帮助指导你的事业决策;另一个是公司的雷达,帮助你们在做购买决定和选择技术方向时保持理智。我会讨论如何创建这两种雷达,但是首先,我想先谈谈为什么我会产生这样的想法。

醒醒吧少年,只用Cucumber不能帮助你BDD

在Ruby社区中,测试和BDD一直是一个被热议的话题,不管是单元测试,集成测试和功能测试,你总能在Ruby社区中找到能帮助你的工具,Cucumber就是被广泛使用的工具之一。许多团队选择Cucumber的原因是“团队要BDD”,也就是行为驱动开发(Behavior Driven Development),难道用了Cucumber之后团队就真的BDD了么?

我们真的缺前端工程师吗?

这两天在好几个地方都看到了一篇关于为什么整个互联网行业都缺前端工程师?的文章,文章本身是去年的,中心思想是:其实我们并不缺前端工程师,我们缺的是优秀的前端工程师。我还是比较同意作者观点的,不过略有意犹未尽的感觉。于是我结合自己的经验,也来聊一下这个话题:我们真的缺前端工程师吗?

敏捷实践之Desk Check

在推广敏捷的过程中,虽然ThoughtWorks有过很多应用的经验,但是当我们把一个实践介绍给其他人,总会遇到为什么要这样做的问题。在带领大家做之前,口头上的介绍和说服工作是必不可少的,毕竟这是给团队成员打消疑虑,树立信心,建立目标的一个过程。做到团队的每个成员都理解了这个实践的意义,对实践的执行就能很容易的达到要求。否则,团队执行的人很难心悦诚服的执行,结果就是这一环节会很快被大家无视,慢慢消亡了。

你会给别人提反馈吗?

我们必须承认人对事物的认知是不同的,它跟每个人的经历,教育背景,工作经验,家庭,所出环境都是有影响的,因此对于同样内容的理解也是因人而异,值得注意的是,尽管当我们为对方基于某个事件而提出反馈时带有个人解读,但是具有感情色彩的判断是不建议的,尤其是负面的感情,因为它对反馈的效果大打折扣,甚至出现负面效果。这就要求提供反馈的人实事求是,反馈的内容是对方的行为,不要增加任何的主观判断。

强迫症的Mac设置指南

一直想写这么一篇文章,把我从同事那里学到的经验分享出来。市面上有很多类似的文章,写得都非常好,让我受益匪浅。不过我还是有一些自己总结出来的经验想要分享。

刚毕业的软件工程师,去大公司还是小团队?

第一份工作的选择仍是至关重要的。它很可能会直接影响着我们此后的进步速度、职业路线和社会地位。同时,职业路线说大一点也正是人生路线,没有人能够给别人直接的答案。说到底,这还是只与个人想成为怎样的人有关系,与别的无关。因此,这里我只想给想成为“技术牛人”的毕业生给一点建议,而不是那些随便找一份能够糊口的工作度日的人,更不是那些学会了SSH 就去接私单的投机主义者。

CRM二三事

相信很多人都听说过、使用过、甚至开发过CRM系统,那么关于CRM的一些基础信息又有多少人知道呢?

看板任务管理

作为一个开发团队的管理者,例如当你是一个团队的项目经理的时候,任务的完成情况通常是你最关心的内容之一,比如说分配的任务是否能够按时间完成,整个项目的进度是否尚在计划之中,团队内的人是不是都在高效地工作,大家有没有什么困难,这些是你经常会关注的问题。在软件开发团队中,任务的分配、跟踪和管理通常是这个团队管理者的一个重要的工作内容。

Tech Lead的三重人格

很多团队都有tech lead这个角色的存在,但同时很多团队对这个角色都缺乏明确的定义。大多数时候,团队只是指派其中经验最丰富、技术最精熟的开发者来担当tech lead。但除了“tech”的成分之外,这个角色还有“lead”的成分,这就决定了他不仅需要技术上的能力,还要眼观六路耳听八方,才能带领团队──至少是开发者们──取得成功。

估算的目的

我第一次与敏捷软件开发的邂逅,是在极限编程刚刚兴起时,跟Kent Beck一起工作的经历。其中让我印象深刻的事情之一,就是我们如何做计划的方式。这里面包括一种估算方式,比起我之前见到过的其他方法,它既轻量,还更有效。这样过了十年,现在一些有经验的敏捷实践者,开始了一场关于估算是否值得甚至是否有害的争论。我想,为了回答这个问题,我们必须审视一下估算的目的。