Comment écrire des objectifs «SMART» en tant que développeur agile?

Comme de nombreuses sociétés, l'entreprise pour laquelle je travaille est en train de passer à un système d'évaluation des performances basé sur des objectifs SMART . Mon équipe est une équipe de développement agile très performante utilisant les pratiques d' Extreme Programming . À notre grand avantage, notre emploi de pratiques agiles bénéficie du plein soutien de la direction immédiate et supérieure.

Pour accomplir le travail, notre équipe utilise des itérations de trois semaines. Au-delà de l'itération immédiate, nous avons un plan général divisé en quartiers. Ce qui signifie que ce que nous aurons accompli dans quelques trimestres à partir de maintenant est beaucoup plus flou que ce que nous accomplirons dans l'immédiat. Nous avons certainement une idée générale de l'orientation de notre projet, mais le mot-clé ici est général .

Compte tenu de notre approche de la planification de projet, les membres de mon équipe, y compris moi-même, éprouvent des difficultés à rédiger des objectifs spécifiques, mesurables, réalisables, pertinents et assortis de délais (SMART).

Deux questions existantes sur SoftwareEngineering.se permettent de répondre à certaines de nos préoccupations:

• Quel est un exemple d'un bon objectif SMART pour un programmeur?
• Les objectifs SMART sont-ils utiles aux programmeurs?

Cependant, les questions ont suscité des réponses plus générales que des spécificités pour traiter des objectifs SMART lorsque vous travaillez dans une équipe de développement agile. En tant que développeur agile, comment rédigez-vous des objectifs de cinq à sept ans, qui sont spécifiques, mesurables, réalisables, pertinents et limités dans le temps?

Cette réponse est écrite du point de vue de quelqu'un qui avait mis en place un tel système de gestion de la performance autour d'une équipe Agile; comme vous, tous les membres de l'équipe ont réalisé la difficulté / l'inutilité des objectifs SMART d'un an appliqués à un groupe Agile, où, lorsqu'elle fonctionne pleinement, la mise en œuvre d'Agile peut être considérée intrinsèquement / déjà SMART.

Pas vraiment! Appelez ce qui suit une rationalisation si vous en avez besoin (si la logique est à moitié cuite ...), mais l'expliquer aux examinateurs en dehors de l'organisation immédiate a préparé le terrain pour les "objectifs" réels que nous mettons dans le système de gestion des performances.

• S pour spécifique : lors de chaque planification de sprint, l'équipe s'accorde sur un ensemble spécifique de tâches à réaliser et s'engage à les réaliser. Les tâches (et les récits d'utilisateurs) répondent aux questions de ce que je veux accomplir, des buts / avantages de la réalisation de l'objectif, qui est impliqué, où il a lieu et des contraintes.
• M pour mesurable : la liste de ces tâches, ainsi que le mouvement des tickets tout au long du sprint, du développement à la révision du code en passant par l'AQ jusqu'à la sortie (ou quel que soit votre flux), répond aux questions de la quantité de travail et quand sera-t-elle accomplie .
• A pour réalisable : les groupes Agiles fonctionnels ne s'engagent généralement pas à quelque chose au stade de la planification à moins qu'il ne soit clairement réalisable - toutes les pièces sont là pour savoir comment l'accomplir
• R pour pertinent : des questions comme cela en vaut la peine, est-ce le bon moment, correspond-elle à nos autres efforts - les histoires et les tâches ne sont pas prises dans un sprint et engagées, sauf si la réponse est oui à toutes ces questions ( typiquement ... YMMV)
• T pour limité dans le temps : un sprint est nécessairement limité dans le temps, que ce soit 2 semaines, 3 semaines, plus ou moins.

Si vous comprenez / vous convainquez que votre travail trimestriel (et donc votre travail d'un an) est en soi un grand objectif SMART, et que vous savez que vous atteignez vos objectifs parce que l'équipe fonctionne bien, la vitesse est positive, les libérations se produisent , vous arrivez au point de votre question, qui est finalement de savoir comment traduire un processus SMART en un ensemble d'objectifs SMART pour le bénéfice de quelqu'un d'autre.

J'ai pu le faire avec succès dans le passé en écrivant quelque chose qui me semble vague et, bien, pas très SMART, mais qui est en fait parfaitement acceptable pour les autres.

Quelques exemples qui ont réussi ailleurs pour moi:

• "Je veux publier une nouvelle version de WidgetMaker tous les trois mois au cours de la prochaine année, en suivant notre processus de développement logiciel interne, afin de nous aligner sur le calendrier de développement global du produit (bla bla)."

• "Je veux augmenter la vitesse de développement de l'équipe de n% de la version A à la version B, en me concentrant sur les modifications incrémentielles du processus de préparation du backlog, afin d'augmenter notre efficacité et de réduire les délais d'expédition du produit."

Vous savez et je sais que ce ne sont pas les principes directeurs de votre groupe de développement actuel, mais ils ne sont pas totalement indépendants, et d'après mon expérience, ce sont des types de choses qui semblent vraiment SMART et utiles aux personnes extérieures à votre organisation immédiate (sans être des mensonges ou totalement boiteux).