1
00:00:09,329 --> 00:00:10,472
[Orador 1]: Muy buenos días a todos.

2
00:00:10,672 --> 00:00:13,472
Vamos con nuestra sesión prevista para
hoy.

3
00:00:15,484 --> 00:00:20,812
Es la cuarta, como sabéis, de una serie
dedicada a métodos ágiles y en particular

4
00:00:20,812 --> 00:00:21,212
Scrum.

5
00:00:21,412 --> 00:00:26,545
Y hoy finalizamos con algo que no es
exactamente algo de proceso o un elemento

6
00:00:26,545 --> 00:00:31,345
organizativo, sino que ya es uno de los
primeros elementos técnicos en el

7
00:00:31,345 --> 00:00:35,745
desarrollo del software, que es la
ingeniería de requisitos con una

8
00:00:35,745 --> 00:00:41,078
metodología de descripción de requisitos
que particularmente casa y se suele usar

9
00:00:41,078 --> 00:00:46,478
en combinación con Scrum como proceso de
desarrollo, que es el de las user stories

10
00:00:46,478 --> 00:00:48,078
o historias de usuarios.

11
00:00:48,698 --> 00:00:53,187
Bueno, por si alguien se suma hoy y no lo
ha hecho a sesiones anteriores,

12
00:00:53,187 --> 00:00:55,308
presentarme un poquito a mí mismo.

13
00:00:55,428 --> 00:00:59,603
Soy Juan Carlos Yelmo, profesor de la
Universidad Politécnica de Madrid y

14
00:00:59,603 --> 00:01:03,721
coordinador de formación de este centro,
del Center for Open Middleware.

15
00:01:03,921 --> 00:01:08,854
Hoy me toca a mí jugar los dos roles de
autopresentarme y de dar la charla.

16
00:01:10,672 --> 00:01:13,205
Bien, pues vamos a empezar ya sin más.

17
00:01:14,477 --> 00:01:15,877
Lo que vamos a ver...

18
00:01:16,913 --> 00:01:21,713
Hoy es una breve introducción para
unificar nuestra terminología, nuestro

19
00:01:21,713 --> 00:01:27,179
conocimiento sobre el campo de aplicación
de lo que es la ingeniería de requisitos,

20
00:01:27,179 --> 00:01:31,913
para luego ir al grano de lo que nos
llevará hoy, yo supongo que unos 50

21
00:01:31,913 --> 00:01:36,579
minutitos no más, más luego un debate
hasta donde a vosotros os parezca

22
00:01:36,579 --> 00:01:37,379
conveniente.

23
00:01:38,480 --> 00:01:42,950
Vamos a hablar de historias de usuario,
vamos a introducir el concepto, vamos a

24
00:01:42,950 --> 00:01:47,592
ver qué formato de representación tiene,
vamos a discutir los distintos niveles de

25
00:01:47,592 --> 00:01:51,604
granularidad de representación de
historias de usuario, vamos a ver qué

26
00:01:51,604 --> 00:01:56,075
podemos hacer entre las historias de
usuario y Scrum para representar y validar

27
00:01:56,075 --> 00:02:00,717
los requisitos no funcionales, vamos a dar
unos criterios de elaboración y con eso

28
00:02:00,717 --> 00:02:01,348
terminamos.

29
00:02:01,548 --> 00:02:05,748
Un par de recomendaciones bibliográficas
lo damos por terminado.

30
00:02:06,317 --> 00:02:08,661
Bueno, vamos a empezar con ingeniería de
requisitos.

31
00:02:08,701 --> 00:02:13,967
Supongo que todos tenemos una noción,
aunque sea intuitiva, de qué es ingeniería

32
00:02:13,967 --> 00:02:14,901
de requisitos.

33
00:02:16,215 --> 00:02:18,481
Pero yo aquí tengo una definición.

34
00:02:19,060 --> 00:02:22,954
Y para no hacerlo yo todo, me gustaría que
en 30 segundos la leyereis vosotros

35
00:02:22,954 --> 00:02:23,309
mismos.

36
00:02:23,509 --> 00:02:26,309
Supongo que se lee incluso desde el fondo.

37
00:02:33,492 --> 00:02:37,265
Bueno, dice, uso sistemático de principios
contrastados, técnicas, lenguajes y

38
00:02:37,265 --> 00:02:39,520
herramientas para hacer algo efectivo en
coste.

39
00:02:39,540 --> 00:02:40,740
Eso es ingeniería.

40
00:02:41,863 --> 00:02:46,126
Siempre que se hace algo de forma
sistemática para hacerlo bien, pero no a

41
00:02:46,126 --> 00:02:48,171
cualquier coste, eso es ingeniería.

42
00:02:48,371 --> 00:02:49,104
Me encanta.

43
00:02:49,332 --> 00:02:50,213
Somos muy útiles.

44
00:02:50,413 --> 00:02:53,918
Hay políticos como Josep Borrell que dicen
que los ingenieros mueven el mundo.

45
00:02:53,938 --> 00:02:57,382
Yo lo digo en casa, mi mujer me mira como
diciendo, si tú lo dices.

46
00:02:57,582 --> 00:03:01,487
Pero hay gente sabia que sostiene que los
ingenieros movemos el mundo.

47
00:03:01,507 --> 00:03:02,385
A mí me gusta.

48
00:03:02,585 --> 00:03:06,146
y que hacemos las cosas bien
sistemáticamente, es decir, que no nos

49
00:03:06,146 --> 00:03:10,301
sale bien una vez, sino que repetida a
veces, lo hacemos bien y que lo hacemos

50
00:03:10,301 --> 00:03:13,916
siempre con un coste proporcional y
equilibrado a lo que pretendemos

51
00:03:13,916 --> 00:03:14,456
conseguir.

52
00:03:14,656 --> 00:03:18,971
En este caso, para el análisis,
documentación, evolución de necesidades de

53
00:03:18,971 --> 00:03:22,932
usuario y la especificación del
comportamiento externo de un sistema

54
00:03:22,932 --> 00:03:23,465
software.

55
00:03:23,485 --> 00:03:27,203
En este contexto vamos a interpretar
software para satisfacer dichas

56
00:03:27,203 --> 00:03:27,869
necesidades.

57
00:03:28,069 --> 00:03:32,472
Es decir, que eso en sí es una disciplina
de ingeniería en sí misma.

58
00:03:32,690 --> 00:03:36,808
La ingeniería de requisitos tiene su
complejidad, es una disciplina en sí

59
00:03:36,808 --> 00:03:41,555
mismo, tiene libros, congresos, expertos,
es decir, que hay gente que se dedica solo

60
00:03:41,555 --> 00:03:44,358
a eso y que ha alcanzado una madurez
considerable.

61
00:03:44,558 --> 00:03:45,891
Abarca muchas cosas.

62
00:03:47,084 --> 00:03:50,091
La ingeniería de requisitos suele tener
como dos grandes ramas.

63
00:03:50,071 --> 00:03:54,316
por una parte el desarrollo de requisitos
y por otra la gestión de requisitos.

64
00:03:54,357 --> 00:03:58,985
En cuanto a desarrollo de requisitos leo
una cosa que está en la transparencia

65
00:03:58,985 --> 00:04:03,553
siguiente para que luego cualquiera que lo
pueda leer pero que yo leo aquí en

66
00:04:03,553 --> 00:04:08,121
relación con este dibujo es, consiste en
identificar, acordar y documentar el

67
00:04:08,121 --> 00:04:12,749
conjunto de requisitos y características
de producto que permitan alcanzar los

68
00:04:12,749 --> 00:04:17,557
objetivos de negocio planteados por el
sistema e involucra actividades de captura

69
00:04:17,557 --> 00:04:18,338
de requisitos

70
00:04:18,539 --> 00:04:22,751
que es la comprensión de los usuarios y
sus necesidades, en inglés lo llaman

71
00:04:22,751 --> 00:04:27,077
elicitation, que podremos traducir como
sonsacar, lo que pasa es que como aquí

72
00:04:27,077 --> 00:04:31,289
tiene una connotación negativa, decir
sonsacar, que parece un interrogatorio

73
00:04:31,289 --> 00:04:35,839
policial, pues casi siempre lo dejamos en
captura de requisitos, pero en inglés se

74
00:04:35,839 --> 00:04:37,188
suele decir elicitation.

75
00:04:37,388 --> 00:04:42,921
Luego esos requisitos hay que analizarlos
desde una perspectiva ya técnica por parte

76
00:04:42,921 --> 00:04:47,788
de los ingenieros, de forma que los
desarrollan, los refinan, los valoran,

77
00:04:47,788 --> 00:04:52,921
hacen con ellos determinados modelos,
establecen criterios para posteriormente

78
00:04:52,921 --> 00:04:53,988
validarlos, etc.

79
00:04:55,937 --> 00:04:57,523
Luego está la especificación.

80
00:04:57,723 --> 00:05:02,943
que es el registro de la información sobre
requisitos para facilitar la comunicación

81
00:05:02,943 --> 00:05:08,163
entre stakeholders de forma que queda por
escrito y no a lugar a confusión sobre qué

82
00:05:08,163 --> 00:05:13,257
es lo que interpretamos que debía hacer el
sistema y finalmente está la validación

83
00:05:13,257 --> 00:05:18,100
que es asegurarnos de que los requisitos
son correctos y el sistema finalmente

84
00:05:18,100 --> 00:05:19,609
desarrollado los cumple.

85
00:05:19,912 --> 00:05:23,479
Y luego hay una faceta que algunas veces
uno no recuerda bien cuando habla de

86
00:05:23,479 --> 00:05:26,109
ingeniería de requisitos que es la gestión
de requisitos.

87
00:05:26,309 --> 00:05:30,993
que tiene que ver con la gestión de la
evolución de los requisitos, atendiendo a

88
00:05:30,993 --> 00:05:35,560
su evolución temporal, peticiones de
cambio sobre los requisitos, es la típica

89
00:05:35,560 --> 00:05:40,245
tarea de gestión de configuración, gestión
de versiones, gestión de cambios, que

90
00:05:40,245 --> 00:05:45,226
normalmente interpretamos que aplica sobre
código fuente de un sistema en desarrollo,

91
00:05:45,226 --> 00:05:47,657
pero que también aplica a los requisitos.

92
00:05:47,858 --> 00:05:52,450
Todos los requisitos evolucionan con el
tiempo y aunque en un momento se registran

93
00:05:52,450 --> 00:05:56,873
de una manera, algún stakeholder puede
solicitar un cambio posterior sobre él y

94
00:05:56,873 --> 00:06:01,239
ese cambio hay que valorarlo y hay que
priorizarlo y hay que decidir qué coste

95
00:06:01,239 --> 00:06:05,719
tiene, hay que decidir si se lleva o no se
lleva a cabo y cómo se lleva a cabo y

96
00:06:05,719 --> 00:06:06,967
quién lo lleva a cabo.

97
00:06:07,167 --> 00:06:11,686
Además los ingenieros lo refinan y lo
desarrollan y lo extienden según va

98
00:06:11,686 --> 00:06:16,143
pasando el tiempo, sobre todo en un modelo
de proceso que sea iterativo.

99
00:06:16,343 --> 00:06:20,306
Y eso requiere control de cambios y
control de versiones y hay herramientas

100
00:06:20,306 --> 00:06:22,878
para hacer eso y es en sí mismo también un
mundo.

101
00:06:23,078 --> 00:06:26,907
Nosotros en cualquier caso en la charla de
hoy nos vamos a ocupar más de la

102
00:06:26,907 --> 00:06:30,425
izquierda, del desarrollo de los
requisitos y sobre todo en lo que se

103
00:06:30,425 --> 00:06:31,357
refiere a captura.

104
00:06:31,557 --> 00:06:33,757
Ese es un poquito nuestro ámbito.

105
00:06:37,218 --> 00:06:38,840
¿Pero qué es un requisito del software?

106
00:06:38,860 --> 00:06:42,105
Pues también todos nos imaginamos qué es
un requisito del software.

107
00:06:42,345 --> 00:06:45,750
Bueno, supongo, porque ni siquiera nos
ponemos de acuerdo en cómo llamarlo.

108
00:06:45,950 --> 00:06:50,510
Muchos de nosotros decimos requisitos,
otros tantos de nosotros decimos

109
00:06:50,510 --> 00:06:55,853
requerimientos, que parece que queda bien
por la traducción del inglés requirement,

