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
- Ex: móvel de design feito a mão:
- Espécie de arte/artesanato de alta qualidade
- É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.
