quarta-feira, 29 de março de 2017

Scrum como funciona ? Engenharia de software

scrum e pepinos

Segundo a Wikipedia o Scrum surgiu conforme a história abaixo

Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo "The New Product Development Game" (Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland[3], John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum, conforme descrito abaixo, na empresa Easel Corporation em 1993, incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo no desenvolvimento de softwares em todo o mundo.

Fonte: https://pt.wikipedia.org/wiki/Scrum_%28desenvolvimento_de_software%29

Jeff Sutherland e Ken Schwaber também ajudaram a criar o manifesto ágil, que nada mais é que declaração de princípios para o desenvolvimento ágil de software.

Os 4 valores do manifesto são os seguintes:
  • Os indivíduos e suas interações acima de procedimentos e ferramentas;
  • O funcionamento do software acima de documentação abrangente;
  • A colaboração dos clientes acima da negociação de contratos;
  • A capacidade de resposta a mudanças acima de um plano pré-estabelecido;

Os 12 princípios contidos no manifesto são os seguintes:
  • Garantir a satisfação do cliente, entregando rápida e continuamente software funcionais;
  • Software funcionais são entregues frequentemente (semanal, ao invés de mensal);
  • Software funcionais são a principal medida de progresso do projeto;
  • Até mesmo mudanças tardias de escopo no projeto são bem-vindas.
  • Cooperação constante entre as pessoas que entendem do 'negócio' e os desenvolvedores;
  • Projetos surgem por meio de indivíduos motivados, devendo existir uma relação de confiança.
  • Design do software deve prezar pela excelência técnica;
  • Simplicidade;
  • Rápida adaptação às mudanças;
  • Indivíduos e interações mais do que processos e ferramentas;
  • Software funcional mais do que documentação extensa;
  • Colaboração com clientes mais do que negociação de contratos;
  • Responder a mudanças mais do que seguir um plano.

 Fonte: https://pt.wikipedia.org/wiki/Manifesto_%C3%81gil


Artigos relacionados :

 

1. O desafio.




Para explicar o funcionamento do Scrum, além de explicar cada item, vamos utilizar um estudo de caso simplificado. Veja abaixo a contextualização do problema.

A empresa Pepino S.A está diversificando seus canais de venda e relacionamento com o cliente e fornecedores.

Apesar dela já possuir uma loja virtual, o conselho executivo da empresa chegou a conclusão que é extremamente importante a criação de um aplicativo para seus clientes monitorarem os pepinos desde o plantio até a entrega em domicílio.

O SEO da empresa estabeleceu o prazo de 4 meses para o software estar disponível na Applestore e Google play para download, pois no final deste período haverá uma festa de comemoração dos 10 anos de funcionamento da empresa, momento este que também será entregue o prêmio de empresa mais sustentável do ano. Para piorar a situação este prêmio será transmitido ao vivo pela rede Globo.

Como podemos ver equipe de tecnologia da informação e de marketing da empresa estão com um pepino na mão, e as incertezas são grandes assim como na maioria dos projetos desafiadores.

2. Como escolher o Product Owner ?

Product Owner


Para que se possa tirar o melhor aproveitamento da metodologia e garantir o bom andamento do projeto será extremamente importante escolher o Product Owner.

Quem é este tal de Product Owner ?

Primeiramente temos que entender que no Scrum existem alguns papéis que são bem definidos, um deles é o de Product Owner, ou seja, é alguém que apesar de poder ou não assumir outras responsabilidades na organização será o responsável por alimentar a equipe com requisitos e demandas, além de também ser o responsável por priorizar tais demandas. Um P.O. é praticamente um membro da equipe pois espera-se que o trabalho da equipe seja feito juntamente com ele, e que ele possa sanar todas as dúvidas relacionadas ao negócio garantindo assim o bom andamento do projeto.

Vejamos como foi a escolha do Product Owner.


João, o responsável pela área de T.I. ao ter ciência do projeto mobile, já sabia que o prazo era curto e que a equipe que ele tinha disponível para a execução do projeto era pequena.

Apesar de não conhecer tão bem o funcionamento da metodologia Scrum, ele decidiu ir por este caminho, pois ao avaliar os riscos do projeto já tinha em mente 3 benefícios:

  1. A equipe de projetos Scrum geralmente é uma equipe com poucos integrantes.
  2. Ganha-se tempo eliminando processos e documentações desnecessárias.
  3. Com o passar do tempo a equipe de projeto tende a melhorar muito pois o processo é iterativo, incremental e preconiza a melhoria contínua.
Com isto em mente a primeira etapa foi quando ele juntamente com o corpo executivo da Pepino S.A escolheram o gerente do setor de logística(Jeremias) como Product Owner.

O P.O. escolhido é um funcionário com mais de 20 anos de carreira que começou na empresa como entregador de Pepinos e trabalhou em diversas áreas da empresa antes de ocupar um cargo de chefia, ou seja, um pessoa que conhece muito o core business da companhia.

 

3. Como escolher o Scrum Master ?

scrum master


Outro papel que é tão importante quanto o de Product Owner é de Scrum Master.

Mas afinal quem é esse cara ?

O Scrum Master é o guardião da metodologia Scrum, o mais importante agente de mudanças da equipe e também trabalha como um orientador.

Podemos comparar este papel a de um técnico de time de futebol. Um técnico de time de futebol é responsável por fazer o planejamento tático, orientar o preparo físico dos atletas e definir as regras do jogo, mas na hora em que o bola rola quem entra em campo para ganhar é o time que foi orientado e treinado pelo técnico.

O Scrum é mais ou menos igual ao futebol. O Scrum Master é o cara que tem facilidade em lidar e orientar pessoas, se comunica bem, tem bom tramite organizacional, é um ótimo mediador de conflitos e ainda arbitra a metodologia. Claro que na hora de jogar quem entra em campo é o time Scrum assim como no futebol

Não se pode comparar um Scrum Master a um gerente de projetos tradicional, pois usando esta metologia sabe-se que uma equipe Scrum é auto-organizada e por isso, muitas funções que tradicionalmente ficavam a par do gerente de projetos serão de inteira responsabilidade da equipe Scrum.

Vejamos como foi a escolha do Scrum Master na Pepino S.A.


De forma sábia, João, o responsável pela Área de T.I da Pepino S.A.escolheu a si mesmo para o papel de Scrum Master e um líder técnico da área de TI, José. Mas porquê duas pessoas ?

Além de possuir as habilidades interpessoais necessárias, João tem um ótimo relacionamento com a alta direção, o que facilita muito a eliminação de impedimentos durante o projeto.

A escolha de José servirá para repassar o conhecimento, visto que se o projeto for bem sucedido o novo modelo de gestão de projetos será replicado em toda a Pepino S.A. Outro ponto que também pesou nesta decisão é que o conhecimento de José será complementar ao de João que possui mais conhecimento em gestão do que na parte técnica.


4. Como escolher a equipe Scrum ?

equipe scrum


Equipes Scrum são bem diferentes das equipes que estamos acostumados a ver em projetos que seguem metodologias tradicionais. Abaixo estão listadas as principais características de uma equipe Scrum:
  • As equipes Scrum são auto-organizadas, ou seja, a própria equipe determina a forma como o trabalho será feito para garantir o sucesso da entrega, poder de decisão.
  • As equipes são multidisciplinares, ou seja, os membros da equipe possuem as competências necessárias para realizar a incremento do software.
  • Nada impede que uma pessoa desvirtue os princípios do Scrum, mas adotando-se a regra as equipes devem ter entre 5 e 9 integrantes. Equipes grandes demandam um esforço maior de gestão, por isso que os times scrum devem ser menores.
  • O comprometimento da equipe é bem visível devido a dinâmica da metodologia.

Vejamos como foi a escolha dos integrantes da equipe.

João e José, os novos Scrum Masters do projeto, escolheram a Jorge que já trabalhou em vários projetos utilizando a tecnologia java, escolheram Joana que trabalha com testes e design de interfaces, escolheram Joel que trabalha com infraestrutura e gestão de configuração e escolheram Janaína que é uma ótima DBA.

João e José pensaram em pessoas que agregam diversos tipos de conhecimento a equipe, e que o conhecimento de cada um se complementam de alguma forma, visando o sucesso do projeto.

Neste time podemos ver que existem vários especialistas. O interessante nesta metodologia é que qualquer membro de uma equipe multidisciplinar é capaz de realizar qualquer tarefa, não somente a que ele é especialista. Isto é muito bom por propiciar a disseminação do conhecimento.

5. Como definir o Product Backlog ?

Definição do product backlog


Tendo os papéis bem definidos o primeiro passo para se iniciar um projeto scrum é fazer uma definição inicial do Product Backlog.

Basicamente o Product Backlog é uma lista com todas as funcionalidades desejadas para um produto, que no caso da Pepino S.A. é um app mobile. Analogamente a metodologias tradicionais de software podemos comparar o Product Backlog a uma lista de requisitos de um software.

É importante destacar que no início do projeto o Product Bakclog nada mais é que uma lista inicial de requisitos que ainda não está totalmente fechada, pois a medida em que o projeto caminha, esta lista pode crescer ou diminuir conforme necessidades do projeto.

Vejamos como foi a definição do Product Backlog na Pepino S.A.

João e José os novos Scrum masters da Pepino S.A., após terem escolhido e comunicado os membros da primeira equipe ágil da Pepino S.A. se reuniram com o P.O. Jeremias para definirem a primeira versão do Product Backlog.

Após 3 horas de reunião e discussão chegou-se a seguinte lista:
  • Funcionalidade de auto cadastramento de usuários.
  • Funcionalidade de notificação de eventos para os clientes cadastrados.
  • Funcionalidade de baixa para o recebimento de sementes, fertilizantes e outros insumos de fornecedores.
  • Funcionalidade de indicação e apontamento no google maps onde um determinado lote de sementes foi plantado.
  • Funcionalidade para cruzar e exibir a informação de quais identificadores de pacote correspondentes a qual lote de sementes e em qual galpão da Pepino S.A se encontra o pacote.
  • Funcionalidade para mostrar onde um determinado pacote foi entregue e também a indicação deste local no google maps.
Inicialmente eles definiram as funcionalidades básicas com relação ao tempo que tinham para o dia da apresentação.

6. O que é Sprint ?



Para entender o que é um Sprint, primeiramente é necessário relembrarmos o que é o modelo de desenvolvimento de software cascata e como ele evoluiu para o interativo e incremental.

No modelo cascata cada etapa do desenvolvimento de software era feito somente após o completo término da etapa anterior, ou seja, as etapas são sequenciais neste modelo.

Para exemplificar o cascata suponhamos que um determinado software possua 10 módulos. De acordo com este modelo na fase de desenvolvimento os 10 módulos serão desenvolvidos por inteiro, ou seja, o desenvolvimento somente começa após o término da etapa de especificação dos 10 módulos.

Já o modelo iterativo e incremental, surgiu devido aos problemas constatados no cascata e ele propõe que as etapas do desenvolvimento de software sejam realizadas em paralelo e ao final de cada iteração um incremento de software é entregue. Neste modelo especificação, desenvolvimento, testes e implantação poderão ocorrer simultaneamente.

A definição do Sprint encaixa-se com o modelo iterativo e incremental, pois ele define um ciclo regular de trabalho, ou seja, um período de tempo predeterminado para execução de tarefas definidas pelo time Scrum. Este ciclo regular pode ser usado para projetos de qualquer espécie, mas falando-se em desenvolvimento de software, este ciclo é igual ao que propões o modelo iterativo e incremental.


7. A definição do Sprint Backlog através da Planning Meeting com o uso da Planning Poker.

Sprint backlog Planning meeting planning poker


Antes do trabalho começar, é necessário fazer o planejamento do que será feito durante a Sprint. Para isto a metodologia define um rito chamado Planning Meeting, que nada mais é do que uma reunião que ocorre antes do início da execução da Sprint, que serve para a equipe juntamente com o Product owner fazer o planejamento e priorização do trabalho que será desenvolvido durante a Sprint.

O Sprint backlog é formado por tarefas relacionadas a itens extraídos do Product backlog, itens que são priorizados pelo Product Owner. Durante a reunião a equipe deve fazer questionamentos suficientes ao P.O. para que se possa haver um comprometimento da entrega dos itens priorizados até o final da Sprint. O sucesso ou fracasso da equipe durante a Sprint será avaliado em um outro rito, chamado Review Meeting, que irá acontecer ao final da Sprint.

O time é quem vai estimar o que poderá ser entregue na Sprint, caso haja mais itens do que a capacidade produtiva do time, alguns itens podem ficar para a próxima Sprint.

Basicamente a Planning Meting é dividida em duas etapas: A primeira é relativa ao entendimento das demandas e a segunda é relativa ao tempo que será gasto e como será realizado o trabalho.

Para estimar o tempo gasto para cada item do Sprint backlog o time usa um artifício chamado Planning Poker que nada mais é do que um jogo de cartas onde cada membro da equipe possui um baralho com as seguintes cartas: 0, 1/2, 1, 2, 3, 5, 8,  13, 20, 40, 100 , interrogação e cafezinho.

Em cada rodada do jogo um item do Sprint backlog é apresentado para votação, em seguida cada membro da equipe escolhe e apresenta uma carta para os demais membros. Divergências frequentemente ocorrem, mas para resolver os jogadores fazem uma discussão até que se chegue a um consenso. A carta de interrogação serve para dizer aos demais jogadores que a pessoa não está apta a votar e o cafezinho sugere uma pausa para discutir melhor a situação.

As cartas da Planning Poker são numeradas de acordo com a série de Fibonacci. O interessante do jogo é que mesmo sendo quase impossível fazer estimativas exatas, estas tendem a se contrabalancear. Em um determinado momento quando uma estimativa possuir valor mais baixo e outra valor mais alto, uma média geral será mantida mesmo havendo pequenos erros de dimensionamento das tarefas.

Para não perderem tempo, logo após a definição inicial do Product Backlog João e José que já se encontravam em uma sala de reuniões com Jeremias, chamaram os integrantes do time para iniciarem a primeira Planning Meeting.

--- Parte 1

A primeira parte da reunião serviu para priorizar os itens do Product Backlog e para esclarecer algumas dúvidas conforme parte do diálogo abaixo:

João(S.M.): Jeremias escolha 3 itens desta lista que você gostaria de ver na primeira versão do aplicativo.
Jeremias(P.O.): Neste primeiro momento seria importante termos o cadastro dos usuários para que eles possam dar baixa na entrega e recebimento dos lotes de sementes que chegarem ao nosso depósito e para que os nossos clientes tenham um perspectiva de quanto tempo os nossos pepinos irão demorar até chegar nos distribuidores.
José(S.M.): Resumindo, seriam as funcionalidades de cadastro de usuários, baixa do fornecedor na entrega do lote de sementes, baixa do nosso setor de compras para o recebimento das sementes e notificação dos clientes para que eles saiba quem após o recebimento do lote de sementes em 90 dias os pepinos irão se encontrar em um distribuidor. Pela minhas contas são 4 funcionalidades.
Jeremias(S.M.): A baixa já é feita pelos nossos fornecedores e pela nossa equipe de compras no ERP da Pepino S.A, seria na verdade uma forma de exibir estes dados no app.
João(S.M.): Time agora que já sabemos quais as funcionalidades, o que vocês precisam saber para começarmos?
Jorge(S.T.): Quem são os tipos de usuários do sistema ?
Jeremias(P.O.): Temos 3 tipos de usuários: o primeiro são os nossos clientes que são pessoas físicas que gostariam de acompanhar nosso processo, o segundo tipo são os nossos fornecedores que são pessoas jurídicas e o terceiro tipo somos nós os funcionários da Pepino S.A.
Janaína(S.T.): Podemos definir o e-mail para ser o login do usuário ?

Etc...

--- Parte 2

Nesta segunda parte da reunião o P.O. não está mais presente e o time está reunido somente com os Scrum Master's.

José(S.M): Time agora que já tiramos as dúvidas com o nosso P.O. vamos começar a definir as tarefas da Sprint. Devemos começar pela funcionalidade de cadastro e login de usuários. Alguma sugestão de tarefas ?
Janaína(S.T.): Com certeza iremos necessitar criar um banco de dados novo, criar o DER e os scripts SQL de banco.
Joana(S.T.): Também será necessário criar a tela de login e a de manutenção de usuários.
Joel(S.T.): Será necessário configurar o projeto na nossa ferramenta de integração contínua para que seja feita a disponibilização da aplicação no ambiente de teste e homologação.
etc...
João(S.M.): Time agora que já definimos as tarefas da Sprint vamos começar com as estimativas. Iremos começar pela tarefa de criar o Banco de Dados, peguem suas cartas pensem na estimativa e exibam todos juntos no já.
João(S.M.): Já.
Jorge, Joel, Janaína e Joana exibiram o valor 3.
João(S.M.): Já que tivemos uma unanimidade vamos para o próximo item, o de criar os scripts SQL de banco.
João(S.M.): Já.
Jorge e Joana exibiram 5 e Joel e Janaína exibiram o valor 13.
João(S.M.): Jorge e ou Joana expliquem para o time o porque do valor 5.
Jorge(S.T.): Como o DER já estará pronto então fica mais fácil, pois as definições arquiteturais já estarão prontas.
Joana(S.T.): A nossa ferramente gera scripts a partir de um modelo DER por isso pensei em 5.
João(S.M.): Joel e ou Janaína expliquem o porque do valor 13
Joel(S.T.): Será necessária a criação de índices, stored procedures, triggers e cursores para o correto funcionamento desta nova aplicação visto que alguns dados virão do nosso ERP. Mas não tinha levado em consideração a criação automática de alguns Scripts.
Janaína(S.T.): Pensei o mesmo que o Joel.
João(S.M.): Agora que já discutimos todos peguem suas para a nova votação do item de criar os scripts SQL de banco.
João(S.M.): Já.
Jorge, Joel, Janaína e Joana exibiram o valor 8.
João(S.M.): Vamos para o próximo item.

Etc...

8. Execução da Sprint com reuniões diárias(Daily) usando o Kanban e o Chart Burndown ?

Daily meeting


O Scrum também define um rito chamado Daily Meeting que nada mais é do que uma reunião diária rápida(no máximo 15 minutos), realizada todos os dias no mesmo local e horário, onde todos os membros do time devem permanecer em pé e também devem responder a 3 perguntas:
  • O que você fez ontem ?
  • O que você fará hoje ?
  • Há algo que está te impedindo ?
Existem vários pontos positivos ao se adotar a Daily Meeting, como:
  • Promove e melhora a comunicação entre os membros da equipe.
  • Possibilita a disseminação do conhecimento.
  • Mitiga os riscos e corrige os rumos do projeto de forma mais rápida e proativa.
  • Por ser uma reunião rápida não demanda tanta energia do time.
  • Reforça o senso de responsabilidade do time sobre o projeto.
Além da Daily Meeting uma das ferramentas gerenciais que utilizada em projetos Scrum é o quadro Kanban.

O Kanban é uma ferramenta gerencial visual, que apesar de ser usada nos projetos Scrum não necessariamente possui vínculo com a metodologia. O Kanban é um quadro de tarefas dividido em 3 raias(To Do, In Progress, In Test, Done) onde as tarefas definidas no Sprint backlog são representadas por post-its e anexadas em cada raia do quadro de acordo com a situação em que se encontram.

O Kanban assim como outras ferramentas visuais garante a transparência do projeto e também promovem sua inspeção. Ele não teve sua origem no Scrum mais foi adotado pela metodologia devido a sua versatilidade e praticidade em realizar o acompanhamento e o andamento das tarefas.

Outra ferramenta gerencial visual que também é muito utilizada no Scrum e que caminha junto com o Kanban é o Chart Burndown. Esta ferramenta é basicamente uma representação gráfica do progresso do time em relação a execução das tarefas da Sprint. Este gráfico pode ser montado de duas formas diferentes, no eixo Y ou eixo vertical pode-se representar os pontos da Sprint ou horas e no eixo X ou eixo horizontal é representado os dias da Sprint.

Neste gráfico é traçado um linha indicando como deveria ser ser a execução ideal das tarefas e outra para indicar como realmente está sendo a execução das tarefas, ou seja, planejado vs. executado. Os pontos positivos deste gráfico é que ele, de certa forma, revela ao time como está o andamento do projeto, quais os pontos fortes e quais os pontos fracos do time além de também mostrar os desvios do projeto e indicar o que pode ser melhorado para garantir o sucesso da Sprint.

Vamos ver como foram algumas Daily's Meeting na Pepino S.A.

--- Sprint 1 - Daily 1

José (S.M.): Time todos de pé para fazermos a nossa primeira Daily.
José (S.M.): Jorge vamos começar por você. Primeiro responda o que você fará hoje ?
Jorge(S.T.): Hoje vou criar a estrutura do projeto e definir a arquitetura da aplicação.
José(S.M.): Têm algo que está te impedindo ?
Jorge(S.T.): Não.
José(S.M.): Ótimo. Joel o que você fará hoje ?
Joel(S.T.): Vou negociar com o pessoal do suporte a liberação de servidores para testes, desenvolvimento e homologação.
José(S.M.): Têm algo que está te impedindo ?
Joel(S.T.): Não.
José(S.M.): Joana o que você fará hoje ?
Joana(S.T.): Vou elaborar um protótipo básico e começar a elaborar alguns casos de testes.
José(S.M.): Têm algo que está te impedindo ?
Joana(S.T.): Não
José(S.M.): Janaína o que você fará hoje ?
Janaína(S.T.): Vou criar os bancos de dados e começar a elaborar o DER.
José(S.M.): Têm algo que está te impedindo ?
Janaína(S.T.): Não
José(S.M.): Beleza time. Agora que estamos alinhados mãos a obra.

--- Sprint 1 - Daily 2

José(S.M.): Todos de pé por favor pois vamos começar a Daily.
José(S.M.): Você primeiro Jorge. O que você fez ontem ?
Jorge(S.T.): Consegui criar a estrutura básica do projeto e também fiz a definição de como será a arquitetura do sistema.
José(S.M.): Jorge o que você fará hoje ?
Jorge(S.T.): Pretendo deixar a aplicação configurada para acessar o banco de dados e deixá-la pronta para consumir o webservice do nosso ERP.
José(S.M.): Têm algo que está te impedindo ?
Jorge(S.T.): Ainda não tenho as URL's de conexão das bases de testes, homologação e desenvolvimento.
José(S.M.): Janaína os ambientes de banco já estão prontos ?
Janaína(S.T.): Sim, foram criados ontem.
José(S.T.): Janaína, depois da Daily ajude o Jorge com a configuração das URL's de banco.
Janaína(S.T.): Ok.
José(S.T.): Continuando, Janaína nos conte o que você fez ontem.
Janaína(S.T.): Ontem consegui criar e configurar as bases para homologação, desenvolvimento e testes.
José(S.M.): Janaína o que você fará hoje ?
Janaína(S.T.): Vou começar o DER e pretendo finalizá-lo até o fim do dia.
José(S.M.): Tome cuidado para não atrasar muito com suas tarefas. Têm algo que está te impedindo ?
Janaína(S.T.): Não.
José(S.M.): Ok. Joel o que você fez ontem ?
Joel(S.T.): Deixei todos os ambientes prontos assim como o Hudson preparado para fazer o deploy da aplicação nestes ambientes.
José(S.M.): O que você fará hoje ?
Joel(S.T.): Pretendo fazer testes de deploy da aplicação nestes ambientes e realizar algumas configurações para acessos ao banco ?
José(S.M.): Têm algo que está te impedindo ?
Joel(S.T.): Ficou faltando as URL's de conexão das bases de testes e homologação e um primeiro commit da aplicação no nosso SVN.
José(S.M.): Janaína depois de ajudar o Jorge sente-se também com o Joel para ajudá-lo com as configurações de banco. Jorge depois de resolver com a Janaína sente-se faça um primeiro Commit da aplicação no Path do SVN que o Joel irá lhe passar depois da Daily.
José(S.M.): E para finalizar, Joana o que você fez ontem ?
Joana(S.T.): Elaborei uma primeira versão do protótipo e comecei a fazer os casos de testes.
José(S.M.): O que você fará hoje ?
Joana(S.T.): Vou continuar os casos de testes.
José(S.M.): Têm algo que está te impedindo ?
Joana(S.T.): Acredito que para os casos de testes ficarem o mais corretos possível e para poder iniciar o desenvolvimento das interfaces gráficas será necessário fazer uma validação do protótipo com o nosso P.O.
José(S.M.): Ok Joana. Deixa comigo que acabando a Daily irei me encontrar com o P.O para fazer isto.
José(S.M.): Beleza time. Mãos a obra.

--- Sprint 1 - Daily 3

Etc...

9. Como apresentar a demo do produto para o Product Owner durante a Review Meeting ao final da Sprint ?

review meeting


Outro rito do Scrum é a Review Meeting que é uma reunião onde os itens do Sprint Backlog serão apresentados para o Product Owner. Geralmente a apresentação é realizada com uma versão demo do software para o P.O, mas pode ser que entrega ainda não seja da demo mas de algum outro artefato.

A importância de se fazer a Review Meeting é que o time se empenha em finalizar o trabalho, pois o que muito se vê em muitos projetos é o jargão: "está quase pronto". Ir para a Review e não estar com o que foi prometido pronto, irá gerar um grande desconforto para a equipe e para o P.O e por isso um dos pontos positivos deste rito é reafirmar o compromisso da equipe com o bom andamento do projeto.

Este rito também acaba gerando insumos para a Retrospective pois muitas vezes algo que a equipe achou que estava sendo feito corretamente acaba não atendendo as necessidades do P.O. e também não atendendo a meta da Sprint.

Um aspecto importante ao se adotar o Scrum é que apesar da Review ser uma reunião com P.O., o contato com ele deve ser constante, mesmo durante a execução da Sprint. Este contato é importante pois espera-se que caso algum problema venha a ocorrer durante a Sprint, ele seja solucionado antes da Review. A expectativa de todos na Review é a aprovação dos itens trabalhado, mas se algo inesperado e não resolvido ocorreu eventualmente algum item poderá ser reprovado.

Vejamos como foi a primeira Demo do projeto.

João(S.M.): Jeremias hoje vamos lhe apresentar a primeira versão do sistema. Nesta versão foram desenvolvidas as funcionalidades de:
  • Cadastro de usuários do tipo fornecedores, clientes e funcionários da Pepino S.A.
  • Funcionalidade de login no sistema.
  • Integração entre o app e o nosso ERP para exibição das baixas de entrega e recebimento de mercadorias e exibição da estimativa de entrega de pepinos nos distribuidores.
João(S.M.): Jeremias utilize este notebook para navegar e realizar os testes.
Jeremias(P.O.): Ok.

Algum tempo depois.

João(S.M.): E então Jeremias o que achou ? e quais as suas ponderações ?
Jeremias(S.M.): No geral está funcionando corretamente. Algo que deve ser mudado é a cor dos componentes, pois espera-se que a aplicativo esteja no padrão da logo da Pepino S.A. Outro ponto muito importante é que a exibição das baixas não está ordenada por data e sim por tipo. A ordem cronológica dos fatos é muito importante.
João(S.M.): Iremos realizar estas mudanças e para a próxima Review Meeting.
Jeremias(S.M.): Todos estão de parabéns e fico aguardando as mudanças.

10. Qual a diferença entre a Retrospective e as lições aprendidas do PMBOK ?

Retrospective meeting


O último rito do Scrum é a Retrospective, que é uma reunião, também ao final da Sprint, onde o time irá discutir o que deu certo e que deu errado durante a execução das tarefas, além de traçar novas estratégias para garantir o sucesso da próxima Sprint.

Em um primeiro momento pode haver uma dificuldade em externalizar os pontos negativos, pois muitas vezes o andamento do projeto pode ser impactado por questões hierárquicas, organizacionais ou relacionadas a outras pessoas. É importante que o Scrum Master garanta um ambiente favorável a discussão, pois o objetivo da Retrospective não é encontrar culpados mas sim garantir a melhoria contínua.

O PMBOK nos diz que o registro das lições aprendidas deverá ocorrer ao final do projeto ou ao final de cada fase do projeto. A dinâmica do gerenciamento de projetos baseado no PMBOK não estabelece uma forma para que tais lições sejam usadas na melhoria contínua e também pode acontecer de muitas lições se perderem caso o período do projeto for grande ou de simplesmente não serem usadas para o próximo projeto.

A Retrospective além de ser uma reunião, também acaba funcionando com registro das lições aprendidas, mas diferentemente do que define o PMBOK, no Scrum ao final de cada Sprint as lições aprendidas serão registradas e já serão traçadas estratégias para a execução da próxima Sprint. A responsabilidade das lições aprendidas não será de uma única pessoa(no caso do PMBOK o gerente de projetos), mas sim da equipe.

A Retrospective corresponde a fase Ckeck do ciclo PDCA(Plan, Do, Check, Act).

Uma boa forma de conduzir uma Restrospective é criar uma quadro dividido em três raias onde a primeira raia é a de pontos positivos, a segunda de pontos negativos e a terceira de ações. Cada membro da equipe recebe alguns post-its para escrever achou que foi bom e ruim durante a Sprint. Após as anotações terem sido realizadas o Scrum Master anexa os post-its nas raias de bom e de ruim e começa a discussão do que melhorar para a próxima Sprint que irá gerar os post-its para a raia de ações.

Vejamos como foi a primeira Retrospective do projeto:

José(S.M.): Time vamos começar a nossa primeira Retrospective.
José(S.M.): Nos post-its vermelhos escrevam o que vocês identificaram como pontos negativos da Sprint e nos post-its verdes escrevam o que vocês identificaram como pontos positivos. Podem começar.

Algum tempo depois.

José(S.M.): Vou pegar os post-its de todos e anexar no quadro para começarmos a discussão.

Quadro(visão 1)
  • Pontos Positivos
    • Tivemos poucos atrasos.
    • Assertividade nas estimativas das tarefas.
    • A equipe se adequou bem com o Scrum.
    • Etc..
  • Pontos Negativos
    • Pouca comunicação entre os membros do time fora da daily.
    • Excesso de dúvidas durante o Sprint. Deveriam ter sido sanadas na Planning.
    • Houve pouca comunicação com o P.O.
    • Falta de padrões de codificação.
    • Falta de padrões de nomenclatura de objetos de banco de dados.
    • Etc...
José(S.M.): Time pensem no que vamos melhorar para a execução da próxima Sprint.
Joel(S.T.): Acho que para melhorar a comunicação deveríamos programar em pares.
José(S.M.): Boa. Vou anotar.
Janaína(S.T.): Acho que deveríamos criar um grupo de e-mail somente do projeto para melhorar a comunicação com o P.O.
José(S.M.): Boa. Vou anotar também.

Algum tempo depois de se discutir os pontos negativos chegou-se a seguinte lista.
  • Pontos Positivos
    • Tivemos poucos atrasos.
    • Assertividade nas estimativas das tarefas.
    • A equipe se adequou bem com o Scrum.
    • Etc..
  • Pontos Negativos
    • Pouca comunicação entre os membros do time fora da daily.
    • Excesso de dúvidas durante o Sprint. Deveriam ter sido sanadas na Planning.
    • Houve pouca comunicação com o P.O.
    • Falta de padrões de codificação.
    • Falta de padrões de nomenclatura de objetos de banco de dados.
    • Etc... 
  • Ações
    • Programar em pares.
    • Criação de um grupo de e-mail para o projeto.
    • Criação de um padrão de nomenclatura para objetos de banco de dados.
    • Etc... 

11. Como foi o fim do projeto Scrum relativo ao aplicativo mobile da Pepino S.A. ?

Sucesso


O Scrum pode ser usado tanto para projetos simples quanto para projetos complexos, tanto para projetos grandes quanto para projetos pequenos. A framework também pode ser configurada para equipes grandes ao permitir subdivisões com o famoso Scrum de Scrums, o que garante uma boa escalabilidade.

Não existe um rito específico para um projeto Scrum, mas entende-se que o final é marcado pela data do último Sprint e que o projeto foi bem sucedido ou não se as metas definidas do negócio e do projeto foram atendidas.

Toda história dever ter um final feliz. Vejamos com foi na Pepino S.A.

O projeto foi um sucesso em todos os aspectos, na entrega, na apresentação, no usos, etc. Poderia ter sido um fracasso devido as circunstâncias, mas como todos estavam empenhados e abertos a uma mudança de paradigma, ele foi finalizado com êxito.

Números do projeto:
  • Integrantes
    • 1 Product Owner
    • 2 Scrum Masters
    • 4 Membros de equipe.
  • Ritos
    • 10 Sprints
    • 150 dias  = 10 Sprints x 15 dias
    • 10 Planning Meetings
    • 10 Retrospectives
    • 150 Dailys


Questões



Ano: 2015 / Banca: FCC / Órgão: TRT3(MG)

Um técnico de TI está trabalhando em um projeto de desenvolvimento de software que utiliza o modelo Scrum, em que as funcionalidades a serem implementadas, na forma de histórias de usuários, são mantidas em uma lista denominada:

A) product backlog.