110
00:06:55,853 --> 00:06:56,244
¿vale?

111
00:06:56,264 --> 00:07:00,648
Yo prefiero requisitos, no le voy a decir
a nadie cómo debe llamar a las cosas, yo

112
00:07:00,648 --> 00:07:05,086
prefiero requisito que requerimiento, que
a mí me suena más a la orden que te da un

113
00:07:05,086 --> 00:07:07,089
juez de ven pa' acá, pa' acá, ¿vale?,

114
00:07:07,289 --> 00:07:08,689
¿Qué es un requisito?

115
00:07:12,578 --> 00:07:17,244
Un requisito es una capacidad
característica o factor de calidad que un

116
00:07:17,244 --> 00:07:21,844
sistema software necesita para tener valor
y utilidad para un usuario.

117
00:07:26,580 --> 00:07:30,380
No sé si estáis de acuerdo en esa
definición de requisito.

118
00:07:31,218 --> 00:07:35,503
Es algo que un sistema tiene que cumplir
obligatoriamente para demostrar

119
00:07:35,503 --> 00:07:39,850
conformidad con unas necesidades
planteadas de una manera también formal.

120
00:07:40,050 --> 00:07:45,383
De forma que para que tenga valor para mí
un sistema es imprescindible que cumpla

121
00:07:45,383 --> 00:07:50,716
esto, esto, esto, esto y esto y de no ser
así pues degradará el valor que para mí

122
00:07:50,716 --> 00:07:51,116
tiene.

123
00:07:53,999 --> 00:07:55,221
Eso es un requisito.

124
00:07:55,421 --> 00:08:00,617
Desde ese punto de vista, la ingeniería
del software y la ingeniería de requisitos

125
00:08:00,617 --> 00:08:05,750
en particular tiene como objetivo básico
encontrar enfoques sistemáticos para que

126
00:08:05,750 --> 00:08:10,562
de una manera eficiente y repetida poder
ser capaz de encontrar, documentar,

127
00:08:10,562 --> 00:08:15,823
organizar, monitorizar los requisitos de
un sistema que sucede que son cambiantes y

128
00:08:15,823 --> 00:08:18,133
no porque sea una maldición bíblica,

129
00:08:18,113 --> 00:08:23,313
como lo de que te ganaras el pan con el
sudor de tu frente y parirás con dolor.

130
00:08:24,805 --> 00:08:26,208
No es una maldición, es una realidad.

131
00:08:26,408 --> 00:08:31,408
Debemos hacer mecanismos organizativos que
encajen bien esa evolución en los

132
00:08:31,408 --> 00:08:32,141
requisitos.

133
00:08:33,082 --> 00:08:36,319
Desde luego que el modelo de proceso
determina también el modelo de gestión de

134
00:08:36,319 --> 00:08:36,950
los requisitos.

135
00:08:36,990 --> 00:08:41,984
Puede haber modelos secuenciales como el
cascada donde los requisitos se establecen

136
00:08:41,984 --> 00:08:46,978
al principio y se congelan a lo largo de
la duración de todo el ciclo de desarrollo

137
00:08:46,978 --> 00:08:51,850
o hay modelos iterativos que los crean y
los hacen evolucionar enriqueciéndoles a

138
00:08:51,850 --> 00:08:54,043
lo largo de todo el proceso y además

139
00:08:54,023 --> 00:08:59,013
SELES de alguna manera cuantifica el valor
de negocio para priorizarlo, pudiendo

140
00:08:59,013 --> 00:09:03,499
reconsiderar esa prioridad o ese valor de
negocio a lo largo del tiempo.

141
00:09:03,699 --> 00:09:09,165
Son dos modelos que encajan en distintas
tipologías de proyectos, no hay ninguno de

142
00:09:09,165 --> 00:09:14,565
ellos que sea mejor que el otro, sino que
simplemente son diferentes y que tenemos

143
00:09:14,565 --> 00:09:18,432
que ser capaces de adecuarlo a lo que el
proyecto nos pide.

144
00:09:19,488 --> 00:09:24,754
El ser humano, cuando se plantea cosas muy
complejas, que no es capaz de manejar

145
00:09:24,754 --> 00:09:28,421
conceptualmente de una sola tacada, tiende
a clasificar.

146
00:09:31,012 --> 00:09:34,841
Esto no sé lo que es, pero te voy a decir
los tipos que hay.

147
00:09:35,041 --> 00:09:36,441
Por ejemplo, la vida.

148
00:09:37,325 --> 00:09:42,725
Muy difícil saber qué es la vida, pero te
voy a clasificar las distintas especies,

149
00:09:42,725 --> 00:09:44,391
en mamíferos, primates...

150
00:09:44,691 --> 00:09:46,633
Entonces, no sé definirlo, pero clasifico.

151
00:09:46,653 --> 00:09:51,056
Pues lo mismo pasa con los requisitos, que
es muy complicado definirlo, pero los

152
00:09:51,056 --> 00:09:53,899
clasificamos, que es siempre la estrategia
de huida.

153
00:09:53,919 --> 00:09:58,652
Entonces, los requisitos del software
tradicionalmente se descomponen en

154
00:09:58,652 --> 00:10:00,585
funcionales y no funcionales.

155
00:10:03,587 --> 00:10:07,365
Y últimamente aparece otra categoría, que
son las reglas de dominio.

156
00:10:07,565 --> 00:10:12,565
Los requisitos funcionales son las
funciones o características que describen

157
00:10:12,565 --> 00:10:15,365
qué debe hacer el sistema en mi beneficio.

158
00:10:17,876 --> 00:10:22,955
Pongamos el caso de un cajero automático,
un cajero automático de banco, que ofrece

159
00:10:22,955 --> 00:10:27,849
a los clientes del banco la posibilidad,
las 24 horas del día, en casi cualquier

160
00:10:27,849 --> 00:10:32,124
lugar cercano a donde te encuentras,
obtener información sobre saldo y

161
00:10:32,124 --> 00:10:33,673
movimientos de tu cuenta.

162
00:10:33,822 --> 00:10:38,317
De forma que eso ofrece un valor a las
personas que tienen una manera sencilla de

163
00:10:38,317 --> 00:10:41,071
mantener un control sobre sus finanzas
personales.

164
00:10:41,271 --> 00:10:46,804
Una persona observa eso de valor, resuelve
una de sus necesidades y tanto es así que

165
00:10:46,804 --> 00:10:52,137
está dispuesto a pagar por ello, sea vía
una comisión o sea vía comisiones cuando

166
00:10:52,137 --> 00:10:54,137
lo utilice como medio de pago.

167
00:10:55,709 --> 00:10:58,575
O sea, eso ya depende del modelo de
negocio.

168
00:10:58,813 --> 00:11:03,013
Un requisito no funcional es un atributo
de calidad del sistema.

169
00:11:04,012 --> 00:11:09,078
de tipo prestaciones, el sistema tendrá un
tiempo de respuesta inferior a 0,2

170
00:11:09,078 --> 00:11:14,212
segundos, el sistema procesará 7500
paquetes por minuto, ese tipo de cosas, de

171
00:11:14,212 --> 00:11:15,412
tipo de velocidad,

172
00:11:20,887 --> 00:11:25,953
precisión, el sistema calculará la
gravedad terrestre hasta la milmillonésima

173
00:11:25,953 --> 00:11:28,553
de ese tipo de cosas, son prestaciones.

174
00:11:30,198 --> 00:11:34,208
O pueden ser cosas como requisitos de
interfaz, que a pesar del nombre no se

175
00:11:34,208 --> 00:11:38,057
refiere a interfaz de usuario, sino
requisitos en cuanto a interfaces con

176
00:11:38,057 --> 00:11:40,570
sistemas externos que el sistema ha de
respetar.

177
00:11:40,771 --> 00:11:45,411
O son requisitos en términos de operación,
que sí se suele referir a la interfaz de

178
00:11:45,411 --> 00:11:45,864
usuario,

179
00:11:46,064 --> 00:11:48,464
tanto de uso como de administración.

180
00:11:49,469 --> 00:11:54,269
O son requisitos en cuanto a uso de
recursos, memoria, disco, periféricos

181
00:11:54,269 --> 00:11:55,002
especiales.

182
00:11:56,079 --> 00:12:00,545
O son requisitos en cuanto a seguridad,
seguridad de la información,

183
00:12:00,545 --> 00:12:05,612
autenticación, autorización, no repudio,
confidencialidad, ese tipo de cosas.

184
00:12:07,216 --> 00:12:11,820
O pueden ser requisitos de fiabilidad,
tiempo medio entre fallos, tiempo medio de

185
00:12:11,820 --> 00:12:14,180
reparación, porcentaje de disponibilidad.

186
00:12:14,380 --> 00:12:19,401
O son cosas de tipo safety, que podríamos
traducir por salvaguarda, es decir, los

187
00:12:19,401 --> 00:12:24,172
mecanismos que tiene el software para que
en caso de mal funcionamiento no se

188
00:12:24,172 --> 00:12:26,683
ocasionen daños personales o económicos.

189
00:12:27,027 --> 00:12:30,624
Y al final es fácil distinguir un
requisito funcional de no funcional, no,

190
00:12:30,624 --> 00:12:31,216
no es fácil.

191
00:12:31,436 --> 00:12:34,937
Un poquito la regla del 9 es que un
requisito funcional,

192
00:12:35,137 --> 00:12:39,583
no funcional, siendo imprescindible, en sí
mismo no tiene valor de usuario.

193
00:12:39,783 --> 00:12:45,183
Imaginad que a alguien se le presenta un
nuevo cajero automático y dice esto tiene

194
00:12:45,183 --> 00:12:46,783
una interfaz telepática.

195
00:12:48,754 --> 00:12:50,677
Es un requisito de operación.

196
00:12:50,877 --> 00:12:56,410
De forma que tú miras fijamente al cajero
y cuando comprende tu pensamiento cambia a

197
00:12:56,410 --> 00:12:56,743
rojo.

198
00:12:59,068 --> 00:12:59,734
Y ya está.

199
00:13:00,089 --> 00:13:00,770
Pero no da dinero.

200
00:13:00,810 --> 00:13:01,743
No, dinero no.

201
00:13:01,871 --> 00:13:02,937
Se pone en rojo.

202
00:13:03,113 --> 00:13:04,379
¿Pagarías por ello?

203
00:13:06,035 --> 00:13:09,301
Este cajero tarda en responderte 0,7
nanosegundos.

204
00:13:10,441 --> 00:13:11,574
Y dinero no vale.

205
00:13:13,386 --> 00:13:14,387
Solo que es rápido.

206
00:13:14,407 --> 00:13:14,873
En fin.

207
00:13:15,188 --> 00:13:16,851
Y este fiable no se ha caído nunca.

208
00:13:16,911 --> 00:13:18,333
Lleva aquí 10 años, pero da dinero.

209
00:13:18,373 --> 00:13:20,516
No, no, en estos 10 años no ha dado ni un
billete.

210
00:13:20,716 --> 00:13:24,576
Es decir, un poquito la regla del 9, por
recordarlo, es que un requisito no

211
00:13:24,576 --> 00:13:28,853
funcional, siendo imprescindible a nivel
de sistema, en sí mismo no aporta valor de

212
00:13:28,853 --> 00:13:30,471
usuario y nadie pagaría por él.

213
00:13:30,491 --> 00:13:31,224
Como regla.

214
00:13:31,973 --> 00:13:34,573
Las reglas de dominio son requisitos...

215
00:13:34,874 --> 00:13:39,707
que representan restricciones generales
del dominio de aplicación, de la empresa

216
00:13:39,707 --> 00:13:41,910
en que se sitúa o del sistema legal.

217
00:13:42,110 --> 00:13:46,620
Son, por ejemplo, la ley de protección de
datos de carácter personal.

218
00:13:46,820 --> 00:13:50,925
Todo ese sistema informático que atiende
al público debe tener en cuenta que no

219
00:13:50,925 --> 00:13:55,346
puede difundirse información de clientes a
terceros porque hay una ley que lo impide.

220
00:13:55,546 --> 00:13:58,985
Y las reglas de dominio, si hay algo que
las distingue, es que no aplican a un

221
00:13:58,985 --> 00:14:01,576
sistema solo, sino a todos los sistemas de
la organización.

222
00:14:01,776 --> 00:14:06,770
Por ejemplo, es posible, digo yo, no lo
sé, que en un banco solo determinados

