Em 17 de maio de 2011, publicamos um artigo intitulado "Agile: Fracasso no Setor Público" em que foram apresentadas as considerações feitas por Alistair Maughan (um advogado britânico especializado na área de TI) sobre a impossibilidade prática de se adotar Agile com sucesso em órgãos do governo. Foi grande a repercussão entre os leitores do InfoQ Brasil, e vários especialistas nacionais adicionaram, nos comentários, experiências e opiniões sobre a nossa realidade, que são resumidas aqui.
Alexandre Gomes falou da sua experiência no atendimento de clientes governamentais e na dificuldade enfrentada na adoção do Agile em algumas esferas do setor público. Citou, por outro lado, que certos setores do governo estão buscando alternativas – entre elas o Agile – para melhorar o resultado em seus projetos.
Nos últimos anos, órgãos de controle e governantes superiores têm buscado os melhores modelos de gestão de contratações, para intensificar o combate aos maus contratantes e aos maus fornecedores.
Leandro Guimaraes argumentou que os órgãos do governo, no geral, não são ágeis, e questionou a forma de auditar ou justificar um projeto de software no governo, usando gestão ágil. Na opinião de Leandro, a utilização de pontos de função define uma estimativa e regras para calcular a dimensão de um sistema ou de uma tarefa, mas, ele questionou, em metodologias ágeis não deveria ser a equipe quem deve determinar a complexidade de uma história?
Alexandre Gomes avaliou em detalhes estes e outros questionamentos, afirmando que por um tempo havia aplicado os preceitos ágeis a projetos governamentais com sucesso, embora tenha enfrentando alguns problemas no final de certos projetos, bem como dificuldades em auditorias externas. E acrescentou uma pergunta:
É possível então trabalharmos na esfera pública como manda o roteiro ágil, entregando frequentemente e repriorizando a todo momento?
Continuou destacando que o governo não precisa validar ideias com o mercado para melhor identificar seu nicho de atuação:
As atribuições do governo estão escritas em leis, decretos, medidas provisórias, portarias, resoluções e tantas outras coisas. Logo, o processo de repriorização de backlog de um órgão público deve ser, pela essência de sua atividade, muito menos volátil que a de um empreendimento digital recém-inaugurado.
Alexandre completou que não é de esperar que ocorram, em um órgão público, grandes mudanças no curso de uma aplicação. Se isso vier a acontecer, na visão do TCU – o principal órgão de controle nacional, que audita os órgãos públicos – ficaria caracterizado que a gestão do órgão contratou sem necessidade concreta.
Fabio Santos trouxe à pauta o relacionamento de projetos com o retorno de investimento (ROI):
Para mim, o problema do governo é o foco. Gestores são cobrados pelo contrato e não pelo resultado dos projetos no ambiente em que serão disponibilizados. Por isso, talvez seja preciso mudar o foco e parar de medir o tamanho do software (usando story points, pontos de função, pontos de casos de uso etc.) e começar a medir o retorno do investimento. Cobrar uma equipe de desenvolvimento em cima do ROI é o princípio mais básico de agilidade. Sem isso, para mim, é impossível ser ágil.
Fernando Ultremare, identificou alguns riscos em se estabelecer uma relação visando unicamente o retorno de investimento em um projeto:
Precisamos tomar cuidado para não confundir o modelo econômico do projeto, ou seja, como o projeto é financiado para que o backlog seja implementado, com a forma que tecnicamente o projeto é desenvolvido (método). Se estamos falando de pontos Scrum, story points, ideal days (ou qualquer outra medida de técnicas ágeis), esta informação diz respeito internamente à equipe. Trata-se de sua velocidade e deve ser usada em seu processo de melhoria contínua.
Fernando ainda ressaltou que a divulgação de uma informação interna (por exemplo, a pontuação do backlog) para o público externo pode colocar em risco os valores ágeis do projeto. Com essa exposição, a equipe poderia ficar tentada a aumentar artificialmente a velocidade medida, através da manipulação da pontuação, por exemplo, visando ao atendimento de expectativas das partes interessadas.
Podemos concluir a partir das discussões que, apesar de existir grande polêmica referente aos resultados do uso ou não de técnicas ágeis em projetos governamentais, a adoção de Agile depende de uma profunda mudança de mentalidade das partes envolvidas no projeto. Outro ponto importante é o fato de projetos governamentais usualmente não possuem a mesma flexibilidade de escopo encontrada em projetos desenvolvidos em outros setores da economia.
Outra conclusão que se pode tirar é o fato de que a adoção de Agile aumenta o valor obtido em projetos governamentais, gerando evolução dos setores envolvidos. Outro ponto destacado pela comunidade ágil é que os benefícios não se restringem somente à maximização do retorno do investimento: fatores adicionais, como a melhoria contínua, o respeito e o comprometimento entre as partes, a flexibilidade, a busca pelo feedback contínuo e a aproximação com os clientes, poderiam renovar a forma que o governo se relaciona com a sociedade e talvez proporcionar maior qualidade nos serviços oferecidos pelo governo aos cidadãos.