250_194444170000_2

这样做!提高敏捷实施成功率(上)

我并不是第一个写“高效的敏捷实施之十大习惯”此类文章的人,我也肯定不会是最后一个。事实上我并不想又创建出这么个长长的列表,因为有太多类似的列表充斥着敏捷实施的世界。

曾有人报道Ken Schwaber说过在所有试图实施Scrum的团队中大约只有30%的团队能够成功。但Ken在他的博客上说他并不记得这么说过,反而指出大约只有30%的团队能够成为“出色的开发组织”。
Read more

三思而后行

没有敏捷经验的团队成员经常抵制对项目采用这种框架。或许他们含糊地听过一些敏捷的实践,并且他们自己总结。然后我们越强烈的坚持这个实践,他们就越抵制我们所遭遇的。

这通常发生在我们尝试介绍这个(或任何)实践,而没有给团队时间来理解时间背后的真正原理。一位对敏捷感兴趣的项目经理想在他的下个项目中采用敏捷,就像这样。常用的方法是像团队简单地介绍基本原理,然后立马开始使用这些原理。通过召集工作场所的人,并且和他们交谈,或者尝试开每日站会,这些都是不规范的。
Read more

敏捷能够用在支持和维护上面吗?

敏捷已经从一个宣言演变成为一项业界标准。多数的软件厂商都在应用敏捷来解决瀑布式中导致的诸多问题。简而言之,使用固定时间长度的sprint来达成预先设定好的目标以及敏捷所主张的整个实施风格能够解决软件项目中痛处。因此,很多软件开发商都使用敏捷,并且通过做项目计划让他们的客户也参与到敏捷当中来。 Read more

谁将抵触Scrum转型

在1969年《Harvard Business Review》的一篇文章中,Paul Lawrence提到变革“既有技术上的变革也有社会关系的变革。技术方面的变革由日常工作中可衡量的变化组成。而社会关系的变革将影响到企业内已经形成的各种关系。”当我们面对抵触的时候,我们倾向于强调技术上的变革带来的好处。毕竟,我们已经说服了自己,所以我们很容易假设现在所有要做的就是说服别人。我们会认为,只要列出对变革有利的完美知识论据,人们的抵触将会消失。Lawrence反对这种错误的逻辑,“有时,我们可能希望技术上的变革的正确性是它的可接受性的唯一决定因素,但事实上,社会关系的变革才决定了抵触是否存在。”(1969,7) Read more

为什么要让你老板的老板也敏捷起来

增量式软件开发方法的历史可以追溯到19世纪50年代,但是知道2001年《敏捷宣言》发布的时候,敏捷开发及其更好、更快、更轻量级的特点才第一次被完整地诠释。

从那以后,一些开发人员一直致力于改进软件开发的速度和灵活性,但可惜的是,他们并没有得到公司里其他成员的响应。 Read more

Scrum应用中的软度量

和每个精彩的故事一样,这个故事也是这样开始的:

从前有一个穷困的鞋匠和他的妻子一齐住在一个小房子里。他们没有什么家具,没有桌子,没有沙发,更不用说冰箱了。他们的食橱里也是空的。
Read more

对艰难改变的防卫

我看到过不少的文章都说kanban方法比scrum方法要好,因为前者不需要在组织上做出很大变更。我第一次看到这种看法,是在David Anderson的文章里,包括他的<Kanban:技术商业的成功跨步>。文章中的论点是你只需要简单地测量“在制品”(work in progress, WIP),然后稍作改动,使得WIP指数保持在较低水平。这种方法看似比单纯的scrum方法要好,因为scrum方法的特点就是要做出组织内的调整变更。 Read more

有头大象在屋里

我步入了以下这些毫无意义的情形中。我怀疑是因为房间里出现了一头大象而使他们发生(译者注:在西方,“出现大象”意为发生了人们所不了解的新奇的事物)。不知道哪位能否给点意见看一下这头象长得到底是什么样子的?
Read more

企业转型社区

发起、鼓励与支持企业引入和改进Scrum 的小组被称为企业转型社区或ETC。企业转型社区的存在是为了创造一种文化、一个氛围——那些对企业的成功抱有满腔热情的人尝试做出改变,而这些人的成功又使更多的人产生更大的热情。ETC 不是通过给企业强加变革来做到这点,而是通过指导实施变革的小组,移去障碍以便做好Scrum,和为变革创造活力与激情来做到这点的。 Read more

小团队试点,还是全面转型

按照惯例,向Scrum或者任何一个敏捷过程转型,长期以来,通常的建议是以一个试点项目作为开始,从中吸取经验教训,然后在企业范围推广。这个方法就是我们经常使用的小团队试点(start-small)模式,使用这个模式时,企业往往选择一到三个有代表性的团队,每个团队人数控制在五到九个,让这些团队取得成功,然后以此为基础推广Scrum。 Read more