Os Papéis do Scrum

Os três papéis definidos no Scrum são:

           * Scrum Master

           * Product Owner

           * Equipe

As pessoas que preenchem estes papéis trabalham em conjunto, numa base diária, para assegurar o bom fluxo de informações e resolução rápida de mudanças.

Scrum Master

O Scrum Master é o guardião do processo. Ele é responsável por fazer o processo correr bem removendo os obstáculos que atrapalham a produtividade da equipe, organizando e facilitando as reuniões.

As responsabilidades do Scrum Master incluem:

• Remover as barreiras entre a equipe e o Product Owner.

• Ensinar o Product Owner como maximizar o retorno sobre o investimento (ROI), e cumprir seus objetivos através do Scrum.

• Facilitar o trabalho da equipe removendo impedimentos que impeçam a equipe de trabalhar.

• Melhorar a produtividade da equipe da forma que for possível.

• Melhorar as práticas de engenharia e ferramentas para que cada incremento de funcionalidades seja potencialmente entregável.

• Manter as informações sobre o progresso da equipe visível a todos de uma forma clara e organizada.

Em termos práticos, o Scrum Master precisa entender bem do Scrum para treinar e orientar os outros papéis, e educar e ajudar as outras partes interessadas que estão envolvidas no processo. Ele deve manter atenção constante ao status do projeto em relação ao progresso esperado. Investigar e facilitar a resolução de quaisquer obstáculos que imobilizam o progresso e, geralmente, ser flexível o suficiente para identificar e lidar com quaisquer problemas que surjam. Ele deve proteger a equipe de perturbações externas.

O Scrum Master não atribui tarefas aos membros da equipe, isso é uma responsabilidade da equipe. Sua abordagem geral para a equipe é incentivá-la e facilitá-la na capacidade de tomada de decisões e resolução de problemas relacionados ao desenvolvimento, de modo que eles possam trabalhar com maior eficiência sem a necessidade de supervisão. Seu objetivo é ter uma equipe auto-organizável.

Product Owner

O Product Owner é dono do produto. Ele fornece o conhecimento do negócio em forma de requistos para a equipe assim como sua ordem de aplicação. Na prática, o Product Owner é a interface entre a empresa e os clientes.

Ele alimenta a equipe com requisitos e correções solicitadas por diversas fontes. É ele o ponto de contato para esclarecimento das dúvidas da equipe sobre os requisitos do produto.

Trabalha em conjunto com a equipe definindo as necessidades dos usuários, os requisitos técnicos, documentando-os conforme a necessidade, e determinando a ordem de sua execução. Ele gerencia o Product Backlog (que é o repositório de todas essas informações), mantendo-o ao nível de detalhe e qualidade que a equipe necessita.

O Product Owner também define o cronograma para liberação das releases, e faz a validação final para saber se as implementações têm as características e qualidade necessárias para a liberação.

Equipe

A equipe, no framework Scrum, deve ser auto-organizada e multidisciplinar, composta por pessoas que fazem o trabalho de desenvolvimento e teste do produto.

Uma vez que a equipe é responsável pelo desenvolvimento do produto, ela também deve ter a autonomia para tomar decisões sobre como executar o seu trabalho. A equipe possui, portanto, auto-organização: os membros da equipe decidem como dividir o trabalho em tarefas, e ao longo da sprint decidem a ordem de execução das tarefas em função da história que está sendo desenvolvida, respeitando sempre a prioridade.

O tamanho da equipe deve ser mantido até nove pessoas, se possível. Um número maior pode dificultar a comunicação e afetar a produtividade.

Fonte: http://www.cprime.com/about/scrum_faq.html

A gerência de risco no XP.

Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, se trata de uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança.

Esta metodologia nasceu nos Estados Unidos ao final da década de 90. E como a febre do gerenciamento de projeto com metodologias ágeis, também está fazendo sucesso em diversos países, ajuda a engajar equipes, ajuda a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica do que nos métodos tradicionais e tudo isso pode ser alcançado pois o XP tem em sua base, foco em valores, princípios e práticas, que vão na linha contrária da forma tradicional e antiga de de desenvolver software.

