Si supiéramos lo que estamos haciendo, no se llamaría investigación.

-Albert Einstein

Los picos son un tipo de historia habilitadora de exploración en SAFe. Definidos inicialmente en Extreme Programming (XP), representan actividades como la investigación, el diseño, la investigación, la exploración y la creación de prototipos. Su propósito es obtener el conocimiento necesario para reducir el riesgo de un enfoque técnico, comprender mejor un requisito, o aumentar la fiabilidad de una estimación de la historia.

Al igual que otras historias, los picos son estimados y luego demostrados al final de la Iteración. También proporcionan un protocolo acordado y un flujo de trabajo que los Trenes de Lanzamiento Ágiles (ART) utilizan para ayudar a determinar la viabilidad de las Épicas.

Agile y Lean valoran los hechos por encima de la especulación. Cuando se enfrentan a una pregunta, riesgo o incertidumbre, los Equipos Ágiles llevan a cabo pequeños experimentos antes de pasar a la implementación, en lugar de especular sobre el resultado o saltar a una Solución. Los equipos pueden usar picos en una variedad de situaciones:

  • Estimar nuevas Características y Capacidades para analizar el comportamiento implícito, proporcionando una visión sobre el enfoque para dividirlas en piezas más pequeñas y cuantificables
  • Realizar análisis de viabilidad y otras actividades que ayuden a determinar la viabilidad de las epopeyas
  • Realizar investigaciones básicas para familiarizarse con una nueva tecnología o dominio
  • Ganar confianza en un enfoque técnico o funcional, reduciendo el riesgo y la incertidumbre

Los picos implican la creación de un pequeño programa, actividad de investigación o prueba que demuestre algún aspecto de la nueva funcionalidad.

Picos técnicos y funcionales

Los picos se presentan principalmente de dos formas: técnicos y funcionales.

Picos funcionales – Se utilizan para analizar el comportamiento global de la solución y determinar:

  • Cómo desglosarlo
  • Cómo organizar el trabajo
  • Dónde existe riesgo y complejidad
  • Cómo utilizar los conocimientos para influir en las decisiones de implementación

Picos técnicos – Se utilizan para investigar varios enfoques en el dominio de la solución. Por ejemplo:

  • Determinar una decisión de construir versus comprar
  • Evaluar el rendimiento potencial o el impacto de la carga de una nueva historia de usuario
  • Evaluar enfoques de implementación técnica específicos
  • Desarrollar la confianza sobre la ruta de solución deseada

Algunas características e historias de usuario pueden requerir ambos tipos de picos. He aquí un ejemplo:

«Como consumidor, quiero ver mi uso diario de energía en un histograma para poder entender rápidamente mi consumo de energía pasado, actual y proyectado.»

En este caso, un equipo podría crear ambos tipos de picos:

  • Un pico técnico para investigar cuánto tiempo se tarda en actualizar la pantalla de un cliente al consumo actual, determinando los requisitos de comunicación, el ancho de banda y si hay que empujar o extraer los datos
  • Un pico funcional – Prototipar un histograma en el portal web y obtener algunos comentarios de los usuarios sobre el tamaño de la presentación, el estilo y el gráfico

Directrices para los picos

Dado que los picos no ofrecen directamente valor al usuario, utilícelos con moderación. Se aplican las siguientes directrices.

Cuantificables, demostrables y aceptables

Al igual que otras historias, los picos se colocan en el Team Backlog, se estiman y se dimensionan para que quepan en una iteración. Los resultados de los picos son diferentes a los de una historia porque los picos suelen producir información en lugar de código de trabajo. Deben desarrollar sólo los datos necesarios para identificar y dimensionar las historias que lo impulsan con confianza.

El resultado de un pico es demostrable, tanto para el equipo como para cualquier otra parte interesada, lo que aporta visibilidad a los esfuerzos de investigación y arquitectura, y también ayuda a construir la propiedad colectiva y la responsabilidad compartida para la toma de decisiones. El Product Owner acepta los picos que han sido demostrados y que cumplen con sus criterios de aceptación.

Calificación de los picos

Dado que representan la incertidumbre en una o más historias potenciales, planificar tanto el pico como las historias resultantes en la misma iteración es a veces arriesgado. Sin embargo, si es pequeño y sencillo, y es probable que se encuentre una solución rápida, entonces puede ser bastante eficiente hacer ambas cosas en la misma iteración.

La excepción, no la regla

Cada historia de usuario tiene incertidumbre y riesgo; esa es la naturaleza del desarrollo ágil. El equipo descubre la solución correcta a través de la discusión, la colaboración, la experimentación y la negociación. Por lo tanto, en un sentido, cada historia de usuario contiene actividades similares a los picos para identificar los riesgos técnicos y funcionales. El objetivo de un equipo ágil es aprender a abordar la incertidumbre en cada iteración. Los picos son críticos cuando existe una gran incertidumbre o hay muchas incógnitas.

Aprenda más

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley, 2011.

Última actualización: 10 de febrero de 2021

La información de esta página es © 2010-2021 Scaled Agile, Inc. y está protegida por las leyes de derechos de autor de Estados Unidos e internacionales. Ni las imágenes ni el texto pueden ser copiados de este sitio sin el permiso expreso por escrito del titular de los derechos de autor. Scaled Agile Framework y SAFe son marcas registradas de Scaled Agile, Inc. Por favor, visite Permissions FAQs y póngase en contacto con nosotros para los permisos.

Autor

  • Richard Knaster – Richard Knaster

Deja una respuesta

Tu dirección de correo electrónico no será publicada.