Categorias
Sem categoria

Como fazer uma Planning do Scrum?

Projeto começando e precisamos planejar, mas por onde começar?

  • Como é feito uma Planning do Scrum?
  • Quem participa desse evento (cerimônia) e quanto tempo ela dura?
  • É necessário ir com algo pronto para ela?

Muitas perguntas surgem nessa hora, é normal… Mas vamos contar um pouquinho como fazemos por aqui.

Quando iniciamos um projeto e vamos para a primeira Planning, precisamos de algumas primícias.

O Product Owner constrói o Product Backlog com as histórias de usuários (técnica de mercado usada para levantar os requisitos necessários de um produto) devidamente priorizadas de modo que agregue valor ao cliente. Geralmente, essa priorização é feita com um conceito de MVP (mínimo produto viável) e existem N técnicas que podem ser usadas para fazer essa priorização, por exemplo, Moscow, GUT, comparação, matriz de importância e conhecimento técnico, entre outros.

Após ter o Product Backlog (confira nosso artigo de como montamos um Product Backlog) montado e priorizado pelo Product Owner, ele juntamente com o Scrum Master e o time de desenvolvimento, fazem o refinamento (usa-se até 10% do tempo do time Scrum) de algumas histórias que entrarão na Sprint a seguir.

Esse refinamento pode ser feito de várias formas, afinal o Scrum não dita nem técnicas e nem ferramentas, mas por prática costumamos usar as 7 dimensões do produto (ator, ação, interface, dados / informações, regras de negócio, qualidade (critério de aceite) e ambiente que o produto vai executar (se analisarmos as histórias o “ator” e a “ações” nós já temos nas histórias, o que facilita esse processo).

Na Planning participa o Product Owner, o Scrum Master e o time de desenvolvimento, e ela é dividida em duas partes, O que fazer e o Como fazer.

O que fazer é decidido pelo Product Owner de acordo com o que ele priorizou no Product Backlog, e ele participa para que todas as dúvidas do time sejam sanadas.

O Como fazer é decidido pelo time de desenvolvimento e ninguém, nem mesmo o Scrum Master diz ao time como transformar o Product Backlog em incrementos de funcionalidades potencialmente liberável. Eles estimam as histórias que o Product Owner priorizou. Uma das formas para estimar é o Planning poker que é uma técnica que usa a sequência de Fibonacci e o time determina em pontos (1, 2, 3, 5, 8, 13, entre outros até mesmo uma carta (símbolo de infinito) que mostra que a história está impossível de mensurar, tem outra com a figura de uma xícara de café que é usada quando o time fica cansado e precisa de uma pausa e outra de interrogação, quando ainda restam dúvidas sobre o assunto abordado na história) que significa a complexidade para realizar cada história.

O Scrum Master faz um cálculo de velocidade (outra técnica de mercado) se baseando no tamanho da Sprint para saber quantos pontos a equipe é capaz de realizar naquela Sprint. Após isso, o time pega as histórias priorizadas até a capacidade que eles podem realizar e chegam em nível de tarefas, as quais normalmente são organizadas em um quadro para gestão a vista e o mais usado pelos times é o proto Kanban com as colunas que representam o processo que precisa ser seguido para entrega das tarefas feitas (geralmente encontramos quadros com as seguintes colunas: “A fazer”, “Fazendo”, “A testar”, “Testando”, “A homologar”, “Homologando”, “Impedimentos”, “Feito”).

Esse conjunto de tarefas determinadas pelo time é chamado de Sprint Backlog, e quem controla ao longo da Sprint é o próprio time de desenvolvimento, somente eles adicionam ou retiram tarefas, além de ninguém, nem mesmo o Product Owner e o Scrum Master dizer à eles como devem trabalhar.

Com base no Scrum Guide, uma Planning para uma Sprint de 30 dias tem duração de até 8 horas. Mas, você pode se perguntar, e para sprints menores?

O mercado adaptou e, provavelmente, você já deve ter visto por aí que as sprints são de 2 a 4 semanas, mas tudo isso surgiu porque na engenharia de software tem um estudo que diz que não é possível entregar nenhum incremento de valor com menos de 2 semanas. Logo, essa adaptação ficou da seguinte forma:

  • Sprint de 4 semanas a Planning tem duração de 8 horas;
  • Sprint de 3 semanas Planning de 6 horas;
  • Sprint de 2 semanas Planning de 4 h.

Até mesmo as outras cerimonias ficaram proporcionais.

Ainda na planning, o time scrum determina qual é a Definição de Concluído (conhecida também como “Definition of Done”) para aquela Sprint e todos precisam chegar em um acordo para que no final não tenham problema onde o Product Owner pergunta: “E aí tá pronto?” e o time responde: “Tá pronto, só faltar testar”. Afinal, tá pronto ou falta testar? Essa definição é de suma importância para deixar todos alinhados.

Para finalizarmos este artigo, é importante saber que no final deste evento (cerimônia) é esperado dois resultados: o Sprint Backlog e a Meta do Sprint.

Obrigada por terem ficado com a gente até aqui.

Um abraço,

Amanna Monteiro

Categorias
Sem categoria

Como fazer uma Retrospectiva do Scrum?

Chegou o evento retrospectiva do Scrum e com isso algumas dúvidas…

Como nós podemos fazer para não tornar esse evento uma lavação de roupas sujas?

Como fazer para não deixar ninguém do time constrangido?

E para evitar discórdias e formação de “panelinhas”? Entre outras inúmeras perguntas.

Tudo depende de como é feito e se está bem claro a todos que esse evento é uma bela oportunidade para que o time cresça, amadureça, se engaje, se entendam cada vez mais, pois acaba conhecendo mais uns aos outros… é um momento de adaptação e inspeção do Scrum (lembra dos três pilares? Transparência, adaptação e inspeção).

Existem várias formas de facilitar esse evento e vou dizer a você o que aplicamos em nossos clientes e funciona bem (fizemos de várias formas já e esse foi o que mais está funcionando até o momento. Sabemos que não existem receita de bolo para lidar com pessoas, então fique atento de considerar o estilo e perfil de cada um, ok?) –Tenho uma dica de leitura que eu considero fantástica: “Como fazer amigos e influenciar pessoas de Dale Carnegie” – se você já leu, sugiro ler novamente com outra visão e se ainda não leu, coloque em sua lista de leitura, pois vale muito a pena.

Então, a final, qual técnica que usamos? Vou detalhar pra você…

Dividimos a parede ou quadro branco em dois e colocamos um sinal de positivo (+) do lado esquerdo e negativo (-) do lado direito. Pedimos para que o time se concentre por 5 minutos nos positivos e sem conversar um com outro, vão anotando em post-its e colando do lado correspondente, depois, por mais 5 minutos é a vez dos negativos e repetem a mesma coisa. Ao terminar o tempo, nós perguntamos quem quer moderar esse evento (mas, Dri, isso não é papel do Scrum Master (SM)? Sim, porém pode revezar e assim o mesmo treina o time em autogerenciamento e muitas outras coisas que ficam atreladas – vale até artigos falando somente de soft skills necessários em times). Então, alguém vai até o local onde os post-its estão colados e organiza – elimina os que estão repetidos, agrupam os que tem semelhança; lê em voz alta a todos e nos positivos, depois que todos estão lidos e entendidos por todos, aplaudem – sim, é motivo de comemorar!! Depois, lê os negativos (e não fica perguntando quem escreveu ou até mesmo tentando descobrir, lembre-se que não é o intuito expor ninguém – por isso, sempre alertamos para que seja escrito com muita clareza para que possamos entender, caso contrário, deixaremos para próxima “retrô”). Para cada item negativo o time sugere plano de ação que será implantado na próxima sprint (tem que ir para o próximo sprint com pelo menos um para melhoria e assim, vamos promovendo a melhoria continua – o famoso Kaizen na prática do Lean manufacturing do setor automobilístico), acrescenta então no próximo Sprint Backlog e assim as coisas seguem.

Espero que tenha gostado de ficar até aqui comigo e que realmente isso faça sentido para você e sua equipe.

Grande abraço e até mais!

Adriane Colossetti – Família Sunsetti

Categorias
Sem categoria

Como montar um Product Backlog?

Recebo muitas dúvidas sobre o ágil, Scrum, Kanban e outros frameworks. No nosso dia a dia na Sunsetti, vemos muitos times com dificuldades logo no início da aplicação do Scrum e por isso, deixo aqui nossa experiencia de como montar um Backlog do produto.

  • Por onde começar a montar um product backlog? Como faço isso? Tem que ser com histórias de usuário? Tem outras formas de fazer?
  • Como priorizar? No que podemos nos basear para que isso seja feito de forma coerente?
  • Quem é responsável? Quem pode ajudar?

Fazendo um dê / para do que aprendemos com a engenharia de software (ES): dividir os sprints (na grande maioria das vezes) em duas semanas – onde, na ES fala que não tem como entregar valor percebido com prazo menor do que esse.

Respondendo a primeira pergunta “Por conde começar a montar um product backlog?” Tudo se inicia de uma visão de produto (documento onde temos praticamente um business case daquele produto que vamos trabalhar e que foi escolhido de forma estratégica pela empresa). Aqui espera-se ver para quem esse produto está destinado (público / cliente-alvo); que os mesmos estão insatisfeitos ou que tem a necessidade de…; o que será ele; diferente do que temos hoje no mercado (da própria empresa e concorrentes) e qual diferencial. Depois disso, construímos o PB com itens necessários para desenvolver o que é necessário.

Seguindo a ordens das perguntas, as próximas são “como faço isso? Tem que ser com histórias de usuário? Tem outras formas de fazer?”

Geralmente nós usamos as famosas histórias de usuários (users stories) que facilita, e muito, a vida do time Scrum, pois deixa claro para quem estamos trabalhando, qual ação necessária e o porquê. Acredite, isso ajuda muito, pois dependendo o produto que vamos trabalhar, tem usuários que podem ter x opções de acesso enquanto tem outros que não podem ter a mesma visão.

Existem outras formas de construir este artefato (documento) PB, umas delas pode ser com os próprios itens como requisitos lá da engenharia de software, como costumamos montar em projetos tradicionais. Há também várias técnicas para se chegar nesta construção, uma delas que se tornou muito conhecida é a inception, onde reúne várias ferramentas (principalmente de marketing), como mapa de empatia com a criação de personas, jornadas do cliente, features e outros. Também podemos trabalhar com roads maps e muitas outras técnicas de mercado que facilite a elaboração do mesmo.

Depois que temos o PB construído até a parte que conseguimos enxergar (sim, não precisamos criar um PB gigantesco e passar meses tentando imaginar o produto inteiro – lembre-se de um dos valores do ágil: respostas as modificações mais do que seguir um plano) temos um passo de extrema importância para a agilidade, que é:

Como priorizar? No que podemos nos basear para que isso seja feito de forma coerente?

Priorização é parte fundamental para conseguimos fugir do “cascágil” que está acontecendo muito por aí, ou seja, geralmente os times Scrum estão trabalhando com todos os eventos certinho, como está no Scrum Guide, porém, o PB está priorizado em ordem de facilidade. O que temos que fazer aqui e na minha visão é o mais desafiador é encontrar quais requisitos (histórias dos usuários ou outra técnica) são os mais valiosos ao nosso cliente. O que os nossos clientes estão esperando receber em um menor espaço de tempo. Aqui trabalhamos o famoso MVP (em português: mínimo produto viável) – o que faz sentido e o que tem valor de mercado para focarmos e desenvolvermos de forma prioritária. Isso faz toda diferença!

Agora, quem é responsável? Quem pode ajudar?

Essa é uma responsabilidade do Product Owner (PO) e quem pode auxilia-lo é o Scrum Master (SM) – também conhecido como o líder servidor / líder coach que colabora com todos no time para que o Scrum seja adotado conforme está escrito no Guia.

Vou parar por aqui, mas em outros artigos traremos mais e mais detalhes sobre esse mundo maravilhoso do ágil com frameworks que entregam com esse mindset.

Espero que tenha gostado de ficar até aqui comigo e que realmente isso faça sentido para você e sua equipe.

Grande abraço e até mais!

Adriane Colossetti – Família Sunsetti

Categorias
Sem categoria

Você sabe ouvir?

Você sabe ouvir?

Como já comentei, para que possamos nos comunicar de forma eficiente e eficaz, uma dica importantíssima é aprender ouvir e começo esse artigo com algumas perguntas a respeito:

  • Você sabe ouvir?
  • Entende o que os outros falam?
  • Quando os outros falam, você fica pensando nos problemas que precisa resolver?

Muitos ouvem o que querem ouvir e não o que realmente o outro está falando, além desse mal habito, muitos deixam os “filtros” internos e suas experiências interpretarem o que os outros falam. É… isso, definitivamente, não é saudável!

Então, o que podemos fazer para melhorar eficazmente sua capacidade de ouvir de verdade e sem filtros?

  • Aprenda a permitir que os outros expressem seus pensamentos sem interrompê-los;
  •  Aprenda a ouvir nas “entrelinhas”, pois nem sempre o outro diz tudo só com palavras;
  •  Concentre-se em desenvolver sua capacidade de retenção do que ouve;
  •  Não ignore seu interlocutor se você acha que aquilo que ele está dizendo não lhe interessa;
  •  Não se exalte ou se irrite se as ideias do outro forem contrárias às suas convicções;
  •  Aprenda a não prestar atenção às interferências do ambiente.

“Para nos comunicar com clareza e eficiência, devemos entender que somos todos diferentes na maneira como percebemos o mundo e usar esse entendimento como um guia para nossa comunicação com os outros.” Anthony Robbins (Poder sem limites)

Deixo aqui um teste (Dr. Joel Mapheo – Amil) para saber se você sabe ou não ouvir. Faça-o e só depois olhe a tendência da resposta.

Abraços e até a próxima.

Adriane Colossetti – Família Sunsetti

Categorias
Sem categoria

Como se preparar para a PSM I?

Vejo muitas pessoas perguntarem, como se preparar para a PSM I?

Bom, existem muitas maneiras, vou contar a minha experiência.

Ler o Scrum Guide, vejo como primeiro passo. Afinal, neste guia está descrito detalhadamente o que é o SCRUM e são apenas 20 páginas. Comece por ele, entenda este Framework e como ele funciona, tendo em vista que a maioria das perguntas são escritas da mesma forma que está escrito nele. Estude ele, pelo menos, umas três vezes antes da prova.

Resuma-o em tópicos, e lembre-se, não existe tópicos que são importantes ou não, tudo é de grande importância e entender cada processo é fundamental para ter êxito. Mas, ler somente ele não é o suficiente para agregar todos os conhecimentos necessários para a certificação. Então, você deve estar se perguntando, o que mais estudar?

Nexus Guide, é outro guia de suma importância, que explica o Scrum Escalado, outro Framework que se baseia no Scrum. 

No Nexus você compreende detalhes que são cobrados na prova e aprende a trabalhar de outra forma com o Scrum, por exemplo, ter apenas um Backlog de produto, independente de quantos times de desenvolvimento você tenha. Então, saber como esse Framework trabalha, é fundamental.

Outra forma de estudar e treinar seus conhecimentos adquiridos até aqui, são os simulados da Scrum.org, eles são ricos de informações explicativas sobre o tema de cada pergunta. Auxiliam a compreender muitos detalhes que, muitas vezes, passam batido na leitura do Scrum Guide. Recomendo faze-lo até atingir no mínimo 95% de acerto, pois eles são uma ótima base do que esperar da prova. 

E também como apoio, deixo abaixo alguns tópicos que são bastante questionados nas perguntas.

Cerimônias / eventos Scrum

  •  Planning – Ter em mente que a planning é uma reunião de planejamento para a Sprint que começa a seguir, composta por duas partes, o que fazer e como fazer, seu time-boxed é de 8 horas para Sprint de 1 mês (máximo permitido).
  •  Reunião diária – Reunião realizada todos os dias no mesmo lugar e hora para evitar complexidade pela a equipe de desenvolvimento, sua duração é de até 15 minutos. Nesta reunião é sugerido pelo Guide responder a 3 perguntas: 
  • O que eu fiz ontem para atingir a meta da Sprint?
  • O que eu farei hoje para atingir a meta da Sprint?
  • O que está me impedindo de atingir a meta da Sprint?
  • Review – Reunião para colher feedback das partes interessadas, a qual o incremento liberável é mostrado pelo time de desenvolvimento ao PO para ser aceito ou não, sua duração é de 4 horas para Sprint de 1 mês.
  •  Retrospectiva – Reunião realizada pelotime Scrum para analisar o que foi bom, o que foi ruim na Sprint e o que deve ser melhorado para a próxima. Tendo sua duração de até 3 horas para Sprint de 1 mês.
  • Refinamento – Normalmente é realizado em Sprints anteriores com o PO, Scrum Master e não pode consumir mais de 10% do tempo do Time.

Artefatos

  • Product Backlog – Lista de histórias de usuário feita pelo PO com todas as exigências dos Stakeholders. Vale ressaltar que existe apenas um Product Backlog por produto.
  • Backlog da Sprint –  Itens do Product Backlog priorizados e refinados, de responsabilidade da equipe de desenvolvimento, com as tarefas a serem realizadas na Sprint.

Papéis

  • Product Owner – Responsável por tratar os interesses dos Stakeholders, montar e priorizar o Product Backlog e garantir que o produto tenha um maior valor em sua entrega. Ele é o único que pode cancelar uma Sprint. Vale relembrar que ele não é um comitê, mas pode representar as vontades de um. 
  •  Scrum Master – Garante que o processo aconteça de forma correta dentro de seus time-boxed, retira os impedimentos do time de desenvolvimento, e apoia o PO caso seja necessário. É um líder-servidor que aplica práticas de liderança coach.
  • Time de desenvolvimento – Time auto organizável, ninguém os diz como trabalhar. Responsável pelo Backlog da Sprint e execução das tarefas. São eles que estimam os itens do backlog do produto e é composto por 3 a 9 pessoas.

Outros

  •  Definição de Concluído – Definição de quando o incremento está pronto, é determinado pelo time Scrum e gera transparência para todos.
  • Pilares – Transparência, adaptação e inspeção.
  •  Valores Scrum – Coragem, foco, abertura, comprometimento e respeito.

Caso precisem de algo, estamos à disposição.

Amanna Monteiro – Família Sunsetti

Categorias
Sem categoria

Habilidade em se Comunicar com Pessoas de Outras Áreas

Quem nunca teve dificuldade em lidar com pessoas que atire a primeira pedra!

E digo mais, você conversa de uma forma que parece que está falando “grego”… E pasme: está!!! Pois, na maioria das vezes fazemos uso do nosso idioma “tecniquês” e ninguém é obrigado a conhecer todos os termos.

Importante deixar claro que quando falo em “tecniquês” não necessariamente cito somente a área de tecnologia da informação, pois continuando na saga “perguntas”:

Quem nunca teve dificuldade de compreender termos técnicos de advogados, médicos, engenheiros, entre outros? Portanto, esse texto pode ser útil à todos os profissionais, cada um com sua dificuldade em conseguir se fazer entender…

Deixo algumas dicas para a área de tecnologia da informação, mas se você é um profissional de outra área de atuação, tente abstrair o objetivo principal desse artigo que é ajudá-lo(a) compreender e desenvolver hábitos de utilizar palavras que todas as pessoas que estão te ouvindo consiga se envolver na conversa, tornando-a agradável e produtiva.

Linguagem técnica x linguagem do usuário:

  • Lembre-se que o usuário tem formação diferente da sua;
  • Tente se colocar no lugar do usuário;
  • Imagine o usuário como um aprendiz e assim você terá que ser mais claro, visual e objetivo possível;
  • Use imagens para explicação;
  • Esqueça os termos técnicos, estes você pode utilizar com os colegas de seu departamento;

Abraços e até a próxima.

Adriane Colossetti – Família Sunsetti

Categorias
Sem categoria

6 Dicas Para Melhorar a Comunicação

6 DICAS PARA MELHORAR A COMUNICAÇÃO

Observando algumas apresentações de trabalhos, ressalto ainda mais minha convicção de que a forma de se expressar, falar, gesticular, faz toda diferença.

A arte de se comunicar é sem dúvida muito importante para o desenvolvimento pessoal e profissional. A pessoa que consegue manifestar suas ideias de forma clara e objetiva, tem a grande chance de sucesso. Portanto, segue algumas dicas para melhorar a dicção e aos poucos ganhar a desinibição da fala em público:

– Crie o hábito de ler livros e artigos fidedignos;

– Leia alguns trechos em voz alta;

– Leia poesias em voz alta;

– Preste atenção em sua pronúncia, clareza e tom de voz emitida;

– Preste atenção em cada palavra lida, pois nosso cérebro tem uma grande tendência de nos enganar, pois lemos tão rápido que nem sempre o que estamos percebendo é o que realmente está escrito.

– Perceba as palavras e escute as pronuncias de cada uma delas e assim conquiste gradativamente a fluência de uma fala correta, eficiente e eficaz.

Aos poucos e com exercícios simples de praticar, você ganhará segurança em seu vocabulário, bem como soltar um pouco mais a língua para que sua fala seja escutada e percebida de forma clara, limpa e objetiva.

Abraços e até a próxima.

Adriane Colossetti – Família Sunsetti