Papéis e responsabilidades nos métodos ágeis

terça-feira, 3 de agosto de 2010

Todo mundo conhece a brincadeira do telefone sem fio. Além de uma brincadeira de crianças, ela serve para ilustrar quanto de conhecimento se pode perder entre a captura de requisitos até as funcionalidades de fato implementadas, caso não haja o cuidado necessário.

O interessante é que ao se buscar a solução para o problema, duas abordagens completamente diferentes podem ser tomadas.


A primeira é a mais óbvia, detalhar o máximo possível. Junto com isto temos técnicas de levantamento de requisitos, técnicas para verificar/validar os requisitos e outros recursos. Muitas informações interessantes ficam registradas e outras tantas podem ser extraídas de um Caso de Uso bem feito. Informações que podem levar a melhores estimativas, redução de custos e até de prazos no futuro, informações valiosas para um processo de melhoria. Porém, é mais trabalhoso.

A segunda, adotada pelos métodos Ágeis é a inversa. Detalhar o mínimo possível. E costuma funcionar dependendo do cenário.

Ao escrever uma User Story, a idéia é quase um lembrete do que deve ser desenvolvido e não a descrição exaustiva da funcionalidade. A abordagem se baseia no fato de que, se a perda de conhecimento acontece nos intermediários da comunicação entre o cliente ou usuário e o desenvolvedor, o melhor a se fazer é colocar os dois para conversar no momento em que aquela funcionalidade for implementada.

Neste momento, o desenvolvedor se torna um pouco analista. A seguir, ele pode ser um pouco arquiteto, um pouco desenvolvedor, um pouco testador, etc. Claro, nada impede que se tenha gente experiente nestas áreas acompanhando o processo em cada fase, mas também não tem nada que exija isto. Porém, quando o cliente ou usuário tem baixa disponibilidade para o projeto, as coisas podem sair um pouco diferentes do esperado.

Não estou dizendo que uma abordagem é melhor ou pior que outra. Como eu estou tentando mostrar, há vantagens e desvantagens e a abordagem ideal deve levar em consideração a cultura organizacional e o alinhamento com os objetivos estratégicos da organização.

A questão do mindset fica bem clara quando analisamos as abordagens. Um dos valores do Manifesto Ágil prega "Individuals and interactions over processes and tools". Isso significa que se deve preferir resolver um problema através da redefinição de papéis e responsabilidades ao invés de recorrer a mais ferramentas e alongar os processos desnecessariamente.

Se um problema pode ou não ser resolvido de formas mais alinhadas ao Manifesto Ágil é outra questão. Pode ser que possam, pode ser que naquela organização não possam ou ainda não se tenha encontrado uma forma de fazê-lo.

Existe um limite para o que pode ser feito pois o necessário é aquilo que se precisa para se atingir um objetivo e não adianta abrir mão de informações que são importantes para manter outras partes do processo funcionando adequadamente ou até informações que poderiam comprometer os objetivos organizacionais caso faltassem.

O limite do que é Ágil e o que não é, na verdade, é um limite móvel, que deve ser adaptado à capacidade e ao cenário de cada empresa. Assim, eu diria que uma organização que tem como objetivo se tornar Ágil, deve começar mudando seu modo de enxergar os problemas.

Tomando que uma empresa em busca da Agilidade julga como sendo melhor entre duas soluções aquela que está mais alinhada com os ideais do Manifesto Ágil, eu diria que, como sempre há uma forma de melhorar, nunca se é Ágil o suficiente.

Logo, não importa muito se há muita coisa a ser melhorada ou se está difícil enxergar onde se pode melhorar. O passo essencial para se tornar Ágil é mudar a perspectiva sobre os problemas, buscar soluções inovadoras e principalmente, mudar o mindset.

Links:
Agile Manifesto:
http://agilemanifesto.org/ (en - oficial)
http://www.manifestoagil.com.br/ (tradução do oficial)
http://en.wikipedia.org/wiki/Agile_Manifesto (en)

User Stories:
http://en.wikipedia.org/wiki/User_story (en)

Casos de Uso
http://pt.wikipedia.org/wiki/Caso_de_uso (pt)
http://en.wikipedia.org/wiki/Use_case (en)

Abraço a todos!

Bookmark and Share

Um comentário:

Postar um comentário

 
addthis_config = { data_ga_tracker: pageTracker }