Ateliê de Software

3 anos depois

Gustavo Maultasch

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

Caixa Econômica - PEDES - 13/03/2018

• Aplicações bem feitas
  • Código
  • Performance
  • UX
• Com testes automatizados
  • Permitem evolução segura
• Que resolvam problemas reais
• E que satisfaçam clientes

O que buscamos

= alta qualidade

Histórico

Posto de trabalho

(até 2010)

Fábrica de software

2 contratos (2011 a 2015)

• Waterfall
• Ponto de Função

Ateliê de software

(desde 05/2015)

• Lean
• Métrica própria

Problemas

• Baixa quantidade de entrega
  • Contratada sem incentivos
• Exigência de muito controle/esforço de nossa parte para manter produtividade
  • Ausência de demandas, por exemplo, é apenas problema nosso
• Assuntos de RH acabam caindo em nosso colo

Ineficiente e caro, mas razoavelmente funcional

Problemas

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

Entrega ZERO

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

3 anos depois...

• Entrega de valor (aplicativos úteis e bem feitos)
• Redução do custo
• Lean
  • Foco no fluxo, na entrega; melhoria contínua; backlog único priorizado; limitação do WIP
• Equipe altamente qualificada (full stack; diversos projetos)
• Tecnologia
  • API first (back e front); orientação a serviço
  • Alta cobertura de testes unitários
  • Novas tecnologias (ZF2/3; nodeJS; Angular/React; Docker)
  • Rastreabilidade completa (ALM)
  • Pipeline todo automatizado
  • Feature flags / canário
  • Deploys diários sem drama

O ateliê de software

• O problema: perda de tempo para a solução de problemas laterais (ex: 60-80% em administração)
  • Consequência: menos tempo dedicado às atividades diplomáticas
• Solução esperada: sistema tradicional de GED
• Solução implementada: comunicação simplificada, desburocratizada, menos hierarquizada

Exemplo inicial: edocs

• Não é documento escaneado
• UX e menção alteram forma de trabalho
  • Linguagem mais coloquial
    • Antes: "Senhor Diretor, Muito agradeceria o obséquio de Vossa Senhoria no sentido de considerar a concessão, com vistas ao adimplemento das formalidades inerentes ao trabalho desta Divisão, de um carimbo. Respeitosamente, Fulano".
  • Menção altera o fluxo e a colaboração
    • Desburocratização; redução de formalismos
• Novas funcionalidades: hashtags; e feed com upvote/downvote (reddit)

edocs

• Não é uma "revolução"
  • Risco: "culture eats strategy for breakfast" (Drucker)
• Mas é uma mudança gradual na cultura
  • Mais colaboração, menos formalismo
• Além disso: é parte de um longo projeto para trazer o "social" para dentro da organização
  • Menos e-mail
  • Mais wikis, feeds, chats, controle de reputação (stackoverflow) etc.
• Mais plataforma, menos workflow

edocs

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 Lean Kanban e 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, e na produção

Desafios

• Modelo de terceirização dificulta investimento em pessoal
  • Contratada de TI como headhunter
  • Promoção ao longo do próprio contrato
• 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