Tag: Product Owner

Como vencer os impedimentos nos times Scrum

Publicado em por .

“Impedimento” é uma palavra com dois possíveis significados no dicionário da língua portuguesa. A primeira refere-se àquilo que impede, como um estorvo ou obstáculo, enquanto segunda se refere à posição irregular no futebol (Brasil sil sil ?).

No primeiro exemplo temos um significado que descreve muito bem o contexto que desejamos. Um obstáculo, ou seja, algo que deve ser ultrapassado para atingir um objetivo.
Já no segundo, podemos brincar lembrando que o “impedimento” de um jogador pode anular um gol, impedindo o bom desempenho do time.

Quando falamos de Scrum, o impedimento (impediment, em Inglês) é citado no guia duas vezes, sendo uma para o papel Scrum Master e outra para o evento Daily Scrum:

Entenda como o Scrum Master ajuda o time:

Removing impediments to the Development Team’s progress;

Descrevendo a Daily Scrum:

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

O que é um impedimento?

Impedimento é qualquer fator que impeça ou retarde o time de realizar o trabalho. Com isso, o impacto é bem nítido na queda da produtividade e/ou velocidade do time.
Outra maneira de definir seria qualquer problema que vai além da auto-organização do time.

Mas afinal, quem remove impedimentos ?
O papel no Scrum que é responsável pela remoção de impedimentos é do Scrum Master, conforme citado acima, pois ele sempre está presente, conectado com o time e com o ecossistema corporativo.

Um bom Scrum Master tem a capacidade de distinguir o que é um bloqueio (que afeta uma tarefa, por exemplo) de um impedimento (que afeta o resultado da Sprint em geral) e além disso faz o rastreio desse impedimento, realiza uma facilitação entre áreas de negócio, assim como o remove definitivamente.

Faço um contraponto, colocando a responsabilidade também para o time de desenvolvimento, pois eles precisam se comunicar bem quando acontece um impedimento, assim como quando se tem um Scrum Master que empodera seus times ele deixa o próprio time correr atrás e remover o impedimento que está afetando o resultado final.

O impedimento terá proporções e até significados diferentes durante a curva de maturidade do time, vou dar alguns exemplos com a “curva de Tuckman”, lembrando que isso não é uma regra, mas acontece na maioria das vezes:

Durante o Forming (formação do time)

Pouco impedimento, tudo corre bem, o time ainda não entende o que é impedimento, mas como a meta das sprints não são atendidas e o BOM Scrum Master orientará o time. O time começará a reportar impedimentos timidamente.

Durante o Storming (“pau quebrando” ?)

Neste momento tudo é impedimento. “O P.O mandou um e-mail sobre uma história” o time já diz que é “impedimento”, troca de algum item do backlog (mesmo que tenha a mesma pontuação) o time dirá que é “impedimento, o ar condicionado não esta gelando bem = impedimento, o almoço não estava legal = impedimento, o outro time demorou 45 minutos pra responder uma dúvida = impedimento. Este é o momento que toda desculpa será chamada de “impedimento”.

Força Scrum Master isso vai passar mas, neste momento, um bom Scrum Master deve ser paciente e mentor.

Durante o Norming (time vivendo a realidade)

Neste momento os impedimentos que aparecerão serão mais pontuais e provavelmente precisarão da liderança, negociação e “jogo de cintura” do Scrum Master. Este time já resolve quase tudo por conta e quando dizem que tem um impedimento, o Scrum Master já entende que não é tempo de ser “mentor” e sim de ser “removedor”.

Durante o Performing (time voando)

Aqui quase não se vê impedimentos no board.

O time já conhece os processos e as pessoas, já articula bem a resolução de todos os itens simples e médios ficando para o Scrum Master apenas os obstáculos que envolvem: ego, negociação, politicagem, etc.

Mas, quais os principais tipos de impedimentos?

Segue abaixo um infográfico, onde destacamos alguns dos impedimentos mais comuns relacionados a : tecnologia, processo e pessoas:

Como conseguimos remover e tratar os impedimentos?

