Nick 每周读读书 - 有关于“敏捷开发”
Posted Nick的产品杂货铺
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Nick 每周读读书 - 有关于“敏捷开发”相关的知识,希望对你有一定的参考价值。
《敏捷革命》- 杰夫·萨瑟兰
-
《精益创业实战》- 莫瑞亚
整个敏捷开发过程中最为关键点就是“用户故事”
用户故事是从用户角度出发来描述他们想要获取的功能。
一般来说用户故事包含 3 个要素:
角色(role):谁来使用这个功
活动(activity):需要完成什么样的功能
商业价值(business value):为什么需要这个功能?这个功能能够带来什么价值。
将三要素串联起来就是故事的结构:
作为一个<角色>,我想要<活动>,以便于<商业价值>
-
独立性:尽可能让每个用户故事可以独立于其他用户故事而存在。减少用户故事之间的相互依赖性有助于确定优先级和估算工作量。 -
可协商性:用户故事只是一个概括,具体的细节是在沟通阶段产出。 -
有价值:每个故事对于用户来说都是有价值的,也就是能够帮助用户解决问题的。 -
可估算性: 敏捷开发中开发人员需要根据用户故事评估工作量,因此用户故事的大小必须是适当的,如果太大了,就需要将其拆分多个更小的故事。 -
短小的:短小并不是指越小越好,因为过于小的故事可能会导致开发人员用来评估的时间比实施还要长。所以,尽量保证在一个迭代周期内大家都可以有充足的事情可以做。 -
可测试的:测试的目的是为了确认它是可以完成的。如果不能测试,那么就无法知道它什么时候可以完成。
包括 3 个角色:
-
产品负责人(product owner): 主要回答产品 why & what 的问题。 -
开发团队: 主要解决产品 how 的问题。 -
Scrum master: 类似于教练,帮助团队成员转换为敏捷思维。
产品待办列表:
产品负责人是产品代办列表的唯一负责人。
应当涵盖产品已知所需设想内容的有序列表,是需求变动的唯一来源。通常采用“用户故事”进行描述
会随着产品和环境的变化不断的演进。
列表中的内容有描述、估算、动态和次序的 4 个属性。也可以称为 DEEP 原值
detailed appropriate
estimated
emergent
prioritised
迭代待办列表:
是从产品待办列表中筛选出来的前迭代要实现的“用户故事”。
是开发团队对于下一个产品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的预测
-
产品增量: -
是完成一个迭代的所有待办列表的综合,以及之前所有 sprint 所产生的增量的价值综合。 -
增量必须是完成的且可用的。
迭代(sprint):是 scrum 的核心,整个开发期间,sprint 的长度保持一致。在这段时间内构建一个“完成”的、可用的和潜在可发布的产品增量。
迭代计划会议(sprint planning meeting):计划在迭代中要做的事情。主要回答以下几个问题:
-
what:接下来的迭代交付产品增量中要包含什么内容 how:如何完成交付增量所需要的工作
每日站会(daily scrum meeting):
为每日制定工作计划,汇报上一日工作进度汇报紧张过程中的障碍并据此预估当日工作量。
迭代评审会(sprint review meeting):
用来检视交付成果并按需调整产品待办列表。将产品增量演示给产品负责人和业务方。根据产品负责人和业务方的反馈调整产品代办列表。并且团队成员总结项目过程中的进展与问题。会议的结果是一份修订后的产品代办列表。
迭代回顾会(sprint retrospective meeting):
-
主要是检视团队自身的目的: -
检视前一个 Sprint 中关于人、关系、过程和工具的情况如何; -
找出并加以排序做得好的和潜在需要改进的主要方面; -
制定改进 Scrum 团队工作方式的计划。
承诺:愿意对目标做出承诺
专注:把心思和能力都用到工作中去
开放:把项目中的一切都开放给团队每个人看
尊重:每个人都有独特的背景和经验
勇气:有勇气做出承诺,履行承诺,接受别人的尊重
以上是关于Nick 每周读读书 - 有关于“敏捷开发”的主要内容,如果未能解决你的问题,请参考以下文章