Introdução a Métodos Ágeis de Desenvolvimento de Software

Introdução a Métodos Ágeis de Desenvolvimento de Software Daniel Cukier (AgilCoop) twitter.com/danicuki Prof. Dr. Rafael Prikladnicki (PUCRS) twitter.com/rafaelpri

Quem usa Scrum e XP?

EUA BR 2 anos! Quem usa Scrum e XP?

Quem usa Scrum e XP?

Daniel Cukier
15 anos de experiência com desenvolvimento do Software
3 anos como gerente de Desenvolvimento na Locaweb
Membro da Agilcoop desde 2003
Autor do blog www.agileandart.com
Mestre em Ciência da Computação – IME/USP (2009)
Palestra em vários eventos
Encontro Ágil, Oxente Rails, Falando em Ágil , SugarLoafPLoP, etc
Áreas de atuação acadêmica e profissional:
Desenvolvedor e líder técnico em vários projetos de software.
Um dos responsáveis pela implantação de Métodos Ágeis na Locaweb
Padrões para Introduzir Novas Ideias na Indústria de Software
Outras não menos importantes:
Teatro, música, poesia, meditação

Contexto e experiência na AgilCoop
Cursos de graduação em XP desde 2001
Apresentações
SBES, SUCESU, SEPAI, SEBRAE, etc.
Arquivos disponíveis: www.agilcoop.org.br
Assessorias em métodos ágeis
Artigos científicos
Dissertações de Mestrado

Professor da FACIN – PUCRS desde 2004 – www.inf.pucrs.br/~rafael
Coordenador de Gestão de Projetos da AGT/PUCRS
Professor do PPGCC desde 2010/1
Coordenador do GUMA e do SPIN-POA (Sucesu-RS)
Certified ScrumMaster (CSM) e Project Mgmt Professional (PMP)
Mestre em Ciência da Computação – PUCRS (2003)
Doutor em Ciência da Computação – PUCRS (2009)
Áreas de atuação acadêmica e profissional:
Desenvolvimento Distribuído de Software
Gerência de Projetos
Melhoria de Processo de Software
Engenharia de Software Experimental
Lean e Métodos Ágeis para Desenvolvimento de Software
Rafael Prikladnicki

Contexto e experiência na PUCRS www.inf.pucrs.br/munddos Criado em 2001 Registrado no CNPq em 2004 Livros publicados em 2007, 2009 e 2010 2 pesquisadores Formou 11 mestres, 1 doutor Possui 6 mestrandos, 2 doutorandos

Implantação de práticas de DDS nas empresas Desenvolvimento de ferramentas para apoiar DDS Integração de DDS com métodos ágeis Estudo de maneiras de usar Follow-the-Sun (FTS) Formação de profissionais e alunos em DDS Estudo do papel do Brasil no mercado global de TI www.inf.pucrs.br/munddos Contexto e experiência na PUCRS

Contexto e experiência na PUCRS

Introdução e motivação
O que são Métodos Ágeis?
Princípios
Problemas com abordagens tradicionais
Alguns métodos ágeis
Conclusão
Agenda

Por que teu projeto termina com sucesso?
Por que teu projeto fracassa?
Discussão em grupo
15 minutos
Agrupar problemas e fracassos em categorias
Dinâmica Grupo 2 Grupo n Grupo 1 Grupo 3 Sucesso Fracasso Ref: Henrik Kniberg

Motivação

Como ganhar dinheiro resolvendo problemas que voce não conhece, com pessoas desconhecidas, em um tempo curto e com poucos recursos (e se divertindo)?
Motivação

Tenho como produzir 100 aviões em 10 minutos? Quantos aviões 10 pessoas produzem em 10 minutos?
Tenho, mas:
Vou verificar tudo ao final
Posso ter baixa qualidade
Posso ter retrabalho
Posso não ter entendido o escopo
Então por que deixar tudo para o final?

Tenho como produzir 100 aviões em 10 minutos? E se produzirmos um pouco a cada 2 minutos? E se melhorarmos a cada ciclo? E se o cliente fornecer feedback a cada ciclo? E se a equipe encontrar a melhor forma de trabalhar? Quantos aviões 10 pessoas produzem em 10 minutos?