223
00:14:06,770 --> 00:14:09,268
empleados pueden hacer arqueo de caja.

224
00:14:09,468 --> 00:14:10,389
Solo algunos de ellos.

225
00:14:10,630 --> 00:14:12,072
Eso es una regla de dominio.

226
00:14:12,272 --> 00:14:16,484
Todos los sistemas, sea para hacer arqueo
de caja de un cajero automático, como para

227
00:14:16,484 --> 00:14:18,667
hacerlo de la caja de una oficina
comercial,

228
00:14:18,867 --> 00:14:22,326
debe cumplir con eso y por tanto sólo
pueden estar autorizados aquellos

229
00:14:22,326 --> 00:14:23,512
empleados que lo puedan.

230
00:14:23,712 --> 00:14:27,252
Es una regla de dominio, no es un
requisito de sistema y un poco la

231
00:14:27,252 --> 00:14:31,544
diferencia está en que aplica a todos los
sistemas de la organización y no sólo a

232
00:14:31,544 --> 00:14:32,403
uno en concreto.

233
00:14:32,603 --> 00:14:34,965
También puede ser aplicaciones de
estándares.

234
00:14:35,165 --> 00:14:40,498
Así que en general podemos decir que hay
requisitos funcionales, no funcionales y

235
00:14:40,498 --> 00:14:41,698
reglas de dominio.

236
00:14:42,314 --> 00:14:46,393
Hay muchas clasificaciones mucho más
pormenorizadas de las que yo he hecho.

237
00:14:46,593 --> 00:14:50,925
Grandes clientes de software como el
Departamento de Defensa norteamericano o

238
00:14:50,925 --> 00:14:54,288
la Agencia Europea del Espacio
proporcionan clasificaciones.

239
00:14:54,349 --> 00:14:59,218
Asociado al modelo de proceso unificado,
ese modelo iterativo, un poco inspirado en

240
00:14:59,218 --> 00:15:04,028
el modelo espiral, también proporciona una
clasificación que se llama Forbes Plus.

241
00:15:04,109 --> 00:15:09,709
y también hay estándares como el ISO 25000
que si bien inicialmente está pensado para

242
00:15:09,709 --> 00:15:14,442
valorar la calidad de los productos de
software a través de una serie de

243
00:15:14,442 --> 00:15:19,775
atributos bien puede ser usado al revés
para clasificar los requisitos en función

244
00:15:19,775 --> 00:15:24,975
de ese estándar de forma que garantiza que
al final cumple con los criterios de

245
00:15:24,975 --> 00:15:30,042
calidad así que bueno estas son las
distintas categorías en la representación

246
00:15:30,042 --> 00:15:33,709
de los requisitos y ya si nos centramos un
poquito en el

247
00:15:34,467 --> 00:15:39,371
En esa figura jerárquica que representaba
la ingeniería de requisitos en la parte de

248
00:15:39,371 --> 00:15:44,098
desarrollo y sobre todo en la parte de
captura de requisitos, fundamentalmente en

249
00:15:44,098 --> 00:15:47,053
la literatura nos encontramos dos grandes
enfoques.

250
00:15:47,253 --> 00:15:51,519
El enfoque centrado en producto y el
enfoque centrado en usuario.

251
00:15:52,237 --> 00:15:56,884
En el enfoque de centrar un producto nos
centramos en describir de manera

252
00:15:56,884 --> 00:16:02,113
pormenorizada las características que el
sistema ha de implementar para cumplir su

253
00:16:02,113 --> 00:16:06,245
objetivo, en forma de funciones,
objetivos, atributos de calidad.

254
00:16:06,445 --> 00:16:10,803
Es la típica especificación de sistema
software que se escribe en forma de

255
00:16:10,803 --> 00:16:15,282
clausulado contractual donde dice
requisito funcional 1, requisito funcional

256
00:16:15,282 --> 00:16:19,104
2, requisito funcional 3, requisito no
funcional 1, requisito no.

257
00:16:19,124 --> 00:16:24,524
El sistema muchas veces ahí en inglés se
pone will o can o may en el sentido de si

258
00:16:24,524 --> 00:16:28,524
es opcional o obligatoria la
característica con una medida de

259
00:16:28,524 --> 00:16:30,524
prioridad, así muy robotizado.

260
00:16:32,433 --> 00:16:37,130
Por ejemplo, sería una característica de
un sistema, el cajero automático dispondrá

261
00:16:37,130 --> 00:16:40,797
de una tecla de cancelación para abortar
la transacción en curso.

262
00:16:40,997 --> 00:16:44,130
Ese es un ejemplo de característica del
sistema.

263
00:16:44,498 --> 00:16:49,631
Este tipo de enfoque es apropiado para
sistemas, software de infraestructura o

264
00:16:49,631 --> 00:16:54,698
software de sistemas operativos, de
protocolos de comunicaciones, middleware,

265
00:16:54,698 --> 00:17:00,164
aplicaciones de tiempo real o empotradas o
aplicaciones en las que el usuario final

266
00:17:00,164 --> 00:17:05,631
no aparece, las aplicaciones intensivas en
computación, en cómputo o tratamiento de

267
00:17:05,631 --> 00:17:06,031
datos.

268
00:17:07,945 --> 00:17:12,545
Entonces son sistemas adecuados para
representarlo de esa manera, pero

269
00:17:12,545 --> 00:17:13,278
últimamente

270
00:17:14,350 --> 00:17:19,816
están ganando una cierta importancia los
llamados enfoques centrados en uso usuario

271
00:17:19,816 --> 00:17:24,816
donde lo que hacemos es ponernos en la
piel del usuario, del humano que va a

272
00:17:24,816 --> 00:17:29,483
utilizar el sistema para tratar de
averiguar cuáles son sus objetivos y

273
00:17:29,483 --> 00:17:34,683
necesidades y estructurar la descripción
de requisitos del sistema de forma que

274
00:17:34,683 --> 00:17:36,483
enfatizamos en primer plano

275
00:17:39,933 --> 00:17:45,133
Unidades de especificación que ponen de
manifiesto que el sistema está ahí para

276
00:17:45,133 --> 00:17:48,533
cubrir sus necesidades, para resolver sus
problemas.

277
00:17:50,149 --> 00:17:54,503
Que todo gira en torno a que sabemos que
él tiene problemas que quiere resolver con

278
00:17:54,503 --> 00:17:56,840
un sistema software y que el sistema lo
hará.

279
00:17:56,860 --> 00:18:02,060
Y que sabemos identificar esas necesidades
y valorar esa importancia o valor de

280
00:18:02,060 --> 00:18:02,593
negocio.

281
00:18:02,950 --> 00:18:08,231
Esto lógicamente es más apropiado para
sistemas intensivos en interacción con los

282
00:18:08,231 --> 00:18:10,542
usuarios, para sistemas finalistas.

283
00:18:10,742 --> 00:18:15,942
Desde ese punto de vista, por ejemplo, que
exista una tecla de cancelación para

284
00:18:15,942 --> 00:18:20,942
abortar una transacción en cualquier
momento carece de valor para un cliente

285
00:18:20,942 --> 00:18:22,942
medio de un cajero automático.

286
00:18:24,903 --> 00:18:26,122
En el sentido de que nadie...

287
00:18:26,322 --> 00:18:30,510
Por eso solo considerado de manera aislada
y autocontenida pagaría un duro.

288
00:18:30,710 --> 00:18:34,417
Oye, este sistema permite que abortes en
cualquier momento.

289
00:18:34,617 --> 00:18:34,717
Bien.

290
00:18:34,737 --> 00:18:35,403
¿Pagarías?

291
00:18:35,659 --> 00:18:36,380
Pues no, gracias.

292
00:18:36,420 --> 00:18:40,496
Ahora bien, tienes un sistema que te
permite tener conocimiento y control sobre

293
00:18:40,496 --> 00:18:42,692
saltos y últimos movimientos de tu cuenta.

294
00:18:42,712 --> 00:18:43,012
¿Mola?

295
00:18:43,112 --> 00:18:43,312
Sí.

296
00:18:43,553 --> 00:18:43,914
¿Pagarías?

297
00:18:44,114 --> 00:18:44,314
Sí.

298
00:18:45,037 --> 00:18:49,970
puedes disponer de un sistema que te
permite disponer de efectivo en muchas

299
00:18:49,970 --> 00:18:55,170
localizaciones geográficas próximas a tu
situación actual y en las 24 horas del

300
00:18:55,170 --> 00:18:55,437
día.

301
00:18:55,892 --> 00:18:56,558
¿Te gusta?

302
00:18:56,773 --> 00:18:57,334
¿Te apetece?

303
00:18:57,354 --> 00:18:58,296
¿Te resuelve un problema?

304
00:18:58,416 --> 00:18:58,616
Sí.

305
00:18:59,277 --> 00:18:59,697
¿Pagarías?

306
00:18:59,878 --> 00:19:00,078
Sí.

307
00:19:00,459 --> 00:19:05,268
Esas son las formas de representar los
requisitos del sistema desde el enfoque

308
00:19:05,268 --> 00:19:06,768
centrado en uso usuario.

309
00:19:06,968 --> 00:19:10,633
¿Se termina con este enfoque diciendo que
habrá una tecla de cancelación?

310
00:19:10,773 --> 00:19:10,973
Sí.

311
00:19:11,814 --> 00:19:13,811
Se termina diciendo, pero en segundo
plano.

312
00:19:14,011 --> 00:19:18,955
en otro sitio, no con esa relevancia, es
decir, porque no se considera que sea un

313
00:19:18,955 --> 00:19:23,777
elemento de información adecuado para
intercambiar información con stakeholders

314
00:19:23,777 --> 00:19:28,598
de la importancia de los usuarios finales
que no son usuarios técnicos y que no

315
00:19:28,598 --> 00:19:30,391
consideran eso una prioridad.

316
00:19:33,918 --> 00:19:38,784
Después de esto, que es la introducción,
vamos a las historias de usuario.

317
00:19:40,326 --> 00:19:42,592
¿Qué son las historias de usuario?

318
00:19:45,803 --> 00:19:51,203
Es una técnica de captura de requisitos de
estas últimas que he mencionado, de las

319
00:19:51,203 --> 00:19:56,203
centradas en uso o usuario y por tanto
adecuadas para sistemas intensivos en

320
00:19:56,203 --> 00:20:01,603
interacción con los usuarios y no tanto
para software de infraestructura, software

321
00:20:01,603 --> 00:20:05,803
de sistemas, sistemas empotrados,
middleware, ese tipo de cosas.

322
00:20:07,403 --> 00:20:11,512
Es un mecanismo que genera descripciones
de requisitos basadas en objetivos de

323
00:20:11,512 --> 00:20:15,674
usuario y la interacción de los usuarios
con el sistema para el logro de dichos

324
00:20:15,674 --> 00:20:16,208
objetivos.

325
00:20:16,288 --> 00:20:20,384
Es decir, que lo que nos planteamos los
ingenieros encargados de desarrollar el

326
00:20:20,384 --> 00:20:20,805
proyecto

327
00:20:21,005 --> 00:20:26,010
Intentan averiguar por todos los medios,
con fuentes directas e indirectas, cuáles

328
00:20:26,010 --> 00:20:30,397
son las necesidades a cubrir por el
sistema, a ponerse en la piel de los

329
00:20:30,397 --> 00:20:34,784
usuarios y a describir todos esos
elementos con la granularidad adecuada

330
00:20:34,784 --> 00:20:39,542
para encontrar cosas de valor que puedo
priorizar desde lo más importante a lo

331
00:20:39,542 --> 00:20:40,593
menos importante.

332
00:20:40,793 --> 00:20:44,721
Al final son descripciones concisas por
escrito, en lenguaje natural, porque

333
00:20:44,721 --> 00:20:49,016
tienen que ser un elemento adecuado para
el intercambio de información con usuarios

334
00:20:49,016 --> 00:20:49,644
no técnicos.

335
00:20:49,861 --> 00:20:51,327
que sea ágil y eficaz.

336
00:20:55,088 --> 00:20:59,154
Y se trata de encontrar qué proporciona
valor para el usuario.

337
00:21:00,695 --> 00:21:05,592
El usuario stakeholder en general, porque
la existencia de un cajero automático y la

338
00:21:05,592 --> 00:21:09,782
posibilidad de poder pedir saldo y
movimientos en cualquier lugar aporta

339
00:21:09,782 --> 00:21:14,620
valor al usuario final por el control de
sus finanzas personales, pero también para