O XP tem seu foco maior, no escopo, como forma para atingir o sucesso dos projetos e é com o foco no escopo que vem junto a preocupação com mudanças e riscos, por isso aborda a gerência de riscos de forma mais completa do que metodologias ágeis como Scrum e Kanban, mostrando ter muito mais artefatos e maneiras de gerenciar o risco. 

Porém com algumas práticas do XP o risco se torna algo maior ou mais emergente, como por exemplo a necessidade da disponibilidade do cliente para colaborar em dúvidas, alterações e priorizações em escopo. Isso dar um dinamismo maior ao projeto porém faz com que o projeto também esteja na dependência de uma pessoa externa a equipe que pode precisa de incetivo para engajamento no projeto.

Outro exemplo é ter como fundamento a refatoração que diz que, a cada nova funcionalidade, é  necessário que o projetista ou arquiteto de software faça uma refatoração no código, porém esta prática reflete em mais hora de trabalho e  isso se torna uma prática nem sempre aceita, por envolver prazos e custos, há uma rejeição tanto por parte do cliente quanto por parte do gerente de projeto.Isso prova que trabalhar de forma ágil como no XP, tem uma complicação por provocar aumento dos riscos do projeto, implicando em um aumento no custo para se gerenciar riscos quando se adota metodologias ágeis, mesmo porque os métodos ágeis são menos eficiente do que os métodos tradicionais quando se fala de gerência de riscos.

O que é Kanban?

Kanban é um termo de origem japonesa e significa literalmente “cartão” ou “sinalização”. É um conceito relacionado com a utilização de cartões (post-it e outros) para indicar o andamento dos fluxos de produção em empresas de fabricação em série. Nesses cartões são colocadas indicações sobre uma determinada tarefa, por exemplo, “para executar”, “em andamento” ou “finalizado”.

A utilização de um sistema Kanban permite um controle detalhado de produção com informações sobre quando, quanto e o que produzir.O método Kanban foi inicialmente aplicado em empresas japonesas de fabricação em série e está estreitamente ligado ao conceito de “just in time”. A empresa japonesa de automóveis Toyota foi a responsável pela introdução desse método devido a necessidade de manter um eficaz funcionamento do sistema de produção em série.

O Kanban eletrônico (e-Kanban) é utilizado em substituição ao método físico evitando alguns problemas como a perda de cartões e proporcionando mais rapidez na atualização do quadro de tarefas.Atualmente, o Kanban é muitas vezes usado em conjunto com o Scrum, porque são duas metodologias usadas no desenvolvimento ágil de software. Outro conceito que por vezes é relacionado com Kanban, Just in Time e Scrum é Kaizen, que também tem como objetivo aumentar a produtividade.

Fonte: http://www.significados.com.br/kanban/

Formação do time - equipe SCRUM

                   O Time Scrum é composto pelo Product Owner, o Time de Desenvolvimento e o Scrum Master. Times Scrum são auto-organizáveis e multifuncionais. Times auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora do Time. Times multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe.

                  O modelo de time no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade. Times Scrum entregam produtos de forma iterativa e incremental, maximizando as oportunidades de realimentação. Entregas incrementais de produto “Pronto” garantem que uma versão potencialmente funcional do produto do trabalho esteja sempre disponível.

Product Owner

O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho do Time de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. 

O gerenciamento do Backlog do Produto inclui: 

 Expressar claramente os itens do Backlog do Produto;

 Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões; 

 Garantir o valor do trabalho realizado pelo Time de Desenvolvimento; 

 Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e, 

 Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário. 

O Product Owner pode fazer o trabalho acima, ou delegar para o Time de Desenvolvimento fazê-lo. No entanto, o Product Owner continua sendo o responsável pelos trabalhos. O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner. Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões. 

                         As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém tem permissão para falar com o Time de Desenvolvimento sobre diferentes configurações de prioridade, e o Time de Desenvolvimento não tem permissão para agir sobre o que outras pessoas disserem. 

O Time de Desenvolvimento

O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos. Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de Desenvolvimento como um todo. Os Times de Desenvolvimento tem as seguintes características: 

 Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis; 

 Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto. 

 O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra. 

 Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo; e, 

 Times de Desenvolvimento não contém sub-times dedicados a domínios específicos de conhecimento, tais como teste ou análise de negócios. Tamanho do Time de Desenvolvimento O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho dentro dos limites da Sprint. Menos de três integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade. Times de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando um Time de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável. Havendo mais de nove integrantes é exigida muita coordenação. Times de Desenvolvimento grandes geram muita complexidade para um processo empírico gerenciar. Os papéis de Product Owner e de Scrum Master não são incluídos nesta contagem, a menos que eles também executem o trabalho do Backlog da Sprint. 

Scrum Master

                            O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum. 

O Scrum Master trabalhando para o Product Owner O Scrum Master serve o Product Owner de várias maneiras, incluindo: 

 Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto; 

 Claramente comunicar a visão, objetivo e itens do Backlog do Produto para o Time de Desenvolvimento; 

 Ensinar a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa; 

 Compreender a longo-prazo o planejamento do Produto no ambiente empírico; 

 Compreender e praticar a agilidade; e, 

 Facilitar os eventos Scrum conforme exigidos ou necessários. 

O Scrum Master trabalhando para o Time de Desenvolvimento 

O Scrum Master serve o Time de Desenvolvimento de várias maneiras, incluindo: 

 Treinar o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade; 

 Ensinar e liderar o Time de Desenvolvimento na criação de produtos de alto valor; 

 Remover impedimentos para o progresso do Time de Desenvolvimento; 

 Facilitar os eventos Scrum conforme exigidos ou necessários; e, 

 Treinar o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido.

O Scrum Master trabalhando para a Organização

O Scrum Master serve a Organização de várias maneiras, incluindo: 

 Liderando e treinando a organização na adoção do Scrum; 

 Planejando implementações Scrum dentro da organização; 

 Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico; 

 Causando mudanças que aumentam a produtividade do Time Scrum; e, 

 Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum nas organizações.

Fonte: Guia do SCRUM

Scrum Solo

Produzir software de maneira ad hoc não é possível, no entanto o Scrum Solo surge como uma customização do processo Scrum voltada para o desenvolvimento individual de software. 

Ao analisar a Figura 1, é possível perceber que o Scrum Solo possui características semelhantes ao Scrum propriamente dito. O product backlog e o sprint backlog ocorrem de maneira idêntica em ambos os frameworks. No Scrum Solo, é proposto que os Sprints tenham durações reduzidas a uma semana e não existam reuniões diárias, ao final de cada Sprint, de forma equivalente ao Scrum, deve ser entregue, pelo desenvolvedor, um protótipo do software com novas funcionalidades e, podem existir, quando necessário, reuniões de orientação entre o grupo de validação (clientes e usuários finais) e o desenvolvedor. 

Figura 1 - Fluxo do processo Scrum Solo

É importante evidenciar também que o fato do Scrum Solo integrar as boas práticas do Framework Scrum com as prerrogativas delineadas pelo PSP garante qualidade e agilidade na produção do software como mostra a figura 2.

Figura 2 - Escopo do Scrum Solo

O processo Scrum Solo pode ser visualizado na íntegra no seguinte endereço:

Fonte: http://scrumsolo.wordpress.com.

Conhecendo o SCRUM...

Segundo Ken Schwaber e Jeff Sutherland, é um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível. 

Scrum é: 

 Leve

 Simples de entender 

 Extremamente difícil de dominar 

Scrum é um framework estrutural que está sendo usado para gerenciar o desenvolvimento de produtos complexos desde o início de 1990. Scrum não é um processo ou uma técnica para construir produtos; em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas. O Scrum deixa claro a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos, de modo que você possa melhorá-las. O framework Scrum consiste nos times do Scrum associadas a papéis, eventos, artefatos e regras. Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum. As regras do Scrum integram os eventos, papéis e artefatos, administrando as relações e interações entre eles. 

Ao decorrer das próximas postagens detalharemos aprofundaremos o conhecimento sobre Scrum! 

Até lá!

Fonte: Guia do Scrum™