Scrum Guides 2017年最新修改

Scrum指南2017与2016之间的改动

采用Scrum中增加章节:

最初Scrum是为了管理与开发产品而开发的。从90年代早期开始,Scrum已经在全球范围内得到广泛应用:

研究及识别可行的市场、技术与产品能力;

开发产品及增强功能;

每天多次频繁发布产品及增强功能;

开发和维护云(线上、安全、按需)及其它操作环境以供产品使用;

维护及更新产品。

Scrum已经用来开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶汽车、学校、政府、市场、管理组织的运行以及我们日常生活中,作为个人及社会使用的几乎每件事情。

随着技术、市场与环境的复杂性及它们的相互作用快速增长......

Scrum转型遇到问题整理

BOB老师提出的三个问题:

1、Sprint进行到一半的时候(比如两周的Sprint,过去了一周),总监要把团队中的一名骨干成员调走到另一个重要的项目。作为Scrum Master,碰到这样的情况,你会怎么办?请列出具体的解决方案以及原因。

回答1(guogegi)、我会找总监先协商下骨干成员调离的时间。最好的情况是能有一定的交接期,包括能保证本迭代已经承诺的交付能达成。并根据协调的时间和队员一起协商交接的计划和方案。

回答2(色拉)、与po一起找总监沟通急调的原因。是短期还是长期?并告知会带来的影响。如果确实要调离,询问是否有骨干的backup帮助团队完成需求。没......

特性团队是敏捷必须的吗?

敏捷真的必须都是特性团队吗?

在回答这个问题之前,我们先来一起看看团队的分类和各自的优缺点。目前大多数组织内团队为组件团队(Component Team),与之对应的就是特性团队(Feature Team)。

组建团队

优点:同一组件的人在一个团队内,组件的所有权清晰,大家的技能相同,便于交流沟通。

缺点:不利于产品交付,做出的组件与其他组件集成时可能出现问题。

特性团队

什么是特性团队?

Larmen和Vodde总结认为:理想的功能特性团队是应该跨职能、跨组件以及同地协作的。团队开发完整的用户功能,一般由6到8名具备通用技能、同时各具专长的人组......

京东敏捷模型

本文开篇引用《管理3.0》里的一句话:

所有模型都是错误的,但都有用。

以下是我在京东研发实践总结的敏捷模型(或者叫模式),供敏捷爱好者参考。

该模型的名字是“一个核心,四个基本点”

more

一个核心是以价值为核心。

四个基本点分别为:透明、迭代、反馈和教练。

不给工具的模型都是耍流氓!

--引用自某人

下面分别介绍一下该模型当中用到的工具。

以价值为核心 -- 工具实践是产品列表,详细介绍请点击。

Scrum教练静修报名接近尾声啦--Scrum联盟赞助主办

2015年9月更新

Scrum教练静修活动(Retreat)已经报名41人,每个人都是非常有经验的敏捷教练,而且他们来自10个不同的国家和地区,分别是中国、香港、台湾、巴西、澳大利亚、德国、美国、印度、日本、泰国。想要来和高手过招吗?

活动详情

报名链接

2015年7月

Scrum教练静修活动通知:重大消息,早鸟名额只剩下少量的几个,如果想参加的同学需需要抓紧啦。

另外,为了达到静修的目的,整体参与者数量限制在75人,并且为了更好的多样性,每个企业限报名3人,超过3人将进入等待名单,在静修活动前2周将通知等待名单的结果。

什么是Scrum教......

敏捷估算--Scrum入门基础系列

本文谈及的均为Scrum中的估算行为,这些方法不是Scrum原创的。

为什么要估算

谈估算,我想先从为什么要做估算谈起。

每次在我的培训课上,学员们会给出各种各样的答案。比如为了估计成本、为了设定发布日期、为了知道什么时候可以做完、为了……。但我认为估算最重要的目的是为了

达成共识

如果没有进行估算,关于需求或任务会有一些假设或者背景被忽略掉。因此在Scrum中,估算是一个集体行为,而不是某个专家拍拍脑袋出来的结果。

more

如何做估算

估算的方式分为两大类,绝对估算和相对估算。绝对估算耗时更长,并且需要依赖上下文,最后的结果也会产生较大误......

产品列表梳理(需求梳理)--Scrum入门基础系列

产品列表梳理会议是Scrum中非常重要,而很容易被忽略的一个会议。说它重要,是因为Scrum开始之前就需要有准备就绪的输入,这个输入就来自于产品列表梳理会议的结果,即初始的产品列表。而对于刚开始转型敏捷的团队,往往会忽略掉产品列表梳理会(需求梳理),从而造成迭代计划会时间过长,或者无法准时开始迭代等等问题。要想解决这个问题,需要首先明确为什么在迭代开始之前要进行梳理会议,以及谁需要参加这个会议,在这个会议都有哪些活动等。

产品列表梳理会议,是迭代就绪的很好的指示,即只有产品列表准备好了,才可以进入迭代。另外,梳理会议是由产品负责人发起或负责,可以召集开发团队参与,也可以只有相关的开发团......

Scrum工件-Scrum入门基础系列

Scrum工件主要包含一下3种:

产品Backlog

Sprint Backlog

产品增量

产品Backlog

在Scrum中,主要由产品负责人[参见Scrum入门基础系列之Scrum角色]整理和维护产品Backlog。产品Backlog是Scrum中维护需求的主要工件,也是做好Scrum的第一步。一个好的产品Backlog,是要符合DEEP原则的,即,产品Backlog是详略得当的(Detailed Appropriate),涌现的(Emergent),估算的(Estimated)和排序的(Prioritised)。详情参考参考之前我发的博文“产品Backlog和用户......

Product Backlog Refinement

Here I would like to talk about product backlog refinement meeting, including what activities should be in this meeting, who should join this meeting and why we need refinement meeting.

Why to have product backlog refinement meeting

As the figure above, it occurs during sprint for product backl......

探秘瀑布式软件开发的“错误起源”

最近一直在反思一个问题,那就是瀑布式软件开发的问题究竟出在哪儿了?这个问题首先要先问问瀑布式开发的鼻祖--Winston Royce,而看了Royce当年的论文之后,有不小的发现。其实他当时提出瀑布式软件开发就已经指出这个过程存在很大的问题,在论文中他提出,瀑布式开发中测试在很靠后的阶段才第一次介入(接触到软件),如果发现设计中(或需求上)的问题结果很严重。

论文的原文如下: