segunda-feira, 10 de abril de 2017

Serrar ou cerrar, marcação cerrada ou serrada, diferenças e significados.

serrar ou cerrar

Serrar ou cerrar ? essas duas palavras são classificadas como verbos, são homônimas homófonas por terem a mesma fonética e também são parônimas por terem a escrita semelhante. Essas palavras existem no português e estão corretas. A diferença entre estes dois verbos é a escrita e os seus significados.

Marcação cerrada é uma expressão correta decorrente do verbo cerrar, podendo significar o cuidado excessivo com algo. Já a expressão marcação serrada está incorreto e não dever ser usado.

O verbo serrar escrito com 's' significa cortar algo com um serrote, já o verbo cerrar escrito com 'c' pode possuir diversos significados, mas os principais são: fechar ou pressionar, mal tempo.

Dica: Deve-se tomar muito cuidado com algumas frases, pois ao se usar os verbos cerrar e serrar podem ocorrer ambiguidades. Imagine o seguinte caso: Um professor de odontologia chega na sala de aula e fala para seus alunos: "Quero cerrar os dentes do paciente." e no outro dia o paciente está banguela. A brincadeira exemplifica um bom caso de ambiguidade, pois o professor pronunciou o verbo cerrar com significado de fechar bem a boca mas os alunos entenderam o verbo serrar com o significado de cortar.




1. O que significa serrar ?


serrar
Significado do verbo serrar segundo o dicionário Michaelis:
  1. Cortar ou dividir com serra ou serrote.
Origem do verbo serrar:  
  • Palavra serrare em latim.
Exemplos de frases:
  • Ele mal conseguiu serrar o armário.
  • Ao serrar a madeira ele acabou cortando o dedo.
  • A porta não foi serrada conforme a descrição técnica.
  • A serra não tinha comprimento suficiente para a grossura daquela árvore.
  • O que devo fazer para serrar aquele armário.


2. O que significa cerrar ?


cerrar
Significado do verbo cerrar segundo o dicionário Michaelis:
  1. Unir duas ou mais partes separadas ou afastadas; fechar, pressionar.
  2. Bloquear abertura ou passagem; tapar, vedar.
  3. Tapar ou encobrir algo.
  4. Dar(-se) por encerrado ou concluído; concluir(-se), encerrar(-se).
  5. Tornar(-se) escuro e carregado (céu, tempo). 
Origem do verbo serrar:
  • Palavra serare em latim.
Exemplos de frases:
  • Não fez diferença alguma acender a luz em meio a cerração.
  • Ao acender a lâmpada verificou-se que o mergulhador já estava imerso.
  • Aquela cerração não me atrapalhou a dirigir.
  • Ele começou a chorar ao cerrar os olhos. 
  • O olhos de Jackie Chan estão cerrados.
  • Cerrar os dentes é perigoso para a saúde bucal.


3. Marcação cerrada ou serrada ?



marcação cerrada
Marcação cerrada, escrito com 'c', é um expressão muito comum para os amantes de futebol, que basicamente, é o trabalho, realizado com muito afinco, que um jogador desempenha em campo para impedir ou dificultar as jogadas do jogador adversário.

Outro significado para esta expressão seria o de zelo excessivo com algo ou com alguém. Um bom exemplo seria a frase: "A namorada do meu amigo sempre faz uma marcação cerrada quando saímos nos finais de semana."

Tome muito cuidado ao com esta expressão pois marcação serrada escrito com 's' está incorreto.



4. Serra ou montanha ?



serra ou montanha
Serra é a palavra que dá origem ao verbo serrar. Apesar da ação do verbo ser a de cortar algo, os principais significados para  a palavra serra, segundo o dicionário Michaellis, seriam:
  1. Ferramenta cortante dotada de lâmina ou disco de aço.
  2. Cadeia de montanhas, de longa extensão, com picos, sinuosidades e depressões.