Motivação

Sociedade demanda
grande quantidade de sistemas/aplicações
software complexo, sistemas distribuídos, heterogêneos
requisitos mutantes (todo ano, todo mês, todo dia)
Mas, infelizmente,
não há gente suficiente para desenvolver tanto software com qualidade
Novos ventos no desenvolvimento de software

Resultado dos projetos em 2004
Relatório do Chaos ( Chaos Report )

Resultado dos projetos em 2004
Relatório do Chaos ( Chaos Report ) 1994 2004 Projetos não concluídos ------------ 31% Proj etos bem sucedidos ----- 16% Estouro médio de custo -----------------------> 180% Estouro médio de prazo -----------------------> 164% Proje tos não concluídos ------- 18% Projetos bem sucedidos ----------- 29% Estouro méd io de custo ----------------- 56% Estouro médio de prazo ------------------------- 84%

Evitar desperdício
Estudo do The Standish Group conclui (Chaos Report): Pesquisa sobre a utilização das funcionalidades do software ...
Mais de 64% de um sistema de software quase nunca não é utilizado!

Com métodos tradicionais/clássicos de desenvolvimento
Supõem que é possível prever o futuro
Pouca interação com os clientes
Ênfase em burocracias
(documentos, formulários, processos, controles rígidos, etc.)‏
Avaliação do progresso baseado na evolução da burocracia e não do código
Com software
Grande quantidade de erros
Falta de flexibilidade
Problemas

Melhores Tecnologias
Padrões de Projeto (reutilização de idéias)
Componentes (reutilização de código)
Middleware/frameworks (aumenta a bstração)
Melhores Metodologias
Métodos Ágeis (o foco deste mini-curso)
outras... (abordados em outros cursos de ES)
Como resolver o impasse?

Erro comum: olhar para software como apenas um desses itens e ignorar os demais
O que é desenvolvimento de software? Por Alistair Cockburn: (Gabriel) Arte (Knuth) Artesanato (Cockburn) Poesia (Humphreys) Disciplina (Meyer) Engenharia (Jacobson) Modelagem

Agile is not a set of practices, but a core set of beliefs and principles
Jim Highsmith
O que são métodos ágeis?

Retorno de investimento
Inovação
Melhoria de processo
Pessoas
Cultura
Comunicação
Adaptação x Antecipação
Princípios

Movimento iniciado por programadores experientes e consultores em desenvolvimento de software.
Questionam e se opõem a uma série de mitos e práticas adotadas em abordagens tradicionais de Engenharia de Software e Gerência de Projetos.
Manifesto Ágil:
Assinado por 17 desenvolvedores em Utah em fevereiro/2001.
http://agilemanifesto.org
Histórico

Processos e ferramentas Documentação abrangente Negociação de contrato Plano pré-estabelecido mais importante que Agile Manifesto (2001) Indivíduos e interações Software funcionando Colaboração do cliente Resposta às mudanças
http://agilemanifesto.org
Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick

O mais importante é o software funcionando
Periodicamente a equipe deve refletir sobre como se tornar mais efetivo
Profissionais motivados
Suporte às necessidades da equipe e a mbiente necessário para desenvolvimento das atividades
Confiança no trabalho da equipe
Alguns princípios

O gerente de projeto concorda em prosseguir sem que todos os requisitos estejam bem definidos
Os desenvolvedores concordam em prosseguir sem ter todos os requisitos documentados
Os membros da equipe sabem que alguém vai ajudar quando ocorrerem problemas
Em um projeto ágil ideal...

Os gerentes percebem que não precisam dizer à equipe o que fazer, ou garantir o que vai ser feito
A equipe percebe que ninguém vai dizer o que fazer, isto faz parte do trabalho da equipe
Não existem mais a impressão de divisão (testers and programmers), todos são desenvolvedores
Em um projeto ágil ideal...

Mudança de Postura Equipe Equipe Equipe Equipe GP Equipe Equipe Equipe Equipe GP Tradicional Ágil Cross-funcional Auto-organização

