Começamos com este artigo a série Desenvolvimento Ágil que busca esclarecer esta metodologia. Em nosso primeiro artigo realizamos uma entrevista procurando expor críticas construtivas sobre as principais práticas ágeis na visão de um conhecedor das práticas tradicionais.

Convidamos o Sr. Alex Prado de Carvalho para uma entrevista opinativa sobre as principais práticas das metodologias ágeis de desenvolvimento de softwares. O Sr. Alex Prado é gerente de Engenharia de Software na empresa TechBiz Informática, formado em Engenharia de Softwares, pós em Gestão e Tecnologia da Informação e MBA em Gestão Empresarial, detentor das certificações MCP, MCSD, MCAD, MCT, Six Sigma BB e ITIL Certificate e possui vasto conhecimento profissional nas metodologias tradicionais de desenvolvimento. A TechBiz é uma das grandes fábricas de softwares de Belo Horizonte, detentora da certificação MPS.BR nível F.

Jogo do Planejamento

Lordware: Nas metodologias ágeis, o desenvolvimento é feito em iterações semanais. No início de cada iteração a equipe se reune com o cliente para realizar o chamado Jogo do Planejamento. No Jogo o cliente propõe as funcionalidades que ele deseja, as chamadas estórias. Os programadores avaliam a dificuldade de implementar cada funcionalidade. Com essa estimativa o cliente prioriza as tarefas mais importantes para realizar na iteração.

Alex Prado: Em processos tradicionais, como o nosso, temos várias possíveis atuações. Nosso processo é Incremental e em Cascata. O planejamento é feito e acordado no início do projeto e são realizadas reuniões de acompanhamento em um período pré-estabelecido (normalmente, 15 dias). A idéia do Jogo do Planejamento é interessante, mas inviabiliza acordos de entregas no início do projeto. Em nossa experiência, sistemas maiores para empresas maiores requerem este planejamento para atendimento das necessidades de diferentes áreas.

Pequenas Versões

LW: Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção.

Com essa prática se busca a medição do cliente do quanto já foi feito; a possibilidade de que se o projeto não terminar, várias partes já foram desenvolvidas e são funcionais; e principalmente o feedback rápido do cliente para detectar problemas ou informar que uma funcionalidade não atendeu a real necessidade.

AP: Para manutenções, pode ser uma estratégia interessante. Para novos projetos isto se reverte em um complicador, em minha opinião. Este escopo negociável aumenta o risco de variação no esforço necessário para conclusão do projeto e assim também, o risco inerente ao preço. Logo, para projetos fechados, isto aumentaria o preço e reduziria a competitividade.

Projeto Simples

LW: No desenvolvimento ágil a complexidade do sistema deve ser sempre reduzida. Usa-se as tecnologias, designs, algoritmos e técnicas mais simples que permitirão atender aos requisitos do cliente. Qualquer complexidade deve ser removida assim que descoberta. Qualquer design, processo ou código criado pensando nas próximas iterações devem ser descartados.

AP: Isto sim acho muito bom e interessante. É comum vermos “propostas de otimizações” durante os sistemas, seja por capricho, entusiasmo ou mesmo “paixão” dos envolvidos. Controlar o projeto de forma a garantir que ele será essencialmente um projeto simples é um grande desafio. As metodologias tradicionais ainda não conseguiram fazer isto de forma consolidada.

Equipe Coesa

LW: No desenvolvimento ágil o cliente faz parte da equipe de desenvolvimento. A comunicação com o cliente é crucial em projetos ágeis. Em vários ramos de metodologias ágeis, é o cliente quem exerce o papel de gerente do projeto, resolvendo os problemas referentes as regras de negócio. Para evitar distorções nas informações os desenvolvedores devem sanar suas dúvidas diretamente com o cliente.

AP: Em nosso processo, temos inferências fortes com o cliente. Além de uma especificação clara e detalhada aprovada com o cliente, há reuniões de acompanhamento constantes. O MPS.BR ainda nos motivou a ir além: todos os envolvidos no projeto devem se comprometer com ele, ou seja, serem informados de suas atividades e estarem plenamente de acordo. Ainda assim, há sempre um Gerente de Projetos de nossa equipe que interage com o do cliente, não repassando responsabilidade ao cliente.

Posse Coletiva

LW: Todo o código fonte pertence a um único dono: a equipe. Assim, todo o código recebe a atenção de todos os participantes resultando em maior comunicação e menos dependência de indivíduos. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.

AP: Em sistemas maiores isto torna-se inviável. Outro ponto é a variação de experiência na equipe. Profissionais ainda com menor senioridade teriam dificuldades nesta assimilação. Trabalhamos com forte documentação em todos os níveis, inclusive dentro de nossas Classes. Há mapeamento e métodos para que qualquer um consiga avaliar os impactos em mudanças e que consiga entender o código e regras de negócio.

Padrões de Codificação

LW: A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.

AP: Extremamente importante também e item ainda pouco referido pelas metodologias tradicionais. Nós, que seguimos o MPS.BR, temos processos que garantem isto. Este são direcionados a reutilização e validação. Contudo, estes processos estão em nível mais elevados de maturidade do MPS.BR (nível E e D).

Refatoração

