Modelo de desarrollo dev ops (wows)

Modelo de Desarrollo DevOps
Oct, 2021
SW Transformation

3
SW Transformation - DevOps Process
DevOps Process -Introducción-
Equipo de desarrollo: Es el
equipo multidisciplinar de
producto que tienen algún
componente tecnológico.
Está compuesto por el PO (o
peticionario en tradicional),
desarrolladores, otros
perfiles e incluso
stakeholders.
Anexos: Conceptos
básicos
Boost the basics: Aplicar
bien la forma de trabajo
básica en los equipos de
desarrollo y reflejarlo de
manera correcta en la
herramienta corporativa
Jira

4
DevOps Process -Introducción-
Objetivos que perseguimos
En este documento se va a describir, de forma resumida, cómo trabajar con
prácticas DevOps y la forma de trazar información mediante la herramienta Jira.
Siempre como parte del ciclo de vida del desarrollo software en BBVA.
Anexos: Conceptos
básicos

5
DevOps Process
Prácticas DevOps desde el punto de vista de la trazabilidad en Jira
Planning Construction Delivery Operations
Gestión de incidencias
Identificamos los errores
reportados y los
asociamos a los equipos
resolutores.
Definicion funcional y
planificación.
Describimos Features,
planificando el trabajo
del equipo de forma
trimestral, y Stories por
Sprint.
Desarrollo, integración
y testing
Las Features
planificadas se desglosan
en Stories y
Dependencias, en su
mayoría asociadas con
desarrollos software.
Integración y despliegue
Marcamos las diferentes
Features descritas como
entregadas con el fin de
trazar lo descrito
funcionalmente con la
fecha.
Desde el punto de vista de la información, las siguientes fases van a determinar el trabajo que vamos a
desempeñar en Jira.

6
Jira
Importancia de las buenas prácticas
Las prácticas y uso común de la herramienta garantizan la consistencia de los datos y por lo tanto una única visión
y lectura de los mismos.
● Importancia de la información: Cada uno de las Issues (ticket de información) que creamos debe tener la
suficiente información como para dejar claro el objetivo que persigue, así como su capacidad de
resolverse. Debe ser comprendida por todo el equipo.
● Uso del workflow guiado: Trabajar con los mismos estados y las mismas transiciones nos garantiza una
mejora en la calidad de la información y simplifica el uso de los estados para otros fines.
● Importancia de actualizar los estados: Cada persona que trabaja en Jira tiene la responsabilidad de
mantener la información asociada a su equipo o equipos. Los estados deben indicar de la forma más
fidedigna las acciones que se realizan sobre un ticket y el tiempo que ha costado dicha acción.
● Trazabilidad: Tener una visión completa del proceso de desarrollo software ayuda a saber el esfuerzo que
cuesta una nueva funcionalidad, poniendo en común problemas y capacidades. La importancia del
desglose de las Features en historias de usuario garantiza la calidad del proceso.
Anexos: Métricas DevOps

9
El primer paso en el ciclo de vida del software sería la definición del tipo de Issue Feature: Funcionalidad que aporta valor al
cliente o stakeholder, o habilita a otra funcionalidad para ello, y que requiere un esfuerzo estimado para su desarrollo
dentro de un trimestre y es implantable (Ejemplo en Anexo).
Planning -Feature-
Funcionalidad desde el punto de vista del usuario final.
● Aporta valor al cliente o stakeholder.
● Tiene que poderse realizar entre 1 Sprint y 1 PI.
● Tiene que ser potencialmente puesta en manos del cliente (implantable).
● Tiene que ser INVEST (detalle en Anexo).
● Deben usar el estado deployed para indicar cuando está implantada y disponible a clientes (guía rápida de estados).
Características:
● Summary: Debe ser autoexplicativa (el cliente tiene que entenderlo).
● Type of Delivery: Distingue si la funcionalidad descrita en una feature va a ser entregada a clientes.
○ Customer Deliverable Execution Phase: Objetivos trimestrales que desarrollan funcionalidades que consumen los
clientes
○ Discovery Pre-Execution Phase: Objetivos y tareas necesarias previas a la fase de ejecución del proyecto.
○ Functional Execution Phase: Objetivos y tareas de negocio durante la fase de ejecución del proyecto
○ Enabler Deliverable Execution Phase: Objetivos trimestrales que si necesitan desarrollo software pero no se entrega a
Campos más relevantes

