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

Question

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 objectifs SMART . Mon équipe est une équipe de développement agile de haut niveau utilisant des pratiques de 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 la direction 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, atteignables, pertinents et limités dans le temps (SMART).

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

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

jcmeloni · Accepted Answer

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é d'une année objectifs SMART 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 se met d'accord 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, plus le mouvement des tickets tout au long du sprint, du développement à la révision du code, en passant par le contrôle qualité jusqu'à la publication (ou autre votre flux est), répond aux questions de la quantité de travail et quand sera-t-il accompli.
A pour réalisable : les groupes Agiles fonctionnels ne s'engagent généralement pas dans 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-il à nos autres efforts - les histoires et les tâches ne sont pas tirées dans un sprint, et engagé, sauf si la réponse est oui à toutes ces questions (généralement ... 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/convainquez-vous 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 positif, des publications se produisent, alors vous allez au point de votre question, qui est finalement de savoir comment traduire un processus SMART en un ensemble d'objectifs SMART au profit de quelqu'un d'autre .

J'ai réussi à le faire par le passé en écrivant quelque chose qui pour moi semble vague et, bien, pas très SMART, mais 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 sans rapport, et d'après mon expérience, ce sont des types de choses qui apparaissent vraiment SMART et utiles aux gens en dehors de votre organisation immédiate (sans être des mensonges ou totalement boiteux).