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.

terça-feira, setembro 22, 2009

O papel do analista de Testes dentro dos processos ágeis - Uma Introdução

Ainda há muitas dúvidas no mercado acerca do papel do analista de testes dentro de uma equipe trabalhando em um processo ágil. A definição de papéis no Scrum, por exemplo, posssui apenas três elementos: Product Owner, Scrum Master e time. Isso algumas vezes leva a confusões e a crenças de que não há lugar para um analista de testes especializado num time ágil.

Esse artigo é minha tentativa de introduzir e explicar o papel do analista de testes dentro de um projeto de desenvolvimento ágil e também a mudança paradigmática que um analista de testes "tradicional" (tradicional no sentido de uma pessoa acostumada a trabalhar em equipes de testes apartadas de equipes de desenvolvimento e utilizando um processo Waterfall) deve sofrer para se tornar um bom analista de testes "agilista".

Vamos então entender e elaborar a resposta à seguinte pergunta: como o processo de testes ágil é diferente do processo de testes tradicional (cascata) e qual o papel do analista de testes em cada modelo?

No processo cascata, os testes da aplicação acontecem no final do ciclo de desenvolvimento. Nesse período é onde temos o esforço mais concentrado dos testers. A grande realidade é que o papel do analista de testes nesse modelo é muito mais reativo e não pró-ativo. É claro que existe o famoso modelo em V. Além disso, o correto num processo cascata é que os analistas de testes planejem os casos de teste em paralelo com a fase de codificação. Mas, mesmo assim, o que ocorre na prática é que a equipe de testes vive separada da equipe de desenvolvimento, correndo em linhas paralelas que só se cruzam no momento da verdade da fase de testes do modelo cascata.

E como é então o processo de testes e o papel do analista de testes no desenvovimento ágil? Nesse modelo o analista de testes passa por uma grande transformação. Ele deixa de ser reativo para se tornar um papel fundamental na interação com os desenvolvedores, analistas de negócio e clientes. Para entender melhor como ocorre essa transformação precisamos de uma ajuda do quadrante de testes ágil, do livro de Lisa Crispin e Janet Gregory:


Temos então quatro grandes grupos de testes importantes:

Q1 - Testes que focam na arquitetura e suportam o time: São os testes unitários e de componentes. Estes são realizados e são de responsabilidade dos próprios desenvolvedores. O papel do analista de testes nesse quadrante é o de apoiar, suportar e mentorizar os desenvolvedores sempre que necessário. De preferência isso é feito fazendo "pairing" com o desenvolvedor no momento de elaborar os testes unitários automatizados.

Q2 - Testes que focam no negócio e suportam o time: São testes funcionais diferenciados, que idealmente utilizam a técnica de Behaviour-Driven Development e Acceptance Test-Driven Development. Isto é, são testes e cenários de exemplo realizados pelos testadores em conjunto com os clientes, usuários e analistas de negócio. Com base nesses exemplos e cenários os desenvolvedores terão melhores condições de desenvolver e entender os requisitos. Além disso, utilizando-se ferramentas adequadas (como o Fitnesse ou o Concordion, por exemplo), uma parte desses testes serão automatizados antes ou em paralelo com o desenvolvimento do cenário. Portanto, o foco desses testes não é encontrar o maior número de defeitos e sim ajudar clientes e desenvolvedores a se entender melhor.

Q3 - Testes que focam no negócio e criticam o produto: esses são o que chamo de testes "clássicos". Os testes de aceitação feitos na homologação do produto ou de suas partes, testes beta e testes exploratórios. São os testes feitos não com o objetivo de dizer que o software funciona mas, pelo contrário, de encontrar defeitos. Essa categoria às vezes é negligenciada por alguns agilistas mais radicais. Mas a verdade é que bons analistas de testes possuem técnicas para encontrar defeitos que poucos desenvolvedores conhecem (até porque o papel do desenvolvedor é construir e o do testador, neste quadrante, é o de destruir!).

Q4 - Testes que focam na arquitetura e criticam o produto: São os testes de performance, de carga e de segurança. Esses são de responsabilidade dos analistas de testes e costumam ser feitos quando pedaços da aplicação já estão prontas e, especialmente, antes da entrada de um release em produção.

Com a explicação do quadrante é que podemos entender melhor então a transformação crucial do testador num processo ágil. A existência dos quadrantes 1 e 2 no processo ágil (e que inexistem no processo cascata) modificam de maneira fundamental o perfil e o papel do analista de testes numa equipe ágil. Ele deixa de ser reativo para também ser pró-ativo. Ele deve estar dentro do time e não fora dele em uma equipe apartada. Ele alça novos rumos e se torna também um analista de negócios, ao ajudar os clientes a criarem cenários de testes que ajudam no entendimento dos requisitos e facilitam o processo de desenvolvimento da aplicação. A Lisa Crispin aborda isso em seu livro, mas não deixa tão clara assim essa mudança radical e transformadora do papel dos testers dentro de um projeto ágil. Por isso decidi escrever esse artigo para esclarecer ainda mais esse ponto e também para deixar essas informações para aqueles que não tiveram ainda a oportunidade de ler o livro dela.

Recomendo então a todos os analistas de testes: estudem bastante o processo ágil de testes, as novas técnicas de Behaviour Driven Development e as ferramentas automatizadas que as auxiliam. Assim você se tornará um recurso muito mais valioso para sua equipe e para o resultado final dos projetos.

segunda-feira, setembro 14, 2009

O Segredo Obscuro do Agile: Agile tem tudo a ver com micro-gerenciamento!

Mike Cohn elaborou uma interessante idéia da qual concordo, mas que pode parecer uma heresia para muitos agilistas: Agile tem tudo a ver com micro-gerenciamento!!!

Sim, isso mesmo, provavelmente alguns devem ter iniciado uma fogueira para queimar os excelentes livros do Mike Cohn sobre gestão e estimativas ágeis em projetos e sobre user stories. Mas antes de riscar o fósforo deixe a idéia ficar mais clara :-) .

Diversas práticas básicas dentro de métodos ágeis estão lá para suportar o micro-gerenciamento das pessoas. Exemplos:

- O Daily Stand-up Meeting (Reunião diária de 15 minutos em pé) é um micro-gerenciamento diário do planejamento da iteração. Ele garante que todos estão fazendo ou farão aquilo que deveriam.

- A Integração Contínua é colocada para que, no instante em que um desenvolvedor cometa um erro e quebre um build, todos fiquem sabendo rapidamente.

- A programação em pares garante que os desenvolvedores não percam o foco, não façam goldplating e que limpem e refatorem continuamente o código.

Mas quem faz esse micro-gerenciamento todo? Aí vem o ponto importante: a equipe faz um auto-microgerenciamento! Isso é bem diferente de um gerente micro-gerenciar. Quando a equipe faz seu próprio micro-gerenciamento ela só tem benefícios e realiza o nirvana da auto-organização.


Veja as Estatísticas