Seguem abaixo algumas dicas sobre remoção de impedimentos:

  1. Não espere a Daily Scrum para falar sobre um impedimento identificado, registre esse impedimento, chame o Scrum Master para que isso traga o menor impacto possível para a meta da Sprint;
  2. Usar objetivo da Sprint, se o impedimento não afeta a Sprint em questão, registre, mas não gaste esforços extras: Não gaste tempo na solução do problema errado!
  3. Melhorar a transparência, dêem visibilidade para todos, através de ferramentas e radiadores de informação (seu board, kanban etc.);
  4. Acompanhe e faça rastreabilidade de impedimentos fixos;
  5. Seja corajoso e criativo;
  6. Colaborem com o Product Owner;
  7. Usem o refinamento para se antecipar a impedimentos clássicos;
  8. Coloquem no DOR (Definition of Ready, em português “definição de preparado”). Deixem claro que PBI (item de backlog) que já possui um impedimento conhecido não deve entrar até o impedimento ser removido.
  9. Revisem os impedimentos conhecidos na planning. Caso algum PBI passe pelo refinamento não deixe entrar no Sprint Backlog.
  10. Esse 10 só entrou para ter 10 mesmo, como se fossem os 10 mandamentos.

Pesquisando sobre abordagem para lidar com impedimentos, achamos uma forma interessante, com 5 etapas: Confirmar, Triagem, Remover, Dar Visibilidade e Aprender (ConTROL):

Fonte: https://www.axisagile.com.au/blog/planning-and-metrics/incriminating-impediments/

Concluindo

Para identificar e remover impedimentos não existem varinha mágica ou bala de prata, por isso é sempre importante que uma vez identificado, todos se responsabilizem para correr atrás e remover o mais rápido possível.

Impedimentos nos levam a desperdício, e precisam ser eliminados em tempo real para não impactarem a produtividade do time.

Mas acredito que a dica de ouro é: tente se antecipar aos impedimentos conhecidos.

E aí, como vocês abordam seus impedimentos? Como os tornam visíveis? Vocês tem uma lista de impedimentos conhecidos?

Vamos discutir o tema com a comunidade; compartilhe, comente sua experiência, dê like no artigo para ele ganhar relevância e vamos falar sério sobre o tema.

Tem dúvidas sobre o mundo ágil? Conte pra gente!

—

Este artigo foi escrito pelos parceiros Ricardo Bruno, MBA, CSM, CSPO, SFC, CLF, CAC

e João Batista Santos – JB.

O que é o Scrum e como ele funciona dentro das organizações

Publicado em por .

O Scrum pode ser definido como um método ágil, como um framework voltado para dinamizar o processo de desenvolvimento e entrega de produtos de maneira incremental e iterativa. Não entendeu nada? Calma! Aqui neste texto você irá entender, por meio de uma linguagem simples, o que é o Scrum e como ele funciona dentro das organizações.

O Scrum

O Scrum é um método voltado para o desenvolvimento e criação de produtos complexos. Muitos estudiosos e pessoas que lidam com o Scrum, no entanto, preferem não chamá-lo de método, mas sim de framework.

Mas afinal, o que é um framework? Um framework é uma estrutura que se mantém pela coesão de seus próprios elementos. É uma espécie de moldura que delimita uma série de procedimentos interligados, que possuem uma dinâmica própria, que formam um “corpo”. Um framework, então, é uma forma de agir dentro de determinados parâmetros.

O Scrum é sim um conjunto de regras, mas um conjunto de regras voltadas para um jogo que está em constante mudança. Logo, uma das principais características do Scrum é a sua alta maleabilidade e adaptabilidade. 

Surgido no final da década de 1980 e com aplicação prática a partir da década de 1990, o Scrum busca dinamizar o processo de produção de produtos complexos. Inserido num movimento maior, fruto da crescente indústria de desenvolvimento de softwares, o Scrum é um dos frameworks do mindset Agile.

Não entraremos aqui em detalhes sobre o Agile, mas de forma rápida podemos dizer que ele é um conjunto de premissas e princípios. É um norte conceitual (mindset) que orienta diversos frameworks, como o Scrum, por exemplo. Para conhecer um pouco mais sobre o Agile, clique aqui.

Como funciona o Scrum

Como trouxemos, o Scrum é um framework desenvolvido no final dos anos 1980 voltado para o desenvolvimento de softwares.

