Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Semelhante a Desenvolvimento de software mundo ideal x mundo real
Semelhante a Desenvolvimento de software mundo ideal x mundo real (20)
Último
Último (8)
Desenvolvimento de software mundo ideal x mundo real
- 1. Continuous LearningAve Native AppsAlley Avenue Coders Plaza DevOps Road Microservices Blvd Cloud Platform Blvd Machine Learning Ave Data Science Plaza Web Development Hwy Design Alley Digital Transformation Ave Agile Coaching Ave E-Commerce Turnpike Developers Hwy
- 2. Henrique Schmidt Willy Salazar
- 3. Desenvolvimento de Software: Mundo ideal x Mundo real Julho, 2020
- 4. Definições Qualidade vs Desenvolvimento Pirâmide de testes CI / CD Boas práticas de código Sumário 1 4 52 3
- 6. Definições
- 7. A V E NUE 7 O que é um desenvolvedor de software (dev)? Definições1
- 8. A V E NUE 8 O que é um analista de qualidade (qa)? Introdução1
- 9. A V E NUE 9 Dois mundos Definições1 Mundo ideal Mundo real ● Relato do nosso conhecimento atual em desenvolvimento de software voltado para literatura. ● Relatos de experiências nossas e de colegas na área de desenvolvimento. ● Realidade onde todas as boas práticas são aplicadas da maneira correta, de acordo com a realidade específica. ● Há restrição de dinheiro, tempo e conhecimento de pessoas envolvidas com desenvolvimento de software. ● Todas pessoas envolvidas com desenvolvimento de software entendem a importância de seguir princípios e práticas consolidadas. ● É um grande desafio para pessoas mudarem a forma de trabalho.
- 11. A V E NUE 11 2 Taylorismo ● Separação do planejamento da execução ● Criação de um departamento separado de qualidade. ● Somente gerência toma decisões Qualidade vs Desenvolvimento Frederick Taylor
- 12. A V E NUE 12 2 Toyota Production System Qualidade vs Desenvolvimento Taiichi Ohno ("Pai" do TPS) Shigeo Shingo ("Pai" do TPS e Poka Yoke) ● Todo trabalhador é responsável por toda a linha de produção. ● Kaizen - Melhoria contínua ● Just in time ● Sistema para evitar falhas humanas (Poka Yoke)
- 13. A V E NUE 13 Comparação Qualidade vs Desenvolvimento2 Mundo ideal Mundo real ● QAs trabalhando junto com os Devs. ● Devs entregam um software para QAs testarem. ● Código de teste é desenvolvido junto com código de produção. ● Código de produção é desenvolvido, sistema é publicado e então os testes são desenvolvidos. ● Segundos após a escrita de um código é possível saber se ele tem a qualidade necessária. Sem estoque de código. ● Dias ou semanas após a escrita de um código é possível saber se ele tem a qualidade necessária.
- 14. Custo vs Tempo de descoberta do bug
- 16. A V E NUE 16 Pirâmide de testes3 Autor: Martin Fowler
- 17. The act of writing a unit test is more an act of design than of verification. Robert C. Martin (Uncle Bob)
- 19. A V E NUE 19 Casquinha de sorvete Pirâmide de testes Muitos testes manuais de interface. Alguns testes de integração e end-to-end. Muito poucos testes unitários. Place your image here. Try to keep your image within these boundaries. And remove this text box later! Again, remove this text box later! One more time: remove this text box later! 3
- 20. A V E NUE 20 Comparação Pirâmide de testes3 Mundo ideal Mundo real ● Poucos testes end-to-end para garantir as jornadas dos usuários. ● Muitos testes manuais repetitivos. ● Muito pouco teste manual, principalmente exploratórios. ● Muitos testes de integração e end-to-end. ● Muitos testes unitários, melhorando o design de código. ● Poucos testes unitários, deixando o design de código ruim.
- 21. CI/CD
- 23. A V E NUE 23 Continuous Integration CI/CD Prática de desenvolvimento de software onde Devs/QAs integram o código com uma branch principal frequentemente. Integrando frequentamente, é possível detectar e corrigir erros mais rápidamente e diminuir problemas de merge. 4
- 24. A V E NUE 24 Continuous Delivery CI/CD Prática de desenvolvimento de software onde o software é construído de uma forma que pode ser publicado em produção a qualquer momento. Testes automatizados são uma peça chave para Continuous Delivery ser possível. 4
- 25. A V E NUE 25 Continuous Deployment CI/CD Um passo além de Continuous Delivery, onde toda alteração de código é automaticamente publicada em produção, se toda pipeline passar. A grande vantagem é que não há mais a pressão de um “dia de deploy” e pode-se receber feedback mais rápido dos usuários. 4
- 26. A V E NUE 26 Comparação 4 Mundo ideal Mundo real ● Os testes automatizados dão confiança para o time que o software pode ser publicado em produção. ● O time precisa passar por uma fase de testes manual para ter confiança no código fonte. ● O time não passa horas/dias resolvendo conflitos. ● Desenvolvedores trabalham muito tempo em branches separadas e merges pode levar horas/dias. ● Sem “estoque” de código. O time tem um feedback rápido dos usuários sobre as alterações. ● Estresse em dias de deploy, demora para receber feedback de usuários.
- 28. I'm not a great programmer; I'm just a good programmer with great habits. Kent Beck
- 29. Nós somos aquilo que fazemos repetidamente. Excelência, então, não é um modo de agir, mas um hábito.Aristóteles
- 30. A V E NUE 30 Análise estática de código Análise de um código-fonte sem execução do programa. Boas práticas de código5
- 32. A V E NUE 32 Complexidade Ciclomática Métrica que pode ser utilizada para detectar código complexo e candidato a refatoração. Mais avançada do que simples número de linhas. Definido por Thomas J. MCCabe, 1976 Boas práticas de código5
- 35. A V E NUE 35 SOLID Princípios de programação orientada a objetos com o objetivo de deixar o design do software mais legível e flexível. Boas práticas de código5
- 36. A V E NUE 36 Design Patterns Soluções típicas para problemas comuns em desenvolvimento de software. Boas práticas de código5
- 37. A V E NUE 37 Code Review Prática que aumenta a Propriedade coletiva do código. Boas práticas de código5
- 38. A V E NUE 38 Comparação Boas práticas de código5 Mundo ideal Mundo real ● Código com funções e classes pequenas e fáceis de entender. ● Código com algumas classes e funções grandes e de difícil entendimento. ● O time utiliza ferramentas de análise estática de código diariamente. ● O time não utiliza ferramentas de análise estática de código. ● O time tem um processo consistente de code review. ● Cada desenvolvedor adiciona novas features com a única preocupação de atender o prazo da demanda. ● Todos devs do time se sentem confiantes para alterar qualquer parte do sistema. ● Cada parte do sistema tem um desenvolvedor como responsável.
- 39. Agilidade
- 40. A V E NUE 40 Cascata Processo sequencial de desenvolvimento de software. Agilidade6
- 41. A V E NUE 41 Manifesto ágil Agilidade6
- 44. A V E NUE 44 Comparação Agilidade6 Mundo ideal Mundo real ● Time entrega software funcionando frequentemente. ● Time raramente faz entregas de software funcionando. ● Time está preparado e recebe bem mudanças no software. ● Time trabalha bastante na fase de análise para evitar mudanças depois. ● Pessoas de negócio estão próximas dos desenvolvedores no dia a dia. ● Desenvolvedores e pessoas de negócio raramente conversam. ● O time decide a melhor forma de solução do problema. ● Pessoas de fora do time decidem como as soluções são desenvolvidas.
- 46. A V E NUE 46 Inglês Indicações de estudo7
- 47. A V E NUE 47 Indicações de estudo7 Livros
- 48. A V E NUE 48 Universidade de Automação de Testes Indicações de estudo7
- 49. A V E NUE 49 Referências Indicações de estudo7 Angie Jones Elias Nogueira Julio de Lima Joe Colantonio
- 50. A V E NUE 50 Referências Indicações de estudo7 Martin Fowler Kent Beck Uncle Bob Eric Evans
Notas do Editor
- Pessoa que o principal papel é escrever a solução para resolver um problema do negocio
- Pessoa que o principal papel é garantir que a solucao desenvolvida pelo time tem a qualidade necessária para o negocio
- Não há verdade absoluta ou balas de prata, desenvolvimento de software é uma área complexa. Relato do nosso conhecimento atual em desenvolvimento de software. Realidade onde todas as boas práticas são aplicadas da maneira correta, de acordo com a realidade específica. Todas pessoas envolvidas com desenvolvimento de software entendem a importância de seguir princípios e práticas consolidadas. Relatos de experiências nossas e de colegas na área de desenvolvimento. Há restrição de dinheiro, tempo e conhecimento de pessoas envolvidas com desenvolvimento de software. É um grande desafio para pessoas mudarem a forma de trabalho.
- Extreme programming -> Kent Beck Engenharia social do taylorismo -> Engenheiros "educados" decidem como deve ser feito e os trabalhadores fazem o que são mandados "cegamente". Autoridade vs Responsabilidade: Arquitetos mandando como deve ser feito e não fazendo junto com o time. Taylor acreditava que os trabalhadores iriam trabalhar mal mas não tão mal para serem notados, por isso, era importante ter um departamento de qualidade. Inovações do Taylorismo Um de seus maiores legados foi “Princípios da Administração Científica”, livro que basicamente expõe a crença de Taylor na racionalização do trabalho. - Princípio do planejamento; - Princípio da preparação dos trabalhadores: - Princípio do controle: - Princípio da execução; Críticas ao taylorismo - exploração e mecanização do trabalhador - As ideias dos trabalhadores eram reprimidas e cabia somente à gerência tomar decisões quanto à produção, gerando também descontentamento e conflitos entre empregados e empregadores.
- Se qualquer pessoa encontra um problema, puxa uma corda e toda a linha de produção é parada. Todos recursos da linha de produção são focados para encontrar a causa raiz e resolver o problema. Kaizen -> Kai (Change) + zen (Good) Kaizen dá voz à força de trabalho, capacitando os indivíduos para identificar áreas para melhoria e sugerir soluções práticas. Controle de processo para melhorar a qualidade como um todo. Just in time -> a matéria prima sempre vai chegar na fábrica na hora em que se precise dela Com o Just in Time não existe sobra de estoque, tudo que é fabricado já tem um destino final certo. Isso se aplica em software, onde não faz sentido estocar requisitos, código, documentação. Se se escrever codigo que só vai ser usado em 6 meses, ele muito provavelmente terá que ser reescrito ou não vai funcionar.
- 8:20
- Mike Cohn came up with this concept in his book Succeeding with Agile. It's a great visual metaphor telling you to think about different layers of testing. It also tells you how much testing to do on each layer. End-to-end (e2e) tests are used to simulate the user journey. So the answer to this question is yet another question — how many user journeys exist in your application? https://martinfowler.com/bliki/TestPyramid.html Talvez mostrar diferentes piramides
- O ato de escrever um teste de unidade é mais um ato de design do que de verificação.
- 8:30
- Não é um ótimo programador, mas um bom programador com ótimos habitos.
- PlataformaPlataforma open-source para inspeção contínua de código-fonte. Tem suporte para mais de 20 linguagens de programação. open-source para inspeção contínua de código-fonte. Tem suporte para mais de 20 linguagens de programação.
- Padrão de solução para problemas comuns. Melhora comunicação entre equipe de desenvolvimento.
- Menos revisão e mais colaboração
- 8:45
- Criado em 2001, é uma declaração de princípios que fundamentam o desenvolvimento ágil. https://agilemanifesto.org/iso/ptbr/manifesto.html Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
- Princípios por trás do Manifesto Ágil Nós seguimos estes princípios: Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. Software funcionando é a medida primária de progresso. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. Contínua atenção à excelência técnica e bom design aumenta a agilidade. Simplicidade--a arte de maximizar a quantidade de trabalho não realizado--é essencial. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
- Busca de materiais Documentacoes Referenciais Empresas Internacionais
- Clean Code (Uncle Bob (Robert C. Martin)) TDD by example - Kent Beck Extreme Programming Explained - Kent Beck The Scrum Guide ( Ken Schwaber and Jeff Sutherland) Head First Design Patterns (Elisabeth Freeman, Kathy Sierra) Domain-Driven Design - Tackling Complexity in the Heart of Software (Eric Evans) Agile Testing (Lisa Crispin)