PDF Gestión Técnica de Proyectos
PDF Gestión Técnica de Proyectos
Índice
1.1 Herramientas para optimizar la gestión de proyectos (software)
1.2 Gestión Ágil con SCRUM y Kanban
1.3 Gestión de multiproyectos
1.4 Design thinking
Herramientas para optimizar la gestión de
1.1 proyectos (software)
Introducción a las metodologías ágiles
https://vimeo.com/323790959/dfea2f688f
Del desarrollo en cascada
al desarrollo ágil
Metodología predictiva:
el desarrollo en cascada.
Este método sigue fases estrictas que se adhieren
a un plan previamente diseñado con
requerimientos inamovibles al principio del
proyecto. Los directores de proyecto emplean
mucho tiempo negociando hitos, funcionalidades,
recursos, etc. trabajando con la duración de las
fases de planificación de un proyecto.
En este vídeo se
estudia el uso del
desarrollo en cascada
para empresas que
crean productos
innovadores (Startups).
https://youtu.be/jgsWdqMcMIo
Los clientes exponen todos sus requisitos antes de comenzar
el largo proceso de desarrollo incluido en el proyecto. El
director de proyecto traza todos los movimientos del proyecto
mediante la gestión de las entregas.
Si todo va bien, el proyecto produce un
lanzamiento en el tiempo y presupuesto
acordados.
No obstante, existen grandes inconvenientes asociados a la
gestión de proyectos utilizando metodologías predictivas:
No son capaces
de responder a
los cambios.
La entrega de un
producto funcional toma
mucho tiempo.
Teniendo en cuenta la naturaleza de la tecnología, es posible que un
lanzamiento de producto a seis meses vista, sobre requisitos fijos, no se
corresponda con las necesidades de los clientes.
Por lo tanto, fruto de la frustración de las
empresas de desarrollo de software con
estas metodologías fijas, surge la historia del
desarrollo ágil, que se diseña para acomodar
mejor los cambios y la necesidad de
desarrollar más rápido los productos.
Javier Garzás
explica el uso de
metodologías
ágiles en el
desarrollo de
software.
https://www.youtube.com/watch?v=L9qlrgKWqfI
El director de proyecto trata de:
Facilitar el trabajo del equipo de desarrollo.
Revisión de iteraciones
A
Funcionalid Funcionalid
ad D ad C
Motivos agregados
¡Vamos a verlos!
01 El enfoque actual de desarrollo en cascada no
está funcionando, por diferentes razones:
Las entregas se realizan con retraso.
La tasa de proyectos fallidos es demasiado elevada.
La calidad de los productos no es adecuada.
El retorno sobre la inversión no es suficiente.
La moral de los empleados es baja.
La productividad es baja.
No hay responsables por los resultados.
Hay demasiado personal y es difícil de
gestionar.
02 Todo lo que rodea al desarrollo del producto es incierto
y no se sabe lo que funcionará y lo que no.
04 lanzando
Se quiere tener una ventaja competitiva sobre la competencia
lo más rápido posible y para ello es necesario desnudar la
idea original e ir vistiéndola en lanzamientos progresivos.
Dominio simple
En el dominio simple se trata de detectar-categorizar-responder.
Tu dominio es simple si:
Respondes a hechos categorizados con prácticas ya establecidas.
Tu entorno es estable y probablemente no cambiará.
Las relaciones causa-efecto son muy claras para todos los miembros de la organización y el
entorno.
Tienes que explorar para aprender sobre un problema, luego inspeccionar y, por último, realizar
la adaptación.
Aunque se pueden solucionar estos problemas usando
Scrum, un enfoque más práctico y sencillo sería establecer
procesos fijos y basar la gestión en ellos.
B
B A
A
Dominio caótico A
B
B
Dominio complejo
B
B
A
Su máxima es sondear-detectar-responder.
Sabes si te encuentras este dominio si te encuentras con lo siguiente:
Tienes que explorar para aprender sobre un problema, luego inspeccionar y, por
último, realizar la adaptación.
Necesitas ser creativo e innovador.
Tienes que crear modos de experimentación a prueba de fracasos para descubrir
patrones.
Necesitas altos niveles de interacción y comunicación.
Tienes que esperar a fases posteriores a los lanzamientos para saber cualquier resultado.
Más cosas impredecibles que predecibles.
Dominio complicado
A
B
El Scrum es
Ligero
Fácil de entender
Eventos
Elementos o artefactos
Reglas Sirven para agrupar los eventos, roles y elementos, gestionando
y regulando las interacciones que tienen lugar entre estos.
Eventos
Equipos Scrum
La teoría de Scrum
Scrum se fundamenta como una teoría de control empírico.
01 Transparencia
02 Inspección
03 Adaptación
Transparencia
Los aspectos significativos de cada proceso deben ser visibles
para los responsables del resultado del mismo.
La transparencia requiere que esos aspectos
sean definidos elaborando estándares comunes,
de manera que los observadores tengan un
entendimiento común de lo que se está viendo
en cada momento.
Por ejemplo, todos los participantes deben
compartir un lenguaje común de referencia y
aquellos que se encarguen de realizar el trabajo
deben tener una definición común de lo que se
considera trabajo realizado.
Inspección
Los usuarios de Scrum deben frecuentemente inspeccionar los
elementos y progresar hacia el objetivo de la interacción para
detectar aquellas variaciones que ocurran.
Eso sí, la inspección no debe ser tan frecuente
como para que entorpezca el trabajo. Cuando
más beneficiosas son las inspecciones es
cuando son realizadas por inspectores
cualificados en el punto de trabajo.
Adaptación
Si un inspector determina que uno o más aspectos del proceso se están desviando fuera
de los límites aceptables y que el producto resultante sería, por tanto, inaceptable, este
proceso o el material que esté siendo procesado debe ser ajustado. Cualquier ajuste
debe realizarse lo antes posible para minimizar estas desviaciones no deseadas.
En Scrum hablamos de cuatro eventos formales para la inspección y la
adaptación.
Estos serían los ya mencionados:
Valores de Scrum
Todo trabajo realizado en el marco de Scrum necesita
una serie de valores que servirán como fundamento para
los procesos e iteraciones. El equipo, mediante la
aceptación de tales valores, las hace todavía más
fundamentales para su salud y éxito.
Valentía
Al trabajar juntos como equipo los miembros se sienten
apoyados y tienen más recursos a su disposición. Esto da
a los equipos mayor valentía para aceptar mayores retos.
Franqueza
En Scrum los miembros del equipo le cuentan a los otros
miembros cómo les va, qué obstáculos encuentran y qué
tipo de preocupaciones tienen acerca del desarrollo.
Compromiso
El compromiso con el éxito en Scrum es enorme dado
que con estas metodologías se tiene un gran control
sobre el propio destino de la empresa y del equipo.
Respeto
A medida que se trabaja juntos, compartiendo éxitos y
fracasos, las personas terminan por respetarse unos a otros y
se ayudan unos a otros a ser merecedores de respeto.
Metodología SCRUM
Scrum es un enfoque ágil para
desarrollar productos y servicios
innovadores.
Pero no hablamos de una metodología cualquiera, ya que
supone una gran innovación con respecto a otras
metodologías de gestión de proyectos.
Funcionalidad
Funcionalidad
A B
Revisión de iteraciones
Funcionalidad D Funcionalidad C
Motivos agregados
¡Vamos a verlos!
01 El enfoque actual de desarrollo en cascada no
está funcionando, por diferentes razones:
Las entregas se realizan con retraso.
La tasa de proyectos fallidos es demasiado elevada.
La calidad de los productos no es adecuada.
El retorno sobre la inversión no es suficiente.
La moral de los empleados es baja.
La productividad es baja.
No hay responsables por los resultados.
Hay demasiado personal y es difícil de
gestionar.
02 Todo lo que rodea al desarrollo del producto es incierto
y no se sabe lo que funcionará y lo que no.
04 lanzando
Se quiere tener una ventaja competitiva sobre la competencia
lo más rápido posible y para ello es necesario desnudar la
idea original e ir vistiéndola en lanzamientos progresivos.
Dominio simple
En el dominio simple se trata de detectar-categorizar-responder.
Tu dominio es simple si:
Respondes a hechos categorizados con prácticas ya establecidas.
Tu entorno es estable y probablemente no cambiará.
Las relaciones causa-efecto son muy claras para todos los miembros de la organización y el
entorno.
Tienes que explorar para aprender sobre un problema, luego inspeccionar y, por último, realizar
la adaptación.
Aunque se pueden solucionar estos problemas usando
Scrum, un enfoque más práctico y sencillo sería establecer
procesos fijos y basar la gestión en ellos.
B
B A
A
Dominio caótico A
B
B
Dominio complejo
B
B
A
Su máxima es sondear-detectar-responder.
Sabes si te encuentras este dominio si te encuentras con lo siguiente:
Tienes que explorar para aprender sobre un problema, luego inspeccionar y, por
último, realizar la adaptación.
Necesitas ser creativo e innovador.
Tienes que crear modos de experimentación a prueba de fracasos para descubrir
patrones.
Necesitas altos niveles de interacción y comunicación.
Tienes que esperar a fases posteriores a los lanzamientos para saber cualquier resultado.
Más cosas impredecibles que predecibles.
Dominio complicado
A
B
El Scrum es
Ligero
Fácil de entender
Eventos
Elementos o artefactos
Reglas Sirven para agrupar los eventos, roles y elementos, gestionando
y regulando las interacciones que tienen lugar entre estos.
Eventos
Equipos Scrum
La teoría de Scrum
Scrum se fundamenta como una teoría de control empírico.
01 Transparencia
02 Inspección
03 Adaptación
Transparencia
Los aspectos significativos de cada proceso deben ser visibles
para los responsables del resultado del mismo.
La transparencia requiere que esos aspectos
sean definidos elaborando estándares comunes,
de manera que los observadores tengan un
entendimiento común de lo que se está viendo
en cada momento.
Por ejemplo, todos los participantes deben
compartir un lenguaje común de referencia y
aquellos que se encarguen de realizar el trabajo
deben tener una definición común de lo que se
considera trabajo realizado.
Inspección
Los usuarios de Scrum deben frecuentemente inspeccionar los
elementos y progresar hacia el objetivo de la interacción para
detectar aquellas variaciones que ocurran.
Eso sí, la inspección no debe ser tan frecuente
como para que entorpezca el trabajo. Cuando
más beneficiosas son las inspecciones es
cuando son realizadas por inspectores
cualificados en el punto de trabajo.
Adaptación
Si un inspector determina que uno o más aspectos del proceso se están desviando fuera
de los límites aceptables y que el producto resultante sería, por tanto, inaceptable, este
proceso o el material que esté siendo procesado debe ser ajustado. Cualquier ajuste
debe realizarse lo antes posible para minimizar estas desviaciones no deseadas.
En Scrum hablamos de cuatro eventos formales para la inspección y la
adaptación.
Estos serían los ya mencionados:
Valores de Scrum
Todo trabajo realizado en el marco de Scrum necesita
una serie de valores que servirán como fundamento para
los procesos e iteraciones. El equipo, mediante la
aceptación de tales valores, las hace todavía más
fundamentales para su salud y éxito.
Valentía
Al trabajar juntos como equipo los miembros se sienten
apoyados y tienen más recursos a su disposición. Esto da
a los equipos mayor valentía para aceptar mayores retos.
Franqueza
En Scrum los miembros del equipo le cuentan a los otros
miembros cómo les va, qué obstáculos encuentran y qué
tipo de preocupaciones tienen acerca del desarrollo.
Compromiso
El compromiso con el éxito en Scrum es enorme dado
que con estas metodologías se tiene un gran control
sobre el propio destino de la empresa y del equipo.
Respeto
A medida que se trabaja juntos, compartiendo éxitos y
fracasos, las personas terminan por respetarse unos a otros y
se ayudan unos a otros a ser merecedores de respeto.
1.2 Gestión Ágil con SCRUM y Kanban
Introducción a los artefactos de SCRUM
https://vimeo.com/326630255/0c0b36f4e4
Volvemos a incidir en el aspecto
general del marco de trabajo de
Scrum, recordándote la gráfica ya
vista anteriormente.
Elementos o artefactos
Eventos
Equipos Scrum
Podemos decir que en Scrum, el
sprint es el esqueleto que sostiene
todo junto. Es por eso que se ve
representado por una flecha ya
que abarca todo el proceso.
Ítems de alta
Todo comienza con la visión de prioridad
Grooming
lo que el product owner o dueño
de producto quiere crear.
Como este cubo puede ser bastante grande,
lo primero que se hace es una actividad
de refinado o grooming (en la cual se
desglosa y prioriza una serie de Ítems de baja
características y funcionalidades) que da
lugar a un product backlog. prioridad
Haz clic sobre cada uno de los elementos mencionados.
Durante la ejecución del sprint se realizan las actividades necesarias para
desarrollar las funcionalidades seleccionadas mediante la ejecución de las
diferentes tareas detalladas en el sprint backlog. También, durante esta
parte del proceso se llevan a cabo reuniones diarias de inspección y
adaptación o inspect-adapt, con las que se monitoriza el progreso, si hay
problemas que impiden, qué se está haciendo para progresar en el
proyecto, etc.
Al concluir la ejecución se elabora un incremento sobre el producto
potencialmente lanzable que será sujeto a dos revisiones de
inspección y adaptación: revisión del sprint y retrospectiva del sprint.
Al principio de cada sprint, el equipo coge un bloque del product backlog y lo descompone para
ver si lo puede ejecutar en un sprint. Si no puede, lo descompone en las unidades que pueda
abarcar, prioriza y el resto lo deja como PBI para otro sprint.
Al concluir la planificación del sprint, el equipo alcanza un compromiso (antiguamente
llamado pronóstico) para entregar lo que se incluye en el sprint.
Los elementos o
artefactos de Scrum
representan trabajo o
valor para dotar de
transparencia y
oportunidades de
inspección y adaptación.
Haz clic sobre cada tipo de PBI para ver su definición y un ejemplo. +
+
+
Que el representante del servicio al cliente pueda
+
Funcionalidad Característica del producto que crear un ticket con una incidencia para registrar y+
añade valor para el cliente. + la petición de soporte técnico de un cliente.
gestionar
Desarrollo que modifica una Que el representante de servicio al cliente quiera que
Cambio funcionalidad para ayudarle a ahora pueda clasificar las incidencias de soporte por
añadir más valor. apellido del cliente en lugar de por número de ticket.
Mejora técnica Trata de realizar una mejora Cambiar a la última versión del software
empleado para gestionar la base de datos.
necesaria en un producto existente.
D etallado E
mergente E
stimado riorizado
Como estamos diciendo durante todo el contenido, el Scrum está orientado a
minimizar todos los esfuerzos y, conocer de antemano detalles sobre un sprint que se
va a realizar dentro de bastante tiempo no es, precisamente, optimizar el esfuerzo.
P
Detallado apropiadamente
Los PBI en los que se va a trabajar próximamente deben tener un tamaño reducido y
contener mucho detalle para saber exactamente lo que hay que hacer y cuánto se va a
tardar. Los PBI más grandes en los que no vayas a trabajar durante un tiempo deben
permanecer más abajo en la lista de prioridades.
Emergente
Mientras haya un producto que esté siendo desarrollado o mantenido, el product
backlog nunca está completo ni parado, sino que se actualiza constantemente
basándonos en un flujo de información de valor que no cesa. Por poner un ejemplo, los
clientes pueden cambiar de opinión acerca de lo que quieren, la competencia puede adoptar
estrategias no esperadas, etc. Precisamente el product backlog tiene como finalidad capacitar
al equipo para adaptarse a estas circunstancias.
Estimado
Cada PBI debe tener una estimación de tamaño equivalente al esfuerzo necesitado para
desarrollarlo. Es el product owner quien usa estas estimaciones como uno de los factores a
tener en cuenta en la priorización de cada PBI.
Las estimaciones de PBI se realizan en días o en puntos de historia. Las estimaciones
deben ser razonablemente exactas, pero no perfectas.
En el caso de los grandes PBI en la base del product backlog, no siempre es posible realizar una
estimación numérica, con lo que en ocasiones se les otorga tamaños como si fueran una
camiseta (L, XL, XXL, etc.). Posteriormente, según se acerque su momento, se irán desglosando
estos PBI y se realizarán estimaciones más cercanas a la realidad.
Priorizado
Solamente será necesario priorizar los PBI pertenecientes a sprints cercanos en el tiempo,
ya que aunque el product backlog sea precisamente una lista priorizada de ítems, va contra la
filosofía Scrum el realizar una priorización exacta desde un principio.
Grooming
Para un buen product El grooming es, por definición, un conjunto
backlog consistente con de tres actividades principales:
los principios DEEP, debes
gestionar, organizar y Crear y refinar (añadir detalles) a los PBI
administrar de manera
Estimar el tamaño de los PBI
proactiva los PBI.
Priorizar los PBI
PBI Tamaño
Haz clic sobre En el momento adecuado,
cada concepto 3 Estimar tendrás que estimar cada
marcado en rosa. PBI para determinar el
orden en tu backlog y para
ayudarte a decidir si es
necesario o no más trabajo
Claro que, si Repriorizar de refinamiento.
las prioridades
ítems
cambian, Inserta Además, a medida que
reordenarás tu r ítem consigas obtener más
backlog. información, crearás
nuevos PBI que insertarás
en el product backlog en
originalmente el orden pertinente.
grande
Ítem
hace hace el Durante el desarrollo de producto, el product owner se reúne con los stakeholders
grooming? (interesados tanto internos como externos de la empresa) para realizar actividades
de grooming con la frecuencia que estimen conveniente.
No existe una regla Mientras trabaja con el equipo de desarrollo, el product owner puede mantener talleres
fija acerca de de grooming, bien semanalmente o bien una vez por sprint. Esto garantiza que el
grooming ocurre de manera regular y monitorizar el tiempo invertido en esta actividad.
cuándo, ni cuántas
veces durante el A veces, los equipos prefieren reunirse varias veces para refinar
proyecto se debe durante el sprint, en lugar de seleccionar un tiempo predeterminado.
realizar esta
actividad. No Aun cuando existen talleres fijados para realizar grooming, la mayoría de los equipos
obstante, te realizan esta actividad de manera natural como parte de la revisión del sprint.
planteamos algunas
posibilidades. No siempre tienen que estar todos los miembros del equipo para
hacer grooming, sino los necesarios en cada momento.
Algo antes de empezar y
luego cuando se necesite.
Después
Talleres durante del daily .
el sprint.
Durante la revisión
del sprint.
Como muestra,
Steve Jobs te
cuenta en este
vídeo cómo lo
hacían en
Apple.
https://youtu.be/NO7QFnGK3qs
Cuando el ítem
está “preparado”
El resultado de refinar los ítems del backlog de producto es
una serie de ítems en las posiciones más altas que están
Grooming
listos para entrar en sprint. Y tienen que estar preparados
porque, solo de esa manera, el equipo de desarrollo
puede comprometerse y completarlo al final del sprint.
Product
Backlog
Definición de Haz
“preparado”
clic
aquí
El equipo de desarrollo entiende, de manera suficiente, los detalles del ítem como
para decidir razonablemente si lo puede completar.
Flujo de lanzamientos
Estaría bien: se trata de funcionalidades que te
gustaría incluir en el siguiente lanzamiento, pero que en
Se trata de un conceptocaso de escasez
importante de recursos
que va a guiar (dinero,Atiempo,
nuestros esfuerzos. etc.)
medida que
podrásirás
trabajes en tu product backlog prescindir
refinando y de ellas y, aun
desglosando así,
nuevos tener un producto.
PBI.
Los sprints tienen que tener una fecha fija de inicio y otra de fin y,
generalmente, todos los sprints de un proyecto tienen la misma duración.
Cada sprint comienza justo después de acabar el sprint anterior. Como norma general el sprint
no se interrumpe con cambios que puedan alterar el alcance o el personal de un sprint.
Timebox tipo de los
Sprint
eventos de Scrum
2 semanas 3 semanas 4 semanas
Duración máxima de la reunión en horas
4 6 8
2 3 4
1,5 2,25 3
15 min. a diario
Planificación del sprint
Para determinar los ítems más
importantes que se tienen que desarrollar
en el siguiente sprint, el product owner
junto al scrum master y el equipo de
desarrollo planifican el sprint.
Objetivo del sprint
A medida que se planifica el sprint,
se decide un objetivo que es lo
que define lo que el siguiente
sprint debe conseguir.
Velocidad sostenible
Con el objetivo del sprint en mente, el equipo de
desarrollo revisa el backlog de producto y determina los
ítems de alta prioridad que el equipo puede conseguir
de manera realista en el siguiente sprint, trabajando a
una velocidad a la que el equipo se encuentre
cómodo durante un periodo extendido de tiempo.
Sprint backlog
El sprint backlog es una recopilación de las
tareas de las que se compone un sprint.
Esto se realiza para ganar confianza sobre el cumplimiento de los
objetivos dentro de plazo y, para ello, se divide el objetivo del sprint
en diferentes tareas, asociándolas al ítem que se está tratando de
desarrollar.
El equipo de desarrollo, una vez vistas las tareas, estima las
horas de esfuerzo requeridas para completar cada tarea.
Just-in-time
Esta filosofía de dividir los ítems en tareas facilita el diseño
"justo a tiempo", en el que las diferentes funcionalidades
se abordan justo cuando son requeridas.
La mayoría de los equipos Scrum que realizan sprints de entre dos
semanas y un mes de duración tratan de realizar la planificación del sprint
en entre 4 y 8 horas. Un sprint de una semana de duración no debería
llevar más de 2 horas de planificación.
Al dividir en tareas, el equipo estima la duración y se van añadiendo,
estas tareas, a medida que el equipo disponga de horas hasta que se
llegue al tope de capacidad del equipo.
Incremento de producto
Un incremento es la suma de todos los ítems del product
backlog completados durante un sprint junto al valor de
los incrementos de los sprints anteriores.
Al finalizar un sprint, el nuevo incremento debe estar "terminado o
hecho", lo que significa que debe estar en condiciones de ser usado,
independientemente de si el product owner decide lanzarlo o no.
Definición de hecho
Definition of Done (DoD)
Cuando un ítem de product backlog se describe NIVEL DE COMPRENSIÓN
MÁXIMO
como terminado, todos los miembros del
equipo deben entender lo que esto significa.
A pesar de todos sus beneficios, las historias de usuario no son la única manera de
representar un ítem de product backlog. Son un primer enfoque, un referente que sirve
como eje central de toda la otra información relevante y útil para detallar un requisito.
Elementos
de las historias
de usuario
01 Tarjetas
02 Conversaciones
03 Confirmación
T
Independent (independiente)
Las historias deben ser lo más independientes posibles unas de otras, dado que cuanto más
interdependientes sean de otras, más difícil será la priorización y la estimación. Imagina, si tienes
que mover en vez de una historia cinco en el orden de prioridades porque unas necesitan de otras será
más complicado, ya que debes conseguir estimar la duración de cinco sprints en lugar de uno.
Negotiable (negociable)
Las historias, aunque muchos piensen lo contrario, no son como los requisitos formales de un proyecto
en cascada, inamovibles y a las que se debe ceñir el equipo del proyecto sí o sí. En Scrum las
historias son puntos de referencia para conversaciones en las que se acordarán los diferentes
detalles.
Testable (testeable)
Las historias deben tener un sistema de testeo final binario, es decir, apto/no apto.
Esto va muy relacionado con el tamaño de la historia. Si una historia es muy grande,
probablemente no podremos someterla a este tipo de testeo. En el ejemplo que citábamos antes
de la red social, si el sistema reconoce archivos protegidos por DRM, acepta archivos hasta 1 giga,
pero no más y acepta las extensiones detalladas, sería apto y de lo contrario no apto.
Proceso de planificación del sprint
Un lanzamiento normalmente se compone de varios sprints,
cada uno de los cuales añade valor para el cliente.
Cada sprint comienza con la planificación del sprint.
Momento en el cual, el equipo Scrum se reúne para
acordar una meta del sprint y determinar, a su vez,
qué es lo que el equipo puede entregar durante el
sprint que está por comenzar, esto es, los PBI
específicos que estén alineados con la meta del scrum
y que pueden ser entregados de manera realista.
4-8h.
PRODUCT OWNER
Propietario del producto
Comparte la meta inicial del sprint, presenta un product backlog
priorizado y responde cualquier pregunta que pueda hacer el equipo
¿Quién
acerca de los PBI.
SCRUM MASTER
Scrum máster
Observa la actividad de planificación, realizando preguntas
profundas y actúa como facilitador para asegurarse que el resultado
es exitoso. No es el encargado del equipo de desarrollo, no puede
decidir en su nombre el compromiso que se ha de adquirir, pero sí
puede retar el compromiso para asegurarse que es realista y apropiado.
Para hacer la planificación de tus sprint, vas a necesitar una
serie de entradas sobre las que decidirás:
Cuántos sprint
del equipo
cuánto trabajo puede completar en un
sprint de duración determinada.
Refinar
objetivo Ajustar
del sprint Pronóstico
Determinar la capacidad
y velocidad del equipo
Como acabas de ver, determinar la capacidad del equipo es el primer paso de
planificación del sprint. Es por esto que debes hacerlo muy bien.
El equipo debe reservar un 10% del tiempo para ayudar en las tareas de grooming del product backlog.
Dedicar tiempo a otras tareas fuera del sprint, tales como mantener productos actuales o trabajar en otros proyectos.
Los miembros de los equipos necesitan un tiempo al día para ser buenos
compañeros: ir a reuniones, responder emails, ser interrumpidos, etc.
Otras consideraciones como horas necesitadas por miembros del equipo para asuntos personales deben tenerse en cuenta.
Y, por último, un "colchón" de tiempo para prever por si las cosas no salen según lo planeado es necesario.
Capacidad
total del sprint
La cantidad restante de todo esto Capacidad
es la capacidad que realmente
Para trabajar sobre los items del
tendrá el equipo para trabajar en
product backlog durante el sprint.
los PBI incluidos en el sprint.
Colchón
Otros compromisos
No relacionados con el sprint: soporte,
mantenimento y otros proyectos.
Puedes, por tanto, en este sentido saber cuánto tiempo te llevarán las tareas que
incluyas en un sprint porque podrás incluir una serie de tareas que sumen la
cantidad de horas que tiene disponible tu equipo.
Esto es lo que se llama cálculo de la capacidad del equipo en horas de
esfuerzo.
Medir la capacidad en
puntos historia o story points
Los puntos historia son una unidad de medida
para estimar el esfuerzo necesario para
implementar un PBI.
Al realizar estimaciones con puntos historia, se asigna a
cada PBI un valor numérico. Los valores en sí no son lo más
relevante, sino la relación entre los diferentes valores
asignados a los diferentes PBI, es decir, su relatividad. Que
decidas otorgar valores de 1, 2 o 3 es lo mismo que si asignas
valores de 100, 200 o 300.
Lo realmente importante que tienes que saber acerca
de los puntos historia es qué variables incluyes en el
cálculo de los mismos.
Concretamente son 3.
1. Cantidad de trabajo a realizar
2. Complejidad
3. Riesgo o incertidumbre
1. Cantidad de trabajo a realizar
Si hay más que hacer para desarrollar un ítem que otro, con seguridad la
puntuación será más alta. Eso sí, como vamos a ver a continuación, la
diferencia de cantidad de trabajo no va a multiplicar directamente, sino que se
verá afectada por la complejidad.
Ahora tienes también una web con cien campos de diferente naturaleza:
Algunos incluyen widgets de calendario, otras son celdas preformateadas para introducir DNI o número de
teléfono. Además, la web exige que existan interacciones entre los campos.
Si por ejemplo, el usuario dice ser de nacionalidad extranjera el campo DNI le pedirá una letra, siete números
y otra letra, mientras que si es español le pedirá ocho números y una letra.
Existen, obviamente, en este caso muchas más probabilidades de que el programador se equivoque y tenga
que retroceder a corregirlo.
Esta complejidad extra debe ser reflejada.
3. Riesgo e incertidumbre
El riesgo y la incertidumbre que afectan a
cada PBI deben ser incluidos a la hora de
realizar las estimaciones de puntos historia.
Haz clic sobre cada uno de los elementos para tener más información.
Descripción del proceso
Haz clic sobre cada una de las partes del
proceso para tener una breve descripción.
Gestionar el flujo
de trabajo durante Sabes las tareas que tienes que realizar con el sprint
backlog, pero esto no basta, debes saber qué trabajo
la ejecución del se va a comenzar, cuándo se va a comenzar, cómo
sprint es crucial organizar el trabajo y quién lo va a hacer.
para su éxito.
Trabajo a realizar
https://trello.com/
Gráfico de trabajo
pendiente
o Burn down
El gráfico Burn down nos muestra la velocidad a lo largo del
tiempo a la que se está completando los objetivos/requisitos.
De esta manera podremos saber si el equipo podrá acabar el
trabajo en el tiempo estimado.
Podemos
utilizar 2 tipos
de gráficos de
trabajo Haz
pendiente. clicaquí.
Durante cada día de la ejecución del sprint los miembros del equipo actualizan la
estimación de cuánto esfuerzo queda para completar cada tarea que no ha sido
completada todavía.
"Con retraso", que indica que el progreso está siendo peor de lo esperado. Es el peor
de los escenarios posibles, ya que implicaría no llevar a cabo un incremento a tiempo como
resultado del sprint. Puede ser indicador de estimaciones mal realizadas, mala planificación
o pobre previsión de eventualidades.
Tanto el sprint backlog como la gráfica de trabajo pendiente (como indica el
nombre de esta última) solamente muestran el esfuerzo realmente invertido, ya
que en Scrum no existe una razón concreta para capturar los esfuerzos
realizados. De todas maneras, se puede tratar de calcular estas cifras con fines
contables o administrativos.
Gráfico
Burn up
De manera análoga a la gráfica de trabajo pendiente, en Scrum
usamos el burn up chart como manera alternativa para visualizar el
progreso en un sprint. Realmente representa la cantidad de
trabajo completado hacia la consecución del objetivo del sprint.
En esta gráfica
mediremos el
trabajo
realizado en
puntos
historia, ya que
en realidad se
están midiendo
los PBI
terminados
durante el
sprint.
En la gráfica, tenemos tres líneas. El significado de cada leyenda es:
“El OBJETIVO”, es decir, todos los puntos historia previstos por planificar en el sprint.
15 min.
El equipo de desarrollo usa el daily Scrum para
inspeccionar el progreso hacia los objetivos y
para inspeccionar cómo se progresa hacia la
consecución del trabajo que hay en el sprint
backlog. Por tanto, podemos decir que el daily
sprint aumenta las posibilidades de que el equipo
alcance los objetivos.
El scrum master se encarga de que estas
reuniones tengan lugar, pero no participa
activamente en ellas. Es el equipo de desarrollo el
que de manera autoorganizada, coordina y dirige
estas reuniones. Por otra parte, el scrum master
es el que enseña al equipo a mantener estas
reuniones dentro del tiempo limitado de 15
minutos.
15 min.
Beneficios
de hacer
Mejoran la comunicación.
Eliminan la necesidad de
mantener otras reuniones.
Identifican rápidamente
impedimentos para poderlos eliminar.
15 min.
Las tres preguntas diarias
En la reunión, con el Scrum master como facilitador, cada
miembro del equipo Scrum responde a las siguientes tres
preguntas:
15 min.
Existirán debates acerca de las diferentes cuestiones que surjan dentro
de estas tres preguntas y conviene que esto ocurra, pero debe suceder
después de la reunión diaria para asegurarse de que esta sea corta.
15 min.
Si un programador dice "hoy, terminaré el módulo
de almacenamiento de datos", todos sabrán que
en la reunión del día siguiente dirá si lo ha
acabado o no. Esto tiene el maravilloso efecto de
ayudar al equipo a darse cuenta del significado de
estos compromisos y, sobre todo, que se están
comprometiendo con los compañeros del equipo y no
con algún cliente o vendedor que está lejano en el
horizonte temporal.
Los impedimentos que surjan en la reunión tienen
que ser resueltos por el Scrum master tan pronto
como sea posible.
15 min.
Los impedimentos más típicos son:
Se me ha roto el ___________ y necesito uno nuevo hoy.
Todavía no tengo el software que pedí hace un mes.
Necesito ayuda resolviendo el problema ____________.
Me está costando aprender ______________ y me gustaría
que me emparejaran con alguien en ese campo.
No puedo contactar con el soporte técnico del proveedor.
Nuestro nuevo contratista no puede empezar porque no hay
nadie aquí para firmar el contrato.
El grupo _________ no me concede una reunión que necesito
mantener con ellos.
El subdirector de mi departamento me ha pedido que trabaje
en otra cosa "durante un día o dos".
En los casos en los que el Scrum master no pueda eliminar los
impedimentos él mismo (esto suele ocurrir cuando se trata de impedimentos
de complejidad técnica elevada) asume la responsabilidad de encontrar la
persona que lo pueda resolver y asegurarse de que lo hace.
La gran mayoría de los equipos comienzan la reunión con un miembro
respondiendo a las tres preguntas, luego otro, etc.
Una alternativa interesante es hablar sobre los diferentes PBI durante la
reunión.
De esta manera cada miembro del equipo puede dar información a sus
compañeros varias veces durante una reunión.
15 min.
Vídeo. Un daily meeting en Google.
15 min. https://youtu.be/78EDC9oAelY
4.1.1. Reunión diaria (7)
El lugar de
la reunión
Lo ideal es que los equipos se hallen en la
misma localización física. Comúnmente se
llama a esta zona, Habitación de Guerra.
Normalmente, se diseña de manera que los miembros del
equipo se puedan mover libremente, además de trabajar y
comunicarse con facilidad al colocarles cerca unos de otros.
Se provee al equipo de herramientas manuales y poco
tecnológicas para facilitar el flujo de trabajo, la colaboración
y la resolución de problemas. Estas herramientas incluyen
tarjetas, notas autoadhesivas, tableros, etc.
Esta estancia a menudo es ruidosa debido a las
conversaciones de los equipos, pero lo cierto es que
estas conversaciones contribuyen mucho al progreso
del equipo. Una buena Habitación de Guerra carece
de limitaciones espaciales (cubículos y despachos) y
permite que el equipo se siente junto para que pueda
tener lugar mucha comunicación cara a cara, lo que
hace que se consolide el equipo y haya transparencia.
15 min.
Características de un
buen daily meeting
Tiene lugar por la mañana.
¿Por qué?
Si el propósito del daily meeting es sentar los objetivos del día, no tendría realmente sentido
hacerlo en otro momento, ni siquiera a última hora para cerrar el trabajo del día siguiente porque
el compromiso se diluye de un día para otro.
El daily meeting trata de hacer un compromiso de lo que voy a hacer hoy y de lo que rendiré
cuentas mañana, no de lo que haré mañana y rendiré cuentas al final del día. Parece lo mismo,
pero no lo es.
Ayuda a comunicar qué está pasando
El dueño de producto explica qué PBI se han terminado y qué PBI no se han
terminado.
El equipo de desarrollo explica lo que fue bien durante el sprint, qué problemas
se encontraron y cómo se resolvieron esos problemas.
Participantes
En el sprint review el equipo Scrum consigue valioso
feedback de personas que no están con el equipo
durante la ejecución de manera diaria.
Para estas personas la revisión del sprint es la primera oportunidad que
tienen para ver y hablar sobre el trabajo que se ha producido durante el
sprint. Por lo tanto, la revisión debe ser atendida por todas las partes
interesadas, las cuales pueden venir de muchas fuentes.
Citamos en la tabla resumen las principales fuentes:
01 02 03 04
4.1.2. Revisión del sprint (4)
Preparación de la reunión
Aunque la reunión de revisión del sprint es informal, el equipo
Scrum debe llevar a cabo cierto grado de preparación.
Para preparar la reunión, el equipo debe:
02 Programar la actividad.
La revisión debe ser programada, es decir, se debe saber cuándo, dónde y
cuánto durará la reunión. De todas las reuniones relacionadas con el sprint, la
revisión es la más difícil de programar porque incluye a muchas personas
de fuera del equipo Scrum.
La mayoría de los equipos hacen algo de grooming durante la revisión de sprint. Dado que
todos los participantes aumentan la comprensión sobre el esfuerzo de desarrollo y su rumbo con
frecuencia de estas reuniones se sale con nuevos PBI o con antiguos PBI eliminados o re
priorizados. Esto afectará a cómo trabajará el equipo en el siguiente sprint.
La revisión de sprint también es posible que cambie otros factores pertenecientes al marco
más amplio del proyecto. Basándose en las conclusiones obtenidas de una revisión de sprint el
dueño de producto puede decidir alterar una de las variables claves de la planificación del
lanzamiento: alcance, fecha o presupuesto. Si por ejemplo, se decide dejar de trabajar en una
funcionalidad considerada hasta el momento clave para el producto, se estaría cambiando el
alcance.
Retrospectiva de sprint
La retrospectiva de sprint es una oportunidad para que el
equipo Scrum pueda inspeccionarse a sí mismo y
pueda crear un plan de mejoras a implementar en el
siguiente sprint.
La retrospectiva de sprint ocurre después de la revisión de sprint
y antes de la siguiente planificación de sprint y debe tener una
duración de entre 3 y 4 horas en el caso de sprints de un mes.
El scrum master debe asegurar que la reunión tenga lugar y que los
participantes entiendan su cometido y les instruye sobre cómo ceñirse
al tiempo estipulado. En esta reunión el Scrum master participa como
un miembro más como responsable del proceso Scrum.
1,5-3h.
El objetivo de la
retrospectiva de sprint es:
El Scrum master anima al equipo a mejorar dentro del marco de trabajo de procesos Scrum,
su proceso de desarrollo y las prácticas que pueden hacer Scrum más efectivo y placentero
para el siguiente sprint.
Durante cada retrospectiva de sprint se planifican modos de mejorar la calidad
del producto adaptando la definición de "terminado" según convenga.
Al final de cada retrospectiva, el equipo Scrum debe haber identificado mejoras para
implementar en el siguiente sprint. Implementar estas mejoras es la adaptación de la
inspección del equipo Scrum en sí mismo.
Aunque las mejoras pueden implementarse en cualquier momento, la
retrospectiva plantea una oportunidad formal para centrarse en la inspección y
la adaptación.
La retrospectiva del sprint da a todo el equipo una
oportunidad para pararse y pensar.
Dentro de este marco los equipos pueden:
Otros
La retrospectiva de Sprint es una de las prácticas más importantes,
pero menos apreciadas, en el marco de trabajo de Scrum:
Se infravalora
Es importante porque los
porque da a los equipos piensan
equipos la que les roba
oportunidad de tiempo de trabajo
adaptarse a sus real, es decir, de
circunstancias desarrollo,
únicas. construcción y
testeo.
Dado que el equipo Scrum se reúne al final de cada Sprint para inspeccionar y adaptar el
proceso Scrum, puede aplicar lecciones aprendidas desde muy pronto dentro del proceso
de desarrollo y, por lo tanto, alterar de manera significativa el resultado del proyecto.
De manera muy sencilla una retrospectiva de Scrum tiene como
objetivo que los miembros del equipo se reúnan y debatan sobre
cuestiones tales como:
¿Qué ha funcionado bien durante este sprint y,
por lo tanto, continuaremos haciendo?
¿Qué no ha funcionado y vamos a dejar de hacer?
De cualquier modo, hay ocasiones en las que un equipo decide centrarse en lo que
actualmente es crucial para el equipo y donde las mejoras son más necesarias, como
por ejemplo:
Centrarse en cómo mejorar las habilidades del equipo con desarrollo guiado por pruebas.
Centrarse en porque con frecuencia se construye en lo que se cree que el cliente
quiere, pero el cliente cree que no se ha entendido bien sus deseos o que se han pasado
por alto aspectos importantes de los requisitos.
Establecer y comunicar el centro de la reunión antes de la retrospectiva permite que el
equipo Scrum determine tres cosas:
Si es necesario invitar miembros del equipo no relacionados con Scrum.
Seleccionar los ejercicios adecuados.
Preparar la información necesaria para asegurar que la reunión es fluida.
4.1.3. Retrospectiva de sprint (9)
Cierre de la
retrospectiva
Una vez que se determinan las acciones de
mejora, los participantes cierran la retrospectiva.
Frecuentemente, se cierra recapitulando qué
acciones ha decidido tomar el equipo, basándose
en lo que han aprendido los participantes. Esto
puede ser algo tan sencillo cómo describir el
compromiso con cada acción y quién va a
trabajar en ello.
Moralmente, el cierre es un
momento excelente para
agradecer a todos por su
trabajo y participación. Cada
participante debe expresar unas
palabras de reconocimiento de
las aportaciones realizadas por
los demás participantes.
Finalmente, es una buena idea
emplear unos minutos pidiendo
al equipo que realicen
sugerencias sobre cómo se
podrían mejorar las futuras
retrospectivas. La retrospectiva
es, después de todo, parte del
marco de trabajo Scrum y, como
tal, debe ser objeto de inspección
y adaptación.
Introducción a equipo SCRUM
https://vimeo.com/326546030/b046a30092
Los roles en la
metodología Scrum
Por las características
de las herramientas y
las diferentes fases
de Scrum podemos
hablar de
roles
del equipo
SCRUM
Equipo de
desarrollo o
Development
team
Propietario del
producto o Grupo de personas que tiene
Product owner
Scrum
como cometido realizar las
tareas necesarias en las
Este rol es el último
responsable de que todos
que se dividen las historias
de usuarios. La gran
Master
los incrementos añadan diferencia con respecto a los
valor al producto conforme equipos tradicionales es que Es una figura que tiene como
a las necesidades de los tiene que componerse de finalidad asegurarse que se
clientes, usuarios y miembros multidisciplinares y cumplen los preceptos de
stakeholders internos. autoorganizados. la metodología Scrum.
Propietario
del producto o
Product owner
El dueño de producto
es la persona con
más poder y
responsabilidad en
cuanto al liderazgo
del producto.
Introducción El product owner tiene que estar, constantemente, mirando en
Propietario del dos direcciones, la de su propio equipo scrum, por un lado y, la
producto o de los stakeholders por otro, quienes están formados por:
Product owner
Otras personas de la
Stakeholders empresa como dueños,
internos gerentes, directivos, etc.
Internos Scrum
de la empresa Master
Propietario
del producto o
Product owner
Externos
Clientes/usuarios
Equipo de desarrollo o
Development team
Propietario del
producto o
Product owner
Propietario del
producto o El dueño de producto es el responsable de la toma
Product owner de buenas decisiones económicas de manera
constante a nivel de:
Lanzamiento
Sprint
Product backlog
Responsabilidades Gestión económica Lanzamiento
Propietario del
producto o
Product owner ¿Qué harías?
Podrías llegar a la lógica conclusión que realizar una entrega
temprana es económicamente más razonable que continuar con el
plan para diez sprints.
Esta flexibilidad para realizar entregas tempranas, solo tienen lugar si
consigues que se trabaje, primeramente, en los valores de alto valor
en la parte alta del product backlog y que en cada sprint, el equipo
está completando el trabajo de acuerdo con una sólida definición de
"terminado".
Responsabilidades Gestión económica Lanzamiento
Propietario del
producto o Gestionar la economía de cada sprint consiste en
Product owner asegurarse de que existe un retorno de la inversión
suficiente de cada sprint. Los buenos dueños de producto
emplean el dinero de la empresa como si fuese suyo.
En la mayoría de los casos el product owner conoce el coste del
siguiente sprint, ya que conoce la duración del mismo y el equipo que lo
va a llevar a cabo.
Como dueño de producto, piensa: ¿extendería un talón desde mi
cuenta bancaria equivalente al coste del sprint para obtener las
funcionalidades que se van a desarrollar? Si la respuesta es no,
probablemente tampoco deberías gastarte el dinero de la empresa.
Responsabilidades Gestión económica Product backlog
Propietario del
producto o
Product owner El dueño de producto es la voz de los stakeholders, tanto
internos como externos. Debe trabajar con ellos de
manera cercana y constante, para guiar al equipo
facilitando información sintetizada y una visión
coherente del desarrollo de producto.
Propietario
del producto o
Product owner Características
¡Vamos a ver cada Habilidades técnicas
una de ellas!
Habilidades interpersonales
Toma de decisiones
Responsabilidad
Características Habilidades técnicas
Debe ser la "voz del cliente“. Esto requiere tener una buena
relación con los stakeholders.
Propietario del
producto o Buen negociador y ayudar a alcanzar consensos.
Product owner Es el enlace entre los stakeholders y el resto del equipo Scrum,
por lo que es necesario que tenga habilidades
comunicativas.
Un buen comunicador tiene las siguientes habilidades:
❖ Está dispuesto a hablar, incluso, si hacerlo va en contra del status quo.
❖ Confía en sus ideas.
❖ Conoce los temas de los que habla.
❖ Es capaz de comunicarse de una manera simple, concisa y fácil de
entender.
❖ Tiene credibilidad.
Scrum
Master
Protege al equipo de desarrollo de las interferencias y
distracciones externas para que sus miembros puedan
centrarse en añadir valor de negocio a cada sprint.
La interferencia puede venir de numerosas fuentes: encargados que
quieren reorientar a miembros del equipo durante un sprint, a asuntos que
surgen en otros equipos, etc.
Independientemente de la fuente, el Scrum master actúa
como interceptor (investigación, gestión y arbitraje) para que
el equipo pueda concentrarse en crear valor.
Responsabilidades Eliminar obstáculos
Conjunto de personas
más “técnicas” que de
manera conjunta
desarrollan el producto
del proyecto.
Equipo de
desarrollo o
Development
team Responsabilidades
¡Vamos a ver cada Realizar la ejecución del sprint
una de ellas! Inspeccionar y adaptar cada día
Planificare el sprint
Equipo de
desarrollo o
Development Sprint
team Durante la ejecución del sprint los miembros del equipo de
desarrollo realizan el trabajo de diseño, creatividad,
construcción, integración y testeo de los PBI. El equipo de
desarrollo invierte la mayor parte de su tiempo en este
proceso.
Responsabilidades Inspeccionar y adaptar cada día
Equipo de
desarrollo o Cada miembro del equipo de desarrollo debe participar
Development en las reuniones de daily Scrum, en la cual, los miembros
team de manera colectiva inspeccionan el progreso hacia el
objetivo del sprint y adaptan el plan para el día de trabajo.
Si algunos miembros del equipo no participan, el equipo
puede perderse fragmentos del mapa de desarrollo y esto
puede hacer que no cumplan el objetivo del sprint.
Responsabilidades Grooming del product backlog
Equipo de
desarrollo o
Development Una porción de cada sprint se emplea en prepararse para
el siguiente sprint. Gran parte de esta preparación implica
team realizar las actividades de grooming. El equipo debe apartar
un 10% de su tiempo para asistir al dueño de producto en
estas actividades.
Responsabilidades Planificar el sprint
Equipo de
desarrollo o Junto al propietario de producto y el Scrum master, el equipo
Development de desarrollo participa en la planificación del sprint.
team
Responsabilidades Inspeccionar y adaptar
procesos y productos
Equipo de
desarrollo o Los equipos de desarrollo también participan en las dos
Development
actividades de inspección y adaptación posteriores al sprint:
team revisión y retrospectiva.
Equipo de
desarrollo o
Development
team Características
¡Vamos a ver cada Autoorganizado
Habilidades en forma de T
Actitud de mosquetero
Comunicación transparente
Tamaño adecuado
Centrado y comprometido
Equipo de Esto quiere decir que lo que muestre la información debe proporcionar una
información clara de lo que esté ocurriendo, para evitar sorpresas y aumentar
desarrollo o el nivel de confianza entre los miembros del equipo Scrum y los stakeholders.
Development
team
Características Tamaño adecuado
“Debemos escaparnos de la
forma 'normal' de pensar”.
Salir del círculo de confort es
fundamental para encontrar
soluciones, Albert Einstein ya lo
comentó en su día:
“Si buscas resultados
distintos no hagas
siempre lo mismo”.
Volvámonos niños, repliquemos su capacidad
de desechar un juguete para jugar con la caja.
No empezamos el viaje solos, el Design Thinking
será nuestro guía. General Electric,
Procter&Gamble y Philips Electronics son algunas de
las marcas que tienen interiorizada esta herramienta
en sus procesos de trabajo e incorporan este
concepto en las rutinas de fabricación de sus
productos.
“El problema de competir como un
loco es que, incluso si ganas, sigues
siendo un loco.”
Lily Tomlin.
¿Qué es Design Thinking?
El pensamiento en modo crisis debe cambiarse
Una de las propuestas básicas que ofrece el Design Thinking es enfocar los desafíos
desde un nivel sistemático. Cuando una situación complicada nos rodea es fácil que las
decisiones que tomamos sean equivocadas, pero eso también es fruto del modo en que
hemos gestionado los problemas anteriormente, ya que se pautaba como primordial
reaccionar, en vez de actuar proactivamente o estar a la defensiva en vez de a la ofensiva.
Dicha situación afecta a la gestión, ya que se
incita y se trabaja por y para el fomento de la
creatividad, pero queda en un segundo plano
la formación indispensable para la disminución
de los errores y riesgos innecesarios.
De la misma manera que los precursores del movimiento
modernista admitieron la necesidad de nuevas concepciones
de diseño para adaptarse al progreso tecnológico del siglo XX,
debemos nosotros en la actualidad estar receptivos a otros
cambios y, poder así, reconocer cuando surge la
necesidad de crear nuevos conceptos administrativos que
se adapten al siglo XXI.
Crisis
No pretendemos que las cosas cambien, si
siempre hacemos lo mismo. La crisis es la mejor
bendición que puede sucederle a las personas y
países, porque la crisis trae progresos, la
creatividad nace de la angustia como el día de la
noche oscura. Es de la crisis que nacen la inventiva,
los descubrimientos y las grandes estrategias. Quien
supera la crisis se supera a si mismo sin quedar
superado.
DO I T
existentes, reforzando y aportando vigor a un negocio sin reinventarlo necesariamente.
Construir prototipos.
De las ideas más prometedoras.
Design thinking es:
▪ Un medio para resolver problemas complejos.
▪ Un marco donde equilibrar las necesidades y la factibilidad.
▪ Un enfoque a la resolución de problemas que los aborda en el nivel sistemático.
▪ Una cultura que fomenta la exploración y la experimentación.
▪ Un paradigma conceptual para la curiosidad y la investigación.
▪ Un enfoque sobre la resolución colectiva de problemas.
▪ Un proceso fijo y un conjunto de herramientas.
▪ Una manera de superar los retos del diseño mediante la aplicación de la empatía.
▪ No es una palabra de moda que usan los diseñadores para sugerir que pueden hacer algo más que
▪ Tampoco
diseñar. una expresión de moda que venden los directivos como la próxima herramienta de estrategia.
Es de vital importancia mencionar que el diseño está ligado por haberse inspirado, en
ocasiones, en disciplinas científicas y, más en concreto, por las ciencias naturales.
Cuando el Design Thinking se aplica en el entorno empresarial, ayuda a las personas que
están en él a identificar, comprender y analizar su competencia y entorno operativo.
“Los analfabetos del siglo XXI no serán los que no sepan leer y escribir,
sino quienes no sepan aprender, desaprender y volver a aprender.”
Alvin Toffler.
Principios de Design Thinking
Introducción
La humanidad, gracias a su facilidad para trabajar en cooperación, mostrar
empatía, comunicarse y tener la capacidad de prever y comprender, ha
trabajado de manera óptima.
Como reflejo de esas capacidades surge esta nueva filosofía, de ahí que la cultura, los
principios y procesos provenientes de las praxis mencionadas, sean potencialmente
más empáticas, antropocéntricas y valientes que la gestión empresarial.
Los principios inherentes al Design Thinking han sido influidos por el enfoque
multifuncional y de diversas perspectivas a la hora de resolver los problemas.
Por eso, cobra sentido introducirlo en la empresa con la finalidad de influir en nuestros
valores esenciales y formas de ver el mundo. En este punto, se debe destacar la importancia
de que todo aquel que lo vaya a utilizar o implantar necesita entender, previamente, la necesidad
humana de sentido y conectividad y, luego, actúa en consecuencia.
Uno de los problemas que podemos encontrarnos es que muchos acceden al método como si
fuese algo perfectamente estructurado, ya que “juegas” con procesos fácilmente
predecibles y que pueden repetirse llegando a catalogarlos como algoritmos, pero también
puede incluir enfoques aleatorios para aprovecharse del poder de la intuición.
Por lo anterior y, porque se trata de un concepto relativamente nuevo, hay que adoptarlo con
precaución e integrarlo en las prácticas de gestión tradicionales y, por descontado, no vincularlo
directamente como técnica de marketing o usarlo como excusa, para que las ideas creativas eludan la
crítica basada en un análisis o la lógica empresarial.
Es fundamental que las empresas que lo implanten reconozcan sus
principios clave y lo presenten como instrumento creativo que facilita la
innovación y la transformación.
Los 10 principios del
Design Thinking
01 El Design Thinking está
orientado a la acción.
Propone aplicar un enfoque de “actuar para aprender”
interdisciplinario a la resolución de problemas. Nos permite
tomar en cuenta diversos intereses y capacidades por
medio de experiencias cognoscitivas prácticas, aplicadas
entre los individuos. Buena parte del Design Thinking
consiste en crear diseño.
Supone ensuciarse las manos y experimentar.
02 El Design Thinking está a
gusto con el cambio.
Es disruptivo y provocador por naturaleza porque fomenta
nuevas maneras de abordar los problemas. El
encuadramiento estratégico de problemas complejos y
ambiguos exige un enfoque libre de dogmas organizacionales,
limitaciones codificadas y supuestos caducos.
Una gran parte del proceso de Design Thinking
consiste en salirse de los roles convencionales y
huir de los dogmas existentes, para analizar nuevas
metodologías para resolver problemas.
03 El Design Thinking
es antropocéntrico.
Siempre se centra en las necesidades del
cliente o del usuario final, incluyendo las
inexpresadas, insatisfechas y desconocidas.
Para ello, el Design Thinking emplea diversas
técnicas de investigación basadas en la
observación y la escucha, para informarse
sistemáticamente sobre las necesidades, tareas,
pasos e hitos del proceso de una persona.
04 El Design Thinking
integra la previsión.
La previsión nos abre el futuro y nos invita a explorar las incertidumbres.
Nos anima a sentirnos a gusto trabajando con incógnitas y, espera
de nosotros, que afrontemos una información insuficiente durante el
proceso de descubrir y crear un resultado tangible.
Sin imaginar de forma anticipada y disciplinada el futuro, el
proceso de planificación estratégico no sirve de nada.
05 El Design Thinking es un proceso
constructivo dinámico.
Es interactivo. Exige una definición, redefinición,
representación, evaluación y visualización contantes.
Es una experiencia cognoscitiva constante que surge de la
necesidad de obtener y aplicar nuevas percepciones a los
objetivos cambiantes. Por este motivo, la definición de
prototipos, la creación de artefactos tangibles y compartibles
se convierte en un elemento importante del conjunto de
instrumentos del Design Thinking.
06 El Design Thinking
fomenta la empatía.
Coloca al usuario en el centro de todo.
Fomenta el uso de instrumentos que nos ayuden a
comunicarnos con las personas con objeto de
comprender mejor sus conductas, expectativas,
valores, motivaciones y las necesidades que les
impulsan y que mejorarán sus vidas.
Usamos esta información para desarrollar
nuevos conocimientos por medio del
aprendizaje y la experimentación creativos.
07 El Design Thinking
reduce los riesgos.
Tanto si se trata del desarrollo y el lanzamiento de un nuevo
producto como de un servicio, aprender de los pequeños
fracasos inteligentes, arroja muchos beneficios. Son
cosas que siempre pasarán, pero las prácticas aplicadas del
Design Thinking ayudan a reducir los riesgos al tener en
cuenta todos los factores presentes en el ecosistema de
desarrollo, incluyendo la tecnología, el mercado, la
competencia, los clientes y la cadena de proveedores.
08 El Design Thinking puede
crear significado.
Las presentaciones del PowerPoint y las
hojas de Excel tienen una capacidad
limitada para transmitir visiones o ideas.
Crear significado es la parte más dificultosa del
proceso de diseño, y los instrumentos de
comunicación que se usan en el Design Thinking
(mapas, maquetas, esbozos y relatos) contribuyen a
captar y a expresar la información necesaria
para formar y socializar el significado. Llegar a
este punto requiere su tiempo, y se va forjando por
medio de las múltiples iteraciones y conversaciones.
09 El Design Thinking puede llevar la creatividad
empresarial al siguiente nivel.
Fomenta una cultura que valora los cuestionamientos, inspira la reflexión frecuente mientras
se actúa, celebra la creatividad, acepta la ambigüedad y crea significado visual por medio de
interacciones con visualizaciones, objetos físicos y personas.
Una organización que usa el Design Thinking crea “un proceso de
inspiración” y “sensibilidad” para hacer el contrato emocional que los
empleados tienen con su organización sea tangible.
10 El Design Thinking es la nueva lógica
competitiva de la estrategia empresarial.
El Design Thinking es la práctica más complementaria que se puede
aplicar a la teoría de la estrategia competitiva de Michael Porter. Permite
a las compañías crear nuevos productos, experiencias, procesos y
modelos de negocio que trascienden de lo que meramente
funciona. Los convierte en productos deseables, lo cual, constituye una
ventaja competitiva realmente sostenible por medio de la innovación.
Premisas principales
del Design Thinking
Enfocarse en valores humanos.
Tener empatía por las personas para las cuales estaremos
diseñando. El feedback de estos usuarios es fundamental.
No decirlo. Mostrarlo.
Comunicar visión de una manera significativa e
impactante creando experiencias, siendo ilustrativos y
contando buenas historias.
Colaboración radical.
Juntar en el equipo personas de distinto perfil. La diversidad
permite salir ideas radicales y con puntos de vista diferentes.
Ser consciente del proceso.
Tener claro el proceso de diseño y saber qué métodos
se utilizan en cada fase.
Cultura de prototipos.
Hacer prototipos no es simplemente una manera de validar
las ideas, debe ser una parte integral del proceso de
innovación.
Incita a la acción.
Se trata de hacer. De pasar de pensar a la acción.
El proceso de
Design Thinking
Empatizar
Definir el
alcance Investigar Sintetizar Idear Prototipar Testear
Lo primordial durante el proceso de diseño es la empatía, ya que así
te centras en mayor medida en las personas y en los usuarios o clientes.
1
se está diseñando así que nos esforzaremos por
Freemium
comprender qué hacen y por qué,Producto básico
sus necesidades (gratis)
físicas
como emocionales, como conciben el mundo y qué es
2
significativo para ellos. PodemosProducto
decir que básico
es una inmersión en un mar de aprendizaje.
con añadidos
esta etapa (de pago)
Esto significa que existe la posibilidad de ofrecer parte del servicio con menos
prestaciones gratis y que el coste sea sufragado por los usuarios premium y
otras fuentes de ingresos.
Vamos ahora a arrojar claridad y enfoque sobre el espacio de diseño en
el que se definen y redefinen los conceptos. Es crucial la correcta
determinación del desafío del proyecto de diseño basado en lo
aprendido del usuario y su contexto. En esta etapa tratamos de dar
coherencia a la información que se ha reunido hasta ese momento.
Definir El modo definición significa crear una declaración de problema
viable y significativo que será guía para enfocarse de mejor manera
a un usuario en particular. El conocimiento sobre el usuario nace de
procesar y sintetizar la información y enfrentando el problema para
hacer conexiones y descubrir patrones racionales.
Para que el conocimiento
Este sobre
modeloel se
usuario
basaseaenválido
la aparición de dos tipos de
debe cumplir con los siguientes criterios:
productos bajo el paraguas de la misma marca:
Freemium 1
Enmarcar el problema con un enfoque directo.
Producto básico (gratis)
Ser inspirador para el equipo.
2 Producto básico con añadidos (de pago)
Generar criterios para evaluar ideas y contrarrestarlas.
iteración.
Esto significa que existe la posibilidad de ofrecer parte del servicio con menos
En ocasiones, la evaluación
prestacionesrevela
gratis que
y queno
el solo
costenos
seaequivocamos conusuarios
sufragado por los la premium y
solución, sino queotras
ni siquiera
fuenteshemos acertado identificando el problema.
de ingresos.
¡Lo Has llegado al final de la unidad