Scrum - Projetos Ágeis e Pessoas Felizes

Cesar Brod

Capítulos

Prefácio da 3ª edição (rolling edition)

Embarcando na viagem ágil, por Cláudio Machado

Prefácio da 2ª edição

Dos pesquis aos bahs e tchês, passando pelas Cataratas do Iguaçu, por Carolina Borim

Prefácio da 1ª edição

Duas cesarianas no mesmo dia, por Franklin Carvalho

Parte I

Para entender o Scrum

Parte II

A prática do Scrum

Parte III

Aprimorando o Scrum

Parte IV

Outros usos do Scrum

Parte V

Dinâmicas Ágeis

Posfácio

A resposta é 42

4.2.6 – Quem é o Product Owner?

Respondendo diretamente, é o principal responsável pelo produto. O Product Owner designado para o Scrum, caso não seja o cliente final, deve ter plena consciência de sua representatividade e responsabilidade, ser o mestre do domínio do produto em desenvolvimento. Em todo e qualquer projeto, criamos algo visando a um público cliente. Raríssimas vezes investimos na criação de algo que atenderá, apenas, a nós mesmos. Assim, é normal na construção de um Product Backlog que ele seja alimentado a partir de pesquisas diretas com os potenciais consumidores ou beneficiários de nosso projeto ou produto. O Product Owner deve ser capaz, a cada revisão de um Sprint, de incorporar a alma coletiva do cliente final.

O Product Owner é também quem paga diretamente o desenvolvimento do produto, ou é responsável pelo orçamento de um grupo de investidores no projeto. Ele tem a palavra final e é quem dá o aceite final às entregas nas revisões de Sprint. Aqui não tem balela, nem choro nem vela. O Product Owner pode ter errado na definição de uma história que entrou no Sprint Backlog e ele deve ser plenamente alertado de seu erro, mas, se ele não aceitar a história, ela não está completa: será redefinida e encaixada em um próximo Sprint. Isso não é tão horrível quanto parece. Especialmente, no início de um projeto, todo mundo chuta muito. Todos têm uma ideia absolutamente inexata do que desejam. É por isso que os Sprints iniciais são de muito ajuste, negociação. O Product Owner deve entender que errou na sua definição, que houve um investimento na construção daquilo que foi construído errado, mas ele não deve se contentar em passar ao cliente a sua incompetência. A equipe Scrum, por sua vez, mesmo apontando a definição inicial equivocada, não deve condenar o Product Owner, mas auxiliá-lo na construção do que será o perfeito resultado final. Se o Scrum foi bem vendido ao grande patrocinador, isso não é tão difícil quanto parece. Independentemente de qualquer coisa, depois do segundo Sprint, essa negociação vai ficando bem fácil.

O espaço para o erro é uma das principais razões de mantermos curta a duração do Sprint. Devemos falhar rapidamente, evitando nos prolongarmos nos erros. O custo de um erro que perdura por uma semana é infinitamente menor do que aquele que é levado ao longo de todo o projeto.

 

Capítulos

Prefácio da 3ª edição (rolling edition)

Embarcando na viagem ágil, por Cláudio Machado

Prefácio da 2ª edição

Dos pesquis aos bahs e tchês, passando pelas Cataratas do Iguaçu, por Carolina Borim

Prefácio da 1ª edição

Duas cesarianas no mesmo dia, por Franklin Carvalho

Parte I

Para entender o Scrum

Parte II

A prática do Scrum

Parte III

Aprimorando o Scrum

Parte IV

Outros usos do Scrum

Parte V

Dinâmicas Ágeis

Posfácio

A resposta é 42

Utilizamos cookies para melhorar a sua experiência em nosso site. Para mais informações, visite nossa Política de Privacidade.