International Product Owner Foundation

Steen Lerche-Jensen

03 Identificando Requisitos de Pessoal

A identificação de requisitos de pessoal é um dos passos iniciais na seleção de um Scrum Master e do(s) Stakeholder(s). É importante documentar os papeis e as responsabilidades de todos os que serão envolvidos na conclusão de tarefas no projeto. Isso inclui todas as pessoas envolvidas no projeto em qualquer capacidade, independentemente de seus papeis serem ou não essenciais.

3.1 Os 4 atores principais no Scrum

 No Scrum existem 4 atores principais:

  • Os Stakeholders
  • O Product Owner
  • O Scrum Master
  • O Time (observe o capítulo 4)

Normalmente, o Product Owner ou o Scrum Master trabalham com o departamento de Recursos Humanos da Companhia para determinar e finalizar os Requisitos de Pessoal para um projeto.

Antes de selecionar o Scrum Master e o(s) Stakeholder(s), suas disponibilidades devem ser confirmadas. Apenas membros do Time que estarão disponíveis e totalmente comprometidos com o projeto devem ser selecionados. A Disponibilidade e Comprometimento de Pessoal é comumente definido na forma da exibição dos cronogramas, quando o RH estará disponível para trabalhar ao longo da duração do projeto.

Para ter efetividade, os Times Scrum devem ter, idealmente, de 6 a 10 membros; e substituir pessoas ou mudar os membros do time não é aconselhável nos Times principais do Scrum. Por essa razão, é importante ter pessoas no Time principal do Scrum que estejam disponíveis e totalmente comprometidas com o projeto.

3.1.1 O Stakeholder

O(s) Stakeholder(s) (pessoas interessadas) do Programa é um termo coletivo que inclui clientes, usuários e patrocinadores. Eles exercem influência sobre todos e por todo o desenvolvimento dos projetos do programa. Os Stakeholder(s) do Programa também podem auxiliar na definição da visão do projeto e proporcionar orientação sobre o valor do negócio.

Os Stakeholders do programa interagem com os Stakeholders do portfólio para garantir o alinhamento do programa com as metas e objetivos do portfólio. Eles também estão envolvidos com a nomeação de stakeholders para projetos individuais além de assegurar que a visão, objetivos, resultados e liberação dos projetos individuais estejam alinhados com os do programa.

3.1.2 Escolhendo o Product Owner certo

Encontrar a pessoa certa para assumer o papel de product owner é desafiador. Como fazemos, como Companhia, para escolher a pessoa certa para ser um Product Owner?

Em geral, existem duas maneiras de organizar os Times Scrum:

  • Times de funcionalidades
  • Times de Componentes

3.1.2.1 Times de funcionalidades

Um Time de funcionalidade implementa um conjunto coeso de requisitos, como um ou mais temas de funcionalidades. O resultado é uma fatia vertical executável que corta as principais partes da arquitetura do software. Os Times de funcionalidades são organizados em torno do Backlog do Produto.

3.1.2.2 Times de componentes

Um Time de Componentes cria um componente ou um subsistema. Os Times de componentes são organizados em volta da arquitetura do software.

As configurações de ambos os times tem vantagens e desvantagens. Os times de componentes garantem integridade da arquitetura e seu reuso. Infelizmente, na maior parte do tempo eles não podem consumir os itens do Backlog do Produto, como por exemplo as User Stories ou Casos de Uso, mas necessitam de requisitos técnicos detalhados. Times de funcionalidades, por outro lado, podem normalmente trabalhar em paralelo. Eles encontram menores problemas de integração e podem consumir os requisitos dispostos no Backlog do Produto. Garantir a integridade e reutilização da arquitetura pode ser um desafio. Como regra geral, as empresas devem empregar Times de funcionalidades sempre que possível e usar Times de componentes apenas se forem os mais importantes.

3.1.2.3 Erros comuns na escolha do Product Owner

Contratar o Product Owner certo pode ser difícil. Aqui, uma lista de erros comuns:

  • O Product Owner impotente
  • O Product Owner com excesso de trabalho
  • O Product Owner parcial
  • O Product Owner distante
  • O Product Owner substituto
  • O comitê do Product Owner

No curso avançado, entraremos em detalhes acerca dos erros.

3.1.3 O Scrum Master

O Scrum Master do programa é um facilitador que assegura que todos os times de projeto no programa tenham um ambiente propício para a conclusão bem-sucedida de seus projetos.

O Scrum Master do Programa guia, facilita e ensina as práticas do Scrum para todos os envolvidos no programa.

  • Providencia orientação aos Scrum Masters de projetos individuais
  • Esclarece impedimentos para os diferentes times de projetos
  • Coordena junto ao Corpo de Orientação do Scrum no sentido de definir objetivos relacionados à qualidade, regulações do governo, segurança e outros parâmetros-chave da organização.
  • Garante que os processos Scrum estão sendo efetivamente seguidos ao longo do programa.

O Scrum Master do programa se interliga ao Scrum Master do Portfólio para garantir o alinhamento entre o programa e os objetivos e metas do Portfólio. Ele ou ela está envolvido também com a nomeação de Scrum Masters para projetos individuais e com a garantia de que a visão, objetivos, resultados e lançamentos dos projetos individuais dentro do programa se alinham com os do programa.

Projetos maiores requerem vários Times Scrum para trabalharem em paralelo. Informações obtidas por um time devem ser comunicadas propriamente para outros Times – O Scrum Master Chefe é responsável por esta atividade.

A coordenação entre vários Times Scrum que trabalham num mesmo projeto é tipicamente realizada através das Reunião do Scrum dos Scrums (SoS). Isto é análogo à Reunião Diária em pé e é um facilitada pelo Scrum Master Chefe, que é tipicamente responsável por lidar com impedimentos que afetem mais de um Time Scrum.

3.1.4 O Time: Observe o capítulo 4

Use the promo code: pofacademy10 and get 10% discount for the International Agile Product Owner Foundation Certification