Especificação de requisitos na metodologia ágil?

[LuizContim 0]

Olá pessoal,

 

Estou com dúvidas conceituais sobre a metodologia de desenvolvimento ágil. Sei que muitas empresas não seguem à risca todas as boas práticas, mas gostaria da opinião de vocês sobre o que pode dá certo e o que pode não dá certo no dia-a-dia de uma equipe de desenvolvimento ágil. Sou formado em Sistemas de Informação pela USP, tive disciplinas sobre o assunto, mas na realidade nem sempre encontramos aquilo que vimos nos livros.

 

Trabalho em uma agência de publicidade, que tem os seus gerentes de projetos, a área de criação (arte), o arquiteto de informação, e os programadores. Eu fui contratado com o papel de analista de sistemas, o primeiro da empresa, aquele que deve "facilitar" o papel dos programadores, no que diz respeito ao entendimento do escopo do projeto. Percebi que muitas vezes os programadores entendiam errado as atividades, ou sentiam falta de um gerente de projetos que falasse "a mesma língua" que eles. Não sei se expliquei muito bem essa parte, mas o meu papel aqui é justamente melhorar o "meio campo" entre gerentes de projetos e desenvolvedores, fazendo especificações/documentações técnicas dos sistemas para facilitar a tarefa do desenvolvedor, e depois facilitar a realização dos testes (QA) baseados nos requisitos.

 

Mas na prática, o dia-a-dia de uma agência é muito ágil. Vejo muitas vezes os programadores partindo para a programação baseados no backlog de reuniões dos gerentes, no wireframe, ou na imagem do assistente de arte que foi aprovada pelo cliente. E os testes, após concluído o desenvolvimento, são realizados também sem "parâmetros" bem definidos, gerando uma planilha no Excel de erros que devem ser corrigidos pelo desenvolvedor.

 

Isso é uma realidade nas empresas, ou estou num lugar atípico? Existe o papel do especificador de requisitos em desenvolvimento ágil? Como introduzir essa "etapa" de especificação de requisitos numa rotina ágil? Como facilitar o entendimento das atividades pelos desenvolvedores e, posteriormente, facilitar os testes?

 

Gostaria da opinião de vocês sobre esse assunto, já que sou recém-formado e sinto que tenho uma grande responsabilidade nas mãos. Desde já agradeço!

[Okani Yori 0]

Até o momento só tive conhecimento pelas aulas e existem diferentes metodologias ágeis. Umas com foco maior na documentação, testes, desenvolvimento e etc, mas a base de todas é tentar focar no que tem que se feito sem perder tempo e de uma forma ágil.

 

Sobre os testes, com ou sem metodologia ágil, recomendo documentar bem e fazer testes válidos e interessantes, que tentam encontrar os erros e não testes que sabe que vai dar certo ou que evita achar erros. Seria interessante também documentar bem todas as etapas, desdo requisitos até os testes. Espero que alguém que já usa essas metodologias possa explicar melhor.

[LuizContim 0]

Até o momento só tive conhecimento pelas aulas e existem diferentes metodologias ágeis. Umas com foco maior na documentação, testes, desenvolvimento e etc, mas a base de todas é tentar focar no que tem que se feito sem perder tempo e de uma forma ágil.

 

Sobre os testes, com ou sem metodologia ágil, recomendo documentar bem e fazer testes válidos e interessantes, que tentam encontrar os erros e não testes que sabe que vai dar certo ou que evita achar erros. Seria interessante também documentar bem todas as etapas, desdo requisitos até os testes. Espero que alguém que já usa essas metodologias possa explicar melhor.

 

Concordo que a base de todas as metodologias ágeis é focar no que tem que ser feito, sem perder tempo. Mas aí surge uma dúvida: qual a melhor forma de indicar pro desenvolvedor aquilo que precisa ser feito? Através de um to-do list? Uma planilha de funcionalidades esperadas? Um documento de requisitos? A grande dúvida é como fazer com que o desenvolvedor entenda o que deve ser feito, de forma a evitar retrabalho, mas que seja ágil.