5. Developer: Desarrollo ágil de productos

Los Developers tienen la responsabilidad vital de dar vida a los incrementos generados en cada Sprint, construyendo los elementos que eventualmente conformarán el producto final. Es imperativo que posean las habilidades y competencias necesarias para realizar este trabajo de manera efectiva. En este capítulo, nos sumergiremos en el mundo de los Developers, destacando las actividades, habilidades y responsabilidades esenciales que delinean su función dentro del equipo Scrum, complementando lo ya discutido en el modelo core de Scrum. Puntos clave de este capítulo: - Identificar las responsabilidades centrales de los Developers en el proceso Scrum. - Explorar las habilidades y competencias que los Developers deben cultivar. - Analizar las actividades diarias y estrategias que facilitan un desarrollo de producto exitoso. - Comprender cómo los Developers colaboran para alcanzar los objetivos de los Sprint y contribuir al producto final.

5.1 - Desarrollo ágil de producto

En el dinámico mundo actual, la figura del Developer se transforma constantemente, abrazando roles más estratégicos y creativos. En este escenario, el desarrollo ágil de productos emerge como un enfoque que no sólo refina tus habilidades técnicas, sino que potencia tu capacidad para contribuir activamente en la creación de soluciones innovadoras.

En este módulo, te invitamos a explorar cómo, como developer, puedes ser un actor clave en este proceso. Desde participar activamente en la definición de la arquitectura del producto, hasta adoptar prácticas de documentación eficientes y ser un protagonista en la implementación de pruebas continuas, tu responsabilidad es esencial para el éxito del producto.

Prepárate para sumergirte en un camino donde tu conocimiento técnico se une con una visión estratégica, permitiéndote participar de manera significativa en la entrega continua de valor. ¡Adelante!

5.1.1 - Autogestión y Gestión del Tiempo: Claves en un buen Scrum Developer

Dentro de un equipo Scrum, se espera que los Developers sean proactivos y asuman un papel central en la autogestión de su tiempo y esfuerzos. Esto no solo fomenta la responsabilidad individual, sino que también promueve una cultura de colaboración y respeto mutuo.

Caso práctico: Imagina un escenario donde un Developer, Carlos, se da cuenta de que una tarea específica está consumiendo más tiempo del esperado, lo cual puede afectar la entrega oportuna del incremento planeado para el Sprint. En lugar de esperar a ser dirigido, toma la iniciativa de comunicar la situación al equipo, proponiendo una sesión de brain-storming para encontrar una solución eficiente. Gracias a esta proactividad, el equipo pudo reajustar y repriorizar las tareas, garantizando la entrega exitosa del incremento.

Tips para una Efectiva Autogestión y Gestión del Tiempo

La autogestión, combinada con una efectiva gestión del tiempo y priorización, no solo facilita la entrega oportuna de productos de alta calidad, sino que también contribuye a un ambiente de trabajo más armonioso y productivo.

5.1.2 - Consideraciones clave para el desarrollo ágil de productos

En el trayecto de construcción de productos ágiles, es imperativo tener en cuenta varios factores esenciales que influenciarán el éxito del producto final. Aquí te presentamos tres preguntas centrales que todo Developer debería tener en mente:

¿Por qué debería definirse la arquitectura de producto

La "Arquitectura del Producto" puede definirse como el esquema estructural que ilustra cómo se organizarán y interactuarán las distintas partes o componentes de un producto. Esta estructura no solo comprende la organización de elementos técnicos, sino también la definición de las relaciones y dependencias que existen entre ellos. El establecimiento de una arquitectura sólida desde el principio, ayuda a prever desafíos y facilita el proceso de incorporación de cambios o ajustes en etapas posteriores del desarrollo. En pocas palabras, funciona como el mapa guía que orienta el desarrollo del producto de una manera organizada y estratégica, asegurando que todas las piezas encajen de manera óptima para cumplir con los objetivos propuestos.

Definir la arquitectura del producto no es solo una cuestión de organización, sino que establece una hoja de ruta clara que facilita la identificación y solución de posibles problemas antes de que surjan. Permite una colaboración fluida entre los miembros del equipo y garantiza que todos trabajen hacia una visión unificada, optimizando los recursos y el tiempo disponible.

Antes de iniciar la construcción del producto es importante identificar la relación entre todos los componentes que harán parte del mismo. Definir una correcta arquitectura permitirá que los equipos de trabajo sepan como organizar sus entregables, se facilitará la integración y la mejora continua.

Es indispensable que, antes de iniciar con el desarrollo se defina el diseño técnico del producto o del incremento de producto a desarrollar. Esta actividad podría hacerse de forma iterativa antes de desarrollar los incrementos en los distintos Sprint, o de forma global al inicio del desarrollo.

Para garantizar que la arquitectura de producto cumple exactamente con los requerimientos y necesidades del cliente se debe hacer en conjunto entre los Developers y el Product Owner.

👉 Tip para el Developer
Involúcrate activamente en las discusiones sobre la arquitectura del producto. Tu conocimiento técnico es vital para diseñar una arquitectura que no solo cumpla con los requisitos del cliente, sino que también sea sostenible y escalable a largo plazo. No dudes en compartir tus ideas y sugerencias.

La arquitectura está estrechamente relacionada con el objetivo del producto (Product Goal). El diseño arquitectónico del producto o sistema sienta las bases para lograr los objetivos y metas del producto, asegurando que se puedan implementar las características y funcionalidades deseadas de manera efectiva.

Ejemplo de arquitectura 1: Construyendo un vehiculo electrico

Al embarcarse en la construcción de un vehículo eléctrico, es vital analizar cuidadosamente los siguientes aspectos cruciales y entender cómo interactuarán entre sí y quién será responsable de su desarrollo, algunos ejemplos que debes considerar al definir la arquitectura son:

Ejemplo de arquitectura 2: Construyendo un software LMS

Una empresa de desarrollo de software planea construir una aplicación para realizar cursos virtuales. Al ser un proyecto de software, en la definición de arquitectura se deberán tener en cuenta los siguientes elementos:

Ejemplo de arquitectura 3: Construcción: Diseño de una Casa Moderna

¿Qué debo considerar respecto a la documentación del producto?

La documentación es una herramienta vital en el desarrollo de productos, ya que facilita la trazabilidad y comprensión de las funcionalidades y características del producto. Es importante considerar no solo qué documentar, sino cómo hacerlo de una manera que sea accesible y útil para todos los involucrados. Además, incentivar la documentación proactiva puede ser un método efectivo para garantizar que se mantenga actualizada y relevante.

La documentación es una herramienta indispensable que, aunque a veces despreciada, puede ser un salvavidas en el ciclo de vida del desarrollo de productos. Vamos a desglosar cómo puede realizarse de manera eficiente y sin dolor:

👉 Tip para el Developer
Considera la documentación como una herramienta que te ayudará, no como una tarea tediosa. Al mantener una documentación precisa y bien organizada, facilitas la gestión de la calidad y la colaboración efectiva en tu equipo.

Caso práctico Pedro, uno de los developers, toma la iniciativa de crear una Wiki para almacenar toda la documentación del proyecto. A medida que el proyecto avanza, el equipo la mantiene actualizada, facilitando la incorporación de nuevos miembros al equipo y sirviendo como una valiosa referencia para revisar decisiones pasadas.

Caso Práctico: Motivando la Documentación Laura, una developer experimentada, notó que el equipo evitaba la documentación, lo que causaba confusión y retrasos. Para remediarlo, instauró junto al Scrum Master sesiones dedicadas a la documentación en cada sprint, complementándolo con un sistema de recompensas para el miembro que más contribuyera. Este enfoque transformó la documentación de una tarea despreciada a una actividad valorada que mejoraba la eficiencia del equipo.

¿Qué implican exactamente las pruebas del producto?

Las pruebas no son una fase aislada en el proceso ágil, sino una integración continua que asegura la calidad y el valor del producto en cada etapa del desarrollo. Los Developers deben adoptar una postura proactiva hacia la realización de pruebas, asegurando que cada incremento cumpla con los estándares de calidad establecidos y contribuyendo al éxito a largo plazo del producto.

Una prueba es la forma de comprobar el correcto funcionamiento del producto o uno de sus incrementos.

👉 Tip para el Developer
Adopta un enfoque proactivo hacia las pruebas, viéndolo como una oportunidad para mejorar continuamente el producto, en lugar de una tarea de última hora. Incorpora pruebas regulares en tu flujo de trabajo para garantizar que cada incremento del producto sea de alta calidad.
👉 Tip para el Developer
Recuerda que las pruebas no son una tarea aislada o exclusiva de un equipo de pruebas; eres co-responsable de la calidad de los entregables. Aprovecha tu conocimiento y habilidades para integrar pruebas continuas. Considera que las pruebas son exclusivas para proyectos de software, sino en todas las facetas del desarrollo de productos. Esto asegurará que el producto no solo funcione como se espera, sino que también cumpla con los estándares de calidad desde el inicio.

Caso práctico: Cuando no se hacen pruebas o no son suficientes En un equipo, inicialmente se pasaba por alto la fase de pruebas o se realizaban de manera muy superficial, lo que llevaba a múltiples errores en las versiones finales del producto. Pero, al establecer definiciones de terminado (DoD) centradas en procesos específicos, se creó una pauta clara para realizar pruebas exhaustivas en cada incremento. Esto no solo redujo los errores sino que también facilitó que cada miembro del equipo pudiera llevar a cabo pruebas efectivas de sus propios entregables, mejorando así la calidad general del producto.

5.2 - Los Developers y los eventos

El desarrollo de un producto exitoso es una jornada colaborativa, y los Developers están en el corazón de este viaje. En el contexto de Scrum, su participación activa en los diversos eventos es crucial, no solo por su papel en la construcción del producto sino también por su contribución a la planificación, adaptación y mejora continua que Scrum fomenta.

En esta sección, desglosaremos cómo los Developers se involucran y contribuyen en cada uno de los eventos de Scrum. Desde la planificación del Sprint, donde establecen las bases del trabajo a realizar, hasta la retrospectiva del Sprint, donde reflexionan sobre el progreso y buscan formas de mejorar. A través de su compromiso y colaboración en cada fase, garantizan que el producto en desarrollo esté alineado con los objetivos establecidos y se adapte eficazmente a las cambiantes demandas y expectativas.

👉 Tip para los Developers
Durante los eventos de Scrum, toma un papel activo en la comunicación y colaboración. No sólo compartas el progreso técnico, sino también busca feedback y aporta ideas para potenciar el valor del producto en desarrollo. La colaboración efectiva entre Developers y otras responsabilidades en el equipo Scrum puede ser la clave para la creación de soluciones innovadoras y de alto impacto.

Los Developers en la Planificación del Sprint

Caso práctico: Durante la planificación del Sprint, el equipo se reúne para discutir las metas del próximo Sprint. Daniela, una Developer, sugiere que se enfoquen en un conjunto particular de historias de usuario que, según su análisis, pueden agregar un valor significativo al producto. Aprovecha este momento para clarificar dudas técnicas con el Product Owner y garantiza que todos los elementos están bien definidos. Juntos, como equipo, realizan una sesión de estimación basada en su experiencia y conocimientos técnicos, asegurando una comprensión compartida de la carga de trabajo y de los objetivos del Sprint.

👉 Tip para los Developers
En la planificación del Sprint, no te limites a hacer caso a lo propuesto por el Product Owner, adopta una postura proactiva en identificar las historias de usuario que podrían agregar más valor al producto. Utiliza este tiempo no sólo para entender el "qué" sino también el "por qué" detrás de cada elemento del Product Backlog, alineándolos estratégicamente con el Objetivo del Sprint (Sprint Goal) y el Objetivo de Producto (Product Goal) a largo plazo.

