Quando o assunto é o Product Backlog, por muitas vezes não fica tão claro quando e como surge o Product Backlog. Outro ponto que não fica muito claro é quando o Product Backlog deve ser revisto e mantido. O Product Backlog existe para dar visibilidade do que e quando será entregue.
Os métodos Ágeis querem viabilizar a construção de um software, o qual atenda às expectativas de todos, deve ser feito através do contato direto entre a equipe de desenvolvimento e o próprio solicitante (cliente).
Em se tratando de Scrum, existem quatro elementos que possuem seus papéis e responsabilidades bem definidos: Scrum Master, Product Owner, o Time de desenvolvimento e, consequentemente, o cliente.
Scrum Master pode ser definido como o Tutor, aquele que irá ensinar e garantir que todos os envolvidos no processo de desenvolvimento de software entendam e adotem o modo ágil nas suas atividades. A atividade de treinamento será uma das principais responsabilidades do Scrum Master. Além disso, o Scrum Master também deverá proteger a equipe dos desvios resolvendo problemas que surjam, mais conhecidos como impedimentos. Seu perfil é o de Liderança Técnica e não de Gestor de Projetos. Além disso, o Scrum Master também deverá suportar a equipe de desenvolvimento e também o Product Owner, que é aquele que detém o conhecimento do Negócio, em suma, é o responsável por determinar o que deve ou não constar no Produto (Software) e, principalmente, é aquele que deverá determinar o Valor e Prioridade do que deve ser construído (desenvolvido) pela equipe de desenvolvimento. Como principal fonte de referência, o Product Owner deverá criar e manter o chamado Product Backlog (Lista de Itens do Produto).
O Product Owner pode ser interno ou externo à organização desde que seja o ponto focal perante a equipe de desenvolvimento e o Scrum Master. Um Product Owner interno à organização pode representar um grupo de usuários (clientes) da organização, mas também poderá ser o porta voz do cliente externo ou até, ser um representante do próprio cliente (externo).
Será o Product Owner o responsável por monetizar cada item do Product Backlog para que possa demonstrar o retorno do investimento realizado (ROI) a cada entrega e, mensurá-la conforme seu uso e evolução. Não obstante, o Product Owner também será o responsável em determinar o que e quando será desenvolvido para entrega do software (priorização). Além disso, deverá estar disponível para auxiliar no esclarecimento de dúvidas, participando das reuniões de definições, planejamentos e homologações das entregas.
Já a equipe de desenvolvimento (Time) são as pessoas que irão codificar (desenvolver) e testar o software (Produto). Devem possuir um perfil auto organizado e multidisciplinar, ou seja, os membros da equipe devem trabalhar juntos, organizando suas atividades, colaborando entre si e, não ficarem exclusivos à uma única atividade. É responsabilidade da equipe fazer o planejamento, orçamento, do esforço para construção do software e garantir que as entregas dos itens do Product Backlog ocorram dentro dos prazos e da qualidade esperada, conforme estabelecido pelo Product Owner.
Seria ótimo poder abordar novamente todo o contexto e a dinâmica do método Scrum porém já o fizemos em outras oportunidades aqui na Revista Engenharia de Software então, vamos focar no tema Product Backlog e Contratos. Diante do exposto anteriormente, podemos perceber que o ponto de origem das demandas de desenvolvimento a serem construídas pela equipe, quando estamos utilizando o método Scrum, são os itens do Product Backlog.
Mas, o que gera o Product Backlog? Podemos dizer que o Product Backlog é composto por um conjunto de necessidades as quais, quando implementadas em um software, agregam valor ao negócio da empresa (seja a partir de uma área funcional da empresa ou de um cliente externo).
Um artefato que é de conhecimento geral é o contrato. Contrato, segundo a definição, é o ato ou efeito de contratar; acordo feito entre duas ou mais pessoas com a obrigação de fazer ou não fazer alguma coisa. Em um contrato, além de estabelecer o que deverá ser feito, temos ainda condições como: prazo, qualidade, remuneração, penalidades e multas.
Em consequência ao artefato contrato, ao estabelecermos um escopo de um projeto, sempre devemos tomar como base o cumprimento do contrato. Na verdade, o ideal seria que o Contrato tivesse surgido tomando como base o Plano de Projeto, conforme orienta o próprio PMBoK (PMI) mas, como estamos tratando de fatos reais, nem sempre a área técnica participa da definição da oferta e da geração do contrato restando apenas a opção de se gerar o Plano do Projeto a partir do Contrato
Infelizmente, nem sempre os contratos representam a realidade das condições como prazo, recursos, viabilidade
técnica. Não é raro ouvirmos estórias tais como que as condições do contrato são impossíveis de serem cumpridas, que
o prazo do contrato não é compatível com nossa capacidade, este item estava fora do escopo do projeto, mas consta no
contrato e agora? Novamente, vamos imaginar um cenário ideal onde estas questões eternas entre uma área comercial (a
qual vendeu um projeto) e a área técnica (responsável por entregar o projeto vendido) não exista. Talvez este artigo
também sirva de subsídios para que seja proposta uma nova dinâmica de trabalho entre as área ...