LW: Não existe uma etapa isolada para modelagem, o código é a modelagem. O design é melhorado continuamente através de refatoramento. Passos de refatoramento melhoram, incrementalmente, a estrutura do código, sem alterar sua função. No desenvolvimento ágil os testes são obrigatórios, assim elimina o medo de que o sistema irá deixar de funcionar por causa de um refatoramento. Sempre que um desenvolvedor perceber uma complexadade ou inclareza no sistema, deve-se refatorar o código e criar os devidos testes.

AP: Acredito que isto possa gerar forte impacto na gestão de custos do projeto, pois uma atividade não possui um fim concreto (pelo meu entendimento). Além disto, a idéia de melhoria contínua se confunde com retrabalho. Acredito e tenho tido bons resultados com a filosofia do Acordado -> Feito -> Entregue -> Aceito.

Integração Contínua

LW: Várias vezes ao dia o desenvolvedor deve integrar suas alterações, sincronizar ao repositório principal e executar todos os testes. A adoção dessa prática estimula design simples, tarefas curtas, agilidade, feedback sobre o estado atual do sistema e principalmente encontrar conflitos e erros de design rapidamente.

AP: Interessante também, apesar de que isto requere que o desenvolvedor seja um “super profissional” e distorce o conceito de “fábrica de software”. Acredito que com a participação de mais papeis nestes pequenos ciclos, seria mais eficiente.

Metáfora

LW: As equipes mantêm uma visão compartilhada do funcionamento do sistema. Para a padronização do sistema com os outros membros da equipe, são criadas analogias das funcionalidades que se refletem na escolha dos nomes de métodos, classes, campos, etc. Além de sempre buscar fazer analogias próximas a linguagem natural do cliente para facilitar a comunicação com o mesmo.

AP: Boa prática, com certeza. Não é necessariamente uma prática de metodologias ágeis (usamos algo similar em nosso processo e padronização) e com certeza é eficiente.

Desenvolvimento Orientado a Testes

LW: Antes de digitar qualquer linha de código, o desenvolvedor deverá refletir sobre a implementação e escrever o devido teste para validá-la. 100% do código deve ser coberto por testes. O teste deve ser feito obrigatoriamente antes de qualquer codificação ou refatoração. Todos os testes são executados automaticamente, o tempo todo.

AP: Não conhecia esta prática e achei muito interessante. Isto faz com que o desenvolvedor pense no seu objetivo final e em como irá validá-lo. Muto bom. Para testes unitários é algo que deve ser muito assertivo.

Testes de Aceitação

LW: São testes construídos pelo cliente para aceitar um determinado requisito do sistema. Todos os requisitos do sistema devem ser cobertos por testes. Quando o teste rodar com - e apenas com - sucesso, a tarefa é considerada finalizada.

AP: Válido e comum também. Em nosso processo temos 4 níveis de testes (Unitários, Funcionais – ou de Integração, Alpha e Beta). O que acredito faltar na prática acima é uma bateria de testes funcionais realizados pela equipe do projeto, antes de enviar ao cliente.

Ritmo Sustentável

LW: O desenvolvimento ágil busca entregar software com o máximo de qualidade e satisfação do cliente, e para isso usa o máximo de produtividade dos desenvolvedores. Para isso o ritmo deve ser sustentável com 40 horas/semana, 8 horas/dia, sem horas extras. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.

AP: Acreditamos no mesmo ideal. Isto é mais do que uma prática de desenvolvimento, é uma prática gerencial – em nível corporativo. Procuramos manter esta harmonia e ambiente favorável através do bom planejamento e cumprimento de tarefas estabelecidas.

Stand-up Meetings

LW: As reuniões no desenvolvimento ágil são realizadas em pé para não se perder o foco nos assuntos, produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe. Todos os dias em um determinado horário toda a equipe deverá se reunir e cada um dirá o que fez, fará e as dificuldades que está tendo para realizar a tarefa, buscando assim que toda equipe saiba o que todos estão executando.

AP: Muito interessante, desde que isto não sobrecarregue a produtividade da equipe. Por experiência, reuniões diárias oneram o esforço para realização de tarefas. No nosso processo, prego muito por objetividade. Não vi isto em nenhuma metodologia, isto é realmente uma definição estratégica.

Programação em Par

LW: A mais polêmica das práticas, no desenvolvimento ágil a programação é realizada sempre com uma dupla de programadores em um único computador. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros. Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado. Além disso a programação em par possibilita: simplicidade, coesão, padrão de codificação, refatoração, reflexão sobre a funcionalidade antes de codificá-la, aprimoramento do conhecimento técnico da equipe e a cobrança para que os testes sempre sejam escritos.

AP: Sem dúvidas, é a mais polêmica das práticas. Nunca vi acontecendo realmente em ambiente profissional e particularmente não acredito que seja tão produtivo. Acredito que existam outras maneiras menos “pesadas” e que permitam o desenvolvimento pessoal por meio de desafios dificuldades – sempre presentes nas empresas.

Considerações Finais

LW: Sr. Alex Prado, muito obrigado pela entrevista. Gostaria de fazer algumas considerações finais sobre o desenvolvimento ágil?

AP: Não tenho opinião formada contra ou a favor de metodologias ágeis no desenvolvimento de sistemas. Conheço a teoria mas não tive contato prático. Em ambientes corporativos não percebi também a substituição de metodologias tradicionais pelas ágeis. Novas implementações já vimos, mas a troca realmente não presenciei. Acredito que possa ser um caminho, mas ainda requer adaptações para do lado da metodologia e mudanças culturais atribuídas ao mercado.