文章

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

/分类： /编辑：

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