• Nenhum resultado encontrado

Métodos Ágeis de Gerência de Software

N/A
N/A
Protected

Academic year: 2021

Share "Métodos Ágeis de Gerência de Software"

Copied!
97
0
0

Texto

(1)

Métodos Ágeis de Gerência de

Métodos Ágeis de Gerência de

Software

Software

Rodrigo de Toledo

Rodrigo de Toledo

(CSM)(CSM)

10 maio 2008

10 maio 2008

(Formação) (Formação)

(2)

Plano

Plano

• Introdução: – Motivação – Histórico – Princípios • Scrum: – Scrum flow

– Personagens, artefatos e meetings

• Prática:

– Velocity, Sprint, Review

– Aplicações, mitos e restrições

• Conclusão:

– Metodologias ágeis no mundo

• Scrum e CMMI

– Metodologias ágeis na Petrobras

(3)

Introdução

(4)

Motivação – Métodos Ágeis

Motivação – Métodos Ágeis

• Metodologias apropriadas a essa nova

ciência: a engenharia de software

• O que tem de tão interessante:

– Processos iterativos,

– people-oriented,

– Cross-functional teams,

– inspeção/adaptação,

– Alta produtividade (4 a 10 vezes maior)

– Satisfação de todos: clientes, usuários,

(5)

Motivação – Métodos Ágeis

Motivação – Métodos Ágeis

(6)

Termos

Termos

• Métodos Ágeis: se contrapõem às metodologias de engenharia

clássica, geralmente aplicados ao desenvolvimento de software. Ex: XP, Scrum, Crystal, Lean (RUP?)...

• Iteração: Etapas curtas (2 a 4 semanas) de

planejamento/desenvolvimento. O processo iterativo se contrapõem ao processo em cascata.

• Adaptação: Passa a ser a verdadeira opção à natureza imprevisível do desenvolvimento de software. Troca-se o par planejamento/controle por inspeção/adaptação.

• Self-organization: As pessoas são responsáveis pelo seu

próprio trabalho. (people-oriented x process-oriented)

• Time-box: Todas as etapas devem estar contidas no seu tempo

(7)

Motivação - Caos

Motivação - Caos

• Desenvolvimento caótico

– “Code and fix” ou “Quick and dirty”

– Um cara só faz tudo - generalista

– Imprevisível

– Pode funcionar para aplicações pequenas

– Pontos negativos:

• “Dono” do código • Baixo reuso

• Dificuldade para manutenção • ...

(8)
(9)

Motivação - Engenharia

Motivação - Engenharia

• Metodologias de engenharias

– Eng. de sw é muito nova comparada com as demais – Por que não usar outras metodologias clássicas?

• Eng. Civil, mecânica, aeronáutica ... • Planejamento  Implementação • Linha de montagem

• Cada etapa tem um responsável diferente - especialistas

– Benefícios:

• Gerenciamento facilitado (pessoas são peças) • Reuso possível

(10)

• Metodologias de engenharias

– Questionamentos:

• Esforço no planejamento é muito maior que nas outras engenharias

• É previsível ?

– Desenvolvimento de sw é considerado a atividade mais complexa do ser humano.

– Pontos negativos:

• Software não é prédio • Perda de flexibilidade • Falsas verdades

Motivação - Engenharia

(11)

Motivação - Engenharia

Motivação - Engenharia

• Construir software NÃO É

igual a construir prédio

– Metáforas são perigosas (mas quase inevitáveis) – Nosso peão é um arquiteto (criativo, artista)

• Desde a primeira prova de programação • Peão feliz/infeliz (muro/igreja)

– Se derrubar uma parede errada, basta fazer um ctrl+z – Falta um tijolo no prédio  falta um “ ; ” no código – Não estamos presos a leis físicas (e.g., gravidade) – Mudanças tecnológicas maiores em impacto e

(12)

Motivação - Engenharia

Motivação - Engenharia

• Perda de Flexibilidade

– Mudanças externas constantes

• Decorrentes da imprecisão dos requisitos

– Falha de quem está levantando

