desenvolvimento de software: uma abordagem sistêmica

Desenvolvimento de Software

Uma abordagem sistêmica

Novembro/2014UDESC – São Bento do Sul

Desenvolvimento de Software: uma abordagem sistêmica

Quem é esse ?

● Rafael Vitor Rodrigues Pina Pereira– Engenheiro Eletricista, UFSC 1996

– MBA em Tecnologia da Informação, FGV 2003

– Certificação PMP/PMI, 2005

– 20+ anos de experiência em desenvolvimento de software, gestão de equipes, produtos e projetos de sistemas de missão crítica para o mercado de telecomunicações e TI

– Gerente de arquitetura de sistemas e hardware – Dígitro Tecnologia

– Professor titular de Engenharia Elétrica, Unisul 2004-2011


Agenda

● Introdução● Histórico● Pessoas● Levantamento de requisitos● Principais metodologias e frameworks● Testes● Refactoring● Integração contínua● Certificações


Introdução

● O desenvolvimento de software envolve várias dimensões que precisam ser consideradas nos projetos;

● Há que se considerar tecnologia, pessoas, estratégia de negócio e time to market, dentre outras;

● Utilizar um modelo pronto sem a devida adaptação à realidade do projeto normalmente não apresenta bons resultados, sendo mais interessante trazer as melhores práticas, técnicas, processos e métodos disponíveis e então adaptá-las ao ambiente;

● Nessa palestra serão abordadas algumas metodologias, processos e ferramentas que podem ajudar a obter um melhor resultado nessa disciplina que mistura técnica e arte.


Pessoas !

● A chave para tudo !– Por enquanto, o software não

vai se escrever sozinho

● Motivadas, são um motor, desmotivadas, um freio

● Precisam ser envolvidas nas definições dos processos e metodologia


Pessoas

● Desenvolvimento de software é atividade criativa– É preciso usar o melhor de cada uma

– Integrar diferente papéis e dar autonomia

– Delegar e cobrar resultado

● Um bom técnico não necessariamente será um bom gestor

● A importância da capacidade técnica nos gestores próximos à equipe não pode ser negligenciada


Levantamento de requisitos

● A raiz e a solução de boa parte dos problemas● Ajuda a criar a metáfora do produto● Requisitos não funcionais são tão importantes

quanto requisitos funcionais– Usualmente, o cliente não enxerga os não

funcionais, é responsabilidade da equipe

● Validação com os stakeholders é fundamental– Independentemente da metodologia utilizada !


Levantamento de requisitos

● Backlog do produto

● Backlog da release

● Backlog da interação

O detalhamento vai crescendo, as estimativas são mais assertivas e a equipe tem mais precisão sobre o que será construído


Resultado do relatório Chaos Research de 2004


Métodos tradicionais

● PMI– Industrial – Repetitivo– Software

● Sequêncial, Waterfall, Cascata – Eng.ª Civil !

– Especificação em detalhes– Contratual – Larga escala– Compreensível por analogias com projetos do mundo físico


Premissas

● Linearidade● Determinismo● Especialização● Foco na execução● Crescimento exponencial do custo de

alteração

Problema:

As premissas não se aplicam ao desenvolvimento de software :-) !


Será ?


Não mais !Ou talvez nunca tenha sido

● Fazer software é um processo de descoberta. Essa curva pressupõe que se sabe tudo no início, tudo será detalhado e não mudará mais

● Software é diferente do mundo físico !– O prédio ficou excelente, só o cliente só quer de

outra cor e que esteja dez metros para o lado !


Manifesto ágil

● Indivíduos e interação entre eles 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

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward

Cunningham Martin Fowler James Grenning Jim Highsmith Andrew

Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve

Mellor Ken Schwaber Jeff Sutherland Dave Thomas

12 princípios - http://manifestoagil.com.br/principios.html

http://manifestoagil.com.br/principios.html


Extreme Programming

● Conjunto de valores● Negociação constante● Princípios

– Simplicidade ! Mais de 45 % das funcionalidades nunca são usadas ! 65 % é inútil ! 20 % é o que realmente importa ! - tenta minimizar o sistema

– Pair programming

– Testes por todo lado

– Metáforas

– Pessoas !

– Fazer certo a coisa certa. Telefone sem fio !

– Releases curtas

– Iterações mais curtas ainda

– Feedback contínuo


Uma boa mistura

● Olhar o todo com metodologia PMI

● Lidar com o micro, diário, tático e operacional de forma ágil


Testes !

● Praticamente todas as metodologias ágeis tratam testes com prioridade– Tests First: TDD, FDD, BDD

● De todos os tipos: Unitários, integração, manual, automatizado, caixa preta, stress, robustez, carga,

● XP normalmente produz mais linhas de código de testes do que funcionalidades

● Testes dão a garantia de que precisamos para fazer Refactoring !


• A largura da etapa indica a o esforço aplicado à ela;

• A altura da etapa indica a importância sob o ponto de vista de produto;

• A altura indica a importância sob o ponto de vista de arquitetura e débito técnico.

•Máximas: Não é possível testar tudo; Testes tem custo; Testes informam sobre risco; Desenvolvimento sem testes não existe.

P - Piloto com usuários reais e ambiente de produção

Validação - Homologação isenta, equipe desacoplada do projeto. Objetiva validar o sistema.

Carga - Robôs de testes exercitando o sistema no seu limite. Executado a cada release.

Caixa Preta - Testes completos de funcionalidades, devem rodar a cada implementação. Pode ser automatizados ou manuais.

Automáticos - Testes que rodam a cada build para exercitar grupos de métodos ou funcionalidades. Visam garantir que não há regressão

Unitários - Testes de funções/métodos que rodam a cada compilação. Evitam regressão, rede de segurança para futuros desenvolvimentos, refactorings, correções.

Testes unitários

Testes automáticos

Testes Caixa Preta

Carga

Validação


Refactoring

● Débito técnico é como juros do cartão de crédito– Tudo aquilo que é problema estrutural, arquitetural, etc

– A escolha é pagar agora ou depois

● Teoria da janela quebrada– Conserte enquanto o estrago ainda é pequeno

– Um software ruim tende a ser tratado com desleixo, afinal já é uma bagunça mesmo...

● Pequenos incrementos– Garantia do funcionamento dos módulos/classes/funções através dos testes

unitários

● Grandes mudanças – Garantia do comportamento do sistema através dos testes de sistema


Integração contínua

● Evolução gradual● Automatização plena

– Testes, compilação, build

● Cada parte é auto-contida e pode ser entregue● Antecipação !!!● Entrega contínua ? Um framework da

Thoughtworks...


Certificações

● Adeque o processo à empresa e não o contrário– Estude, traga quem conhece, mas sempre adapte

● Busque valor, não só atender às normas– O sistema tem que ser usado, deve ajudar

– A metodologia/norma deve se ajustar à realidade da equipe/empresa


Dúvidas ?


Obrigado !Eng. Rafael Pina Pereira, MBA, PMP

[email protected]