ARC009Team System – Metodologia Ágeise Conceitos: Scrum, XP e MSF AgileBruno Câmara                        Tiago Pascoalbr...
Patrocinadores
Não Somos Pastores!
Agenda Problemas das metodologias tradicionais Manifesto Ágil Scrum Extreme Programming MSF Agile Team System e as Metodol...
Problemas            Só 30% dos           Projectos são   60%    bem Sucedidos   50%   40%   30%   20%   10%    0%        ...
ProblemasCausas   Challenged   Lack of User Input                                                   12.8%   Incomplete Req...
Agile Manifesto“We are uncovering better ways of  developing software by doing it  and helping others do it. ....”        ...
Agile Manifesto“We are uncovering better ways of developing   software by doing it and helping others do it.   Through thi...
Agile Manifesto“We are uncovering better ways of developing   software by doing it and helping others do it.   Through thi...
Agile Manifesto“We are uncovering better ways of developing   software by doing it and helping others do it.   Through thi...
Agile Manifesto“We are uncovering better ways of developing   software by doing it and helping others do it.   Through thi...
Scrum
Origens do Scrum “The New New Product Development Game” in Harvard Business Review, 1986, by Hirotaka Takeuchi and Ikujiro...
Scrum    Estrutura                                                      24 horas                                Daily Scru...
ScrumPorcos e Galinhas
ScrumPapéis ScrumMaster   Responsável pelo processo Scrum Product Owner   Responsável pela visão do produto e pelo   retor...
ScrumArtefactos: Product Backlog
ScrumArtefactos: Sprint Backlog
ScrumArtefactos: Burndown Chart
Scrum - VSTS
Extreme Programming (XP)                 Fonte: http://www.extremeprogramming.org
XPPlaneamento Definição das User Stories Release Planning Pequenas iterações (2-3 semanas) Pequenas releases Planeamento d...
XPDesenho Desenho simples Não adicionar funcionalidades que não vão ser usadas Cartões CRC (Class, Responsabilities and Co...
XPCodificação Pair Programming Testes Unitários Integração Contínua Convenções de Código O cliente está sempre disponível
XPTestes Testes unitários Todos os testes devem passar Perante um Bug devem ser criados novos testes Os Testes de aceitaçã...
Scrum + XP                                                                  -Desenho Simples                              ...
MSF Agile
MSF AgilePersonas e cenários A qualidade de um sistema, mede-se pelo valor que este fornece aos seus utilizadores Como não...
MSF AgilePersonas  Representa um utilizador tipico do sistema,  devem ser:    Reconhecíveis    Reais    Podem ter um perfi...
MSF AgilePersonas do Visual Studio LarrySykes        Jacqui           ArtBenson Business Analyst   Ackerman          Ar...
MSF AgileCenários Representa o caminho que a persona efectua para atingir um objectivo. Formulado na linguagem e no contex...
MSF AgileQOS – Quality of Service  Representam requisitos não  funcionais   Segurança   Privacidade   Desempenho   Usabili...
MSF AgileIterações  Determinar duração da iteração  Estimar cenários e QOSs  Decompor o cenário e QOS em  tarefas  Reserva...
MSF AgileScenarios e Tarefas  Decompor os cenários em tarefas  Os developers escolhem as suas tarefas  O scenario é atribu...
MSF AgilePersonas e Scenarios
MSF AgileAvaliar Progresso  Através dos atributos    Remaining work    Completed Work  Análise Gráficos    Remaining Work ...
VSTS – MSF Agile
Sumário Aceitar a mudança Promover a comunicação Release early and often Adaptação e melhoria contínua
Resources/Recursos Úteis Visual Studio Team System   http://www.microsoft.com/teamsystem Scrum   http://www.controlchaos.c...
Related Sessions/ParticipeNoutras Sessões DEV005 Team System - Extensibilidade e Integração Contínua 20 de Março, 14:15 DE...
Outros RecursosPara Profissionais de TI  TechNet Plus    2 incidentes de suporte gratuito profissional    software exclusi...
Questionário de AvaliaçãoPassatempo! Complete o questionário de avaliação e devolva-o no balcão da recepção. Habilite-se a...
© 2007 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no...
Team System - Metodologias ágeis e conceitos - scrum, msf, xp  (TechDays 2007)
Team System - Metodologias ágeis e conceitos - scrum, msf, xp  (TechDays 2007)
Team System - Metodologias ágeis e conceitos - scrum, msf, xp  (TechDays 2007)
Team System - Metodologias ágeis e conceitos - scrum, msf, xp  (TechDays 2007)
Upcoming SlideShare
Loading in …5
×

Team System - Metodologias ágeis e conceitos - scrum, msf, xp (TechDays 2007)

654 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
654
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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.
  • Team System - Metodologias ágeis e conceitos - scrum, msf, xp (TechDays 2007)

    1. 1. ARC009Team System – Metodologia Ágeise Conceitos: Scrum, XP e MSF AgileBruno Câmara Tiago Pascoalbruno.camara@agilior.pt tiago.pascoal@agilior.ptAgilior Agilior
    2. 2. Patrocinadores
    3. 3. Não Somos Pastores!
    4. 4. Agenda Problemas das metodologias tradicionais Manifesto Ágil Scrum Extreme Programming MSF Agile Team System e as Metodologias Ágeis
    5. 5. 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
    6. 6. ProblemasCausas 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
    7. 7. Agile Manifesto“We are uncovering better ways of developing software by doing it and helping others do it. ....” Fonte: http://www.agilemanifesto.org/
    8. 8. 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 toolsThat is, while there is value in the items on the right, we value the items on the left more. “ Fonte: http://www.agilemanifesto.org/
    9. 9. 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 documentationThat is, while there is value in the items on the right, we value the items on the left more. “ Fonte: http://www.agilemanifesto.org/
    10. 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: Customer collaboration over contract negotiationThat 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. 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: Responding to change over following a planThat 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. 12. Scrum
    13. 13. Origens do Scrum “The New New Product Development Game” in Harvard Business Review, 1986, by Hirotaka Takeuchi and Ikujiro Nonaka
    14. 14. 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 funcionalidadeVisão, Mapa de no produto (potencialmenteReleases, pronto para Produção)Product Product BacklogBacklog Prioritização de Requisitos Fonte: Adaptado de Agile Software Development with Scrum, Ken Schwaber and Mike Beedle.
    15. 15. ScrumPorcos e Galinhas
    16. 16. ScrumPapé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
    17. 17. ScrumArtefactos: Product Backlog
    18. 18. ScrumArtefactos: Sprint Backlog
    19. 19. ScrumArtefactos: Burndown Chart
    20. 20. Scrum - VSTS
    21. 21. Extreme Programming (XP) Fonte: http://www.extremeprogramming.org
    22. 22. XPPlaneamento 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
    23. 23. XPDesenho Desenho simples Não adicionar funcionalidades que não vão ser usadas Cartões CRC (Class, Responsabilities and Collaboration) Refactor
    24. 24. XPCodificação Pair Programming Testes Unitários Integração Contínua Convenções de Código O cliente está sempre disponível
    25. 25. XPTestes 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
    26. 26. 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 funcionalidadeVisão, Mapa de no produto (potencialmenteReleases, Prioritização de Requisitos pronto para Produção)ProductBacklog User Stories Fonte: Adaptado de Agile Software Development with Scrum, Ken Schwaber and Mike Beedle.
    27. 27. MSF Agile
    28. 28. MSF AgilePersonas 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.
    29. 29. MSF AgilePersonas 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”
    30. 30. MSF AgilePersonas do Visual Studio LarrySykes Jacqui ArtBenson Business Analyst Ackerman Architect Project ManagerMort Gaines Ian ManningDeveloper Renee Davis Tester Release Manager
    31. 31. MSF AgileCená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
    32. 32. MSF AgileQOS – Quality of Service Representam requisitos não funcionais Segurança Privacidade Desempenho Usabilidade Gestão
    33. 33. MSF AgileIteraçõ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
    34. 34. MSF AgileScenarios 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)
    35. 35. MSF AgilePersonas e Scenarios
    36. 36. MSF AgileAvaliar Progresso Através dos atributos Remaining work Completed Work Análise Gráficos Remaining Work Bug Rates Unplanned Work Scenario Details
    37. 37. VSTS – MSF Agile
    38. 38. Sumário Aceitar a mudança Promover a comunicação Release early and often Adaptação e melhoria contínua
    39. 39. 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
    40. 40. Related Sessions/ParticipeNoutras 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
    41. 41. Outros RecursosPara 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
    42. 42. Questionário de AvaliaçãoPassatempo! 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!CODXXXXXSession Name
    43. 43. © 2007 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

    ×