q
Podemos dizer que o Product Owner é um analista de negócio e um profissional com conhecimento nas duas pontas: no negócio do cliente e na tecnologia. Tem como principal objetivo representar os interesses do cliente com a equipe técnica. Funciona, portanto, como uma interface entre o cliente e a equipe de desenvolvedores, e deve estar sempre em contato com o cliente para saber o que precisa ser feito no projeto para satisfazer o negócio.
Juntamente com os outros envolvidos, ele é o responsável por listar as prioridades e os requisitos, além de revisar e aprovar as entregar no final de cada Sprint.
q
Mais detalhadamente, ele tem as seguintes responsabilidades: 1 Definir os requisitos e funcionalidades de produto;
1 Decidir sobre data de lançamento e término; 1 Ser responsável pela rentabilidade do produto (ROI);
1 Priorizar as funções de acordo com a necessidade atual do cliente;
1 Ajustar recursos e priorizar tarefas a cada ciclo, geralmente de 30 em 30 dias, como necessário;
1 Aceitar ou rejeitar o resultado do trabalho.
Scrum Master
q
É o líder da equipe de desenvolvimento, geralmente o programador ou analista de sistemas mais experiente da equipe. É responsável por garantir a aplicação das práticas do Scrum, assim como repassar os ensinamentos da metodologia para os outros membros do projeto. Gerencia e delega as atividades que foram definidas durante o planejamento pelo Product Owner.
Suas principais responsabilidades são:
1 Assegurar-se de que a equipe de desenvolvimento funciona plenamente e é produ- tiva, intermediando a comunicação entre a equipe e o Product Owner;
1 Assegurar-se de que a metodologia está sendo seguida;
1 Conduzir reuniões diárias e reuniões de planejamento de atividades; 1 Revisar atividades, tendo conhecimento das que foram concluídas e das que
foram iniciadas;
Veremos esse termo em detalhes no tópico de Artefatos.
Ca pí tu lo 3 - A me to dolo gi a
q
1 Identificar novas tarefas, priorizá-las e alterar qualquer estimativa que possa ter mudado. Isso permite a ele atualizar sempre o Burndown Chart (veremos esse termo em detalhes no tópico de Artefatos);
1 Tomar ações para tarefas em aberto e computar quantas tarefas estão em aberto com o objetivo de minimizá-las o máximo possível para garantir um trabalho eficiente; 1 Avaliar as pendências e obstáculos que causam prejuízos ao andamento do projeto.
Essas pendências e obstáculos devem ser listados, para receber níveis de prioridade e ser acompanhados com o objetivo de minimizá-los o mais rapidamente possível, a fim de serem solucionados. Um plano de ação deve ser implementado de acordo com a ordem de prioridade desses impedimentos. Alguns podem ser resolvidos pelo time, outros através de vários times, e outros precisam do envolvimento da gerência ou até do cliente, pois podem ser problemas que não são da alçada da equipe e, portanto, podem correr o risco de causar um bloqueio no andamento do projeto;
1 Efetuar a gestão das pessoas, percebendo e resolvendo problemas pessoais ou conflitos entre os integrantes do time do desenvolvimento Scrum. Caso o Scrum Master não consiga resolver algum tipo de problema, deve solicitar ajuda à gerência ou do depar- tamento de Recursos Humanos. Alguns estudos apontam que 50% dos problemas de desenvolvimento acontecem por razões pessoais, então o Scrum Master precisa estar sempre atento ao time para maximizar a produtividade e motivação da equipe.
Equipe de desenvolvimento
q
Também conhecida como Scrum Team, correspondem aos membros encarregados por realizar as atividades de projeto. Ou seja, são aqueles que vão efetivamente colocar a mão na massa para que o projeto se concretize.
Suas principais atividades são organizar e gerenciar suas próprias atividades. e geral- mente estão integralmente dedicados ao projeto. Dependendo da complexidade do sof- tware, um projeto pode ter mais do que uma equipe de desenvolvimento. No entanto, a troca de equipe só deve ocorrer na mudança de ciclo.
Suas principais características são: 1 Multifuncional e auto-organizável;
1 Pequenas e multidisciplinares, com até 10 participantes;
1 Definem metas a cada Sprint, junto com o Scrum Master, e especificam seus resul- tados de trabalho;
1 Têm como responsabilidade principal entregar o bloco (Sprint) no tempo determi- nado e com o mínimo de erro possível;
1 Têm o dever de respeitar as regras da metodologia; 1 Devem sempre manter o senso de equipe.
Como já falamos, por ser multifuncional, a equipe de desenvolvimento Scrum deve ser composta por profissionais dos mais variados perfis, incluindo, mas não se limitando a: 1 Programadores;
1 Testadores; 1 Analistas;
1 Desenvolvedores de interfaces; 1 Administradores de bancos de dados.
Fu nd ame nt os d o S cr um
q
Na prática, a diferença entre uma equipe não multifuncional é que na primeira, como podemos visualizar na figura 3.1, o projeto anda mais rápido, pois profissionais de dife- rentes especialidades trabalham juntos para cumprir uma tarefa. O sentido de equipe é exatamente esse – os membros compensam entre si as competências e as carências, em um aprendizado mútuo e contínuo.
Time não Multifuncional
Time Multifuncional Sprint 1 Análise Código Código Código Sprint 4 Código Testa Sprint 5 Testa Testa Testa Testa
Análise Análise Análise
Sprint 2 Código Análise Sprint 3 Código Testa Análise
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Cerimônias
q
A equipe também tem a responsabilidade de participar das cerimônias. Essas são reuniões que ocorrem em diversos momentos durante o projeto. O método é dividido sucintamente em basicamente três cerimônias principais, a saber:
1 Reuniões de Planejamento da Sprint (Planning Meetings); 1 Reuniões Diárias de Scrum (Daily Meetings);
1 Reunião de Revisão da Sprint (Sprint Retrospective).
Esses três tipos de evento caracterizam bem o ciclo de vida de cada Sprint, que possui início, meio e fim.