Los Developers en el Daily

Consejo: Recuerda que el objetivo del Daily no es supervisar sino facilitar la colaboración y el flujo de información. Anima a los Developers a que se apropien de este espacio, compartiendo no sólo avances sino también aprendizajes y retos, promoviendo una cultura de transparencia y confianza mutua, y evitando la percepción de que se trata de una herramienta de supervisión.

👉 Tip para los Developers
Evita la Monotonía: Para prevenir que los Daily se conviertan en encuentros monótonos, varía la estructura ocasionalmente. Por ejemplo, puedes introducir una breve sesión de brainstorming para solucionar un problema específico o facilitar una rápida actividad de team-building que fomente la colaboración y la energía positiva en el equipo.

Los Developers durante el desarrollo del Sprint

Consejos para Developers durante el Desarrollo de un Sprint

Caso Práctico: Durante el desarrollo del Sprint, Laura, una Developer, se da cuenta de que una funcionalidad que están implementando podría beneficiarse de una integración con una herramienta externa, lo que potencialmente podría ahorrar tiempo y esfuerzo en el futuro. Acción: Laura discute esta idea con el resto del equipo durante una sesión de trabajo. Juntos, evalúan los pros y los contras de la implementación de esta integración en este momento, teniendo en cuenta el Objetivo del Sprint y las capacidades del equipo. Resultado: Después de una discusión constructiva, deciden adaptar el plan de Sprint para incorporar esta mejora, ajustando las historias de usuario y las tareas asociadas según sea necesario. Esto les permite entregar un incremento de mayor valor al final del Sprint, demostrando una adaptabilidad y una perspectiva centrada en el valor.

Los Developers en la Revisión del Sprint

Consejos para Developers durante la Revisión del Sprint

Caso práctico: En una sesión de revisión del Sprint, los Developers se encuentran presentando el incremento de producto que lograron durante el Sprint. Laura, una de las Developers, toma la iniciativa de explicar cómo abordaron ciertos retos técnicos y lograron cumplir con los criterios de aceptación establecidos. A medida que se presentan los elementos, Juan, otro Developer, muestra ejemplos prácticos de las funcionalidades implementadas, permitiendo que las partes interesadas tengan una comprensión más clara del progreso. Juntos, los Developers colaboran para asegurar que todas las voces sean escuchadas y que el feedback recibido sea adecuadamente integrado en las consideraciones para el próximo Sprint.

Los Developers en la Retrospectiva del Sprint

Aclaración: Una retrospectiva no solo incluye la identificación de problemas, sino también la colaboración proactiva para diseñar soluciones viables y establecer metas claras para mejorar en áreas específicas.

👉 Tip para el Developer en la Retrospectiva
Cambia el Entorno y Añade un Toque Personal: No permitas que las retrospectivas se conviertan en una rutina aburrida. Sugiere realizar estas sesiones en una herramienta de colaboración gráfica, donde el equipo pueda visualizar de manera creativa los puntos de mejora, o incluso fuera de la oficina en un ambiente más relajado. Además, ¿por qué no agregar un elemento de diversión? Podría ser organizar una comida especial o un snack diferente para cada retrospectiva, fomentando un ambiente más ameno y relajado que puede ayudar a que fluyan mejor las ideas y la comunicación.
Consejos para Developers durante la Retrospectiva del Sprint

Caso práctico: En la retrospectiva, algunos miembros del equipo mencionan que sienten que no hay mucho que discutir o mejorar, mientras que otros sienten que hay problemas pero son reacios a hablar de ellos para evitar situaciones incómodas. Acción: Laura, una de las developers, decide tomar la iniciativa. Ella comparte honestamente algunos desafíos que ha notado durante el Sprint, aunque son temas sensibles. Su apertura anima a otros a compartir sus propias observaciones y preocupaciones, lo que lleva a una discusión enriquecedora. Resultado: El equipo logra identificar varios aspectos cruciales para trabajar y mejorar en el próximo Sprint. Además, se dan cuenta de que, enfrentando los temas incomodos, pueden encontrar soluciones conjuntas y fortalecer la dinámica del equipo.

