卡诺模型-产品需求的认识

卡诺模型是有关需求认知的一个很重要的模型。1984年日本人Noriaki Kano博士提出的。在这个模型里把需求分为4类。

亮点(attraction)需求

线性(linear)需求

基础(fundamental)需求

无差异(indifference)需求

模型是一个二维图表,横坐标是产品功能(左边是不需要实现,右边是必须实现),纵坐标是客户满意度(上边是客户非常满意,下面是客户不满意)。

一个产品的需求无外乎包含以上4类需求。我们需要知道这4类需求的特点,来区别对待才能最优我们的产品。

亮点需求

对于一个产品,如果没有亮点需求,那么就很难出类拔......

总结 - Agile1001公开课 第三期【北京】敏捷需求捕获By用户故事

2014.1.19 王立杰老师为大家带来了一场敏捷需求的公开课(蛇年的最后一场)。这次非常感谢联众游戏为我们提供场地赞助。(如有企业或个人能提供场地赞助,请联系我或王立杰老师)

会后的合影:

关于用户故事的3C【DanielTeng扩充为5C】和INVEST原则,也可以参考我之前总结的一篇博文。

会后大家对于这次公开课的反馈:

王x 17:32 谢谢您王老师!辛苦了

Arthur 17:34 王老师讲得好!

Arthur 18:02 提问: 第一排的那个儒雅风度的是谁? 回答: 王老师

Arthur 18:03 再提问......

敏捷软件开发中的版本规划

如上图,开始之前我们假设产品backlog做过第一次梳理,并且总的故事点为127.

 

0. 在迭代开始之前,需要有一个产品backlog,并且其中顶部的一些故事是相对更详细的。

 

1. 产品backlog需要符合INVEST标准(参见我的一篇博客)。为了达到这个标准,需要产品负责人(PO)和团队一起(早期有可能是团队代表或核心人)对产品backlog进行优先级排序,估算(有故事点估算、团队估算、三角估算等方法)等梳理工作。

 

2. 假设我们有一个产品backlog如附件所示,每个sprint为3周,第一个sprint团队计划完成21个故事点......

Scrum抛球游戏介绍

游戏规则

一组或者多组都可以(每组建议5-9人——你懂得)

从哪个人开始,到那个人结束

不允许把球传给相邻的人

球必须有滞空时间

所有人都参加

每个迭代2分钟

迭代后有1分钟做回顾和下一迭代的估算

一共5个迭代(可以酌情删减)

游戏手册

介绍游戏(2分钟)

介绍游戏规则(2分钟)

团队准备时间(2分钟)

估算能传递几个球

开始第1个迭代

回顾和下一个迭代的估算(1分钟)

重复4次

总结(15分钟)

计分用的表格

 

总结的要点

在游戏里发生了哪些事情?

哪个迭代是最好的?为什么?

哪个地方能体现出......

企业的主管领导们,你们准备好敏捷了吗?

主管领导经常宣扬敏捷,但他们真正了解什么是敏捷吗?当然,敏捷增加了协作,提高了透明度和响应变化的能力。谁不喜欢呢?主管们所了解的是,敏捷转型只影响Scrum团队。下面让我们看看对于组织而言敏捷是什么:

CIO - Chief Information Officer

传统的资源模式受到冲击。Scrum需要团队奉献精神,构建高效能团队和可靠的开发节奏(速率)。为了支持这个观点,你需要确保有价值的工作稳定产出。这需要真正的协作。

_基础架构_需要支持持续集成和频繁发布。开发、运维模式(dev ops),这是一种很好的方式。

敏捷转型可能需要几年时间,因此Scrum团队最大的挑战......

2014.1.16

Remember when life’s path is steep to keep your mind even. 记住,当人生之路陡峭之时,要保持沉着。

林肯

Agile1001公开课 第三期【北京】敏捷需求捕获By用户故事

Agile1001第三期公开课,再次迅速降临北京!感兴趣的同学请于后台回复报名

报名格式: 中文姓名、手机、公司

题目:【实战工作坊】敏捷需求捕获By用户故事

地点:望京附近,近地铁15号线出站口,为防止空降,具体地址另行通知。

内容:据Standish Group分析,在项目失败的原因中,有近7成是跟需求相关的。如何在敏捷的背景下有效的分析、捕获需求,是实施敏捷软件开发的第一要素。本工作坊试图通过理论讲解加上实战演练,让听众掌握如何通过用户故事(User Story)来分析、描述、估算一个需求,进而管理多个需求。

本工作坊同时覆盖如何区分用户角色,如何......

《克服团队协作的五种障碍》读书笔记

2014.1.14

Sometime a little discomfort in the beginning can save a whole lot of pain down the road. 有时起初的隐忍可以避免一路的痛苦。

回顾会议墙——改进回顾会议结果的一种工具

_译者注:回顾会议是敏捷的核心,在敏捷原则最后一条中提到“团队定期地反思如何能提高成效,并依此调整自身的举止表现。” 对于团队如此,个人何尝不是呢。作为一个上进的人,需要时刻反思如何改进自己,调整自己的行为,向着自己的目标前进_。

回顾会议变得很无聊,或者只产生几点改进意见、做的好的地方,这是很普遍的。下面介绍一个对我的团队很有效的方法。这个方法不是说比其他方法更好。只是为回顾会议提供一个新的尝试。

首先,先说明一下为什么我想改进回顾会议。全组人(除了PO,通常是代表客户的)坐在一起,比较随意的开始提出一些想法,在这个sprint中哪些事情做得好(正面的)以及哪些地方做得不好(......

Social Media

Search

Recent Articles