Slides da disciplina de metodologias ágeis da pós em Governança em TI do UNIBH.
Tratam de métodos ágeis, abordando os seguintes tópicos: Manifesto Ágil, Valores ágeis, Scrum, XP, Estudos de Caso.
Gostaria de agradecer ao Danilo Sato, Emmanuel Santana, Luca Bastos, Maciel, Moreira, Luiz Aguiar, Fernando Boaglio (ele tem umas fotos de Kanban muito boas no qual utilizei nessa apresentação), Rodrigo de Toledo e Roberto Nogueira pela ajuda e revisão dos Slides e também gostaria de agradecer toda lista de discussão do Visão Ágil, que me deram muitas dicas e fontes interessantes.
Parte do material que uso em meus treinamentos sobre Scrum. Nesse material mostro algumas visões pessoais e minhas experiências na adoção/adaptação do framework Scrum.
Introdução ao Scrum - uma rápida apresentação com conceitos básicos. Útil para quem precisa fazer apresentações rápidas sobre o tema.
Veja vídeo desta apresentação em https://www.youtube.com/watch?v=2fzUWTK4G1Q
Precisa melhorar seu posicionamento e resultados on-line?
Acesse e conheça o http://marketing4nerds.com
Internet Marketing na linguagem dos Nerds.
Sincero, sem fórmulas mágicas, sem gurus super-stars.
E sem promessas de dinheiro fácil.
Treinamento de Scrum que aplico em empresas que desejam adotar métodos ágeis no desenvolvimento de software. Mais informações em http://www.luiztools.com.br
Gostaria de agradecer ao Danilo Sato, Emmanuel Santana, Luca Bastos, Maciel, Moreira, Luiz Aguiar, Fernando Boaglio (ele tem umas fotos de Kanban muito boas no qual utilizei nessa apresentação), Rodrigo de Toledo e Roberto Nogueira pela ajuda e revisão dos Slides e também gostaria de agradecer toda lista de discussão do Visão Ágil, que me deram muitas dicas e fontes interessantes.
Parte do material que uso em meus treinamentos sobre Scrum. Nesse material mostro algumas visões pessoais e minhas experiências na adoção/adaptação do framework Scrum.
Introdução ao Scrum - uma rápida apresentação com conceitos básicos. Útil para quem precisa fazer apresentações rápidas sobre o tema.
Veja vídeo desta apresentação em https://www.youtube.com/watch?v=2fzUWTK4G1Q
Precisa melhorar seu posicionamento e resultados on-line?
Acesse e conheça o http://marketing4nerds.com
Internet Marketing na linguagem dos Nerds.
Sincero, sem fórmulas mágicas, sem gurus super-stars.
E sem promessas de dinheiro fácil.
Treinamento de Scrum que aplico em empresas que desejam adotar métodos ágeis no desenvolvimento de software. Mais informações em http://www.luiztools.com.br
Palestra realizada na Fundação Santo André (fsa.br) para MBA de Engenharia de Software. Também ministrada na semana da computação na Universidade de São Caetano (uscs.edu.br) e PHP Conference BR 2010
Um guia definitivo para o Scrum: As regras do jogo.
O propósito do Guia do Scrum.
Scrum é um framework para desenvolver e manter produtos complexos. Este guia contém a definição do Scrum. Esta definição consiste em papéis, eventos, artefatos e as regras do Scrum que unem os demais e os mantém integrados. Ken Schwaber e Jeff Sutherland desenvolveram o Scrum; o Guia do Scrum é escrito e fornecido por eles. Juntos, eles apoiam o Guia do Scrum.
Guia do Papel e Responsabilidade do Scrum MasterPaulo Lomanto
O Guia do Papel e Responsabilidade do Scrum Master é um documento que contém dicas gerais sobre a figura do ScrumMaster em equipes de tecnologia que utilizam Scrum.
Esse guia foi concebido através de um trabalho conjunto de diversos profissionais e contém uma grande coletânea de dicas e guias para auxiliar os ScrumMasters a desempenharem melhor as suas atividades.
Uma introdução ao SCRUM, palestra nível iniciante que apresenta o framework, seus atores, artefatos e cerimônias.
Sinta-se a vontade para baixar, copiar e distribuir. Apenas cite a fonte.
Palestra apresentada em faculdades por volta de 2012.
PS: Sobre a diferença entre entre Scrum Master e Gerente de Projetos, amadureci muito minha visão sobre isso, se quiser bater um papo, entre em contato.
Este artigo relata como foi abordada a metodologia ágil SCRUM, durante a elaboração de um software, apresentado como resultado de um TCC para obtenção do título de bacharel em Sistemas de Informação.
Palestra realizada na Fundação Santo André (fsa.br) para MBA de Engenharia de Software. Também ministrada na semana da computação na Universidade de São Caetano (uscs.edu.br) e PHP Conference BR 2010
Um guia definitivo para o Scrum: As regras do jogo.
O propósito do Guia do Scrum.
Scrum é um framework para desenvolver e manter produtos complexos. Este guia contém a definição do Scrum. Esta definição consiste em papéis, eventos, artefatos e as regras do Scrum que unem os demais e os mantém integrados. Ken Schwaber e Jeff Sutherland desenvolveram o Scrum; o Guia do Scrum é escrito e fornecido por eles. Juntos, eles apoiam o Guia do Scrum.
Guia do Papel e Responsabilidade do Scrum MasterPaulo Lomanto
O Guia do Papel e Responsabilidade do Scrum Master é um documento que contém dicas gerais sobre a figura do ScrumMaster em equipes de tecnologia que utilizam Scrum.
Esse guia foi concebido através de um trabalho conjunto de diversos profissionais e contém uma grande coletânea de dicas e guias para auxiliar os ScrumMasters a desempenharem melhor as suas atividades.
Uma introdução ao SCRUM, palestra nível iniciante que apresenta o framework, seus atores, artefatos e cerimônias.
Sinta-se a vontade para baixar, copiar e distribuir. Apenas cite a fonte.
Palestra apresentada em faculdades por volta de 2012.
PS: Sobre a diferença entre entre Scrum Master e Gerente de Projetos, amadureci muito minha visão sobre isso, se quiser bater um papo, entre em contato.
Este artigo relata como foi abordada a metodologia ágil SCRUM, durante a elaboração de um software, apresentado como resultado de um TCC para obtenção do título de bacharel em Sistemas de Informação.
Métodos ágeis para design de sistemas interativos centrados no usuárioKarine Drumond
Métodos ágeis e boas práticas de design centrado no usuário para guiar profissionais e empresas que buscam uma maior integração entre pesquisa, design e desenvolvimento. Palestra apresentada na PUC São Gabriel e UNA Buritis.
Apresentação do Prof. Dr. Edivandro Conforto utilizada na palestra "Gerenciamento Ágil de Projetos - Aplicação em Produtos Inovadores" na Poli - USP em 12/11/2015, abordando o tema da nova disciplina do MBA em "Gestão e Engenharia de Produtos e Serviços" coordenado pelo Prof. Dr. Paulo Kaminski, do PECE - Programa de Educação Continuada da Escola Politécnica da USP.
Esta palestra apresenta os valores e princípios do manifesto ágil, os resultados de uma pesquisa sobre a adoção de metodologias e práticas ágeis, uma visão geral do processo ágil para construção de software SCRUM e práticas ágeis de desenvolvimento mais usadas da XP. O objetivo é apresentar os conceitos do manifesto ágil e promover uma discussão sobre como eles podem influenciar as equipes positivamente, visando obter sucesso nos projetos.
Ao final da aula, os alunos devem conhecer as diferenças entre os modelos de programação visual e console.
O conceito de desenvolvimento de software com base no modelo RAD será apresentado e exemplificado.
Inovação Disruptiva na Gestão de Projetos de Inovação - rumo à agilidade e ba...Edivandro Conforto
Palestra ministrada pelo Prof. Daniel Amaral na Fundação Dom Cabral, Centro de Referência em Inovação (Nacional) na cidade de São Paulo, no dia 06 de Dezembro de 2012. A reunião do grupo CRI Nacional teve como tema "Gestão de Projetos de Inovação". A apresentação traz uma discussão dos novos rumos da gestão de projetos e contém um resumo dos resultados do programa de pesquisa sobre o tema "agilidade no gerenciamento de projetos de inovação", conduzido pelo Grupo EI2 / EESC / USP em parceria com o grupo de pesquisa GEPEC / UFSCar.
Os 12 princípios ágeis foram publicados em 2001 pela Agile Alliance alguns meses depois do lançamento do manifesto ágil para suportar os times na fazer transição para a nova metodologia. Nesta apresentação compartilho estes princípios e minha visão obre eles.
Metodologias Ágeis de Gestão de ProjetosLeandro Faria
Apresentação utilizada na palestra "Metodologias Ágeis de Gestão de Projetos" ministrada no dia 18/julho de 2012 no 15o Seminário Nacional de Gestão de Projetos do Ietec, em Belo Horizonte, Minas Gerais.
http://br.linkedin.com/pub/lorena-lopes/35/a71/b0O Scrum é uma das metodologias mais utilizadas para gerenciamento de projetos e desenvolvimento ágil de software. A apresentação faz parte do Ciclo de Palestras da Inove (www.inoveinformatica.net) e foi elaborada pela analista de sistemas Lorena Lopes (http://br.linkedin.com/pub/lorena-lopes/35/a71/b0)
Conceitos e princípios dos métodos ágeis, com foco no Scrum. Aborda também técnicas, cerimônias e ferramentas da gestão ágil. Apresentado para diversas áreas do Senado Federal, com o intuito de difundir as práticas para toda a organização.
Apresentação do CRIAR STARTUP, uma iniciativa de um grupo de profissionais e empreendedores prometem transformar qualquer ideia em produto em apenas 3 dias, usando métodos Ágeis para desenvolvimento de Software e frameworks para desenvolvimento rápido de aplicações.
Além de entregar um produto funcional e bonito para encantar os clientes, o CRIAR STARTUP constrói a presença do produto no Facebook, Twitter e Google Plus, faz os primeiros posts e elabora uma estratégia de comunicação para ser seguida pelo empreendedor após o lançamento do produto.
Após a entrega do produto os empreendedores podem começar a faturar, além de terem algo para validar as hipóteses e apresentar para potenciais investidores.
Para conhecer mais sobre essa iniciativa, visite www.criarstartup.com.br ou visite facebook.com/criarstartup
Este certificado confirma que Gabriel de Mattos Faustino concluiu com sucesso um curso de 42 horas de Gestão Estratégica de TI - ITIL na Escola Virtual entre 19 de fevereiro de 2014 a 20 de fevereiro de 2014.
Em um mundo cada vez mais digital, a segurança da informação tornou-se essencial para proteger dados pessoais e empresariais contra ameaças cibernéticas. Nesta apresentação, abordaremos os principais conceitos e práticas de segurança digital, incluindo o reconhecimento de ameaças comuns, como malware e phishing, e a implementação de medidas de proteção e mitigação para vazamento de senhas.
As classes de modelagem podem ser comparadas a moldes ou
formas que definem as características e os comportamentos dos
objetos criados a partir delas. Vale traçar um paralelo com o projeto de
um automóvel. Os engenheiros definem as medidas, a quantidade de
portas, a potência do motor, a localização do estepe, dentre outras
descrições necessárias para a fabricação de um veículo
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...Faga1939
Este artigo tem por objetivo apresentar como ocorreu a evolução do consumo e da produção de energia desde a pré-história até os tempos atuais, bem como propor o futuro da energia requerido para o mundo. Da pré-história até o século XVIII predominou o uso de fontes renováveis de energia como a madeira, o vento e a energia hidráulica. Do século XVIII até a era contemporânea, os combustíveis fósseis predominaram com o carvão e o petróleo, mas seu uso chegará ao fim provavelmente a partir do século XXI para evitar a mudança climática catastrófica global resultante de sua utilização ao emitir gases do efeito estufa responsáveis pelo aquecimento global. Com o fim da era dos combustíveis fósseis virá a era das fontes renováveis de energia quando prevalecerá a utilização da energia hidrelétrica, energia solar, energia eólica, energia das marés, energia das ondas, energia geotérmica, energia da biomassa e energia do hidrogênio. Não existem dúvidas de que as atividades humanas sobre a Terra provocam alterações no meio ambiente em que vivemos. Muitos destes impactos ambientais são provenientes da geração, manuseio e uso da energia com o uso de combustíveis fósseis. A principal razão para a existência desses impactos ambientais reside no fato de que o consumo mundial de energia primária proveniente de fontes não renováveis (petróleo, carvão, gás natural e nuclear) corresponde a aproximadamente 88% do total, cabendo apenas 12% às fontes renováveis. Independentemente das várias soluções que venham a ser adotadas para eliminar ou mitigar as causas do efeito estufa, a mais importante ação é, sem dúvidas, a adoção de medidas que contribuam para a eliminação ou redução do consumo de combustíveis fósseis na produção de energia, bem como para seu uso mais eficiente nos transportes, na indústria, na agropecuária e nas cidades (residências e comércio), haja vista que o uso e a produção de energia são responsáveis por 57% dos gases de estufa emitidos pela atividade humana. Neste sentido, é imprescindível a implantação de um sistema de energia sustentável no mundo. Em um sistema de energia sustentável, a matriz energética mundial só deveria contar com fontes de energia limpa e renováveis (hidroelétrica, solar, eólica, hidrogênio, geotérmica, das marés, das ondas e biomassa), não devendo contar, portanto, com o uso dos combustíveis fósseis (petróleo, carvão e gás natural).
3. Motivação Interna -
Chaos Report
● Projetos de Pontes ● Projetos de Software
● Prazo – OK ( menos no ● Prazo – estoura
Brasil ) ● Orçamento – estoura
● Orçamento – OK ● Têm problemas com
● Quase nenhuma cai freqüência
● Ciência Antiga – 4 a 6 ● Ciência nova – 50 anos
mil anos
4. Motivação Interna -
Chaos Report
Aspectos críticos
● Projetos de ponte são engessados e ninguém dá “pitaco”
● Projetos de software normalmente precisam suportar
mudanças nas regras de negócio
● Pontes que caem têm relatórios de erros. Softwares são
mascarados e ignorados. Não há aprendizado
5. Motivação Interna -
Chaos Report
Projetos que
terminam
31%
Termina
m
16% Prazo e Orçamento
Não
terminam OK
69%
Sim
Não
84%
6. Motivação Interna -
Chaos Report
Requisitos presentes
ao final
42% Sim
Não
58%
7. Motivação do
Mercado
● RAD – Rapid Application Development – anos 90.
● Métodos iterativos (ciclos) e evolucionários (bottom-
up)
● Empresas buscam produtos de TI como forma de
diferenciação
● Frustração com planejamentos
8. Motivação do
Mercado
● Necessidade de atendimento a modelos de
maturidade – CMMI, MPS.BR
● Alternativas à época com baixa tolerância a
mudanças de requisitos
10. E aí!?
● Desenvolvimento ágil não garante necessariamente
que o projeto terá mais ou menos sucesso :-(
11. E aí!?
● Desenvolvimento ágil não garante necessariamente
que o projeto terá mais ou menos sucesso :-(
● Mas ajuda!!! Como?
12. E aí!?
● Desenvolvimento ágil não garante 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
● :-))
13. Manifesto Ágil
● Encontro de 17 agilistas – Utah – Fevereiro – 2001
● Kent Beck – XP (Extreme Programming)
● Ken Schwaber – SCRUM
● Alistair Cockburn – Crystal – Metodologia sob
demanda
● www.agilemanifesto.org
14. 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
15. Manifesto Ágil
● Working software over comprehensive
documentation
● Software bem organizado e documentado
● Alguma documentação existe. Apenas o suficiente e
não conta como produto, resultado de trabalho.
16. Manifesto Ágil
● Customer collaboration over contract negotiation
● Cliente deve estar 'infiltrado' na equipe de
desenvolvimento.
18. Método x Processos
● XP 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
desenvolvimento de software e gestão de projeto
de software
19. Scrum
● O nome vem do rugby. Reinício da partida.
● Baseado na teoria de controle de processo industrial
● Auto-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
20. Scrum
● Empirismo
● Conhecimento a partir da experiência e tomada de
decisões
● Pilares
● Transparência
– Linguagem comum sobre o processo
– Definição de “Pronto”
21. Scrum
● Pilares
● Inspeção
– Artefatos e progresso são inspecionados sempre
– Não pode atrapalhar a execução das tarefas
– Detecção de variações indesejáveis que prejudiquem o
objetivo
22. Scrum
● Pilares
● Adaptação
– Ocorre quando qualquer aspecto sai dos limites
aceitáveis
– O processo ou material produzido deve ser ajustado
– Ajuste deve ser breve para minimizar impactos e
desvios
– Ex.: primeira iteração atrasada em 30%
– Scrum descreve atividades formais para inspeção e
adaptação ( daqui a pouco veremos )
23. Scrum
● Ajuda a controlar projetos de desenvolvimento de
software
● Não garante sucesso completo do projeto
● Garante que o trabalho é dedicado aos resultados
de maior valor agregado
● Se o recurso for cortado, cliente sempre vai ter algo
em mãos com alguma utilidade.
● Requisitos importantes nunca ficam para o final
25. Scrum
● Obtém-se do backlog o que
é de mais valor
● Planeja-se a iteração
● Faz-se acompanhametno
diário
● Entrega acréscimo de
funcionalidades ao fim da
iteração.
26. Scrum - Time
● Times auto-organizáveis e multifuncionais
● Escolhem a melhor forma para completar o trabalho
● Possuem, em conjunto, todas as competências para
realizar TODO o trabalho
● Modelo visa aperfeiçoar flexibilidade, criatividade e
produtividade
● Entregas
● Interativa e Incremental
– Oportunidades de feedback
– Produto “Pronto” sempre disponível para o cliente usar
27. Scrum - Time
● Product Owner (CLIENTE – Interno ou Externo)
● Responsável por Maximizar o valor do produto
● Responsável por Maximizar a produtividade do time
● Ordenar os itens do Backlog, garantindo o valor do
trabalho – planejamento de Sprints e Releases
● Garantir que a Equipe de Desenvolvimento entenda
os itens de Backlog no nível necessário
● Traz informações e expectativas do cliente ao time
● Deve estar integrado a equipe (história do táxi).
28. Scrum - Time
● Team (EQUIPE)
● Profissionais responsáveis por entregar uma versão
usável que potencialmente incrementa o produto
● Existe somente o Desenvolvedor – nenhum outro
título é atribuído
● Auto-gerido e auto-organizado (experiência)
● Multi-funcional ( programador, testador, arquiteto, etc).
As responsabilidades são sempre do time todo
● Devem ter de 3 a 9. Equipes menores não vão
conseguir entregar um incremento e maiores será
difícil de coordenar
29. Scrum - Papéis
● Scrum Master
● Ensinar Scrum aos outros envolvidos
● Manter o método nos “trilhos”
● Respeitar 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
30. Scrum - Papéis
● Scrum Master
● Apoia o PO no gerenciamento do Backlog
● Comunicação do Backlog(visão e objetivo) ao Time
● Treina a equipe de desenvolvimento – auto-
gerenciamento e interdisciplinaridade
● Remover impedimentos para o progresso da equipe
● Facilitação das atividades do Scrum
● Planejamento, liderança e organização da
Implantação do Scrum
31. Scrum - Papéis
● Scrum Master x Gerente de Projetos
● Autoridade indireta, baseada no conhecimento do SM
sobre Scrum
● Papel de facilitador: ajuda o PO a selecionar os itens
do backlog de maior valor, ajuda o TIME a transformar
o backlog em funcionalidade
32. Scrum - Artefatos
● Product backlog
● Requisitos do sistema ou produto sendo
desenvolvido
● O PO é responsável pelo conteúdo, priorização e
disponibilidade do backlog
● Evolui a medida que o produto e o ambiente de
aplicação evoluem
● Dinâmico visando que o produto seja útil e
competitivo
33. Scrum - Artefatos
● Sprint backlog
● Derivado a partir do product backlog
● Detalha os itens do product backlog em tarefas para
que se possa criar um incremento ao produto
● Só o time pode alterar o Sprint Backlog
● Alta visibilidade. Acompanhamento diário da evolução
do status de cada tarefa
34. Scrum - Artefatos
●
Burndown Chart – quanto mais VERTICAL, melhor
● Acima da linha significa atraso
35. Scrum - Artefatos
● Incremento de funcionalidade de produto
potencialmente 'entregável'
● Esse incremento deve ser levantado em cada sprint
● CLIENTE 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
36. Scrum - Regras
● Sprint
● Período de no máximo 30 dias – time-boxed
● Grande o suficiente para o time construir algo de valor
significante para o cliente
● Pequeno o suficiente para o cliente não perde o
interesse no progresso
● Pequeno o suficiente para não ser necessário incluir
documentações para o processo
37. Scrum - Regras
● Sprint – 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.
38. Scrum - Regras
● Sprint Planning Meeting – parte inicial – 4 horas
● 4 horas definindo itens mais importantes e
empacotáveis do backlog de produto
● Todos os papéis participam
● Backlog deve ser preparado antes pelo Product
Owner(de preferência) ou Scrum Master(pior)
● Sprint Planning Meeting – parte final – 4 horas
● Scrum Master responde perguntas da EQUIPE nas 4
horas finais para detalhamento de tarefas
● Ao final, tem-se o Sprint Backlog
39. Scrum - Regras
● Daily Scrum Meeting
● 15 minutos independente do número de membros
● Muita rigidez com presença e pontualidade
● Trê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
● Participação de todos, seja por telefone ou skype
40. Scrum - Regras
● Sprint Review Meeting
● 4 horas
● Apresentar funcionalidades ao Cliente e stakeholders
● Artefatos 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 ouvidos
● Ao final, o próximo Sprint Review Meeting é agendado
41. Scrum - Regras
● Sprint Retrospective Meeting
● 3 horas
● SM, 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 respostas
● TM prioriza a ordem de melhoras em potencial para
discutir
42. Scrum
● Definição de “Pronto”
● Status final de um item do backlog ou um incremento
● Pode variar entre diferentes times de Scrum
● Entendimento compartilhado do que significa o
trabalho estar completo
● A definição orienta os times no planejamento.
Quantas coisas “prontas” cabem em uma iteração?
● Com o ganho de maturidade, os times incrementam a
definição de “pronto” com critérios de qualidade
43. Scrum
● Exemplo de História de Usuário Pronta
● Descrição obedece a: O que? Quem? Por que?
● Todos os campos das interfaces descritos e todos os
comandos da interface detalhados
● Diagramas de caso de uso e interação elaborados
● Exemplo de funcionalidade / incremento pronto
● Implementado
● Casos de testes automatizados e bem sucedidos
● Manual de Instalação
● Manual de Usuário incrementado com o feature liberado
44. Scrum
● Envolvimento x Comprometimento
● História do empreendimento de um porco e uma
galinha.
45. EXtreme
Programming - XP
● “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.
45
46. XP
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.
46
47. XP
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.
47
48. XP
● 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.
48
49. XP
● 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
49
50. XP
● Valores :: Simplicidade
● Posicione-se: onde está e para onde quer ir?
● Qual é o jeito mais simples(barato, legal) de se
mover?
● Valores :: 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
50
51. XP
● Valores :: 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.
● Valores :: Respeito
● Comprometimento. Senso de responsabilidade
● (Edição de 2004 do Embrance Change)
● Respeite o seu time, respeite o que outros fazem
● Respeite o projeto, cuide dele
51
52. XP
● Prática :: 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.
52
53. XP
● Prática :: Planning Game – Jogo do
Planejamento
● 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.
53
54. XP
● Práticas :: Planning Game – Jogo do
Planejamento
54
55. XP
● Prática :: 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?)
55
56. XP
● Prática :: 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.
56
57. XP
● Prática :: 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.
57
58. XP
● Prática :: 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.
58
59. XP
● Prática :: 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
59
60. XP
● Prática :: Coding Standards – Código
padronizado
● Já que todo mundo pode mexer...
● Agilidade na refatoração
● Facilidade de Leitura
● Exemplo:
– http://pear.php.net/manual/en/standards.php
60
61. XP
● Prática :: 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.
61
62. XP
● Prática :: 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
62
63. XP
● Prática :: 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”
63
64. XP
● Prática :: 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.
64
65. XP
● Prática :: 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ínuos
(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
65
66. XP – Desafios para
Implantação
● 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
66
67. XP – Desafios para
Implantação
● 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
67
68. XP – Desafios para
Implantação
● 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
68
69. XP – Desafios para
Implantação
● 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.
69
70. XP – Desafios para
Implantação
● Utilizar XP não vai mudar seus problemas
● Atitudes do cliente
● Prazos mal negociados
● Orçamentos.
● Mas pode 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
70
71. XP – Desafios para
Implantação
● 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.
71
72. XP – Desafios para
Implantação
● 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
72
73. XP – Desafios para
Implantação
● 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.
73
74. XP – Estudos 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 testar suspeitas.
74
75. XP – Estudos de Caso
● 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
75
76. XP – Estudos de Caso
● 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
76
77. XP – Estudos de Caso
● 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
77
81. XP – Estudos de Caso
● 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]
81
82. XP – Estudos de Caso
● 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%
82
84. XP - Documentação
● 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.
84
85. XP - Documentação
● 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)
85
86. XP - Documentação
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
86
87. XP - Escalabilidade
● 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”.
87
88. XP - 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?
88
89. 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.
89