Uma gura importante no desenvolvimento ágil de produtos é o cliente, que é um dos maiores influenciadores e afetados pelo projeto.
Juntamente com o PO, o Scrummaster pode contribuir para que o cliente entenda a importância dos trabalhos conjuntos com o PO e do fornecimento de todos os detalhes e informações necessárias para que o PO e o Time entendam perfeitamente os requisitos do produto a ser construído. Essa função é própria do PO, mas o Scrummaster pode contribuir para que o trabalho seja mais bem entendido e realizado, tirando proveito das técnicas e ferramentas do Scrum. Outro apoio é no entendimento do cliente quanto à documentação necessária e não extensa ou inútil. O gerenciamento ágil prega a documentação necessária para se entender o produto e busca o não desperdício de tempo com documentação extensa e desnecessária. Nesse ponto o Scrummaster pode contribuir muito para que o cliente entenda o real objetivo de uma documentação correta e objetiva.
Product Owner
Nesse momento o trabalho do Product Owner aparecerá como em nenhum outro momento, pois será a hora de o PO apresentar todo o seu entendimento a respeito do backlog do produto que foi montado em conjunto com o cliente.
A tarefa principal do PO durante do planejamento da Sprint é passar o seu conhecimento adquirido a respeito do produto a ser desenvolvimento e fazer com que o Time passe a ter o mesmo entendimento que ele e o cliente, e possa, a partir desse entendimento, determinar como construirá um produto que agregará valor ao cliente.
fornecendo todas as informações necessárias para que o Time consiga determinar “como” fará o trabalho para entregar o esperado.
As responsabilidades do PO passam por trazer as histórias listadas para a reunião de planejamento da Sprint, bem como artefatos complementares para o entendimento dessas histórias, tais como documentos de requisitos, especi cações, casos de uso, wireframes, protótipos, modelos, exemplos, entre outros artefatos que possam servir de insumo e de apoio para que o Time compreenda da melhor maneira possível o que será trabalhado na próxima Sprint.
A seleção inicial do que será trabalhado na Sprint vem do PO, assim como a priorização do que deverá ser construído primeiro – essa é uma tarefa de exclusividade do PO e nenhum outro papel deve assumir tais seleções e priorizações.
Por m, o PO deve estar pronto para responder qualquer questionamento do Time a respeito de detalhes importantes sobre o backlog do produto e sobre a seleção e de nição do backlog da Sprint. Caso o PO não tenha todas as respostas nesse momento, este também deverá ser o responsável por buscá-las, especialmente aquelas ligadas ao negócio do cliente, e trazê-las para o Time o mais breve possível.
Na prática, nesse momento, o PO apresenta cada uma das histórias, descrevendo os detalhes necessários para que o Time entenda como cada história irá se transformar em uma parte funcional do produto.
A responsabilidade do PO é especialmente com relação aos entendimentos do negócio e do valor esperado pelo cliente ao receber o produto construído. Alguns aspectos técnicos podem ser trazidos pelo PO, porém as de nições técnicas e como o produto será construído tecnicamente são de responsabilidade do Time e não do PO.
Se o PO for o cliente, melhor será o entendimento do produto e de suas necessidades. O único requisito é que o PO (cliente) esteja sempre disponível para o Time de Desenvolvimento, e isso inclui participar da reunião de planejamento da Sprint e de outras que ocorrerão ao longo do projeto.
O Product Owner deve participar da reunião de planejamento da Sprint.
Nessa etapa do planejamento, o Time de Desenvolvimento deve focar seus esforços no entendimento do que será trabalhado na próxima iteração para completar o objetivo da próxima Sprint.
O PO tem o entendimento do backlog do produto até o momento, mas o Time de Desenvolvimento deve ser capaz de transferir o entendimento do PO para si e determinar como construirá o produto e entregará o valor esperado pelo cliente.
Com as informações em mãos, ou, melhor dizendo, na cabeça, o Time de Desenvolvimento entende as histórias apresentadas pelo PO e determina o esforço necessário para constuir uma parte do produto com base em cada uma das histórias conhecidas.
Com o entendimento, o Time prevê o tamanho das histórias e quebra todas elas em tarefas menores para que seja possível estimar com mais precisão o conteúdo da próxima Sprint.
O Time de Desenvolvimento é o único responsável pelas de nições técnicas e por determinar como irá trabalhar nas histórias. O PO repassa o entendimento de negócio referente a cada história, mas somente o Time de ne como irá trabalhar tecnicamente para construir cada história, tomando decisões ligadas a arquitetura, linguagens, modelagens, codi cações, tecnologias e outras características que irão in uenciar o conteúdo técnico que irá compor uma entrega futura.
O PO apresenta uma história que fala sobre transferir alguns dados do sistema do cliente para outro sistema de um grande banco internacional. O PO traz as regras que in uenciarão na transferência – por exemplo, todos os dias às dez horas da noite uma transferência de dados ao banco deve ser iniciada com todos os pagamentos realizados dentro daquele dia.
O Time de Desenvolvimento, ao entender esta história, de ne por conta própria como irá realizar a implementação da história – por exemplo, utilizando um webservice disponibilizado pelo banco e construindo um serviço que irá rodar no sistema operacional e disparará todos os dias às dez horas da noite o chamado ao webservice.
Perceba os limites de cada papel e suas responsabilidades: o PO apresenta ao Time de
Desenvolvimento “o que” deve ser feito e o Time de Desenvolvimento define “como” irá realizar o trabalho para entregar a necessidade solicitada.
As previsões de tempo e esforço também são unicamente exclusividade do Time de Desenvolvimento, pois apenas quem irá desenvolver tem condições de estabelecer estimativas,
sejam elas de tempo ou esforço.
No caso das estimativas, o PO pode in uenciar o Time de Desenvolvimento no que diz respeito às prioridades, puxando ou empurrando histórias mais ou menos priorizadas de acordo com as estimativas de esforço apresentadas pelo Time de Desenvolvimento, mas nunca determinar qual é essa estimativa, passando por cima da definição do próprio Time de Desenvolvimento.
6. Executando a Sprint
O Time de Desenvolvimento coloca o cialmente a mão na massa e começa a construir o produto do projeto na fase de execução (também conhecida como etapa de desenvolvimento). Essa fase é marcada principalmente por ser o momento em que o Time põe em prática o planejamento realizado nas etapas iniciais, especialmente o realizado no planejamento da Sprint.
“Colocar a mão na massa” é uma expressão utilizada para representar as atividades especí cas da etapa de desenvolvimento e as tarefas que o Time realizará para construir propriamente o produto do projeto.
No Scrum, trata-se exatamente do momento entre a reunião de planejamento da Sprint e a reunião de revisão da Sprint.
Ao mesmo tempo em que o Time arregaça as mangas, oportunidades de inspeção surgem naturalmente e permitem que o Time monitore o seu próprio andamento e tenha uma percepção real da evolução dos trabalhos que está realizando.
Essa inspeção é parte da auto-organização do Time, conhecido também como microgerenciamento, que permite, além dessa pequena autogestão, um acompanhamento próprio para uma melhoria contínua constante.
A etapa de desenvolvimento é marcada também pelo início do monitoramento do avanço do projeto, que visa colher evidências do progresso das atividades e da comunicação dessas informações às partes interessadas do projeto.
Essas inspeções constantes permitem correções, adaptações e replanejamentos mais curtos.
Você sabia que, ao contrário do que muitos pensam, há mais tempo investido em planejamento nas abordagens de gerenciamento ágil do que nas tradicionais?
É verdade! No gerenciamento tradicional o planejamento é maior no início e bem menor durante a execução do projeto. Já no ágil as etapas de planejamento são quase constantes ao longo de todo o projeto, sendo menores em duração contínua, porém bem mais frequentes.
Vamos agora entender como essa fase funciona e como os papéis do Time, do PO e do Scrummaster trabalham em conjunto para construir o produto da próxima entrega e unem forças em direção ao mesmo objetivo:
Entregar valor o mais breve possível para o cliente.
A gura a seguir destaca em preto em que etapa do ciclo Scrum o uxo de desenvolvimento de produto se encontra e qual é a cerimônia principal do Scrum que o Time irá trabalhar.
Figura 12