340
00:21:14,620 --> 00:21:16,155
el banco fideliza clientes

341
00:21:16,135 --> 00:21:20,248
y por disminución de los clientes que
tienen que acudir a la oficina para ese

342
00:21:20,248 --> 00:21:23,766
tipo de operaciones a lo mejor lo puede
hacer con menos plantilla.

343
00:21:23,966 --> 00:21:28,287
Es decir que los distintos requisitos
caracterizados de esta manera aportan

344
00:21:28,287 --> 00:21:33,018
valor a los stakeholders en general y no
solo a los usuarios directos del sistema.

345
00:21:33,218 --> 00:21:37,900
Aquí por tanto de lo que se trata es de
enfatizar el cumplimiento de objetivos y

346
00:21:37,900 --> 00:21:40,449
el valor que proporciona a sus
stakeholders.

347
00:21:40,649 --> 00:21:43,715
Es una técnica muy vinculada a procesos
ágiles.

348
00:21:44,165 --> 00:21:49,631
y a modelos de procesos de desarrollo de
software de tipo iterativo y ya veréis que

349
00:21:49,631 --> 00:21:54,765
encaja muy bien con la idea de los ítems
del Product Backlog del Scrum como ya

350
00:21:54,765 --> 00:21:57,498
hemos visto en otras sesiones anteriores.

351
00:21:59,305 --> 00:22:02,371
El término User Story fue acuñado por Kent
Beck

352
00:22:03,571 --> 00:22:08,607
que es el autor de otro de los modelos de
procesos ágiles muy conocidos, que aquí no

353
00:22:08,607 --> 00:22:11,399
hemos mencionado mucho, es Extreme
Programming.

354
00:22:11,599 --> 00:22:16,669
Lo menciona en su libro de 1999 este
término como historias de usuarios o user

355
00:22:16,669 --> 00:22:17,065
story.

356
00:22:17,085 --> 00:22:20,018
¿Qué formato tienen las historias de
usuario?

357
00:22:20,269 --> 00:22:23,252
Pues son frasecitas muy sencillas que
puede entender cualquiera.

358
00:22:23,272 --> 00:22:24,472
Tienen esta pinta.

359
00:22:25,134 --> 00:22:30,000
Esta plantilla es una de los formatos de
plantilla de historia de usuario.

360
00:22:32,461 --> 00:22:32,927
Yo como

361
00:22:33,558 --> 00:22:36,691
rol, quiero un objetivo, de forma que una
razón.

362
00:22:42,189 --> 00:22:47,031
Hay algunas otras estructuras para
representar historias de usuario, pero se

363
00:22:47,031 --> 00:22:47,936
parecen mucho.

364
00:22:47,996 --> 00:22:49,929
Por ejemplo, aquí tengo otra.

365
00:22:50,419 --> 00:22:55,019
Yo como tipo de usuario, por ejemplo,
cliente de cuenta corriente, por

366
00:22:55,019 --> 00:22:59,819
distinguirlo de un cliente de depósito,
por distinguirlo de un cliente de

367
00:23:02,735 --> 00:23:07,782
Cartilla de ahorro, por distinguirlo, a lo
mejor puedo dar una categoría, un tipo.

368
00:23:07,982 --> 00:23:13,048
Quiero, y este es más procedimental,
realizar determinada tarea con objeto de

369
00:23:13,048 --> 00:23:15,048
alcanzar determinado objetivo.

370
00:23:15,613 --> 00:23:19,479
Son semánticamente equivalentes, aunque
varían un poquitín.

371
00:23:20,840 --> 00:23:25,995
Os voy a dar una tercera opción con una
estructura distinta, pero ya la pinto en

372
00:23:25,995 --> 00:23:27,105
forma de tarjeta.

373
00:23:27,305 --> 00:23:32,305
Porque es muy común representar las
historias de usuario o en una tarjeta de

374
00:23:32,305 --> 00:23:35,971
papel o en un post-it que se puede pegar
en una pizarra.

375
00:23:36,960 --> 00:23:40,105
Bueno, esto es una cosa que a los
americanos les encanta.

376
00:23:40,305 --> 00:23:45,705
O sea, esto de las tarjetitas, rellenar
tarjetitas, bueno, desde los años 70 o así

377
00:23:45,705 --> 00:23:50,705
es una cosa que se hace con un montón de
técnicas de trabajo estructurado de

378
00:23:50,705 --> 00:23:51,838
trabajo en grupo.

379
00:23:54,693 --> 00:23:59,436
Aquí hemos tardado muchas décadas en
pensar que eso es algo más que hacer el

380
00:23:59,436 --> 00:24:04,432
indio y que es un poco procrastinar el
trabajo real, pero que no llegue un jefe,

381
00:24:04,432 --> 00:24:09,302
asome por la puerta y diga, pero vosotros
cuándo os vais a poner a escribir el

382
00:24:09,302 --> 00:24:13,097
código, macho, mientras tú pegas post-it
por aquí y por allá.

383
00:24:13,117 --> 00:24:16,917
Pero bien pensado es una buena idea, ya
veréis cómo lo es.

384
00:24:17,542 --> 00:24:22,365
Bueno, aquí pone que yo como persona,
persona en inglés, persona en inglés

385
00:24:22,365 --> 00:24:26,330
significa rol social o personaje
reinterpretado por un actor.

386
00:24:26,530 --> 00:24:28,292
Es lo que significa persona en inglés.

387
00:24:28,492 --> 00:24:33,758
Yo como persona me gustaría que el sistema
tuviera determinada característica de

388
00:24:33,758 --> 00:24:37,092
forma que yo obtenga determinado beneficio
o valor.

389
00:24:37,321 --> 00:24:42,321
Bueno, una tercera estructura posible de
historia de usuario que viene a ser

390
00:24:42,321 --> 00:24:47,321
semánticamente equivalente, pero bueno,
para que dispongáis de un abanico de

391
00:24:47,321 --> 00:24:47,921
opciones.

392
00:24:48,625 --> 00:24:52,158
Vamos a poner algunos ejemplos de historia
de usuario.

393
00:24:58,496 --> 00:25:03,696
Yo como usuario registrado en el sistema
me gustaría hacer login para acceder a

394
00:25:03,696 --> 00:25:05,762
contenido reservado a abonados.

395
00:25:08,428 --> 00:25:13,694
Podría ser un requisito de alguien que
quiera ver la tele en directo a través de

396
00:25:13,694 --> 00:25:17,161
la aplicación Go de Movistar Televisión,
por ejemplo.

397
00:25:18,578 --> 00:25:24,044
Pues yo como usuario abonado y registrado
de Telefónica me gustaría poder acceder a

398
00:25:24,044 --> 00:25:28,978
esta aplicación web para acceder al
contenido reservado solo para abonados.

399
00:25:29,195 --> 00:25:30,928
Bueno, pues es una opción.

400
00:25:32,060 --> 00:25:32,926
Otro ejemplo.

401
00:25:35,045 --> 00:25:39,845
Yo como usuario típico quiero leer
críticas objetivas de los restaurantes

402
00:25:39,845 --> 00:25:44,778
próximos a una localización con objeto de
decidir a dónde puedo ir a cenar.

403
00:25:47,384 --> 00:25:51,579
Bueno, pues es una forma sencilla en
lenguaje natural de representar los

404
00:25:51,579 --> 00:25:56,307
requisitos sobre un sistema, pero que eso
sí, pone en valor exactamente lo que el

405
00:25:56,307 --> 00:25:58,198
cliente espera de la aplicación.

406
00:25:58,218 --> 00:26:02,344
¿Qué es lo que quiere un cliente de
TripAdvisor cuando busca un restaurante?

407
00:26:02,544 --> 00:26:02,877
Esto.

408
00:26:03,805 --> 00:26:06,409
Y la aplicación tendrá éxito en la medida
en que lo cubra.

409
00:26:06,609 --> 00:26:11,233
Y por otra parte, está escrito en un
lenguaje tan sencillo que cualquiera lo

410
00:26:11,233 --> 00:26:13,638
puede comprender y discutir sobre ello.

411
00:26:13,838 --> 00:26:14,704
Más ejemplos.

412
00:26:17,253 --> 00:26:22,464
Como usuario de la wiki quiero poder subir
un fichero a la wiki para compartirlo con

413
00:26:22,464 --> 00:26:23,218
mis colegas.

414
00:26:24,021 --> 00:26:24,361
Bueno, pues otro.

415
00:26:24,381 --> 00:26:27,228
Y otro que está aquí es de estudiantes,
porque yo he usado esta transparencia en

416
00:26:27,228 --> 00:26:27,445
clase.

417
00:26:27,465 --> 00:26:30,748
Y digo, les voy a poner uno de los que a
ellos les hacen mastilín.

418
00:26:30,948 --> 00:26:36,135
Y no debo haberme acordado de poner uno de
banca aquí para quedar mejor con vosotros.

419
00:26:36,335 --> 00:26:41,108
Yo como estudiante quiero poder consultar
mis notas online para no tener que esperar

420
00:26:41,108 --> 00:26:44,272
hasta una comunicación formal para saber
si he aprobado.

421
00:26:44,472 --> 00:26:48,978
A los estudiantes de la universidad
últimamente se les pone en una aplicación

422
00:26:48,978 --> 00:26:53,485
que se llama Politécnica Virtual todas sus
notas y además lo reciben por SMS.

423
00:26:53,685 --> 00:26:58,136
Porque no queremos que los chicos dejen
sus intensas actividades de ocio para

424
00:26:58,136 --> 00:27:00,714
venir a averiguar sus notas a la
universidad.

425
00:27:00,734 --> 00:27:04,267
Es una molestia importante que no queremos
que sufran.

426
00:27:07,303 --> 00:27:10,147
Entonces, bueno, pues como estudiante a
día de hoy cualquiera tiene este

427
00:27:10,147 --> 00:27:10,548
requisito.

428
00:27:10,748 --> 00:27:12,414
Si no le llega por SMS...

429
00:27:12,805 --> 00:27:15,338
Pues, ¿qué mierda universidad es esta?

430
00:27:17,270 --> 00:27:20,394
Bien, pues esta es la pinta que tienen las
historias de usuario.

431
00:27:20,434 --> 00:27:21,834
Es sencillo, ¿verdad?

432
00:27:22,896 --> 00:27:25,429
La verdad es que no tienen mucha miga.

433
00:27:28,002 --> 00:27:33,002
Una cosa que es importante destacar aquí
es que realmente estas historias de

434
00:27:33,002 --> 00:27:35,402
usuario no especifican un requisito.

435
00:27:38,590 --> 00:27:42,723
Se dice que son placeholders o
contenedores para especificar un

436
00:27:42,723 --> 00:27:43,390
requisito.

437
00:27:43,760 --> 00:27:48,960
De forma que son una especie de título
identificativo que permite que todos los

438
00:27:48,960 --> 00:27:54,160
stakeholders, usuarios y desarrolladores
sepan que están encargados de hacer un

439
00:27:54,160 --> 00:27:58,293
sistema que permita que el estudiante
consulte sus notas online

440
00:27:59,482 --> 00:28:03,763
sin necesidad de esperar a una
comunicación formal para saber si ha

441
00:28:03,763 --> 00:28:05,190
aprobado o suspendido.

442
00:28:05,390 --> 00:28:10,190
Y que detrás de esa etiqueta puede haber
documentos de cientos de páginas

443
00:28:10,190 --> 00:28:14,923
detallando acuerdos, consensos, modelos,
especificaciones, mecanismos de

444
00:28:14,923 --> 00:28:20,456
comprobación de conformidad o validación,
reglas de satisfacción, ese tipo de cosas.

445
00:28:25,656 --> 00:28:26,456
De forma que

446
00:28:26,853 --> 00:28:32,119
Eso solo es una etiqueta o placeholder o
contenedor para el consenso en relación

447
00:28:32,119 --> 00:28:33,986
con un requisito de usuario.

448
00:28:34,702 --> 00:28:36,504
En primer lugar, ahí no está todo.

449
00:28:36,704 --> 00:28:42,170
Eso es solo la etiqueta identificativa de
un requisito escrito en términos de valor

450
00:28:42,170 --> 00:28:43,237
para un usuario.

451
00:28:43,952 --> 00:28:49,285
Y por otra parte, que justo ese concepto
de placeholder para la especificación de

452
00:28:49,285 --> 00:28:54,818
requisitos es la definición de un item de
un product backlog en un modelo de proceso

453
00:28:54,818 --> 00:28:55,551
tipo Scrum.

454
00:28:57,042 --> 00:29:01,688
Por esa razón casa estupendamente esta
metodología de las historias de usuario

455
00:29:01,688 --> 00:29:06,275
con la idea de Scrum y básicamente lo que
se propone y es lo más frecuente de

456
00:29:06,275 --> 00:29:10,680
utilizar es que los ítems en un Product
Backlog sean historias de usuario,

457
00:29:10,680 --> 00:29:15,568
historias de usuario como esta, que por sí
solas no contienen toda la información,

458
00:29:15,568 --> 00:29:19,914
repito, sino que son placeholders para
toda la información que contienen.

459
00:29:21,479 --> 00:29:24,812
En ese sentido de que estos títulos no lo
son todo,

460
00:29:25,072 --> 00:29:30,117
Normalmente en la literatura se considera
tres grandes componentes en la descripción

461
00:29:30,117 --> 00:29:31,759
de una historia de usuario.

462
00:29:31,959 --> 00:29:35,319
Lo que llaman tarjeta o card, que viene a
ser esto que hemos visto en la

463
00:29:35,319 --> 00:29:37,023
transparencia anterior, un titulito.

464
00:29:37,043 --> 00:29:41,376
Yo como usuario me gustaría, como objeto
de alcanzar tal objetivo.

465
00:29:42,489 --> 00:29:46,328
Es una descripción escrita de la historia
de usuario, efectos de descripción de

466
00:29:46,328 --> 00:29:49,676
requisitos, planificación y como
referencia para discusión posterior.

467
00:29:49,876 --> 00:29:54,542
Se escribe en una tarjeta o más
frecuentemente en un post-it y se suele

468
00:29:54,542 --> 00:29:55,809
pegar en un tablón.

469
00:29:56,273 --> 00:29:58,073
Pero eso es solo un título.

470
00:29:58,878 --> 00:30:01,164
Lo importante es lo que viene a
continuación.

471
00:30:01,364 --> 00:30:02,245
La conversación.

472
00:30:02,266 --> 00:30:07,199
Se entiende por conversación toda la
discusión entre todos los stakeholders

473
00:30:07,199 --> 00:30:12,399
posterior a la puesta en común del título
en relación con la especificación del

474
00:30:12,399 --> 00:30:13,066
contenido.

475
00:30:17,671 --> 00:30:22,804
Todas las aclaraciones que los clientes
hicieron, todas las propuestas que los

476
00:30:22,804 --> 00:30:27,204
desarrolladores hicieron, los
refinamientos posteriores, lo podemos

477
00:30:27,204 --> 00:30:32,204
considerar como un blog donde se va
registrando todas las conversaciones que

478
00:30:32,204 --> 00:30:37,671
los stakeholders mantienen en relación con
la historia de usuario y que representan

479
00:30:37,671 --> 00:30:41,671
de verdad la especificación del requisito
funcional asociado.

480
00:30:43,810 --> 00:30:48,743
Creo que lo menciono más adelante, pero
desde un punto de vista filosófico,

481
00:30:48,743 --> 00:30:53,610
también la conversación tiene la
consideración de puntos de consenso entre

482
00:30:53,610 --> 00:30:58,343
stakeholders, porque aquí Scrum, os
recuerdo, es un equipo de desarrollo

483
00:30:58,343 --> 00:31:03,143
multidisciplinar con personas de alta
cualificación y alta motivación que

484
00:31:03,143 --> 00:31:08,676
trabajan de forma autónoma y con capacidad
de decisión y criterio para conseguir que

485
00:31:08,676 --> 00:31:11,676
la aplicación cumpla sus objetivos de
negocio.

486
00:31:12,329 --> 00:31:16,995
Entonces, en ese contexto no cuadran bien
las coerciones contractuales.

487
00:31:18,478 --> 00:31:22,741
Escribí el 15 de marzo en la
especificación del sistema que tiene

488
00:31:22,741 --> 00:31:27,271
carácter contractual que el sistema
proporcionaría tal funcionalidad.

489
00:31:27,471 --> 00:31:29,274
No es ese carácter el que tiene aquí.

490
00:31:29,474 --> 00:31:34,000
No son especificaciones de carácter
contractual entre un cliente que paga

491
00:31:34,199 --> 00:31:39,399
y un equipo o empresa que desarrolla lo
que le han encargado, sino que juega el

492
00:31:39,399 --> 00:31:43,532
rol de registro de conversaciones como
instrumento de consenso,

493
00:31:44,223 --> 00:31:48,741
De forma que se alcanza un acuerdo común
sobre lo que el sistema tiene que

494
00:31:48,741 --> 00:31:53,630
proporcionar y todos somos un equipo y
todos estamos involucrados y nadie impone

495
00:31:53,630 --> 00:31:58,024
al otro como si de una cláusula
contractual se tratara ese requisito del

496
00:31:58,024 --> 00:31:58,520
sistema.

497
00:31:58,720 --> 00:32:02,281
Y finalmente hay una tercera parte en las
historias de usuario que son la

498
00:32:02,281 --> 00:32:02,925
confirmación.

499
00:32:03,125 --> 00:32:06,949
Es la sección donde se describen las
normas de satisfacción.

500
00:32:07,149 --> 00:32:10,635
Como después de implementada esa historia
de usuario, yo voy a

501
00:32:10,835 --> 00:32:15,768
comprobar que está correctamente
implementada y que efectivamente satisface

502
00:32:15,768 --> 00:32:17,568
las necesidades de usuario.

503
00:32:18,569 --> 00:32:23,433
Puesto todo en un ejemplo junto que va en
una tarjeta, aunque no se suele poner todo

504
00:32:23,433 --> 00:32:27,125
en una tarjeta, aquí tenemos una especie
de User Story avanzada.

505
00:32:27,325 --> 00:32:30,591
Avanzada e inútil, no me gusta este
procedimiento.

506
00:32:32,754 --> 00:32:34,361
Aquí se ve mucha información.

507
00:32:34,561 --> 00:32:39,627
La historia de usuario tiene una tarjeta
aquí donde tiene la típica expresión

508
00:32:39,627 --> 00:32:45,094
textual de As a registered user I want to
login so I can access subscriber content.

509
00:32:45,680 --> 00:32:47,543
Es uno de los ejemplos que he puesto
antes.

510
00:32:47,743 --> 00:32:51,114
Pero además se la numera, arriba a la
izquierda hay un número, esa es la

511
00:32:51,114 --> 00:32:52,492
historia de usuario número 1.

512
00:32:52,692 --> 00:32:54,695
Tiene un nombre abreviado, user login.

513
00:32:54,895 --> 00:32:59,697
Tiene a la derecha una asignación de valor
en puntos de función según la serie de

514
00:32:59,697 --> 00:33:00,298
Fibonacci.

515
00:33:00,498 --> 00:33:05,031
Luego tiene medio como una especie de
borrador o diseño preliminar de

516
00:33:05,031 --> 00:33:07,164
pantallazo, de cómo es el login.

517
00:33:07,746 --> 00:33:12,556
Y se determina que debe tener un tick para
decir cuándo quieres que te recuerde para

518
00:33:12,556 --> 00:33:17,252
la próxima vez, de forma que se generará
una cookie que el navegador guardará para

519
00:33:17,252 --> 00:33:20,440
no volverte a pedir autenticación en
futuras conexiones.

520
00:33:20,640 --> 00:33:25,245
Tiene una especificación de que el
username será tu dirección de email.

521
00:33:25,445 --> 00:33:28,045
Tiene una nota a la derecha diciendo...

522
00:33:30,451 --> 00:33:35,517
qué servidor de autenticación se va a
comprobar la password, que tiene ahí un

523
00:33:35,517 --> 00:33:36,984
montón de información.

524
00:33:37,582 --> 00:33:42,260
Se trata de una historia de usuario que ya
refleja el resultado de muchas

525
00:33:42,260 --> 00:33:43,950
conversaciones y acuerdos.

526
00:33:44,153 --> 00:33:48,353
Y en el reverso, los criterios de
confirmación, los criterios de

527
00:33:48,353 --> 00:33:49,219
satisfacción.

528
00:33:49,421 --> 00:33:54,287
En cuanto a éxito, la idea de que todo
usuario válido se registrará y será

529
00:33:54,287 --> 00:33:57,487
dirigido a la página adecuada una vez
registrado,

530
00:33:58,244 --> 00:34:02,926
Y que en caso de que esté el TIC en el
cuadro de Remember Me, pues se almacenará

531
00:34:02,926 --> 00:34:07,787
una cookie para que la próxima vez no se
tenga que repetir el proceso y que en caso

532
00:34:07,787 --> 00:34:08,558
contrario no.

533
00:34:08,758 --> 00:34:11,925
En cuanto a fallos, se hace una
descripción de los posibles mensajes de

534
00:34:11,925 --> 00:34:12,242
fallos.

535
00:34:12,262 --> 00:34:16,384
O bien porque la dirección de correo
electrónico utilizado no tiene el formato

536
00:34:16,384 --> 00:34:19,972
adecuado, o porque no se reconoce el
nombre, o porque la password es

537
00:34:19,972 --> 00:34:24,202
incorrecta, o porque el servicio está
temporalmente no disponible, o bien porque

538
00:34:24,202 --> 00:34:25,380
la cuenta ha expirado.

539
00:34:25,580 --> 00:34:28,233
Entonces estos son los criterios de
satisfacción.

540
00:34:28,433 --> 00:34:32,874
Yo no creo que sea útil poner todo en una
tarjeta física de esta manera.

541
00:34:33,074 --> 00:34:34,940
Lo habitual es que el título

542
00:34:36,550 --> 00:34:42,150
de la historia de usuario se escribe en un
post-it y esté en el tablón de trabajo del

543
00:34:42,150 --> 00:34:46,750
equipo de desarrollo y que haya
herramientas de soporte que guarden el

544
00:34:46,750 --> 00:34:51,550
registro de las conversaciones y de los
criterios de satisfacción para no

545
00:34:51,550 --> 00:34:56,750
concentrar la información en una pieza de
papel tan pequeña que realmente haría

546
00:34:56,750 --> 00:35:00,283
ilegible o poco sencillo concentrar tanta
información.

547
00:35:02,234 --> 00:35:07,017
Así que yo entiendo que, aunque a modo de
ejemplo está bien, no creo que sea lo más

548
00:35:07,017 --> 00:35:07,543
práctico.

549
00:35:07,563 --> 00:35:12,415
A lo mejor es un post-it con el título y
conversación y confirmación estén en

550
00:35:12,415 --> 00:35:15,034
alguna herramienta de soporte al proceso.

551
00:35:19,485 --> 00:35:23,418
Las historias de usuario pueden tener
distinta granularidad.

552
00:35:24,745 --> 00:35:29,678
Es decir, que la necesidad de los
stakeholders puede plantearse con niveles

553
00:35:29,678 --> 00:35:32,478
de granularidad muy grandes y muy
pequeños.

554
00:35:33,961 --> 00:35:36,146
Desde, por ejemplo, cajero automático.

555
00:35:36,346 --> 00:35:37,812
¿Qué propósito cumple?

556
00:35:38,149 --> 00:35:41,349
Obtener beneficios por intermediación
financiera.

557
00:35:42,837 --> 00:35:43,559
Qué grueso, ¿no?

558
00:35:43,679 --> 00:35:47,546
Eso parece realmente la misión de negocio
del banco en su conjunto.

559
00:35:47,746 --> 00:35:51,760
O alguien puede decir, yo quiero que los
movimientos me los presenten línea a línea

560
00:35:51,760 --> 00:35:53,033
con la fecha a la derecha.

561
00:35:53,173 --> 00:35:55,937
Vaya, pues eso parece como de granularidad
muy fina, ¿no?

562
00:35:56,137 --> 00:36:01,063
Probablemente, entre blanco y negro, pues
habrá algún gris que sea adecuado.

563
00:36:01,083 --> 00:36:05,762
De todos modos, en esta metodología de
historias de usuario, suele darse nombres,

564
00:36:05,762 --> 00:36:09,915
digamos, a historias de usuario con mayor
o menor nivel de granularidad.

565
00:36:10,115 --> 00:36:15,581
A las historias de usuario que tienen un
nivel de granularidad grueso, se les suele

566
00:36:15,581 --> 00:36:16,981
llamar épics, ¿vale?,

567
00:36:18,155 --> 00:36:19,888
como las historias épicas.

568
00:36:20,478 --> 00:36:24,345
Epics aquí es un nombre, en castellano
épico solo es un adjetivo, tiene que

569
00:36:24,345 --> 00:36:27,848
acompañar a otra historia, pero bueno, en
inglés se usa como nombre.

570
00:36:28,048 --> 00:36:33,314
Entonces una epic es una gran historia de
usuario que en general, y en eso se la

571
00:36:33,314 --> 00:36:38,448
distingue, abarcará meses de desarrollo
cubriendo no solo muchos sprints, sino

572
00:36:38,448 --> 00:36:41,381
probablemente más de una release de
producto.

573
00:36:42,573 --> 00:36:46,994
Está bien empezar con EPICS, pueden ser
adecuadas, pero al final el equipo de

574
00:36:46,994 --> 00:36:51,183
trabajo tiene que refinarlas o
descomponerlas en características de menor

575
00:36:51,183 --> 00:36:52,464
nivel de granularidad.

576
00:36:52,664 --> 00:36:56,140
Muchas veces se encuentra un nivel
intermedio de granularidad que se llaman

577
00:36:56,140 --> 00:36:58,912
features, que son historias de usuario de
tamaño intermedio.

578
00:36:59,112 --> 00:37:04,045
Algo que en un momento dado entran enteras
en una release de producto, pero

579
00:37:04,045 --> 00:37:06,178
difícilmente en un único sprint.

580
00:37:06,738 --> 00:37:10,426
Y finalmente están las stories, las
stories básicas, que son historias de un

581
00:37:10,426 --> 00:37:14,263
tamaño adecuado para implementar en un
sprint, teniendo en cuenta que un sprint

582
00:37:14,263 --> 00:37:16,919
muchas veces implementa más de una
historia de usuario.

583
00:37:17,119 --> 00:37:21,027
Así que esas son las historias de usuario
propiamente dichas, las stories.

584
00:37:21,227 --> 00:37:25,546
Lo que pasa es que muchas veces el proceso
de elaboración comienza con epics, se

585
00:37:25,546 --> 00:37:29,538
descomponen en fichas y las fichas se
descomponen en historias de usuario.

586
00:37:29,738 --> 00:37:34,605
Luego una cosa que también aparece muchas
veces es la idea de theme, que solo es un

587
00:37:34,605 --> 00:37:38,701
contenedor, un nombre, similar a los
paquetes de Java, si alguien está

588
00:37:38,701 --> 00:37:43,332
acostumbrado a... Lo vamos a ver en un
ejemplo más adelante lo que es un theme.

589
00:37:46,377 --> 00:37:51,121
Vamos a poner un ejemplo de una historia
de usuario de granularidad demasiado

590
00:37:51,121 --> 00:37:53,744
gruesa para implementar en un único
sprint.

591
00:37:54,486 --> 00:37:58,707
Bueno, alguien está desarrollando una
aplicación que hace backup automático de

592
00:37:58,707 --> 00:37:59,036
un PC.

593
00:37:59,236 --> 00:38:03,764
Bueno, pues eso puede ser una cosa
tremendamente sencilla como una copia

594
00:38:03,764 --> 00:38:08,674
directa y literal de todo el disco duro a
un disco externo, puede ser una cosa

595
00:38:08,674 --> 00:38:13,202
sofisticada como la Time Machine de Apple
o puede ser una herramienta de

596
00:38:13,202 --> 00:38:18,304
administrador de sistema que hace backup
incremental y que solo guarda deltas, en

597
00:38:18,304 --> 00:38:18,559
fin.

598
00:38:18,760 --> 00:38:21,463
y que admite muchos elementos de
configuración.

599
00:38:21,663 --> 00:38:26,601
Entonces, pues la historia de usuario como
usuario del sistema, me gustaría poder

600
00:38:26,601 --> 00:38:31,724
hacer backup del disco duro completo, pues
tiene una granularidad de epic, es decir,

601
00:38:31,724 --> 00:38:34,255
difícilmente cabe eso en un único sprint.

602
00:38:34,455 --> 00:38:38,684
Y hay muchas historias de usuario en las
que puede refinarse, ahí tengo un par de

603
00:38:38,684 --> 00:38:39,160
ejemplos.

604
00:38:39,340 --> 00:38:44,006
La primera, por ejemplo, como
administrador de sistema o power user, me

605
00:38:44,006 --> 00:38:45,340
gustaría tener un...

606
00:38:48,241 --> 00:38:52,907
Modo extendido de backup en el que
determino que se haga backup solo de

607
00:38:52,907 --> 00:38:57,374
ficheros de determinado tamaño o con
determinada fecha de creación o

608
00:38:57,374 --> 00:38:58,241
modificación.

609
00:38:58,523 --> 00:39:03,189
Es una característica que el usuario
ordinario no tendrá, no requerirá.

610
00:39:04,036 --> 00:39:07,888
no le hace falta, pero que un
administrador de sistema sí, puede tener

611
00:39:07,888 --> 00:39:12,187
la necesidad de decidir, voy a hacer
backup de los ficheros más grandes o solo

612
00:39:12,187 --> 00:39:16,653
de los ficheros creados en el último día o
de los ficheros modificados en las dos

613
00:39:16,653 --> 00:39:17,434
últimas horas.

614
00:39:17,676 --> 00:39:21,341
Pues eso ya sí es de granularidad adecuada
para un sprint.

615
00:39:21,541 --> 00:39:26,536
O otra puede ser, como usuario me gustaría
poder indicar en la configuración de

616
00:39:26,536 --> 00:39:31,403
backup algunas carpetas que por contener
información que yo considero de poca

617
00:39:31,403 --> 00:39:34,413
importancia, no es necesario que se haga
backup.

618
00:39:34,613 --> 00:39:39,238
Normalmente porque ahí tendré cosas que no
quiero que vean nadie, probablemente.

619
00:39:39,258 --> 00:39:43,376
Bueno, pues ese es un ejemplo como a
partir de una epic de granularidad gruesa

620
00:39:43,376 --> 00:39:47,066
puede derivarse un conjunto de user
stories que tienen la granularidad

621
00:39:47,066 --> 00:39:47,548
adecuada.

622
00:39:47,748 --> 00:39:50,372
Granularidad adecuada es que caben en un
sprint.

623
00:39:50,572 --> 00:39:52,972
Es el criterio básico y fundamental.

624
00:39:55,117 --> 00:39:59,440
Bueno, y esos son los elementos, los de
abajo, las historias de usuario, que se

625
00:39:59,440 --> 00:40:01,768
introducen como item en un product
backlog.

626
00:40:01,968 --> 00:40:06,968
En el product.log se introducen estos
ítems que son historias de usuario, se

627
00:40:06,968 --> 00:40:11,568
meten las etiquetas, pero ojo que cada
etiqueta luego da lugar a mucha

628
00:40:11,568 --> 00:40:17,034
información de conversaciones y reglas de
confirmación o satisfacción y comienza el

629
00:40:17,034 --> 00:40:18,368
proceso de grooming,

630
00:40:18,910 --> 00:40:24,110
Epic demasiado gruesa se descompone en
stories donde dos stories se refunden en

631
00:40:24,110 --> 00:40:29,443
una de mayor nivel porque se observa que
tienen un nivel de granularidad muy fino

632
00:40:29,443 --> 00:40:34,443
donde se evalúa y se reevalúa una
estimación de esfuerzo o complejidad donde

633
00:40:34,443 --> 00:40:39,776
se considera y reconsidera el valor del
negocio y por tanto el nivel de prioridad

634
00:40:39,776 --> 00:40:45,243
en el stack que tiene cada característica
y esto es donde engancha con Scrum porque

635
00:40:45,243 --> 00:40:47,776
se presta muy bien a esta metodología.

636
00:40:51,530 --> 00:40:56,796
Si bien es común que en los ítems del
Product Backlog haya historias de usuario,

637
00:40:56,796 --> 00:40:58,930
también puede haber otras cosas.

638
00:41:05,266 --> 00:41:10,199
Peticiones de cambio, defectos encontrados
por los usuarios en el sistema o

639
00:41:10,199 --> 00:41:15,399
actividades de adquisición de conocimiento
o de resolución de riesgos técnicos.

640
00:41:16,015 --> 00:41:20,881
Es decir, que aparte de historias de
usuario con requisitos funcionales de

641
00:41:20,881 --> 00:41:26,348
usuario final, en un product backlog puede
haber, aquí Iván nos contaba el otro día

642
00:41:26,348 --> 00:41:31,615
un mecanismo combinado con Kanban donde
esas otras cosas iban por otra vía, pero

643
00:41:31,615 --> 00:41:34,348
puede haber también peticiones de cambio,

644
00:41:36,502 --> 00:41:40,737
defectos del sistema en producción o
actividades de adquisición de conocimiento

645
00:41:40,737 --> 00:41:42,529
y resolución de riesgos técnicos.

646
00:41:42,549 --> 00:41:47,444
Es decir, no tienes ni idea si con tal
tecnología podrás lograr implementar tal

647
00:41:47,444 --> 00:41:52,402
cosa o no sabes si es mejor usar una base
de datos SQL o no SQL y te inventas un

648
00:41:52,402 --> 00:41:56,984
item de product backlog que prototipa
ambas cosas para hacer un proceso de

649
00:41:56,984 --> 00:42:01,377
evaluación y selección de la más adecuada
en función de algún criterio.

650
00:42:01,578 --> 00:42:04,805
Y a lo que iba entonces, y los requisitos
no funcionales.

651
00:42:04,826 --> 00:42:07,352
¿Qué hacemos con los requisitos no
funcionales?

652
00:42:07,552 --> 00:42:11,357
Porque las historias de usuarios son
requisitos funcionales.

653
00:42:15,530 --> 00:42:19,596
Bueno, en principio también podrían
ponerse como user stories.

654
00:42:19,860 --> 00:42:20,793
Por ejemplo...

655
00:42:21,018 --> 00:42:25,503
Como usuario quiero que el sistema soporte
los navegadores Firefox y Chrome de forma

656
00:42:25,503 --> 00:42:28,530
que funcione para la mayoría de los
ordenadores europeos.

657
00:42:28,730 --> 00:42:30,713
Es un requisito no funcional de
portabilidad.

658
00:42:30,853 --> 00:42:33,898
En sí mismo no presenta valor de usuario
final.

659
00:42:34,098 --> 00:42:39,431
Si ese sistema es de ver imagenio a través
de una aplicación web, el valor es ver

660
00:42:39,431 --> 00:42:42,031
imagenio a través de la aplicación web.

661
00:42:42,911 --> 00:42:44,173
Si es Firefox o Chrome,

662
00:42:44,153 --> 00:42:49,419
O si el sistema debe funcionar tanto para
Firefox o Chrome, realmente a mí me da

663
00:42:49,419 --> 00:42:49,819
igual.

664
00:42:49,882 --> 00:42:53,813
Es un requisito de portabilidad que no
tiene un valor nítido para el usuario

665
00:42:53,813 --> 00:42:54,128
final.

666
00:42:54,328 --> 00:42:56,572
¿Lo puedo poner como historia de usuario?

667
00:42:56,772 --> 00:42:56,972
Sí.

668
00:42:58,094 --> 00:43:02,426
Sin embargo, la mayoría de los autores
recomiendan otra alternativa y es

669
00:43:02,426 --> 00:43:04,624
incluirlo en la definición de hecho.

670
00:43:04,824 --> 00:43:10,217
Recordad que el criterio de finalización
de un sprint o de una historia de usuario

671
00:43:10,217 --> 00:43:11,882
implementada en un sprint

672
00:43:12,082 --> 00:43:17,415
era que cumpliera con lo que el equipo
había consensuado que era la definición de

673
00:43:17,415 --> 00:43:22,348
hecho, con características de tipo
compila, ha pasado pruebas unitarias, ha

674
00:43:22,348 --> 00:43:27,415
pasado pruebas de integración, se ha
puesto en beta en determinada plataforma

675
00:43:27,415 --> 00:43:32,348
del cliente final, añadir ahí el
cumplimiento de requisitos no funcionales.

676
00:43:33,596 --> 00:43:38,244
Por ejemplo, forma parte de la definición
de hecho de esta aplicación web que se ha

677
00:43:38,244 --> 00:43:40,569
comprobado que funciona tanto para Chrome

678
00:43:40,769 --> 00:43:42,035
¿Cómo para Firefox?

679
00:43:44,575 --> 00:43:45,536
Bueno, es una alternativa.

680
00:43:45,777 --> 00:43:50,977
Tenemos las dos, poner los requisitos no
funcionales como historia de usuario o

681
00:43:50,977 --> 00:43:54,377
bien incluirlo en la definición de hecho
del equipo.

682
00:43:55,351 --> 00:43:57,351
Bueno, eso está comentado ahí.

683
00:43:59,017 --> 00:44:03,806
Bueno, criterios de elaboración de un buen
conjunto de historias de usuario.

684
00:44:04,006 --> 00:44:08,393
¿Cuándo las historias de usuarios que me
he sacado de la manga son buenas,

685
00:44:08,393 --> 00:44:09,475
regulares o malas?

686
00:44:09,675 --> 00:44:13,900
Bueno, pues algunos autores, usando
también una cosa que a los americanos les

687
00:44:13,900 --> 00:44:18,181
gusta mucho, es poner una especie de
metáfora como acrónimo para que nos sirva

688
00:44:18,181 --> 00:44:22,573
de regla mnemotécnica, es los criterios
INVEST, que son seis criterios que dicen

689
00:44:22,573 --> 00:44:26,132
que tienen que cumplir un buen conjunto de
historias de usuarios.

690
00:44:26,332 --> 00:44:30,783
Entonces, INVEST es un acrónimo de
independent o independientes, que es que

691
00:44:30,783 --> 00:44:35,354
las historias de usuarios deben ser
independientes, totalmente independientes

692
00:44:35,354 --> 00:44:40,166
es imposible, pero que la conexión entre
dos historias de usuarios sea débil, que

693
00:44:40,166 --> 00:44:42,030
no estén fuertemente acopladas.

694
00:44:42,231 --> 00:44:46,289
Es un criterio de bajo acoplamiento muy
viejo en ingeniería del software, que

695
00:44:46,289 --> 00:44:47,037
tiene 40 años.

696
00:44:47,077 --> 00:44:51,088
El criterio de bajo acoplamiento entre
historias de usuarios, es decir, que más o

697
00:44:51,088 --> 00:44:52,844
menos sean unidades independientes.

698
00:44:53,044 --> 00:44:54,044
Por otra parte,

699
00:44:54,597 --> 00:44:59,997
La idea de que las historias de usuarios
son negociables, son conversaciones entre

700
00:44:59,997 --> 00:45:04,997
stakeholders, no una especificación
contractual que alguien impone porque es

701
00:45:04,997 --> 00:45:07,597
el que paga y los demás han de cumplir.

702
00:45:08,095 --> 00:45:13,244
Que no debe tener ese criterio, sino que
tiene que ser una oportunidad de discusión

703
00:45:13,244 --> 00:45:16,887
y consenso en un equipo uniforme que
persigue un fin común.

704
00:45:17,087 --> 00:45:18,731
Por otra parte, que tengan valor.

705
00:45:18,931 --> 00:45:23,864
es decir, deben tener valor para el
usuario final o stakeholder en general,

706
00:45:23,864 --> 00:45:29,131
describiendo características del sistema
que resuelven problemas que uno tiene y

707
00:45:29,131 --> 00:45:31,464
que merecen que uno pague por ello.

708
00:45:31,668 --> 00:45:37,001
Tienen que ser cuantificables, es decir,
deben contener suficientes detalles para

709
00:45:37,001 --> 00:45:41,134
establecer alguna métrica de esfuerzo o
coste en su desarrollo.

710
00:45:43,214 --> 00:45:47,594
deben ser relativamente pequeñas, es
decir, con un nivel de granularidad

711
00:45:47,594 --> 00:45:50,185
pequeño, de forma que quepan en un sprint.

712
00:45:50,205 --> 00:45:52,738
Se les llama muchas veces sprintables.

713
00:45:53,630 --> 00:45:58,356
Y debe ser comprobable, es decir, que
tiene que haber pruebas o criterios de

714
00:45:58,356 --> 00:46:03,397
satisfacción que permitan determinar si
finalmente conseguimos el objetivo cuando

715
00:46:03,397 --> 00:46:04,847
las hemos implementado.

716
00:46:05,047 --> 00:46:08,707
Así que cuando hacemos un juego de
historias de usuarios nos tenemos que

717
00:46:08,707 --> 00:46:09,120
plantear

718
00:46:09,320 --> 00:46:14,720
como una posibilidad, no será la única, sí
cumple con los criterios de Invest, ¿de

719
00:46:14,720 --> 00:46:15,253
acuerdo?

720
00:46:16,031 --> 00:46:20,127
Y en cuanto a cómo proceder para
elaborarla, bueno, venga, vale, ya tengo

721
00:46:20,127 --> 00:46:24,621
el kit de metodología de historias de
usuario y Scrum, me han encargado un nuevo

722
00:46:24,621 --> 00:46:27,409
sistema que tiene que hacer algo, ¿cómo
empezamos?

723
00:46:27,609 --> 00:46:32,475
Bueno, pues yo en la literatura he
recogido un par de prácticas comunes, y

724
00:46:32,475 --> 00:46:32,809
es...

725
00:46:33,198 --> 00:46:38,664
Lo primero, trabajar en forma de workshop
estructurados, esto también es muy viejo,

726
00:46:38,664 --> 00:46:43,664
sale de metodologías de captura de
requisitos de los años 70 que se llamaban

727
00:46:43,664 --> 00:46:45,598
Join Application Development,

728
00:46:46,175 --> 00:46:50,842
donde se trataba de crear grupos
heterogéneos, multidisciplinares, que se

729
00:46:50,842 --> 00:46:55,963
juntaban en plan cónclave, cerrando con
llave y de allí no salía nadie hasta que

730
00:46:55,963 --> 00:47:01,343
no se especificaban un conjunto de cosas y
tal, y que se estructuraba la reunión con

731
00:47:01,343 --> 00:47:06,464
un secretario, un facilitador, que era
alguien no involucrado directamente, pero

732
00:47:06,464 --> 00:47:11,131
que facilitaba la discusión entre los
demás, bueno, en fin, son cosas muy

733
00:47:11,131 --> 00:47:11,780
conocidas.

734
00:47:11,980 --> 00:47:16,282
Entonces se trata de hacer un workshop de
story mapping, de story writing, perdón,

735
00:47:16,482 --> 00:47:21,748
donde en conjunto, esto funciona en grupos
pequeños, yo lo he intentado hacer en

736
00:47:21,748 --> 00:47:26,948
clase, que son 40, es un gallinero, no
funciona, entonces esto tiene que ser en

737
00:47:26,948 --> 00:47:30,748
grupos, yo diría, 10 o menos, de lo
contrario no funciona.

738
00:47:31,231 --> 00:47:35,457
Entonces, las personas, de forma
espontánea, en grupos estructurados y

739
00:47:35,457 --> 00:47:40,357
multidisciplinares, y que no vienen a la
reunión con la mente en blanco, sino que

740
00:47:40,357 --> 00:47:45,440
previamente han hecho unos deberes y traen
propuestas concretas, tienen que proponer

741
00:47:45,440 --> 00:47:49,728
una serie de roles de usuario y un
conjunto de user stories candidatas.

742
00:47:49,928 --> 00:47:54,135
o bien para todo el proyecto o al menos
para la siguiente entrega.

743
00:47:54,335 --> 00:47:59,601
De una manera estructurada se discute
sobre ellas y se las clasifica en cuanto a

744
00:47:59,601 --> 00:48:04,535
nivel de granularidad en epics, features o
stories y así se va procediendo.

745
00:48:06,173 --> 00:48:10,614
Y la segunda actividad, una vez que tengo
un juego de historias de usuario

746
00:48:10,614 --> 00:48:15,542
candidatas, es hacer lo que se llama story
mapping, que es la descomposición en la

747
00:48:15,542 --> 00:48:18,585
granularidad adecuada para las historias
de usuario

748
00:48:18,785 --> 00:48:21,308
y su organización y secuenciación
temporal.

749
00:48:21,368 --> 00:48:24,568
Tengo un par de dibujitos que vienen a
aclararlo.

750
00:48:26,014 --> 00:48:31,280
El story mapping viene a situar en un eje
de tiempos que va de la izquierda a la

751
00:48:31,280 --> 00:48:36,747
derecha todas las historias de usuario, de
forma que, y como no voy a saber usar el

752
00:48:36,747 --> 00:48:39,014
láser me voy a levantar a apuntar,

753
00:48:44,958 --> 00:48:50,424
Yo aquí pongo epics y por debajo de cada
epic pongo las historias de usuario en que

754
00:48:50,424 --> 00:48:51,358
se descompone.

755
00:48:54,189 --> 00:48:59,122
El criterio de valor de negocio o
prioridad es de arriba a abajo y el orden

756
00:48:59,122 --> 00:49:01,989
de implementación es de izquierda a
derecha.

757
00:49:03,701 --> 00:49:08,546
De forma que esta historia de usuario
tiene mayor valor que esta historia de

758
00:49:08,546 --> 00:49:11,454
usuario, aunque se van a implementar a la
vez.

759
00:49:11,654 --> 00:49:16,927
Y estas dos historias de usuario tienen el
mismo valor de negocio, aunque yo voy a

760
00:49:16,927 --> 00:49:19,011
implementar esta antes que esta.

761
00:49:19,211 --> 00:49:22,611
Así que aquí las dos dimensiones son
significativas.

762
00:49:22,719 --> 00:49:27,852
En vertical el valor de negocio, en
horizontal de izquierda a derecha el orden

763
00:49:27,852 --> 00:49:29,052
de implementación.

764
00:49:31,482 --> 00:49:36,875
de forma que con las historias de usuario
que identifiqué en el workshop anterior y

765
00:49:36,875 --> 00:49:42,137
una vez descompuestas hasta su nivel de
granularidad adecuado, yo voy a conseguir

766
00:49:42,137 --> 00:49:47,267
ordenarlas de forma que sé lo que tengo
que implementar, con qué prioridad y en

767
00:49:47,267 --> 00:49:48,517
qué orden temporal.

768
00:49:48,717 --> 00:49:53,717
Aquí está muy bonito, muy cuadrado, en la
realidad suele tener más bien este

769
00:49:53,717 --> 00:49:58,117
aspecto, en algún tipo de tablón o papel
en la pared y con post-its

770
00:50:01,570 --> 00:50:06,970
pues yo pongo aquí por lo que se ve hay
epics aquí esto de aquí en amarillo suelen

771
00:50:06,970 --> 00:50:12,170
ser themes se agrupa este conjunto de
historias de usuario bajo un nombre común

772
00:50:12,170 --> 00:50:17,036
porque giran en torno a la misma
funcionalidad y aquí historias de usuario

773
00:50:17,036 --> 00:50:21,903
que no están puestas en un orden
arbitrario sino por importancia de arriba

774
00:50:21,903 --> 00:50:26,036
a abajo y por orden de implementación de
izquierda a derecha si

775
00:50:30,578 --> 00:50:35,711
Quisiéramos poner un ejemplo como bien
hecho y con esto casi vamos a terminar.

776
00:50:37,888 --> 00:50:39,221
Yo tendría algo así.

777
00:50:40,592 --> 00:50:45,824
Aquí veis esto es un sistema inventado que
debo haber sacado no sé de dónde para el

778
00:50:45,824 --> 00:50:50,100
desarrollo de un cliente avanzado de
correo electrónico que tiene la

779
00:50:50,100 --> 00:50:55,013
funcionalidad de enviar y recibir correos
electrónicos y también dispone de un

780
00:50:55,013 --> 00:50:57,310
calendario para organizar tu agenda.

781
00:50:57,511 --> 00:51:00,777
Entonces por arriba hemos encontrado
cuatro EPICS.

782
00:51:01,396 --> 00:51:05,729
Organizar email, gestionar email,
gestionar calendario y gestionar

783
00:51:05,729 --> 00:51:06,396
contactos.

784
00:51:07,484 --> 00:51:12,750
Son los grandes EPICS o funcionalidades de
altísimo nivel que tiene que tener la

785
00:51:12,750 --> 00:51:13,484
aplicación.

786
00:51:16,056 --> 00:51:19,789
En cuanto a organizar email yo he puesto
aquí dos themes.

787
00:51:20,682 --> 00:51:23,425
Búsqueda de correos y registro de correos.

788
00:51:23,586 --> 00:51:26,910
En búsqueda de correos tenemos buscar por
palabra clave,

789
00:51:27,160 --> 00:51:32,293
buscar por campo, limitar la búsqueda a
solo un campo, buscar por attachment o

790
00:51:32,293 --> 00:51:33,760
buscar en subcarpetas.

791
00:51:40,861 --> 00:51:46,327
En cuanto al registro de emails, tengo dos
historias de usuario, poder mover emails

792
00:51:46,327 --> 00:51:49,061
entre carpetas y poder crear subcarpetas.

793
00:51:50,583 --> 00:51:55,331
En cuanto a la epic de gestionar email,
tengo dos grandes themes, componer

794
00:51:55,331 --> 00:51:59,884
mensajes, es decir, crear mensajes de
correo y leer mensajes de correo.

795
00:52:00,084 --> 00:52:05,550
En componer mensajes de correo tengo crear
y enviar email básico, crear y enviar en

796
00:52:05,550 --> 00:52:08,417
formato RTF, crear y enviar en formato
HTML.

797
00:52:10,107 --> 00:52:13,707
crear email con nivel de prioridad y así
sucesivamente.

798
00:52:13,915 --> 00:52:19,181
En leer tengo leer básico, leer RTF, leer
HTML, en borrar tengo borrar mensaje o

799
00:52:19,181 --> 00:52:23,048
borrar la carpeta de trash o de basura y
así sucesivamente.

800
00:52:25,852 --> 00:52:30,712
Como normalmente un proyecto tengo que
ponerlo en explotación, no solo cuando

801
00:52:30,712 --> 00:52:35,381
acabo, sino que hay entregas intermedias
de producto que pueden ponerse en

802
00:52:35,381 --> 00:52:39,858
explotación, puedo trazar líneas
horizontales que representan releases.

803
00:52:39,878 --> 00:52:44,878
De forma que esta es la funcionalidad que
voy a entregar en la release 1 del

804
00:52:44,878 --> 00:52:45,478
producto.

805
00:52:46,085 --> 00:52:50,771
esta es la funcionalidad que le voy a
añadir a la segunda release de producto y

806
00:52:50,771 --> 00:52:55,398
esta es la funcionalidad que le voy a
añadir a la tercera release de producto.

807
00:52:55,418 --> 00:52:59,951
Así que si yo he tenido éxito en la
aplicación de esta metodología de

808
00:52:59,951 --> 00:53:05,284
descripción de requisitos funcionales de
un sistema, lo tendré todo organizado de

809
00:53:05,284 --> 00:53:10,884
forma que tengo claro qué valor tiene cada
historia de usuario, qué prioridad o valor

810
00:53:10,884 --> 00:53:12,017
de negocio tiene,

811
00:53:14,536 --> 00:53:19,469
en qué orden las voy a implementar y
cuáles van a ir en la release 1, en la

812
00:53:19,469 --> 00:53:21,336
release 2 y en la release 3.

813
00:53:22,065 --> 00:53:27,524
Esto que en un ejemplo, digamos, académico
se muestra muy bien en una transparencia,

814
00:53:27,524 --> 00:53:30,155
no es fácil de conseguir en la realidad.

815
00:53:30,355 --> 00:53:35,288
Es decir, llegar a esa pizarra o ese
tablón donde de una vez por todas esto

816
00:53:35,288 --> 00:53:38,355
está tan organizado, además de que es
dinámico.

817
00:53:39,781 --> 00:53:44,445
que yo puedo llevarme este post-it de aquí
y lo pongo aquí, y este de aquí a aquí, y

818
00:53:44,445 --> 00:53:48,715
voy marcando hecho o pospuesto, es decir
que esto se va moviendo, sin lugar a

819
00:53:48,715 --> 00:53:51,075
dudas, es decir que esto es una cosa viva.

820
00:53:51,276 --> 00:53:55,641
Y luego por otra parte, esto está muy bien
para que se manejen los equipos de

821
00:53:55,641 --> 00:54:00,237
trabajo, pero con frecuencia también se
utilizan herramientas, herramientas donde

822
00:54:00,237 --> 00:54:02,650
está la información detallada de todo
esto.

823
00:54:02,815 --> 00:54:07,887
pues yo tengo alguna experiencia, nosotros
hemos usado con propósitos académicos una

824
00:54:07,887 --> 00:54:12,776
herramienta que se llama Ice Scrum, donde
permite registrar todo esto para que en

825
00:54:12,776 --> 00:54:17,237
extenso las conversaciones en relación con
cada historia de usuario queden

826
00:54:17,237 --> 00:54:20,109
registradas y donde hay criterios de
validación.

827
00:54:20,310 --> 00:54:21,920
Hay herramientas como Fitness,

828
00:54:22,120 --> 00:54:26,985
que a partir de un criterio de validación
escrito en el lenguaje natural es capaz de

829
00:54:26,985 --> 00:54:30,854
crear casos de pruebas de aceptación
escritas en Java, por ejemplo.

830
00:54:31,094 --> 00:54:35,369
Hay muchas herramientas que se pueden
añadir a este mecanismo básico de

831
00:54:35,369 --> 00:54:37,385
interacción en grupos de trabajo.

832
00:54:37,585 --> 00:54:42,918
Yo creo que no tengo nada más para este
somero repaso a lo que es la metodología,

833
00:54:42,918 --> 00:54:43,851
solo nombraros

834
00:54:45,239 --> 00:54:49,939
algo de bibliografía que tiene la gracia
de que si se accede desde una dirección de

835
00:54:49,939 --> 00:54:54,296
la UPM se puede acceder a un servicio
gratuito que es Safari Books Online, es

836
00:54:54,296 --> 00:54:58,481
decir, que no hace falta comprarse los
libros, solo si se accede desde una

837
00:54:58,481 --> 00:55:02,151
dirección de la UPM que es quien paga la
suscripción al servicio.

838
00:55:02,351 --> 00:55:03,351
Y por mi parte,

839
00:55:04,105 --> 00:55:09,638
Pues creo que nada más, con esto termino y
bueno, lo que os parezca oportuno debatir

840
00:55:09,638 --> 00:55:10,438
o preguntar.

841
00:55:11,055 --> 00:55:15,921
[Orador 2]: Mi pregunta es cómo encajan algunos
mecanismos que hay de más amplio nivel

842
00:55:15,921 --> 00:55:20,721
como descripción de escenarios o
descripción de personas donde cuentas...

843
00:55:20,930 --> 00:55:26,002
toda una historieta donde entrarían varias
de estas user stories interrelacionadas

844
00:55:26,002 --> 00:55:29,384
sin saber muy bien dónde acaba una, dónde
empieza otra.

845
00:55:29,584 --> 00:55:34,164
¿Cómo encajaría esto que se hace muchas
veces para empezar a arrancar una

846
00:55:34,164 --> 00:55:37,537
definición, una especificación de
requisitos en Scrum?

847
00:55:37,557 --> 00:55:40,423
Si se usa o si es algo completamente
aparte.

848
00:55:41,284 --> 00:55:43,427
[Orador 1]: No estoy seguro de entender la pregunta,
Samuel.

849
00:55:43,407 --> 00:55:47,576
[Orador 2]: Sí, hay metodologías como por ejemplo
definición de personas donde dices, Claire

850
00:55:47,576 --> 00:55:51,798
es una estudiante deportista que no sé
qué, vas contando todas sus motivaciones y

851
00:55:51,798 --> 00:55:55,968
cuentas como usaría el sistema Sí, una
caracterización de ese rol en concreto de

852
00:55:55,968 --> 00:56:00,137
ese usuario O descripciones de escenarios
donde no se centra tanto en el usuario

853
00:56:00,137 --> 00:56:04,360
sino que empieza a decir, pues el usuario
llega por la mañana, abre la aplicación

854
00:56:04,360 --> 00:56:07,474
del email, tiene muchos emails de trabajo,
emails personales

855
00:56:07,454 --> 00:56:12,787
empieza a responder emails, luego cambia,
no entras tanto en la definición de los

856
00:56:12,787 --> 00:56:17,387
requisitos concretos que serían las User
Stories que aquí ya están muy

857
00:56:17,387 --> 00:56:22,720
concretizadas responder email, escribir
email, borrar email ¿Cómo encajarían este

858
00:56:22,720 --> 00:56:28,187
tipo de artefactos que se usan a veces muy
de principio de no sé cómo voy a abordar

859
00:56:28,187 --> 00:56:29,987
el sistema dentro de Scrum?

860
00:56:30,657 --> 00:56:32,857
¿Sería razonable empezar por ahí?

861
00:56:33,340 --> 00:56:34,606
No, yo creo que no.

862
00:56:35,383 --> 00:56:38,949
[Orador 1]: Yo creo que te refieres a descripciones
que son más elevator pitch que otra cosa.

863
00:56:39,149 --> 00:56:40,832
Normalmente es cuando se quiere vender una
moto, ¿no?

864
00:56:40,852 --> 00:56:44,608
Se pone el escenario de alguien que en un
uso cotidiano de la vida, pues algo de

865
00:56:44,608 --> 00:56:45,559
tipo futurista, ¿no?

866
00:56:45,620 --> 00:56:50,181
Y fulano llega al hotel y le gustaría
tener los mismos canales de su proveedor

867
00:56:50,181 --> 00:56:52,551
de televisión de pago que tiene en casa.

868
00:56:52,571 --> 00:56:55,856
Y entonces, con solo identificarse por voz
ante la tele, dirá.

869
00:56:55,876 --> 00:57:00,343
Y entonces se presenta un escenario
atractivo y para vender una moto, no.

870
00:57:00,323 --> 00:57:03,924
No, eso es un vendemotos, no tiene que ver
con una metodología de captura de

871
00:57:03,924 --> 00:57:05,797
requisitos funcionales para un sistema.

872
00:57:05,997 --> 00:57:10,935
Bueno, un vendemotos, no quiero ser
despectivo, pero es un elevator pitch para

873
00:57:10,935 --> 00:57:15,681
llamar la atención a alguien sobre las
bondades de lo que quieres venderle.

874
00:57:15,701 --> 00:57:18,234
No, no tienen relación, casi relación.

875
00:57:23,105 --> 00:57:24,571
¿Alguna otra cuestión?

876
00:57:24,747 --> 00:57:29,747
[Orador 3]: Sí, yo quería preguntar, si vamos dos
transparencias atrás, que va a ser más

877
00:57:29,747 --> 00:57:35,213
fácil preguntarlo, justo la representación
de las historias de usuario con respecto

878
00:57:35,213 --> 00:57:37,347
al tiempo y al valor de negocio.

879
00:57:37,944 --> 00:57:43,010
Aquí pintamos las release, pero claro, en
teoría el eje horizontal es tiempo,

880
00:57:43,010 --> 00:57:47,610
entonces no sé encajar, porque al final
las tres release las tienes...

881
00:57:50,763 --> 00:57:52,963
en el mismo tiempo, al finalizar.

882
00:57:53,867 --> 00:57:55,769
[Orador 1]: Bueno, no, claro, no está bien
representado.

883
00:57:55,789 --> 00:57:56,989
Iríamos en zigzag.

884
00:57:58,192 --> 00:58:02,592
Cogen la banda de la raíz 1, la
implementas, entregas, vuelves a la

885
00:58:02,592 --> 00:58:03,258
izquierda.

886
00:58:04,300 --> 00:58:09,226
Sí, en dos dimensiones no es... He visto
hace poco la película Interestelar.

887
00:58:09,426 --> 00:58:10,408
No sé si la habéis visto alguno.

888
00:58:10,468 --> 00:58:15,534
Yéndome a la quinta dimensión hubiera
podido quizás representarlo, pero no...

889
00:58:16,092 --> 00:58:20,557
Bueno, veo que no muchos de vosotros lo
habéis visto, es que va de dimensiones y

890
00:58:20,557 --> 00:58:24,402
viajes en el espacio que sales diciendo no
sé en qué dimensión estoy.

891
00:58:25,265 --> 00:58:26,665
¿Alguna pregunta más?

892
00:58:29,592 --> 00:58:31,325
¿Os ha quedado todo claro?

893
00:58:33,097 --> 00:58:36,763
Bueno, pues si no tenéis más preguntas, lo
dejamos aquí.

894
00:58:37,724 --> 00:58:38,725
Muchas gracias a todos.