Atualmente, no entanto, ele já é adotado por diversas equipes, empresas ou organizações que nada têm a ver com o desenvolvimento de softwares.

O Scrum nasce para tornar o desenvolvimento de projetos mais eficiente e adaptável, com foco na entrega do produto e não na burocracia do processo. Seu objetivo é fazer com que as pessoas trabalhem sempre com foco na melhoria contínua, de forma incremental e iterativa.

Vamos à tradução:

Incremental – de forma a incrementar o produto, ou seja, a cada dia entregar algo novo, uma parte do produto, que somado gerará o produto final.

Iterativa – é fazer as coisas de maneira iterada, ou seja, repetir determinadas ações de forma a nunca ficar parado.

Para tanto, o Scrum enquanto framework prevê a existência de papéis, eventos e artefatos, estabelecendo uma dinâmica entre eles.

Papéis

Os papéis são as tarefas desempenhadas por cada um dentro de um Time Scrum. Dentro de um Time Scrum existem os papéis do:

  • Product Owner – é o “dono do produto”. É a pessoa responsável por fazer com a equipe entregue o melhor produto possível, garantindo que todo Backlog (lista priorizada do que se deseja do produto) seja cumprido.
  • Time de Desenvolvimento –são times auto-organizados, compostos por desenvolvedores. São eles que, atuando de forma sinérgica, desenvolvem um produto. Não há hierarquia entre os componentes do Time de Desenvolvimento. O ônus e bônus do projeto são responsabilidades de todos. O ideal é que os times tenham mais de 3 e menos de 9 pessoas.
  • Scrum Master – é o profissional responsável por garantir que todos os envolvidos no desenvolvimento entendam e sigam as premissas do Scrum. Ele é ao mesmo tempo uma espécie de professor e de inspetor, que garante que tudo seja devidamente realizado dentro do framework Scrum.

Eventos

Os eventos são utilizados para criar uma dinâmica de funcionamento coerente e constante ao Time Scrum, sem a necessidade de reuniões não planejadas. Todos os eventos são time-boxed, ou seja, possuem uma delimitação temporal tanto para a sua ocorrência quanto para a sua conclusão.

Os eventos estão relacionados a um conceito maior, que é o de Sprint. 

Sprint – pode ser considerada o núcleo central do Scrum. Uma Sprint geralmente é uma etapa com prazo aproximado de um mês em que o Time Scrum deve entregar algo “pronto”, um produto que minimamente já possa ser utilizado. 

Uma Sprint, por sua vez, também é composta por diversos eventos. São eles:

  •  Reunião de Planejamento da Sprint;
  •  Reuniões diárias;
  •  Trabalho de desenvolvimento;
  •  Revisão da Sprint;
  •  Retrospectiva da Sprint;

Cada uma destas fases e tarefas dentro de uma Sprint servem para manter os membros do Time Scrum focados na entrega progressiva de resultados. Além do mais, diariamente mede-se o avanço da equipe, permitindo em tempo real adequar metas e revisar procedimentos.

Artefatos

Podem ser considerados como as informações-chave das quais tanto o Time Scrum quanto os desenvolvedores precisam estar cientes. Eles são voltados para a transparência, para que todos os envolvidos possam ver o que está sendo desenvolvido e, consequentemente, fazer as adaptações necessárias.

O conceito de artefatos subdivide-se em:

  • Backlog do Produto – é a lista de prioridades do produto, tudo o que ele precisa ter, como características, funções, melhorias e correções;
  • Backlog do Sprint – é a lista de prioridades para determinada Sprint, o que se deve buscar e priorizar em cada uma destas etapas. Com ela sempre é possível se realizar uma estimativa de quanto de trabalho falta para se completar cada objetivo da Sprint.
  • Incremento do Produto – é a soma do que já foi realizado durante a atual Sprint e as Sprints anteriores. Ou seja, é o quanto de trabalho previsto no Backlog do Produto já foi realizado e quanto o produto está próximo da condição de “Pronto” para ser utilizado.

A importância dos conceitos e da prática 

Como vimos, o Scrum preconiza um processo contínuo de desenvolvimento de produtos, que altera de maneira substancial a dinâmica das equipes e organizações, promovendo a transformação organizacional.

Fazer Scrum demanda, antes de mais nada, uma compreensão clara e precisa de seus conceitos e da maneira correta de aplicá-lo. Muitos afirmam adotar o Scrum, mas poucos de fato o fazem.

E o primeiro passo para dominar o Scrum é obter uma formação ampla e aprofundada. Cursos como o Certified Scrum Master e o Certified Scrum Product Owner são apenas alguns dos passos a serem trilhados nesta jornada rumo ao conhecimento.

A Massimus

Se você, sua equipe ou empresa de fato querem realmente transformar a forma como pensam e atuam e pensam no mercado, fique por dentro dos cursos e treinamentos oferecidos pela Massimus.

Excelência, respeito, inovação, honestidade, franqueza, simplicidade são os valores que fazem da Massimus referência global na promoção da transformação organizacional.

Para ficar por dentro de todos os cursos, turmas regulares e treinamento in company oferecidos pela Massimus, clique aqui.

Confira essas dicas para implementar o Scrum na sua empresa

Publicado em por .

O avanço das tecnologias e a alta competitividade do mercado exigem cada vez mais competência e agilidade dos desenvolvedores – e todos nós sabemos que isso não é fácil. Reunir um time empenhado em cumprir as metas no prazo, delegar tarefas para um líder da equipe e conseguir mapear erros e acertos em tempo real é a grande obsessão das empresas que trabalham com desenvolvimento de software ou outras áreas que pedem a aliança entre capital intelectual e recursos tecnológicos. 

É nessa hora que muita gente ouve falar do Scrum – um método Agile que revoluciona os procedimentos das corporações para conseguir tudo isso – metas, prazos, empenho da equipe e entrega de produtos com rapidez e autonomia de execução. Mas, afinal de contas, como implementar o Scrum dentro da sua lógica de trabalho? É o que pretendemos esclarecer nesta matéria.

Vamos por partes para implementar o Scrum

Antes de mais nada, é preciso ter em mente que uma mudança de procedimentos não pode ser feita do dia para a noite, por uma série de questões. A primeira delas tem a ver com a natureza humana, que tende à acomodação.

Se você implementar um processo novo que mexa com todas as etapas do desenvolvimento, da criação à execução, possivelmente não terá bons resultados e poderá comprometer toda a rede. Por isso, sugerimos que o Scrum seja adotado para projetos específicos, enquanto os demais seguem utilizando o padrão de trabalho que o grupo já conhece. Aos poucos, os times vão naturalmente pavimentar o novo caminho.

Já mostramos por aqui em vários posts a revolução que o Scrum promete – e o melhor, cumpre. Em linhas gerais, podemos resumi-lo como um procedimental ágil, flexível, composto por uma distribuição de tarefas avaliadas diariamente, cujo resultado é a entrega de um produto testado e utilizável, em tempo recorde. No caso do software, pode ser uma sequência de versões, todas autônomas, até que o conteúdo definitivo seja entregue.

A primeira mudança deverá ser no ambiente de trabalho. O time Scrum, que deve ser composto preferencialmente por até onze pessoas, deve trabalhar próximo ou com garantias de conexão para reuniões. Esses encontros (Daily Scrum), como o nome sugere, são diários e rápidos – o ideal é que todos fiquem de pé, para evitar digressões.

O Product Owner é o cabeça do projeto: ele é o responsável por definir a ordem dos processos, com quais recursos e competências. Se você se interessou por essa função, a Massimus oferece treinamentos específicos para o Product Owner, dê uma olhada aqui.

Recentemente, abordamos também o papel do Scrum Master – um líder atento que não exerce papel gerencial, mas sim de intermediação de interesses e solução de problemas. Trata-se de um coach, que precisa reunir o domínio de todo o estágio – que como você sabe, chamamos de sprint. Cada sprint deve durar no máximo um mês.

Etapas de projeto

Com as funções definidas, é hora de iniciar o projeto. Para isso, todas as etapas comporão um grande mapa conceitual, conhecido por Product Backlog. O mais legal deste prospecto é que ele nos apresentará o que deve ser feito com prioridade, a fim de garantir a agilidade necessária à criação.

É normal que o time precise de vários sprints para dar conta do Product Backlog – então é por isso que é necessária a divisão de trabalho em subconjuntos. Isso tudo fica mais claro quando o grupo usa um quadro ou uma lousa com todos os apontamentos. Se na sua estação de trabalho isso já é feito, meio caminho andado! E, é claro, existem muitos aplicativos que ajudam na organização e na divisão de trabalhos – mais adiante falaremos deles.

Como você viu, quase todas as funções desempenhadas no Scrum exigem senso de liderança – o que envolve algum feeling pessoal, mas também muita qualificação. Entre os dias 8 e 9 de outubro, a Massimus promoverá um treinamento de alto desempenho chamado Management 3.0, voltado para profissionais que pretendem se tornar líderes inspiradores. Dê uma olhada na programação!

Entenda mais sobre o papel do Product Owner

Publicado em por .

Literalmente o “dono do produto”, ou Product Owner é peça-chave nos processos Scrum. Conforme menciona o próprio Scrum Guide de 2017, este personagem é o responsável por maximizar o valor da solução resultante do trabalho do time de desenvolvimento. Neste post, vamos entender melhor o papel do PO.

A primeira grande confusão que se faz é entre os papéis do Product Owner e o do Scrum Master. Embora todos saibam que papel não é cargo, nem sempre as diferenças de atribuições ficam claras.

O PO tem pleno domínio do produto final e é o responsável pela elaboração das tarefas e requisitos que comporão cada Sprint (Product Backlog). Ele também tem como atribuição fazer a interação de negócio entre o Time Scrum e os demais setores da empresa (financeiro, operacional, etc.), assim como deve sustentar a relação com o cliente. Ou seja, trata-se de um papel qualificado, uma espécie de expert de negócio daquele projeto.00

Vale lembrar que a elaboração do Backlog do Produto precisa levar em conta os seguintes critérios:

  • Definição clara de metas e missões de cada Sprint, com duração média de duas a quatro semanas;
  • Otimização do valor do trabalho do time de desenvolvimento;
  • Garantia de que o Backlog esteja visível e transparente a todos (já mostramos aqui ferramentas que podem ajudá-lo nisso);
  • Garantia de que o time de desenvolvimento esteja inteirado de todos os itens que compõem a tarefa, e no nível necessário;

Jogo de xadrez

O Product Owner não é incumbido apenas de elaborar o prospecto, mas sim de participar de todas as etapas de planejamento. Trata-se de um enxadrista, responsável por mover as peças certas a cada iteração, a fim de amenizar erros, aprender com os mesmos, e garantir que todas as etapas sejam cumpridas com autonomia e resolutividade.

Mesmo que este profissional opte por delegar parte de suas atribuições na elaboração do plano, a palavra final e a chancela do produto sempre será dele. É como o responsável técnico de uma obra. Ainda que parte da execução fique a cargo de um mestre de obras, quem assina o projeto e reporta erros e acertos para o dono da construção é o engenheiro.

Diferenças

Mas… Ainda não esclarecemos as principais diferenças entre o Product Owner e o Scrum Master. Enquanto o segundo está totalmente envolvido com a estratégia de implementação dos Sprints, de maneira atenta e receptiva às demandas do time, o primeiro também cumpre tarefas gerenciais, como prestar contas à diretoria da empresa e ao cliente e o envolvimento com outras áreas da corporação, como o marketing e a gestão.

É por isso que o  PO não pode dedicar seu tempo de maneira exclusiva para o desenvolvimento dos produtos. Ele precisa também lidar com o gerenciamento dos stakeholders, além de alocar tempo para a elaboração de novos planejamentos e o convencimento do cliente de que o trabalho trará resultados maximizados.

Um risco sempre presente é que o Product Owner se torne apenas um “tirador de pedidos”, um despachante que delega funções e apresenta resultados. Por isso, já falamos aqui sobre a importância do Agile Coach para capacitar esse papel para ajudá-lo a ganhar respeito e autonomia. A Massimus também oferecem treinamentos de compliance e liderança para quem já é ou quer se tornar um Product Owner.

Veja aqui!

Como um Agile Coach pode ajudar o Product Owner a não se tornar um simples “tirador de pedidos”?

Publicado em por .

Atualmente nas empresas que estão passando por um processo de transformação organizacional, querendo sair da inércia, de quebrar o paradigma do caminho hierárquico e dos silos departamentais, acabam não dando todos os subsídios para que os profissionais possam exercer suas funções em plenitude. Vemos cada vez mais, gerentes de áreas de negócio, analistas de requisitos ou “hard users” dessas mesmas áreas assumirem um papel de Product Owner, simplesmente por que de um dia para outro a empresa falou que serão ágeis. Nesse contexto, frequentemente esses profissionais nem conhecem e nem sabem de fato o que precisam fazer, realizando um trabalho aquém do esperado e sem trazer eficácia na entrega e na qualidade dos produtos.

Segundo o Scrum Guide (http://scrumguides.org/scrum-guide.html):

“O Product Owner é responsável por maximizar o valor do produto e o trabalho do time de desenvolvimento. O Product Owner é a única pessoa responsável por gerenciar o backlog do produto. O Product Owner pode representar os desejos de um comitê no backlog do produto, mas aqueles que desejam alterar a prioridade de um item no Backlog devem recorrer ao Product Owner.”

E agora P.O.?

No contexto descrito anteriormente, o que acontece em muitos casos? Os Product Owners não sabem a dimensão do seu trabalho, não tem a mínima ideia de como escrever histórias e nem definir as prioridades de um produto, consequentemente mal conseguem responder aos inúmeros questionamentos que são feitos pelo time de desenvolvimento.

Isso também, quando não são abordados por gerentes, diretores, CEO, entre outros que fazem todos os tipos de solicitação, nesse caso, o Product Owner submetido por pressão ou intimidação, acabam “tirando o pedido”, sem nenhum critério, criando uma alta expectativa para quem realizou essa solicitação. Podendo com isso gerar um PBI (Product Backlog Item) para adicioná-lo no planejamento de uma próxima Sprint, ou até mesmo inseri-lo indevidamente na Sprint atual.

Por não fazer perguntas poderosas, esse Product Owner acaba sendo um mero repassador de problemas e não entendendo se a demanda solicitada vai atender ou não a real necessidade do cliente, podendo até gerar um novo problema.

Dado esse contexto, onde entraria o Agile Coach nesse cenário?

Um Agile Coach seria de extrema importância para atuar em conjunto com o Product Owner, que dada a situação encontra-se totalmente perdido, desde que consentido por ele, para realizar um forte trabalho, fazendo com que o PO entenda e consiga enxergar alternativas e métodos para mudar essa situação.

O primeiro ato desse Agile Coach seria ter uma conversa de coaching com o Product Owner, identificando o seu momento atual e qual é de fato o seu nível de conhecimento sobre o papel que ele desempenhará para a empresa e para o time, podendo assim treiná-lo minimamente sobre o que é esperado na sua posição de PO, repassando conceitos básicos de SCRUM, ensinando técnicas preliminares de como se comportar e agir diante das mais variadas solicitações que ele receberá.

Após entender a situação atual e trazer o PO para um novo nível de conhecimento, será muito importante o Agile Coach acompanhar e apoiar esse Product Owner para que aos poucos ele vá se engajando melhor e possa realizar de forma eficaz o seu trabalho.

É válido orientar o Product Owner na busca de conhecimento complementar através de cursos e certificações existentes no mercado.

O Agile Coach deve estabelecer um prazo junto com o PO para medir os seus avanços e identificar junto com ele novas necessidades de melhorias no seu trabalho.

O Product Owner deverá imergir profundamente nas solicitações que ele receber e entender qual é de fato o problema que precisa ser resolvido. Qual o retorno que essa demanda terá para a organização? Diminuição de custos? Aumento de receitas? Diminuição de reclamações de clientes? E assim escrever histórias completas, detalhadas e com um nível pré-acordado (Definition of Ready) com o time para que seja possível realizar de forma mais assertiva as suas estimativas.

Essas são algumas questões que o Agile Coach pode trabalhar com o Product Owner para melhorar o refinamento do backlog do produto, melhorar a qualidade da escrita das histórias que serão priorizadas e assim poder repassar para o time de desenvolvimento nas reuniões de Sprint Planning o real motivo da inclusão desse PBI e o quanto de valor e benefício será gerado no final dessa Sprint, fazendo com que o time de desenvolvimento esteja sempre engajado, mais motivado e contextualizado com o valor que será obtido com os esforços que serão dispendidos.

Concluindo

O papel do Product Owner é importantíssimo, pois ele traduzirá as necessidades estratégicas das empresas em desenvolvimento de novos produtos, melhorias de produtos existentes e também para passar de forma mais detalhada possível as informações para o time que fará “a mágica” acontecer. Esse é um papel que o Agile Coach precisa sempre acompanhar de perto e auxiliar sempre que possível para ter uma melhor integração e obtenção dos melhores resultados.

 

Sobre o autor: Ricardo Bruno

Ricardo Bruno Alves da Silva

Ricardo Bruno, tem mais de 20 anos de experiência com tecnologia. Foi sócio fundador de 2 startups, trabalhou em empresas de médio e grande porte, como provedor de internet, indústria, varejo e serviços. Amante de frameworks ágeis como Scrum, Kanban, Lean, XP e Lean Inception. Hoje é Agile Coach de uma fintech em grande crescimento. Além de Agile Coach (CAC) certificado é também:
Leader Coach
Certified Scrum Master (CSM)
Certified Scrum Product Owner (CSPO)
CLF® – Certified Lean Inception Facilitator

https://www.linkedin.com/in/ricardo-bruno-alves-silva/

Como lidar com Débitos Técnicos do Time de Desenvolvimento?

Publicado em por .

Olá Scrum Masters, Product Owners e Agile Coaches, como vocês têm lidado com PBIs (Product Backlog Items) de débitos técnicos do time?

Quis começar esse artigo com uma pergunta e aproveito a oportunidade de colocar alguns pontos de vista sobre essa questão.

Os débitos técnicos são itens gerados pelo Time de Desenvolvimento, onde durante a codificação das histórias percebem a necessidade de criar esse PBI e revisitar futuramente essas partes de código para realizarem refatoração.

É errado isso?

Eu acredito que não, quando temos uma cobrança forte para entrega de uma Sprint, cabe ao time de desenvolvimento definir como devem implementar certos pontos do código e nesse caso se para atingir o objetivo da entrega seja necessário “pecar” em alguma das melhores práticas de desenvolvimento ágil de software para o bem da entrega, nesse caso eu acho válido, desde que esse mesmo desenvolvedor registre esse débito técnico e todo o time tenha ciência que precisa ser refatorado.

E como fazer para reduzir esses PBIs de débitos técnicos?

Durante a Sprint Retrospective, que é o momento onde todo o time de desenvolvimento aproveita para realizar Kaizen do processo, precisam conversar e estabelecer um plano de ação para a redução desses itens. Hoje em dia, diversas ferramentas são utilizadas durante o processo de deploy contínuo, como por exemplo: Sonar Qube e Codacy, que realizam inspeção da qualidade do código para revisões automáticas, detecção de bugs e vulnerabilidades de segurança e que “deduram” pontos para o time de desenvolvimento atuarem para correção/melhoria desses “issues”.

Qualquer Product Owner durante uma Sprint Planning, que ele traz a lista de PBIs priorizados para que o time faça a estimativa e identifique o que cabe na próxima Sprint, dificilmente entenderia a inclusão de um item identificado pelo Dev Team de débito técnico, nesse ponto é salutar que haja uma boa negociação com esse PO para que ele entenda a necessidade de refatoração de partes do código para uma melhor performance e também para evitar bugs e vulnerabilidades nos sistemas.

Uma alternativa válida é se comprometer com um número menor de histórias e ter um “buffer” para refatoração efetiva dos pontos identificados.

Concluindo

Débitos técnicos são ocorrências que sempre existirão durante o ciclo de vida de um produto, é responsabilidade de todos do time de desenvolvimento terem a consciência e a auto-organização necessária para identificá-los e em momentos oportunos realizar as melhorias visando a melhor qualidade do código e a satisfação do cliente com o produto que está sendo entregue.

Vamos discutir o tema com a comunidade, compartilhe, comente sua experiência, dê like no artigo para ele ganhar relevância, vamos falar sério sobre o tema.