Marcos Miguel

marcos.a.miguel@gmail.com

MBI (Master in Business Intelligence) UFJF Bacharel em Sistemas de Informação pelo CES/JF Diretor de desenvolvimento da Projetus Informática Professor do Centro de Ensino Superior de Valença

Agenda
O Introdução
O Conceitos
O Papéis O Envolvimento x Comprometimento O Cerimônias

O Artefatos

O Caso de uso O Conclusões O Dúvidas

O Referências

Mais uma metodologia?

Problemas no desenvolvimento de Softwares
O Caos pela mudança constante de requisitos O Estimativas de tempo, custo e qualidade do

produto totalmente irreais O Os desenvolvedores não sabem exatamente como está indo o andamento do projeto e acabam mentindo ou se enganando sobre seus próprios resultados

Perdendo no revezamento...
O O estilo de “corrida de revezamento” aplicado

ao desenvolvimento de produtos pode conflitar com os objetivos de velocidade e flexibilidade máximas. Ao invés disto, um estilo holístico, integrado, onde a equipe busca, como em um jogo de futebol, de forma integrada, chegar ao gol, com passes de bola, pode servir melhor às atuais necessidades competitivas.
Adequado de “The New New Product Development Game”, Hirotaka Takeuchi e Ikujiro Nonaka, Harvard Business Review, January 1986.

Origens do Scrum
O Jeff Sutherland O Uso inicial do scrum na Easel em 1993 O IDX e mais de 500 pessoas usando Scrum O Ken Schwaber O ADM O Apresentação na OOPSLA 96 com Sutherland O Três livros sobre Scrum O Mike Beedle O Padrões para o Scrum na PLOPD4 O Ken Schwaber and Mike Cohn O Fundaram a Scrum Alliance em 2002, O Inicialmente junto com a Agile Alliance

Quem usa o Scrum?
O Microsoft O Yahoo O Google O Electronic Arts O High Moon Studios O O O O O O O O BBC O First American Real

O Lockheed Martin
O Philips O Siemens O Nokia O Capital One

Estate Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Projetus Informática Globo.com

Scrum tem sido usado para
O Software comercial O Desenvolvimento O O O O O O Video games O Desenvolvimento interno O Sistemas para suporte à

contratado terceirização) O Projetos de preço fixo Aplicações Financeiras O Aplicações certificadas O pela Isso 9001 O Sistemas embarcados O Sistemas disponíveis O 24x7

vida Sistemas para controle de satélites Websites Software para handhelds Telefones celulares Aplicações para redes Algumas das maiores aplicações em produção

Características
O Equipes que se auto-organizam O O produto evolui em uma série de “Sprints” de 2 O

O
O O

a 4 semanas Os requerimentos são listados em um “ProductBacklog” Não há prática de engenharia prescrita (o Scrum adequa-se a todas) Usa regras generativas na criação de um ambiente ágil para a entrega de projetos É uma das “metodologias ágeis”

Conceitos
O Scrum é baseado nas melhores práticas

aceitas pelo mercado, utilizadas e provadas por décadas O É definido como uma teoria de processos empíricos O É um framework conceitual
O Jim Coplien certa vez observou: "Todos irão

gostar de Scrum; ele é o que já fazemos quando estamos pressionados contra a parede."

Conceitos
O Baseia-se em 3 Pilares:
O TRANSPARÊNCIA O aspectos do processo que afetam o resultado

devem ser visíveis para aqueles que gerenciam os resultados O quando alguém inspeciona um processo acredita que algo está pronto

O INSPEÇÃO O Os diversos aspectos do processo devem ser

inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas

Conceitos
O ADAPTAÇÃO O Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo
O Existem três pontos para inspeção e adaptação em Scrum:
O A Reunião Diária: inspecionar o progresso em direção à meta

da Sprint e realizar adaptações que otimizem o valor do próximo dia de trabalho O Revisão da Sprint e de Planejamento da Sprint:: inspecionar o progresso em direção à Meta da Release e para fazer as adaptações que otimizem o valor da próxima Sprint O Retrospectiva da Sprint: revisar a Sprint passada e definir que adaptações tornarão a próxima Sprint mais produtiva, recompensadora e gratificante

Resumo do processo
O O produto é definido: quais são os seus requisitos? O que realmente O

O

O

O

o cliente quer? O responsável por esta tarefa é o que chamamos de Proprietário do Produto (Product Owner) O Proprietário do Produto define quais são as funcionalidades do programa que mais importam, criando assim o que chamamos de Product Backlog Com as prioridades definidas, uma pessoa é definida para ser o ScrumMaster, uma espécie de coordenador do projeto. O ScrumMaster, junto com o Proprietário do Produto e o Time de desenvolvimento definem o que chamamos de Sprints. Cada Sprint possui uma parte de todo o Product Backlog, e devem ser trabalhados de acordo com as prioridades definidas no Product Backlog. Os Sprints devem ser preparados de uma forma de que durem de 2 a 4 semanas, e que no final de cada período tenham um produto apresentável para o cliente Os Sprints vão sendo feitos até o Product Backlog acabar e o PO definir que o projeto está pronto

Conteúdo
O Scrum emprega os eventos com duração fixa (time-boxes) para

criar regularidade O Entre os elementos do Scrum que têm duração fixa:
O O O O O O

Reunião de Planejamento da Release Reunião de Planejamento da Sprint Sprint Reunião Diária Revisão da Sprint Retrospectiva da Sprint

O O coração do Scrum é a Sprint, que é uma iteração de um mês ou

menos, de duração consistente com o esforço de desenvolvimento. O Todas as Sprints utilizam o mesmo modelo de Scrum e todas as Sprints têm como resultado um incremento do produto final que é potencialmente entregável.

Conteúdo
O Scrum utiliza quatro artefatos principais:
O Backlog do Produto: é uma lista priorizada

de tudo que pode ser necessário no produto O Backlog da Sprint: é uma lista de tarefas do produto potencialmente entregável O Burndown: é uma medida do backlog restante pelo tempo O Burndown de Release: mede o Backlog do Produto restante ao longo do tempo de um plano de release

Papeis
O PRODUCT OWNER (PO)
O Representa os interesses do cliente. O Ele tem que ser a interface entre o cliente e o O O O O O

O

time de desenvolvedores Definir as características e conteúdo do produto; Decidir sobre a data de término; Ser responsável pela rentabilidade do produto; Prorizar as funções de acordo com o valor de mercado e com o cliente; Ajustas recursos e priorizar tarefas a cada 30 dias, como necessário; Aceitar ou rejeitar o resultado do trabalho.

O PO pode ser um membro do Time, mas frequentemente leva a conflitos.

Papeis
O SCRUMMASTER O Líder da equipe de desenvolvimento e durante o trabalho, fica mais em contato com o PO. Ele gerencia e repassa o trabalho que foi decidido durante o planejamento pelo Proprietário do Produto. O Assegurar que a equipe de desenvolvimento funcione plenamente e seja produtiva; O Ajudar na cooperação entre todas as funções e papéis do time; O Proteger a equipe de interferências externas; O Assegurar-se de que a metodologia está sendo seguida, incluindo chamadas para reuniões diárias (Daily Scrum Meetings), revisões de atividade (Sprint Reviews) e reuniões de planejamento das atividades (Sprint Planning). O Ajuda o Time a entender e usar autogerenciamento interdisciplinaridade O Ajuda o Time a fazer o seu melhor em um ambiente O “Remove impedimentos“

O ScrumMaster pode ser um membro do Time, mas frequentemente leva a conflitos.

Papeis
O

SCRUMMASTER
O

Além de comandar as reuniões diárias, o ScrumMaster têm três principais responsabilidades:
Precisa saber quais atividade foram concluídas, quais foram iniciadas, quaisquer novas tarefas que foram descobertas e qualquer estimativa que possa ter mudado. Isto permite a ele atualizar sempre o Burndown Chart, que permite mostrar quanto trabalho falta para um Sprint acabar, dia por dia. Ele também tem que sempre olhar cuidadosamente para o número de tarefas em aberto. Estes trabalhos em aberto devem ser minimizados o máximo possível para garantir um trabalho sempre limpo e eficiente. O Deve avaliar as dependências superficiais e bloqueios que causam prejuízos ao andamento do Projeto. Estes itens devem receber prioridades e serem acompanhados. Um plano de solução deve ser implementado de acordo com a ordem de prioridade destes impedimentos. Alguns podem ser resolvidos pelo time, outros podem ser resolvidos através de vários times, e outros podem precisar de envolvimento da gerência, pois podem ser problemas relacionados à empresa que bloqueiam qualquer membro do time a fazer qualquer coisa. Como exemplo deste tipo de impedimento externo, temos as questões judiciais. O O ScrumMaster deve perceber e resolver problemas pessoais ou conflitos entre os integrantes do time de desenvolvimento SCRUM. Este tipo de problema deve ser clarificado pelo ScrumMaster e resolvido por diálogo com o time, ou então o ScrumMaster terá que ter ajuda da gerência ou do departamento de Recursos Humanos. Alguns estudos apontam que 50% dos problemas de desenvolvimento acontecem por razões pessoais. O ScrumMaster precisa estar sempre atento ao time para fazer dele totalmente funcional e produtivo.
O

Papeis
O TIME O Desenvolvedores com todas as habilidades necessárias
O

O O

O O

para transformar os requisitos do PO em um pedaço potencialmente entregável do produto ao final da Sprint Possui conhecimentos especializados, como programação, controle de qualidade, análise de negócios, arquitetura, projeto de interface de usuário ou projeto de banco de dados O conhecimento é compartilhado e todos contribuem Ninguém nem mesmo o ScrumMaster - diz ao time como transformar o Backlog do Produto em incrementos de funcionalidades entregáveis. O Time descobre por si só A sinergia que resulta disso melhora a eficiência e eficácia geral do Time como um todo Tamanho ideal de 5 a 9 membros

Envolvimento X Comprometimento

Envolvimento X Comprometimento

Envolvimento x Comprometimento
O Baseados nesta historinha, existem dois

tipos de pessoas em projetos Scrum: O Galinhas: Apenas envolvidas com o projeto
O Todos os demais

O Porcos: Totalmente comprometidos com o

projeto
O Time SCRUM (Time, SrumMaster, PO)

Cerimônias

Reunião de Planejamento do Sprint
PO desenvolve um plano para o projeto de software bem próximo ao cliente para definir todas as funcionalidades que o cliente quer no seu produto. A partir desta lista, ele também tem que definir as prioridades de cada funcionalidade de acordo com várias variáveis: valor de mercado, importância de base, importância para o cliente, entre outras. Esta lista final é o que chamamos de Product Backlog e é a base para a reunião de planejamento do Sprint. O Nesta reunião, o ScrumMaster trabalha junto com o PO e a Equipe de Desenvolvimento para definir qual a carga de tempo que cada funcionalidade do Product Backlog terá. Isto ajuda o PO a definir prazos reais para o projeto e o habilita a poder verificar como está o andamento do projeto durante todo o período de desenvolvimento. Esta carga de tempo e esforço é definida de acordo com o tamanho do(s) time(s), horas disponíveis e o nível de produtividade do time. O Quando as prioridades e prazos das funcionalidades do software são definidas por completo, o PO sai de cena e o ScrumMaster começa a trabalhar juntamente com a Equipe de Desenvolvimento para a quebra destas tarefas grandes em pequenas tarefas, divididas por todos os integrantes da equipe de desenvolvimento. Esta reunião de planejamento geralmente dura até 4 horas e é ela quem define o Sprint Backlog, um dos artefatos SCRUM. O Uma vez definido o Sprint Backlog, com a listagem de todas as tarefas, seus responsáveis e seus prazos, o processo de desenvolvimento começa.
O

Reunião Diária
O Tempo: Até 15 minutos O Cada membro da equipe deve responder à três

perguntas:
O

O que você fez desde a última reunião diária dentro deste projeto? O O que você fará entre agora e a próxima reunião diária dentro deste projeto? O O que te impede de fazer seu trabalho da maneira mais eficaz possível?

O Scrum Master é responsável por organizar O Galinhas não têm permissão de falar ficam na periferia O Porcos ou galinhas que não obedecerem as regras

acima podem ser convidadas a se retirar da reunião (galinhas) ou removidas da equipe (porcos)

Reunião de Revisão do Sprint
O No final do período do Sprint, a reunião de revisão do Sprint é feita. Nesta O O O

O O

O

reunião, a equipe de desenvolvimento, junto ao ScrumMaster, se reúne com o PO (e convidados, caso ele achar adequado, como por exemplo o cliente ou acionistas do projeto). Esta reunião dura aproximadamente 4 horas. Na primeira parte da reunião, o resultado do Sprint é apresentado para o PO. As funcionalidaes são revisadas PO define quais itens do Product Backlog foram completados no Sprint, discutindo então com os membros da equipe e o cliente quais serão as novas prioridades. Primeiro passo para criar um novo Sprint, caso seja necessário, pois dessa primeira parte da reunião, um novo Product Backlog é gerado. Na segunda parte da reunião, o ScrumMaster se reunie com a equipe de desenvolvimento e revisa os altos e baixos do ciclo. O time conversa para saber o que foi bom e como se pode melhorar ainda mais o ambiente, as ferramentas e o convívio entre o time e suas funções. Esta parte é basicamente um aprimoramento interno. Depois que esta reunião é finalizada, um novo ciclo Sprint pode começar

Product Backlog
Funcionalidade Modelagem de dados Cadastro e gerenciamento de usuários Prioridade 1 2

Conversão de vídeo para visualização na Internet (Codec)

3

Cadastro e gerenciamento de vídeos pelos usuários Layout (Aparência) da página Comentários para os vídeos e usuários Notas para vídeos (ranking) Proteção contra SPAM Canais (grupos) de vídeos e usuários Sistema de legendagem de vídeos

4 5 6 7 8 9 10

Reconhecimento de sons dos vídeos

11

Reunião de Planejamento do Sprint
uncionalidade Modelagem de dados Prioridade 1 Custo-horas 32 Cadastro e gerenciamento de usuários 2 26 Conversão de vídeo para visualização na Internet (Codec) 3 80

Cadastro e gerenciamento de vídeos pelos usuários

4

48

Layout (Aparência) da página

5

28

Comentários para os vídeos e usuários

6

20

Notas para vídeos (ranking) Proteção contra SPAM Canais (grupos) de vídeos e usuários

7 8 9

16 20 26

Sistema de legendagem de vídeos

10

64

Reconhecimento de sons dos vídeos

11

92

Meta do primeiro Sprint
Funcionalidade Modelagem de dados Definição de dados Organização de tabelas Relacionamento Implementação em SGBD Cadastro e gerenciamento de usuário Formulários Prioridade 1 1.1 1.2 1.3 1.4 2 2.1 2.2 2.3 2.4 2.5 Custo-horas 32 8 12 8 4 26 6 6 6 4 4

Interação com cadastro na base de dados
Visualização de perfil Mudança de dados Relacionamento entre usuários

Sprint Backlog

Burndown Chart

Ferramentas
O VersionOne
O http://www.versionone.com/

O Pronto
O http://pronto.bluesoft.com.br/

O FireScrum
O http://www.firescrum.com/

Scrum Board

Scrum Board

Caso de Uso

Ferramenta VersionOne

Tempo de desenvolvimento por Sprint
(Rendimento da equipe) Tempo

200 150 100 50 0 1 Sprint 2 Sprint 3 Sprint Tempo 5 Sprint 6 Sprint Tempo

4 Sprint

Índice de problemas resolvidos

Gráfico Mantis Ferramenta de Controle de Bugs

Conclusões
O O Scrum é um metodologia de

desenvolvimento que tem despontado e trago resultados satisfatórios para muitas equipes

O “Não basta ser

uma equipe, é preciso ser um time”

DUVIDAS?

Referencias
O ScrumGuide: Guia oficial do Scrum em

http://www.scrum.org/scrumguides
O Implements Scrum: Mais informações

http://www.implementingscrum.com

Outros links:
www.mountaingoatsoftware.com/scrum www.scrumalliance.org

Contato
O marcos@projetusinformatica.com.br O marcos.a.miguel@gmail.com

Sign up to vote on this title
UsefulNot useful