Quando uma empresa de software decide, baseando-se nas tendências atuais de gestão, trocar sua estratégia de desenvolvimento de um modelo baseado no Rational Unified Process (RUP) da IBM, no Capability Maturity Model Integration (CMMI) do SEI ou padrão semelhante para um método ágil como o Scrum, uma das questões que costumam aparecer com mais força é: “Devemos dividir, ou não, os papéis no time de desenvolvimento?” Isso porque, nos modelos mais formais, a divisão de papéis é a regra. Nos métodos ágeis, a tendência é não especializar com o mesmo rigor: equipes autogeridas tendem a ser mais flexíveis.

Para quem implanta um modelo de desenvolvimento baseado no RUP, a IBM disponibiliza uma tabela online de disciplinas, papéis e respectivas responsabilidades. Designa-se, para cada tarefa, uma disciplina (macroprocesso) que a agrupa, os insumos de entrada, os papéis, as ferramentas e técnicas envolvidos na sua execução, os artefatos e produtos a serem entregues.

Modelar o negócio, por exemplo, é de responsabilidade da equipe de analistas/projetistas de processo de negócio, que devem descobrir e detalhar todos os casos de uso do sistema em nível de negócio. 

Analistas de Requisitos devem descobrir e detalhar esses mesmos casos de uso em nível de requisito do produto. Arquitetos/projetistas de software devem tomar decisões tecnológicas e modelar os casos de uso a serem implementados. Implementadores e integradores devem “meter a mão na massa”, ou seja, construir o sistema. Projetistas de testes devem elaborar planos de testes e desenvolver scripts de testes, quando for o caso. Testadores devem executar os testes manuais ou automatizados planejados. Tem também o gestor de configuração, o gestor do projeto, os especialistas de ferramentas, etc.

Indo para os métodos ágeis, que inclui em seus princípios a autogestão, o panorama é outro. No Guia do Scrum, Schwaber e Sutherland dizem que “O Scrum não reconhece títulos para os integrantes da Equipe de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra.”

Comparando RUP (formal) com Scrum (ágil), percebemos abordagem claramente opostas. Devemos supor que, após mais de uma década aplicando e vendo os resultados do Scrum, a ênfase dada por seus autores a não aceitarem exceções à regra de haver apenas um único título no Time, o de Desenvolvedor, não é sem motivo. Eles perceberam que, se abrir exceções, o método descamba, por várias razões. 

Uma dessas razões é o conceito de posse coletiva: Todos os itens do Backlog da Sprint pertencem a toda equipe, mesmo que ele seja realizado por um membro específico do Time. Esse conceito reforça o espírito de equipe, tão necessário para fazer o método dar certo. 

Outro motivo é que o Scrum incorpora, em sua raiz, conceitos empíricos de Takeuchi e Nonaka relativos à gestão do conhecimento: o conhecimento vem da experiência, e a tomada de decisões deve ser baseada naquilo que é conhecido. A divisão fixa de tarefas somada à posse individual de responsabilidades inibem trocas de experiências e interações. Consequentemente, desfavorecem a colaboração e a gestão do conhecimento.

Mas se a realidade antes de Deming, McGregor e dos métodos ágeis era o comando e controle, que têm em sua base a divisão e o controle individual de tarefas, como realizar uma migração bem-feita? De uma hora para outra, não vou ter mais testadores, analistas de requisitos, arquitetos? Tudo agora vai ser um papel único, o de Desenvolvedor, como alegam ser necessário os mentores do Scrum?

A resposta para essa pergunta parece difícil de alcançar, mas está no próprio Guia do Scrum: “Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo”. 

Em outras palavras, a diferença está entre ser e estar. Nos métodos formais os papéis são fixos. Você é um analista de requisitos, um programador, um testador. Pode passar anos exercendo sempre o mesmo papel. Nos métodos ágeis, conforme o momento, você está realizando o papel de analista de requisitos, programador, testador ou o que vier em um determinado momento. 

O Time de Desenvolvimento se sente coletivamente responsável por todos os detalhes do produto que está sendo construído e colabora entrei si para resolver os problemas e impedimentos surgentes.

Tem outra questão, igualmente importante, que diferencia o comando e controle dos métodos ágeis: Quem designa quem vai desempenhar um determinado papel em um determinado momento? Se formos pelo comando e controle, a resposta é hierárquica: algum gestor com autoridade para essa decisão. 

Na abordagem ágil, o Guia Scrum sugere autogestão: “Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis.” Essa regra incluir a definição de papéis: é o Time de Desenvolvimento que, coletivamente, compreende como organizar, internamente, os papéis em cada ciclo de desenvolvimento.

* Roges Horacio Grandi e Alexandre Horn são professores da Faculdade Estácio do Rio Grande do Sul.