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

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

敏捷工作方式如何签署合同?

对于敏捷方法,人们常常提出这样的问题:“如果基于敏捷工作方式,应该如何签署合同?”

传统的瀑布式模型,与公司采购的方式完全契合:先整理出需求,一家供应商提供一个报价(基于他们对需求的阐释和对成本的估计),大家都签署一个法律上的捆绑协议。
Read more

事物不断变化(流程也需调整)

Jonathan Kohl是一位咨询顾问、作家和知名博主,他提出了这样的观点:时下团队在工作中身处的或正在构建的技术环境,与过去那些曾诞生了许多通用开发流程的环境已经有了很大不同。他鼓励团队在检查流程时保持清醒和活跃,并让自己做好准备,以能够适应当今他们工作中身处的现实。
Read more

使每日站会的价值最大化

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

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

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

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

把客户融入进来

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

Read more

可持续的节奏:相信你的团队

无止境的商业需求,特性需求,市场压力,总是有更多的工作要完成。有时候,你会感觉无止境的sprint就像你觉得你每次快到终点的时候,总有人告诉你还有一圈。你鼓足了劲继续前行,但是当你转过最后一个弯道准备冲线的时候,你听见场外有人在喊“还有一圈,还有一圈”,然后你试图再次给自己鼓劲但是你已经筋疲力尽。你一直在想你会有机会休息的,但是你从来没有等到那一天。一个接一个的sprint就像一圈又一圈的赛跑,你永远都看不到终点。你需要调整你的呼吸,需要补充水分,你已经慢慢开始体力透支,直到最后精疲力竭。
Read more

为大数值辩护

很多人为我允许(甚至是鼓励)大家将用户故事估算成20,40和100这样的大数值感到惊讶。我们在我们举行的会议以及课程中出售和赠送的计划扑克牌中也把这些大数值的卡片包含进去了。然而,很多人告诉我,他们一个开始就将这些20,40和100的点数卡片抽出然后再也不用了。
Read more