离线下载
PDF版 ePub版

梦里风林 · 更新于 2018-11-18 07:00:35

团队技能

为什么评估很重要

为了尽快获得一个可以高效使用的工作软件系统,不仅需要为开发做计划,还需要为文档,部署,市场做计划。在一个商业工程里,这还需要销售和金融计划。没有对开发时间的预测能力,是不可能高效预测以上这些东西的。

好的估计提供了预测能力。管理者喜欢,而且应该这么做。事实是这不可能,不论是理论上还是实践上,准确预测开发软件消耗的时间总是被管理者忽视。我们总是被要求做这些不可能的事情,而且我们必须诚实地面对它。然而,不接受这个任务的不可能性是不诚实的,必要的时候,需要解释。然而,评估这件事情,有很大的错误传达的空间,因为人们有一种令人吃惊的趋势会这样希望满满地想:

我估计,如果我确实理解了这个问题,我们在 5 周内有 50%的可能完成任务(如果在此期间没有人干扰我们的话)。

真实的含义是:

我保证从现在开始五个星期内完成任务。

这个常见的解释问题需要你专门与你的 boss 和顾客讨论(就好像把他们当做傻子那样)。重新阐述你的解释,不管他们对你来讲它们有多么显而易见。

如何评估编程时间

评估需要实践,也需要劳动。因为它需要花如此长的时间以至于评估评估的时间可能是一个好主意,尤其是你被要求去评估一些巨大的事情。

当被要求评估一些比较大的事情的时候,该做的最可靠的事情是先停下来。大多数工程师是充满热情并且想要开心的,停下来当然会让停下来的事情不开心。但对一个进行中的事情做评估一般是不准确且不可靠的。

停下来时,考虑一些事情或者重新为任务重新定型成为可能。如果政策压力允许,这是执行评估的最准确的方式,并且它会产生确实的进度。

在没有时间做调查的时候,你首先应该非常清晰地建立评估的含义。首先重新阐述要评估的内容,还有你编写的评估的最后部分。重新构建任务为进度化的更小的子任务,直到每个小任务需要的时间不超过一天(理想情况是每个任务的长度最多为一天),以此准备一个写好的评估计划。最重要的事情是不要漏掉任何事情。例如,文档,测试,规划的时间,与其他小组交流的时间,还有度假时间,这些都是很重要的。如果你每天都要花时间和一些傻逼交流,在评估里为这件事情划一个明确的时间界限。这能让你的 boss 对于你将要花费的最少时间有了一个认识,并且可能给你更多的时间。

我认识一些会隐式地填充评估时间的好的程序员,但我推荐你不要这样做。填充的一个结果是对你的信任可能被耗尽。例如,一个工程师可能为一个将要花费一天的工作评估为三天。这个工程师可能计划花两天去为代码写文档,或者花两天去做一些其他有用的工程。但当任务在一天内完成时,如果它在那天暴露出来的话,这是可以察觉的,并且松懈或高估的表现会出现。为你确实要做的事情做合适的剖析要好得多。如果写文档需要花两倍于编程的时间,并且评估的结果就是这样的,让这对管理者可见就能得到巨大的好处。

相反,显式填充。如果一个任务可能花一天,但如果你的方法没有生效,可能花十天 - 用某种方式在你的评估里记下这个情况,否则,至少为这个可能性,评估一个权重计算可能的时间。任何你可以识别和进行评估的风险因素应该在时间表里被体现。一个人不太可能在给定的任何星期都生病。但一个有很多工程师的大项目会需要一些疾病时间,还有休假时间。或者,强制的公司范围的培训研讨会的可能性?如果这可以预估,也把它算进来。当然,还有一些未知的未知,或者 unk-unk。Unk-unk 在定义上是不能被独立评估的。你可以尝试为所有 unk-unk 创建一个全局的界线,或者用你与你的 boss 交流好的其他方式去处理它们。然而,你不能让你的 boss 忘记它们的存在。在把评估变成时间表的过程中,把它们遗忘是超级容易的。

在一个团队环境里,你应该让任务的执行者去做这种评估,而且你们应该在团队范围内对评估的结果取得一致。人与人在技术,经验,准备和信心上都有很多的不同。当一个牛逼的程序员为他自己评估了时间,然后一些弱一点的程序员被这种评估约束时,灾难降临了。整个团队在一个一行一行的细致的评估计划上取得的一致,阐述了团队的理解,以及允许在策略上对资源的重新分配的机会(比如,把负担从弱一点的团队成员那里移到强一点的成员那里)。

如果有不能评估的大风险,你的责任是足够有力地阐述以至于你的管理者不会在这个问题上做承诺,在风险发生时也不会变得窘迫。这种情况下,任何需要的事情都有希望被执行来减小这个风险。

如果你可以说服你的公司去使用极限编程,你只需要评估相当小的事情,这也是更加有趣和有效率的。

如何发现信息

你所搜寻的事情的本质决定了你应该如何去寻找它。

如果你需要客观的而且容易辨认的关于具体事物的信息,例如一个软件的最新补丁版本,可以在 Internet 搜索,礼貌的询问很多的人,或者发起一个讨论组。不要在网上搜索任何带有观点或主观解释的东西:能够抵达真相的概率太低了。

如果你需要“一些主观的普遍知识”,人们对这些东西已有的思考历史,那就去图书馆吧。例如,学习数学或蘑菇或神秘的东西,去图书馆吧。

如果你需要知道如何做一些琐碎的事情,找两三本关于这个主题的书,仔细阅读。你可以从网络上学到如何做好这些琐碎的事情,比如安装一个软件包。你甚至可以学到一些重要的东西,例如好的编程技术,但相比读一本纸质书的相关部分,你很容易花更多时间在搜索和对结果排序,以及评估结果的权威性。

如果你需要可能没有人知道的信息,例如,“这个新品牌的软件在海量数据的情况下能工作吗”,你仍然必须在网络和图书馆里搜索。在这些选项都完全竭尽后,你可能需要设计一个实验来搞清楚这个问题。

如果你需要一些考虑了某些特殊环境的观点或估值,和一个专家聊聊。例如,如果你想要知道用 Lisp 构建一个现代数据库管理系统是否是一个好主意,你应该和一个 Lisp 专家和一个数据库专家聊一聊。

如果你想要知道它具体是怎样的,比如一个还未发布的在一个特定程序上更快的算法,跟一些在这个领域工作的人聊聊。

如果你想要做一个只有你自己能做的个人决定,比如你是否应该开始某个事业,尝试把一些对这个想法有益和有害的点列出来。如果这没有什么用,做一些预测。假设你已经从各个角度研究了这个想法,并且已经完成了你的任务,在心里列举所有的后果,赞同的意见,反对的意见,但可能仍然有迟疑。你现在应该遵循你自己内心的想法,然后让你的大脑停止思考。大多数可用的预测技术都对决定你内心一半的欲望有作用,因为它们在体现你自己完全多义和随机模式的潜意识都很有用。

如何把人们作为信息源

尊重其他每个人的时间,与你的时间相平衡。问别人问题比得到答案能获得更多。人们会从你的存在和倾听特定的问题从你身上学到东西。你也可以用同样的方式从别人身上学习到东西,你可能学到你正在搜寻的东西的答案。这通常比你的问题更加重要得多。

然而,这个问题的价值会减少你在上面做的事情。你毕竟使用了一个人拥有的最珍贵的商品:时间。交流的好处必须与代价相权衡。更进一步,特定的代价和好处在人与人之间都不一样。我强烈相信一个 100 人的管理者每个月应该花五分钟与他所在的组织的每个人谈话,大概是它们的时间的 5%。但十分钟可能太多了,如果他们有 1000 个员工,5 分钟也可能太多了。你与组织中每个人交谈花费的时间取决于他们的角色(而非他们的位置)。你应该和你的 boss 交谈而非和你 boss 的 boss 交谈,但你偶尔也可以和你 boss 的 boss 交谈啦。这可能不太舒服,但我相信你有责任每个月和你的上上级稍微聊聊,什么都行。