10
Planning -Feature-
Feature Workflow
FEATURE (JIRA)
Execution
Delivery Operations
Construction
Design & Set Up
New Analysing Ready In Progress Ready to Verify Accepted
Ready to
Deploy
Deployed
El workflow en Jira es fundamental para aportar información del avance y posibles bloqueos. Se trata de la información
más importante que tenemos que actualizar.
Refinamiento. Detallar la
feature y convertirla en
un documento de trabajo
planificado y priorizado
No necesita más nivel de
detalle. Comprendida por
todo el equipo, tiene
capacidad de desglose y
ejecución
Alguna de las tareas en
las que se ha desglosado
se encuentra en estado
“In progress”
Con capacidad de ser
probada funcionalmente.
Se han desarrollado todas
las Issues asociadas a la
misma.
Lo descrito encaja con lo
desarrollado. Se
considera finalizado en
cuanto a construcción.
El código asociado a la
funcionalidad tiene
capacidad de ser
implantado
funcionalidad está en
manos de cliente. Se
considera entregado
Alta de una nueva
funcionalidad. Toda la
información que nos
ayude a identificarla y
ordenarla

12
Construction -User Story-
Funcionalidad desde el punto de vista del usuario final
Las historias de usuario son una descripción breve de una funcionalidad contada desde la perspectiva del cliente y escrita
en el lenguaje común del usuario, y que son resultado de descomposición de las features por parte del equipo. Una historia
debe ser desarrollada íntegramente durante un Sprint (Ejemplo en Anexo).
● Aporta valor al cliente o stakeholder.
● Tiene que poderse realizar entre 1 Día y 1 Sprint.
● Tiene que ser potencialmente puesta en manos del cliente (implantable).
● Tiene que ser INVEST (Detalle en Anexo).
● Deben estar asociadas a una feature.
Características:
● Tech Stack: Marcamos el tipo de desarrollo predominante en la historia de usuario.
● Feature link: Recomendamos crear la historia dentro del detalle de la feature padre desde el botón habilitado para tal efecto, de
no ser así, debemos completar el campo Feature link del formulario de entrada al crear la historia de usuario dejándola enlazada
a la funcionalidad a la que pertenece.
Campos más relevantes:

13
Construction -Dependency-
Funcionalidad desde el punto de vista del usuario final
Tareas necesarias para completar las features que deben ser ejecutadas fuera de la capacidad interna del equipo, es decir, un
entregable proporcionado por otro proyecto o por algún especialista de cualquier otro equipo o building block. Las
dependencias son tareas independientes, negociables, planificables y cuantificables. Cuando una dependencia no se cumple
se puede convertir en un impedimento.
● Una dependencia no se puede dar por valida hasta que no ha sido aceptada por el receptor.
● Todas las dependencias que se necesiten para el plan de ese trimestre deben estar validadas de iniciar el PI (1 semana antes. El
proceso de declaración de dependencias se recomienda mínimo con 2 Sprints de adelanto).
● Tiene que poderse realizar entre 1 Día y 1 Sprint.
● Deben estar asociadas a una feature.
Características:
● Petitioner y Receptor Team: Equipo que peticiona la dependencia y el equipo que lo recepciona o ejecutor.
● Feature link: Recomendamos crear la dependencia dentro del detalle de la feature padre desde el botón habilitado para tal
efecto, de no ser así, debemos completar el campo Feature link del formulario de entrada al crear la historia de usuario dejándola
enlazada a la funcionalidad a la que pertenece.
Campos más relevantes:

14
Planning -Story-
Story Workflow
STORY (JIRA)
Feature
New Analysing Ready In Progress Ready to Verify Accepted
Ready to
Deploy
Deployed
En la actualidad el ciclo de vida de una historia es igual al de su ascendente la Feature. Si bien es cierto recomendamos el
uso de todos los estados, siendo posible que no todos sean necesarios dependiendo de la forma de trabajar del equipo.
Refinamiento. Detallar la
historia como para que
sea comprendida por
todo el equipo
Se encuentra priorizada y
lista para entrar en un
sprint de trabajo.
Se inicia el desarrollo de
la tarea.
Se valida que la historia
cumple con los requisitos
definidos
Aceptación funcional o
integración de código
El código integrado se
encuentra en una rama de
despliegue.
historia se ha desplegado
en un entorno productivo
Alta de una nueva historia
de usuario asociada con
una Feature.

16
Delivery
El estado Deployed como sinónimo de entrega
El estado DEPLOYED debe ser el concepto de entregado para todos los que desarrollamos informando nuestro trabajo
en Jira. El modelo irá evolucionando para guardar la información de las versiones y agrupaciones por entrega.
● Revisar periódicamente nuestros backlogs (todas las issues asignadas a un mismo “team backlog”). Es
importante descartar (estado DISCARDED) o borrar (DELETED) todos los issues, sobre todo Features, que no
vayan a formar parte de la entrega, para poder tener una visión real del esfuerzo empleado.
● Reducir los tiempos de fases no productivas. TO REWORK y BLOCKED son estados que indican falta de
progreso. Si está en nuestra mano debemos intentar desbloquear este tipo de situaciones.
● Es bastante común que las Features se encuentren demasiado tiempo en estado de READY TO VERIFY.
recomendamos que el equipo avise de forma activa a la persona encargada de verificar la funcionalidad del
mismo.
Recomendaciones de mantenimiento de la información:

18
Operations -Bug-
Trabajo diario con errores e incidencias
Los debemos usar para tipificar aquellos cambios software no evolutivos ó que están destinados a solucionar algún
comportamiento no deseado.
- Casos provenientes de canales de atención al usuario que sean correctivos que requieran cambios
software.
- Incidencia que requiere cambio software.
- Hotfixes.
- Correctivos software realizados después de integrar o publicar los cambios con terceros.
- Errores encontrados como parte del desarrollo de una User Story y antes de integrar o publicar los
cambios con terceros.
- Incluir nuevos cambios de uso en una User Story una vez pasa de estado In Progress.
● Ejemplos de casos que SÍ deberíamos tipificar como Bug:
● Ejemplos de casos que NO deberíamos tipificar como Bug:
Características:

19
Operations -Bug-
Información necesaria para gestionar errores e incidencias
Dentro de Jira los BUGS nos sirven como medida para conocer la calidad de la entrega, y capacidad de respuesta. Es
importante que el título del mismo sea lo suficiente descriptivo e incluir en el caso de que tengamos en identificador de la
incidencia.
● Stage: El entorno más crítico donde se presenta el problema. Es
importante para discriminar el impacto; no es lo mismo generar
una indisponibilidad en entornos previos que en entornos
productivos.
○ Production: Cuando el error se presenta en entornos
usados por los clientes.
○ Release: Cuando el error se descubre en las pruebas de
release o de certificación antes de salir a producción.
○ Development: Cuando el error se descubre después de
integrar o desplegar los cambios.
● Support Cases: debemos añadir los códigos de los casos de
soporte separados por comas, p.e INC0023134, INC0023142,
etc.
Información:
● Priority: Realmente importante indicar la prioridad cuando un
Bug se ha encontrado en un entorno productivo. Se debe aplicar
el siguiente criterio común 1:
○ Blocker: Caída de servicios críticos o pérdidas
económicas importantes. Es recomendable que sean
resueltos en menos de 24 horas (se debe marcar como
Hot Fix en el campo habilitado para ello)
○ Highest, High: Mal funcionamiento de servicios críticos ó
pérdidas económicas moderadas. Es recomendable que
sean resuelto en menos de 3 días (se debe marcar como
Hot Fix en el campo habilitado para ello)
○ Medium, Low, Lowest: Impacto en servicios no críticos ó
pérdidas económicas bajas. Resuelto en el siguiente pase
calendado.
● Detection Date: Indicar siempre la fecha inicial en la que se
descubrió el problema y los clientes lo reportaron. 1 El criterio de priorización de bugs está en revisión y podría ser modificado

21
Enforcement
La automatización de las buenas prácticas
De forma gradual, Jira mediante la herramienta SAMUEL , va a ofrecer nuevas ayudas contextuales que nos van a
proporcionar más control sobre la información y una mayor calidad en los datos. Estas validaciones o políticas de
comportamiento, empezaran siendo simplemente avisos que nos guiarán a través de las distintas fases del desarrollo
software. Solamente aplicaran a aquellos equipos que se encuentren trabajando bajo el workflow guiado.
● Historias y dependencias parte de una Feature: El comportamiento avisa cuando una historia o dependencia sin padre feature avanza en el
workflow
● Coherencia jerárquica de entrega: El comportamiento avisa si una Feature avanza a estado DEPLOYED y alguna de sus Historias o
dependencias descendientes no se encuentran finalizadas (estados finales)
● Coherencia aceptación de Feature: El comportamiento avisa, si seguimos desglosando trabajo en una Feature en estado ACCEPTED
● Trazabilidad equipos SDA: Si un equipo está marcado como “SDA related” se validará que sus Features están relacionadas con un proyecto de la
SDA al pasar al estado IN PROGRESS.
● Trazabilidad código: El comportamiento avisa si las historias tipificadas con el campo “Tech Stack” para los valores CELL, ASO y APX no cuentan
con al menos un commit asociado cuando lleguen al estado READY TO VERIFY.
● Coherencia jerárquica de trabajo: El comportamiento nos avisa de que una Feature no ha sido desglosada en historias de usuario y
dependencias cuando llega al estado IN PROGRESS
● Coherencia jerárquica progreso (automatización): Si una de las historias o dependencias que componen una Feature pasa al estado IN
PROGRESS la Feature debe pasar automáticamente al estado IN PROGRESS
Ejemplos de comportamientos fase 1:

