Ateliê de Software

Superando o modelo de “fábrica” a partir do

“Software Craftsmanship”  


Gustavo Maultasch

Chefe da Divisão de Informática do Itamaraty (MRE)

Agile Trends GOV - 09/08/2016

Histórico

Até 2010

Fábrica de software

2 contratos (2011 a 2015)

  • Waterfall
  • Ponto de Função

Problemas

  • Atrasos surreais
    • 2 anos (ou nunca entregues)
  • Baixíssima qualidade nas entregas
    • +50 bugs
  • Altíssimo turn-over

Entrega ZERO

Problemas com o modelo

Métrica (ponto de função)

Filosofia/concepção (fábrica)

Metodologia (Waterfall/RUP)

Processo industrial de desenvolvimento

Divisão de tarefas

Controle estrito do processo

+

=

Esquece-se da importância de uma equipe altamente qualificada

  • Deseconomia de escala
  • Programação não é repetitivo

Processo industrial de desenvolvimento

  • Entregas lentas
  • Pouca iteratividade
    • Dificuldade de lidar com mudanças
  • Remuneração por papel (paradoxo do lucro-papelada)

Lenta agregação de valor

Problemas do Ponto de Função

  • Medida do escopo ≠ Medida do recurso e do tempo (Baixa legibilidade)
  • Não permite remunerar a qualidade
    • Ex.: testes automatizados, front-end rico
  • Não permite remunerar evoluções de processo

Alguns anos depois...

Software Craftsmanship

  • Craft
    • Espécie de arte/artesanato de alta qualidade
      • Ex: móvel de design feito a mão:
        • Precisa funcionar
        • Bom design, bom acabamento, boa durabilidade
  • Ética do craft - profissionalismo
    • Fazer algo bem feito pelo dever de se o fazer
    • Responsabilidade pessoal pelo seu produto

Software Craftsmanship

  • Software: craft é uma metáfora melhor
    • Desenvolver software não é atividade fabril
    • Atividade de criação (não redutível a processos bem definidos)
  • Não basta funcionar; tem de ser bem-feito
    • Confiabilidade, Manutenibilidade
  • Equipe altamente qualificada é o centro de tudo
    • Nenhum processo vai te salvar

Ateliê de Software no MRE

 

 

1 ano depois...

Aprendizados

  • Conhecer (e explicar) bem sua capacidade
  • Limitação do número de projetos (WIP)
    • Alinhamento com a alta gestão
  • Ferramenta de ALM

Aprendizado 1: a gestão da TI deve estar bem organizada

Aprendizados

  • Full-stack
    • Sem divisão de perfil (requisitos, analista etc.)
    • Não há equipe separada de testes/QA
  • Diligência prévia de capacidade
  • Pirâmide invertida (senior >= pleno >= junior)
  • Rodízios (ferramenta de ALM; projeto; back/front)
  • Estudo de código
  • Novas tecnologias - Labs/Dojos

Aprendizado 2: a equipe de devs deve ser altamente qualificada, motivada e com senso de responsabilidade

Aprendizados

  • Funcionar é o mínimo
  • Pixel-perfect
    • Recusa de entregas por defeitos mínimos

Aprendizado 3: expectativa alta contribui para a qualidade

Aprendizados

  • Delegação de responsabilidade aos devs
    • Equipe exigida em tudo, do negócio ao deploy
  • Mas...:
    • Autonomia de trabalho
    • Respeito à opinião técnica (inclusive prazos)
    • Divisão do risco
      • PO é sempre da TI
      • Problemas são vistos como oportunidades para melhoria contínua

Aprendizado 4: responsabilidade deve ser retribuída com poder e respeito

Aprendizados

  • Começamos com "scrum simplificado" e fomos o adaptando...
    • Melhoria contínua (insatisfação construtiva)
    • Retrospectivas e lições aprendidas
  • ...e chegamos ao "um método por projeto"
    • Adaptar o processo conforme a necessidade de agregação de valor da sprint
    • Muita comunicação
    • Criatividade diante de desafios (Taiichi Ohno)

Aprendizado 5: processo é menos importante do que criatividade

Aprendizados

  • Repertório de estimativas próprio e atualizável
    • Permite remunerar testes unitários, spikes, protótipos, análises exploratórias etc.
  • Baseada em esforço (avaliação empírica)
  • Definição da produtividade diária (7 USTs/dia)
  • Redução do custo!

Aprendizado 6: métrica própria baseada em esforço real funciona melhor

Aprendizados

  • Nada é remunerado sem aprovação prévia
    • Eventuais erros/imprevistos são arbitrados em boa-fé
  • Nada é remunerado sem entregável; mas, mais ainda:
    • Nada é pago sem código

Aprendizado 7: aprovação prévia é fundamental

Equipe do TR

  • Min. João Pedro
  • Min. Nestor Forster
  • OC Thiago Weiprecht
  • ATI Adriano Soares
  • ATI Anderson Braga
  • ATI Gustavo Macedo

Agradecimentos

  • Alexandre Gomes
  • Flávio Alves
  • Ricardo Poppi

A toda a equipe do MRE

Referências

  • McBreen, P. Software Craftsmanship: The New Imperative
  • Sandro Mancuso
    • https://www.youtube.com/watch?v=9OhXqBlCmrM
  • Robert C. Martin
    • https://www.youtube.com/watch?v=QJxXUQIeB6E
  • The Programmer's Oath
    • http://ronjeffries.com/articles/015-11/oath/
  • Manifesto for Software Craftsmanship
    • http://manifesto.softwarecraftsmanship.org/

Obrigado

@ghmol

 

slides.com/gustavohmo

Ateliê de Software – Superando o modelo de “fábrica” a partir do “Software Craftsmanship”

By Gustavo H. Maultasch de Oliveira

Ateliê de Software – Superando o modelo de “fábrica” a partir do “Software Craftsmanship”

Apresentação realizada no Agile Trends Gov, em 9 de agosto de 2016. Resumo: Após 4 anos de experiências mal sucedidas com contratos tradicionais de “fábrica de software” (com RUP e ponto de função), o Itamaraty concluiu que o problema que tinha não era de gestão de contrato, mas sim fruto do próprio conceito de “fábrica de software” e do modelo de fiscalização que o acompanha. Após estudar alternativas por 1 ano, o Itamaraty fez nova licitação, baseada na filosofia do “software craftsmanship” e em suas lições aprendidas. Esse novo modelo, chamado de Ateliê de Software, traz uma série de inovações. Este talk detalhará os problemas do modelo de “fábrica de software” e a implantação do Ateliê de Software no Itamaraty.

  • 2,551