基本的规则是,每个与你交谈的人都能稍微受益,他们与你聊得更多,他们能获得的收益越少。你的应该给他们提供这种好处,还有得到与他们交流的好处,平衡这种好处与花费的时间。

尊重你自己的时间是很重要的。如果和一些人聊天,即使这会消耗他们的时间,结果会节省你很多的时间,那么你应该这样做,除非你认为他们的时间在这个因素上,对整个集体,比你的时间更加有价值。

一个奇怪的例子是暑期实习生。一个处于高技术含量位置的暑期实习生不能被期望去完成太多东西;他们可能会把每个人纠缠到地狱。但为什么这是被允许的呢?因为被纠缠的人从实习生身上可以接收到一些重要的东西。他们得到了一点炫耀的机会,他们可能有机会去听到一些新的思想,他们有机会可以从不同的角度去看问题。他们可能会尝试招聘这个实习生,但即使不是这样,他们也获得了很多。

如果你真诚地相信别人有一些东西可以告诉你,无论合适,应该询问他们的意见与智慧。这能让他们高兴并且你可以从他们身上学到一些东西,也可以教会他们一些东西。一个好的程序员不会经常需要销售副经理的建议,但如果你需要,你当然应该询问这个问题。我曾经被要求去倾听一些销售电话以便更好地理解我们的销售员工的工作。这不会耗费超过 30 分钟,但我认为小的努力可以在销售压力上产生好的影响。

如何睿智地写文档

人生太短,不能写没人会读的废话,如果你写了废话,没人会去读。所以一点好的文档是最好的。经理不会去理解这些东西,因为不好的文档会给他们错误的安全感以至于他们不敢依赖他们的程序员。如果一些人绝对坚持你真的在写没用的文档,就告诉他们“是的”,然后安静的找一份更好的工作。

没有其他事情比精确估计 把好的文档转为放松文档要求的估计 更为有效率。真相是冷酷而艰难的:文档,就像测试,会花比开发代码多几倍的时间。

首先,写好的文档是好的写作。我建议你找一些关于写作的事情,学习,练习他们。但即使你是一个糟糕的写手或者对你需要写文档的语言掌握不好,这条黄金规则是你真正需要的:己所不欲,勿施于人。花时间去确实地思考谁会读你的文档,他们从文档中想要获得的真正的东西是什么,并且你可以如何把这些东西交给他们。如果你这样做,你将会变成一个超过平均水平的文档编写者,和一个好的程序员。

当代码可以自成文档时,与提供文档给非程序员看相反,我认识的最好的程序员们有这样一个普遍的观点:编写具有自我解释功能的代码,仅在你不能通过代码清晰解释其含义的地方,才写注释。有两个好的原因:第一,任何人需要查看代码级别的文档大多数情况下都能够并且更喜欢阅读代码。不可否认的,有经验的程序员似乎比初学者更容易做到这件事,然而,更重要的是,没有文档的话,代码和文档不会是自相矛盾的。源代码最糟糕的情况下可能是错误并且令人困惑的。没有完美编写的文档,可能说谎,这可糟糕一千倍。

负责任的程序员也不能让这件事变得更简单些。如何写自解释的代码?那意味着什么?它意味着:

  • 编写知道别人会去阅读的代码(译者注:编写给人看的代码)
  • 运用黄金法则
  • 选择直接的解决方案,即使你可以更快地获得另一个解决方案
  • 牺牲那些可能混淆代码的小的优化
  • 为读者考虑,把你珍贵的时间花在让她更加容易阅读的事情上,并且
  • 永远不要使用这样的函数名比如 foo,bar, 或 doIt!

如何在糟糕的代码上工作

工作在别人写的糟糕的代码上是常有的事。不要把他们想得太糟,直到你用他们的鞋子走路时。他们可能被要求非常自觉地快速完成一些东西来满足时间表的压力。不管之前发生了什么,为了在不清晰的代码上工作,你必须理解它。理解它需要花费一些学习时间,你必须坚持从时间表中某些部分划出一部分时间来做这件事。为了理解它们,你必须读源代码,你可能需要在上面做一些实验。

即使是为你自己,编写文档也是一个好的时机,因为尝试为你的代码编写文档会强迫你从你可能没有考虑过的角度思考,并且完成的文档可能会有用。当你在做这个时,考虑重写部分或所有代码会消耗你什么东西。是否重写一部分代码事实上真的会节省时间?你重写代码后你会更信任它吗?在这里小心你的傲慢。如果你重写它,你处理它会更容易,但下一个必须阅读它的人是否真的更加容易?如果你重写了,测试的负担在哪里?重新测试的需要是否大于可能获得的好处?

在任何对你没有编写的代码的评估中,代码的质量会影响你对风险问题的认识以及一些未知的事情。

铭记抽象和封装是很重要的,这两个程序员最好的工具,对糟糕的代码是特别好用的。你可能不能够重新设计一大块代码,但如果你可以为它增加一定量的抽象,你不用重新在这整团迷雾上工作就可以获一些好的设计的好处。特别的,你可以尝试隔离尤其糟糕的代码,这样他们就可以被独立重构。

如何使用源代码控制

源代码控制系统让你高效地管理工程。他们对一个人是很有用的,对一个团队是至关重要的。它们追踪不同版本里的所有改变,以至于所有代码都未曾丢失,其含义可以归属于改变。有了源代码控制系统,一个人可以自信地写一些而半途而废的代码和调试的代码,因为你修改的代码被仔细地与提交的、官方的即将与团队共享或发布的代码分割开。

我挺晚才开始意识到源代码控制系统的好处,但现在即使是一个人的工程,我也不能离开源代码控制系统。当你们团队在同样的代码基础上工作时,通常它们是必要的。然而,它们有另一个巨大的优点:它们鼓励我们把代码当做一个成长的有机系统。因为每个改变都会被标记为带有名字或数字的修正,一个人会开始认为软件是一种可见的一系列渐进的提升。我认为这对初学者是尤其有用的。

使用源代码控制系统的一个好的技术是一直保持在几天后提交更新。在提交后,一定程度上不活跃,不被调用的代码在几天内都不会完成,因此也不会对其他任何人产生任何问题。提交错误降低你队友的速度是一个严重的错误,这往往是一种禁忌。

如何进行单元测试

单元测试,对独立的代码功能片段,由编写代码的团队进行测试,也是一种编码,而非与之不同的一些事情。设计代码的一部分就是设计它该被如何测试。你应该写一个测试计划,即使它只是一句话。有时候测试很简单:“这个按钮看起来好吗?”,有时候它很复杂:“这个匹配算法可以精确地返回正确的匹配结果?”。

无论任何可能的时候,使用断言检查以及测试驱动。这不仅能尽早发现 bug,而且在之后也很有用,让你在其他方面担心的谜题得到解决。

极限编程开发者广泛高效地编写单元测试,除了推荐他们的作品,我不能做更好的事情了。

没有思路时,休息一下

没有思路时,休息一下。我有时候没有思路时会冥思 15 分钟,当我回来看问题时,它就神奇地解开了。更大尺度上,一个晚上的睡眠能做到一样的事情,临时切换到其他活动上可能会生效。

如何识别下班时间

计算机编程是一种活动也是一种文化。不幸的事实是它不是一种看重身心健康的文化。从文化/历史缘由看(例如,在机器空载的晚上工作的需要),还有因为超过市场时间的压力和程序员的缺乏,计算机程序员传统上总是过度工作。我不认为你可以相信你听到的所有故事,但我认为一周工作 60 小时是常见的,50 小时更多的像一个最小值。这意味着实际总是比需要的时间花费得更多。这对一个好的,不仅为他们自己负责而且为他们的同事负责的程序员来说是一个严重的问题。你需要识别什么时候下班,有时候还要建议其他人回家的时间。解决这个问题的固定规则不存在,抚养一个孩子的固定规则也是,出于同样的原因---每个人都是不同的。