– Incapacidade do cliente em detalhar

(ex: construção customizada de um carro)

Frase comum: “o problema deste projeto é que os requisitos vivem mudando”

(13)

Motivação - Engenharia

Motivação - Engenharia

• Perda de Flexibilidade (Jeff Sutherland et al. 08)

– Ziv’s Uncertainty Principle:

Uncertainty is inherent and inevitable in software development processes and products

– Humphrey’s Requirements Uncertainty Principle:

For a new software system the requirements will not be completely known until after the users have used it.

– Wegner’s Lemma:

(14)

Motivação - Engenharia

Motivação - Engenharia

• Mitos sobre as metodologias de engenharia:

– Esforço maior apenas no início do projeto – Pessoas são apenas peças do processo – Quanto mais informação escrita melhor – Previsibilidade

• Processos criativos não são fáceis de planejar

((A engenharia de software é ao mesmo tempo uma ciência precisa/matemática e um exercício criativo/humano))

• Pior ainda: Fingir que é previsível

– Documentos que não são lidos

– Documentos para descrever como algo será feito escritos depois desse algo feito

– Fim do projeto! Bom projeto tem fim ? – O que é um produto de sucesso ?

• No prazo, no custo e de acordo com o plano

Maior Business Value Não

(15)

Video

(16)

Histórico – Métodos Ágeis

Histórico – Métodos Ágeis

• Anos 80 (qualidade)

– Nonaka e Takeuchi:

• Toyota, Xerox, 3M, Fujifilm ... • “Knowledge Management”

• Papers: “The New New Product Development Game”, 1986 “The knowledge-creating company”

– Algumas histórias ou lendas:

• Força tarefa japonesa

• Grupo de consultoria (Toyota consulting)

• Qualidade começou anos 70 com americano

– SmallTalk (Xerox, 1980)

• OO, metaclasses, dev. environment, virtual machine (1983), unit test

(17)

Histórico – Métodos Ágeis

Histórico – Métodos Ágeis

• Anos 90 (Eng.Sw.)

– XP (Kent Beck e Ron Jeffries, ~97)

• 5 valores, 14 princípios, 24 práticas • Outra lenda:

Kent Beck desafia QA’s (GQS) em 2001 • TDD

– Scrum (Jeff Sutherland, Ken Schwaber, Mike

Beedle 93~95~99)

• Mais gerencial que XP

– Crystal (Alistair Cockburn)

• Coleção de métodos • Mais flexível que XP

(18)

Histórico – Métodos Ágeis

Histórico – Métodos Ágeis

• Anos 2000

– Grande divulgação

– Diversos exemplos de uso

• 2001

– Agile Manifesto

– Agile Alliance

• Últimos anos

– Google, Yahoo, Borland, Sega (todas as

grandes empresas de jogos), MS …

(19)

Manifesto for Agile Software Development

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

Working software over comprehensive documentation

Customer collaboration over contract negotiation

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.

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Kent Beck Mike Beedle Arie van Bennekum

Alistair Cockburn Ward Cunningham

(20)

Principles behind the Agile Manifesto

Principles behind the Agile Manifesto

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• Working software is the primary measure of progress.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

• Continuous attention to technical excellence and good design enhances agility. • Simplicity--the art of maximizing the amount of work not done--is essential.

• The best architectures, requirements, and designs emerge from self-organizing teams.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

(21)

Video

Video

(22)

About SCRUM

About SCRUM

Product Owner Scrum Master Done Visibility Retrospectives Planning POKER Stand-up Meeting Sprint Product Backlog Selected Backlog Sprint Backlog Team Burn-down Chart Story Points Time Box Task Board

(23)

SCRUM

(24)

Scrum

Scrum

• Metaprocesso (framework)

– “Metodologia que diz que metodologias não são tão importantes”

• Adaptável

– 1ª regra: as regras podem ser alteradas*

• Promete alta qualidade

– software robusto

• Promete alta produtividade

– 4 a 10 vezes mais produtivo

– Mais “business value” ou valor agregado * Existem algumas pré-condições

(25)

Scrum – Primeiros Conceitos

Scrum – Primeiros Conceitos

• Sprint:

– iteração

– período de 2 a 4 semanas de trabalho da equipe

• Daily sprint:

– 1 dia de trabalho da equipe

• Product backlog:

– Lista de requisitos em formato user-story – Ordenada por prioridade

• Selected backlog:

– Lista de tarefas a serem realizadas durante a sprint – Baseada nas maiores prioridades do product backlog – De acordo com a capacidade da equipe em uma

(26)

Scrum

(27)

Scrum - Personagens

(28)

Scrum - Personagens

Scrum - Personagens

• Apenas três

• Não tem relação direta com cargos e

hierarquias

Scrum Master Product Owner

(29)

Scrum - Personagens

Scrum - Personagens

• Product Owner

– Fornece a visão do negócio

– Mantém os itens do product backlog

atualizados e priorizados

– A cada início de sprint auxilia a elaborar o

selected backlog

– Maximiza ROI ("valor agregado")

– Aceita ou rejeita o que foi produzido

– Alta participação em início e fim de sprints

– Disponível para esclarecer dúvidas

(30)

Scrum - Personagens

Scrum - Personagens

• Scrum Master

– Facilitador

– Não tem autoridade

– Conduz reuniões e eventos

– Mantém o Scrum funcionando

– Remove empecilhos e obstáculos

– Presta serviço ao time

– Protege o time

– Ajuda o time nas suas tarefas

(31)

Scrum - Personagens

Scrum - Personagens

• Time

– Multidisciplinar

• sem papéis específicos

– Auto-gerenciado

– de 5 a 9 pessoas

– Comprometido com o objetivo e consigo mesmo

• esforçado, pontual etc.

– Autoridade para fazer o que for necessário para

atingir o objetivo

– Comunicação constante

(32)
(33)

Scrum - Comprometimento

Scrum - Comprometimento

• Comprometimento x Envolvimento

• Porcos e galinhas

(34)

Scrum - Princípios

(35)

Scrum - Princípios

Scrum - Princípios

Processo iterativo e incremental (1/6)

• Modelo Tradicional

• Modelo Ágil

(36)

Scrum - Princípios

Scrum - Princípios

Processo iterativo e incremental (1/6)

• Benefícios:

– confiabilidade do software

– antecipação de valor agregado

– aumento de confiança do cliente

– motivação do time

Manifesto Ágil: devemos valorizar mais SOFTWARE FUNCIONAIS do que documentações extensas.

(37)

Scrum - Princípios

Scrum - Princípios

Auto-organização (2/6)

• Acreditar na competência das pessoas

• O time tem capacidade de se

auto-organizar

• Tarefas não devem ser atribuídas

autoritariamente, mas voluntariamente

– pull tasks, not push

• atribuições ocorrem diariamente

(38)

Scrum - Princípios

Scrum - Princípios

Comunicação (transparência) (3/6)

• Através de reuniões diárias a comunicação é

feita pessoalmente

• Controles visuais

• Reuniões regulares de retrospectiva

– A cada mudança de sprint – Verificação de obstáculos – Melhora contínua

• Problemas vêem rapidamente a superfície

• group programming (collective code ownership)

– Resultado das atribuições diárias e

(39)

Scrum - Princípios

Scrum - Princípios

Time-box (4/6)

• O tempo da sprint é mandatório

(assim como qualidade)

• Todos os meetings

tem tempo fixo:

– Daily-meeting – Sprint Planning – Etc... Qualidade Tempo Escopo Fixos custo/esforço Único que pode alterar

(40)

Scrum - Princípios

Scrum - Princípios

Menos planejamento, mais ação (5/6)

• Retardar decisões

– Por causa da complexidade – Não há conflito com:

• "não deixe para amanhã o que pode ser feito hoje" • Um é ação e outro é planejamento

– Retardar uma decisão e retomá-la apenas no momento apropriado:

• cenário mais atualizado • novas prioridades

• mais conhecimento sobre as condições

