Agilidade & Licitações 14
Estamos numa espécie de cruzada na resolução deste problema, tão maior que a gente, que é o de se trabalhar utilizando metodologias ágeis no governo. As dificuldades são enormes, e ainda não há solução satisfatória, mas em que ponto estamos no momento?
No Ágiles 2009, fizemos uma apresentação sobre este tema (abaixo).
Seguida pela entrevista do Alê pelo Luiz, da Bluesoft:
Entrevista com Alexandre Gomes da SEA Tecnologia no Ágiles 2009 from Bluesoft on Vimeo.
Resumindo a conversa, devido a uma combinação de várias Leis e acórdãos do TCU, o Governo passou a considerar desenvolvimento de software como sendo um serviço comum, sendo obrigado a ser adquirido via pregão. E a unidade de software licitada é normalmente baseada numa métrica, a maioria Pontos por Função.
Uma das conseqüências do uso de pregões para aquisição de software tem sido a diminuição da necessidade de comprovações técnicas, que ocorriam nas licitações do tipo técnica e preço. Por exemplo, onde antes se pedia MPS.BR nível A, hoje aceita-se qualquer certificação MPS.BR. O mesmo vale para o CMMI. E também já faz algum tempo que certificações de profissionais não são mais pedidas como critérios de pontuação técnica, visto que a empresa não precisa ter o profissional contratado antes do início do projeto. As comprovações técnicas dos profissionais são pedidas no momento do contrato, já definido o ganhador do pregão.
Um dos objetivos dos órgãos públicos estarem diminuindo esses critérios para participação é permitir a concorrência entre mais empresas e diminuir o preço do serviço, visto que este é considerado serviço comum. Isso tende a diminuir a força e a fatia de mercado de médias e grandes empresas dentro das áreas de Tecnologia da Informação do governo (será que estavam satisfeitos com elas?). Mas vamos analisar a questão de serviço comum por um instante.
A Lei nº 10.520/02, define que bens e serviços comuns são aqueles cujos padrões de desempenho e qualidade possam ser objetivamente descritos no edital, por meio de especificações usuais no mercado. Mas observem nos slides os “objetivos” padrões de desempenho e qualidade que caracterizam software como serviço comum (e tirem suas próprias conclusões).
Acreditamos que ainda existem algumas fragilidades nessas definições para podermos considerar desenvolvimento de software como serviço comum. Por exemplo: concordamos que haver mecanismos de gestão do projeto favorece que os projetos estejam mais sob controle e que documentação aumente as chances do sistema ser melhor manutenível, mas e se forem mal planejados? Quais são os critérios de qualidade de um plano? Ou de um documento de visão? Ou de um documento de arquitetura? Quando existem, são caracterizados pela presença de tópicos (ex: documento de visão ter definição do problema, necessidades, características e definição dos usuários) e validação de um profissional. Mas isso não seria ainda muito subjetivo? Você pode definir mal o problema, as necessidades e mesmo assim esses tópicos constarem no documento. E a documentação também pode ficar obsoleta. O profissional vai usar quais critérios objetivos para validar a documentação? O mesmo vale para os questionários e aceites normalmente utilizados.
Reiterando: consideramos todos esses mecanismos válidos para aumentar as chances da qualidade do resultado, mas ainda não podem ser considerados como definitivos para tal finalidade. Por isso proporemos novos critérios, baseados em métricas de qualidade como cobertura de testes e taxa de duplicidade do código que, assim como os atuais, também favorecerão a qualidade do software entregue, bem como manutenibilidade e documentação do código.
É claro que pode-se ter um software 100% coberto por testes e ainda assim estes testes serem ruins. Nenhuma métrica totalmente objetiva jamais será perfeita. O fato é que haver testes automatizados no software aumenta as chances de ele ter qualidade, ser melhor documentado e mais manutenível ao longo do tempo.
Observe que estes critérios não resolveriam o problema da qualidade no momento da contratação, pois as métricas só seriam aferidas nas entregas. Mas, ao longo do tempo, descartando-se as empresas que não entregam software com qualidade (por exemplo, numa eventual fase de homologação), haveria uma adaptação dos produtos e do mercado para uma realidade melhor.
Por que o interesse nesses novos critérios? Porque apesar das boas intenções, as conseqüências desse formato de contratação não têm sido boas. Os preços de fato caíram muito, mas muitas empresas não estão conseguindo entregar os sistemas. E muitas delas entregam sistemas de qualidade muito ruim, o que em muitos casos deverá resultar em nova contratação para o mesmo projeto (Isso já foi noticiado na imprensa.). Ou seja, não está havendo economia de fato. Acreditamos que esse modelo tende a colapsar. Ainda há necessidade de adaptação a esse novo formato, e acreditamos que estas métricas de qualidade de código contribuem para isso.
Outra razão (mais particular), é que nós trabalhamos com testes automatizados, sabemos que isso favorece a qualidade dos sistemas e sabemos o quanto isso melhoraria os sistemas que têm sido desenvolvidos para a população. Só que até então, não observamos nenhum retorno desse diferencial. O desenvolvimento está nivelado por baixo. Então a idéia é tangibilizar essa qualidade para que seja valorizada e requerida em editais, para que todos que trabalham como trabalhamos e agregam o valor que agregamos no código possam se beneficiar disso.
Portanto, nossa próxima batalha é essa: tangibilizar a qualidade que dizemos agregar, de forma a contribuir para aumentar a qualidade do serviço de desenvolvimento de software prestado ao Estado. Depois, tentar sensibilizar o governo em quanto a isso, para que possa melhorar seus editais de contratação (quiçá, Acórdãos e Leis!). Quem tá junto nessa?
Já existe um grupo discutindo isso. Se tiver interesse em participar, mande um e-mail para renato ponto willi arromba seatecnologia ponto com ponto br.
[]s
Willi
SINFORM, Ágiles e RailsSummit 4
<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>
A maratona começou em Ilhéus/BA, com a IX
Semana de Informática da UESC,
na qual apresentei uma palestra
sobre Computação Invisível
e um mini-curso
de Ruby e Rails.
Além da turma da organização do
evento, que fez um trabalho sensacional, conheci outras grandes
figuras: Camilo Lopes
(IBM), Hugo
Santana (Google) e o Prof.
Aquiles Burlamaqui (UFRN). Foi
um prazer, caras!
Na sequência, descemos pra Florianópolis/SC para
participar do Ágiles2009,
o principal evento de metodologias
ágeis da América Latina, no qual falamos do
Manifesto
2.0 e do paradoxo Agilidade
x
Licitações.
Rolou até uma sessão de dojo no evento!
Impressionou-me neste encontro a qualidade das discussões e
o nível da galera presente. Em especial, encantou-me o
discurso do
Roy Singham, CEO da ThoughtWorks,
não apenas pela presença de palco e pela
habilidade de condução da palestra mas,
principalmente, pela grande intersecção do que
ele falou com o que nós temos falado no Manifesto
2.0. \o/ Se alguém tiver
gravado, dá um toque, por favor!
Ah, e aproveito pra mandar um salve pro Samuel Crescêncio
(@screscencio), Victor Hugo (@victogh) e pro Bruno Ghisi (@bghisi).
Muitíssimo obrigado pela recepção
fantástica que nos deram. Vocês são
foda!
Por fim, seguimos pra São Paulo/SP, para participar do
RailsSummit
2009 que, IMHO é,
atualmente, o melhor evento de
TI do Brasil. Apesar de não estarmos na
programação oficial da conferência,
tivemos a oportunidade de novamente falar do Manifesto 2.0
como uma lightning talk, que os
amigos da BlueSoft fizeram o gentil favor de filmar e publicar.
Manifesto 2.0 no Rails Summit 2009 por Alexandre Gomes from Bluesoft on Vimeo.
Como andei tuitando,
blogando
e já disse para vários colegas, o grande lance do
RailsSummit não é o RubyOnRails, mas a
comunidade que em torno dele se formou. Não sei é
pelo fato de ser constituída de gente de diversos outros
mundos tecnológicos ou simplesmente por ter nascido no
umbigo do pensamento 2.0, mas a essência dos debates
é de singular admiração.
Não vou repetir aqui o
que já disse no passado.
@AkitaOnRails está novamente de parabéns pelo
empreendimento.
E, por falar em empreendimento, deve rolar no próximo ano um
evento sobre Empreendedorismo
em TI. Fiz essa
sugestão ao final da palestra do @viniciusteles e a
galera comprou a idéia.
Muito provavelmente, será no Rio.
Atentem-se!
E, por falar em @viniciusteles, ele
o @akitaonrails
fizeram as melhores palestras do evento, em minha humilde
opinião. Portanto, não percam a oportunidade de
assisti-los.
As demais apresentações já
estão disponíveis aqui.
O @leozera nos fez um ótimo review do primeiro
e do segundo
dia, com links para os slides e tudo mais. Outras impressões
sobre o evento podem ser vistas no TrendTime.
A turma da @sea_tecnologia foi, gostou e indica a quem se interessar.
2010
Finda a maratona, é hora de retornar à vida real,
responder alguns emails e preparar o espírito para 2010 que,
AFAIK, já conta com:
- Março - Maré de Agilidade (Belo Horizonte/MG)
- Abril - MaréDeAgilidade.Gov.Br (Brasília/DF)
- ?? - Maré de Agilidade (Florianópolis/SC)
- Junho - Ágil Brasil (Porto Alegre/RS)
- Agosto - Bundle Maré de Agilidade + Oxente Rails (Natal/RN)
- Setembro - DevInRio (Rio de Janeiro/RN)
- Outubro - Ágiles (Lima/Peru), RailsSummit (São Paulo/SP)
Como diria o Guapo, e vamo que vamo!
[]s