Olá, pessoal vamos prosseguir com o Scrum e para fechar o assunto vamos
falar hoje sobre o time, papeis de cada um e aspectos deste Framework. Espero
que gostem!
Como vimos no post anterior esse Framework utiliza algumas reuniões para delinear seu processo de incremento do produto que ocorre através das Sprints. Então vamos ver quem faz parte do Time Scrum.
O Time Scrum: O time Scrum é composto por desenvolvedores que transformam o Backlog do produto em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Membros do tipo Scrum frequentemente possuem conhecimentos especializados, como programação, controle de qualidade, analise de negocio, arquitetura, projeto de interface de usuário ou projeto de banco de dados.
Os Times Scrum são auto-organizáveis e cada componente pode atuar em áreas especificas de seu conhecimento como em outras áreas conforme necessidade, mesmo que isso exija do componente aprender e desenvolver novas habilidades.
O tamanho ótimo para um time Scrum é de sete pessoas contato com variação de dois para mais ou para menos. Quando há cinco ou menos membros no time, há menor interação e, como resultado, há menor ganho de produtividade. Ainda pode-se encontrar dificuldade técnicas que acarretaram dificuldades em entregar partes da Sprint trabalhada.
Quando o time possui nove componentes ou mais, há uma necessidade maior de coordenação do time. Times grades geram muita complexidade para que um processo empírico consiga gerenciar.
O Product Owner e o Scrum Master não estão incluídos na conta das equipes, a menos que estes executem mais de um papel na instituição.
A composição do time Scrum pode mudar ao final da Sprint, porém, toda vez que o time muda, o ganho de produtividade reduz porque a auto-organização do time requer entrosamento entre a equipe.
Product Owner: Product Owner é a única pessoa responsável pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Time, ele é o dono do produto!
Essa pessoa matem o backlog do produto e garante que ele esta visível para todos. O Product Owner é uma pessoa e não um comitê, por tanto, mesmo que se tenha um comitê que define prioridades do produto, essa prioridade será representada pelo Product Owner e ele é o responsável por seu Backlog.
Para que o Product Owner obtenha sucesso, todos na organização precisam respeitar suas decisões. Ninguém tem permissão de dizer ao Time Scrum para trabalhar em outro conjunto de prioridades uma vez que o Product Owner é quem defini as prioridades do Backlog do Produto.
ScrumMaster: O ScrumMaster é o responsável por garantir que o time Scrum esteja aderindo aos valores do Scrum, às praticas e as regras. O ScrumMaster educa o time treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade.
O papel do ScrumMaster é ajudar o time Scrum a entender e usar o autogerenciamento e interdisciplinaridade. No entanto, o ScrumMaster não gerencia o time Scrum; o time Scrum é auto-organizável.
O Framework Scrum, consiste ainda em trabalhar com eventos com duração fixa, artefatos e regras e agora vamos conhecer um pouco mais dessa parte importante para o processo.
Eventos de duração Fixa: no primeiro post, vimos que temos reuniões especificas para cada etapa e cada reunião possui um Time-boxe, ou seja, uma duração fixa.
As reuniões presentes no Scrum e que possuem um time-boxe especifico são:
Reunião de Planejamento da Versão para Entrega: O propósito dessa reunião é estabelecer um plano e metas que o time Scrum e o resto da organização possam entender e comunicar. Essa etapa responde a pergunta: “Como podemos transformar a visão em um produto vencedor da melhor maneira possível?
O plano da versão para entrega estabelece a meta da versão, as maiores prioridades do backlog do produto, os principais riscos e as características gerais e funcionalidades que estarão contidas na versão. Ela estabelece também uma data de entrega e custo prováveis que devem manter se nada mudar.
Ao se utilizar o Scrum, os produtos são construídos interativamente, de modo que cada sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco. Mas e mais Sprints vão adicionando incrementos ao produto. Cada incremento é um pedaço potencialmente entregável do produto completo.
Quando já tiverem sido criados incrementos suficientes para que o produto tenha valor e uso para seus investidores, o produto é entregue.
Sprint: Sprint é o tempo em que o time Scrum se dedica para desenvolver o Backlog de produto definido na Reunião de planejamento da Sprint. Durante a Sprint, o ScrumMaster garante que não será feita nenhuma mudança que possa afetar a Meta da Sprint. Tanto a composição do time quanto as metas de qualidade devem permanecer constantes durante a Sprint.
As Sprints ocorrem uma após a outra, sem intervalos entre elas. O Scrum é um framework para projetos cujo horizonte não é superior ao período de um mês, onde já há complexidade suficiente para tal que um horizonte mais longo seria arriscado demais. A previsibilidade do projeto deve ser controlada pelo menos a cada mês, e o risco de que o projeto saia de controle ou se torne imprevisível é contido pelo menos a cada mês.
Somente o Product Owner tem o poder para cancelar uma Sprint, embora ele possa fazê-lo sob influencia das partes interessadas, do Time Scrum ou do ScrumMaster. A gerencia pode solicitar ao Product Owner que cancele uma Sprint sob varias situações como: Mudança de estratégia da corporação, Tecnologia, mudanças de mercado, etc. Em gera uma Sprint só deve ser cancelada se esta não fizer mais parte das circunstancias atuais.
O cancelamento de uma Sprint é traumático e consome recursos já que todos terão que se reagrupar em outra reunião de planejamento de Sprint para iniciar nova Sprint.
Revisão da Sprint: Ao final da Sprint, é feita uma reunião de revisão da Sprint. Para Sprints de um mês, essa é uma reunião com duração de 4 horas e proporcional a Sprints de menor período.
Durante a Revisão da Sprint, o time Scrum e as partes interessadas colaboram sobre o que acabou de ser feito. Baseados nisso e em mudanças no Backlog do Produto feitas durante a Sprint, eles colaboram sobre quais são as próximas coisas que podem ser feitas.
A reunião inclui o Product Owner, o Time Scrum e o ScrumMaster e fornece entradas valiosas para as reuniões de planejamento de Sprints seguintes.
Pessoal, o Scrum é muito mais que um simples Framework ou metodologia.Conheça mais de seus processos pesquisando as referencias abaixo e nos fale de suas experiencias.
No mercado existem profissionais certificados em desenvolvimento utilizando o Scrum, para saber mais acesse: http://www.scrum.org/Assessments/Professional-Scrum-Master-Assessments
Como vimos no post anterior esse Framework utiliza algumas reuniões para delinear seu processo de incremento do produto que ocorre através das Sprints. Então vamos ver quem faz parte do Time Scrum.
O Time Scrum: O time Scrum é composto por desenvolvedores que transformam o Backlog do produto em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Membros do tipo Scrum frequentemente possuem conhecimentos especializados, como programação, controle de qualidade, analise de negocio, arquitetura, projeto de interface de usuário ou projeto de banco de dados.
Os Times Scrum são auto-organizáveis e cada componente pode atuar em áreas especificas de seu conhecimento como em outras áreas conforme necessidade, mesmo que isso exija do componente aprender e desenvolver novas habilidades.
O tamanho ótimo para um time Scrum é de sete pessoas contato com variação de dois para mais ou para menos. Quando há cinco ou menos membros no time, há menor interação e, como resultado, há menor ganho de produtividade. Ainda pode-se encontrar dificuldade técnicas que acarretaram dificuldades em entregar partes da Sprint trabalhada.
Quando o time possui nove componentes ou mais, há uma necessidade maior de coordenação do time. Times grades geram muita complexidade para que um processo empírico consiga gerenciar.
O Product Owner e o Scrum Master não estão incluídos na conta das equipes, a menos que estes executem mais de um papel na instituição.
A composição do time Scrum pode mudar ao final da Sprint, porém, toda vez que o time muda, o ganho de produtividade reduz porque a auto-organização do time requer entrosamento entre a equipe.
Product Owner: Product Owner é a única pessoa responsável pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Time, ele é o dono do produto!
Essa pessoa matem o backlog do produto e garante que ele esta visível para todos. O Product Owner é uma pessoa e não um comitê, por tanto, mesmo que se tenha um comitê que define prioridades do produto, essa prioridade será representada pelo Product Owner e ele é o responsável por seu Backlog.
Para que o Product Owner obtenha sucesso, todos na organização precisam respeitar suas decisões. Ninguém tem permissão de dizer ao Time Scrum para trabalhar em outro conjunto de prioridades uma vez que o Product Owner é quem defini as prioridades do Backlog do Produto.
ScrumMaster: O ScrumMaster é o responsável por garantir que o time Scrum esteja aderindo aos valores do Scrum, às praticas e as regras. O ScrumMaster educa o time treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade.
O papel do ScrumMaster é ajudar o time Scrum a entender e usar o autogerenciamento e interdisciplinaridade. No entanto, o ScrumMaster não gerencia o time Scrum; o time Scrum é auto-organizável.
O Framework Scrum, consiste ainda em trabalhar com eventos com duração fixa, artefatos e regras e agora vamos conhecer um pouco mais dessa parte importante para o processo.
Eventos de duração Fixa: no primeiro post, vimos que temos reuniões especificas para cada etapa e cada reunião possui um Time-boxe, ou seja, uma duração fixa.
As reuniões presentes no Scrum e que possuem um time-boxe especifico são:
Reunião de Planejamento da Versão para Entrega: O propósito dessa reunião é estabelecer um plano e metas que o time Scrum e o resto da organização possam entender e comunicar. Essa etapa responde a pergunta: “Como podemos transformar a visão em um produto vencedor da melhor maneira possível?
O plano da versão para entrega estabelece a meta da versão, as maiores prioridades do backlog do produto, os principais riscos e as características gerais e funcionalidades que estarão contidas na versão. Ela estabelece também uma data de entrega e custo prováveis que devem manter se nada mudar.
Ao se utilizar o Scrum, os produtos são construídos interativamente, de modo que cada sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco. Mas e mais Sprints vão adicionando incrementos ao produto. Cada incremento é um pedaço potencialmente entregável do produto completo.
Quando já tiverem sido criados incrementos suficientes para que o produto tenha valor e uso para seus investidores, o produto é entregue.
Sprint: Sprint é o tempo em que o time Scrum se dedica para desenvolver o Backlog de produto definido na Reunião de planejamento da Sprint. Durante a Sprint, o ScrumMaster garante que não será feita nenhuma mudança que possa afetar a Meta da Sprint. Tanto a composição do time quanto as metas de qualidade devem permanecer constantes durante a Sprint.
As Sprints ocorrem uma após a outra, sem intervalos entre elas. O Scrum é um framework para projetos cujo horizonte não é superior ao período de um mês, onde já há complexidade suficiente para tal que um horizonte mais longo seria arriscado demais. A previsibilidade do projeto deve ser controlada pelo menos a cada mês, e o risco de que o projeto saia de controle ou se torne imprevisível é contido pelo menos a cada mês.
Somente o Product Owner tem o poder para cancelar uma Sprint, embora ele possa fazê-lo sob influencia das partes interessadas, do Time Scrum ou do ScrumMaster. A gerencia pode solicitar ao Product Owner que cancele uma Sprint sob varias situações como: Mudança de estratégia da corporação, Tecnologia, mudanças de mercado, etc. Em gera uma Sprint só deve ser cancelada se esta não fizer mais parte das circunstancias atuais.
O cancelamento de uma Sprint é traumático e consome recursos já que todos terão que se reagrupar em outra reunião de planejamento de Sprint para iniciar nova Sprint.
Revisão da Sprint: Ao final da Sprint, é feita uma reunião de revisão da Sprint. Para Sprints de um mês, essa é uma reunião com duração de 4 horas e proporcional a Sprints de menor período.
Durante a Revisão da Sprint, o time Scrum e as partes interessadas colaboram sobre o que acabou de ser feito. Baseados nisso e em mudanças no Backlog do Produto feitas durante a Sprint, eles colaboram sobre quais são as próximas coisas que podem ser feitas.
A reunião inclui o Product Owner, o Time Scrum e o ScrumMaster e fornece entradas valiosas para as reuniões de planejamento de Sprints seguintes.
Retrospectiva da
Sprint: Essa reunião acontece antes da próxima reunião de planejamento da Sprint. Nesta reunião, com duração fixa em
três horas, o ScrumMaster encoraja o Time a revisar, dentro do modelo de
trabalho e das práticas do processo do Scrum, seu processo de desenvolvimento,
de forma a torna-lo mais eficaz e gratificante para a próxima Sprint.
A finalidade da Retrospectiva é inspecionar como correu a
última Sprint em se tratando de pessoas,
das relações entre elas, dos processos e das ferramentas. A inspeção deve identificar e priorizar os principais
itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter
deixado as coisas ainda melhores. Isso inclui a composição do Time,
preparativos para as reuniões, ferramentas, definições de “pronto”, métodos de
comunicação e processos para transformar itens do Backlog do produto em alguma
coisa pronta.
Ao final da retrospectiva, o Time Scrum deve ter
identificado medidas de melhoria factíveis e essas mudanças se tornaram a
adaptação para a inspeção empírica da próxima Sprint.
Reunião Diária:
Cada Time se encontra para uma reunião de 15 minutos, sendo essa reunião
realizada sempre no mesmo lugar e horário.
Durante a reunião cada membro explica:
1 - O que realizou desde a ultima reunião diária?
2 – O que ele vai fazer antes da próxima reunião diária (que
será a próxima reunião)?
3 – Quais obstáculos estão em seu caminho?
As reuniões diárias melhoram a comunicação, eliminam outras reuniões,
identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem
a tomada de decisão, melhoram o nível de conhecimento de todos acerca do
projeto.
O ScrumMaster garante que o time realize essa reunião,
ensina o time a manter a reunião com o prazo estipulado reforçando as regras
garantindo que as pessoas falem brevemente. O ScrumMater também enfatiza a
regra em que somente o time tem poder de
fala nesta reunião.
A reunião diária não é uma reunião de status, ela é uma
reunião de acompanhamento e inspeção do progresso em direção a meta da Sprint.
Só participam pessoas do time Scrum que estão transformando o backlog de
produtos em um incremente utilizável. A intenção é sempre otimizar a
probabilidade de que o time alcance a meta da sprint.
Pessoal, o Scrum é muito mais que um simples Framework ou metodologia.Conheça mais de seus processos pesquisando as referencias abaixo e nos fale de suas experiencias.
No mercado existem profissionais certificados em desenvolvimento utilizando o Scrum, para saber mais acesse: http://www.scrum.org/Assessments/Professional-Scrum-Master-Assessments
Referencias usada para esse artigo:
Guia do Scrum – Ken Schwaber, maio de 2009.
http://pt.wikipedia.org/wiki/Scrum