一周超过 60 个小时工作对我来说是非常辛苦的,我可以申请挺短的一段时间(大概是一周),有时候在我的预料中。我不知道对一个人来说一周工作超过 60 小时是否公平,我甚至不知道 40 小时是否是公平的。然而,我确定,如果你努力工作,却在你额外工作的时间里获得了很少东西,这是很愚蠢的。对我个人来说,我认为做一个懦夫不是一个程序员该做的事。遗憾的是,事实上,程序员经常要求做一个懦夫来为一些人表演,例如一个经理想要给总经理留下深刻印象。程序员经常对此屈服,因为他们希望开心,并且不善拒绝,与此相反的有四道防护墙:

  • 尽可能与公司里的任何人交流,这样没人可以误导总经理正在发生的事情;
  • 学习明确而防御性地评估和规划,让每个人看到时间表的内容以及它的立场;
  • 学会拒绝,在必要时作为一个团队拒绝,并且
  • 如果必须的话,退出团队

大多数程序员是好的程序员,好的程序员想要做很多东西。为了做到这点,他们需要高效管理他们的时间。从一个问题中兴奋和深陷其中都有一定量的心理惯性。许多程序员发现他们在长久不被打扰的一段时间兴奋和集中注意力后工作得最好。然而,人们必须睡觉,并且有其他的责任。每个人需要找到一种方式去满足他们的生物节奏和工作节奏。每个程序员需要做任何必须的事情来提供高效的工作周期,比如只参加的某些最关键的会议,以此保留一定的时间。

因为我有孩子,我尝试和他们在晚上相处。我自己最好的工作节奏是工作很长的一天,在办公室或办公室附近睡觉(从家到工作我需要很长的转换时间)然后足够早地回家,在我的孩子们睡觉前与他们相处。我觉得这并不舒服,但这是我可以工作的最好的妥协。如果你得了传染病,回家。如果你有自杀的想法,回家。如果你有超过几秒的凶杀的想法,回家。如果有人有严重的心理障碍或者超出心情低落的心理疾病的标志,把他送回家。如果你由于疲劳变得与平时不同地在某种程度上趋于不诚实或失望,休息一下。不要使用药物缓解疲劳。不要滥用咖啡因。

如何与不好相处的人相处

你可能必须和不好相处的人相处。甚至可能你本身就是一个不好相处的人。如果你是那种与同事和权威人物有许多矛盾的人,你应该珍惜这种独立所暗示的东西,但需要在不牺牲你的智力或原则的前提下提高你的人际交往能力。

在这方面没有什么经验,或者先前生活的行为模式在工作场合的经验不能适用的一些程序员,对这种事情会非常困扰。不好相处的人经常习惯于拒绝,并且与他人相比,他们更不容易受社交压力所影响。关键是合适地尊重他们,而非你可能想做的事,但不要充分地满足他们想要的(译者注:他们想要的往往是过分的)。

程序员必须作为一个团队一起工作。当分歧出现时,它必须用某种方式解决,它不能被长时间挂起。不好相处的人通常是极度聪明的,并且有一些很有用的意见可以发表。不带对这个人的偏见,倾听并理解不好相处的人是非常至关重要的。失败的交流通常是分歧的基础,但它有时候可以被巨大的耐心移除。尝试冷静诚恳地保持交流,并且不接受任何可能产生更大矛盾的引诱。在一个合理的尝试理解的周期后,再做决定。

不要让一个恶霸强迫你做你所不同意的事情。如果你是老大,做你认为最好的事情。不要为任何个人因素做出决定,并时刻准备好为你的决定做出解释。如果你是一个有着不好相处的同事的团队成员,不要让老大的决定有任何个人影响。如果没有按你的想法发展,全身心地按(已成事实的)另一种方法去做。

不好相处的人能够改变与进步。我曾亲眼目睹这种情况,但这很稀少。然而,每个人都有暂时的高兴与失落情绪。

有这样一个,每个程序员除了特殊的老大都会面对的挑战是:让不好相处的人保持完全的忙碌。他们比别人更倾向于枯燥的工作,并且更能被动地忍受。

上一篇: 个人技能 下一篇: 个人技能