文章

介绍一个敏捷团队的绩效评估方法

有很多不做绩效评估的理由。Google是不做的。在google每个人有一个网页,里面有照片,个人简介,三个月目标。每个人在这个网面里做自我评估。

如果你必须得做绩效评估的话,在这里介绍一个1993首次在Easel公司实施并且后续在多家领先的企业中得到优化的评估流程。Hyperproductive团队曾使用这个方法来加速改进他们的效率。 (Hyperproductive 曾创记录的快速递交产品,很多计算机媒体的记者曾惊叹这是他们所见过的同类产品里最好的。) Read more

什么是真正的目的?

随着敏捷开发的成功案例越来越多,越来越多的公司开始关注敏捷。连IBM和微软这样的大公司也开始关注敏捷开发。IBM已经有25%软件项目开始使用敏捷。微软著名的Pattern&Practice团队很早就在使用敏捷方法和实践,甚至微软vSTS团队在全球开发VSTS 2010项目中也在使用Scrum等敏捷方法。越来越多的公司和团队开始关注敏捷,讨论敏捷,导入敏捷,敏捷渐渐成了一种时尚。于是我们听到了越来越多导入敏捷失败的案例。我听说很多公司的高层听了Scrum介绍后感觉不错,马上吩咐下属去制定计划导入Scrum。下属人员或者去参加Scrum课程,或者去读了Scrum的书,然后就开始在团队里面推广实施。不出意外,很多失败了。也有很多即使没有失败也是只是借用了Scrum的一些形式,其实实质上还是在继续原有的方法体系。我曾经面试过一个在某最著名公司里做了两年ScrumMaster的应聘者。在面试中他告诉我他们团队一直在用Scrum框架,迭代开发,有sprint 计划、每日站立会议、demo等等,可是令我吃惊的是他告诉我两年内他们的Scrum从来没有发生过变化。Scrum的一个重要的原则是”审查和调整”。而这个Scrum团队,这个ScrumMaster在做Scrum的两年中,竟然没有进步,这绝对不是Scrum,绝对不敏捷! Read more

技术债务和设计死亡

第一部分

 在最近的一次Scrum聚会上,Ken Schwaber 和Jeff Sutherland谈到技术和设计的死亡。虽然这两个概念本身不是新的,Ken和Jeff发现的关于它们的许多特征(我认为)属于独创而深刻的见解。此外,他们还概述了一些有用的图表,公司或部门可以用它来显示软件产品的“健康”状况。我本来打算写一篇文章,讨论这些图表指示的含义以及图表所需的数据。不过,我想为此引用说明Ken和Jeff观点的文章。搜索了网络,我却没有找到什么。最后我决定,既写介绍,也写后续的文章。这第一篇文章是介绍,讨论了技术债务、设计死亡的概念,及其最主要的特点。 Read more