0. Levantamento de Requisitos
1. Análise de Requisitos
2. Desenho da Arquitetura
3. Implementação
4. Testes
5. Produção / Manutenção
Enquanto isso, num projeto tradicional...

É necessário fazer uma análise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema
É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la
É necessário testar o sistema completamente antes de mandar a versão final para o cliente
Premissas básicas do modelo tradicional

Cascata é como uma bala de canhão

Interface Cliente Servidor BD C Iterativo = não espere ter tudo correto na primeira vez Incremental = construa em ”pedaços” verticais ( features ) ao invés de horizontais (camadas) Desenvolvimento monolítico Desenvolvimento incremental Talvez não seja necessário construir o resto C Interface Cliente Servidor BD Iterativo e Incremental Ref: Henrik Kniberg 1 2 3 4 1 2 3

Iterativo e Incremental Produto ?

O que muda? Custo da mudança Intensidade e stress Tempo Tempo Tempo Entrega de valor Transparência Envolvimento do cliente Tempo Ref: Henrik Kniberg Tradicional Ágil

Metodologias ágeis são uma tentativa de refinar as metodologias iterativas, tirando o foco do processo em si e dando mais ênfase para a contribuição das pessoas

Metodologias ágeis é uma febre? Uma onda passageira?
É o início de uma mudança na forma de trabalho...

Evitar incerteza x Gerenciar para incerteza Ref: Luiz Cláudio Parzianello

Visão tradicional
“ Tudo é importante, vamos fazer tudo ao mesmo tempo!”
Visão ágil
“ Prioriza e foca naquilo que é mais importante!”
O paradoxo da multitarefa Ref: Henrik Kniberg Jan Feb Mar Abr Mai Jun Jul Jan Feb Mar Abr Mai Jun Jul A B C

Métodos tradicionais
O planejamento deve propiciar a prevenção de mudanças
Métodos ágeis
A mudança é incorporada ao escopo
Razões
Necessidades de negócio
Novas oportunidades
Mudanças de legislação
Requisitos incompletos
O que muda?

A atitude dos desenvolvedores de software seria completamente diferente:
Tomaríamos as grandes decisões o mais tarde possível
Implementaríamos agora somente o que precisamos agora
Não implementaríamos flexibilidade desnecessária (não anteciparíamos necessidades)
E se fosse essa a realidade?

Orientação a Objetos : facilita e cria oportunidades para mudanças
Técnicas de Refatoração
Testes automatizados : nos dão segurança quando fazemos mudanças
Prática / cultura de mudanças : aprendemos técnicas e adquirimos experiência em lidar com código mutante
E essa é a nova realidade (em muitos casos)

Adaptative Software Development (ASD)
Jim Highsmith
Crystal Clear (Crystal)
Alistar Cockburn
Extreme Programming (XP)
Kent Beck, Eric Gamma
Scrum
Ken Schwaber, Jeff Sutherland, Mark Beedle
Lean Software Development
Mary e Tom Poppendieck
Feature Driven Development (FDD)
Peter Coad, Jeff DeLuca
Test Drive Development (TDD)
Kanban
Principais Métodos Ágeis

Agile Project Management – Jim Highsmith, 2008
Agile Enterprise Framework
Governança e Portfólio Gerência de Projeto Gerência de Iterações Práticas Técnicas ROI, Progresso, Risco, Investimento Release, aquisição, PMBOK, externo Interno, Scrum XP, FDD, etc Mudança de perspectiva

1. David Rico (2008)
Survey de artigos acadêmicos e científicos publicados
2. VersionOne (2008)
Survey online com mais de 3.000 pessoas
3. QSMA (Michael Mah 2008)
Comparação rigorosa de 26 projetos ágeis com uma base de 7.500 projetos “tradicionais”
Equipes ágeis variando entre 26 e 1.000 pessoas
4. Dr. Dobb’s Journal (2008)
Survey online com 642 pessoas
Métodos ágeis funcionam?

Fonte: Mah 2008. Agile projects are 16% more productive at a statistically significant level of confidence. Métodos ágeis funcionam?