Segundo do site ciberduvidas a diferença entre serra e montanha seria: O significado de serra remete a uma cadeia de montanhas a o significado de  montanha remete a somente um monte muito alto.



Questão de concurso 1


#   Ano: 2016 / Banca: UFMT / Órgão: TJ(MT)

Na língua portuguesa, há muitas palavras parecidas, seja no modo de falar ou no de escrever.

A palavra sessão, por exemplo, assemelha-se às palavras cessão e seção, mas cada uma apresenta sentido diferente.

Esse caso, mesmo som, grafias diferentes, denomina-se homônimo homófono.

Assinale a alternativa em que todas as palavras se encontram nesse caso.


A) taxa, cesta, assento

B) conserto, pleito, ótico

C) cheque, descrição, manga

D) serrar, ratificar, emergir


Questão de concurso 2


#   Ano: 2007 / Banca: FEC / Órgão: DETRAN(RO)

O substantivo em caixa alta no trecho “e maior SENSO de humanidade” (6º parágrafo) é homônimo do substantivo CENSO, que significa RECENCEAMENTO. 

Nas frases abaixo, foram deixadas lacunas onde cabe, pelo sentido do contexto, um dos dois homônimos entre parênteses. 

A frase que se completa com o 2º homônimo, e não com o 1º, como nas demais, é:

A) O trânsito poderia melhorar, mas por enquanto as medidas eram ____ (incipientes / insipientes).

B) Ao ver o veículo se aproximando, o pedestre ficou ____, sem saber o que fazia (estático / extático).

C) No final da palestra, o Tenente fez um ____ para os que chegaram atrasados (extrato / estrato).

D) O Tenente tinha certeza de que o assunto direção defensiva estava _____ em sua palestra (incerto / inserto).

E) O Tenente resolveu ____ sua palestra, citando um grande poeta (cerrar / serrar).




Questão de concurso 3


#   Ano: 2007 / Banca: FEC / Órgão: DETRAN(RO)

"Como CONSERTAM os óculos!" (5º §).

Pelo sentido da frase acima, tem de ser usado o verbo CONSERTAR, e não o seu homônimo CONCERTAR (harmonizar, participar de concerto).

Das frases abaixo, aquela em que a lacuna deve ser preenchida pelo segundo elemento do par de homônimos entre parênteses é:



A) O mentiroso era ____ de uma das pernas (coxo /cocho).

B) O posudo trabalhava na ____ de licitações(sessão / seção)

C) Mentirosos e posudos não têm o ____ do ridículo (senso / censo).

D) O lojista deveria ____ as portas quando percebesse o tumulto na rua (cerrar / serrar).

E) O posudo recebia em ____ as suas propinas (cheque / xeque).


sexta-feira, 7 de abril de 2017

O cheque ou o xeque, pôr em xeque ou cheque, diferenças e significados.

Cheque ou xeque


Artigos relacionados:

Sela ou Cela
As palavras cheque e xeque são substantivos masculinos e estão corretos, apesar do significado de cada um ser diferente. O mesmo não ocorre com a expressão pôr xeque escrito com 'x',  e pôr em cheque escrito com 'ch', visto que este segundo caso está errado e não deve ser usado.

Cheque com 'ch' e xeque com 'x' são palavras consideradas homófonas, ou seja, palavras que são pronunciadas de forma idêntica mas que possuem escrita e significados distintos, assim como sexta e cesta.

O vocábulo escrito com "ch" remete a um documento utilizado para fazer alguma operação bancária e o vocábulo escrito com "x" pode assumir mais de um significado, mas os mais comuns são: tipo de jogada do xadrez, líder muçulmano e forma de dizer que algo está em risco ou ameaçado.




1. Qual o significado da palavra cheque ?


cheque
O Substantivo masculino cheque, segundo o dicionário Michaelis pode assumir os seguintes significados:

  1. Ordem de pagamento, à vista, de forma impressa, com determinada quantia, emitida ao banco pelo titular de uma conta-corrente a seu favor ou de outra pessoa ou empresa.
Origem:
  • Inglês check
Exemplos:
  • O conserto da grama foi pago com um cheque de mil reais.
  • Ele foi colocado em uma cela junto com outros deputados que usaram o cheque em branco do governo.
  • Este cheque me fez um bem danado.
  • O comprimento deste cheque é diferente de todos que já vi. Pode ser que seja falso.


2. Qual o significado da palavra xeque ?


xeque
O Substantivo masculino xeque, segundo o dicionários Michaelis e Priberam pode assumir os seguintes significados:

  1. Ataque ao rei, no jogo do xadrez.
  2. Chefe muçulmano em um país, cidade, bairro ou tribo;
  3. Contrariedade ou prejuízo.
Origem:
  • Árabe xah
Exemplos:
  • O disfarce do agente foi posto em xeque.
  • A sua discrição foi posta em xeque.
  • Não é por ser xeque que ele é uma pessoa.
  • Ele emergiu como xeque naquela comunidade carente.


3. Qual o significado da expressão xeque-mate no jogo de xadrez ?



xeque mate

O xeque-mate é uma expressão cuja sua classificação é de substantivo masculino e cujo significado corresponde ao ataque indefensável que um adversário faz ao rei, a peça mais importante no jogo de xadrez.

Curiosidade: Segundo a Wikipedia a maioria dos termos de xadrez, usados pelos europeus, tem origem persa. Shah, que quer dizer rei, deu origem a check e chess em inglês, echec e echecs em francês, scacco em italiano e xaque em espanhol. Shâh-mât significa o rei está morto.







4. O certo é escrever a expressão pôr em xeque ou pôr em cheque ?



pôr em xeque
A expressão pôr em xeque escrito com 'x' está correto e é uma expressão que teve sua origem no jogo de xadrez. Basicamente este termo significa colocar algo ou alguém em posição de perigo, sendo que no xadrez corresponde a uma jogada(onde o rei é ameaçado) anterior ao xeque-mate.

Já a expressão pôr em cheque está errada conforme descrito no site ciberduvidas.







5. Xeique, sheik ou xeque, diferenças e significados.



xeque xeique sheik
Não há diferenças entre os significados das palavras Xeique, sheik e xeque, pois todas elas são sinônimas. A principal diferença encontra é na origem da cada palavra segundo o site dicio.

  • A origem da palavra xeque são as palavras em árabe xãh e em persa xah.
  • A origem da palavra xeique são as palavras em árabe xãyh e xekh.
  • A origem da palavra sheik são as palavras em inglês sheik e árabe xayh.



Questão de concurso 1


#   Ano: 2013 / Banca: FUNDEP / Órgão: IPSEMG

Leia a seguinte frase:

O mandato do deputado condenado deveria ter sido ________ naquela _______ da Câmara, mas isso não ocorreu, colocando em ________ o bom _______ do Legislativo.

Assinale a alternativa em que as palavras completam CORRETAMENTE as lacunas da frase acima.


A) caçado – cessão – cheque – censo.

B) cassado - sessão – xeque – senso.

C) cassado – seção – xeque – senso.

D) caçado – secção – cheque – censo.



Questão de concurso 2


#   Ano: 2007 / Banca: VUNESP / Órgão: TJ(SP)

Considerando que as duas personagens estão jogando xadrez, deve-se entender que a primeira, referindo-se a uma jogada, quis dizer _______ . A segunda entendeu como uma referência a um documento bancário – ________ . Trata-se________com ________ .

Os espaços da frase devem ser preenchidos, respectivamente, com
:



A) xeque ... xeque ... da mesma palavra ... a mesma pronúncia

B) cheque ... cheque ... da mesma palavra ... a mesma escrita

C) cheque ... xeque ... de palavras diferentes ... a mesma pronúncia

D) cheque ... cheque ... de palavras iguais ... a mesma pronúncia e escrita

E) xeque ... cheque ... de palavras distintas ... a mesma pronúncia



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