Conheça o processo Criar os Entregáveis - SBOK SCRUMstudy

Conheça o Processo Criar os Entregáveis no Gerenciamento Ágil de Projetos

Conheça o Processo Criar os Entregáveis no Gerenciamento Ágil de Projetos

Neste artigo, apresentaremos o processo Criar os Entregáveis, da fase Implementar do Scrum de acordo com o Scrum Body of Knowledge, da SCRUMstudy. A fase Implementar é composta por 3 processos. Além da fase Impelemtar, existem ainda outras 4 fases: Iniciar, Planejar e Estimar, Revisão e Retrospectiva e Release.

Propósito do Processo Criar os Entregáveis

Criar os entregáveis é executar o Sprint, é construir os incrementos de produto que formaram a entrega final. A cada Sprint é entregue um pedaço funcional, que agrega valor, do todo. É um processo que depende principalmente da equipe de desenvolvimento, mas que sem a ajuda do Scrum Master na remoção de impedimentos e no mantenimento dos processos Scrum, não é possível.

Carreiras Site Campus

O Dono do Produto também tem um papel fundamental neste processo, que é o de representar a Voz do Cliente e manter o backlog do produto atualizado e refinado para que a equipe de desenvolvimento faça o trabalho que precisa ser feito e nada mais.

Conheça o Processo Criar os Entregáveis no Gerenciamento Ágil de Projetos

Entradas

Time Central do Scrum*

Entrada obrigatória neste processo!

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Backlog do Sprint*

Já descrito no artigo sobre o processo Criar o Backlog da Sprint, clique aqui para conferir.

Entrada obrigatória neste processo!

Scrumboard*

Já descrito no artigo sobre o processo Criar o Backlog da Sprint, clique aqui para conferir.

Entrada obrigatória neste processo!

Registro de Impedimentos

Antes de falarmos de impedimentos, vamos entender o que é um problema: um problema é algo que pode ser resolvido pela equipe de desenvolvimento. Resolver problemas, é para isso que formamos equipes. Resolver problemas é o que nos dá trabalho! É o que faz com que projetos existam em primeiro lugar!

Assim, problemas são coisas positivas, porque resolvendo eles alcançamos soluções. Mas, por outro lado, impedimentos não são positivos. Impedimentos nos distanciam da solução dos problemas. Se um programador precisa de um computador e a área de compras da empresa não comprou o PC, então isso é um impedimento porque o programador não vai poder resolver problemas por meio de sua programação.

Tratamos impedimentos para que o time possa resolver problemas. Todos impedimentos devem ser tratados pelo Scrum Master e registrados de alguma forma. Geralmente a equipe identifica estes impedimentos e coloca no Scrumboard, para que todos possam ver. Isso é ser transparente. Desta forma, o Scrum Master pode ver o impedimento e tratar ele. Esta é uma das principais tarefas do Scrum Master: remover impedimentos.

Cronograma de Planejamento da Release

Já descrito no artigo sobre o processo Conduzir o Planejamento da Release, clique aqui para conferir.

Dependências

Já descrito no artigo sobre o processo Criar as Tarefas, clique aqui para conferir.

Recomendações do Scrum Guidance Body

Já descrito no artigo sobre o processo Criar a Visão do Projeto, clique aqui para conferir.

Ferramentas

Expertise do Time*

Para criar produtos complexos, só há uma coisa sem a qual não podemos passar: uma equipe de desenvolvimento que saiba o que está fazendo. Sem o conhecimento técnico da equipe, não é possível construir qualquer produto. Assim, a expertise do time é o que vai transformar ideias em resultados. O Dono do Produto e o Scrum Master não necessariamente precisam dominar a área do escopo do produto, mas este não é o caso quanto a equipe de desenvolvimento.

A expertise do time vai se manifestar por meio da realização das tarefas, que criarão as histórias de usuário e os épicos – levando o projeto do zero até as releases planejadas. A equipe de desenvolvimento tem a liberdade para definir como irá trabalhar e a responsabilidade para fazer isso.

Ferramenta obrigatória neste processo!

Software

Toda e qualquer ferramenta necessária para a construção das entregas planejadas, incluindo ferramentas de colaboração e desenvolvimento. Skype, por exemplo, pode ser uma ferramenta de trabalho – assim como Word, Excel, um compilador de códigos ou um programa para criação de maquetes eletrônicas.  Podemos também considerar ferramentas não eletrônicas.

Outras Ferramentas de Desenvolvimento

Diversas ferramentas podem ser utilizadas. Se mantivermos o foco no desenvolvimento de software, ainda podemos considerar as seguintes:

Refactoring

De acordo com o SBOK, refactoring é uma ferramenta específica para projetos de software. O objetivo desta técnica é o de melhorar a manutenção do código existente e torná-lo mais simples, mais conciso, e mais flexível. Refactoring significa melhorar o design do código atual, sem alterar a forma como o código se comporta. Envolve o seguinte:

  • Eliminar código repetitivo e redundante
  • Dividir métodos e funções em rotinas menores
  • Definir claramente as variáveis e os nomes dos métodos
  • Simplificar o design do código
  • Tornar o código mais fácil de se entender e de se modificar

Padrões de Design

Os Padrões de Design fornecem uma maneira formal de registro de uma resolução, para um problema de design em uma área de especialização específica. Esses padrões registram tanto o processo usado quanto a resolução atual, o que pode ser reutilizado mais tarde para melhorar a tomada de decisão e produtividade.

Expertise do Scrum Guidance Body

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Saídas

Entregável do Sprint*

Mais resumido do que está no SBOK, impossível:

No final de cada Sprint, um incremento do produto ou um entregável é concluído. O entregável deve possuir todas as características e funcionalidades definidas nas História de Usuário incluídas no Sprint e devem ter sido testadas com sucesso.

Para conseguir entender de fato o que é um entregável, é preciso conhecer a noção de história de usuário, épicos e tarefas – além dos critérios de aceitação e a definição de pronto. Se isso te deixa em dúvida, revise os artigos anteriores e principalmente os artigos da fase Planejar e Estimar.

Saída obrigatória neste processo!

Scrumboard Atualizado*

Analise o modelo de Scrumboard abaixo e perceba como ele é dividido em etapas. Uma vez que algum membro da equipe de desenvolvimento conclua uma tarefa ou história de usuário, pode levar ela para a coluna de “testes” ou até mesmo “pronto”. Assim, a evolução do trabalho é visível para todos e pode ser acompanhada por meio do quadro Scrum, ou Scrumboard. Mantê-lo atualizado é quase que um esforço natural por parte da equipe de desenvolvimento.

Conheça o Processo Criar os Entregáveis no Gerenciamento Ágil de Projetos

Saída obrigatória neste processo!

Registro de Impedimentos Atualizado*

Neste mesmo artigo, falamos sobre o que são impedimentos e o que são problemas. Manter o registro de impedimentos atualizado é uma tarefa do Scrum Master. Mais do que manter um registro atualizado, contudo, é preciso trabalhar para remover impedimentos. O Scrum Master blinda o time e também garante que ele tenha o que precisa para fazer seu trabalho. Um líder-servidor vai garantir que todos consigam atingir seu máximo potencial.

Saída obrigatória neste processo!

Solicitações de Mudança Não Aprovadas

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Riscos Identificados

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Mitigação de Riscos

Imagine que você está em um barco e sabe que ele tem um furo. Você pode continuar sua jornada com aquele furo, sem cobrir ele, e isso seria aceitar o risco de afundar. Agora imagine que você decide remover toda água que entre pelo buraco com um balde. Isso seria mitigar o risco, porque você diminui seu impacto. Ainda há outra alternativa: você decide arrumar o buraco e, desta forma, eliminar o risco. Por fim, poderia ainda contratar uma empresa de seguro para caso o barco afunde, você seja ressarcido. Esta alternativa final é a transferência do risco.

Expliquei de forma simples todas as estratégias possíveis para os riscos identificados. Para todos estes, o Dono do Produto terá de elaborar estratégias – não apenas de mitigação. Ele pode contar com apoio direto da equipe de desenvolvimento e do Scrum Master, mas é responsabilidade dele buscar por processos de gerenciamento de riscos e integrar os riscos e suas respostas ao backlog do produto.

Dependências Atualizadas

Já descrito no artigo sobre o processo Criar as Tarefas, clique aqui para conferir.

Deixe seus comentários!

#
Compartilhe!
Fale com o Site Campus!

Tags: , , , ,