Satisfação no trabalho
Após 15 meses de adoção do Scrum, 86% dos colabroadores da Salesforce.com estavam tendo um “good time” ou o “best time”
Apenas 40% disseram isto antes de adotar Scrum
92% recomendariam métodos ágeis para outras pessoas
Time to Market
VersionOne
64% disseram que o time to market melhorou
23% disseram que melhorou significativamente
Michael Mah
Projetos ágeis tem um time to market 37% mais rápido com um nível de confiança estatisticamente significante
Métodos ágeis funcionam?

Fonte: Mah 2008. Métodos ágeis funcionam?

Melhoria na satisfação dos stakeholders
Dr. Dobb’s
47% disseram que a satisfação foi “ somewhat higher ”
31% disseram que foi “ much higher ”
Version One
Métodos ágeis funcionam? Improved Significantly Improved Enhanced ability to manage changing priorities 41% 51% Improved project visibility 42% 41% Improved alignment of IT and business goals 39% 27% Reduced project risk 48% 17%

5 motivos para NÃO usar métodos ágeis?

Motivo 1
Eu sei e defino todos os requisitos no início do projeto
Cinco Motivos para não usar Métodos Ágeis Não preciso de ciclos iterativos Qual projeto de software possui todos os requisitos definidos (corretamente) no início?

Motivo 2
Os objetivos do meu projeto estão muito claros desde o início
Cinco Motivos para não usar Métodos Ágeis O cliente descobre o que quer ao longo do caminho

Motivo 3
Meu projeto envolve baixa incerteza
Cinco Motivos para não usar Métodos Ágeis Qual projeto de software envolve baixa incerteza?

Motivo 4
Minha estimativa está toda definida e com índice de erro muito baixo
Cinco Motivos para não usar Métodos Ágeis Em qual projeto de software consigo ter estimativas precisas?

Motivo 5
Meu processo é rígido e controlado (comando-controle)
Cinco Motivos para não usar Métodos Ágeis As tarefas são delegadas, equipes ficam desmotivadas mais facilmente Qual equipe gosta de trabalhar desmotivada?

Requisitos definidos desde o início
Objetivos claros desde o início
Comando-controle
Baixa incerteza
Estimativas precisas
Qual projeto de desenvolvimento de software possui estas características?
Cinco Motivos para não usar Métodos Ágeis

Requisitos definidos desde o início
Objetivos claros desde o início
Comando-controle
Baixa incerteza
Estimativas precisas
Qual projeto de desenvolvimento de software possui estas características?
E os Cinco Motivos? Entao NÃO faz sentido NÃO usar metodologias ágeis na grande maioria dos casos. Mas não APENAS metodologias ágeis!!!

Scrum - Jogada de Rugby

Ref.: 3rd Annual ”State of Agile Development” Survey June-July 2008 3061 respondentes, 80 países Quem usa Scrum?

Requisitos Longe de um acordo Perto de um acordo Tecnologia Perto da certeza Longe da certeza Simples Complicado Complexo Anarquia Ref. : Strategic Management and Organizational Dynamics by Ralph Stacey, in Agile Software Development With Scrum by Ken Schwaber and Mike Beedle. Mesmo que o produto seja complexo... ... Tente manter uma iteração simples Como resolver

Adaptativo E C D A Planejado Tradicional Ágil B C D A B D A B A B Sem 1 Sem 2 Sem 3 Sem 4 Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 Sem 6 Sem 7 Sem 8 Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 Sem 6 Sem 7 Sem 8

Princípio
Características desconhecidas
Prioridades devem ser consideradas
Escopo irá mudar!
Essência do SCRUM
Inspeção
Verificar o que foi feito no período
Adaptação
Melhorar o processo
Planejar
Planejar o sprint
Desenvolver
Realizar o sprint
Inspecionar ( check )
Sprint review e retrospectiva
Adaptar
Lições para o próximo planejamento
Ênfase: processo empírico PLAN DO ACT CHECK

O Framework do Scrum

Product Owner e Cliente
Visão do produto
Requisitos funcionais e não funcionais
Restrições e User stories (prática do XP)
Criação do product backlog
Conjunto de funcionalidades do sistema
Priorização das funcionalidades
Preparação da base necessária para o desenvolvimeto
Mecanismos de comunicação e coordenação
Formação das equipes
Planejamento e preparação

User stories
Identificação de atores envolvidos
Como um [papel do usuário] quero [funcionalidade] para [valor de negócio]
I.N.V.E.S.T. (independente, negociável, valorizável, estimável, small e testável)
Quebrar grandes e juntar pequenas
Definição do conceito de DONE (testes)
Diferentes perspectivas
Prioridades das user stories
Valor entre 1 e 150?
Must have
Should have
Could have
User Stories

Product Owner , ScrumMaster e Equipe
Análise e organização do Product Backlog
Refinamento das funcionalidades
Estimativas
Escolha das funcionalidades para o sprint
Formalização do sprint backlog
Identificação das tarefas
Organização da taskboard
Desenvolvimento 2-4 hs 2-4 hs

Estimativas
Tempo e/ou complexidade?
Fibonacci
1, 2, 3, 5, 8, 13, 21…
Planning poker
As duas estratégias de uso de planning poker
Jogar as cartas para cada estória
Colocar cada estória embaixo de uma carta
Algumas práticas utilizadas:
Pontos para funcionalidades e horas para tarefas
1- day tasks (máximo 2 e mínimo 1/2)
Considerar tarefas como teste, pesquisas, documentação, etc.
Desenvolvimento

Tempo ou Complexidade
4 pessoas trabalhando 4 semanas
Equipe: 640 horas
2 junior, 2 senior
Produzem 25 pontos de complexidade
4 pessoas trabalhando 4 semanas
Equipe: 640 horas
4 senior
Produzem 60 pontos de complexidade
Desenvolvimento

Planning poker 1 Muito pequeno! 2 3 5 8 13 21 40  Férias!  Mais detalhes!  Nem idéia!  Intervalo!

Planning Poker na PRÁTICA!
Avaliar distância entre
Argentina e Mongólia
Chile e Itália
Japão e Austrália
Índia e Alemanha
EUA e Rússia
Ucrânia e China
Planning poker

VALOR COMPLEXIDADE Alta Baixa Alta Baixa UStory1 UStory2 UStory3 UStory4 Priorização e classificação do backlog

40 30 30 28 30 31 30 30 Estimado Realizado 40 30 40 30 40 30 40 30 50 30 60 30 40 35 35 30 30 25 30 25 20 Calibrando a velocidade Estimado Realizado Estimado Realizado Estimado Realizado

Calibrando a velocidade Início da sprint 8 5 3 5 5 5 3 5 5 8 Backlog do produto 8 5 3 5 5 Backlog da sprint Final da sprint 8 5 3 5 5 Feito! Feito! Feito! Quase Nem iniciamos Velocidade real = 18 Backlog da sprint Velocidade estimada = 26

Administrate users Register new user Edit existing user Delete user Find user 100 simultaneous users Operations manual As a helpdesk operator I want to see who is logged in View Invoice in HTML, PDF, or Excel format 100 simultaneous users Operations manual As a helpdesk operator I want to see who is logged in View Invoice in HTML, PDF, or Excel format Register new user Edit existing user Delete user Find user 100 simultaneous users Operations manual As a helpdesk operator I want to see who is logged in View Invoice in HTML, PDF, or Excel format Dividindo user stories

Dividindo user stories Administrate users Register new user Edit existing user Delete user Find user User admin User admin User admin User admin Do GUI design Write failing test Do integration test Create DB schema Write server-side logic Write form validation Dividir Quebrar em tarefas durante a reunião de sprint planning 13 5 3 8 2 Ref: Henrik Kniberg Como priorizar itens do backlog? Como planejar as tarefas?

ScrumMaster e Equipe
Dia-a-dia do SCRUM
Sprint
2 semanas a 4 semanas
Daily meetings (Daily Scrum)
Impedimentos
Obstáculos ao trabalho da equipe
Manter a taskboard
Burndown
Tarefas e estimativas
Tarefas não-planejadas
Desenvolvimento

O Gráfico de Burndown 5 10 15 20 Trabalho que resta na sprint (pontos de user story) Dias da sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Gráfico de Burndown de uma Sprint de duas semanas Vamos terminar antes

O Gráfico de Burndown 5 10 15 20 Trabalho que resta na sprint (pontos de user story) Dias da sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Gráfico de Burndown de uma Sprint de duas semanas Não vamos conseguir cumprir a meta desta sprint

O Gráfico de Burndown 5 10 15 20 Trabalho que resta na sprint (pontos de user story) Dias da sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Não estamos atualizando o gráfico de burndown Gráfico de Burndown de uma Sprint de duas semanas

O Gráfico de Burndown 100 200 300 400 Trabalho que resta no projeto (pontos de user story) Nro de sprints 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 O projeto vai terminar entre os sprints 14 e 16 Gráfico de Burndown da release ou do projeto

Daily Meetings (Daily Scrum)
Reunião diária de 15 minutos
Mantém equipe informada e integrada
O que você fez ontem?
O que pretende fazer para amanhã?
Quais são seus impedimentos?
Questões técnicas
No final da reunião
Não se resolve problema, apenas se identifica
Desenvolvimento

Para ajudar na execução ( taskboard )
Desenvolvimento

Cliente, PO, SM e Team
Apresentação do produto
Foco no QUE foi feito e não COMO foi feito
Aceite formal e feedback do cliente
Melhoria na forma de priorização?
Sprint review

Lições aprendidas
Alimentam o próximo sprint
Velocidade da equipe
Erros x acertos
Previsto x realizado
Fator de foco da equipe
Repositório de lições
Disseminação na empresa
Usar parte do sprint anterior para planejar o próximo sprint
Próximo sprint Lições aprendidas

Sprint 2-4 semanas ??? Objetivo do Sprint Produto a ser entregue (ou seu incremento) ‏ Backlog do produto Cupons Embrulho 24 horas Fluxo do Scrum Cancel Gift wrap Return Backlog da Sprint Cupons Cancelar Sprint Planning 1 Sprint Planning 2 Daily Scrum Sprint Review Retrospectiva

Lembram disto?
Como Métodos Ágeis podem ajudar a resolver ou minimizar os motivos de fracasso identificados?
Dinâmica Grupo 2 Grupo n Grupo 1 Grupo 3 Sucesso Fracasso Ref: Henrik Kniberg

Quando temos problema em cronograma, modelos tradicionais cortam testes, modelos ágeis cortam histórias. Um reduz a qualidade, o outro reduz o escopo.
A questão não é documentar, é entender.
Não existem melhores práticas. Existem boas práticas para determinadas situações.
Entregue hoje. Adapte amanhã.
Adaptação é uma resposta à mudança.
Equipes auto-gerenciáveis não são equipes sem liderança, são equipes com outro estilo de liderança.
Uso de técnicas como Refatoração, Testes, Modelagem Ágil são fundamentais para constante mudança do código
Plans are nothing; Planning is everything
Conclusões

twitter.com/danicuki twitter.com/rafaelpri

Dinâmica Analista Projetista Programador Testador Cliente Ref: Luiz Cláudio Parzianello  Æ Œ

Dinâmica … … … … Ref: Luiz Cláudio Parzianello … … … … Pequenos Lotes Grandes Lotes   Æ    Æ Œ  Æ  Æ  Æ Œ ™  Æ Œ  Æ Œ  Æ Œ ™  Æ Œ ™   Æ  Æ Œ  Æ Œ ™

Qual é o arranjo logístico mais rápido ?
Qual equipe apresentou o maior esforço por projeto?
Quais as vantagens de cada abordagem?
Quais as desvantagens de cada abordagem?
Qual a justificativa para manter os grandes lotes?
Dinâmica

http://www.agileandart.com	262
http://www.locawebers.com.br	36
http://us-w1.rockmelt.com	1

Introdução a Métodos Ágeis de Desenvolvimento de Software

by Daniel Cukier on Sep 30, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 299

Statistics

Introdução a Métodos Ágeis de Desenvolvimento de Software — Presentation Transcript