Como escrever objetivos "SMART" como desenvolvedor ágil?

Como muitas empresas, a empresa em que trabalho está migrando para um sistema de análise de desempenho baseado nos objetivos SMART . Minha equipe é uma equipe de desenvolvimento ágil de alto funcionamento, empregando práticas da Extreme Programming . Para nosso grande benefício, nosso emprego de práticas ágeis tem o total apoio da gerência imediata e superior.

Para realizar o trabalho, nossa equipe utiliza iterações de três semanas. Além da iteração imediata, temos um plano geral dividido em trimestres. Significando que o que conseguiremos daqui a alguns trimestres é muito mais perigoso do que o que realizaremos no trimestre imediato. Certamente temos uma idéia geral de onde nosso projeto está indo, mas a palavra-chave aqui é geral .

Dada a nossa abordagem ao planejamento de projetos, os membros da minha equipe, inclusive eu, estão achando difícil escrever objetivos que sejam específicos, mensuráveis, atingíveis, relevantes e com prazo determinado (SMART).

Duas perguntas existentes no SoftwareEngineering.se fazem um bom trabalho ao abordar algumas de nossas preocupações:

• Qual é um exemplo de um bom objetivo SMART para um programador?
• As metas SMART são úteis para programadores?

No entanto, as perguntas suscitaram respostas mais gerais do que específicas para lidar com as metas SMART ao trabalhar em uma equipe de desenvolvimento ágil. Como desenvolvedor ágil, como você escreve objetivos de cinco a sete anos, específicos, mensuráveis, atingíveis, relevantes e com prazo determinado?

Essa resposta foi escrita da perspectiva de alguém que tinha um sistema de gerenciamento de desempenho implantado em torno de uma equipe ágil; como você, todos na equipe perceberam a dificuldade / inutilidade das metas SMART de um ano aplicadas a um grupo Agile, onde, quando em pleno funcionamento, a implementação do Agile pode ser considerada inerentemente / já SMART.

Não mesmo! Chame a seguir uma racionalização, se necessário (se a lógica estiver incompleta ...), mas explicá-la aos revisores de fora da organização imediata preparou o terreno para os "objetivos" reais que colocamos no sistema de gerenciamento de desempenho.

• S para específico : durante cada planejamento de sprint, a equipe concorda em um conjunto específico de tarefas a serem atingidas e se compromete a executá-las. As tarefas (e as histórias do usuário) respondem às perguntas do que eu quero realizar, propósitos / benefícios de atingir a meta, quem está envolvido, onde ocorre e restrições.
• M para mensuração : a lista dessas tarefas, além do movimento dos tickets no sprint, do desenvolvimento à revisão de código, ao controle de qualidade e à liberação (ou seja qual for o seu fluxo), responde às perguntas de quanto trabalho e quando será realizado .
• Um para atingível : os grupos Agile funcionais normalmente não se comprometem com algo no estágio de planejamento, a menos que seja claramente atingível - todas as peças existem para saber como realizá-lo
• R para relevante : perguntas como vale a pena, é a hora certa, corresponde aos nossos outros esforços - histórias e tarefas não são puxadas para um sprint e comprometidas, a menos que a resposta seja sim para todas essas perguntas ( tipicamente ... YMMV)
• T para limite de tempo : um sprint é necessariamente de limite temporal, seja 2 semanas, 3 semanas, mais ou menos.

Se você entende / se convence de que seu trabalho trimestral (e, portanto, seu trabalho de um ano) é em si um grande objetivo SMART e que você sabe que está alcançando seus objetivos porque a equipe está tendo um bom desempenho, a velocidade é positiva, as liberações estão acontecendo , então você chega ao ponto da sua pergunta, que é basicamente como traduzir um processo SMART em um conjunto de metas SMART para o benefício de outra pessoa.

Consegui fazer isso com sucesso no passado, escrevendo algo que me parece vago e, bem, não muito INTELIGENTE, mas na verdade é perfeitamente aceitável para os outros.

Alguns exemplos que já passaram em outros lugares para mim:

• "Quero lançar uma nova versão do WidgetMaker a cada três meses no próximo ano, seguindo nosso processo interno de desenvolvimento de software, para alinhar com o cronograma geral de desenvolvimento de produtos (blá blá)."

• "Quero aumentar a velocidade de desenvolvimento da equipe em n%, do release A ao release B, concentrando-me em alterações incrementais no processo de preparação de pedidos em atraso, para aumentar nossa eficácia e diminuir os atrasos no envio do produto".

Você sabe e eu sei que esses não são os princípios orientadores do seu grupo de desenvolvimento real, mas não são totalmente independentes, e, na minha experiência, são os tipos de coisas que parecem realmente INTELIGENTES e úteis para as pessoas de fora da sua organização imediata (sem mentiras diretas ou totalmente coxas).