24
DevOps Process
Conceptos básicos para trabajar en Jira
● Workspace: Un espacio de trabajo (Project en Jira) determina la
tipología de la entrega de lo que los equipos van a desarrollar.
Podríamos decir que se corresponderia con el aplicativo o área
donde trabajan de forma independiente un determinado número
de equipos, es obligatorio tener o conocer el espacio de trabajo
donde creamos nuestros tickets funcionales..
● Team Backlog: Pila de tareas y objetivos independientes de un
equipo, que puede agrupar trabajo de varios workspaces.
● Issue: Es posible que veas escrito este término en numerosos
manuales o documentación oficial. En Jira una issue es un ítem o
ticket de información. El cual siempre va a pertenecer a un
Workspace por tipo de entrega y a un team backlog responsable
del desarrollo y entrega del mismo. Los mas comunes serian
Feature, Story, Dependency y Bug
● Workflow: Cada uno de las Issues descritas anteriormente
avanza (ciclo de vida ) por una serie de estados que
determinan fases en las cuales se deben realizar una serie de
acciones.
● Developer Team: Siempre que hacemos mención a un equipo
de desarrollo no nos referimos en exclusiva a las personas que
se dedican a construir código, si no todos los integrantes desde
la definición, pasando por el diseño construcción y la entrega.
● Backlog: Siempre que hacemos mención a este término nos
referimos a la pila de trabajo de un equipo formada por varias
Issues ordenadas por prioridad.
En ocasiones, vamos a encontrarnos en la documentación algunos conceptos que debemos conocer para
comprender mejor el objetivo del mismo. A continuación explicamos algunos de los términos más empleados.

25
DevOps Metrics
La calidad de la información como palanca en la entrega de valor al cliente
La información nos ayuda en la mejora de los procesos
Los ejes de información en Jira:
La calidad de la información que volcamos en Jira es fundamental para mejorar el proceso productivo. No se
trata de gestión o seguimiento que aporta muy poco a la mejora del sistema. Los datos son la pieza clave para
descubrir las ineficiencias del proceso.
● Workspaces: Como eje de información nos debe dar visión de
entrega, bien dentro de una unidad de trabajo donde desarrollan
software varios equipos o bien dentro de un aplicativo.
● Team backlogs: Si los nombres de los backlog se encuentran
correctamente definidos y expresan claramente la tipología de la
entrega de este backlog. Tendremos el eje por el que mediremos el
trabajo, desde el punto de vista del esfuerzo y responsabilidad de
la entrega
● Geografía: Presente como datos en cada uno de nuestros Team
backlogs y workspace indican la procedencia del equipo (global,
local) o donde se está entregando
Calidad y predicción de entrega.
Anticipación de necesidades.
Calidad pruebas del equipo.
Recursos y capacidad.
Capacidad de respuesta.
Análisis de cuellos de botella.
Fortalezas y debilidades .

26
INVEST - Features y Stories
La información nos ayuda en la mejora de los procesos
S (Pequeña):
Una buena Feature / Story debe ser
pequeña en esfuerzo (max. 1
iteración - PI / Sprint)
Las Features y Stories deberían ser
independientes de otras (lo más
posible).
Una Feature / Story de usuario es
negociable. La "tarjeta" es una
descripción corta que no incluye
detalles.
Cada Feature / Story tiene que tener
un valor para el cliente (para el usuario
o para el comprador).
INVEST
I (Independiente):
N (Negociable):
V (Valiosa):
E (Estimable):
Los desarrolladores necesitan poder estimar
una Feature / Story de usuario para permitir
que se pueda priorizar y planificar.
T (Testeable):
Una Feature / Story necesita poder
probarse para que ocurra la etapa de
"confirmación”

27
Ejemplos: Clientes de las Features
Cliente: Usuario de la app BBVA (cliente retail)
Feature: Transferencia entre dos particulares
Feature: Listar movimientos de tarjetas
Feature: Buscar un fondo
Cliente: Empleado BBVA
Feature: Reservar plaza de parking de una sede
Feature: Pedir un día de vacaciones
Feature: Revisar mi última nómina
Cliente: Banco Central Europeo
Feature: Transferir cierre contable
Cliente: Red de oficinas
Feature: Calcular el rating hipotecario de un cliente

