Artigos Engenharia de Software Elaboração do contrato com Product Backlog

Por que eu devo ler este artigo:Neste artigo iremos falar sobre o Product Backlog, que pode ser explicado como se fosse uma linha de base do escopo do produto, ou seja, são todos itens os quais compõem o produto a ser desenvolvido e entregue. Além disso também é composto por itens já finalizados (entregues). Mas, fica a dúvida de qual a melhor forma de compor este Product Backlog de maneira que fique clara a sua origem e composição e como deverá ser mantido. O contrato firmado pode servir como base para o Product Backlog. Mas, como surge um contrato e qual sua relação com o Product Backlog? Apresentaremos neste artigo uma abordagem mais prática sobre o uso do Scrum desmistificando este tema. Desta forma, vamos entender o processo que é necessário para gerá-lo de forma que sua equipe de desenvolvimento esteja afinada, tanto com a necessidade do cliente como também com a estratégia da empresa.

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 ...

Quer ler esse conteúdo completo? Tenha acesso completo