• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Team System - Metodologias ágeis e conceitos - scrum, msf, xp  (TechDays 2007)
 

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

on

  • 436 views

 

Statistics

Views

Total Views
436
Views on SlideShare
436
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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) Team System - Metodologias ágeis e conceitos - scrum, msf, xp (TechDays 2007) Presentation Transcript

  • ARC009Team System – Metodologia Ágeise Conceitos: Scrum, XP e MSF AgileBruno Câmara Tiago Pascoalbruno.camara@agilior.pt tiago.pascoal@agilior.ptAgilior Agilior
  • Patrocinadores
  • Não Somos Pastores!
  • Agenda Problemas das metodologias tradicionais Manifesto Ágil Scrum Extreme Programming MSF Agile Team System e as Metodologias Ágeis
  • 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
  • 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
  • Agile Manifesto“We are uncovering better ways of developing software by doing it and helping others do it. ....” Fonte: http://www.agilemanifesto.org/
  • 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/
  • 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/
  • 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/
  • 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/
  • Scrum
  • Origens do Scrum “The New New Product Development Game” in Harvard Business Review, 1986, by Hirotaka Takeuchi and Ikujiro Nonaka
  • 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.
  • ScrumPorcos e Galinhas
  • 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
  • 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 da iteração (escolha das user stories e cenários de teste) Reunião diária Stand-up
  • XPDesenho Desenho simples Não adicionar funcionalidades que não vão ser usadas Cartões CRC (Class, Responsabilities and Collaboration) Refactor
  • 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ção devem correr frequentemente com publicação de resultados
  • 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.
  • 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 temos um utilizador sempre presente para avaliar recorremos a personas e cenários Ferramentas para perceber , comunicar e criar esse valor para os utilizadores.
  • 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”
  • MSF AgilePersonas do Visual Studio LarrySykes Jacqui ArtBenson Business Analyst Ackerman Architect Project ManagerMort Gaines Ian ManningDeveloper Renee Davis Tester Release Manager
  • 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
  • MSF AgileQOS – Quality of Service Representam requisitos não funcionais Segurança Privacidade Desempenho Usabilidade Gestão
  • 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
  • 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)
  • MSF AgilePersonas e Scenarios
  • MSF AgileAvaliar Progresso Através dos atributos Remaining work Completed Work Análise Gráficos Remaining Work Bug Rates Unplanned Work Scenario Details
  • 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.com http://www.scrumforteamsystem.com http://www.codeplex.com/VSTSScrum XP http://www.extremeprogramming.org MSF http://www.microsoft.com/msf
  • 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
  • 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
  • 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
  • © 2007 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.