BT

Agile: Fracasso no Setor Público?

por Eder Ignatowicz em 17 Mai 2011 |

Em recente artigo na Computer Weekly, Alistair Maughan fez a controversa afirmação que os projetos governamentais do Reino Unido que seguem a filosofia Agile estão fadados ao fracasso. Alistair argumenta que, apesar de concordar que – se tudo correr bem – a utilização de Agile reduzirá os riscos de um projeto de TI, a adoção de Agile não funcionará em projetos governamentais. O post gerou uma longa seqüência de comentários e discussões baseadas principalmente nos seguintes temas levantados pelo autor.

Incerteza de resultados

Alistair afirma que clientes governamentais necessitam de uma definição completa inicial do custo de um projeto de TI. Como em projetos Agile é paga uma determinada quantia de dinheiro por certo volume de trabalho, não seria possível garantir uma entrega específica para um determinado orçamento. O autor completa com a seguinte afirmação referente à complicada relação entre o governo e projetos ágeis:

Em projetos governamentais, o orçamento é gerenciado detalhadamente e deve ser aprovado por uma comissão; por isso a abordagem ágil não funcionaria. De que forma um projeto seria aprovado por uma comissão de orçamento sem possuir escopo e custos definidos?

Reparação de danos

Alistair argumenta que em projetos Agile a relação entre cliente e fornecedor é altamente acoplada, pois o cliente está fortemente comprometido com as decisões e os resultados do projeto. Ele completa afirmando que, nesta categoria de projetos, contratos são construídos de forma colaborativa e estão livres das obrigações contratuais com relação ao escopo do projeto. E se baseando nesta argumentação, faz os seguintes questionamentos:

Se existe uma relação íntima entre cliente e fornecedor, como buscar responsáveis pelo fracasso do projeto? De que forma é feita a recuperacão dos danos ou prejuízos caso o projeto fracasse?

Hierarquia rígida

O autor argumenta que o Agile não é compatível com as estruturas hierárquicas rígidas do governo, e destaca que no governo o processo de decisão é centralizado e mais lento, inevitavelmente envolvendo diversos níveis hierárquicos. Projetos ágeis, no entanto, dependem de decisões rápidas e baseadas na confiança mútua, o que inviabilizaria, segundo ele, sua aplicação no governo.

Repercussão

Em seu blog, Nik Silver realizou considerações referentes às afirmações de Alistair Maughan e aos comentários de outros leitores.

Quanto à incerteza de resultados, Nik rebate indicando que é incorreto afirmar que o orçamento de um projeto Ágil deva fundamentalmente ser aberto e flexível. Em determinadas situações isto seria plausível, mas não se trata de um pré-requisito para a aplicação de técnicas ágeis. Nik afirma que é perfeitamente aplicável gerenciar um projeto ágil com rigor orçamental. As estimativas e o planejamento são partes cruciais do processo de desenvolvimento ágil. 

Segundo Nik, um projeto pode – e deve – ser planejado com um objetivo claro de negócio; além disso, devem ser criados marcos ao longo do caminho, com estimativas acordadas entre o cliente (o departamento governamental) e os fornecedores (a equipe de desenvolvimento). Esta premissa não seria negociável:

O Agile não fornece à equipe de desenvolvimento um cheque em branco ou um período infinito de tempo de desenvolvimento. O Agile apenas requer dos envolvidos um alto grau de comprometimento.

Com relação à reparação de danos, Nik defende que entregas rápidas e frequentes não seriam a única solução para o problema da adoção de Agile no setor público. O cliente ou consumidor não pode se isentar da responsabilidade de seguir uma boa governança, e se existirem riscos ao projeto, estes devem ser identificados o mais antecipadamente possível.

Nik Silver afirma, ainda, que qualquer projeto está sujeito a riscos e que esses riscos podem ser mitigados por diversas abordagens. Segundo o autor, seguindo a filosofia Agile o cliente estará obrigatoriamente envolvido no projeto; contudo todos os participantes devem possuir obrigações claras, e estas podem ser cobradas em caso de eventuais problemas durante a execução do projeto.

Quanto à hierarquia, Nick Silver afirma que novamente a resposta para o problema reside na governança pública: 

Não há dúvida que caso cada decisão exija uma consulta ao topo da hierarquia, um projeto Agile certamente irá fracassar, devido à lentidão das decisões tomadas. 

Por outro lado, o autor pondera que se todas as decisões forem tomadas sem pareceres do alto escalão, o risco de o projeto também falhar é grande, pois pode ser desenvolvido um produto que não atende à visão global do projeto.

Concluindo, Nick Silver argumenta que o Agile se baseia fortemente na confiança no trabalho da equipe de desenvolvimento. Entretanto, a visão estratégica e a orientação fornecidas pelo alto escalão são fundamentais em grandes projetos.

Respostas

Após a publicação do post de Nik Silver, Alistair Maughan ponderou as considerações que realizou em seu artigo. Afirmou que talvez não tenha deixado suficientemente claro que considera Agile uma forma apropriada e sensata para a execução de muitos tipos de projetos. Mas na visão dele, o problema é que o governo não está pronto para as mudanças de governança necessárias para a adoção de Agile. 

A iniciativa pública é lenta e conservadora demais para atender aos requisitos necessários à adoção de Agile. Projetos públicos são normalmente observados atentamente e auditados por diversas comissões. Por isso, as equipes buscam uma metodologia padrão e segura de trabalho, que minimize os ricos inerentes aos projetos. Mas esta postura geralmente implica manter o status-quo.

O conselho de Alistair aos clientes que desejam a adoção de Agile é que mantenham os olhos abertos e preparem o ambiente para as mudanças necessárias em sua governança. Ele não está totalmente convencido de que o setor público seja capaz de modificar e otimizar suas políticas internas para viabilizar as mudanças necessárias à adoção do Agile.

 


E você, o que acha? Na sua opinião, a realidade brasileira para a adoção de métodos ágeis é similiar à do Reino Unido? Você conhece alguma iniciativa ou projeto Agile governamental executada com sucesso no país?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão
Comentários da comunidade

Causas que atrapalham a cultura ágil nas licitações públicas by Cantinho do Agile

Causas que atrapalham a cultura ágil nas licitações públicas:
O setor público geralmente exige previsão do futuro como forma de garantia nas licitações. Por isso APF e tantas certificações de qualidade nos editais;
Contrato de escopo fechado adotado pelas empresas públicas.
regards
Cantinho do Agile

Contratação pública de TI direto das trincheiras by Alexandre Gomes


Você conhece alguma iniciativa ou projeto Agile governamental executada com sucesso no país?


Sim. SERPRO, Banco Central, Petrobrás e INEP, só para citar alguns.


E você, o que acha?


Minha opinião sobre o assunto divide-se em duas fases.

Tempos extremistas

Na @SEA_Tecnologia, vivemos de contratos públicos. Respiramos isso diariamente. 98% dos nossos projetos são com o governo.

Começamos a abraçar a filosofia ágil por volta de 2006. Desde então, tentamos por diversas vezes levar a bandeira governo adentro. Até obtivemos alguns êxitos, como o da Aeronáutica, apresentado exaustivamente em vários eventos (Falando em Agile, Scrum Gathering e vários Marés de Agilidade, dentre outros), por meio da palestra 'A agilidade está no ar'. Mas o ritmo não estava sendo sustentável e as barreiras tornavam-se cada vez maiores, principalmente após publicação, em 2008, de uma Instrução Normativa do Ministério do Planejamento, que complicou deveras toda esta tentativa de aperfeiçoamento da entrega de software à administração pública. Começava ali nossa guerra contra o sistema.

No evento Agiles 2009, o @rwilli apresentou a palestra Agilidade e Licitações. No mesmo evento, dei uma opinião bem radical pro pessoal da Bluesoft. No fim do ano, escrevi um post resumindo todo o cenário, sob o meu ponto de vista. Em 2010, continuei o debate, junto com o @rwilli, no Agile Brazil, na palestra provocativa 'Desenvolver software é atividade intelectual? Pro governo brasileiro, não'.

Esta investida gerou um baita zum-zum-zum em Brasília e, entre mortos e feridos, ironicamente, toda esta agressividade acabou aproximando-nos do 'inimigo'.

Fase da paz e do amor

Ainda em 2010, depois da confusão gerada pelo Agile Brazil, tive contato com uma pessoa do TCU que me trouxe uma outra visão sobre todo este universo de software no governo. Além de ter se disposto a ouvir e compreender nossa proposta heterodoxa, foi um cara que teve total paciência em discutir os grandes nós do processo de contratação que até então nos sufocava. Já gastamos horas de conversa e ainda temos muito a debater. Tenho um blog engatilhado sobre isso. Uma hora sai.

Uma síntese de todo o papo seria apresentado no Agile Brazil 2011 mas, infelizmente, nossa proposta 'O setor público já está agindo para a melhoria das contratações de TI. Em que você pode colaborar?' foi rejeitada pelo comitê de avaliação. Este era o abstract:


A contratação pública de serviços de TI é historicamente marcada por cenas de oportunismo, abusos e ilegalidades. Protagonizadas por empresas e gestores sem compromisso com a boa aplicação do dinheiro público, o direcionamento de contratações e a atestação de serviços de má qualidade ainda são práticas comuns
no setor. Nos últimos anos, no entanto, órgãos de controle e governantes superiores tem buscado os melhores modelos de gestão de contratações para intensificar o combate aos maus contratantes e aos maus fornecedores. Esta palestra apresentará uma visão comum entre governo e mercado a respeito dos principais conceitos e orientações que suportam um bom processo de contratação pública de serviços de TI e os principais problemas que ainda afligem órgãos públicos e setor privado.



Se tudo der certo, viabilizaremos alguma oportunidade em Brasília, no 2º semestre, para esta apresentação. Sintam-se todos convidados.

A propósito, a entrevista que demos pra Bluesoft no Ágiles 2009 tem sido utilizada hoje no curso de formação dos concursados do próprio MPOG, como faísca para o debate em torno do tema de contratação pública, parte fundamental da rotina dos gestores recém contratados. Definitivamente, vejo hoje todos parte de um mesmo time.

[]s


Re: Contratação pública de TI direto das trincheiras by Jonas Beto Rompkovski

Excelente discussão. Vivo isso aqui em Curitiba com a Prefeitura. Mas considero extremamente pertinente a motivação co Alexandre Gomes e acredito que essa resposta é um exemplo para as empresas de Ti lá fora.

Re: Contratação pública de TI direto das trincheiras by Leandro Guimarães

Alexandre,

Você me parece ser um cara que está mais próximo dessa realidade. Vou comentar algumas coisas, expondo meu ponto de vista e um pouco, também, da minha realidade e gostaria que você contribuísse, se possível.

Ao meu ver, os 2 maiores complicadores para um projeto com GESTÃO (acho que existe uma diferença entre desenvolvimento ágil e gestão ágil), e vou me limitar aqui a falar em projeto scrum, são 2:

1. Os órgãos governamentais, no geral, não são ágeis.
2. Como se audita, ou como se justifica, um projeto de software usando uma gestão ágil?

Relato aqui minha experiência. Tenho trabalhado em um projeto com um órgão governamental. Temos um orçamento pré-definido e um backlog com todas as estória que, em teoria, deveriam existir. Temos trabalhado com entregas intermediárias (a cada 2 semanas) de itens priorizados pelo próprio cliente e o cliente tem ciência que o orçamento não cobre todo o backlog. Essa parte é linda.

Aonde pega? Pega que estamos enfrentando um grande problema de se obter feedbacks rápidos a respeito das entregas realizadas bem como sanar dúvidas, detalhar processos: sempre tem que envolver alguém que tá em outra atividade e esse alguém não está disponível... Nesse quesito entra o ponto 1.

Com relação ao ponto 2, entra a parte da gestão do projeto que não tem sido tão ágil. Fazemos uma review com o cliente apresentando o que foi entregue, temos acompanhamento quinzenal das atividades, conseguimos nos adequar a eventuais re-priorizações. Bonito. Maaaaaaas, utilizamos pontos de função para controlar os custos, controlar o que foi feito. E aí entra meu ponto 2 e uma outra questão: se eu tô usando qualquer metodologia para mensurar a complexidade da minha tarefa e esta metodologia foi definida por alguém, que não a equipe, já não posso dizer que meu projeto é ágil (sendo purista). A metodologia NESMA ou a metodologia IFPUG "dizem" quanto que vai "custar" (em termos de esforço e complexidade) para desenvolver uma tarefa, ou melhor, um processo elementar.

O outro ponto que levanto é, apesar dos pesares, pontos de função define uma regra (nem sempre tão clara) para que se calcule a dimensão (e não o esforço) de um sistema, de uma tarefa. Ou seja, eu e você conseguimos avaliar determinado processo sob um mesmo ponto de vista: as definições, por exemplo, da IFPUG. Quando vamos para uma gestão ágil, quando trabalhamos com scrum, quem determina a complexidade de uma estória é a EQUIPE! Utilizando critérios, nem sempre tão objetivos, definidos pela própria equipe.

Como tornar isso mensurável a ponto de que um auditor externo ao projeto (tanto no desenvolvimento quanto na utilização) consiga auditar se está tudo "dentro da lei" e não tem ninguém abusando do dinheiro público? E isso é algo que acho que não dá para ser ignorado. "Não façamos mais auditoria!". No Brasil, não funciona. Pelo menos por enquanto.

Só para deixar claro, não estou, de forma alguma, criticando as metodologias ágeis. Acho que não vivenciei nada (nos meus 10 anos de mercado de TI) tão revolucionário quanto as questões ágeis. Estou apenas problemas que vejo e tentando descobrir como podemos fazer para "derrubar" esses problemas e ser, efetivamente, agile em projetos desse porte.

Re: Contratação pública de TI direto das trincheiras by Alexandre Gomes

Leandro,

você quer a boa ou a má notícia primeiro? :-)

A boa é que você está no caminho certo. A má é que não tenho resposta pra você.

O que predomina no governo, de fato, são estimativas em APF. O que tentamos fazer nos nossos tempos de lua-de-mel com a agilidade e o governo foi:

- Entregar com a maior frequência possível
- Coletar feedback
- Ajustar o rumo
- Entregar mais uma vez
- Coletar mais feedback
- Converter a entrega realizada em pontos de função e abater da estimativa original

Isso funcionou muito bem durante um tempo, mas gerou outros problemas.

O primeiro deles foi quando o projeto chegou perto do fim, quando normalmente o cliente entra em desespero. Por mais que todo o processo tenha sido amistoso e colaborativo, o esquema mela quando o cliente percebe que a mão de obra está de partida. Aí ele começa a usar de instrumentos formais para te segurar. Conosco, aconteceu de nos acusarem de não cumprimento do contrato, mesmo após todos o histórico de satisfação das entregas que fazíamos quinzenalmente. Acabamos tendo que arcar com o prejuízo de implementação do escopo original. Foda.

Outro problema é o controle externo. Se você não cumpre o projeto básico do edital, você está correndo risco. Pode ser que o cliente, em momentos de amizade, jogue do seu lado e argumente ao seu favor mas, pode ser também, que a auditoria ocorra no período de crise e, aí mermão, é pernas pra que te quero, porque nego é bruto. Só que, tem um lado bom. O gestor público é responsável por todas as demandas. Nada é feito sem sua anuência. Logo, se sobrar pra você, pode crer que vai sobrar muito mais pra ele >:-)

De tudo isso, nasce a questão: é possível então trabalharmos na esfera pública como manda o roteiro ágil, entregando frequentemente e repriorizando a todo momento? Segundo meu brother do TCU, sim, e aí começa meu breve comentário :-P

Em sua visão, e eu concordo, o governo é um bicho estável. O governo não respira as incertezas de uma startup. O governo, em seu metiê básico, 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 um tanto de 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.

Portanto, no geral, não é esperável que aconteça em alguma autarquia pública ou em qualquer outra instância, por exemplo, o que aconteceu com o Twitter que, de um simples aplicativo de troca de status para aparelhos celulares, tornou-se na principal mídia de comunicação de ponta do mundo. Se por ventura isso vier a acontecer, na visão do TCU, é porque a gestão do órgão contratou sem necessidade concreta, e eles definem isso de um problema de governança.

Nos últimos anos, o TCU promoveu uma devassa nos contratos de TI da esfera federal. Auditou, embargou, multou e a conclusão final foi de que o real problema das más contratações não estava nas áreas de TI, mas em que as demandava. A partir daí, começaram a investigar em que pé estava o alinhamento das solicitações de TI com os planos estratégicos de cada órgão e o resultado foi desanimador pois, ao contrário do que se esperava, o gestor público em pouco se preocupa com a relevância social de seus atos. Quer dizer, pouco tem se levado em consideração, num processo de contratação, a contribuição de seu objeto para a atividade fim do órgão contratante. O relatório final está disponível na página do TCU. Dê uma olhada. Deste relatório, publicaram o Acórdão 2.308/2010 que, em síntese, busca:


9.1. recomendar (a um monte de gente) que:
9.1.1. orientem as unidades sob sua jurisdição, supervisão ou estrutura acerca da necessidade de estabelecer formalmente: (i) objetivos institucionais de TI alinhados às estratégias de negócio; (...)


Ora, mas é justamente disso que falamos na agilidade. Maximizar ROI, entregar valor, evitar o desperdício... Ou seja, o controle externo busca exatamente o mesmo que nós.

Mas, se é lindo assim, por que é que as últimas orientações (IN 04/2008 e 2010) têm nos complicado tanto a vida, como pregões eletrônicos onde se observa variações de até 10.000% entre propostas?

Minha resposta é: porque não dá pra separar o joio do trigo. Não dá pra aplicar um antibiótico sem sofrer suas consequências colaterais.

Pode até ser que o mecanismo de combate à sacanagem não seja o mais adequado. Mas é, no meu entendimento, após vários longos papos com gente do TCU, a forma mais rápida de se fazer algo contra a roubalheira.

Eu acabei sendo convencido da pouca perspectiva de se aplicar a filosofia ágil a curto prazo no governo após um diálogo semelhante a este:


- Como você gostaria que o governo trabalhasse?
- Com um fluxo contínuo de demandas, retrospectivas, feedbaks, repriorização de backlogs a todo momento para maximizar a entrega de valor etc...
- Você acha que algum comprometimento deve existir para se trabalhar assim?
- Comprometimento total de todos os envolvidos!
- Você acha que a imensa maioria das empresas prestadoras de serviço e dos gestores governamentais possuem este comprometimento?
- GLUP!


Ou seja, nossa cultura é a da sacanagem. São 511 anos de nego querendo tirar vantagem à menor oportunidade. O arroxo pós IN04 pôs um freio a isso tudo. Gerou complicações, sim. É o ônus da decisão. A proposta enviada pro Agile Brazil era pra justamente debater formas que se chegar a um equilíbrio.

Se quiser ficar mais por dentro, além de todos os links do meu comentário anterior, participe também do ciclo de debates que o TCU vem promovendo em torno do tema de Governaça de TI. É importante que estejamos todos do mesmo lado.

No segundo semestre, faremos o #MareDeAgilidade.Gov, a 10ª (ou 11ª) edição do Maré com foco exclusivo nesta dicotomia:


Como o governo pode entregar mais valor à sociedade?
Como pode a sociedade entregar mais feedback às ações governamentais?


Fica ligado.
Falei e disse.

[]s

Re: Contratação pública de TI direto das trincheiras by Renato Willi

Leandro,

Trabalhei nesses projetos que o Alê citou e vivi algumas dessas dores, deixa eu entender melhor suas questões pra tentar ajudar de alguma forma...

Sobre o ponto 1, esse problema não é privilégio de governo, software ou método Ágil. É "falha sistêmica" de qualquer organização =) , é multitarefa nociva, modelo matricial, etc. Faz parte de se mudar a cultura para que as pessoas entendam que fazem parte do processo de construção e desenvolvimento da solução.
É complicado resolver, mas dá pra melhorar tentando marcar pelo menos alguns momentos de dedicação/disponibilidade de todas as pessoas envolvidas. É uma questão política que tem que ser costurada, leva tempo, exige muita paciência, muitas habilidades interpessoais e muitas vezes pode ser frustrante. Como dizia o Capitão Nascimento, "o sistema não vai contra o sistema".

Acho que algumas poucas pessoas conseguem influenciar muito uns poucos ambientes e isso gera resultados. Depois, depende de muitos fatores para que os bons resultados sejam notados e possam influenciar outros ambientes e pessoas.

Sobre o ponto 2, não sei se compreendi direito o problema. Por que vocês querem unir a estimativa em story points e APF? Realmente não podem cobrar por story points, concordo.
A gente usava story points pra estimar e planejar o escopo dentro do tempo (o custo era o tempo, PF era mais uma dimensão de tamanho para cobrança). O que mais interessava aos gestores, nesses casos, eram as funcionalidades, visto que o orçamento do projeto como um todo já era fixado na licitação.

Eles querem controlar quanto $$ é aplicado em cada sprint? O que isso agrega de valor à solução? Isso é claro aos gestores?
Se não houver como fugir, vocês podem ter as duas dimensões em cada user story, e o PO priorizar com um parâmetro a mais ($$, tempo, benefício).
Podem fazer um burndown de verba/PFs do projeto (A gente fez isso).

Para efeitos de auditoria, claro que a métrica importa e estaria documentada a cada entrega, mas não vejo como os story points podem gerar abusos sendo usados internamente pelas equipes para estimar e planejar as entregas.

[]'s
Willi

Re: Contratação pública de TI direto das trincheiras by Fabio Santos

Para mim o problema do governo é, mais uma vez, o foco. Em alguns projetos em que participei o foco do cliente governamental está no contrato. Os gestores são cobrados pelo contrato e não pelo resultado do projeto no ambiente em que será disponibilizado.

Por isso, talvez seja preciso mudar o foco. Parar de medir o tamanho do software (story points, APF, UCP, etc) e começar a medir o ROI. Cobrar uma equipe de desenvolvimento em cima do ROI é o princípio mais básico de agilidade e, sem isso, para mim, é impossível ser ágil.

É claro que medir o ROI é mais difícil e envolve coisas mais complexas socialmente do que um contrato ou uma RFP. Mas sem esse pequeno passo acho muito pouco provável um dia experimentarmos agilidade no governo.

Cobre o ROI do seu fornecedor, envolva-o na maximização do ROI, e dificilmente seu fornecedor trabalhará contra você. Ou estabeleça um super-contrato com o seu fornecedor e faça com que ele tenha que gastar mais tempo lutando com o contrato do que trabalhando em prol da sua organização. Talvez existam tons de cinza, mas para mim, todos eles parecem muito escuros...

Re: Contratação pública de TI direto das trincheiras by Alexandre Gomes

É exatamente isso, Fábio.

E, quanto menos comprometido com o bem público for o gestor, mais focado em contrato (e menos em ROI) serão os projetos.

A dinâmica predominante é a seguinte:

O alto escalão concebe demandas arbitrárias e repassa, em caráter de urgência, aos gestores de TI. Esses, dada a prioridade imposta, sob a luz de seu descompromisso e na ânsia de proteger sua função comissionada, busca os meios mais rápidos para contratar. Para isso, recorrem a editais pré-existentes de outros órgãos, não adequados a suas reais necessidades, solicitam que empresas de mercado elaborem o documento público, naturalmente, com todos os direcionamentos possíveis, e saltam etapas essenciais do processo de validação técnica da contratada. Feita a contratação e assinado o contrato, como o objetivo predominante dos gestores é só o de tirar o seu da linha de tiro do alto escalão e dos órgãos de controle e como o objetivo predominante das empresas é o de mamar nas pátrias tetas, entra-se no ciclo vicioso dos maus gastos. E, por mais que um dos lados tenha boa fé, ele nunca consegue quebrar o ciclo sem a cumplicidade da outra parte. Uma empresa de caráter nunca conseguirá fazer um bom trabalho com gestores descomprometidos, e vice-versa.

Coincidentemente, acabei de ler o seguinte no artigo de Nihad Bassis na revista Dinâmica Pública:


Se fizermos um amplo estudo legal, acharemos de tudo um pouco, mas não com foco na melhor gestão técnica do recurso em prol da sociedade, mas sim algo mais focado em regimentar os processos burocráticos do Estado no menor custo possível.


[]s

Questão de foco e capacidade de gestão pública by Marcos Alves

Caros,

Gostaria de compartilhar uma perspectiva um pouco diferente sobre o tema. Não sou técnico, não entendo nada de codificação (embora tenha um background e bom conhecimento de tecnologia). Mas sei reconhecer e vendo os benefícios do Agile pela Dextra Sistemas (www.dextra.com.br), uma software-house que hoje é 100% ágil. Aqui eu sou gerente de negócios, responsável por contas privadas e públicas.

Esse mix privado/público é o que acredito nos fazer diferentes - e ter resultados muito bons com desenvolvimento ágil tanto em governo quanto em empresas privadas. Definitivamente não somos uma empresa focada em governo. Hoje nosso faturamento é meio a meio, sempre com o cuidado de não deixarmos a participação de governo crescer demais.

Fomos pioneiros em oferta de modelo de desenvolvimento ágil no Brasil. Começamos com a iniciativa privada quando esta ainda não comprava agilidade. E começamos com governo quando ainda era raridade. Hoje não temos nenhum projeto que não seja ágil, com muito orgulho.

Não procuramos governo. Somos procurados por ele. E é aí que eu acho que reside a diferença: o gestor que nos procura está interessado em fazer, entregar, realizar. O gestor já sofreu com fornecedores aventureiros, já apanhou dos projetos RUPianos, vem sendo cobrado internamente por resultados, e basicamente quer entregar com alguém de confiança. Isso faz toda a diferença: a postura e cabeça aberta do gestor!

Se o gestor público quer um projeto RUPiano, quer fazer mais do mesmo, quer maracutaia, a Dextra não topa. Tem fornecedores suficientes aí pelo Brasil que topam. Na nossa visão, essa postura está fadada ao fracasso e não queremos embarcar nessa.

Notem que eu não falei de tecnologia, não falei de agilidade, não falei de legislação. IMHO, desenvolvimento ágil é o que existe de mais interessante para lidar com a complexidade inerente a construção de software e gestão de expectativas de clientes. E a legislação permite, sim. É só saber o caminho legal e 100% aderente a Lei 8666, que não é fácil, mas é viável.

Logo, novamente na minha opinião, é saber encontrar os clientes públicos certos, com os gestores certos e saber fazer contratos de maneira legal e segura para os dois lados. E isso, reforçando um ponto que eu coloquei no começo, só é possível quando você não depende de clientes governamentais para sustentar a sua empresa e tem uma tremenda experiência na iniciativa privada que você não abre mão de aplicar no projeto de governo.

Existe muita gente séria no governo interessada em sair do marasmo para onde a burocracia brasileira os empurra. Têm uma postura privada e focada em resultados. Sabem envolver seus clientes internos, vender os benefícios de um projeto ágil, lidar com os departamentos jurídicos e de compras, e entregar, entregar, entregar.

IMHO, tecnologia e metodologias são escolhidas para refletir a postura da liderança. Se o gestor é mais tradicional, conservador, burocrata, RUP é o método mais seguro - e o fato de não entregar resultados não importa: o foco é a segurança. Se o gestor é ágil, busca eficiência, resultados, naturalmente é afeito a Agile.

Esse cliente é o foco da Dextra, e por isso todos os nossos projetos ágeis em governo (5 projetos grandes em 3 diferentes clientes da esfera federal) são muitíssimo bem sucedidos. Mas os escolhemos a dedo, sem vícios de outros projetos de governo.


Um abraço,


Marcos Alves

www.dextra.com.br
br.linkedin.com/in/malves
Twitter: @mvmalves

Re: Questão de foco e capacidade de gestão pública by Reinaldo Braga

Marcos,

Mas e as questões levantadas pelo Leandro Guimarães, como consegue resolve-las ?
Principalmente quando há auditorias sobre o que foi proposto e o que está sendo entregue ?
Tenho curiosidade, pois os cenários que vivi são mais parecidos com o do Leandro e o do Alexandre.

abraço,
Reinaldo.

Re: Questão de foco e capacidade de gestão pública by Marcos Alves

Oi Reinaldo,

O Leandro também trabalha na Dextra e o projeto que ele está mencionando é um dos nossos principais.

Na minha visão (ressalto bastante isso), de maneira geral, o problema é que as equipes técnicas têm uma tendência a ser puristas demais. "Ou é Agile by the book, ou não é Agile". Obviamente, até pelas limitações legais, o modelo ágil precisa ser adaptado para ser aplicado em governo e não funciona 'by the book'.

Uma das limitações é a produtividade medida por PF. Ao meu ver, isso é até bom, porque estabelece metas de resultados e produtividade que a equipe tem que alcançar (acho que o Leandro discorda disso :) ). Lembre-se que o meu ponto de vista é de negócio e gestão. Além disso, entendo que PF é muito ruim, mas desconheço métrica melhor para dar segurança a contratações públicas, então é preciso adaptar o modelo e saber jogar o jogo: aprenda a contar bem PF's e crie o backlog com o seu cliente tendo em mente as limitações da contagem.

Ou é isso (o meio termo), ou voltar aos projetos RUPianos (argh!).

Quanto a um ponto que o Alexandre colocou, parece que o agile é limitado a empresas startup. Discordo completamente. Parto do pressuposto que um dos pontos mais difíceis de desenvolver software é gerenciar as expectativas e os requisitos do usuário/cliente. O RUP tenta tratar desse aspecto gastando 50% do projeto com documentação e geração de papel. O agile tenta resolver isso - associado com técnicas de prototipação rápida - mostrando logo para o usuário telas e software funcionando para ele - o usuário - amadurecer a sua visão sobre o software. Principalmente esse aspecto de aproximação da equipe com o cliente para refinamento dos entendimentos - e não a mudança radical - é que o faz o agile tão bem sucedido. E muito relevante também para governo.

Agora, ressaltando a minha visão de que é tudo uma questão de foco e escolher os clientes certos, se o seu cliente (público ou privado) não estiver interessado em participar do projeto, for pouco responsivo, for daqueles que tira o corpo fora, e se esperar que você leia uma pilha de papel e volte 6 meses depois com um software rodando com zero erro, bem... nesse caso, o projeto desse cliente vai fracassar com qualquer metodologia. E o lado mais fraco da corrente é sempre o fornecedor. :-/

Abs,
Marcos

Re: Questão de foco e capacidade de gestão pública by Leandro Guimarães

Olá, moçada! Vamos lá: talvez eu não tenha sido claro o suficiente em minhas considerações. Li todos os pontos, postado por todos, e vou comentar alguns que me chamaram a atenção.

Alexandre,

O "pega pra capar" que você relatou que acontece no momento que a equipe está indo embora, até o momento passou longe de nossos projetos. E esperamos que continue assim. Acredito que isto esteja relacionado com os critérios utilizados pela Dextra, conforme o Marcos disse, para entrarmos ou não em um projeto público.

Só para ilustrar, no projeto que atuo atualmente, o cliente tem muito claro que o orçamento que ele tem não é suficiente para fazer o sistema completo que eles vislumbraram lá atrás. E nesse cenário, tem funcionado muito bem a priorização tendo como pano de fundo o ROI. Eles priorizam o backlog deles com aquilo que irá fornecer retorno pra eles. O que é desejável, por exemplo, fica num stand by que, se sobrar dinheiro do orçamento, trataremos estes itens num tempo futuro. E o que ele quer é conseguir um aporte financeiro maior para conseguirmos desenvolver mais coisas ao invés de pegar o contrato e ficar lendo as cláusulas para nos prender por lá.

Willi,

Temos conseguido sim obter resultados realmente muito interessantes em conseguir envolver o usuário final no processo de desenvolvimento de solução. Esse é um ponto muito elogiado pelos usuários que temos lidado. Mas ainda assim, eu acho que falta a faísca para o cara se sentir, efetivamente, como parte do processo.

Um outro ponto que julgo bastante interessante nessas nossas experiências é que temos conseguido sim mostrar para os envolvidos como é mais interessante se desenvolver um projeto com metodologias ágeis do que os meios tradicionais que eles estavam acostumados. Estamos conseguindo colocar a interrogação na cabeça dos envolvidos. O que eu acho ótimo!

Achei bem legal suas colocações a respeito do sistema. Concordo contigo que o sistema ainda é muito grande e temos que passar por muuuuuuitos degraus para conseguir, efetivamente, mudá-lo. Se é que todos esses degraus estão acessíveis para nós, pobres mortais... :) Estou passando exatamente por isso no meu projeto: meu cliente está felicíssimo com o resultado do projeto, não se cansa de elogiar a dinâmica que o projeto tomou, quer aumentar seu orçamento uma vez que tem acompanhado de forma muito rápida o retorno do que ele tem investido, tem verba pra isso, mas a autorização desse novo orçamento está parada há meses em um outro nível hierárquico e lá está esperando o outro nível hierárquico de um outro órgão que, por sua vez, está esperando pelo nível hierárquico de outro órgão e assim vai... :)

Marcos e Willi,

Sobre meu ponto 2, eu não quero unir User Story com APF nem fazer qualquer outra conversão utilizando tais métricas. Como bem o Marcos disse, e estou de pleno acordo com ele, Pontos de Função, mesmo com seus problemas, ainda me parece a forma mais segura para se tocar um projeto desse tipo. A bola que eu levanto é: temos algo melhor, e muito melhor para isso, que é a pontuação scrum.

Em Pontos de Função, muitos aspectos (design, arquiteturais) ficam descobertos e acredito que ambos os lados acabam perdendo. Na veradade ambos os lados tem que estar constatemente ligados para não perder. Tanto é verdade que, pelo o que soube, o IFPUG tem quebrado a cabeça para conseguir definir uma nova diretriz para conseguir contemplar melhor esta realidade. Porém, quer queira quer não, em APF "A regra é clara!" (nem sempre, mas ok, consideremos assim). Um auditor que não sabe absolutamente nada do projeto consegue ver, analisar, calcular e conferir com aquilo que foi dito como feito.

Com a pontuação scrum conseguimos um número muito mais real, para ambos os lados, além de conseguir, também:
- "Indivíduos e interação entre eles mais que processos e ferramentas": contar ponto de função não é das tarefas mais agradáveis;
- "Colaboração com o cliente mais que negociação de contratos": ninguém precisa caçar o contrato ou a diretriz IFPUG para ver se ela diz que é A ou B.

Só que a pontuação scrum é subjetiva. Ela é válida para uma equipe, em um determinado cenário. Os critérios são muito mais subjetivos. Nesse cenário, como conseguir justificar que aqueles tantos mil reais do governo foram utilizados para pagar Y pontos scrum no projeto W? Como tornar a pontuação scrum algo paupável para ser auditado?

Ponto de função é bom? Tem funcionado, melhor do que qualquer outra coisa, muito bem para contratos públicos (pelo menos no nosso caso). Mas o sentimento que me incomoda é: temos algo muito melhor que isso! Que vai agregar mais para o cliente e também para nós, fornecedores. O que eu quis tentar trazer pro debate foi:
- Mais pessoas enxergam que utilizar a pontuação scrum é muito melhor que utilizar a contagem de pontos de função?!
- Como será que é possível, se é que possível, transformar a pontuação subjetiva de scrum em algo mais concreto e auditável?

É isso! Estou gostando do debate!

[ ]s
Leandro

Re: Questão de foco e capacidade de gestão pública by Renato Willi

Leandro, Marcos, Reinaldo, demais,

Eu me comunicava com um grupo de pessoas interessadas na discussão (e em soluções para a problemática como um todo), que reuni a partir do post do blog sobre agilidade e licitações.

Criei uma lista contratacao-publica-ti@googlegroups.com, adicionei-os e convido todos aqui (inclusive leitores) a participarem contribuindo com suas experiências, propostas e conhecimentos sobre o tema, que é de suma importância para nós cidadãos.

[]'s
Willi

Re: Questão de foco e capacidade de gestão pública by camilo lopes

excelente discussão pessoal.Por acaso, cerca de duas semanas eu discutir isso com um colega aqui no trabalho, como ser Agile no Governo? Com os comentarios do Marcos o que chamou atenção é onde ele fala que o governo que procura a Dextra e não eles, isso já é o pulo do gato. Pois, no final da história, Agile é questão de cultura e não um processo. O governo adora ter processo para resolver as coisas.Dar para ver isso nos termos das licitações e no produto que eles querem. A lentidão e a falta de preocupação de otimização de tempo por parte do governo é algo muito cultural deles. Então tanto faz ser agile ou não.
A respeito das empresas governamentais aqui no Brasil que o alexandre citou,tem que ser levado em consideração os seguintes pontos:
- A SERPRO: é uma empresa pública, então a forma que eles conduzem o trabalho deles, deve ser mais byself.Só precisam manter as coisas funcionando.
- A Petrobras: essa aqui nao é uma empresa 100% do governo, certo? Então ela precisa está no mesmo nível das empresas privadas que são ageis em tomadas de decisões. Enfim, é a menina de ouro do governo, tem que ser tratada diferente. Os investidores são "chatos".

Enfim, é um longo caminho à percorrer com o governo brasileiro neste ponto, pois normalmente quem bate o martelo governamental e de fato vai fazer o carro andar, talvez seja um "dinoussauro".

abracos,

Re: Questão de foco e capacidade de gestão pública by Fabio Santos

Leandro,

Com relação à questão de métricas (APF, pontuação Scrum, UCP, etc) eu reafirmo que o problema ainda é de foco. Todas estas métricas medem tamanho de software, e isso não quer dizer nada para o cliente, sendo ele o governo ou não.

A única coisa que faz sentido medir (não que seja fácil) é o ROI. E nenhuma destas métricas nos dá isso. Na maioria dos casos eu tenho visto os clientes (privados ou públicos) que não medem o ROI, apenas têm um sensação sobre ele.

Acredito que seria muito benéfico começarmos a movimentar a comunidade neste sentido. Parar de medir software e medir o ROI; o benefício do software, não o seu tamanho. Tenho visto muito pouca discussão neste sentido.

Ágil Inviável? O que é viável então? by Marcos Macedo

Trabalho diretamente em desenvolvimento de software com o governo a mais de 10 anos. Já trabalhei com projetos com processos ao estilo RUP e também com ágil (basicamente XP).

Eu diria que, com respeito aos problemas citados acima o XP funciona muito melhor que o RUP. Também não vejo o ágil como problemática para contratação de ágil (acho ele mais fácil em relação ao RUP). As tentativas e problemas com TCU e normas como a IN4/2008 atingem até mais o desenvolvimento RUP do que o ágil.

Explicando nos três ítens acima:

- Incerteza de resultados: O ágil tem boas técnicas de planejamento e consegue dar muito mais certeza de resultado que , por exemplo o RUP. Na prática que eu tenho observado o RUP demora mais tempo até que eu tenha todo o requisito estável o suficiente para ele estimar o esforço do que o ágil para fazer todo o sistema. E com acompanhamento regular ao estilo XP (Jogo do Planejamento) eu consigo fechar os projetos no prazo e custo e com satisfação de resultados.

- Reparação de danos: Este é um princípio básico que a administração pública tem que ser consistente com a distribuição de responsabilidade. Há riscos? Sim. Maiores no Ágil? Não. Menores, porque você tem retorno e há monitoração constante e concreta.

- Hierarquia rígida: Novamente este problema é bem menor com XP. Isso porque você tem resultados concretos em escala constante e pontos frequentes de revisão de planejamento. Tempos muito longos (como no RUP) são problemas graves nesses contextos.

Re: Ágil Inviável? O que é viável então? by Alexandre Gomes

Marcos,

perfeita sua colocação. Criamos um grupo para continuar essa discussão (que vai loooonge): groups.google.com/group/contratacao-publica-ti. Manda esse seu comment pra lá também.

[]s

Agile: Fracasso no Setor Público? by Fabiano Nunes

Muitos profissionais empregam muito mal o conceito de Ágil por não compreender a sua real natureza, acredito que opinião Alistair Maughan foi muito infeliz e equivocada, nenhum processo de desenvolvimento ou framework para desenvolvimento de software ágil nos dizem que o escopo do projeto deve ser aberto ou fechado, o que temos no mercado são profissionais de empresas diversas recomendando que projetos ágeis tem que ter o escopo aberto, pois não encontraram forma melhor de definir custos do projeto por insegurança em saber se aquele projeto daria lucro ou prejuízo.
Mas sim em projetos ágeis podemos ter uma visão final do produto e se temos uma visão final do produto podemos sim estimar os custos de uma projeto ágil ou não, a diferença é que essa visão do produto, “de requisitos previamente definidos por um PO cliente ou representante do cliente” será planejada e executada ao longo do projeto e não no inicio dele, e se o planejamento completo dessa visão no inicio do projeto fosse garantia de alguma coisa não teríamos a longo da historia tantos fracassos em projetos de software como tivemos.
Outro ponto bem equivocado é a questão de relação cliente fornecedor, em qualquer projeto de software seja ele desenvolvido de maneira ágil ou não esta relação existira, o que vai mudar, é que em projetos ágeis o cliente ou representante do cliente (PO) deverá estar sempre em comunicação com a equipe de desenvolvimento acompanhando o que esta efetivamente sendo feito no projeto, utilizando e validando aquilo que já foi entregue, enquanto que em projetos formais o cliente só verá valor do produto no fim do desenvolvimento e se nessa hora o cliente disser a empresa ou profissional de desenvolvimento que não era aquilo que ele queria ou que esta errado, o produto será descartado e um novo projeto terá que ser feito ou refeito gerando 10X ou mais o custo daquele projeto.
Em relação a instituições governamentais brasileiras ou de qualquer outro pais, ágil é sim uma boa abordagem e o que deve ser levado em conta é que ágil deve ser adotado para desenvolver projetos de software e não para calcular os custos desses projetos e ainda que requisitos venham a emergir durante o projeto devesse ter em conta que se esse requisito alterar demasiadamente a visão inicial do produtos, estejam certos de que o mesmo projeto em um ambiente formal não chegaria ao final.

Re: Contratação pública de TI direto das trincheiras by Fernando Ultremare

Fábio, chegando até um pouco tarde na discussão, concordo contigo sobre ser mais efetivo medir ROI à medir PF, mas...

Só 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 uma técnica ágil), essa informação diz respeito internamente à equipe, se trata de sua velocidade e deve ser usada em seu processo de melhoria continua.

Quando usamos essa informação interna com um público externo (stakeholders) ai sim começamos a ameaçar os valores ágeis da equipe, e isso ocorre de formas variadas.

Independe do contrato que está por trás do financiamento do projeto, quando a velocidade da equipe tenta ser artificialmente alavancada para atender as expectativas dos stakeholders, teremos a situação acima.

Já vi isso acontecendo com escopo aberto, fechado, orientado... Utilizando PF não é diferente.

Os desafios e os riscos existem, mas sem dúvida é possível criar uma atmosfera ágil quando as partes estão realmente interessadas no sucesso do projeto.

Um abraço,

Fernando Ultremare
Twitter: @feroult

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

19 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT