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)

70º Fórum TIC - Dataprev - 27/10/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 (em 1 entrega)
  • 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

  • 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
    • "Vendedor ou professor"?

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
  • Devs responsáveis pela aplicação em produção

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"
    • 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"?)

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)
  • Lembra um "WBS" do PMBoK
  • 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

Exemplo: visualização de detalhamento de 1 item qualquer (o "r" do crud), com banco existente

Item do repertório USTs
Elaboração de tela (html/css/js) com componentes que exijam novos itens ou a personalização de itens do cookbook 7
Programação de 1 operação de banco (criação, leitura, atualização, remoção) no back-end, ou de criação de 1 método no Apigility, com dados submetidos  pelo front-end. (Programação completa, incluindo validação do campo, sanitização das “strings” etc.) 4
Programação de teste unitário. A programação de teste unitário será remunerada com o mesmo número de USTs da função/método/serviço que esse teste visa a testar 4
​Programação de funcionalidade no front-end, completa, com tratamento de dados, validação, submissão ao back-end e tratamento e incorporação do retorno 4
TOTAL 19

OBS: histórias, prototipação, criação de plano de deploy etc.

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

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

Made with Slides.com