Elementos clave de un ADF: personas, procesos y métricas

#Elementos clave de un ADF

Los pilares del software funcional que tiene como base el ADF son: las personas, procesos y herramientas; métricas.

1. Personas e interacciones y la manera en la que se comunican. Es importante definir la estructura organizacional. Claridad de roles y responsabilidades: saber quién es y como se involucra en el equipo. Y por último, el Stakeholder management, el manejo de las personas ajenas al núcleo del equipo, como manejar las expectativas de todas las personas que no hacen parte integral del equipo de desarrollo. El tiempo y la confianza lo es todo: requiere de tiempo, de prueba y error, generar confianza en el equipo.
2. Los procesos y herramientas son esenciales. Usar herramientas que agreguen valor, que el equipo va a usar y les servirá, no forzar herramientas que no aportan. No usar muchas herramientas: reducir y simplificar los procesos y herramientas.
3. Métricas de un ADF: cómo y cuando usarlas
   Usa todas las métricas que quieras Úsalas como indicadores para mostrar que el software está funcionando, en momentos críticos como indicadores de mejora, no como elementos únicos en la toma de decisiones.

Clase 5: Elementos clave de un ADF: personas, procesos y métricas

Los pilares del software funcional que tiene como base el ADF son: las personas, procesos y herramientas; métricas

Personas

• Personas e interacciones y la manera en la que se comunican.
• Es importante definir la estructura organizacional.
• Claridad de roles y responsabilidades: saber quién es y como se involucra en el equipo.
• El Stakeholder(Interesada) management, el manejo de las personas ajenas al núcleo del equipo, como manejar las expectativas de todas las personas que no hacen parte integral del equipo de desarrollo.
• El tiempo y la confianza lo es todo: requiere de tiempo, de prueba y error, generar confianza en el equipo.
• https://fourweekmba.com/es/modelo-tuckmans-de-desarrollo-de-grupos/

Procesos

• Los procesos y herramientas son esenciales.
• Usar herramientas que agreguen valor, que el equipo va a usar y les servirá, no forzar herramientas que no aportan.
• No usar muchas herramientas: reducir y simplificar los procesos y herramientas.
• https://www.softwaretestinghelp.com/agile-project-management-tools/

métricas

• Métricas de un ADF: cómo y cuando usarlas
• Usa todas las métricas que quieras
• Úsalas como indicadores para mostrar que el software está funcionando, en momentos críticos como indicadores de mejora, no como elementos únicos en la toma de decisiones.
• https://businessmap.io/es/agiles/metodologia-agile/metrics

Personas:
Tiempo y confianza lo es todo- Así como la manera en que colaboran

Procesos y herramientas:
Menos es más → Simplicidad
Si no funciona hay que cambiarlo. Si el proceso de iteración requiere cambiar herramientas, Hay que hacerlo

Métricas: Siempre medir, hay que usarla como indicador de mejora no como elementos únicos en la toma de decisiones. Deben indicar si el producto o servicio está funcionando y agregando valor.

Párrafo 1: Introducción a los elementos clave Ahora vamos a hablar de 500 clave de todo haya el delivery fin. Sin importar cual podemos utilizar Trump canva fruman 6 XP min dsdm cristal. La lista continúa, les dije, ya hay muchos, no importa cuál utilicemos. Lin. Es mi experiencia que. Su indemnización requiere de 3 un amigo. Este temblor de Ángel del libro y luego al que nos permite entregar software de valor. Párrafo 2: Tres pilares fundamentales Está incluido. Sobre estos 3 pilares. Esta es mi experiencia, sus experiencias pueden variar. Es más, es muy probable que sean distintas, pero eso es lo que a mí me ha funcionado y a los equipos con los que he trabajado. Párrafo 3: Resumen de los tres pilares ¿Son las personas como colaboran? El segundo Pilar son los procesos y herramientas que permiten estas personas entregar valor y el tercer Pilar son las métricas, es decir. La manera en que reciben retroalimentación de lo que se ha construido. Párrafo 4: Importancia de las personas y sus interacciones Bueno, ahora vamos a pasar a hablar un poquito más de cada una de ellas. Empezamos con las personas y sus interacciones. No por nada hemos escuchado muchas veces en la gente decir que las personas son los recursos más importante. Suena trillado, suena repetitivo, pero en El Mundo del software diariamente es. Muy importante, como colaboran las personas y. La manera en que se comunica ahora no es solo. Contratar a la gente correcta no es solo mantenerlos reactivados, es muy importante cuando rentamos un proyecto o una serie de proyectos, un programa de software, tener claridad. Tanto el delivery manager delivery Direct Project manager, el Program manager como los individuos, los ingenieros, cada miembro del equipo debe de tener una clara idea de la estructura. Todos hemos visto los croquis importante tenerlo definido idealmente recomiendo tenerlo plasmado. ¿Un organigrama no tiene que ser notificado, pero que todo El Mundo sepa por lo menos quiénes son las personas involucradas? Tanto el equipo interno como los actores o stakeholders externos. Párrafo 5: Responsabilidades y roles del equipo También es muy importante que sepamos cuáles son nuestros problemas y responsabilidades, dependiendo del tiempo y los recursos que tengamos podemos tener. Una página escrita con los goles sensibilidades de cada quien, pero por lo menos es importante que se discutan, no el ejemplo de Chrome. ¿Yo soy el productor que hace el producto, yo soy el equipo de desarrollo que hace el equipo de desarrollo y por quién está conformado? Yo soy él external stakeholders viene, soy y como me involucro en el equipo. Párrafo 6: Gestión de los stakeholders externos ¿Y por último, hablamos de stakeholder Management, que significa esto? El manejo de personas ajenas a nuestro núcleo y eso es muy importante. ¿Cómo manejamos las expectativas de todas las personas que no son parte integral de nuestros equipos de desarrollo? Eso es un elemento que muchas veces nos olvidamos de prestarle atención, manejo de expectativas e identificación de todas las personas que están involucradas. Sí, vamos a tener dentro de cada proyecto un grupo núcleo, pero. En el desarrollo de software hay muchas otras personas que tenemos que estar por lo menos pendientes de ellas, o tener conocimiento de quiénes son. Párrafo 7: Construcción de confianza en el equipo En los equipos de desarrollo es mi experiencia y el tiempo y la confianza es lo que verdaderamente hacen las dife. No podemos esperar que un equipo de desarrollo no se conocen, que son nuevos en el proyecto desde el día 1 estén trabajando a todo vapor, no es racional pensar, requiere de tiempo, requiere de prueba y error, requiere de. Generar confianza, pues eso es para generar confianza dentro de un equipo hay mucho. ¿Como? Referencia les sugiero que arranquen leyendo sobre el modelo de Tucumán pueden Leer más sobre este modelo en los recursos del curso. Párrafo 8: Procesos y herramientas como segundo pilar Importantísimo, las personas vamos escuchado muchas veces. Las personas y la manera en que colaboran fundamental. Ahora pasamos al siguiente Pilar. Los procesos y las herramientas, bueno existen. Muchos procesos y herramientas, en la misma manera que hay muchos, hayan leído diferencia entre cada familia. Hay sinfín de procesos sin fin de herramientas. Me pongo enlistarlas, no acabamos nunca. Sin embargo, igualmente recursos de El curso pueden ver una lista de ellos como punto de referencia. Párrafo 9: Elección de procesos y herramientas Ahora lo más importante en la elección de los procesos y las herramientas que utilizamos es. Y sean herramientas. Y agreguen valor nuevamente no me voy a cansar de decir ahora. ¿Qué significa esto? Y que aquí son las herramientas y el equipo va a utilizar, no puedes forzarlo. Un equipo que utilice una herramienta es la herramienta que le sirve para construir software de valor. Párrafo 10: Equilibrio en el uso de procesos y herramientas Con los procesos y herramientas es importante reconocer que no importa cuál se elija, todas pueden ser muy benéficas, todas pueden servir, pero también pueden causar daño. En sin ellas no tenemos estructura, no hay orden, pero si hay demasiadas como todos en la vida y se abusan y si hay demasiados bellas ON generar caos. Menos. Es más. ¿Yo le sugiero sin ti y reducir el número de procesos de herramientas en universo, no? Pero a medida que los equipos van integrando podemos ahondar o incluir nuevos procesos y nuevas herramientas. Párrafo 11: Ejemplo de adaptación de herramientas Les doy un ejemplo sencillo, no a ver si a un constructor le pedimos que lave. Un lavo por un pedazo de madera. Quiero utilizar un Martí el ente, o sea herramienta funciona, pero si más adelante tiene un tornillo. Gana un clavo, un tornillo y lo tiene que atornillar sobre. La misma madera. Va a utilizar el martillo, no necesariamente la primera iteración en el primer ciclo, que no muy bien el martillo. Cambiaron las exigencias cliente cambió el mercado, ya no utilizan más tornillos. En clavos, ahora necesitamos utilizar tornillos, ya no nos sirve la misma herramienta, no vamos a forzar el uso de la herramienta y sabemos que ahora es importante utilizar otra. En este caso utilizaríamos un destornillador. Un ejemplo muy sencilloel.es el mismo, hay que poder utilizar las herramientas que sabemos que funcionan y no está funcionando. Escuchamos el equipo, escuchamos a los diferentes de stakeholders y hacemos los cambios de escenarios. Párrafo 12: Métricas como tercer pilar Bueno, el último Pilar. Las métricas. Es importante. Siempre estar midiendo las métricas pueden ser IVA, pueden ser objetivas, no pueden ser opiniones o pueden ser datos puntuales. De una manera pueden ser cualitativas, pueden ser cuantitativo. Igual que con los procesos y herramientas en Pilar. Las métricas. Es importante. Siempre estar midiendo las métricas pueden ser IVA, pueden ser objetivas, no pueden ser opiniones o pueden ser datos puntuales. De una manera pueden ser cualitativas, pueden ser cuantitativo. Igual que con los procesos y herramientas en Pilares anteriores, las métricas también tienen que cumplir con dos características fundamentales: Párrafo 13: Características de las métricas efectivas En primer lugar, las métricas tienen que estar alineadas con los objetivos del negocio y los objetivos del equipo. No pueden ser métricas aisladas, tienen que tener una conexión clara con lo que se quiere lograr. Y en segundo lugar, las métricas tienen que ser medibles, tienen que ser algo que podamos cuantificar, que podamos dar seguimiento, que podamos entender cómo vamos evolucionando en esos indicadores a través del tiempo. Párrafo 14: Ejemplos de métricas clave Algunos ejemplos de métricas que pueden ser útiles pueden ser: velocidad de entrega, es decir, cuánto software estamos siendo capaces de producir en un periodo de tiempo determinado. Calidad, es decir, cuántos defectos o problemas se están presentando en el software que estamos entregando. Satisfacción del cliente, es decir, qué tan satisfechos están los usuarios finales con lo que estamos generando. Y por último, el impacto en el negocio, es decir, qué tanto valor estamos generando con nuestras entregas de software. Párrafo 15: Aplicación de las métricas Estas métricas no solo nos sirven para medir, sino también para tomar decisiones. Nos permiten entender qué está funcionando bien, qué está funcionando mal, y en base a eso poder hacer ajustes, poder mejorar nuestros procesos, poder mejorar la forma en que trabajamos. Es un ciclo constante de medición, análisis y mejora continua. Párrafo 16: Conclusión En resumen, los tres pilares fundamentales para mejorar la entrega de valor en proyectos de software son: las personas y su forma de colaborar, los procesos y herramientas que utilizan, y las métricas que permiten medir el desempeño y el impacto. Al enfocarnos en estos tres elementos clave, podremos optimizar la forma en que desarrollamos y entregamos software de calidad a nuestros clientes.