Manifesto Ágil: devemos valorizar mais REAGIR A MUDANÇAS do que seguir um plano.

(41)

Scrum - Princípios

Scrum - Princípios

Menos planejamento, mais ação (5/6)

• Mais código e menos documentação prévia

• Planejamento Fibonacci (1,1,2,3,5,8,13,21...)

– Escala progressiva

– Detalhes do planejamento devem ser inversamente proporcionais à distância no tempo

– Scrum tem 3 escalas: projeto, sprint, dia

• Não discutir muito o processo:

– Tentar primeiro e melhorar para a próxima sprint

Manifesto Ágil: devemos valorizar mais SOFTWARE FUNCIONAIS do que documentações extensas. REPETINDO

(42)

Scrum - Princípios

Scrum - Princípios

Cliente é um parceiro (6/6)

• Participação ao longo do projeto

• Acompanhamento mensal

• Disponibilidade para dúvidas

• Mudanças de requisitos são bem-vindas a

qualquer momento

Manifesto Ágil: devemos valorizar mais COLABORAÇÃO COM O

(43)

Scrum Phases

Scrum Phases

• Diferença entre

estratégia e tática

• Já vimos:

– Product Backlog – Selected Backlog

• Falta vermos:

– User story – Story point

– Task e Sprint Backlog – Task Board

(44)

Scrum

Scrum

Flow

(45)

Scrum - Artefatos

(46)

Scrum – Artefatos

Scrum – Artefatos

• User Story (backlog items)

– Product e Selected Backlogs são compostos por user stories. – Campos:

• ID, Título (ou descrição sucinta) • Valor

– Valor medido pelo product owner (business value)

– Não precisa ter valores absolutos, podem ser relativos

• Story points

• Descrição mais detalhada

– Suficiente para compreensão de time

– Pode ser uma descrição da interação com o usuário ou uma prévia da lista de tarefas

– Outros possíveis campos:

• “Me <name>, as <user role>, would like to <feature>, so that <value>” • Sprint number

(47)

Scrum – Artefatos

Scrum – Artefatos

• Story Points

– Medida de esforço de implementação

– Associado a cada story

– Valores concretos ou relativos?

• Pode ser associado a uma referência concreta

– ex: Homem-dia de trabalho

• Pode ser simplesmente um valor relativo

– Ex: Escolhe-se a story mais simples e pontua com valor 2

– Usa-se uma série adaptada de Fibonacci:

1, 2, 3, 5, 8, 13, 20, 40 e 100

(48)

Scrum – Artefatos

Scrum – Artefatos

• Tasks

– Cada story deverá ser quebrada em tarefas

– Idealmente, tarefas correspondem a 1 dia de trabalho – São a menor unidade de divisão

– Cada tarefa vira um Post-it

– As atribuições das tarefas às pessoas ocorre diariamente

• Sprint Backlog

– Conjunto de tasks de cada uma das stories da sprint corrente

(49)

Scrum – Artefatos

Scrum – Artefatos

(50)

Scrum – Artefatos

Scrum – Artefatos

• Task Board

– To do, doing, done – Conceito de DONE

– Pode ter outras colunas, exemplos:

• commited • reviewed – Burn-down chart – Outros conteúdos: • Post-it chart • Limbo • Impediments • Notícias – Mesa retrátil

(51)

Scrum – Artefatos

Scrum – Artefatos

• Burn-down Chart

– São dois:

• Por sprint • Produto completo

– Contagem de pontos

• Pontos parciais das stories • Total de pontos da story

(52)

Scrum - Meetings

(53)

Scrum - Meetings

Scrum - Meetings

• São 6 diferentes meetings

MEETINGS

Sprint i Sprint i +1 ...

...

Review Retrospecitve

Daily meetings Daily meetings

Sprint Planning 2 Sprint Planning 1 Estimation Estimation

(54)

Scrum - Meetings

Scrum - Meetings

• Sprint Planning 1

– Material:

• Product backlog atualizado, priorizado e estimado. • Informações práticas sobre próximo sprint

• pessoas, tempo de sprint etc.

– Envolvidos: Product owner + time + scrum master – Objetivo: Definir sprint backlog

– Procedimento:

• sprint backlog é preenchido com os itens de maior prioridade do product backlog até completar o número de story points correspondente a velocity do time.

• O product owner poderá então propor alterações para incluir, excluir e alterar o escopo das stories.

(55)

Scrum - Meetings

Scrum - Meetings

Sprint Planning 2 – Material:

• Sprint backlog priorizado e detalhes do sprint (incluindo o objetivo).

• Informações práticas sobre próximo sprint (pessoas, tempo de sprint etc.).

– Envolvidos: Time + scrum master (+ product owner) – Objetivo: Definir tarefas de cada story do sprint. – Procedimento:

• Divisão das stories em tarefas de 1 dia, criando post-its para a coluna to do do VRSIVIEP:painel de tarefas.

• Lembrar que as tarefas devem incluir:

• Aprendizado de tecnologia desconhecida • Programação

• Teste

• Code review • Documentação

(56)

Scrum - Meetings

Scrum - Meetings

Planning Poker ou Estimation meeting – Envolvidos: time

– Material: cartas do planning poker com os valores: 1 2 3 5 8 13 20 40 100 200.

– Procedimento:

1. Identificar no product backlog o item que o time julga ser o de menor esforço e pontuamos como 2.

2. A partir do product backlog fazemos um "pre-selected" backlog com os itens mais urgentes na visão do prod. owner, ou seja, Luciano+Ismael.

Para cada item:

4. Lemos a story relativa ao item e verificamos se não há desentendimento. 5. Fazemos uma rodada de PP entre os membros do time.

6. Os membros que tiverem dado menor e maior valores fazem uma breve defesa do porque.

Repetimos itens 4 e 5 até convergir

8. O valor é associado ao item, você pode verificar naquele arquivo sprint1.txt que passei para você os valores atribuídos aos 9 itens do sprint1.

– Freqüência:

(57)

Scrum - Meetings

Scrum - Meetings

• Daily meetings ou Satand-up meetings ou Scrum meetings – Envolvidos: time.

– Material: Painel de tarefas; post-it; canetas. – Procedimento:

• De pé, máximo de 15 minutos, não é para discutir/resolver problemas • 3 perguntas atualizando o Task Board:

• o que eu fiz ontem? • o que farei hoje?

• tenho algum empecilho? • Sincronização de conhecimento • atualização do burn-down

(58)

Scrum - Meetings

Scrum - Meetings

O que eu fiz ontem?

1

O que vou fazer hoje?

2

Tenho algum obstáculo?

3

(59)

Scrum - Meetings

Scrum - Meetings

• Retrospective

– Material:

• informações do VRSIVIEP:painel de tarefas já organizados. • post-its e flip-chart

– Envolvidos:

• Time, scrum master (+ product owner)

– Objetivo:

• Rediscutir o processo de desenvolvimento (visando sua melhora)

– Procedimento:

• Repassar a sprint cronologicamente

• 5 min de WWWs (What Went Well & What Went Wrong) em post-it • Discutir os itens organizando o impediment backlog

– who is in control?.

• Fechamento: cada individuo faz sua conclusão

(Se a retrospective for anterior a review, pode-se preparar a review com o time.)

(60)

Scrum - Meetings

Scrum - Meetings

• Review

– Material:

• informações do painel de tarefas

– Envolvidos:

• time + scrum master + product owner

– Objetivo:

• Revisar último sprint e andamento global do projeto

– Procedimento:

• Revisar detalhes da última sprint: objetivo, stories, burndown chart etc. • Demo do último incremento do projeto.

• Pode incluir a demonstração de documentos e outros.

(Se a review for posterior a retrospective, pode-se discutir impediments)

– Freqüência:

(61)

Scrum

Scrum

Flow

(62)

Ainda sobre SCRUM

Ainda sobre SCRUM

• Sprint, um resumo

• Done, Velocity

• Infraestrutura

• Escalabilidade

• Aprendizado

• Exemplo Prático

(63)

Scrum - Sprint

Scrum - Sprint

• Sprint, um resumo

– Iteração de 2 a 4 semanas

– Termina com uma deployable version

– Não pode ter sua data postergada

• O que fazer se atrasar ?

– A descrição da sprint deve conter:

• Data início e fim

• Pessoas envolvidas (time) • Objetivo

• Total de pontos • Sprint backlog

(64)

Gráfico de Baleia

Gráfico de Baleia

Ao invés de completar uma coisa por vez...

... equipes Scrum fazem um pouco de cada coisa, todo o tempo.

(65)

Scrum - DONE

Scrum - DONE

Design

Codificação

Unit-test

Code review

Refactoring

Comentado

Commited

Documentado

(66)

Scrum - Velocity

Scrum - Velocity

• Velocity

(67)

Jogo das bolas

Jogo das bolas

• Um único time

• As bolas devem passar por todos

• Bolas devem ser passadas ficando um tempo no ar • Não podem ser passadas ao vizinho

• Mesmo ponto de início e fim • 2 minutos por sprint

• 1 minuto para retrospectiva/review • 5 iterações

(68)

Scrum – Suporte Tecnológico

Scrum – Suporte Tecnológico

• Teste Unitário

– J-Unit – Cpp-Unit – NUnit

• Integração Contínua

– Hudson – Scons

• Wiki (Visibilidade)

– Confluence

• Subversion

– TortoiseSVN

• Acompanhamento de issues

– Jira

(69)
(70)
(71)
(72)

Escalabilidade

Escalabilidade

• Times de 7

±

2 pessoas

• Pode ser escalável

• Scrum of Scrum

– Ken Schwaber

• Diversas vezes implementou para centenas de desenvolvedores

– Mike Cohn

• Implementou para mais de 1000

• Faz uso genérico do Scrum (além de des. de sw) • Próximo objetivo: + de 10.000 pessoas

(73)

Scrum of Scrum

(74)

Scrum of Scrum

(75)

Scrum - Relatórios

Scrum - Relatórios

• Product backlog a cada sprint

– Análise das diferenças

• Análise de desempenho

– Burn-down charts, velocity …

(76)

Scrum - Aprendizado

Scrum - Aprendizado

• Group programming

– Especialistas compartilham sua experiência

• Retrospective

– Todos aprendem sobre o processo e como

melhorá-lo

– Essa é a explicação de porque os métodos

ágeis se tornaram tão bons

(77)

Exemplo Prático - SiVIEP

Exemplo Prático - SiVIEP

• Sistema de Visualização Integrado de E&P • Alta complexidade de requisitos:

– Multi-plataforma – Realidade Virtual

• Renderização distribuída

• Interação com dispositivos 3D

– Suporte a grafo de cena – Som 3D

– Cluster – Distribuído

– Arquitetura de componentes – Plug-in

– Acesso as funcionalidades via script – Open source

– Plataforma de desenvolvimento para outras universidades – Browser 3D

(78)

• Um pouco mais de ano de projeto antes

do Scrum

• 5-6 pessoas

• ±10 sprints realizadas

Exemplo Prático - SiVIEP

(79)

Poços

Plataforma (PNA-I) Plataforma (PNA-II)

Reservatório

(80)
(81)

• Adaptações do Scrum no SiVIEP:

– 3 dias úteis de trabalho por semana

– Estimation meeting acontece em conjunto

com sprint planning 1

– Limbo + Prod. Backlog candidates

– mesa retrátil

– Post-it chart (cor diferente para post-it novo)

– Inversão entre retrospective e review

Exemplo Prático - SiVIEP

(82)

Meetings Sprint i Sprint i +1 ... ... Review Retrospecitve

Daily meetings Daily meetings

Sprint Planning 2 Sprint Planning 1 Estimation Estimation 1 day 1 day Meetings Sprint i Sprint i +1 ... ... Review Retrospecitve

Daily meetings Daily meetings

