敏捷实践

跨职能团队并不意味着每个人都具备所有技能

跨职能团队就是指在团队里面的每一个人都具备完成所有工作的所有技能,这或许是敏捷中最流行和持续存在的一个误区。

这显然是不正确的。跨职能团队的成员具有各种技能,但这并不意味着每个成员都具备所有技能。

敏捷团队拥有专家成员是可以接受的

敏捷团队拥有专家成员是完全可以接受的。(注:本文提到的专家成员是指在团队里面只擅长某个方面的单一技能的团队成员。)
Read more

scrum中文网为什么scrum master不叫Scrum Manager?

为什么Scrum Master不叫Scrum Manager?

scrum中文网,为什么Scrum-Master不叫Scrum-Manager?

 

 

 

 

 

 

 

 

昨天, 去看最新上映的星战8
其中有一段剧情是这样的, 卢克·天行者担心自己没有能力教导下一代绝地武士, 尤达大师现身对他说了一段话, 大意是:

[“yes you can teach them, you can pass knowledge, pass experience, pass…, pass failure, yes, failure, is the most important thing… we are something they grow to beyond, that's the true meaning of masters.

你有能力教导她, 你可以传递知识, 传递经验, 传递…, 传递你曾经失败的经历, 是的, 失败的经历是最重要的, 在我们的帮助下, 他们将超越我们, 这就是一位Master真正的意义. "

*现场听记,可能与原文有出入 ]
Read more

scrum中问网敏捷实践编年史

敏捷实践编年史

敏捷实践编年史(敏捷联盟版)记录了上世纪六十年代至今敏捷相关实践的发展史,其英文原版材料来自于国际敏捷联盟网站(AgileAlliance.org) .

原文链接: https://www.agilealliance.org/agile101/practices-timeline

本文由国内知名敏捷教练李洁(Jerry Li)和廖靖斌(Eric Liao)翻译成中文版本。

1968年:“康威定律(Conway’s Law)”

“康威定律”被提出并概括为:“任何组织,在设计系统(不仅限于信息系统)时,产生的设计在结构上必然会复制自身组织的沟通结构。”长期以来,“康威定律”都只是被当成民间传说,而非得到充分论证的科研成果,尽管最近有些研究为其提供了一些学术支持。(直到90年代中期,软件开发的人际交互方面仍然在很大程度上为软件工程学术研究忽视。)
Read more

timg

Scrum Master的职业发展路线

我最近写了篇博客回答了这个问题:“一个Scrum团队是否可以变得足够的优秀以至于他们不再需要Scrum Master了?”,在这篇文章中我发现了一个与此密切相关的话题:假设Scrum Master不会消失,那么Scrum Master的职业发展路线是什么?

根据我的经验,Scrum Master的职业发展路线通常会有如下的四个方向:
Read more

39d912b

以社交活动的方式做计划-乐高公司的大规模敏捷

Henrik Kniberg & Eik Thyrsted Brandsgård

2016年12月

原文授权链接: http://blog.crisp.se/2016/12/30/henrikkniberg/agile-lego

翻译&审校:

李洁(Jerry Li) 何强 龚正 姚宇宏(Ella Yao) 陈婧(Elina Chen) 申健(Jacky Shen)

统筹&出品:申健(Jacky Shen)

2017年1月

中译文链接:http://www.jackyshen.com/2017/01/31/planning-as-a-social-event-scaling-agile-at-lego/

 

— “什么?一个150人的团队会议只要(2天)1天?”

— “对啊!每两个月一次。运行得非常好。”

— “但是为什么这样?怎么做到的?”
Read more

敏捷变革

敏捷变革模型大荟萃

“ 人们并不抵制改变,他们抵制的只是被改变。”

                                                                                                           - - 《Fearless Change》的作者Linda Rising

本文介绍敏捷变革的一些经典模型,做为撬动组织变革的杠杆,供大家参考实践。如下图所绘:

敏捷转型

  • 问题驱动->应用实践->增量式改善三步走

Read more

scrumcn_userstory

用户故事,史诗故事和主题故事

敏捷团队喜欢以一种刚刚好的方式处理需求。我们采用最低限度地、逐渐细化并保存在产品待办项(Product Backlog)中的特性描述文字,来替代传统长篇大论的需求文档。

我们发现用户故事是最好的描述方式,这种形式能够捕获到特性足够多的信息,并促进产品负责人和团队在后续进一步交流。用户故事是从人(通常是系统的用户或者客户)渴望新功能的视角来对特性进行描述。

用户故事一般会采用以下这种简单格式进行描述:“作为【某类用户】我【想要/能/需要…】以便【满足什么用户价值】”。尽管这种描述格式有其优越性,但只要能围绕着故事进行交流,用户故事可以以任何形式进行描述。
Read more

Scrum中文网

反对迭代0:停止拖延,开始迭代

很多项目都不会一开始就完全就绪——例如,需要分配人员和准备工作。为了处理这些项目开始前的任务,很多团队使用了“迭代0”的做法。虽然理解其由来,但我仍然感到担心。以下是我的理由。

停止“迭代0”的三个理由:

首先,尽管很难相信,但绝大多数的项目都是可以立刻启动的。我所听过的所有声称需要在Scrum项目启动前完成的事项有:需要组建团队,包括调配人员到项目上或雇佣新人;需要获取或者设置硬件设备;需要写一个初始的产品待办列表(即使只是高度概要的)。然而现实情况是:诸如技术环境、初始产品待办列表之类的事项都可以在第一个迭代中完成(一个完全是正常的和传统模式的迭代一),同时至少还可以交付了某些潜在可发布产品增量。
Read more

敏捷管理实践

测试自动化:关注服务层测试

众所皆知,测试应该自动化。敏捷强调要实现测试自动化,但是我们往往都做的不够多、不够快、甚至可能根本没有做。我认为,测试自动化不足的主要原因之一是因为我们关注错了自动化的层次。大多数团队都把精力集中在单元测试和UI测试上,却忽略了服务层测试。

为了说明为何服务层测试如此有价值,让我们仔细观察下测试自动化金字塔的每一层。 Read more