Quem nunca ouviu, "mas é só mais campinho na tela?". Nesta palestra compartilharemos com vocês como estamos conscientizando a equipe e os demais setores da empresa da importância de avaliar o impacto de alterações nos sistemas, mesmo que sendo apenas uma linha de código. Iremos apresentar os aprendizados, desafios e erros que já enfrentamos nestes 12 meses de uso e evolução do processo de desenvolvimento na HostGator America Latina com fases/atividades mais bem definidas e a importância de perpetuar esta visão para os demais setores da empresa. Além disso, apresentar sobre o presente, o crescimento e o futuro desta nova cultura voltada a usabilidade, qualidade, escala e segurança.
Deixando de publicar em horas para publicar em minutos
Desenvolvimento de software: do planejamento à entrega de valor
1. É só mais um
Vandré M. Ramos
Software Development Manager
Lucas Rosa
Software Development Team Lead
campinho na tela!
2. Mestrado em
Administração (UFRGS)
Vandré M. Ramos
MBA em
gerenciamento
de projetos (FGV)
Pós-graduado em
Web Sistema de
Informação (UFRGS)
Bacharel em TI
(UEPG)
Gerente de Desenvolvimento
Casado
+ uma filha
de 8 anos
CSM e trabalhando
com agilidade há mais
de 11 anos ;)
Extra: Esposa ja foi QA e hoje é Agile Coach
3. Técnico em programação e bacharel em Ciência da
Computação pelo Instituto Federal Catarinense e
University of Prince Edward Island.
Tem 6 anos de atuação em desenvolvimento de
sistemas, incluindo experiência internacional com o
desenvolvimento de pesquisa no laboratório de
Interface humano-computador da UPEI no Canadá.
Lucas Rosa
Team Leader de Desenvolvimento
4. Especialidades
● Deploys com FTP;
● Testes unitários com consulta no banco;
● Automação de testes com BDD com testes unitários;
● Reverter versão do Google Chrome para funcionar
com versão desatualizada do Selenium WebDriver;
Lucas Rosa
Team Leader de Desenvolvimento
5. Fundada em 2002
nos USA
Há + de 10 anos
no Brasil
Parte do Grupo
EnduranceFundada em
2002 nos USA
Há 10 anos
no Brasil
Parte do grupo
Endurance
6. EUA + Índia
+ América Latina
+ 4.000
funcionários
+ 12 milhões de
domínios no mundo!
+ 5MM de
clientes ativos
29. Tarefas
● Análise do requisito
● Definir KPIs
● Criar o campo no front-end
○ Criar componente no React
○ Inserir o campo no estado do Redux
○ Implementar chamada de API
● Contratar um serviço externo de validação, vamos chamá-lo
de CEP3PO
● Criar contar de testes e de produção no CEP3PO
● Liberar IPs dos servidores de desenvolvimento, staging e
produção na API do CEP3PO e atualizar o nosso firewall
com os IPs deles.
● Criar lib de autenticação com CEP3PO
● Criar API no back-end utilizando o CEP3PO
e tem mais...
30. Tarefas
● ...
● Documentar integração, código, componentes e fluxo
● Testar e validar a funcionalidade
● Definir como funcionará o monitoramento das APIS, tanto a criada
por nós, quando a do CEP3PO
● Treinar o suporte interno com a nova funcionalidade
● Enviar comunicação para toda a empresa informando que uma
nova funcionalidade será implementada (com link para a
documentação)
● Deploy
● Configurar os sistemas de monitoramento com as novas APIs
● Acompanhar fluxo de clientes e relatórios de performance.
31. Medindo impacto de alterações
● Clientes internos
● Clientes externos
● Funcionalidades impactadas
● Regras de negócio
● Fluxo completo de testes
37. “Todo squad é responsável
pelos recursos que cria
durante o ciclo de vida do
produto e consegue
enxergar perfeitamente
onde cada recursos desses
acertou ou errou.”
40. Diferença entre feature, bugfix e
hotfix
● Feature: qualquer nova funcionalidade ou atualização
de funcionalidade existente;
● Bufgix: correção de não conformidade;
● Hotfix: qualquer alteração que precisa ser feita com
urgência;
○ Exemplo: alteração do valor mínimo de boletos
registrados.
41. Urgente, Importante ou Desejo
● Como avaliamos a urgência
● Score do incidente
● Bom senso
42. O tempo que se leva com retrabalho, correções de
última hora e bugs em produção é muito maior do
que o tempo investido na análise dos requisitos.
43. Quanto custa um bug em produção
1. Cliente encontra o bug.
2. Cliente reporta para o atendente de suporte.
3. Atendente de suporte reporta para supervisor.
4. Supervisor analisa o problema e reporta para o setor de produtos.
5. Product owner analisa o problema e reporta para os
desenvolvedores.
6. Desenvolvedor analisa o problema e replica em seu ambiente local.
7. Desenvolvedor corrige o problema e envia para teste cruzado.
8. Colega desenvolvedor efetua teste cruzado em ambiente local e
aprova a alteração.
9. Analista de qualidade testa a correção em ambiente de
homologação.
10. Desenvolvedor envia o código para aprovação.
11. Colegas aprovam (ou não) o código.
12. Desenvolvedor envia código para publicação.
13. Administrador do sistema faz o deploy do código.
Isso se tudo der certo!
44. Conclusão
● Sair da confusão e parar de entrar nela
● Entender o processo de negócio que a tecnologia ampara
● Estruturar um processo que apoie a empresa entregando valor
ao cliente
● Estruturar formas de medir o impacto de alterações
● Alinhar expectativas
● Investir em automação de testes
● Respirar antes de “commitar”
45. Do you want it fast
or
do you want it to last?