quarta-feira, setembro 30, 2009

O papel do analista de sistemas / negócios / requisitos nos processos ágeis - Introdução

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.

13 Comentários:

At 12:58 PM, Blogger Paulooo disse...

Muito bom, deixou o papelo muito claro para os analistas!
Gostei bastante!
Sucesso!

 
At 2:27 PM, Blogger Myck disse...

Sobre sua frase "o processo de gestão de requisitos só existe por um motivo", gostaria de te perguntar se o produto do trabalho resultante desse processo também não serviria para: (a) reduzir o tempo de manutenções futuras (b) capacitação sobre o produto para uma equipe de rotatividade significativa (c) revisões internas de alta complexidade dentro da equipe Arquitetos-Desenvolvedores

 
At 2:33 PM, Blogger José Papo, MSc disse...

Olá Myck. A grande verdade é que a documentação muitas vezes até atrapalha manutenções futuras. Na maioria dos projetos que participei a documentação não era atualizada e ficava dessincronizada com a realidade do código-fonte. A melhor documentação é aquela auto-documentável. Por isso os metodologistas hoje recomendam fortemente o uso de self-documenting code. Se você precisa de documentação para capacitação de pessoas então vale mais à pena investir em criar manuais e helps para os usuários finais. Inclusive estes serão até mais úteis para as manutenções futuras.

Mas lembrando: documentação é importante. Porém, como descrito no manifesto ágil, é menos importante que software funcionando.

Abraços!

 
At 2:45 PM, Blogger Rodrigo Yoshima disse...

Excelente Post Papo! E valeu a menção honrosa. Eu vejo muito valor nos analistas de negócio, o problema é achar bons analistas. Muitos deles se escondem atrás de casos de uso e artefatos. Analista bom é avaliado na conversa com os usuários e clientes. Quem tiver tempo leia isso:

Sim! Nós agilistas temos escopo

 
At 4:02 PM, Blogger Ballack Linguiceira disse...

Olá Papo. Belo post. Uma duvida: trabalho em uma empresa que tem um produto que tem evolução constante, mediante leis, e tem vários segmentos. Concorda que necessito de uma documentação um pouco mais aprofundada de cada "versão" do produto? Como disse o Myck, para ajudar no entendimento de alterações e manutenções. Não digo uma documentação pesada e massante em milhares de docs Word, sou a favor de geração diagramas UML a partir de engenharia reversa do código corrente (garantindo a documentação atualizada) junto ao uma ferramenta de rastreamento de requisitos. Neste caso, o Analista de Requisitos (que corre atrás) tem o entendimento do negócio, visão da situação e pode prever a gravidade das alterações, riscos e impactos. Você concorda.
Outra pergunta: Concordo que todos devem ter uma atuação mais pró ativa do que reativa, e que para ser um substituto de Owner, o Analsita de requisitos pode (deve) estar um passo a frente da equipe em questão de funcionalidades que estão por vir e o seu entendimento. Você acha viável o analista de requisitos gerar artefatos que o ajude e facilite a compreensão deste entendimento, mesmo que estes não sejam em nenhum momento insumos do projeto?
Grato.

 
At 4:45 PM, Blogger José Papo, MSc disse...

Olá Ballack! Concordo que todo projeto deve possuir uma documentação minimamente suficiente. O que significa isso? Depende do produto ou sistema! Em sistemas de missão crítica pode ser necessária mais documentação. Um manual de uso sempre atualizado também se tornará um ativo extremamente valioso.

Na sua segunda pergunta também concordo. No exemplo de uma empresa que constrói um produto para milhares de usuários será fundamental fazer pesquisas de mercado e uso de outras ferramentas de marketing. Como costumam falar: o processo de planejamento colaborativo de requisitos e de marketing é muitas vezes mais importante do que o mero resultado final descrito em documentos. Não que o documento não seja útil. Ele é uma ferramenta boa para armazenar o conhecimento explícito. Mas como o papa da gestão de conhecimento Nonaka já comentava, o conhecimento tácito é o mais importante ativo de uma organização.

 
At 4:53 PM, Blogger Ballack Linguiceira disse...