B) sprint.

C) chaos list.

D) sprint burndown.

E) metaphor list.

 


Ano: 2014 / Banca: FCC / Órgão: TRT13(PB)

No Scrum, um projeto se inicia com uma visão simples do produto que será desenvolvido. 

A visão pode ser vaga a princípio e ir tornando-se clara aos poucos. 

O (1) então, transforma essa visão em uma lista de requisitos funcionais e não-funcionais para que, quando forem desenvolvidos, reflitam essa visão. 

Essa lista, chamada de (2), é priorizada pelo (3) de forma que os itens que gerem maior valor ao produto tenham maior prioridade.

Completa, correta e respectivamente, as lacunas (1), (2) e (3): 

A) (Daily Scrum) (Scrum Team) (Sprint)

B) (Daily Scrum) (Product Backlog) (Sprint Planning Meeting)

C) (Product Owner) (Sprint) (Product Backlog)

D) (Scrum Team) (Sprint Planning Meeting) (Product Owner)

E) (Scrum Team) (Sprint Planning Meeting) (Product Owner)






Ano: 2014 / Banca: FCC / Órgão: AL(PE)

O Scrum define reuniões e eventos que devem ser realizados de forma a oferecer oportunidades formais para inspeção e adaptação, cujos tempos de duração são referenciais máximos recomendados. Considere:

I. É uma Sprint de um mês, para inspecionar o incremento e adaptar o Backlog do Produto, se necessário.

II. É uma reunião time-boxed de 3 horas para uma Sprint de um mês, sendo uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint.

III. É um evento time-boxed de 15 minutos, para que a Equipe de Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas.

IV. É um time-box de 8 horas para uma Sprint de um mês de duração.


Estão de acordo com as definições I, II, III e IV, respectivamente, as denominações:

A) planejamento da Sprint - revisão da Sprint - daily Scrum - retrospectiva da Sprint

B) revisão da Sprint - retrospectiva da Sprint - daily Scrum - planejamento da Sprint

C) revisão da Sprint - planejamento da Sprint - 15 min break - retrospectiva da Sprint

D) retrospectiva da Sprint - planejamento da Sprint - short meeting - revisão da Sprint

E) planejamento da Sprint - retrospectiva da Sprint - daily Scrum - revisão da Sprint



Nenhum comentário:
Postar um comentário