aula03 04 agile_scrum_xp

Desenvolvimento ágil de SoftwareMotivaçãoManifesto Ágil e ConceitosSCRUMExtreme Programming (XP)

Motivação Interna – “Dor”

http://www.youtube.com/watch?v=1lqxORnQARw

Projetos de PontesPrazo – OK ( menos no

Brasil )Orçamento – OKQuase nenhuma caiCiência Antiga – 4 a 6

mil anos

Motivação Interna - Chaos Report

Projetos de SoftwarePrazo – estouraOrçamento – estouraTêm problemas com

freqüênciaCiência nova – 50

anos


Aspectos críticosProjetos de ponte são engessados e ninguém dá

“pitaco”Projetos de software normalmente precisam

suportar mudanças nas regras de negócioPontes que caem têm relatórios de erros. Softwares

são mascarados e ignorados. Não há aprendizado


69%

31%

TerminamNão terminam

16%

84%

SimNão

Projetos que terminam

Prazo e Orçamento OK


42%

58%

SimNão

Requisitos presentes ao final

Motivação do MercadoRAD – Rapid Application Development – anos

90.Métodos iterativos (ciclos) e evolucionários

(bottom-up)Empresas buscam produtos de TI como forma

de diferenciaçãoFrustração com planejamentosNecessidade de atendimento a modelos de

maturidade – CMMI, MPS.BRAlternativas à época com baixa tolerância a

mudanças de requisitos

E aí!?

E aí!?Desenvolvimento ágil não garante

necessariamente que o projeto terá mais ou

menos sucesso :-(


necessariamente que o projeto terá mais ou menos sucesso :-(

Mas ajuda!!! Como?


necessariamente que o projeto terá mais ou menos sucesso :-(

Mas ajuda!!! Como?Ajuda a descobrir antes que algo não está

indo bem – ITERAÇÕES CURTAS E ENVOLVIMENTO DO CLIENTE PARA VALIDAÇÃO

:-))

Manifesto Ágil

Encontro de 17 agilistas – Utah – Fevereiro – 2001

Kent Beck – XP (Extreme Programming)Ken Schwaber – SCRUMAlistair Cockburn – Crystal – Metodologia sob

demandaChegaram a conclusões:

www.agilemanifesto.org

Manifesto Ágil

Individuals and interactions over processes and tools Uma descrição mínima de processo é

necessária para se começar a trabalhar.Cliente sempre presente

Manifesto Ágil

Working software over comprehensive documentationSoftware bem organizado e documentadoAlguma documentação existe. Apenas o

suficiente e não conta como produto, resultado de trabalho.

Manifesto Ágil

Customer collaboration over contract negotiationCliente deve estar 'infiltrado' na equipe de

desenvolvimento.

Manifesto Ágil

Responding to change over following a plan

Método x ProcessosXP e SCRUM não são processos

Processos definem fluxo, entradas saídas, papéis.

São métodos (ou metodologias)Esse entendimento facilita a adoção de

práticas ágeis em processos tradicionais já definidos – não precisa substituir o processo

Importante diferenciar também processo de software e gestão de projeto de software

SCRUMO nome vem do rugby. Reinício da partida.Baseado na teoria de controle de processo

industrialAuto-organização e emergência

Utilizado há 15 anos com sucesso em milhares de projetos, centenas de organizações

É gerencial. Não serve apenas para projetos de software

SCRUMAjuda a controlar projetos de

desenvolvimento de softwareNão garante sucesso completo do projetoGarante que o trabalho é dedicado aos

resultados de maior valor agregadoSe o recurso for cortado, cliente sempre

vai ter algo em mãos com alguma utilidade.

Requisitos importantes nunca ficam para o final

SCRUMObtém-se do backlog o

que é de mais valorPlaneja-se a iteraçãoFaz-se acompanhametno

diárioEntrega acréscimo de

funcionalidades ao fim da iteração.

SCRUM - PapéisProduct Owner (CLIENTE)

Lista de requisitos (product backlog)Objetivos de ROIPlanejamento de Releases (priorizar)

Team (EQUIPE)Desenvolvimento de funcionalidadesAuto-gerido e auto-organizado (experiência)Multi-funcional ( programador, testador,

arquiteto, etc)

SCRUM - PapéisScrumMaster

Ensinar Scrum aos outros envolvidosManter o método nos trilhosRespeitar cultura da organização x

Entregar benefícioS CULTURA é uma das principais barreiras a

serem vencidas

Garantir que os outros envolvidos sigam as regras e práticas do SCRUM

SCRUM – Visão Geral

SCRUM - ArtefatosProduct backlog

Sempre evoluiSprint backlog

Derivado a partir do product backlogDetalha os itens do product backlog em tarefas

SCRUM - ArtefatosBurndown Chart – quanto mais horizontal,

melhor

SCRUM - ArtefatosIncremento de funcionalidade de produto

potencialmente 'empacotável'Esse incremento deve ser levantado em cada sprintCLIENTE pode querer implantar ( Antecipação ao

release. Furo no SCRUM? Equipe estará apta? )O que é um incremento CONCLUÍDO? (done)

Testado Código bem escrito e bem estruturado Disponível em um executável Com documentação de usuário

SCRUM - RegrasSprint Planning Meeting – parte inicial – 4 horas

4 horas definindo itens mais importantes e empacotáveis do backlog de produto

Todos os papéis participamBacklog deve ser preparado antes pelo Product

Owner(de preferência) ou ScrumMaster(pior)Sprint Planning Meeting – parte final – 4 horas

SCRUMMASTER responde perguntas da EQUIPE nas 4 horas finais para detalhamento de tarefas

Ao final, tem-se o Sprint Backlog

SCRUM - RegrasDaily Scrum Meeting

15 minutos independente do número de membros

Muita rigidez com presença e pontualidadeTrês questões

O que você fez desde a última conversa? O que você vai fazer de agora até a próxima? O que lhe impede de fazer o seu trabalho o mais

eficientemente possível?

Exigem respostas rápidas

SCRUM - RegrasSprint – duração sugerida: 30 dias

Itens de Backlog de sprint CONGELADOS durante a execução do sprint

Atendimento a mudanças de requisitos garantida pela continuidade de alterações no backlog de produtos

ScrumMaster pode abortar o sprint (casos extremos)Team pode consultar ao P. Owner o que retirar do

backlog quando for constatada impossibilidade de finalizá-lo por completo. O contrário (acrescentar funcionalidades) também é aceito.

SCRUM - RegrasSprint Review Meeting

4 horasApresentar funcionalidades ao Cliente e

stakeholdersArtefatos não podem ser apresentados como

produtos de trabalho (Forma de policiar o contrato? Afinal o que tem valor é software funcional – valor ágil )

Stakeholders são ouvidosAo final, o próximo Sprint Review Meeting é

agendado

SCRUM - RegrasSprint Retrospective Meeting

3 horasSM, TM e PO (opcional)Perguntas ao TM

O que foi bom no último sprint? O que não foi bom? Melhorar práticas

SM cataloga as respostasTM prioriza a ordem de melhoras em potencial

para discutir

Gostaram do SCRUM?Falamos de Gestão de ProjetoAgora 'tá' na hora de práticas de

desenvolvimentoVamos falar de XP

33

:.: :.: ÍÍNDICENDICE

1.1 Motivação

1.2 Muito Prazer, eu sou XP

34

:.: 1.1 - Motivação:.: 1.1 - Motivação

Programadores estão Sofrendo ao Redor do Mundo

Versão Original

( http://www.youtube.com/watch?v=SE7gzecA43U )

Versão Legendada

( http://www.youtube.com/watch?v=W-188Z-xgjo0 )

http://www.youtube.com/watch?v=SE7gzecA43U

http://www.youtube.com/watch?v=SE7gzecA43U

http://www.youtube.com/watch?v=W-188Z-xgjo0

http://www.youtube.com/watch?v=W-188Z-xgjo0

35

:.: 1.1 - Motivação:.: 1.1 - Motivação

Relatório do Caos – Chaos Report

36

:.: 1.2 – Muito Prazer, Eu sou :.: 1.2 – Muito Prazer, Eu sou XPXP

“Jeito leve, eficiente, de baixo risco, flexível, previsível, científico e divertido de desenvolver software” - Kent Beck

Recomendado para:

– Projetos com requisitos vagos e que mudam frequentemente

– Desenvolvimento Orientado a Objetos– Equipes Pequenas(não superiores a 12 pessoas)– Desenvolvimento Incremental – Interativo, com

versões intermediárias até se chegar a versão final.

37


Define um conjunto de valores, práticas e

recomendações que se seguidos em conjunto

levarão ao desenvolvimento de um produto

com alta qualidade e o menor custo

possível, além de valorizar as pessoas

envolvidas nas atividades de construção do

produto.

38


Premissa compartilhada com outros métodos Ágeis

O cliente deve estar integrado a equipe de

desenvolvimento e aprenderá sobre suas

necessidades a medida em que puder manipular

versões intermediárias durante o

desenvolvimento.

39


XP não é:

Um software ou ferramenta de gestão de projetos

Um processo de desenvolvimento de software – Não prevê fases, artefatos, papéis formais, etc.

40

Metodologias Ágeis: Metodologias Ágeis: Extreme Extreme ProgrammingProgramming

2 – Elementos de 2 – Elementos de Extreme Extreme ProgrammingProgramming..

Professor: Joaquim Lopes Júnior Professor: Joaquim Lopes Júnior ([email protected])([email protected])

41


2.1 Valores

2.2 Práticas

42

:.: 2.1 - Valores:.: 2.1 - Valores

Comunicação

Alguém no time saberá a solução para seu problema. Mas você precisa avisar!

Ao se deparar com um problema, avalie se ele teria sido evitado se alguém tivesse “contado” alguma coisa.

A partir disso, melhore a comunicação e defina como parte do processo

43


Simplicidade

Posicione-se: onde está e para onde quer ir?

Qual é o jeito mais simples(barato, legal) de se mover?

Feedback

Times XP se esforçam para dar o máximo de feedback e o mais rápido possível

Opinem sobre ideias, sobre a qualidade do código-fonte, diga se os testes foram fáceis de implementar e se executaram sem problemas

44


Coragem

Você não precisa ser um bombeiro ou policial para ser corajoso

Coragem não é inconsequência – seja equilibrado

Tenha coragem para jogar uma parte do sistema fora. Ou para escrever pouca documentação.

Respeito (Edição de 2004 do Embrance Change).

Respeite o seu time, respeite o que outros fazem

Respeite o projeto, cuide dele

Planning Game – Jogo do Planejamento

Técnicas de planejamento para manter o foco no que é mais importante (maior valor) para o cliente.

Ocorre sempre no início de uma iteração ou release.

– Releases (~8 semanas) : Entrega de módulo do software que represente valor.

– Iteração (~2 semanas) : Implementação de conjunto de funcionalidades. Marco do release.

45

:.: 2.2 - Práticas:.: 2.2 - Práticas


No JP, o cliente é responsável por definir quais são as funcionalidades – histórias – a serem entregues no próximo release – prioriza o que tem maior valor.

Histórias de Usuário são as funcionalidades descritas em cartões – post-its. Responsabilidade do usuário.

Tempo para desenvolvimento da História medido em pontos.

46



47


Standup Meeting – Reunião em pé

Reunião diária para acompanhamento das tarefas. Ela deve ser rápida e objetiva (por isso a turma não pode sentar)

No Scrum, sugere-se para o Daily Meeting:

15 minutos | O que você fez de ontem para hoje? | O que você fará até amanhã? | Quais dificuldades têm enfrentado? (Qual valor do XP?)

48


49


Pair Programming – Programação em Pares

Dois desenvolvedores compartilhando uma estação.

Análise, Desenho, Programação e Testes.

Um mantém o outro motivado e no foco.

50


Test Driven Development – Desenvolvimento Dirigido por Testes

XP e outros métodos ágeis tem foco em alta qualidade.

Antes de se programar uma funcionalidade, programa-se um teste para ela. A funcionalidade tem que passar no teste.

Dessa forma aprimora-se a análise (há mais tempo para entender o que é necessário) e investe-se mais tempo no desenho do software – Interfaces. Menor retrabalho.

51


Refactoring – Refatoração

Modificações contínuas no código-fonte sem alterar a funcionalidade implementada.

Deixar o código mais simples, com melhor desempenho, mais modularizado, mais fácil de se integrar a outros módulos.

Os testes (Test Driven Development) ajudam a garantir que nada para de funcionar após uma mudança.

52


Shared Code – Código Compartilhado/Coletivo

Não existe segmentação de partes do sistema entre os desenvolvedores. Todos podem acessar qualquer parte do código fonte, sem pedir autorização.

Aumento de Qualidade – Verificação e revisão de código

A qualquer momento um programador (ou um par) pode refatorar um código que achar que pode ser melhorado

53


Coding Standards – Código padronizado

Já que todo mundo pode mexer, “né” ?

Agilidade na refatoração

Facilidade de Leitura

Exemplo:

http://pear.php.net/manual/en/standards.php

http://pear.php.net/manual/en/standards.php

54


Simple Design – Design(Desenho) Simples

Faça hoje o que você precisa para hoje.

Motivação: feedback rápido, entrega de funcionalidades de valor para o cliente.

Assume-se que será possível refatorar o código a qualquer momento para comportar novas funcionalidades.

Talvez a prática mais criticada pelos tradicionalistas.

55


Metaphor – Metáfora do Produto

Relacionar o desenvolvimento do produto com abstrações do cotidiano.

Importante estar com a mente “oxigenada”.

Crie metáforas para as funcionalidades como se não existissem computadores.

E talvez esta seja a mais difícil de explicar

56


40-hour week – 40h semanais / Ritmo Sustentável

XP depende de pessoas praticarem XP

Toda a qualidade do produto e dos elementos utilizados para desenvolvê-lo depende da qualidade das pessoas

Evitar horas extras.

Cuidado com os FREELAS...

57


Continuos Integration – Integração Contínua

Os pares integram seus códigos ao sistema todo várias vezes

ao dia.

O processo de integração consiste em adicionar o incremento

do software e testar todo o sistema.

Dessa forma a integração não acrescenta erros ao sistema

Ferramentas: CruiseControl, Jenkins, Hudson, Bamboo,

BuildMaster, Teamcity, etc.

Desenho de ambiente.

58


Short Releases – Releases Curtos

O principal objetivo desta prática é fazer com que o cliente tenha acesso ao valor do produto o mais cedo possível.

E esses incrementos de valor devem ser contínos (ex.: a cada 2 meses uma nova versão)

Favorece o feedback por parte do cliente de forma precoce. Diminui atrasos em entregas, aumenta assertividade, e aumenta a taxa de aproveitamento do produto

59

:.: 2.2 – Práticas:.: 2.2 – Práticas

lFrequência de Utilização das Práticas

Entendimento em 4 ciclos

http://blogs.msdn.com/b/jmeier/archive/2010/04/04/the-four-circles-of-xp-extreme-programming.aspx

60

Metodologias Ágeis: Metodologias Ágeis: Extreme Extreme ProgrammingProgramming

3 – Implantação de XP nas 3 – Implantação de XP nas OrganizaçõesOrganizações

Professor: Joaquim Lopes Júnior Professor: Joaquim Lopes Júnior ([email protected])([email protected])

61


3.1 Desafios Gerenciais

3.2 Adoção de XP

3.3 Estudo de Caso

3.4 Documentação em XP

3.5 Escalando XP

3.6 Debate

62

:.: 3.1 – Desafios Gerenciais:.: 3.1 – Desafios Gerenciais

Conflitos de Processo de Desenvolvimento

Mesclar agilidade com processos tradicionais: ou se perde agilidade ou se joga fora muito esforço em definição de processo.

Variabilidade: Equipes ágil e não ágil no mesmo produto nem sempre vão se falar bem. Tomadas de decisões e documentos serão muito diferentes.

Ciclo de Vida: Entrega Imediata x Evolução a longo prazo

63


Conflitos de Processo de Desenvolvimento

Sistemas Legados: Difícil de refatorar.

Requisitos: Histórias de Usuários precisarão ser “inchadas” com requisitos não funcionais de performance e segurança para ficar compatível

64


Conflitos de Processo de Negócio

Recursos Humanos: Traz desafios para gerir pessoas que não se enquadram em uma única função. Gestão de bem estar e gestão de tempo para imprevistos.

Gestão de Progresso: Contratos e técnicas tradicionais (milestones) podem não suportar um desenvolvimento em XP. Muda a forma de negociar pagamento, por exemplo.

Medida de Maturidade: CMMI e MPS.BR

65


Conflitos de Pessoas

Atitudes: Processos evolutivos muito formalizados dificultam atitude multitarefa.

Logística: Um time de XP deve trabalhar unido (Comunicação).

Gestão da Mudança: Pessoas com resistência a mudanças irão se comportar de forma resistente.

Sugestões: Eduque, enfatize o valor para o cliente, escolha as pessoas certas, recompense valores individuais e junto a equipe.

66

:.: 3.2 – Adoção de XP:.: 3.2 – Adoção de XP

Utilizar XP não vai mudar seus problemas

– Atitudes do cliente

– Prazos mal negociados

– Orçamentos.

Vai mudar a forma como você os resolve.

Seja suave para não ter que abortar o processo

– O gerente vai pedir para a equipe trabalhar mais

– O programador vai escrever código sem teste

Encontre um patrocinador executivo de peso

67


Mude e em seguida provoque a mudança

Aprenda TDD, depois ensine a toda equipe

Sua equipe aprende a estimar e desenvolver com base nas histórias, depois convide os clientes internos a apresentar histórias (comece sempre por um projeto interno)

Sua empresa aprende a entregar software de qualidade no prazo, então convide clientes externos para fazer parte do planejamento.

68


Escolha um coach

Pessoa com experiência em XP → Mais fácil aprender com o erro alheio

Normalmente trabalha em equipe mas tem suas próprias atividades → é quem lidera tentativas de melhorias

Um evangelizador → Mantém todo mundo praticando XP

69


Quando não adotar XP

Escute os valores → Se os valores da organização não forem alinhados não vai dar certo.

Sistemas de Premiação Individuais

Contratos de Escopo Fechado → Dificultam mudanças e utilização otimizada do XP. Catequize o cliente.

70

:.: 3.3 – Estudo de Caso:.: 3.3 – Estudo de Caso

Considerações importantes sobre estudos de casos:

Um caso de estudo não é um experimento formal, mais focado e com base em variáveis de contexto

Testa-se teorias (hipóteses) em uma configuração

Cada projeto tem características próprias. Validade questionável cientificamente. Difícil generalizar

Útil pois apresenta informações para a indústria de software. Ajudam a validar suspeitas.

71


Sabre Airline Solutions → Resultados apontam aumento de produtividade e qualidade.

Empresa que desenvolve software para cias. Aéreas

Equipe tinha características favoráveis ao XP. Não foi necessário redimensionar ou ajustar o XP.

Comparação entre 2 releases do mesmo produto.

– Um release imediatamente antes da adoção

– Outro após aprox. 2 anos de utilização

72


Sabre Airlines Solutions → Resultados apontam aumento de produtividade e qualidade.

Desenvolveram um framework para avaliação de XP → Fatores de Contexto, Métricas de Aderência ao XP, Métricas de Resultados do XP

A aplicação consiste em um sistema de desenvolvimento de interfaces para outros Sws.

O sucesso da utilização de XP fez com que mais de 200 pessoas em 30 times utilizassem o método

73


74


Hipóteses:

Qualidade do pré-release → defeitos detectados antes de liberar o software

Qualidade do pós-release → defeitos após release detectados pelos usuários

Produtividade dos programadores → medidas qdt de histórias e linhas de código por programador-mês

Satisfação do cliente → Medido por entrevistas e feedback

Satisfação da equipe → Medida por meio de pesquisa interna

75


76


77


Outros Estudos de Casos:

– NASA testou XP para validá-lo para projetos de missão crítica e tiveram 2x mais produtividade [Wood & Kleb, 2003]

– Caso de Estudo de XP no Instituto de Pesquisa da Finlândia: precisão de estimativas +26%, produtividade + 12 linhas de código/hora, taxa de defeitos não variou. [Abrahamsson, 2003]

78


Outros Estudos de Casos:

– Williams et. al. [2004] fez uma aplicação do framework na IBM, em um projeto onde o XP foi adotado parcialmente:

• Aumento de produtividade e queda de defeitos no pós-release da ordem de 40%

79

:.: 3.4 – Documentação em XP:.: 3.4 – Documentação em XP

XP tem documentação, SIM SENHORES!

Mas só o suficiente!

80


Documentações, testes de unidade e aceitação dão suporte ao código gerado (principal entrega).

Documenta-se apenas o suficiente para que futuros desenvolvedores possam dar manutenção

Refatoração, Código Coletivo e Prog. Em pares contribuem para se ter código mais limpo e simples, reduzindo esforço de documentar.

81


Visão tradicional → custo de alterar o software cresce exponencialmente ao longo do ciclo de vida. Preferível manipular docs do que corrigir código.

Visão ágil → Orientação a objetos e ferramentas de apoio a devel tornam mais barato corrigir código do que manter documentos atualizados

E ainda há uma grande dificuldade de se manter toda documentação tradicional atualizada e coerente (rastreabilidade)

82


Exemplos de documentos:

Histórias - Testes de Aceitação - Testes de Unidade -

Documentação de APIs - Modelo de Classes -

Modelo de Dados - Processos de Negócio -

Manual do Usuário - Acompanhamento Diário -

Acompanhamento do Projeto - Fotos

83

:.: 3.5 – Escalando XP:.: 3.5 – Escalando XP

Número de pessoas → divida o problema em vários times pequenos e trate a integração

Relação com a parte não ágil da empresa → Tenha um GP experiente. Não esconda nada. Não condene.

Projetos de Longa Duração → Não descuide dos testes e continue utilizando XP.

Complexidade dos problemas → Tenha um time de especialistas faça um conhecer o trabalho do outro

Missão Crítica → Adicione auditorias. Não só no final. Faça um “Continuous Auditing”.

84

:.: 3.6 – Debate:.: 3.6 – Debate

Como é a cultura da sua organização?

Você consegue identificar um primeiro projeto para utilizar XP?

Você teria apoio da diretoria para usar XP?

Você acha que as pessoas gostariam de usar XP?

O seu cliente faria parte da sua equipe?

85

:.: BIBLIOGRAFIA:.: BIBLIOGRAFIA

Manhaes Teles, Vinicius. Um estudo de caso da adoção das práticas e valores do Extreme Programming. 2005. 180 f. Dissertação (Mestrado em Informática) - Universidade Federal do Rio de Janeiro, Rio de Janeiro. 2005.

Beck, K. & Andres, C. (2004). Extreme Programming Explained: Embrace Change. Addison

Wesley, 2a edição. ISBN 0-321-27865-8

Boehm, B. & Turner, R. (2005). Management Challenges to Implementing Agile Processes in

Traditional Development Organizations. IEEE Softw. 22, 5 (Sep. 2005), 30-39. DOI= http://dx.doi.org/10.1109/MS.2005.129

Lucas Layman, Laurie Williams , Lynn Cunningham, Exploring Extreme Programming in Context: An Industrial Case Study, Proceedings of the Agile Development Conference (ADC'04), p.32-41, June 22-26, 2004

W. Wood, W. Kleb, "Exploring XP for Scientific Research," IEEE Software, vol. 20, pp. 30-36, 2003.

P. Abrahamsson, "Extreme Programming: First Results from a Controlled Case Study," in 29th EUROMICRO Conference. Belek, Turkey: IEEE, 2003.

D. J. Reifer, "How to Get the Most out of Extreme Programming/Agile Methods," in 2nd XP and 1st Agile Universe Conference. Chicago, IL: Springer LNCS 2418, August 2002, pp. 185-196.

L. Williams, W. Krebs, L. Layman, and A. Antón, "Toward a Framework for Evaluating Extreme Programming," presented at Proceedings of the Eighth International Conference on Empirical Assessment in Software Engineering (EASE 04), 2004, in press.

aula03 04 agile_scrum_xp

Technology