Description:

En este episodio vamos a platicar sobre qué son, en qué consisten y algunos ejemplos de los anti-patrones más comunes.

_

NOTA: Para tener una mejor experiencia, te sugerimos escuchar el podcast mientras revisas éstas notas

_

Content:

Hola amigos, me habían solicitado que hablara sobre los anti-patrones dentro de ágil, así es que con gusto, en este episodio vamos a platicar sobre qué son, en qué consisten y algunos ejemplos de los anti-patrones más comunes.

¿En dónde se origina?

El término anti-patrón (del inglés antipattern) fue utilizado y acuñado por primera vez por Andrew Koenig en 1995 en la edición del Journal of Object Oriented Program, por lo que la referencia hacia alusión al desarrollo de software, Andrew lo describió de la siguiente manera:

“An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution, but isn’t one.” – Andrew Koening

O lo que en español sería algo así: “Un anti-patrón es igual que un patrón, excepto que en lugar de proveer una solución, nos entrega algo que superficialmente luce igual que una solución, pero no lo es.”

Un tanto complicado, ¿no creen?, en sí a lo que se refiere es a lo siguiente; un anti-patrón es una práctica común que inicialmente parece una solución apropiada y termina teniendo malas consecuencias que superan cualquier beneficio.

¿Qué es un anti-patrón dentro de las prácticas agiles?

El concepto se extendió y también es utilizado dentro de la gestión de proyectos y en las prácticas agiles.

Los Coaches y Consultores utilizamos el término cuando queremos señalar el comportamiento que está teniendo las personas y/o equipos que estamos entrenando y lo hacemos para sugerir utilizar mejores patrones.

Entonces, un anti-patrón es un patrón que pensamos que va a mejorar las cosas pero que en realidad, hace lo opuesto y las empeora. Algunas veces son visibles y otras no y existen muchos que pueden investigar en internet.

Image By Martin Fowler

_

Anti-patrones

Les voy a anexar un listado de algunos anti-patrones:

Calidad, Criterios de Aceptación y Definición de Terminado

  • Cuando no existen Definitions of Done, que son responsabilidad del Product Owner.
  • Cuando NO se tienen Criterios de Aceptación para cada una de las Historias de Usuario, que también son responsabilidad del Product Owner.

Gestión

  • Cuando el Product Owner y/o el Scrum Master le dicen al equipo cuánto esfuerzo (y peor, cuántas horas) debe durar cada historia de usuario.
  • Cuando el Scrum Master le dice al equipo cómo debe organizarse y cómo deben de trabajar, siempre y cuando no sea por motivos de coaching.
  • Cuando el Scrum Master minimiza las dudas, innovación y esfuerzos del equipo.
  • Cuando el Product Owner cancela o cambia el contenido de un Sprint ya iniciado para imponer su voluntad hacia el equipo.
  • Cuando el equipo no tiene un límite de WIP (Work in Progress)
  • Cuando el equipo no actualiza el tablero (board) a tiempo para reflejar el estatus real actual.
  • Cuando el equipo está trabajando en temas adicionales o a parte que no están visibles en el tablero.
  • Cuando el equipo extiende la duración del Sprint unos días para poder cubrir la meta del Sprint.
  • Cuando los integrantes del equipo no están dedicados EXCLUSIVAMENTE a un proyecto y trabajan en varios.

Comunicación

  • Cuando les dicen “ya deberías de saberlo”, pero en realidad es la primera vez que lo escuchas.
  • Cuando no hay retrospectiva porque el equipo cree que no hay nada que mejorar.

Solo es una lista pequeña de los muchos que existen y que se crean continuamente en la medida en que más empresas quieren hacer la transición a las prácticas agiles.

_

Recuerda que para Vivir Ágil requieres, Hacer Ágil y Ser Ágil

_

Links:

.

Songs/Música:

_

Social & Business Relations:


0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *