Início > Processo de Desenvolvimento > Manifestação Ágil

Manifestação Ágil

Cheira Scrum, Mas Fede Waterfall foi escrito em um momento de transição do Scrum para algo mais próximo dos processos clássicos. O Scrum não suportou as constantes colisões com os objetivos de outras equipes e desmoronou, mas sob seus escombros estão as pessoas que formavam um time e que ainda anseiam pela volta daquela forma objetiva e participativa de trabalhar, pois uma vez expostas aos métodos ágeis, as pessoas ficam contaminadas para sempre.

Mais Um Processo

Em caráter interino, assumi a liderança técnica da equipe de desenvolvimento – nomenclatura condizente com o “novo velho processo” – até que nosso líder voltasse das férias. Conversando com um colega, enxergamos uma oportunidade de quebrar o processo instituído de delegação de tarefas, que formava especialistas em determinadas áreas do sistema.

Nossa idéia não era ressuscitar o Scrum, mas seguindo a filosofia ágil, queríamos apenas que o conhecimento das áreas sistêmicas fosse disseminado entre as pessoas através de um processo um pouco mais participativo.

A idéia do Scrum é entregar valor a cada sprint. Esse valor é um item de backlog devidamente priorizado pelo product owner e pontuado pela equipe. Dado que atualmente estamos trabalhando na correção de bugs oriundos da execução de casos de teste e nenhuma nova funcionalidade seria desenvolvida por enquanto, o maior valor que poderíamos entregar era um caso de teste passando sem erros, e não a correção pontual de um bug. Um caso de teste tem a vantagem de olhar os casos de uso na horizontal. Dessa forma, achamos interessante que os desenvolvedores também utilizassem esse documento para guiar seus testes de forma contextual.

Ressuscitamos, mas abduzimos, nosso velho e saudoso taskboard. Em princípio, nosso taskboard abduzido terá as seguintes colunas:

  • Backlog: os casos de teste que falharam;
  • Não Iniciado: artefatos implementáveis, ou seja, tarefas, melhorias e bugs relacionados a cada caso de teste;
  • Em Execução: artefatos sendo implementados;
  • Bloqueado: artefatos que não podem ser implementados devido a alguma dependência externa;
  • Pronto Para Integração: artefatos implementados, mas cujo caso de teste ainda não foi executado;
  • Entregue: todos os artefatos corrigidos e o caso de teste executado com sucesso.

Os post-its do backlog recebem um identificador sequencial que é copiado para todos os artefatos relacionados. Os artefatos são tratadas por qualquer desenvolvedor seguindo algum critério que ainda precisamos definir. O último que finalizar uma tarefa ou alguém que acabe de terminar uma tarefa qualquer fica responsável pela execução do caso de teste. “Então ninguém vai terminar a última tarefa”, um de nós brincou, mas creio que todos captaram a ideia e estão prontos para colaborar.

A execução do caso de teste pode apresentar prematuramente outros problemas tanto em nível de código quanto em nível de especificação. O desenvolvedor, com o auxílio do tester e até do analista, reescreve o caso de teste e aponta os erros em outros artefatos de documentação seguindo duas premissas básicas:

  • O desenvolvedor não é tester;
  • O desenvolvedor não é analista de sistemas.

Dessa forma, a convivência é pacífica e alinhada com as necessidades atuais do projeto. Nossa definição de pronto é:

Todas os artefatos entregues e o caso de teste passando sem falha.

Carências do Processo

Ainda precisamos definir:

  • Uma forma de priorizar os itens de backlog ou alguém que o faça. Por enquanto, os casos de teste mais prioritários são aqueles que geraram mais pendências técnicas;
  • Uma forma de estimar (artefatos ou casos de teste);
  • Tamanho da iteração. Em princípio, serão duas semanas.

Conclusão

Reinserimos as pessoas no processo e elas responderam de forma positiva. Noto que elas abraçam as tarefas e os casos de teste até o fim. A gerência mostrou-se satisfeita com nossa iniciativa. Não é o tipo de processo no qual eu gostaria de trabalhar, mas é o melhor possível dentro da nossa realidade e, dessa forma, é possível produzir software dentro do CMMi.

Anúncios
  1. Nenhum comentário ainda.
  1. 08/08/2010 às 12:24 PM
  2. 28/12/2010 às 9:44 PM

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: