原文地址：https://www.scrumalliance.org/community/articles/2015/february/t-shaped-skills
刚转入敏捷的团队常问我一些问题：测试人员问如何对特性/任务进行估算，程序员如何估算测试的工作。通常这很难回答，但在scrum团队中确实能成功。
先问个问题。我们多少人会做饭？当然并不全会，有时我们帮助别人做饭，或者我们只是看着别人做饭。如果被问及多久能做好一盘鱼，相信大家都有一个初步的估计，基于以往的观察。我同意有时估算并不准确，但是就像英国经济学家John Maynard Keynes所说：粗浅正确的估计，要比精确而错误的估计强。
现在来谈一下Scrum团队中的T型开发人员。我用“开发人员”这词，是因为，在Scrum团队中，编码和测试都是团队成员，都是开发人员。同样团队成员也会有设计师和业务分析师。实质上，每个人都对其他人工作有所涉猎。我们可以说，每个开发人员都是“样样精通”（或者说博而不精）。我个人更喜欢开发人员能够既样样都行，同时精通一项。
我给大家分享一个T型技能的例子，虽然跟scrum无关。
几天前我请一个电工来家里修理插座，我发现他带着电钻。当他做完工作，我请他再帮我在墙上钻几个洞来挂画。我本打算请一个木工来做，但看到他带着电钻，我请他来做以便能更快地完成工作
他很开心能帮我挂画，他说自己经常承接一些小活，类似管道工作和木工工作，因为他和管道工人和木工经常一起工作了许多年。
以上就是一个例子：一个人精通一项技能但又有很多该领域其他技能。
但是，我们不能不多钻两个洞，因为第一次的画没有对齐。
哪出错了？
- 我告诉他在墙上钻洞，但是我挡住了他的视线。他本来应该看到画后面的挂钩并未对称。这本来可以避免的。
我从他的其他技能中获取了什么？
- 我不用等待管道工了，多打2个洞解决了对齐问题
- 我省了一些钱，他多赚了一些钱
其他需要“全才”的理由，如：
在传统项目管理中，我们分配估算如下（虽然我不喜欢这种时间分配，但有时我们用这种方法来做大概估计）：
- 25%的工作量用于分析
- 50%用于设计，编码和单元测试
- 25%用于测试
如果有个需求是变更公司的邮件地址，其影响了系统480处，但邮件地址是从某个文件中获取的，所以只需花费少量时间就可以实现并验证。
用于测试的时间应该分配多少？有两个相关的观点。如果一个测试人员说他要验证480处所有被影响的地方，那么上面提到的估算时的时间分配方式就不起作用了。然后，如果测试人员对编程有所了解，他能看到代码的修改，验证一些随机的页面。前提是测试人员懂得一些编程技术。对自动化测试来说，这是必备的。我已经见到一些企业开始对团队人员展开多技能培训，如测试人员懂得基本的编程，编程人员知道软件测试技术。
最后…
T型技能的获取需要花费团队时间，但是从软件开发的长远角度来看，作用会很大，尤其是在结对编程、结对测试或文档编写中。所以，如果scrum团队愿意只需改进并最大化sprint的价值，他们需要T型技能。
译者：于喆 [email protected]