《程序员度量:改善软件团队的分析学》一程序员在其核心职责之外的贡献如何

程序员在其核心职责之外的贡献如何

在程序员显而易见的职责之外,对项目和软件开发团队的成功而言还有很多其他非常重要的事情。这些事情不太显眼,但其重要程度和基本的编码、设计和测试完全相当。在体育运动中,作为确定球员对团队成功的贡献的关键方法,已经证明有些不太显著的统计数据是非常有价值的。例如,在棒球比赛中,知道击球员击球的判断正确率或者守场员在多大范围内能获得接近他们的球是很有价值的。

程序员能覆盖多少领域

当从一个领域迁移到另一个领域或者从一种类型的工作转移到另一种类型时,就是展示程序员的广度能力的时候。对大多数程序员来说,这是一个长期的、渐进的过程。例如,一个程序员可以在一个特定领域的代码上工作数月,然后迁移到下一个领域,并且也许还需要维护前面领域的代码。然而,有些程序员却需要同时兼顾多个领域。例如,一个程序员可能需要为多个特性修改bug,同时还需要改善构建脚本以及更新安装程序代码。

程序员足够主动吗

另一个重要的方面是主动性。如果存在一个问题或机会,程序员会发现它,并自己来解决这个问题——尽管通常他们没有计划过。另一种类型的主动性也很重要,就是程序员在出现问题或者将要出错时向团队的其他成员指出。这可能意味着需要积极地指出他人写的一部分代码需要修改,或者意味着向团队领导或经理描述问题,甚至是与其他团队成员的个人问题。当程序员确实采取了这样的主动行为时,就值得关注。因此,这也是需要考虑的度量。

程序员创新吗

与主动性密切相关的是创新。程序员经常获得独特的解决方案或改进,或从前没想到的新能力。有时,这些创新益处较小,或者是边缘性的,但有时这些益处非常大。有时候创新来自于单个程序员的主动性工作,或者是多个程序员协作的结果。创新是项目成功的一个非常重要的因素。

程序员处理压力的能力如何

程序员有时也需要处理外部压力或者心理压力。这可能出现在项目接近最后期限或者修复关键的产品问题时。在不同的环境中,压力的波动、频率不同,因此所谓的“压力较大”和“压力正常”也是相对的。例如,在启动阶段,所谓的正常压力也可能会导致一些程序员抓狂。不时地,很多程序员需要处理压力——有时可能是很紧急的情况,类似篮球比赛的最后两分钟,足球的最后一刻钟或者是棒球第9场接近结束的时候一样。

程序员应对逆境的能力如何

逆境类似于压力的情形,但值得单独一提。只有很幸运的程序员永远不会遇到逆境。逆境可以有多种形式。产品的失败、软件团队由于公司的财务困难而进行的裁员,以及可能遇到的团队成员患病或过世的情形。一些程序员可以很好地面对逆境。他们或者坦然面对,或者恢复元气。逆境的应对能力也是值得考虑的度量之一。

时间: 2024-09-11 01:19:59

《程序员度量:改善软件团队的分析学》一程序员在其核心职责之外的贡献如何的相关文章

《程序员度量:改善软件团队的分析学》一导读

前 言 是否存在一种合理的方法来衡量程序员的技能与贡献,并且也同样适用于团队所有的人?是否可以通过度量来帮助个人提高程序员的自我意识,以及促进团队工作.出谋划策和目标设定?能否通过详尽的数据帮助你做出更好的聘用决策,或者更公平地进行绩效考核,从而让你的软件开发团队变得更成功? 无论你是程序员.团队负责人,还是项目经理,如果你对这些主题中的任何一个感兴趣,或者你对如何采用不同工作方式将度量应用到软件开发团队中感兴趣,那么本书很适合你.本书的思路和过去在软件开发中使用度量的方式有很大不同.本书中提出

《程序员度量:改善软件团队的分析学》一数据获取

数据获取 很多系统都能帮助收集数据元素.有些可以提供易于访问的有用数据,特别是那些直接打交道的或控制的并且与开发相关的系统.对度量而言最有用的系统之一可能就是实际产品本身,一些适当的手段和监控可以提供关于客户采用.使用或特定特性和产品改变的成功的大量数据.有些系统可能不容易访问,通常是你无法授权使用其他业务部门的数据.我的经验是,如果你向系统所有者或管理员解释数据的有用性和使用目的,而且说明你并不需要保密和敏感的数据,你应该能得到授权.有时我们可以直接从系统中得到数据,而有时数据是从常规报告或者

《程序员度量:改善软件团队的分析学》一关于软件采用、问题以及竞争的数据

关于软件采用.问题以及竞争的数据 除了测量程序员技能,目标受众以及那些通过不同方式和软件打交道的人员(外部用户.内部用户.销售和支持人员或者上述所有人员)对软件的接受情况也是关键的测度.收集那些可以指示软件的成功以及人们对工作的响应的质量数据,包括收集关于采用.效益和问题的数据,还可以相对于已知的竞争对手来评估成功. 关注与采用 作为度量系统的基础,确定一个软件产品.项目或者特性是否可以积极或者消极地接受,以及尝试度量这种响应的程度,非常关键.可用来对响应进行跟踪的最基础的指标是使用情况.但是使

《程序员度量:改善软件团队的分析学》一第1章

第1章概述让我们不要太确信,我们没有错过一些重要的东西.--比尔·詹姆斯(棒球统计学家和作者),摘自"Underestimating the Fog"这是一本关于程序员.软件开发团队的度量和模式的书.本书的一些想法源于我在多年前开始的对软件开发团队构成的思考:无论好坏,所有细微贡献以及无名英雄的辛勤汗水都是项目成功的关键组成部分.近二十年里,我一直在负责设计师.程序员和测试团队的组建与管理工作.这些年,我意识到一个软件开发团队就像一支球队一样,需要有各种角色的球员和不同的技能的专业人员

《程序员度量:改善软件团队的分析学》一连接活动与目标

连接活动与目标 程序员是软件开发团队中的球员,这个软件开发团队是某个商业活动或者组织的一部分.至少这个组织的一些目标同样也是这个软件开发团队的目标(因此,那些目标也同样是程序员的目标).最有意义和有用的度量允许将程序员和团队关联到组织目标上. 为了做到这一点,需要定义那些软件团队所共享的组织目标,并且这些目标可以精确地或近似地测量出.然后,需要确定程序员和团队的哪些技能是可以测量的,最终,必须建立一个模型或者度量将技能与目标关联在一起. 你可能说,运动团队有一个清晰的目标,那就是赢得比赛(并且最

《程序员度量:改善软件团队的分析学》一软件团队是成功还是失败

软件团队是成功还是失败 在体育运动中,每个团队都为胜利而战,而成功的定义也很清晰.精确.软件开发与此不同,我们缺乏对成功的恰当测度.我所发现的最佳策略是软件开发团队的成功三角形,它基于三方面的因素:客户响应.质量指标和效率.这些都能按发布版.特性来测量,并且可以相对于先前的水平.团队目标和组织目标加以评估. 用户对每个软件发布版的响应是什么 开始时,你可以考虑以三个月为周期测量用户对新发布版的采用率是否达到了20%.你能够同设定的目标相比较.为客户响应.质量指标和效率进行这种检测,为团队提供了一

《程序员度量:改善软件团队的分析学》一有价值的数据

有价值的数据 本书后续章节将讨论一些特定的程序员度量.某些度量相当简单,基于产品bug这类原子数据:而有些度量相对更复杂一些,它们需要利用公式以及多个数据元素的组合. 无论如何,在深入探究特定的度量之前,我们都应考虑各种可用于程序员度量的数据类型,并思考这些数据是否有用处.我们需要广泛而深入地思考那些令人关注的.新的数据元素,因为它们能够带来更有意义的度量.同样,程序员和软件团队的工作需要关联到团队和组织的目标.我们也同样需要认真地思考如何确定这些数据. 下面的列表是我发现的一些有用的数据示例,

《程序员度量:改善软件团队的分析学》一度量可以帮助回答哪些问题

度量可以帮助回答哪些问题 如下关键问题是构造度量的第一步需要考虑的:关于程序员和软件开发团队,你希望了解哪些方面.为了创建有意义的和有用的度量,需要弄清楚要回答的问题.有些问题显而易见,而有些则不是.问题一旦确定,就可以决定哪些数据可用,这些可用数据的中哪些元素最有助于构建有意义的度量,用于帮助你理解成功团队模式的整体目标.

《程序员度量:改善软件团队的分析学》一好的度量像探照灯

好的度量像探照灯 虽然度量不能告诉你哪些技能是好的,哪些技能是坏的,但是具体的度量本身显然有好有坏.坏的度量通过没用的或者实际不相关的细节浪费你的时间,分散你的注意力,使你不能有更深刻的理解:好的度量拨开迷雾,将灯光照耀在真正紧要的事情上.特别是那些随着时间流逝,你或许已经错过.忘记或未能充分欣赏的事情.问题是,如果你不使用它们的话,你无法区分哪些是坏的度量,哪些是好的度量.如果度量太难于收集,或者太抽象并且混乱,我们可以认为这些度量是坏的.你可以通过如下这些问题来评估一个度量本身的好坏: 这个