Sprint Planning 2 Sprint Planning 1 PROCESSO SIVIEP 1 day Estimation •Pontos positivos: •Participação do Prod. Owner em 1 único dia •Apenas 1 dia sem produção •Pontos negativos: - retrospective antes da review - Estimation na frente do prod. Owner PROCESSO CONVENCIONAL

(83)

Exemplo Prático – V3O2

Exemplo Prático – V3O2

• E&P

• Projeto antigo com diversos usuários

• ± 8 sprints realizadas

(84)

Tópicos para discussão

Tópicos para discussão

• Pontos negativos

• CMMI

(85)

Pontos negativos dos Métodos Ágeis

Pontos negativos dos Métodos Ágeis

• Para times com pessoas experientes

– Ken Schwaber diz que funciona para idiotas 

• Processo exigente, trabalha-se muito

– Google compensa com o esquema 80-20

• Perda de flexibilidade no horário

• Como tratar especialistas em equipes

multidisciplinares?

• Como fazer o contrato (preço e escopo)?

• Como auditar e certificar?

Atenção! Cuidado com os falsos mitos negativos:

– Só serve para grupos pequenos (FALSO) – Não gera documentação (FALSO)

(86)

Contratos

Contratos

• Fixed price / fixed date or

Latest date / maximum cost

• Já existem diversos modelos de contrato

prontos

(87)

Scrum & CMM

Scrum & CMM

• Level 2:

– Christ Vriens, “Certifying for CMM Level 2 and ISO9001 with XP@Scrum”, May 2002

• Ken Schwaber

– Primeira experiência ruim:

• Sistema web para um grande banco (CMM level3, há 3 anos), 1997

– Encontro com Mark Paulk, 2002

• Descobriu que o SCRUM já era CMM level 2 quase 3

• 2003, fez pequenos ajustes para tornar SCRUM em CMM level 3 • Jeff Sutherland

– Se tornou especialista em CMM (em conjunto com o Scrum) – Certificou algumas empresas em CMMI com Scrum

– J Sutherland et al., “Scrum and CMMI Level 5: The Magic Potion for Code Warriors”, 2008

(88)

Scrum and CMMI Level 5

Scrum and CMMI Level 5

Establish and maintain an organizational policy for planning and performing Agile Methods

Establish and maintain the plan for performing Agile Methods

Provide adequate resources for performing Agile Methods

Assign responsibility and authority for performing Agile Methods

Train the people performing Agile Methods

Place designated work products under appropriate level of configuration management

Identify and involve the relevant stakeholders as planned

Monitor and control Agile Methods against the plan and take appropriate corrective action

Objectively evaluate adherence to the Agile Methods and address noncompliance

Review the activities, status, and results of the Agile Methods with higher-level management and resolve issues

Establish and maintain the description of Agile Methods

Collect the results from using Agile Methods to support future use and improve the organization’s approach to Agile Methods

(89)

Falhas no CMMI

Falhas no CMMI

(corrigidas pelo Scrum)

(corrigidas pelo Scrum)

• Respeita processos mas ignora pessoas

• Não foca em problemas organizacionais

internos

• Associa erradamente qualidade de produto à

qualidade do processo. (O que é um produto de

sucesso?)

• Não é business-oriented

• Ignora infra-estrutura técnica e organizacional

• Foca em eficiência interna e ignora a

(90)

Métodos Ágeis aplicados no mundo

Métodos Ágeis aplicados no mundo

• Empreas

– Google, Yahoo, Microsoft, Electronic Arts, High Moon Studios, Lockheed Martin, Philips, Siemens, Nokia, Capital One, BBC, Intuit, Nielsen Media, First American Real Estate, BMC Software, Ipswitch, John Deere, Lexis Nexis, Sabre, Salesforce.com, Time

Warner, Turner Broadcasting, Oce….

• Como introduzir:

– Ken Schwaber: democraticamente (bottom-up) – Jeff Sutherland: institucionalmente (top-down)

– Mike Cohn: ambos os métodos são interessantes – Mark Striebeck at Google: “Ssh! We Are Adding a

