Quem dentre as seguintes alternativas é responsável por prover ao Time Scrum com um ambiente propício para criar os entregáveis?

Na primeira parte do artigo, aprendemos um pouco sobre os princípios do Scrum, baseado no Guia SBOK™.

Se você ainda não leu a primeira parte desse artigo, basta clicar nesse link https://goo.gl/5bYfcB

Hoje vou falar sobre aspectos.

Aspectos do Scrum

Os aspectos do Scrum devem ser destacados e gerenciados durante o projeto Scrum. Esses aspectos são dividos em 5: Organização, Justificativa de negócio, Qualidade, Mudança e Risco.

Organização - está ligada aos papéis e suas responsabilidades dentro do projeto. Os papéis são divididos em duas categorias: Papéis centrais e papéis não-essenciais.

Para ilustrar melhor esses papéis, vou ilustrar com a fábula do Porco e da Galinha.

Na tirinha acima vemos a diferença entre envolvimento e comprometimento. A contribuição da galinha para o restaurante seria apenas os ovos, ou seja, ela apenas precisaria por ovos, entregar ao restaurante e voltar as suas atividades normais, mas para o porco fornecer o pernil, ele teria que ser abatido. Então a galinha apenas faria uma contribuição e o porco daria a própria vida.

Existem também os pombos, que são aqueles que quando entram em um projeto, só fazem sujeira e saem voando. Cuidado com eles.

Papéis centrais (Porco):

Product Owner PO (Dono do produto) - Representa a voz do cliente. Responsável por alcançar o maior valor de negócio para o projeto e coordenação das necessidades dos clientes.

Scrum Master - Responsável por manter o time Scrum em um ambiente propício para concluir o projeto com sucesso. Ele servirá como uma certa blindagem para assuntos externos que venha a atrapalhar o rendimento do time. O Scrum Master é responsável por guiar, facilitar e ensinar as práticas do Scrum para todos os envolvidos no projeto. Remove os impedimentos e assegura que os processos estejam sendo seguidos. Se a equipe não estiver entregando o que foi planejado, é obrigação do Scrum Master entender porque isso está acontecendo e tomar uma atitude para que as entregas sejam feitas dentro do prazo combinado. Não devemos pensar que o Scrum Master deve gerenciar o projeto, essa atribuição é do gerente de projetos.

Time Scrum - Responsável pelo desenvolvimento das entregas e entender os requisitos especificados pelo dono do produto. É o pessoal que mete a mão na massa. No caso de um projeto de software, são os desenvolvedores.

Papéis não essenciais (Galinha)

Que não são obrigatoriamente necessários para o projeto Scrum

Papéis não essenciais são os que não estão comprometidos com o sucesso do projeto, porém não devem ser ignorados, pois podem ajudar ou atrapalhar o desenvolvimento.

Os papéis não essenciais são:

Partes interessadas (Stakeholders) - Stakeholders podem ser: cliente, usuário e patrocinadores. São todos aqueles que tem algum tipo de interesse que o projeto exista e funcione. Normalmente interagem com o time e influenciam o projeto em todo o seu desenvolvimento.

Scrum Guidance Body - Conjunto de documentos e/ou grupo de especialistas que estão envolvidos com a definição de objetivos relacionados com a qualidade, regulamentações governamentais de segurança e outros parâmetros chaves da organização. Orienta o trabalho do PO, Scrum Master e Time.

Fornecedores - Indivíduos ou organizações externas que fornecem produtos e/ou serviços que não estão dentros das competências essenciais da organização.

Dono do Produto Chefe (Chief Product Owner) - Esse papel existe em projetos maiores, onde existem vários times Scrum. Esse papel facilita o trabalho dos donos dos produtos dos times Scrum existentes e por manter o negócio durante um grande projeto. Acontece quando existe Scrum de Scrums.

Scrum Master Chefe (Chief Scrum Master) - Não confunda Scrum Master Chefe com um chefe de cozinha que utiliza o Scrum. Em poucas palavras, é um Scrum Master que gerencia mais de um time Scrum.

Justificativa de negócio - É importante que a organização realize uma avaliação adequada do negócio, antes de iniciar qualquer projeto, isso ajuda os tomadores de decisão a entender a necessidade do negócio para uma mudança ou para um novo produto ou serviço. A justificativa de negócio em Scrum é baseada no conceito de entrega dirigida à valor. Sempre que um projeto irá iniciar, na sua fase de planejamento, existirá a incerteza do resultado de sucesso, se aquilo que está sendo planejado, será cumprido nos prazos acordados. É impossível garantir o sucesso do projeto, independente do seu tamanho ou complexidade. Diante dessa incerteza, o Scrum tenta entregar valor o mais rápido possível. Essas entregas rápidas de valor, oferecem uma oportunidade pra reinvestimento e comprova o valor do projeto aos Stakeholders. Com o Scrum, os Stakeholders conseguem visualizar de forma concreta a evolução do projeto, dando a eles mais conforto para continuar ou não o investimento.

Como o Scrum é adaptável, qualquer alteração na justificativa de negócio, pode ser reparada sem grandes danos.

Qualidade - capacidade dos entregáveis de atender os critérios de aceitação e alcançar o valor de negócio esperado pelo cliente. Para que isso aconteça o Scrum trabalha com melhoria contínua para os times e comprometimento dos Stakeholders em manter o backlog priorizado do produto constantemente atualizado com qualquer mudança que haja nos requisitos. Como o Scrum é realizado em Sprints, isso permite que os erros sejam detectados mais cedo, através de repetitivos testes de qualidade durante o seu desenvolvimento. Com esses erros detectados precocemente, o custo de correção é infinitamente menor do que ser fosse para correção de erros detectados posteriormente. 

Para que a qualidade ocorra, é importante que estejam planejados no Sprint, tarefas como desenvolvimento, teste e documentação de forma separada.

Entregáveis que não passarem pelo teste de qualidade proposto, voltarão para o backlog priorizado e entrarão para correção na próxima Sprint. É importante que os Stakeholders estejam em constante contato com o time de desenvolvimento, para alinhar as expectativas com o que realmente está sendo desenvolvido. Esse contato aumenta a assertividade dos entregáveis da Sprint.

Mudança - Se você já trabalhou em pelo menos um projeto, sabe que todo o projeto está sujeito a mudanças e os projetos Scrum são projetados para aceitar essas mudanças. As organizações devem minimizar os impactos e maximizar os benefícios das mudanças. É importante saber que os Stakeholders podem mudar de ideia no decorrer do desenvolvimento. Dependendo do tamanho do projeto, torna-se quase impossível definir tudo o que é necessário para o termino do projeto, então novas definições aparecerão durante o desenvolvimento. No Scrum as mudanças não são um problema, pois temos entregáveis em períodos curtos que incorporam o feedback do cliente, fazendo com que o cliente interaja com frequência com o time, minimizando a entrega de uma funcionalidade em não conformidade.

Risco - É definido como um evento incerto ou um conjunto de eventos que podem afetar os objetivos de um projeto e podem contribuir para seu sucesso ou fracasso. Assim como todo o projeto, os riscos devem ser revistos de forma iterativa, do inicio do projeto até todo o seu ciclo de vida.

Riscos positivos podem ser vistos com oportunidades, já os riscos negativos devem ser encarados como ameaças. Um exemplo de risco negativo é ter apenas um investidor como detentor de grande parte do investimento. Se esse investidor recua e não pretende mais investir no projeto, o risco do fracasso para o projeto é muito grande. Já um risco positivo, que deve ser encarado como oportunidade, seria um novo investidor entrando no projeto.

Os riscos devem ser identificados, avaliados e um plano de ação deve ser definido e colocado em prática apropriadamente. Os riscos devem ser identificados, avaliados e respondidos com base em dois fatores: Probabilidade de ocorrer e impacto caso ocorra. Os riscos de alta probabilidade e alto impacto devem ser tratados antes dos de baixa.

Resolvi deixar os processos para um artigo diferente, para a leitura não ficar massante, já que são 19 processos para descrever.

Um grande abraço a todos e até os processos.

Ronni Oliveira.

Quem é o responsável por oferecer ao Time Scrum um ambiente favorável para o desenvolvimento dos entregáveis?

Quem é responsável pelo Time Scrum?

Quem é responsável por promover e suportar o Scrum?

Quem é responsável por nomear membros de um Time Scrum em um projeto?