En el desarrollo tradicional de software se busca especificar los requisitos en una etapa bien definida y además que se pueda describir las características del producto en una documentación detalla, lo que debería servir como especificaciones invariables durante el desarrollo del software. Sin embargo ante la dinámica en la que actúan hoy en día las empresas, se ha visto que los requerimientos también van cambiando demostrando así la necesidad de que los requisitos también sean adaptables. Ante esta situación el desarrollo ágil se muestra como una alternativa, ya que, en base a la generación de entregables en iteraciones cortas es posible garantizar la generación del valor para los usuarios.
En ese sentido es necesario adaptar alguna otra alternativa para obtener los requisitos, es así, que las historias de usuario se muestran adecuadas para cumplir esta tarea permitiendo mejorar la colaboración del equipo con todos los implicados del proyecto y generando la posibilidad de la tolerancia al cambio.
Especificación de Arquitectura de SoftwareSoftware Guru
El objetivo de la plática es mostrar con un ejemplo como especificar la arquitectura de un sistema.
Hoy en día hay varios libros de Arquitectura de software que nos muestran: Que debemos hacer, Que podemos usar pero pocos nos dan un ejemplo concreto.
Esta platica está dirigida a aquellos colegas que quieren iniciar en el rol de Arquitecto de Software, que tienen la experiencia y conocimientos pero tienen duda de como plasmar sus decisiones de diseño ó se preguntan si su diseño es suficiente y correcto.
En esta platica se desarrolla en 2 partes:
En la 1ª. se repasaran algunos conceptos relativos a la práctica de Arquitectura tales como objetivo, requerimientos no funcionales, riesgos, restricciones, patrones, vistas, etc.
En la 2ª. parte se mostrará como hacer una especificación de Arquitectura de un caso real pero acotado.
Al final espero que el participante se quede con una referencia que sirva para mejorar su práctica de Diseño de Arquitectura.
Especificación de Arquitectura de SoftwareSoftware Guru
El objetivo de la plática es mostrar con un ejemplo como especificar la arquitectura de un sistema.
Hoy en día hay varios libros de Arquitectura de software que nos muestran: Que debemos hacer, Que podemos usar pero pocos nos dan un ejemplo concreto.
Esta platica está dirigida a aquellos colegas que quieren iniciar en el rol de Arquitecto de Software, que tienen la experiencia y conocimientos pero tienen duda de como plasmar sus decisiones de diseño ó se preguntan si su diseño es suficiente y correcto.
En esta platica se desarrolla en 2 partes:
En la 1ª. se repasaran algunos conceptos relativos a la práctica de Arquitectura tales como objetivo, requerimientos no funcionales, riesgos, restricciones, patrones, vistas, etc.
En la 2ª. parte se mostrará como hacer una especificación de Arquitectura de un caso real pero acotado.
Al final espero que el participante se quede con una referencia que sirva para mejorar su práctica de Diseño de Arquitectura.
User Stories - Cómo crearlas y cuándo usarlas. Con Sr. UX Manager Rodrigo Par...Omar Corona
Algunas veces recibimos proyectos con largas listas donde se describe a detalle todo lo que el producto hará, sin que tengamos visibilidad de por qué cada requerimiento es relevante para las personas que lo usarán - al final del cuento, para quien diseñamos. ¿Te ha pasado?
Las historias de usuario son una manera amigable y casual de describir las funcionalidades de un producto o plataforma, que además están plasmadas en lenguaje natural. Su importancia al diseñar un producto centrado en el usuario, y basado en empatía hacia este a través de nuestras Personas, radica en que éstas están narradas desde su perspectiva.
En esta plática, conversaremos sobre el origen de las historias de usuario, modelos comunes, y ejercicios prácticos que podrás facilitar con los involucrados de tu proyecto para crearlas. Finalmente, se considerarán también sus debilidades para contemplar en qué casos nos serán más útiles y en cuáles deberíamos pensar en otro formato.
Rodrigo Partida Zermeño, en Wizeline. Maestro en Ciencias de Factores Humanos en el Diseño de Información. Se especializa en investigación de usuario y ha facilitado talleres para varios clientes Fortune 500, así como impartido cursos y ejercicios para Wizeline Academy y universidades como Tec de Monterrey.
Experiencia de Usuario (UX) y Propuesta de Valor Fernando Cea
En coordinación con Global Trust Association, ORCI Latam y KI Teknology, presentamos un webinar sobre herramientas de Experiencia de Usuario y Propuesta de Valor como pilar estratégico de los negocios.
Presentación: Fernando Cea
Charla realizada para #DevHangout de @devacademyla sobre la importancia de los requerimientos, técnicas ágiles para identificación y experiencias en proyectos.
Historias de Usuario en acción: potenciando el valor de los productosMarco Avendaño
En esta charla, se explora las historias de usuario, como herramienta fundamental en el desarrollo ágil para potenciar significativamente el valor de los productos.
A través de ejemplos y casos reales, se desentraña el poder de las historias de usuario para comprender las necesidades del usuario, mejorar la colaboración en el equipo y garantizar la entrega de productos que no solo cumplan, sino que superen las expectativas.
Presentación de Design Thinking para I-Quattro, donde se da conocer la importancia de la experiencia los usuarios, ejemplos de casos de éxito y recomendaciones para la adopción en las organizaciones.
eduScrum es un marco dentro del cual docentes y alumnos abordan problemas complejos y desafiantes y persiguen objetivos de aprendizaje del mayor valor posible de una manera productiva y creativa. En la presentación se comparte algunas experiencias para la adopción de Scrum en la educación.
Cuando un equipo esta empezando a usar Scrum, en algunas ocasiones no tiene muy claro de donde obtener el Product Backlog o que aspectos del producto se deben incluir.
Considerando que el Product Backlog es una lista emergente y ordenada de lo que se necesita para mejorar el producto, resulta conveniente que se tomen las medidas necesarias para incluir solamente aquellos aspectos que resultan imprescindible y adecuados; ademas que puedan ser considerados a partir de la interacción con los involucrados durante sesiones de Discovery del Producto.
Para responder a los retos del entorno actual, las organizaciones están adoptando Scrum; sin embargo para que funcione adecuadamente es necesario generar cambio en el equipo, sus relaciones y toda la organización. El Scrum Master contribuye a este desafío, siendo el actor central para generar el cambio con ayuda de otros Scrum Masters.
Shift Left: En busca del éxito del softwareMarco Avendaño
Las organizaciones en la actualidad se encuentran en el reto de prosperar en un mundo digital y generar soluciones que satisfagan necesidades de las personas que son cada vez más exigentes. Ante esta situación, se hace necesario un enfoque de servicio que acerque el conocimiento a sus clientes, que reduzca los costes, mejore la experiencia de los clientes y, lo que es más importante, que equilibre la tecnología y la conexión humana. Adoptar una estrategia basada en "Shift Left" brinda la posibilidad de responder a estas necesidades.
“Shift Left” es considerada una práctica originada en el software delivery, cuyo objetivo es mejorar la calidad y la rentabilidad trasladando las actividades críticas lo antes posible en el ciclo de vida del desarrollo de un producto. En la presente charla se dará a conocer las principales características, beneficios y prácticas de “Shift Left”.
Antipatrones de las retrospectivas relacionados a las personasMarco Avendaño
Una retrospectiva se trata en esencia de hacer grandiosos a los buenos equipos y por lo tanto su realización debe ser de suma importancia. Sin embargo en muchas ocasiones se puede apreciar que las personas no quieren asistir a las retrospecticas ya que sienten que no les proporciona ningún beneficio. En esta presentación se comparten algunos antipatrones relacionados a las personas en la realización de las retrospectivas.
Value Stream Mapping para la eficiencia del procesoMarco Avendaño
Durante la conferenica Agile 2019, Jeff Sutherland, co-autor de Scrum, recordaba que la única métrica que importa es la eficiencia del proceso. La eficiencia se centra en la rapidez con la que se entrega valor y por eso se le debe dar la importancia correspondiente.
Las siete dimensiones del producto, brindan a los “socios del producto“ (cliente, negocio, tecnología) una comprensión integral y holística del producto. Estas dimensiones son: user, interface, action, data, control, environment, quality atribute.
De acuerdo a la definición de Michael Hüttermann, DevOps es una mezcla de patrones destinados a mejorar la colaboración entre desarrolladores y operadores. DevOps se dirige a compartir metas e incentivos, así como procesos compartidos y herramientas. En el presente workshop se proporcionará los conceptos básicos, características y recomendaciones que podrían considerar los agentes de cambio para impulsar este movimiento en las organizaciones.
Si se quiere ganar un partido de ajedrez, no basta con conocer la reglas, también se necesitan estrategias. Si la Guía de Scrum fuera lo que es un libro de reglas de juego para el ajedrez, para ganar el partido necesitamos tener estrategias; estas estrategias son los patrones. Un patrón es una solución repetible aplicable a un problema que surge en un contexto específico.
En esta presentación se da a conocer los patrones orientados al valor y ROI.
Eliminando desperdicios en el desarrollo de softwareMarco Avendaño
Se entiende por “desperdicio” a cualquier actividad que consuma recursos pero que no agrega ningún valor, según la percepción del cliente. El desarrollo de software Lean está inspirado en Lean Manufacturing y Toyota Production Systems, donde se encuentran definidos los 7 desperdicios de la fabricación, y es a partir de ellos que se adopto los 7 desperdicios del desarrollo de software, con los cuales se tiene el propósito de descubrirlos y eliminarlos para reducir costos y hacer que los productos sean más efectivos. En la presente charla se dará a conocer las características de estos desperdicios, así como, indicar algunas recomendaciones para reducirlos.
Los acuerdo de equipo son directrices que permitan a los miembro del equipo estar “en la misma página”, se constituyen en las pautas para eliminar malos entendidos que pueden traer consecuencias costosas. Permiten que el equipo conozca el tipo de información que se comparte, cómo se comunican, y cómo se conoce qué están haciendo los demás. Los acuerdos son un artefacto vivo y deben ser revisados de manera periódica.
OKR: Alineando objetivos y resultados en las organizacionesMarco Avendaño
OKR (Objectives and Key Results) es un framework de pensamiento crítico y disciplina continua que busca asegurar que los empleados trabajen juntos, enfocando sus esfuerzos para hacer contribuciones medibles que impulsen a las organizaciones. En esta charla, se dará a conocer sus principales características y sugerencias para su adaptación
Resolver problemas y testar nuevas ideas, aunque estemos separados. Se presenta algunas recomendaciones y herramientas para el desarrollo de sesiones de Design Sprint de manera remota.
User Story Mapping - Proceso de construcciónMarco Avendaño
El mapeo de historias de usuario (User Story Mapping) consiste en ordenar historias de usuarios a lo largo de dos dimensiones independientes. El "mapa" organiza las actividades del usuario a lo largo del eje horizontal en un orden aproximado de prioridad (o "el orden en el que describiría las actividades para explicar el comportamiento del sistema"). El recorrido hacia abajo del eje vertical, representa una sofisticación creciente de la implementación. En la presentación se da a conocer el proceso de su construcción.
El entorno actual en el que nos desenvolvemos es volátil, incierto, complejo y ambiguo, es por ello que las empresas están buscando alternativas para la generación de productos y servicios innovadores. Ante esta situación cobra mayor realce el Product Discovery por medio del cual trata de garantizar que el producto correcto se construya para la audiencia correcta. Esta se constituye en la base para una implementación exitosa y una fase de lanzamiento posterior y debería proporcionar la confianza para representar la visión del producto ante el equipo, los Stakeholders y la alta gerencia.
Cada vez escuchamos y vemos con más frecuencia el término "agile" en diferentes contextos, generalmente asociando su uso a lograr resultados rápidos o realizar actividades llenas de post-its; sin embargo agile es mucho más que eso! Más que un conjunto de prácticas y herramientas, esta relacionado a una mentalidad (mindset).
"Mindset agile" hace referencia a algo nebuloso e intangible que describe un valor o comportamiento necesario para el éxito de una transformación, metodología, proceso o práctica ágil. Por lo tanto debemos hacer mayor énfasis en "SER AGILE" en lugar de "HACER AGILE".
En este Workshop compartimos una serie de actividades y dinámicas que nos permitirán conocer con más a detalle los Valores y Principios del "Manifiesto por el Desarrollo Ágil de Software", que serán nuestro punto de partida para el desarrollo de una mentalidad ágil como individuo, equipo u organización.
7. Obligatorio, fijo, difícil de
cambiar.
Centrada en las
característica, en lugar del
valor.
Especifica el qué, en lugar
del por qué.
Costoso.
Los requerimientos
9. Alternativa a WBS
Definir el plan del proyecto en términos de lo que será entregado en lugar de qué pasos de trabajo se llevará a
cabo.
10. Opciones
Use Cases Requirements Stories
Goal capture a behavior
establish a
contract
generate
conversation
Scope
a process
"day in the life"
everything a single activity
Format numbered bullets specifications a single sentence
Completeness
locked, changes
may
impact entire
process
locked, require
scope
change and
approvals
open for
negotiation
and refinements
Language structured, flows precise, technical
simple,
comprehensible
11. Requisitos por escrito
Pueden ser pensados, revisados y editados.
Proporciona un registro permanente.
Se comparten más fácilmente con grupos de personas.
Consume mucho tiempo para producirlos.
Pueden ser mal interpretados.
Requisitos verbales
Retroalimentación instantánea y clarificación.
Intercambio de información.
Más fácil de aclarar y obtener un entendimiento común.
Más fácilmente adaptado a cualquier nueva información conocida en el
momento.
Puede generar ideas sobre problemas y oportunidades.
Requerimientos y la comunicación
12. Modelo de comunicación
Agile Software Development: Communicating, Cooperating Teams
By Alistair Cockburn - Aug 10, 2009
22. Una lista de todos los trabajos deseados en el proyecto “los
requisitos“.
Propiedad, administrado y priorizado por el Product Owner.
Items son estimados por el equipo.
Se pueden volver a priorizados al inicio de cada iteración.
Expresados de tal manera que cada ítem tiene valor para los
usuarios o clientes del producto.
Algunos equipos también optan por incluir mejoras en los
procesos, bugs y correcciones de la deuda técnica.
Product Backlog
27. Proporcionan un “enfoque
ligero” para gestionar los
requisitos de un sistema.
Es una pequeña pieza de
funcionalidad que adiciona
valor al negocio.
Es una promesa para
entablar conversación..
¿Qué son?
28. No es un documento de
requerimientos.
No es un caso de uso.
No es un documento de
diseño técnico.
No son escenarios.
No es reporte de bugs.
¿Qué NO son?
29. El software está escrito en
C++.
La base de datos tendrá un
pool de conexiones.
Las anti historias
30. Centrado en el usuario: lo que es importante para el cliente.
Historia: El Poder de la Narrativa.
Prestamos más atención a las historias que a los hechos.
Una historia dibuja una imagen, y una imagen vale mas que
mil palabras.
Centrado en el beneficio, el valor, lo importante:
Define Criterios de Aceptación ANTES de implementar.
Apoya la "extracción" de información según sea necesario.
Desarrollo iterativo.
Características
32. 1. Card
• Escrito en una tarjeta
(Card).
2. Conversation
• Detalles capturados en
las conversaciones.
3. Confirmation
• Los criterios de
aceptación confirman
que la historia esta
realizada (Done).
Las 3 C’s
Como usuario, puedo acceder a
la intranet, para colaborar con
toda la organización.
¿Qué hay de las
cuentas expiradas?
¿Cuántos intentos
se tiene para
ingresar?
• Cuentas expiradas no acceden.
• Después de 3 intentos la
cuenta es bloqueada.
33. Estructura
Como lector del Blog
Quiero suscribirme al Blog
Para poder realizar
comentarios a las entradas de
mi interés
Rol de usuario,
Persona ¿Quien?
Función deseada
¿Qué?
Resultado final ¿Para
qué?
34. Definen los límites de la historia.
Ayudan al Product Owner a responder lo que se necesita para
que esta característica proporcione valor.
Ayudar al equipo a obtener un entendimiento compartido de la
historia.
Ayuda a los desarrolladores y testers a obtener pruebas.
Ayuda a los desarrolladores a saber cuándo dejar de agregar
más funcionalidad a una historia.
Criterios de aceptación
37. Debe ser autónoma, de tal
manera que no haya una
dependencia inherente a
otra historia de usuario.
Independent
As a user
I want to pay bills online
So that I don’t have to write
checks
38. Las historias de usuarios,
hasta que forman parte de
un Sprint, siempre se
pueden cambiar y volver a
escribir.
Negotiable
As a driver
I want to get directions to
conveniently located stores
So that I get there quickly
Acceptance Criteria:
Show locations on map
Show locations on Google
Maps
39. Debe proporcionar valor al
usuario final y al negocio.
Valuable
As a customer
I want 75% off all purchases
So I can save money
Claramente existe valor
para el usuario, pero
existe valor para el
Negocio?
40. Siempre se debe ser capaz
de estimar el tamaño de una
historia de usuario.
Estimable
41. Debe ser pequeña en
esfuerzo, generalmente
representando no más de 2-
3 personas/semana de
trabajo.
Una historia que es más
grande va a tener más
errores asociados a la
estimación y alcance.
Small
42. Su descripción debe
proporcionar la información
necesaria para hacer posible
el desarrollo de pruebas.
Testable
49. Planificación de la Iteración
• El equipo selecciona historias del Product Backlog s que pueden
comprometerse a completar.
• Se crea el Sprint Backlog:
• Se identifican tareas y cada una es estimada en horas.
• Las tareas y sus estimaciones se realizan de manera
colaborativa.