¿Cómo escribir objetivos "SMART" como desarrollador ágil?

Al igual que muchas corporaciones, la compañía para la que trabajo está haciendo la transición a un sistema de evaluación del desempeño basado en objetivos SMART . Mi equipo es un equipo de desarrollo ágil de alto funcionamiento que emplea prácticas de Extreme Programming . Para nuestro gran beneficio, nuestro empleo de prácticas ágiles cuenta con el pleno apoyo de la administración inmediata y superior.

Para lograr el trabajo, nuestro equipo utiliza iteraciones de tres semanas. Más allá de la iteración inmediata, tenemos un plan general establecido en cuartos. Lo que significa que lo que habremos logrado en unos pocos trimestres a partir de ahora es mucho más peligroso que lo que lograremos en el trimestre inmediato. Ciertamente tenemos una idea general de hacia dónde se dirige nuestro proyecto, pero la palabra clave aquí es general .

Dado nuestro enfoque para la planificación de proyectos, los miembros de mi equipo, incluyéndome a mí, tienen dificultades para escribir objetivos que sean específicos, medibles, alcanzables, relevantes y con plazos (SMART).

Dos preguntas existentes sobre SoftwareEngineering.se hacen un buen trabajo al abordar algunas de nuestras preocupaciones:

• ¿Cuál es un ejemplo de un buen objetivo SMART para un programador?
• ¿Son útiles los objetivos SMART para los programadores?

Sin embargo, las preguntas obtuvieron respuestas más generales que específicas para tratar con los objetivos SMART al trabajar en un equipo de desarrollo ágil. Como desarrollador ágil, ¿cómo escribe objetivos de cinco a siete años que son específicos, medibles, alcanzables, relevantes y con plazos determinados?

Esta respuesta está escrita desde la perspectiva de alguien que tenía un sistema de gestión de rendimiento implementado alrededor de un equipo ágil; Como usted, todos en el equipo se dieron cuenta de la dificultad / inutilidad de las metas SMART de un año aplicadas a un grupo ágil, donde, cuando funciona completamente, la implementación de Agile puede considerarse inherentemente / ya SMART.

¡No realmente! Llame a lo siguiente una racionalización si es necesario (si la lógica está a medias ...), pero explicarlo a los revisores fuera de la organización inmediata ha preparado el escenario para los "objetivos" reales que ponemos en el sistema de gestión del desempeño.

• S para específico : durante cada planificación de sprint, el equipo acuerda un conjunto específico de tareas para lograr, y se compromete a realizarlas. Las tareas (y las historias de los usuarios), responden las preguntas de lo que quiero lograr, los propósitos / beneficios de lograr el objetivo, quién está involucrado, dónde se lleva a cabo y las limitaciones.
• M para medible : la lista de estas tareas, más el movimiento de los tickets a lo largo del sprint, desde el desarrollo hasta la revisión del código y el control de calidad para liberar (o lo que sea su flujo), responde a las preguntas de cuánto trabajo y cuándo se realizará .
• A para alcanzar : los grupos ágiles en funcionamiento no suelen comprometerse con algo en la etapa de planificación a menos que sea claramente alcanzable: todas las piezas están ahí para saber cómo lograrlo
• R para relevante : preguntas como si vale la pena, es el momento adecuado, coincide con nuestros otros esfuerzos: las historias y las tareas no se ven envueltas en un sprint y se comprometen, a menos que la respuesta sea afirmativa a todas estas preguntas ( típicamente ... YMMV)
• T para un límite de tiempo : un sprint es necesariamente un límite de tiempo, ya sea 2 semanas, 3 semanas, más o menos.

Si comprende / se convence a sí mismo de que su trabajo trimestral (y, por lo tanto, su trabajo de un año) es en sí mismo un gran objetivo INTELIGENTE, y que sabe que está logrando sus objetivos porque el equipo está funcionando bien, la velocidad es positiva, los lanzamientos están sucediendo , entonces llega al punto de su pregunta, que es, en última instancia, cómo traducir un proceso SMART en un conjunto de objetivos SMART para el beneficio de otra persona.

He podido hacer esto con éxito en el pasado escribiendo algo que para mí parece vago y, bueno, no muy INTELIGENTE, pero de hecho es perfectamente aceptable para otros.

Un par de ejemplos que me han pasado a otra parte:

• "Quiero lanzar una nueva versión de WidgetMaker cada tres meses en el próximo año, siguiendo nuestro proceso interno de desarrollo de software, para alinearlo con el programa general de desarrollo de productos (bla, bla)".

• "Quiero aumentar la velocidad de desarrollo del equipo en un n% desde la versión A hasta la versión B, concentrándome en los cambios incrementales en el proceso de preparación del trabajo atrasado, a fin de aumentar nuestra eficacia y disminuir los retrasos en el envío del producto".

Usted sabe y yo sé que estos no son los principios rectores de su grupo de desarrollo real, pero no son totalmente ajenos, y en mi experiencia son los tipos de cosas que parecen realmente INTELIGENTES y útiles para las personas fuera de su organización inmediata (sin ser completamente mentiras o totalmente cojo).