O papel do analista de sistemas / negócios / requisitos nos processos ágeis

Em um artigo anterior tratei do papel dos analistas de testes dentro dos processos ágeis. Neste artigo tratarei sobre o papel do analista de sistemas / negócios / requisitos. Lembrando que esse papel pode ser conhecido como analista de requisitos, analista de negócios ou analista de sistemas. Varia de empresa para empresa. Antes de falar sobre o papel do analista de negócio é importante detonar dois mitos sobre requisitos em projetos ágeis: que projetos ágeis não realizam requisitos e que eles não necessitam de boas práticas e técnicas de requisitos. Esse mito pode ser rebatido quando citamos as diversas práticas de envolvimento da equipe do projeto com stakeholders e usuários: Interação contínua com stakeholders, reuniões para definição do produto, demonstrações de produtos das iterações, Workshops de requisitos, gestão de mudanças e priorizações de requisitos através de um backlog de produto e a aproximação de todos os membros da equipe com o product owner. Eliminados então esses mitos sobre o processo de requisitos dentro de processos ágeis vamos à pergunta principal: qual o papel do analista de negócios dentro de um processo ágil de desenvolvimento? Vamos entender primeiro algumas atividades "tradicionais" de um analista de negócio: - Elaborar uma visão de alto nível do sistema - Servir de ponte entre os diversos stakeholders de um projeto e a equipe de desenvolvimento - Modelar e documentar necessidades e requisitos - Ajudar nos testes e validações conhecidos como testes de aceitação dos usuários - Representar os stakeholders quando a equipe não possui um cliente sempre presente O que vejo de problemas e frequentemente explico quando leciono sobre gestão de requisitos é que os analistas de negócio não podem ser meros copiadores de informação e elaboradores de atas de entrevistas. Eles devem colaborar pró-ativamente no entendimento dos problemas e necessidades dos stakeholders e ajudar na proposição de soluções e idéias para o produto final. Segundo Scott Ambler, nós temos que realizar o processo de requisitos, mas isso não implica obrigatoriamente que em todos os tipos e condições de projetos nós temos que ter analistas de negócio especialistas e só realizando esse papel. Por ajudar na melhoria da comunicação entre stakeholders e equipe, o papel de um analista de negócio ágil vai mudar consideravelmente dependendo da organização e tamanho do time. Caso 1 - Projeto pequeno com número mínimo de stakeholders. O caso extremo disso é o exemplo do projeto DDWorks feito pelo Rodrigo Yoshima. Ele desenvolveu um site com o cliente (único stakeholder) do lado dele o tempo todo. Era necessário um analista de negócio? Obviamente não. O Scott Ambler vai mais além: em uma equipe pequena, com um cliente treinado como product owner, um desenvolvedor ou analista de testes pode exercer esse papel de analista de negócio. No próprio OpenUP, na descrição do papel de Analista, está escrito que "um membro da equipe pode realizar esse papel e também o papel de testar o software". Caso 2 - Projeto grande com desenvolvimento geograficamente distribuído. Nesse cenário onde as equipes de desenvolvimento se situam em locais diferentes dos stakeholders e onde há muitos stakeholders você acabará tendo gaps de comunicação. Nesse caso o papel mais "tradicional" dos analistas de negócio será fundamental para reduzir falhas de comunicação. Um outro ponto importante é: será que um desenvolvedor pode aprender a ser um analista de negócio? E vamos mais além: será que um dos stakeholders ou clientes não podem aprender a como se tornar um analista de negócio? Obviamente que sim. Aliás, em diversos casos, é mais fácil ensinar um cliente ou product owner a ser um melhor analista de negócio que ensinar a um analista de negócio um domínio de negócio complexo. Portanto, o que idealmente devemos ter nas diversas configurações de projetos são especialistas generalistas. A pessoa pode ser especializada em requisitos, mas deve ter outros conhecimentos que ajudam o time em outros aspectos. Um conhecimento que recomendo sempre a analistas de negócio é o de saber realizar testes, especialmente os de aceitação. Outra situação é tornar um analista de negócio senior o "Product Owner" de um sistema. No RUP esse papel é conhecido como o "Campeão do Produto". O importante é lembrar que nesse cenário o analista de negócio deve focar seus esforços no domínio do negócio e colaborar com o time para atender as necessidades dos stakeholders de forma priorizada. Um analista de negócio pode virar um product owner quando há muitos stakeholders para o projeto e nenhum deles pode ficar o tempo todo com a equipe. Ou então quando o projeto vai desenvolver um produto para um mercado amplo, com milhares de usuários. Resumindo então: o processo de análise e gestão de requisitos continua existindo e é importantíssimo em processos ágeis. O papel do analista de negócio nesses processos passa a ser muito mais pró-ativo. Como já havia comentado, o analista de negócio não pode ser um passivo receptor e tradutor de informações vindas dos stakeholders para documentos formais. Ele deve fazer outras atividades no projeto, como essas: - Ele deve entender o negócio a fundo e ajudar na priorização de requisitos com base em números financeiros. - Deve trabalhar em pares com os membros da equipe de desenvolvimento, para explicar melhor os requisitos enquanto o desenvolvedor faz seu desenvolvimento dirigido por testes. - Deve criar exemplos e cenários de testes que ajudem a guiar os desenvolvedores e confirmar os requisitos e necessidades dos stakeholders. - Deve ajudar nos testes do sistema tanto durante as iterações como também junto com os usuários e clientes durante a homologação formal. Portanto a mensagem para você que é analista de negócio: tenha uma postura mais pró-ativa nos projetos, se envolva com a equipe de desenvolvimento tanto quanto você se envolve com os stakeholders. Nunca esqueça que o processo de gestão de requisitos só existe por um motivo: para mitigar o risco de comunicação entre stakeholders e equipe. O objetivo fim de todo projeto de desenvolvimento de software é criar o software, e não criar uma pilha gigantesca e indecifrável de documentações. por José Papo, MSc @ 9:33 AM no http://josepaulopapo.blogspot.com/