文章

敏捷团队中测试工程师的绩效管理

众所周知,绩效管理从来都不是一个容易的工作。为什么绩效工作不容易?从我自身的感受以及听到的抱怨中,主要有两个方面的原因。首先是评价标准的确定。对测试工程师团队来说,通常测试工程师都会分散在不同的项目中,追求建立一个“公平的”标准非常困难;其次是在对绩效工作的理解上,绩效工作包括目标设定、绩效评价、绩效跟踪、绩效沟通几个主要部分,但不少测试管理者仅仅把重点放在绩效评价上,忽略了目标和基于目标的沟通,导致绩效工作变成了一个单纯的打分,这样自然引入了许多的问题。
Read more

如何对团队进行绩效考核

很多公司都会进行绩效考核,不管你怎么做,你对你的团队成员进行细致的绩效考核,最终的结果,可能不是你想看到的。我们做绩效考核的主要目的只是为了提高工作效率,提高个人和公司的管理水平。但是得到不好考评的人,可能会感到心里不平衡而导致离职等等,这就背离了我们当初做这个绩效考核时的目的。
Read more

敏捷团队如何进行绩效考核?

近期公司要求各部门必须要制定详尽的KPI考核方案,看了下人力下发的模版,对研发非常非常不科学,简直把研发工作当做了工厂产线,于是特别针对我们部门的敏捷团队,制定了这么一套考核方案。
Read more

使每日站会的价值最大化

在最近过去的几年中,我在许多不同的每日站会中担任过参与者和协助者的角色。众所周知,每日站会的真正价值在于团队有能力不断地为当前的sprint周期的“承诺”而努力。每日站会并不是状态汇报,现在团队成员经常很容易陷入提供状态相关信息的这样一种模式。近期虽然我正在使用一种最老的每日站会的方法,但我认为一个成熟的团队可以从不同的程度来花费15分钟做这些事情,与此同时他也继续在进化使用敏捷/Scrum。
Read more

权利:scrum团队中缺少的要素

我们都明白scrum团队应该自管理和自组织的。被授权是一个通用的术语,因为没有权利,很难进行自管理和自组织。

我和许多团队一起工作过,他们尝试着适应Scrum来作为他们开发的框架。有时候这个顺应就是纯粹地发生了,因为管理部门已经做了决定(这是由上至下的管理方式),有时候不一样的是由团队来做决定(由下而上的管理方式)。我的角色通常是担任团队专门的ScrumMaster,或者为多个Scrum团队担当内部指导。在任何一个情况下,我都根据需要和团队,ScrumMast紧密合作。我经常看到几种典型的问题,下面我将做些讲解。
Read more

把客户融入进来

最近我写了一篇文章,并用反问作为标题:“客户是否已经为敏捷做好准备?”这个想法来源于在软件开发组织已经遵循了瀑布方法学太久的事实,以至于它已经在客户,他们的规划管理办公室和IT部门的灵魂中根深蒂固了。

Read more

敏捷开发方法如何展现项目整体规划

敏捷开发方法近来风气云涌,不少组织、团队开始采用敏捷方法。
敏捷开发方法的阶段划分与传统的瀑布型生命周期是不一样的。敏捷展现出来的是一个又一个迭代,似乎难以展现项目的整体情况。与领导沟通汇报时难以在短时间内说清楚。
Read more