Team System - Metodologias ágeis e conceitos - scrum, msf, xp (TechDays 2007)
•
1 gostou•576 visualizações
Promover a comunicação e a adaptação às mudanças são princípios centrais das metodologias ágeis. O documento descreve Scrum, XP e MSF Agile, abordando papéis, artefactos e práticas como planeamento iterativo, envolvimento do cliente e valorização do software funcionando sobre a documentação. As metodologias promovem o desenvolvimento de software de forma colaborativa e adaptável às necessidades dos utilizadores.
Mais conteúdo relacionado
Mais procurados
Mais procurados (18)
Semelhante a Team System - Metodologias ágeis e conceitos - scrum, msf, xp (TechDays 2007)
Semelhante a Team System - Metodologias ágeis e conceitos - scrum, msf, xp (TechDays 2007) (20)
Team System - Metodologias ágeis e conceitos - scrum, msf, xp (TechDays 2007)
- 2. ARC009 Team System – Metodologia Ágeis e Conceitos: Scrum, XP e MSF Agile Bruno Câmara Tiago Pascoal bruno.camara@agilior.pt tiago.pascoal@agilior.pt Agilior Agilior
- 5. Agenda Problemas das metodologias tradicionais Manifesto Ágil Scrum Extreme Programming MSF Agile Team System e as Metodologias Ágeis
- 6. Problemas Só 30% dos Projectos são 60% bem Sucedidos 50% 40% 30% 20% 10% 0% 1994 1996 1998 2000 2002 2004 Succeeded Failed Challenged Fonte: Standish Group, 2004 Third Quarter Research Report, CHAOS Research Results
- 7. Problemas Causas Challenged Lack of User Input 12.8% Incomplete Requirements & Specifications 12.3% Changing Requirements & Specifications 11.8% Success User Involvement Support Lack of Executive 7.5% 15.9% Executive Management Support 13.9% Failed Clear Statement of Requirements 13.0% Incomplete Requirements 13.1% Lack of User Involvement 12.4% Lack of Resources 10.6% Unrealistic Expectations 9.9% Fonte: Standish Group, 2004 Third Quarter Research Report, CHAOS Research Results
- 9. Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. ....” Fonte: http://www.agilemanifesto.org/
- 10. Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools That is, while there is value in the items on the right, we value the items on the left more. “ Fonte: http://www.agilemanifesto.org/
- 11. Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Working software over comprehensive documentation That is, while there is value in the items on the right, we value the items on the left more. “ Fonte: http://www.agilemanifesto.org/
- 12. Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Customer collaboration over contract negotiation That is, while there is value in the items on the right, we value the items on the left more. “ Fonte: http://www.agilemanifesto.org/
- 13. Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. “Fonte: http://www.agilemanifesto.org/
- 15. Scrum
- 16. Origens do Scrum “The New New Product Development Game” in Harvard Business Review, 1986, by Hirotaka Takeuchi and Ikujiro Nonaka
- 17. Scrum Estrutura 24 horas Daily Scrum 15 min Sprint Review and Retrospective Meeting Sprint Sprint 4H + 3H Planning Sprint Backlog Meeting 30 dias (Tarefas) 4H + 4H Incremento de funcionalidade Visão, Mapa de no produto (potencialmente Releases, pronto para Produção) Product Product Backlog Backlog Prioritização de Requisitos Fonte: Adaptado de Agile Software Development with Scrum, Ken Schwaber and Mike Beedle.
- 19. Scrum Papéis ScrumMaster Responsável pelo processo Scrum Product Owner Responsável pela visão do produto e pelo retorno do investimento. Team Equipa responsável por executar os planos definidos para o produto
- 23. Scrum - VSTS
- 24. Extreme Programming (XP) Fonte: http://www.extremeprogramming.org
- 25. XP Planeamento Definição das User Stories Release Planning Pequenas iterações (2-3 semanas) Pequenas releases Planeamento da iteração (escolha das user stories e cenários de teste) Reunião diária Stand-up
- 26. XP Desenho Desenho simples Não adicionar funcionalidades que não vão ser usadas Cartões CRC (Class, Responsabilities and Collaboration) Refactor
- 27. XP Codificação Pair Programming Testes Unitários Integração Contínua Convenções de Código O cliente está sempre disponível
- 28. XP Testes Testes unitários Todos os testes devem passar Perante um Bug devem ser criados novos testes Os Testes de aceitação devem correr frequentemente com publicação de resultados
- 29. Scrum + XP -Desenho Simples -Testes unitários -Refactoring -Pair Programming 24 horas -Integração Contínua Daily Scrum -Convencções de Código Selecção dos Sprint requisitos Sprint Backlog para o Sprint 30 dias (Tarefas) Product Backlog Incremento de funcionalidade Visão, Mapa de no produto (potencialmente Releases, Prioritização de Requisitos pronto para Produção) Product Backlog User Stories Fonte: Adaptado de Agile Software Development with Scrum, Ken Schwaber and Mike Beedle.
- 30. MSF Agile
- 31. MSF Agile Personas e cenários A qualidade de um sistema, mede-se pelo valor que este fornece aos seus utilizadores Como não temos um utilizador sempre presente para avaliar recorremos a personas e cenários Ferramentas para perceber , comunicar e criar esse valor para os utilizadores.
- 32. MSF Agile Personas Representa um utilizador tipico do sistema, devem ser: Reconhecíveis Reais Podem ter um perfil e motivações diferente Tem um nome próprio e uma foto Cria empatia com quem desenvolve o sistema Permite um foco individualizado em vez de um “segmento de mercado”
- 33. MSF Agile Personas do Visual Studio LarrySykes Jacqui ArtBenson Business Analyst Ackerman Architect Project Manager Mort Gaines Ian Manning Developer Renee Davis Tester Release Manager
- 34. MSF Agile Cenários Representa o caminho que a persona efectua para atingir um objectivo. Formulado na linguagem e no contexto do utilizador As diferenças de visão dos 2 lados ficam mais visíveis Tangível e pode ser validado pelo utilizador Reduz ambiguidade Ajuda ao macro planeamento do projecto
- 35. MSF Agile QOS – Quality of Service Representam requisitos não funcionais Segurança Privacidade Desempenho Usabilidade Gestão
- 36. MSF Agile Iterações Determinar duração da iteração Estimar cenários e QOSs Decompor o cenário e QOS em tarefas Reservar tempo para resolução de bugs Agendar cenários e QOSs
- 37. MSF Agile Scenarios e Tarefas Decompor os cenários em tarefas Os developers escolhem as suas tarefas O scenario é atribuído a uma pessoa (tipicamente developer) Responsável por garantir que os testes tem sucesso e fechar o scenario quando completo Criam e atribuem-se tarefas de testes (por scenario e podem estar ou não relacionados com uma tarefa)
- 38. MSF Agile Personas e Scenarios
- 39. MSF Agile Avaliar Progresso Através dos atributos Remaining work Completed Work Análise Gráficos Remaining Work Bug Rates Unplanned Work Scenario Details
- 40. VSTS – MSF Agile
- 41. Sumário Aceitar a mudança Promover a comunicação Release early and often Adaptação e melhoria contínua
- 42. Resources/Recursos Úteis Visual Studio Team System http://www.microsoft.com/teamsystem Scrum http://www.controlchaos.com http://www.scrumforteamsystem.com http://www.codeplex.com/VSTSScrum XP http://www.extremeprogramming.org MSF http://www.microsoft.com/msf
- 43. Related Sessions/Participe Noutras Sessões DEV005 Team System - Extensibilidade e Integração Contínua 20 de Março, 14:15 DEV014 Team System – Boas práticas para melhorar a qualidade de código 21 de Março, 13:30
- 45. Outros Recursos Para Profissionais de TI TechNet Plus 2 incidentes de suporte gratuito profissional software exclusivo: Capacity Planner software Microsoft para avaliação actualizações de segurança e service packs acesso privilegiado à knowledge base formação gratuita e muito mais. www.microsoft.com/portugal/technet/subscricoes
- 46. Questionário de Avaliação Passatempo! Complete o questionário de avaliação e devolva-o no balcão da recepção. Habilite-se a ganhar uma Xbox 360 por dia! CODXXXXX Session Name
- 47. © 2007 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
Notas do Editor
- Na Agilior temos por hábito fazer uma analogia entre toda esta problemática das metodologias e as religiões. Isto porque, tal como acontece na religião, a adopção de determinada metodologia tem a ver com as nossas crenças e convicções. Nós só adoptamos determinada m.etodologia se acreditarmos profundamente que a mesma é boa para a nossa prática do desenvolvimento de software.Mas ainda que façamos esta analogia, não nos vejam como os pastores que vêm aqui evangelizar determinada metodologia, e que nos vamos pôr a cantar e a fazer histerias colectivas. Até porque acreditamos que assim que tipicamente uma pessoa tem uma preferência por determinada metodologia tipicamente não muda ou muda com muita resistência. O mesmo acontece com a religião, como devem calcular converter um muçulmano em católico é uma tarefa quase impossível.O importante é no final do dia vocês escolherem as melhores práticas das diferentes metodologias que forem conhecendo.
- Sucesso: On Time, On Budget, com tosos os requisitos solicitadosChallenged: Com Atraso, Excede Orçamento, Não faz tudo o que é suposto.Failed: Abortado sem resultadosPorque é que apenas 30% dos Projectos na nossa indústria sucedem? Acham que esta taxa de sucesso é aceitável? Na nossa opinião é claramente uma taxa de que não nos orgulhamos. Mas o importante aqui é percebermos porque é que isto acontece. www.softwaremag.com/L.cfm?doc=newsletter/2004-01-15/standish
- Na vossa opinião qual a principal razão para o insucesso?http://www.spinroot.com/spin/Doc/course/Standish_Survey.htmPortanto, no topo da lista temos as seguintes razões: 1 – Requisitos imcompletos 2 – Envolvimento do utilizador
- On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground�and of course, to eat. What emerged was the Agile �Software Development� Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.Incomplete Requirements: - Customer Collaboration: se o cliente fizer parte da equipa poderemos todos ter um entendimento melhor sobre os requisitos - Individuals and interactions: aumentando a comunicação na equipa poderemos perceber melhor os requisitos - Se tivermos Software em vez de documentação o cliente aperceber-se-á mais rapidamente se aquilo que pretende é aquilo que realmente está a ser entregueLack of User Involvement - Customer Collaboration: se o o cliente faz parte da equipa... - Working Software: o cliente mais rápidamente dá feedback sobre o que está a obterChange Requirements & Specification - Responding to change: encarar a mudança como algo natural em vez de seguirmos um plano já desajustado da realidade. - Customer Collaboration: permiter ter um entendimento melhor sobre as alterações pretendidas - Working Software: permite ao cliente aperceber-se mais cedo se a sua alteração foi bem implementada
- On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground�and of course, to eat. What emerged was the Agile �Software Development� Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.Incomplete Requirements: - Customer Collaboration: se o cliente fizer parte da equipa poderemos todos ter um entendimento melhor sobre os requisitos - Individuals and interactions: aumentando a comunicação na equipa poderemos perceber melhor os requisitos - Se tivermos Software em vez de documentação o cliente aperceber-se-á mais rapidamente se aquilo que pretende é aquilo que realmente está a ser entregueLack of User Involvement - Customer Collaboration: se o o cliente faz parte da equipa... - Working Software: o cliente mais rápidamente dá feedback sobre o que está a obterChange Requirements & Specification - Responding to change: encarar a mudança como algo natural em vez de seguirmos um plano já desajustado da realidade. - Customer Collaboration: permiter ter um entendimento melhor sobre as alterações pretendidas - Working Software: permite ao cliente aperceber-se mais cedo se a sua alteração foi bem implementada
- On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground�and of course, to eat. What emerged was the Agile �Software Development� Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.Incomplete Requirements: - Customer Collaboration: se o cliente fizer parte da equipa poderemos todos ter um entendimento melhor sobre os requisitos - Individuals and interactions: aumentando a comunicação na equipa poderemos perceber melhor os requisitos - Se tivermos Software em vez de documentação o cliente aperceber-se-á mais rapidamente se aquilo que pretende é aquilo que realmente está a ser entregueLack of User Involvement - Customer Collaboration: se o o cliente faz parte da equipa... - Working Software: o cliente mais rápidamente dá feedback sobre o que está a obterChange Requirements & Specification - Responding to change: encarar a mudança como algo natural em vez de seguirmos um plano já desajustado da realidade. - Customer Collaboration: permiter ter um entendimento melhor sobre as alterações pretendidas - Working Software: permite ao cliente aperceber-se mais cedo se a sua alteração foi bem implementada
- On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground�and of course, to eat. What emerged was the Agile �Software Development� Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.Incomplete Requirements: - Customer Collaboration: se o cliente fizer parte da equipa poderemos todos ter um entendimento melhor sobre os requisitos - Individuals and interactions: aumentando a comunicação na equipa poderemos perceber melhor os requisitos - Se tivermos Software em vez de documentação o cliente aperceber-se-á mais rapidamente se aquilo que pretende é aquilo que realmente está a ser entregueLack of User Involvement - Customer Collaboration: se o o cliente faz parte da equipa... - Working Software: o cliente mais rápidamente dá feedback sobre o que está a obterChange Requirements & Specification - Responding to change: encarar a mudança como algo natural em vez de seguirmos um plano já desajustado da realidade. - Customer Collaboration: permiter ter um entendimento melhor sobre as alterações pretendidas - Working Software: permite ao cliente aperceber-se mais cedo se a sua alteração foi bem implementada
- On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground�and of course, to eat. What emerged was the Agile �Software Development� Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.Incomplete Requirements: - Customer Collaboration: se o cliente fizer parte da equipa poderemos todos ter um entendimento melhor sobre os requisitos - Individuals and interactions: aumentando a comunicação na equipa poderemos perceber melhor os requisitos - Se tivermos Software em vez de documentação o cliente aperceber-se-á mais rapidamente se aquilo que pretende é aquilo que realmente está a ser entregueLack of User Involvement - Customer Collaboration: se o o cliente faz parte da equipa... - Working Software: o cliente mais rápidamente dá feedback sobre o que está a obterChange Requirements & Specification - Responding to change: encarar a mudança como algo natural em vez de seguirmos um plano já desajustado da realidade. - Customer Collaboration: permiter ter um entendimento melhor sobre as alterações pretendidas - Working Software: permite ao cliente aperceber-se mais cedo se a sua alteração foi bem implementada
- O termo Scrum designa a formação que é feita no Rugby.
- “The New New Product Development Game” in Harvard Business Review, 1986, by Hirotaka Takeuchi and IkujiroNonaka“The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.”
- The story: A chicken and a pig are walking down the road. The chicken says to the pig, “Do you want to open a restaurant with me?”. The pig considers and says “Yes. What do you want to call the restaurant”. The chicken said “Ham and Eggs”. The pig stops, pauses and replies “On second thought, i don’t think i want to open a restaurant with you. I’d be committed, but you’d only be involvedUm porco: uma pessoa totalmente empenhada no projectoUma galinha: uma pessoa apenas envolvida no projecto.Uma métrica possível: Se podes ser despedido pelo insucesso do projecto então és um Porco. Caso Contrários és uma galinha
- Define os requisitos funcionais e não funcionais, com a respectiva prioridadeAssociado a cada requisito existe uma estimativa grosseira de esforçoNunca está completoPode a qualquer altura ser alterado
- Define as tarefas a serem realizadas durante o SprintAs tarefas devem ser divididas de forma a que cada tarefa demore 4-16 horasApenas a Equipa pode alterarNo final do dia, cada membro da equipa deve actualizar o Sprint Backlog
- Mostra a evolução ao longo do tempo, do esforço necessário para a conclusão do produto/SprintPermite fazer “what-if analysis”: se eu remover determinada funcionalidade qual será a nova data expectável da release?Pode ser aplicado ao Product Backlog, ao Sprint Backlog (à Equipa ou Individual)
- In the early 1990s a man named Kent Beck was thinking about better ways to develop software. He had recently spent some time working with Ward Cunningham. Ward and Kent together had experienced an approach to software development that made every thing seem simple and more efficient. Kent contemplated on what made software simple to create and what made it difficult. In March of 1996 Kent started a project at DaimlerChrysler using new concepts in software development. The result was the Extreme Programming (XP) methodology.
- Começa-se por definir as User Stories: é o equivalente aos Use-Cases. São escritos pelos clientes e definem cenários de utilização. Devem ser tb definidos testes de aceitação para cada user-story. É tb dada uma ema estimativa a cada user story. Release Planning: consistem em definir o RoadMap de Releases, com base nas prioridades.Iteration Planning: definição das tarefas para cada User Story.