Equipe Ágil

Os diferentes papéis em uma Equipe Ágil – SCRUM

Agora que você já leu meu primeiro artigo da série sobre “Desenvolvimento Ágil de Software”, vamos conhecer os diferentes papéis e responsabilidade de cada um em uma equipe ágil. Assim como existem diversas metodologias ágeis, como: Scrum, Kanban, XP, etc.. Vamos focar a série de artigos em Scrum, pois é a mais utilizada no mundo e em minha opinião a metodologia mais recomendada para aqueles que estão começando com seus times no mundo ágil, vamos ao papéis.

Scrum Master

O Scrum Master é o que chamamos de líder servidor (servant leader), ele é o guardião das práticas Scrum e deve assegurar que todos os envolvidos diretamente no projeto saibam como aplicá-las corretamente. Ele é responsável por disseminar conhecimento sobre o método de trabalho, por assegurar a evolução do time, apoiando o aprendizado multi-funcional e a auto-organização. Este modelo permite o aperfeiçoamento constante das habilidades e capacidades de todo o time, p O que vem a ser líder servidor? O líder servidor atua fundamentalmente para o sucesso do time e não em benefício próprio, ele tem de ser um verdadeiro líder para estar nesta função, buscando facilitar o trabalho dos integrantes da equipe, resolvendo problemas, removendo obstáculos que impeça a evolução do trabalho e o progresso do time, além de eliminar conflitos que venha a existir. Eu destaquei as principais características do Scrum Master, existem outras, abaixo um resumo de suas responsabilidade:

  • Permitir estreita cooperação entre todos os papéis e funções
  • Remover obstáculos e proteger a equipe de distrações
  • Trabalhar com a organização para acompanhar o andamento do projeto e fazer ajustes necessários na estrutura ou processos da organização
  • Garantir que as práticas ágeis estão sendo seguidas, incluindo reuniões diárias (stand-ups), reuniões de planejamento, de demonstração e de revisão, e retrospectivas
  • Facilitar reuniões de equipe e reuniões de tomada de decisão

Product Owner

O Product Owner é responsável pelo produto e pelo ROI do projeto, ele basicamente faz a interface entre o cliente e o time, isso faz com que o papel do Product Owner seja um fator crítico de sucesso. O Product Owner tem que trabalhar alinhado com o time, caso contrário os objetos não serão alcançados. É muito comum em qualquer tipo de projeto, seja software, industrial, marketing e outros notarmos que os cliente tem dificuldade em expressar suas necessidades, quando fazem mudam com frequência e geralmente a entrega tem de ser para ontem. Por outro a equipe que irá desenvolver o projeto não entendem o que está sendo solicitado e muitas não querem entender, com isso dificilmente atende as necessidades e para finalizar adicionamos a dificuldade na comunicação e entendimento com o cliente. O Product Owner é a interface entre o cliente e sua equipe, aquele que está no papel de Product Owner necessita ter uma grande habilidade de comunicação, pois deverá traduzir os requisitos de negócio em uma linguagem que a equipe entenda, além de avaliar e priorizar o que deverá ser feito com base naquilo que traz mais valor. A questão do valor é algo chave em métodos ágeis e pretendo falar sobre isso mais adiante. Abaixo as responsabilidades do Product Owner:

  • Definir os requisitos e priorizar o seu valor
  • Determinar a data de lançamento (release date) e conteúdo
  • Ter um papel ativo nas reuniões de iteração e planejamento do release
  • Garantir que a equipa está sempre trabalhando sobre os requisitos mais valiosos
  • Representar a voz do cliente
  • Aceitar as histórias (stories) que satisfaçam a definição de pronto (DONE) definida pela equipe e os critérios de aceitação definidos pelos product owner e/ou cliente

Scrum Master, Product Owner e time juntos

Quanto colocamos todos juntos temos o que você pode ver na figura abaixo, SCRUM recomenda que para se obter maior produtividade o tamanho da equipe pode variar de 5 à 9 pessoas, o que chamamos de 7 [+/-2], onde temos um Product Owner, um Scrum Master e o restante do time. Existem diversas opiniões com relação ao tamanho ideal, como Jurgen Apello por exemplo que sugere o tamanho ideal como 5, entre ele adverte que ao invés de seguir a recomendação do tamanho da equipe, as equipes devem primeiro tentar se auto-organizar e gradativamente chegar a uma equipe de tamanho ideal.

No próximo artigo vamos conhecer como os times ágeis planejam seu trabalho.

4 respostas
  1. Eduardo Flaeschen
    Eduardo Flaeschen says:

    Caro Andreano,
    Estou iniciando a leitura de seus artigos e gostando muito, parabéns, tem sido de muita utilizada para a minha atualização. Sou desenvolvedor Delphi desde a 1ª versão e agora no Delphi 2009, estudando as possibilidades para migração para XE3. Mais uma vêz, parabéns !
    Se me permite uma sugestão: algumas pessoas do meu time são iniciantes e estou recomendando enfaticamente a leitura de seus artigos mas eles, e eu também em alguns casos, estão enfrentando dificuldades com algumas abreviaturas, a famosa sopa de letrinhas do “informatiques”. Assim, sugiro que coloque entre parênteses o significado delas, com certeza vai ficar ainda mais didático.
    Obrigado,
    Eduardo

    Responder

Deixe uma resposta

Quer participar da discussão?
Fique a vontade para contribuir!

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>