AgileBrazil 2010
<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>
De lá pra cá, foram mais 8.000 emails trocados,
mais de 15 conf calls, cerca de 850 inscrições,
150 submissões, 7 delas vindas do exterior, 23
empresas e 6 universidades palestrantes. Para quem já se
envolveu na organização de eventos, sabe a
trabalheira que dá e, dados esses números, tem-se
uma noção do baita feito atingido pela equipe de
organização. Um salve para todos que trabalharam
duro para presentear a comunidade brasileira com um encontro de
tão alto nível!
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
O evento já começa nesta próxima
semana, em Porto Alegre/RS, com 2 dias de cursos e outros 2 de
palestras.
A presença de alguns figurões do mundo do
desenvolvimento de software, como Martin Fowler, Philippe Kruchten e
Klaus Wuestefeld, aliada à possibilidade de
intercâmbio de ideias com uma das comunidades mais ativas
desses dias, faz do AgileBrazil uma oportunidade única para
aprendizado e expansão do networking.
A SEA estará palestrando em dose dupla
na 5ª-feira, 24/06.
Alexandre Gomes e Renato Willi, 24/06 às 11:45hs
A mentalidade industrial de nossos legisladores desenham um futuro cataclítico para a TI no setor público. Em recente debate aberto em um órgão do governo, fomos surpreendidos com afirmações dignas de 30 anos atrás. Como atores diretos deste segmento, indignamo-nos com o desejo generalizado de se fazer sempre mais do mesmo e a displicência dos envolvidos com todas as tendências pró-agilidade, sustentabilidade e eficiência que emergem mundo afora. Iremos continuar o raciocínio iniciado no evento Agiles´2009, na palestra sobre Licitações Ágeis, revisando cada conceito relacionado, analisando a atual Lei de Licitações, refletindo sobre o que deve levar pessoas tão inteligentes a pensarem desta forma e sobre como podemos mudar a inércia da máquina pública rumo ao colapso.
Arrumando a cozinha com Pomodoro, GTD, TDD e Scrum
Bruno Pedroso, 24/06 às 18:15hs
Essa palestra apresentará as metodologias Pomodoro, GTD, TDD e Scrum enquanto peças de um sistema metodológico integral. Serão apresentadas em uma visão geral e contextualizadas no novo modelo de trabalho que se desenvolve no início desse século. Serão evidenciadas suas semelhanças e os princípios em comum que as tornam coesas em um sistema com características fractais, ou auto-similares.
O problema da contratação de TI 6
<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>
A Constituição
da República Federativa do Brasil
de 1988, a.k.a
Constituição, estabelece alguns
princípios básicos sobre os quais toda a
legislação derivada deve se estruturar. Em
especial, destaca-se o princípio da
isonomia, expresso em seu
Art. 5º, que clama que:
O Art. 45 da Lei 8.666/93 (e outras leis complementares), em seu parágrafo primeiro, define 4 possíveis tipos de licitação: (i) a de menor preço, (ii) a de melhor técnica, (iii) a de técnica e preço e (iv) a de maior lance ou oferta.
Falando especialmente em termos de TI, a modalidade de licitação predominante nos últimos tempos foi a de melhor técnica e preço. Nesta modalidade, a empresa vencedora da concorrência é aquela que apresentar os melhores diferenciais técnicos e a melhor proposta de preço, conforme ponderação previamente definida pelo edital. Por diferenciais técnicos, entende-se certificações, currículos abastados, parcerias estratégicas, selos, prêmios e outros.
Só que é bem sabida a articulação política que grandes empresas fazem nos bastidores da administração pública, para o fomento e viabilização de projetos de seus interesses. Neste trabalho, influencia-se a elaboração de editais para que características únicas de suas empresas sejam inseridas como critérios de alto peso na classificação final. Como resultados, vê-se o claro loteamento do setor público, entre grandes empresas terceirizadoras de mão-de-obra, e a marginalização das micro e pequenas empresas do mercado de prestação de serviços para o governo, como deflagrado pela Operação Mainframe da Polícia Federal. Leia sobre o assunto aqui, aqui, aqui, aqui, aqui, aqui, aqui, aqui e vários outros aqui (pesquise por ‘operacao mainframe’).
 |
“O
Departamento de Proteção e Defesa da
Concorrência, da Secretaria de
Direito Econômico (SDE), do Ministério da
Justiça e o Departamento de
Polícia Federal deflagraram nesta quinta-feira, 19/03, a
“Operação
Mainframe” para a busca e a apreensão de documentos e discos
rígidos de
computadores em quatro das principais empresas de Tecnologia da
Informação de Brasília: Poliedro,
Politec, Policentro e CTIS. Os dois
órgãos abriram inquéritos -
administrativo e polícial - para investigar
suspeitas de formação de cartel e fraude em
licitações públicas
cometidas por essas empresas.” Convergência Digital |
Como forma de contornar a situação, o TCU, em conjunto à Secretaria de TI e Logística do Ministério do Planejamento, uniram-se na compilação de toda a jusrisprudência relacionada e elaboraram um conjunto de orientações, na forma da Instrução Normativa Nº 04 de 19 de maio de 2008, direcionadas a gestores públicos responsáveis pela contratação de TI.
Da IN04/2008 em diante, pouco importa a qualidade de seu produto ou serviço. Só o preço importa. Então, não adianta ser ágil, entregar valor constante e guiar-se sempre pelo ROI. Tudo isso, em nada mais importa ao governo. Importa quem tem o menor preço. E, neste menor preço, incluem-se aventureiros das mais diferentes laias, que tiram oportunidade reais de empresas sérias, e desperdiçam nosso dinheiro ao se demonstrarem incapazes de cumprirem com todas as obrigações do contrato, obrigando o gestor contratante a cancelar o contrato vigente e a iniciar um novo processo de contratação que, a propósito, não é nada rápido, e nem barato.
Bom, deste ponto em diante, sugiro que leiam o excelente post do Willi, sobre Agilidade e Licitações. O objetivo aqui foi de esclarecer conceitos iniciais da discussão. No post do Willi, há uma chamada para formação de um grupo de discussão sobre o assunto. Participem, e ajude-nos a fazer um Brasil melhor.
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