5.3 - Técnicas y herramientas útiles para los Developers

En el dinámico mundo de Scrum, las responsabilidades de los Developers trascienden las fronteras de las tareas convencionales. Se espera que estén equipados para abordar una amplia variedad de desafíos, adaptándose con agilidad a las demandas cambiantes del proyecto. En esta sección, exploraremos algunas técnicas y herramientas cruciales que pueden facilitar a los Developers esta navegación a través del vibrante entorno de Scrum. Dentro de ellas veremos:

Consejo Al seleccionar y emplear diversas técnicas y herramientas, es vital hacerlo con un enfoque centrado en el valor y la eficiencia. Considera la compatibilidad con las necesidades del organización, la facilidad de integración y cómo pueden potenciar una colaboración efectiva y una entrega ágil de incrementos de alta calidad. A menudo, una herramienta simple pero bien elegida o una técnica aplicada con pericia puede marcar una significativa diferencia, optimizando procesos y fomentando un ambiente de trabajo más productivo y armonioso.

5.3.1 - Para el desarrollo ágil

En esta sección, exploraremos técnicas y herramientas que pueden facilitar un proceso de desarrollo más fluido y colaborativo, promoviendo la calidad y eficiencia en cada incremento.

Nota: Para aquellos interesados específicamente en el ámbito del desarrollo de software, les invitamos a consultar nuestra otra publicación enfocada especialmente en este sector, disponible a través de CertMind, donde profundizamos en técnicas y herramientas adaptadas a las particularidades del desarrollo de software.

Programación por parejas – Pair programming

La programación por parejas es una técnica de desarrollo ágil en la que dos desarrolladores colaboran en la misma tarea, trabajando en un único equipo o computadora. Este enfoque fomenta la colaboración, la comunicación directa y un intercambio fluido de ideas, lo que a menudo resulta en soluciones más innovadoras y eficientes.

Aunque puede parecer que esta técnica reduce la cantidad de funcionalidad producida, en realidad, tiende a mejorar notablemente la calidad del resultado final. Al tener dos pares de ojos revisando el trabajo en tiempo real, es más probable que se identifiquen y corrijan errores en una etapa temprana, lo que puede prevenir costos adicionales a largo plazo.

👉Tip para el Pair Programming
La programación por parejas no es una sesión de enseñanza; de hecho, funciona mejor cuando ambos desarrolladores tienen un nivel similar de conocimiento y habilidades. Esto permite una colaboración más fluida y equitativa, donde ambos pueden contribuir significativamente al progreso de la tarea. Asegúrate de emparejar a desarrolladores con niveles de habilidad compatibles para aprovechar al máximo esta técnica.

El pair programming no solo se usa en programación de software

Caso práctico: El pair programming puede ser agotador En una empresa de tecnología, se instauró la técnica de programación por parejas como una actividad regular pero no constante. Los equipos encontraron que trabajar en parejas durante periodos específicos (como por la mañana o en sesiones de no más de dos horas) era beneficioso sin ser agotador. Esta moderación permitió mantener altos niveles de energía y concentración, favoreciendo la calidad y eficiencia del trabajo realizado.

Caso práctico: Cambiando de pareja En una startup, se estableció una rotación de parejas de programación con cada nuevo Sprint. Esta rotación no solo permitió que los Developers fortalecieran sus relaciones interpersonales, sino que también promovió una comprensión más profunda y diversificada del proyecto en su conjunto, ya que cada miembro del equipo tuvo la oportunidad de trabajar y aprender de diferentes perspectivas y enfoques a lo largo del tiempo.

👉Tip: el Pair Programming no se aplica a todas las tareas
El "Pair Programming" no es una regla fija que deba aplicarse a todas las tareas. Es una herramienta especialmente efectiva para abordar desafíos complejos, explorar nuevas tecnologías o desarrollar funcionalidades críticas. Considera implementarlo estratégicamente, especialmente en situaciones donde la colaboración directa puede potenciar la creatividad, la calidad y la eficiencia. Recuerda, la clave es usarlo donde agregue el mayor valor al proceso de desarrollo del producto.

La refactorización

La refactorización, en un contexto más amplio que el desarrollo de software, puede ser entendida como el proceso de revisar, ajustar y mejorar las estructuras existentes de un proyecto o sistema para hacerlo más eficiente, manejable o adaptable a nuevas necesidades, sin alterar su función fundamental. Esto puede aplicarse a una variedad de ámbitos, como procesos empresariales, estrategias de marketing, estructuras organizativas, etc.

Ejemplo: Antes de la Refactorización Un equipo utiliza una plantilla de informe densa y complicada, que contiene una cantidad significativa de campos irrelevantes. Esto no solo consume tiempo sino que también dificulta la comprensión clara de los puntos clave. Después de la Refactorización - El equipo decide revisar y simplificar la plantilla, eliminando los campos innecesarios y dando prioridad a la información más crítica. Como resultado, los informes ahora son más concisos, centrados y fáciles de leer, facilitando la toma de decisiones y la comunicación efectiva dentro del equipo.

👉Tip: La refactorización debe ser vista como una actividad continua
La refactorización es un compromiso con la mejora constante. No es un "arreglo único", sino un proceso en el que se está siempre atento a las oportunidades de optimizar y ajustar para alcanzar una mayor eficiencia y efectividad. Además, es vital evitar la "refactorización por refactorización". Cada cambio debe tener un propósito claro y estar orientado a lograr mejoras tangibles, evitando alteraciones que no agregan valor significativo.

5.3.2 - Para estimar el trabajo

La estimación consiste en definir entre todos una suposición lo más precisa posible, de lo que se puede lograr y en cuanto tiempo.

La estimación permite:

Nota: El momento en que se realiza la estimación es durante la Planificación del Sprint.

Estimar con Planning Poker

El póker de planificación consiste en un conjunto de tarjetas numéricas que sirven para realizar la estimación de tareas o historias de usuario.

El póker puede ir numerado de 1 a 10 o utilizando la sucesión de Fibonacci

Estimar por afinidad

Consiste en encontrar las similitudes de las Historias de Usuario y tareas que se van a estimar. Lo que hace el equipo es agrupar los elementos que son similares. La mejor manera de “encontrar similitudes” es visualizar el panorama completo y luego agrupar elementos.

Estimar con Tallas de camiseta (t-shirt)

Se asigna una talla de camiseta a cada Historia de Usuario o tarea (desde XS hasta XXL) que representará el esfuerzo relativo de ese trabajo.

Con esta técnica se elimina la necesidad de la precisión de un modelo numérico, por lo que el equipo puede pensar de manera más abstracta en las estimaciones del trabajo a estimar.

¿Qué pasa cuando se Subestima/Sobreestima un Sprint?

Cuando los equipos Scrum son nuevos, o tienen poca experiencia es típico que sucedan las siguientes 2 situaciones:

Sobreestimación: Cuando los Developers proponen demasiado tiempo para el trabajo del Sprint y acaban mucho antes de la Revisión del Sprint. En este caso el Product Owner agregará más trabajo al Sprint en curso (para que la Revisión no se cambie de fecha).

Subestimación: Cuando los Developers proponen muy poco tiempo para el trabajo del Sprint, lo que puede causar que el incremento no esté completamente terminado. En este caso la Revisión se hace sobre los elementos que se hayan completado y los demás quedan pendientes para ser terminados en el próximo Sprint (la revisión NO se aplaza).

Otras posibles técnicas que podrían ser útiles para mejorar el flujo de trabajo durante un Sprint