Olá Papo, obrigado pelas respostas.
Duas perguntas finais: Você conhece uma ferramenta de geração de diagramas UML a partir de código Java, da Sparkx (Empresa donad o EA)?

Para obter sucesso no desenvolvimento de um projeto de software, independente da metodologia usada, é necessário ao minimo, testes de regrassão automatizados?

Grato.

 
At 6:00 AM, Blogger Conhecimentos disse...

Papo, muito bom! (sempre tem escritos ótimos weblog) Concordo com o que escreveu sobre o analista de negócio, pois este PAPEL deve existir em todo desenvolvimento de software, sendo pequeno ou extenso, sozinho ou numa equipe. Ou seja, estas atividades são imprescindíveis num processo de software (ágil ou não).

Agora, você citou sobre "auto-documentável". Teria uma ferramenta disponível para a documentação ao usuário (manual, tutorial, vídeo, outros) que pudesse ser ágil e conectado diretamente no processo de software? É que vejo a documentação de requisitos e casos de usos objetivas no desenvolvimento, pois faz parte da análise para a implementação, porém depois de concluído o software caminha para um lado a documentação fica estacionada. É lógico, que podemos utilizar técnicas de prototipação para materializar o que o usuário final irá receber no software, porém ali ainda não se tem o todo e o aprofundado do software final. Você poderia ajudar neste quesito?

Abraços,
Marco Hisatomi

 
At 10:03 AM, Blogger Jordano Gonzatto disse...

José Papo, sua introdução ao assunto é de importante análise para o papel do analista de negócios ágeis. Mas para traçar o perfil de competências para um profissional analista de negócios ágeis, podemos defini-lo, em síntese, como:
- pró-ativo
- Interativo
- adaptativo a mudanças
- capacidade de planejamento
- conhecimento multi disciplinar
- comunicação envolvente
- conhecimento técnico
- habilidade de relacionamento

Enfim, quais competências são fundamentais, na sua visão, para um analista de negócios ágeis? Obrigado. Jordano.

 
At 10:33 AM, Blogger José Papo, MSc disse...

Olá Ballack, sobre testes unitários automatizados eu gosto de usar a definição do livro "Working Effectively with Legacy Code" de Michael Feathers. Para ele um sistema legado é aquele que não possui testes unitários automatizados. E concordo totalmente com essa definição :-)

 
At 10:39 AM, Blogger José Papo, MSc disse...

Olá Marco,

Nenhuma ferramenta conseguirá gerar uma documentação para o usuário final de forma automática. Mas quem inventá-la ficará trilionário :-) . Mas creio que desenvolver manuais, usar técnicas de vídeo, montar bons materiais de treinamento, elaborar screencasts, wikis corporativos. Isso provavelmente será o futuro da "documentação", ou melhor, do conhecimento explícito. Acho que nos acostumamos demais com Word e Excel. É bom abrirmos a mente para outros formatos. Creio que nos ajudarão muito.

 
At 10:46 AM, Blogger Rafa Ballack disse...

Olá Papo. (só mudei meu nick que o antigo tava muito ruim).

Eu não captei bem a ideia, porem, para nao delongar em um assunto que nao é a essencia do seu post, vou ler o livro.

é que aki onde trablaho, realmente muda muito o código, muita alteração e versao. Agora, nao sei dizer se é o processo aqui que causa a necessidade de testar tudo que estava integro, ou se realmente é boa pratica usa testes de regressao automatico.

Grato.

 
At 11:01 AM, Blogger José Papo, MSc disse...

Olá Jordano! Todas as que você citou :-) ! Mas creio que a pró-atividade é fundamental. Sem ela o analista de negócios vira um mero escriba e tradutor de informações.

Aproveitando a todos para agradecer pelas perguntas e comentários. Eles ajudam a detalhar ainda mais as idéias e contribuem para melhorar o conteúdo da postagem original.

Obrigado!

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas