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)

Caixa Econômica - 22/11/2016

Histórico

Até 2010

Problemas

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

Problemas com o modelo

Processo industrial de desenvolvimento

• Programação não é atomizável
• Programação não é repetitivo
• Deseconomia de escala

Processo industrial de desenvolvimento

• Entregas lentas
• Pouca iteratividade
  • Dificuldade de lidar com mudanças
• Remuneração por papel (paradoxo do lucro-papelada)
• Muita responsabilidade na mão do cliente
  • Cliente lendo caso de uso?
  • Software ou álibi?

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
  • Geralmente fixo em contrato/roteiros/manuais

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 emergente de aprendizado e criação (não redutível a processos bem definidos)
    • Práticas técnicas (XP)
• 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,5 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
• Responsabilidade assumida pela TI (sem álibis)
  • Com o devido poder sobre o projeto ("ultimatos", cancelamentos)
• Investimento "agressivo" em capacitação

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

Aprendizados

• Funcionar é o mínimo
• Pixel-perfect
  • Recusa de entregas por defeitos mínimos
• Devs responsáveis pela aplicação em produção

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

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"
  • Conforme a necessidade de agregação de valor da sprint
  • Muita comunicação
    • Requisitos às vezes implícitos: quando o custo de refinar é maior do que o de aprimorar
  • Criatividade diante de desafios (Taiichi Ohno)
• Visão de produto > visão de projeto ("Manutenção"?)

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)
• Lembra um "WBS" do PMBoK
• Definição da produtividade diária (7 USTs/dia)
• Redução do custo!

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

Desafios

• Modelo de terceirização dificulta investimento em pessoal
  • Contratada de TI como headhunter
• Faturamento da empresa deveria ser maior
  • "Furos no cano"
• Evitar o conforto (melhoria contínua)
• Desafios técnicos (testes de front, deploys etc.)

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