(91)

Métodos Ágeis aplicados no mundo

Métodos Ágeis aplicados no mundo

• Cenário ideal para começar:

– Grupo pequeno (<10) – Projeto complexo

– Time interessado

– Product owner disponível

• Perfil ideal das empresas:

• Empresas que valorizam o bem-estar dos funcionários • Informais

• Respeitem as horas de trabalho dos funcionários • Pequenas ou grandes empresas (de software)

(92)

Métodos Ágeis aplicados na Petrobras

Métodos Ágeis aplicados na Petrobras

• Justamente por essas características, a Petrobras proporciona boas possibilidades de uso Ágil

• Hoje

– Existem algumas iniciativas

– Mais por parte das prestadoras de serviços

– Escolher projetos mais propícios (E&P, CENPES...) – Pouco desenvolvedores crachá verde

• Curto Prazo

– Nós podemos mudar o cenário (agora todos os 40 são ágeis) – Deve ser feito democraticamente (ou não?)

• Longo Prazo

– Metodologia Agil (além de OO, R/3 etc...) – Associar a CMMI ?

(93)

Futuro dos métodos ágeis

Futuro dos métodos ágeis

• É possível usar SCRUM para outros

desenvolvimentos que não sejam

software?

– Essa pergunta me ocorre desde o meu curso

de CSM

– Recentemente, no TMCE 2008:

“Agile PDM-implementation”, Jörg Feldhusen,

Frederik Bungert, Manuel Löwer

(94)

Referências

Referências

• Sobre o SCRUM (by Ken Schwaber)

Ken Schwaber e Mike Beedle • Sobre a prática do Scrum

Ken Schwaber • Implementação do Scrum em diversas empresas • Quase um romance Ken Schwaber • pretendo ler

(95)

Referências

Referências

• Da Internet

– Jeff-Sutherland-7-Ways-To-Fail-With-Scrum.pdf – “Agile Project Management”

• Sobre liderança ágil

– “Scrum from the trenches”

• Experiência de uso do Scrum em uma empresa na Suécia • Altamente recomendável para quem está implementando

(96)

Referências

Referências

• Outras:

– Nonaka e Takeuchi:

• “The New New Product Development Game”, 1986

• “The knowledge-creating company”, 1995, 8000 referências (+ 4000 para versão japonesa)

– Jeff Sutherland:

• “Scrum and CMMI Level 5: The Magic Potion for Code Warriors”, 2008

• “Agile development: lessons learned from the first scrum”, 2004

(97)

Agradecimentos

Agradecimentos

• Turma UP2*, AS-ES-2008.1

• Uanderson

• Marcio Mascarenhas

• Saulo (videos)

• Dani e Carol

• Tecgraf

Referências

Documentos relacionados

Cálcio , magnésio e potássio são absorvidos pelas células vegetais como cátions (Ca ~2.. com cerca de 2 em , foram exc i sados de plântulas pr eestabelecidas in vitro, em meio MS,

 Investigar se os professores de educação infantil utilizam a pesquisa como príncipio educativo, para compreender se esta auxilia na aprendizagem dos alunos... 5.2

a) Determine a diferença entre os pesos moleculares desses dois hidrocarbonetos. Possui três ramificações diferentes entre si, ligadas à cadeia principal.. d)

Error of the Estimate Predictors: (Constant), Precip., Fertilizante. Produção

Este cliente possui alta restrição de tancagem em dois de seus cinco tanques e, este aumento a partir do mês de Outubro, está dire- tamente associado a falhas sobre a

A partir dos resultados, é possível observar as alterações hemodinâmicas, humorais e neurais causadas pelos exercícios físicos, que se manifestam nos sinais vitais como

Em função dos benefícios do uso de um método formal e da necessidade do uso de assistentes inteligentes no processo de desenvolvimento de software, o objetivo deste trabalho foi

Total de prémios e modo de divisão: Troféu para os 3 primeiros classificados e rosetas para 25% dos participantes em cada prova. Georges Aberta a: Cavalos com idade mínima de 7 anos