-
Notifications
You must be signed in to change notification settings - Fork 0
/
artefactos-de-scrum.html
199 lines (168 loc) · 15.6 KB
/
artefactos-de-scrum.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
<!DOCTYPE html>
<html lang="es" prefix="og: http://ogp.me/ns# fb: https://www.facebook.com/2008/fbml">
<head>
<title>Artefactos de Scrum - sblancov</title>
<!-- Using the latest rendering mode for IE -->
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link rel="canonical" href="/artefactos-de-scrum.html">
<meta name="author" content="Santiago Blanco" />
<meta name="keywords" content="Agile,Scrum" />
<meta name="description" content="Los artefactos que se usan en Scrum." />
<meta property="og:site_name" content="sblancov" />
<meta property="og:type" content="article"/>
<meta property="og:title" content="Artefactos de Scrum"/>
<meta property="og:url" content="/artefactos-de-scrum.html"/>
<meta property="og:description" content="Los artefactos que se usan en Scrum."/>
<meta property="article:published_time" content="2018-03-19" />
<meta property="article:section" content="Scrum" />
<meta property="article:tag" content="Agile" />
<meta property="article:tag" content="Scrum" />
<meta property="article:author" content="Santiago Blanco" />
<!-- Bootstrap -->
<link rel="stylesheet" href="/theme/css/bootstrap.min.css" type="text/css"/>
<link href="/theme/css/font-awesome.min.css" rel="stylesheet">
<link href="/theme/css/pygments/native.css" rel="stylesheet">
<link rel="stylesheet" href="/theme/css/style.css" type="text/css"/>
</head>
<body>
<div class="navbar navbar-default navbar-fixed-top" role="navigation">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-ex1-collapse">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a href="/" class="navbar-brand">
sblancov </a>
</div>
<div class="collapse navbar-collapse navbar-ex1-collapse">
<ul class="nav navbar-nav">
<li >
<a href="/category/docker.html">Docker</a>
</li>
<li >
<a href="/category/estructuras-de-datos.html">Estructuras de datos</a>
</li>
<li >
<a href="/category/git.html">Git</a>
</li>
<li class="active">
<a href="/category/scrum.html">Scrum</a>
</li>
</ul>
<ul class="nav navbar-nav navbar-right">
<li><a href="/archives.html"><i class="fa fa-th-list"></i><span class="icon-label">Archives</span></a></li>
</ul>
</div>
<!-- /.navbar-collapse -->
</div>
</div> <!-- /.navbar -->
<!-- Banner -->
<!-- End Banner -->
<div class="container">
<div class="row">
<div class="col-sm-9">
<section id="content">
<article>
<header class="page-header">
<h1>
<a href="/artefactos-de-scrum.html"
rel="bookmark"
title="Permalink to Artefactos de Scrum">
Artefactos de Scrum
</a>
</h1>
</header>
<div class="entry-content">
<div class="panel">
<div class="panel-body">
<footer class="post-info">
<span class="label label-default">Date</span>
<span class="published">
<i class="fa fa-calendar"></i><time datetime="2018-03-19T00:00:00+01:00"> lun 19 marzo 2018</time>
</span>
<span class="label label-default">Tags</span>
<a href="/tag/agile.html">Agile</a>
/
<a href="/tag/scrum.html">Scrum</a>
</footer><!-- /.post-info --> </div>
</div>
<h1>Artefactos</h1>
<h2>Product Backlog</h2>
<p>El Product Backlog es una lista ordenada de todo lo que se sabe que tiene que tener el producto. Es la única fuente de requisitos del producto. El Product Owner es responsable del contenido, de la disponibilidad y del orden del Product Backlog.</p>
<p>El Product Backlog nunca está completo. Al inicio del desarrollo se empieza por los requisitos de los que se tiene mayor conocimiento y se entienden mejor. El Product Backlog evoluciona a la par que el producto y el entorno. Por tanto, el Product Backlog es dinámico, se encuentra en un proceso de constante cambio para identificar cuales son las necesidades apropiadas, competitivas y útiles. El Product Backlog existe mientras exista el producto.</p>
<p>El Product Backlog lista todas las funcionalidades, funciones, requisitos, mejoras, y correcciones que constituyen los cambios que habrá que hacer en futuras versiones. Los Product Backlog Items tienen descripción, orden, estimación y valor y, a menudo, también incluyen descripciones sobre como probar que están "Done".</p>
<p>Mientras se usa el producto y va ganando valor, el mercado va dando feedback, el Product Backlog se va haciendo cada vez más grande y se convierte en una lista cada vez más exhaustiva. Los requisitos no paran de cambiar, asi que el Product Backlog es un artefacto vivo. Los cambios en los requisitos de negocio, las condiciones del mercado y la tecnología pueden alterar el Product Backlog.</p>
<p>A menudo, varios Scrum Teams trabajan juntos en el mismo producto. En cualquier caso, solo se usa un Product Backlog para describir el trabajo a realizar en el futuro. En este caso se puede emplear un atributo que agrupe los Product Backlog Items.</p>
<p>El refinamiento del Product Backlog es el acto de agregar detalles, estimaciones y reordenar los Product Backlog Items. Este es un proceso continuo en el que Product Owner y el Development Team colaboran para detallar cada uno. Durante un reginamiento los Product Backlog Items se repasan y se revisan. El Scrum Team decide como y cuando se hace un refinamiento, pero normalmente no sobrepasa el 10% de la capacidad del Development Team. No obstante, los Product Backlog Items pueden ser modificados por el Product Owner o según su criterio.</p>
<p>Cuanto más alto se encuentra un Product Backlog Item, más claro y más detallado suele estar. Cuanto más claros están y con mayor detalle más sencilla y precisa puede ser la estimación. Los Product Backlog Items de los que se encargue el Development Team se refinan para que puedan quedar "Done" dentro del siguiente Sprint. Estos Product Backlog Items que pueden acabar "Done" en un Sprint se suelen considerar "Ready" para que puedan ser seleccionados en futuros Sprint Plannings. Los Product Backlog Items adquieren el grado de transparencia adecuado a través de sucesivos refinamientos.</p>
<p>El Development Team es responsables de las estimaciones. El Product Owner puede influenciar al Development Team ayudandoles a entender y seleccionando soluciones intermedias, pero quienes van a realizar el trabajo son los que dan una estimación al final.</p>
<h3>Progreso hacia los objetivos</h3>
<p>En cualquien momento, se puede ver el trabajo que queda por hacer. El Product Owner puede sabe el trabajo que queda por hacer al menos en cada Sprint Review. El Product Owner compara la cantidad de trabajo que queda con los Sprint Reviews anteriores para evaluar el progreso hacia la consecución de los objetivos. Esta información es transparente para todos los interesados.</p>
<p>Se usan varias técnicas para predecir el progreso, entre ellas destacan graficos del tipo burn-down, burn-up y gráficos apilados. Aunque este tipo de herramientas pueden ser útiles no remplazan la importancia del empirismo. En entornos complejos en los que se desconoce lo que puede ocurrir, solo se puede usar para tomar decisiones con vistas al futuro lo que ya ha ocurrido.</p>
<h2>Sprint Backlog</h2>
<p>El Sprint Backlog es el conjunto de los Product Backlog Items seleccionados para el Sprint, junto con el plan para entregar el Product Increment y completar el Sprint Goal. El Sprint Backlog es una estimación hecha por el Development Team sobre la siguiente funcionalidad que se puede construir como Product Increment y el trabajo que necesita para entregar esa funcionalidad "Done".</p>
<p>El Sprint Backlog representa todo el trabajo que el Development Team considera necesario para conseguir el Sprint Goal. Para asegurar la mejora continua, se incluye al menos un proceso de mejora de alta prioridad identificado en el Sprint Retrospective anterior.</p>
<p>El Sprint Backlog es un plan con suficiente detalle en el que los cambios en progreso se pueden entender en la Daily. El Development Team modifica el Sprint Backlog a lo largo del Sprint, y el Sprint Backlog emerge durante el Sprint. Este surgimiento ocurre porque el Development Team trabaja de acuerdo al plan y aprende sobre el trabajo que necesita para alcanzar el Sprint Goal.</p>
<p>Si se requiere nuevo trabajo, el Development Team lo agrega al Sprint Backlog. A medida que el trabajo se realiza, la estimación del trabajo restante se actualiza. Cuando hay elementos del plan que se consideran innecesarios, se eliminan. Solo el Development Team puede cambiar el Sprint Backlog durante el Sprint. El Sprint Backlog es visible, y debe ser una foto a tiempo real del trabajo que el Development Team tiene planeado completar durante el Sprint, y pertenece solo al Development Team.</p>
<h3>Progreso del Sprint</h3>
<p>En cualquier momento de un Sprint, el trabajo restante total del Sprint Backlog se puede consultar. El Development Team hace un seguimiento del trabajo restante total al menos en cada Daily para predecir la probabilidad de conseguir el Sprint Goal. Al hacer el seguimiento del trabajo restante a lo largo del Sprint, el Development Team gestiona su progreso.</p>
<h2>Product Increment</h2>
<p>El Product Increment es la suma de todos los Product Backlog Items completados durante el Sprint y el valor generado en todos los Sprints anteriores. Al final del Sprint, debe haber un Product Increment "Done", lo que significa que está en condiciones para ser usado y que reune todas las caracteristicas que ha definido el Scrum Team como "Done" tanto si el Product Owner decide sacar una nueva versión como si no. Un Product Increment es un paso más hacia una vision o una meta.</p>
<h1>Transparencia en los artefactos</h1>
<p>En Scrum se confía en la transparencia. Las decisiones para optimizar el valor y el control del riesgo se toman en función del estado de los artefactos. Siempre que haya transparencia completa, estas decisiones tendrán una base solida. Cuando la transparencia sea incompleta, las decisiones tendrán fallos, disminuirá el valor y aumentará el riesgo.</p>
<p>El Scrum Master debe trabajar con el Product Owner, el Development Team y los demás involucrados para saber si los artefactos son completamente transparentes. El Scrum Master es responsable de ayudar a todos a encontrar las prácticas más apropiadas para conseguir completa transparencia. El Scrum Master puede encontrar signos de falta de transparencia examinando los artefactos, buscando patrones, escuchando atentamente lo que se dice y detectando diferencias entre los resultados esperados y los obtenidos realmente.</p>
<p>El deber del Scrum Master es trabajar con el Scrum Team y la organización para incrementar la transparencia de los artefactos. Este trabajo normalmente incluye aprendizaje, convencimiento y cambio. La transparencia no se consigue de la noche a la mañana, pero es el camino a seguir.</p>
<h2>Definición de "Done"</h2>
<p>Cuando un Product Backlog Item o un Product Increment se describe como "Done", todo el mundo debe entender que significa "Done". Aunque esto pueda variar significativamente en cada Scrum Team, los miembros deben tener una idea compartida sobre lo que significa que el trabajo este completo y se asegure su transparencia. Esto es el Definition of Done para el Scrum Team y se usa para asegurarse de cuando el trabajo está terminado en un Product Increment.</p>
<p>La misma definiciones guían al Development Team al conocer cuantos Product Backlog Items pueden seleccionar durante un Sprint Planning. El proposito de cada Sprint es entregar Product Increments de funcionalidad potencialmente desplegable que encaje con la definición actual de "Done".</p>
<p>Los Development Teams entregan Product Increments cada Sprint. Este incremento es usable, asi que el Product Owner puede elegir, publicarlo inmediatamente. Si la definición de "Done" para un incremento es parte de las convenciones, estándares o guias de desarrollo de la organización, todos los Scrum Teams deben seguirlas como mínimo.</p>
<p>Si "Done" para un Product Increment no es una convención de la organización, el Development Team debe definir un Definition of Done apropiado para el producto. Si hay varios Scrum Teams trabajando en el sistema, todos los Development Team deben definir conjuntamente el Definition of Done.</p>
<p>Cada Product Increment se suma a todos los Product Increments anteriores y se prueba completamente, asegurando que toda la funcionalidad funciona junta.</p>
<p>Según los Scrum Teams maduran, sus Definition of Done irá siendo cada vez más extenso, incluyendo criterios para aumentar la calidad. Las nuevas definiciones, pueden no cubrir el trabajo realizado en anteriores Sprints. Cualquier producto o sistema debería tener un Definition of Done que fuera estándar para cualquier trabajo realizado.</p>
<h1>Más información</h1>
<p>La fuente de información principal es la <a href="http://www.scrumguides.org/scrum-guide.html">Scrum Guide</a>. En el sitio oficial de <a href="https://www.scrum.org/">Scrum</a> se puede encontrar información relacionada con Scrum así como todo lo necesario para poder certificarse en los diferentes roles definidos en la guía.</p>
</div>
<!-- /.entry-content -->
</article>
</section>
</div>
<div class="col-sm-3" id="sidebar">
<aside>
<section class="well well-sm">
<ul class="list-group list-group-flush">
<li class="list-group-item"><h4><i class="fa fa-home fa-lg"></i><span class="icon-label">Social</span></h4>
<ul class="list-group" id="social">
<li class="list-group-item"><a href="https://twitter.com/sblancov84"><i class="fa fa-twitter-square fa-lg"></i> Twitter</a></li>
<li class="list-group-item"><a href="https://github.com/sblancov"><i class="fa fa-github-square fa-lg"></i> Github</a></li>
</ul>
</li>
</ul>
</section>
</aside>
</div>
</div>
</div>
<footer>
<div class="container">
<hr>
<div class="row">
<div class="col-xs-10">© 2018 Santiago Blanco
· Powered by <a href="https://github.com/DandyDev/pelican-bootstrap3" target="_blank">pelican-bootstrap3</a>,
<a href="http://docs.getpelican.com/" target="_blank">Pelican</a>,
<a href="http://getbootstrap.com" target="_blank">Bootstrap</a> </div>
<div class="col-xs-2"><p class="pull-right"><i class="fa fa-arrow-up"></i> <a href="#">Back to top</a></p></div>
</div>
</div>
</footer>
<script src="/theme/js/jquery.min.js"></script>
<!-- Include all compiled plugins (below), or include individual files as needed -->
<script src="/theme/js/bootstrap.min.js"></script>
<!-- Enable responsive features in IE8 with Respond.js (https://github.com/scottjehl/Respond) -->
<script src="/theme/js/respond.min.js"></script>
</body>
</html>