28
Las siguientes Features describen con visión cliente una funcionalidad completa e independiente al resto de funcionalidades que
ofrecemos a los clientes y le aporta valor (le permite generar una operación, le dota de facilidad de uso o comprensión, habilita
poder ofrecerle aspectos diferenciales, etc):
● La posición Global de la web de Retail
● Listado de movimientos de tarjetas
● Buscador de fondos en catálogo público
● Contratación de préstamo One-Click
● Traspaso entre cuentas
Ejemplos de lo que SÍ podría ser una Feature...
● El diseño UX para un frontal → Es parte de una funcionalidad.
● Test de pruebas → Es necesario y dota de consistencia a una funcionalidad, pero no es la funcionalidad de por sí.
● Tareas técnicas del equipo → Una refactorización va a permitir mejorar los tiempos de respuesta del equipo para poder
desarrollar nueva funcionalidades, tanto dotando al código de claridad como de reusabilidad, pero no es la funcionalidad.
● Una transacción Host que será invocada por un frontal → Es parte de una funcionalidad.
Ejemplos de lo que NO es una Feature...

29
Ejemplo - Features y Stories
Feature: Transferencia entre dos particulares
Beneficio: Permite que el cliente envíe dinero vía transferencia a otro particular.
Descripción: Proceso por el que un usuario es capaz de enviar dinero que tenga disponible en alguna de sus
cuentas a otra cuenta que conozca.
Criterios de Aceptación:
DADO un usuario logado en la App CUANDO quiere realizar una transferencia ENTONCES debe
seleccionar el origen de entre sus cuentas
DADO un usuario logado en la App CUANDO quiere realizar una transferencia ENTONCES debe añadir la
cuenta de destino donde quiere transferir el dinero
DADO un usuario logado en la App CUANDO quiere realizar una transferencia ENTONCES debe añadir la
cantidad que quiere transferir
DADO un usuario logado en la App CUANDO realiza una transferencia ENTONCES debe recibir una
notificación de que se ha realizado

30
Historia de Usuario: Añadir cuenta origen
COMO Usuario de la App
QUIERO seleccionar una de mis cuentas
PARA marcarla como origen de la operación de transferencia
Criterios de aceptación:
DADO un usuario logado en la App CUANDO selecciono una cuenta ENTONCES debe fijarse la cuenta
seleccionada.
DADO un usuario logado en la App CUANDO solo tiene una cuenta ENTONCES no debe desplegarse el
listado de cuentas.

31
Historia de Usuario: Añadir cuenta destino
QUIERO escribir un número de cuenta válido
PARA marcarla como destino de la operación de transferencia
DADO un usuario logado en la App CUANDO añado una cuenta destino ENTONCES debe verificarse el
número de cuenta marcarse en verde si es correcto
DADO un usuario logado en la App CUANDO añado una cuenta destino ENTONCES debe verificarse el
número de cuenta marcarse en rojo cuando no es correcto e indicarlo en un mensaje

32
Historia de Usuario: Añadir dinero a transferir
QUIERO añadir una cantidad válida
PARA añadir la cantidad de dinero que quiero transferir
DADO un usuario logado en la App CUANDO añado una cantidad ENTONCES debe verificarse que es
menor que el dinero disponible en la cuenta de origen saliendo un check en caso correcto
menor que el dinero disponible en la cuenta de origen poniéndose en rojo y saliendo un mensaje en caso
contrario
menor que el límite para esa cuenta para hacer transferencias poniéndose en rojo y saliendo un mensaje en
caso contrario

33
Historia de Usuario: Check transferencia
QUIERO recibir confirmación de transferencia
PARA saber que la operación se ha completado.
DADO un usuario logado en la App CUANDO realizo una transferencia ENTONCES debe salir un mensaje
de verificación en caso de que la operación haya tenido éxito
DADO un usuario logado en la App CUANDO realizo una transferencia ENTONCES debe salir un mensaje
indicando error y motivo en caso de que la operación no se haya podido realizar

34
Uso básico de Jira
Cómo buscar tu espacio de trabajo
Cómo se crea una Feature
Cómo ordenar Features en el Backlog
Cómo se crea una Story
Cómo desglosar una Feature en Stories y Dependencies
Cómo se abre un Sprint
Cómo se cierra un Sprint

Modelo de desarrollo dev ops (wows)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a Modelo de desarrollo dev ops (wows)

Similar a Modelo de desarrollo dev ops (wows) (20)

Último

Último (20)

Modelo de desarrollo dev ops (wows)