Product Backlog: o que pode e não pode cair para Sprint Backlog?

Uma discussão que sempre gera muita negociação é o que o time pode se comprometer a fazer em uma determinada Sprint Backlog?

Obviamente que o PO tem a atribuição de definir o que deve ser priorizado, podendo aplicar diversas técnicas para tal (MOSCOW[a], KANO[b], WSJF[c], etc).

De qualquer forma cabe ao time nas cerimônias de refinamento e planning aferir se os acordos das histórias estão sendo cumpridos. Por exemplo:

Story

  1. As histórias estão DOR (Definition of Ready), com o detalhamento necessários para compreensão do time, ou seja, detalhamento de ao menos um critério de aceite, wireframe/protótipo de baixa fidelidade?
  • A história é do tipo INVEST(Independent, Negociable, Valuable, Estimable, Small e Testable). Ou seja, sua atomicidade garante um desenvolvimento desacoplado, pode ser negociada, tem valor suficiente para uma implementação para o cliente, é passível de ser estimada e suficientemente testável?
  • Existem riscos de indefinições técnicas, de negócio ou arquitetura que não serão resolvidas pré-Sprint?
  • Existem dependências com outros times que não foram negociadas as demandas para sincronização adequada de implementação?
  • A história tem uma importância e relevância para o cliente?

Está gostando deste post? Cadastre-se na nossa newsletter e receba os próximos conteúdos sobre transformação digital e mais!


Maturidade

Times com baixa maturidade e sem um suporte adequado de um agilista do processo (Scrum Master e Agile Coach por exemplo), acabam não se atentando aos pontos citados acima. Isso corrobora ao não atingimento do objetivo definido na Sprint, perda do timebox estabelecido e consequentemente frustração entre os integrantes do time.

Ainda nessa linha, é necessário verificar se a formação do time foi montada de acordo com as características técnicas necessárias do que será implementado no roadmap das sprints planejadas.

Uma vez que os itens acima sejam considerados, o time consegue não aceitar histórias incompletas e que gerem riscos para cumprimento do objetivo estabelecido na Sprint.

Naturalmente que o time deve ter autonomia e maturidade suficiente para eventuais itens considerados “incompletos” não caiam para Sprint Backlog, onde se comprometem a entregar as histórias discutidas e entendidas para serem implementadas.

No início deste processo, naturalmente o time terá muitas dificuldades em fazer cumprir as regras/acordos definidos. Neste cenário, o agilista (como citado acima), ganha uma importância fundamental para orientar, passar direcionamento, realizar mentoring e nas retrospectivas tangibilizar ao time, eventuais motivos que a sprint “capotou” e não foi possível cumprir o que foi comprometido na planning. Por exemplo, histórias incompletas que o time permitiu que fossem construídas.

Outro aspecto importante que o agilista pode contribuir é não permitir que o time se fruste com insucessos iniciais, já que estamos lidando com modelo não prescritivo e empírico.

As retrôs neste cenários são muito importantes para identificar problemas de indefinições, riscos existentes, histórias incompletas e atuar em ações assertivas para que um novo ciclo não se repita as mas características de ocorrências.

Com esse acompanhamento realizado pelo agilista, o time vai ganhando cada vez mais confiança e empoderamento, para que nas próximas sprints o processo fique cada vez mais maduro e assertivo.

[a] MOSCOW

O termo MoSCoW é um acrônimo em inglês derivado da primeira letra de cada uma das quatro categorias com os “Os” no meio para fazer a palavra ser pronunciável. Dessa forma:

  • Must Have (Tenho que fazer)
  • Should Have (Devo fazer)
  • Could Have (Poderia fazer)
  • Won’t Have (Não vou fazer)

[b] KANO

O Modelo Kano (pronuncia-se “kah-no”) é uma abordagem para priorizar recursos em um roadmap de produtos com base no grau em que eles provavelmente satisfarão os clientes. As equipes de produto podem avaliar um recurso de alta satisfação em relação aos custos de implementação, para determinar se a inclusão ou não no roadmap é uma decisão estratégica.

[c] WSJF  

Sigla com significado Weighted Shortest Job First, que realizando uma tradução objetiva seria trabalho com menor esforço e maior valor devem ser priorizados primeiro. Criando um peso de cada item do backlog para calcular qual teria mais relevância e menor esforço para ser desenvolvimento primeiro.


Artigo escrito por Sérgio Ricardo Vieira, Agile Coach da Mooven Consulting.

3 principais métricas ágeis para quantificar o retorno do Agile

Executar uma tarefa e não saber se o desempenho atendeu às expectativas pode ser frustrante, concorda? Nesse sentido, as métricas ágeis são fundamentais para quantificar o retorno obtido com a gestão ágil de projetos.

Bem como esse assunto é de extrema relevância para muitas pessoas, preparamos este artigo especial. Ao longo do texto, você encontrará os principais indicadores, como usá-los e a relação que estabelecem com as finanças de uma organização. Continue a leitura! 

O que são os métodos ágeis e por que são vantajosos? 

Um método ágil — termo adaptado do inglês “Agile” — é um jeito de pensar e realizar a gestão de empresas e projetos. Ele se vale de técnicas específicas para aprimorar a rotina de um negócio, como: 

  • mensurar os resultados; 
  • facilitar o acesso aos dados; 
  • antecipar entregas de valor; 
  • agilizar a comunicação; 
  • otimizar a produtividade.  

A grande vantagem que esse tipo de abordagem proporciona é a redução do desperdício de recursos: temporais, materiais, financeiros e assim por diante.  

Eventualmente, métodos ágeis também são aplicados em conjunto com outras ferramentas, como prototipação e Design Thinking. Elas são úteis para propor soluções, compreender o andamento de um projeto e encontrar oportunidades para promover melhorias.  


Está gostando deste post? Cadastre-se na nossa newsletter e receba os próximos conteúdos sobre transformação digital e mais!


Como saber se a estratégia está funcionando? 

Em primeiro lugar, é preciso entender quais são os desafios da organização — em boa parte das vezes, eles se associam aos prazos, uma vez que projetos tradicionais tendem a demorar além do esperado. Tal fator pode ser um obstáculo, afinal, é feito um investimento para alocar recursos, mas a entrega do produto não ocorre. 

No Agile, trabalha-se com ciclos de entrega ou sprints: os recursos aplicados são sincronizados com retornos palpáveis. Afinal, algum resultado será entregue no fim de cada ciclo, cuja duração vai até 30 dias. Geralmente, a extensão é de uma ou duas semanas, mas tudo depende da complexidade do que está sendo construído. 

Por exemplo, imagine a seguinte situação: no desenvolvimento de um app para uma loja, o cliente recebe uma funcionalidade de validação do CPF antes da conclusão do projeto. A medida serve para saber se o investimento realizado foi correspondido, visto que, pode-se acompanhar o desenvolvimento e ver os resultados. 

Na prática, não existe uma relação de linearidade entre a aplicação realizada e o retorno recebido: às vezes, gasta-se um pouco menos e o resultado vem acima do esperado. Ainda assim, podemos considerar que o aporte e a entrega do produto caminham próximos.  

O importante é que há sempre uma retrospectiva ao final dessas pequenas entregas, o que permite pensar em como melhorar os processos de forma contínua. Além de ser uma prática estimulante, ela viabiliza um ambiente de trabalho colaborativo — o time é guiado a produzir com mais velocidade, uma vez que está aperfeiçoando seus métodos de trabalho. 

Quais são as principais métricas ágeis? 

Listamos, logo abaixo, algumas das principais métricas ágeis que possibilitam monitorar a evolução do projeto e das entregas. Esses instrumentos ajudam a corrigir decisões equivocadas para que se possa alcançar o objetivo final com o máximo de eficiência.  

1. Gráfico de Burnup 

O gráfico de Burnup é útil por apresentar a quantidade de trabalho que uma equipe entregou. Em uma única visualização, combina-se a entrega total e o escopo. Usado para verificar as tendências e, a partir delas, estimar o prazo de entrega da meta analisada.  

Trata-se, portanto, de uma poderosa ferramenta de comunicação e controle interno, já que o próprio time pode avaliar o desempenho e a velocidade de produção no ciclo. Graças a essa característica, pode ser utilizada para negociar com stakeholders. 

Desse modo, se você se comprometeu a entregar algo novo para o site do cliente, basta dividir o trabalho a ser feito pelo total de dias e ficar de olho na progressão, por exemplo. 

2. Balance Scorecard 

Quando se pensa na gestão organizacional como um todo, logo se vê a necessidade de usar o Balance Scorecard para ponderar o que está sendo entregue ao mercado, bem como a velocidade de crescimento. 

Essa métrica auxilia a entender como o aprendizado dos colaboradores está evoluindo, a fim de criar produtos cada vez mais inovadores. De qualquer forma, é preciso ressaltar que o Balance Scorecard não é uma ferramenta ágil, necessariamente. Ele funciona como um indicador de gestão, independente da maneira como é conduzida, pode ser adaptada para métodos ágeis. 

Via de regra, o Balance Scorecard é formado pelo equilíbrio entre essas perspectivas: 

  • finanças; 
  • aprendizado e crescimento; 
  • clientes; 
  • processos internos e criação de valor.  

3. Throughput  

Throughput nada mais é do que o número médio de unidades processadas por unidade de tempo, ou seja, ele mede quanto itens foram entregues em uma semana. É comum que haja uma confusão entre esse indicador e a Velocity, métrica utilizada no Scrum, mas ambos têm propósitos distintos.  

O throughput é interessante porque ajuda a responder questões como o total de entregas que o time consegue fazer em um determinado período e avaliar se certo aspecto está bloqueando ou impulsionando a performance. A partir dele, todos os envolvidos conseguem acompanhar a evolução com bastante transparência.  

Como quantificar o retorno financeiro? 

Os hábitos de consumo mudaram, assim como as formas de avaliar a satisfação de quem consome. Nesse cenário, vender bastante e se apegar a números de curto prazo não é mais suficiente — é fundamental oferecer uma experiência única aos clientes para fidelizá-los e torná-los divulgadores espontâneos da marca, que deve estar bem posicionada no mercado.  

Para isso, mais do que analisar o retorno financeiro imediato, é preciso entender a cultura da organização. Muitas vezes, estabelece-se uma gestão baseada em comando e controle — nela, o colaborador é apenas uma mão de obra e não um intelecto repleto de potencialidades. 

Contudo, essa transformação é hierárquica e passa pelas lideranças. Sem uma mudança de mentalidade, fica difícil evoluir e encontrar alternativas. Às vezes um produto não proporciona um retorno de investimento imediato, mas acaba viralizando e se transforma em uma enorme receita no futuro: o WhatsApp exemplifica isso muito bem. 

Enfim, métricas ágeis são instrumentos valiosos. Ainda assim, devem ser acompanhadas de uma gestão inovadora, capaz de observar e compreender que velocidade e pressa não se misturam.  

Se você gostou do conteúdo e precisa suporte especializado para aplicar métodos ágeis em seu negócio, entre em contato com a Mooven! 


Leia mais sobre:

Transformação Digital

Transformação Digital Corporativa: solução para os problemas da sua empresa

Você precisa de um Agile Coach?

você precisa de um agile coach

É muito difícil encontrar um framework de mercado que explicitamente descreva e inclua o Agile Coach em seus métodos. Ainda assim é muito comum encontrarmos Agile Coaches nas implementações ágeis no mercado. Se esse cargo não é parte integrante da maioria dos frameworks, por que preciso investir em um Agile Coach?

Para entender a importância do Agile Coach em uma implementação ágil, precisamos entender antes suas competências e como suas atribuições se diferenciam de outros cargos comuns em times ágeis. Para isso, vamos ver como a Lyssa Adkins descreve as competências de um Agile Coach no seu livro Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition.

As oito competências do Agile Coach

Segundo a Lyssa Adkins (coach, professora, autoria do livro Coaching Agile Teams e fundadora dos programas TENWOMENSTRONG e #WomeninAgile), um Agile Coach deve demonstrar competência em 8 áreas distintas, sendo elas Práticas Agile-Lean; Instrução (dar aulas), Mentoria; Maestria Técnica, Maestria de Negócios, Maestria em Transformação, Facilitação e Coaching Profissional.

Práticas Agile-Lean é o conhecimento básico técnico de Agile, aqui estão incluídos práticas, frameworks, métodos e ferramentas necessárias não só para fazer ágil no dia a dia, mas também valores e princípios fundamentais para criar uma cultura e um mindset ágil nas equipes, seus líderes e integrantes. 

Juntamente do conhecimento sobre Agile, um Agile Coach deve se interessar e aprender o mínimo necessário do ambiente em que está inserido, adquirir uma Maestria do Negócio e uma Maestria Técnica suficiente para dialogar com os integrantes da equipe, e poder apoiá-los inclusive em alguma particularidade desse ambiente. 

Tendo todo o conhecimento em Agile, juntamente com uma maestria do negócio e aspectos técnicos do ambiente em que está inserido, o Agile Coach deve usar de suas competências em Mentoria, Instrução, Facilitação e Coaching para apoiar esse time em seus objetivos, entendendo como que ele pode contribuir para alavancar seus resultados.

Todo esse processo de melhoria deve ser fortemente baseado em técnicas de Gerenciamento de Transformação, que a Lyssa Adkins chamou de Maestria em Transformação. Esse gerenciamento de transformação é essencial para que todas as mudanças e melhorias se tornem perenes, mesmo na ausência de um Agile Coach. 

Você reparou que não citei nenhum termo comum de ambientes ágeis aqui? E essa é uma grande diferença entre um Agile Coach e outros cargos comuns em times ágeis! 

O grande diferencial do Agile Coach

Diferentemente de um Scrum Master, que é um especialista no framework Scrum, ou um RTE, cargo descrito pelo SAFe, um Agile Coach não se limita a um ou outro Framework. Um Agile Coach deve ter conhecimento de múltiplos frameworks e práticas ágeis para justamente ser um apoio ao Scrum Master, RTE ou outros cargos dentro do time, independente do framework em questão. 

Eu recomendo que um Agile Coach deva conhecer em detalhes pelo menos 3 frameworks de mercado, assim ele constrói repertório ágil suficiente para poder navegar entre frameworks e adaptá-los ao contexto em que está inserido. 

Atingindo resultados estratégicos

Agora que está mais claro quais são as competências de um Agile Coach e como ele se diferencia de outros cargos dentro de um time ágil, vamos entender quais são os benefícios de ter um Agile Coach em sua equipe. 

Um Agile Coach é um agente de transformação, que vai utilizar suas competências para extrair o que há de melhor do time, da liderança e dos processos. O Agile Coach vai identificar os pontos de melhoria dentro desses três contextos e utilizar de técnicas de coaching, mentoria, instrução e facilitação para desenvolver esses pontos. 

Além disso, o Agile Coach pode identificar as fortalezas do time, dos processos e da liderança, e assim trabalhar melhor esses pontos como uma forma de tração do time em direção aos seus resultados

Aqui está um ponto essencial, o Agile Coach vai trabalhar pontos fortes e fracos dos times, processos e liderança tendo como foco os objetivos de negócio aí presentes e, é claro, caso os objetivos não estejam claros, o Agile Coach vai apoiar as lideranças nesse aspecto também. 

Ter um Agile Coach em sua equipe é ter um profissional multidisciplinar, com conhecimentos diversos, focado essencialmente no desenvolvimento do time, para extrair o que há de melhor dos indivíduos, processos e liderança tudo isso visando os objetivos de negócio.

São esses e outros benefícios, muitas vezes intangíveis, que justificam a presença de um Agile Coach na maioria dos processos de transformação ágil no mercado. E você deveria investir em um? Se atingir resultados estratégicos e desenvolvimento são imperativos importantes para você, definitivamente sim

Solução digital para cobrança de dívidas

Case: solução digital para cobrança de dívidas

Agilidade corporativa vencendo resistências

Case: agilidade corporativa

Visão Sistêmica para Estruturação do Backlog do seu Produto

O motivo de eu escrever este artigo é o de compartilhar uma visão estruturada da formação de um backlog de produto que de fato considere vertentes de engenharia de produtos e de agilidade.

Como todos sabem, desde 2012 atuo fortemente na transformação organizacional, ágil e digital de empresas de destaque no mercado brasileiro. Nesses trabalhos, em todos os casos me deparei como uma grande dificuldade por parte dos líderes dos times de entrega em materializar um backlog de trabalho que de fato represente as necessidades relacionadas a entrega de valor esperada pela organização.

A minha ideia neste texto não é discutir ou analisar práticas e abordagem de mercado para formar um backlog, fazer inceptions ou coisas do tipo (existem artigos mais adequados para isso). Aqui desejo apresentar para vocês princípios de arquitetura corporativa, engenharia de software e gestão de requisitos que devem ser bem estabelecidos nas sinapses de cada um para que de fato possam trabalhar de forma eficiente e alinhada com algo que ao final resulte em um produto que tenha seu valor maximizado.

DEFINIÇÕES E SIGNIFICADOS

Não adianta caminharmos para um debate sem que os significados das coisas estejam claras. Destaco que aqui não busco mudar a sua “crença” sobre os termos a seguir, mas sim deixar claro o que tenho em minha visão de solução.

ARQUITETURA DE UMA EMPRESA

O maior erro que se pode cometer na formação de um backlog de trabalho é ignorar completamente a estruturação da organização. Essa estrutura em sua forma ideal, permeia a organização de ponta a ponta, criando sinergia entre aqueles que transformam esforço (processos, funcionários, sistemas, algoritmos, etc ) em versões de produtos prontos para os clientes.

Não entrarei em detalhes para todos os itens, seria tema de um outro artigo. Todavia, alguns pontos preciso mencionar:

  1. Numa organização existem 3 camadas representas por seres humanos: Acionistas, colaboradores/parceiros e clientes
  2. Clientes consomem os produtos e serviços através de um catálogo via canais ( digitais ou analógicos)
  3. Estruturas corporativas (áreas, feudos, tribos, departamentos…etc) existem para levar da melhor forma esses produtos e serviços via canais para os clientes
  4. Uma estrutura corporativa tem ligação direta com um ou mais “Componente de negócio”
  5. Para suportar um componentes de negócio são necessárias plataformas e times
  6. Uma plataforma é feita de features ( funcionalidades ) – UFA!!! se quiser esquecer todos os outros itens é um bom momento, mas guarde este por favor!

Fora os 6 itens comentados gostaria de destacar um outro ponto importante. Em nenhum momento mencionei o termo projeto. Logo, no meu ponto de vista, projetos não são entidades necessárias em uma organização.

ÉPICOS

Representa um serviço prestado por um componente de negócio (business services). É uma jornada de evolução de plataforma/arquitetura/tecnologia . Representa o atendimento a um tema estratégico.

O épico não é um projeto dito de outra forma.

O épico não é um produto.

Um épico existe, impacta e demanda a organização enquanto tiver sua relevância e uso.

Exemplos de épicos seriam: Análise de contratos(Jurídico); Avaliação de crédito (Financeira); Empacotamento (Logística);Atendimento ao cliente(Agência);Gestão de conformidade(Governança)

FEATURES

É um componente da solução de tecnologia ( plataforma ou infra) que suporta a execução de um business service <=> Épico

É o item tangível do valor esperado pelo cliente/usuário para atender suas necessidades

Pode ser tipificado em: Interface humana, campanha, pesquisa, interface sistêmica, relatório, rotina automatizada, documentação técnica, algoritmo, vídeo, documentação funcional, etc

DICA: O tipo de feature aliado com a plataforma, tecnologia, nível de automação e maturidade de equipes é um ponto de partida excepcional para previsibilidade do portfólio de demandas (tema para outro artigo de tão importante)

HISTÓRIAS

Uma História representa a forma como uma determinada persona deseja interagir como uma Feature.

Para sua construção utiliza-se um modelo mais humano que busca manter a necessidade de negócio na perspectiva do usuário. Em geral as Histórias seguem a seguinte estrutura.

“Dado que sou , <Papel do usuário> gostaria que <descrição da necessidade> de tal forma que <descrição do objetivo>.

A história tem uma definição de “ready”, definição de ”done” e critérios de aceite e pode receber diversos documentos complementares como anexo, para que viabilize o entendimento entre as partes

Uma história inclui, altera, remove ou ativa/inativa uma feature de um produto/plataforma

TASKS

A Tarefa define o trabalho necessário para completar a entrega de uma História.

Uma tarefa tem como objetivo impactar uma feature para atender uma história de usuário

Uma tarefa deve ser qualificada em planejamento, documentação, desenvolvimento, testes, implantação e suporte.

ENTREGA

Uma entrega é um conjunto de features que foram desenvolvidas através da transformação de esforço (tarefas) em features de uma solução para atender as necessidades de um clientes (história) através de um determinado canal

ROADMAP / RELEASE PLAN

Uma visão na linha do tempo das entregas

VISÃO GERAL DE RELACIONAMENTO

Os Épicos e Histórias estão relacionados ao fluxo de valor, com experiência e com a jornada

As Features e Tasks são relacionadas com a engenharia do Produto/Solução.

AJUSTANDO A ROTA

Nos itens abaixo vou compartilhar com vocês alguns pontos que devem ser atacados para ajustar a rota para ter um backlog top de verdade, que todos tenham clareza e que a gestão de ponta a ponta seja efetiva.

USE FEATURES!

Se você ainda não usa o conceito de features, pare tudo e comece a usar. Migre de um conceito “vamos listar os desejos” para uma ação orientada a features de produtos, com valor agregado e estimativas.

Para isso ser alcançado invista em um profissional com a competência. Não parta do princípio que as pessoas conseguem fazer essa mudança logo de cara. As carreiras associadas a este são são de Gerente de Produto e Product Owners!

Uma linha de estudo sensacional para esse tema é conhecer mais de #FDD – Feature driven developement.

RECICLE O MODELO DE ATENDIMENTO

Não torne o processo de formação de backlog uma maneira diferente de fazer a “tirada de pedidos” no caderninho. Utilize técnicas de #designthinking #productbacklogbuilding #leaninception #UX #customercentricity

FERRAMENTA DE SUPORTE ADEQUADA

Esse é um grande desafio pois as ferramentas que seguem o modelo de requisitos ágeis em sua grande maioria ignoram a existência de Features trabalhando apenas com Épicos, Histórias e Tasks. Fale com o seu #agilecoach ou especialista para que possa ser configurado um template com features ou que sejam utilizados TAGS ou Cores para definir o que é uma feature. Não é um absurdo ter um Kanban separado para Features e que seja feita uma gestão mais manual do processo.

Ferramentas como #TFS #JIRA são recomendadas e cobrem essa visão. Já #trello #planner darão mais dores de cabeça

TENHA PROFISSIONAIS ESPECIALISTAS

Não ignore a complexidade do tema, tenha especialistas no time! Um especialista vai custar mais, mas vai entregar 2x ou 3x mais do que uma pessoa com pouco conhecimento. Profissionais para esse tema levam 10 a 12 anos para ter a bagagem necessária para ter eloquência ao ponto de tocar o tema na dimensão corporativa.

CASO QUEIRA DETALHAR MAIS O TEMA

CONTATO PESSOAL

Me adicione no linkedin que eu respondo todo mundo.

ME ENCONTRE PELA MOOVEN

Como muitos devem saber sou um dos sócios da Mooven Consulting – uma empresa especializada em Transformação Digital e Ágil.

Confira o site da Mooven e verifique nosso catálogo de serviços, será um prazer ter um relacionamento pessoal ou profissional contigo!

#vempramooven

Visite o site da Mooven Consulting

ME ENCONTRE PELA MODO

Outra maneira de me encontrar e bater um papo é via MODO.ONLINE. A MODO é uma iniciativa nova na qual estou atuando para criar um canal diretor entre profissionais e empresas. Faça seu cadastro na plataforma que será um prazer dar um feedback para vocês que buscam ampliar o alcance de suas carreiras!

#vaidemodo

Visite o site da MODO.ONLINE

Artigo escrito originalmente no LinkedIn por Rodrigo Galdi, Co-Founder & CTO da Mooven Consulting

Como o Product Owner e os demais papéis geram valor para o produto e projeto?

Você entende qual é a importância de um Product Owner no desenvolvimento de um produto ou de um projeto? Compreende de quais formas ele pode colaborar no planejamento estratégico de sua empresa?
Criamos este artigo para comentar o tema. Durante a leitura, você encontrará informações relevantes sobre essa função e a dos outros membros presentes na gestão de produtos e projetos. Continue lendo até o fim para ficar por dentro do assunto!

Quem é o Product Owner de um projeto e o que ele faz?

O Product Owner, também conhecido como PO, é o membro de uma equipe que trabalha com Scrum ou outro método ágil de desenvolvimento de produtos ou projetos. 
Ele geralmente atua na definição das estórias de usuários que compõem o backlog do produto, mantendo o conceito que rege as novas funcionalidades ou ideias a serem desenvolvidas.
Sua atribuição mais importante é estar junto e direcionar o time ágil “no que deve ser feito primeiro” com sua respectiva ordem de execução e conforme o valor para o negócio/cliente e critérios estabelecidos, deixando claro os requisitos, regras de negócios e outras especificações envolvidas, tudo conforme a filosofia e métodos ágeis. Ele também atua na aceitação das estórias concluídas pelo time ágil ajudando a controlar a qualidade e valor final da entrega.
Além de precisar reunir um profundo conhecimento do negócio, da empresa, do mercado e do produto, o PO também deve ter uma série de competências humanas para o bom exercício de seu papel. Nesse sentido, é fundamental que tenha empatia, facilidade de síntese e se comunique com desenvoltura e clareza. Também é interessante conhecer um pouco sobre questões financeiras, como ROI e time-to-market. 
Na prática, o Product Owner é o elo que conecta os clientes, time de desenvolvimento e demais stakeholders. Portanto, é essencial que ele atue de forma próxima a todas as pontas a fim de garantir que todos os envolvidos do projeto compreendam quais recursos são necessários e como o resultado deve ficar.
Além disso, ele tem poder e autonomia para fazer priorizações, porque conhece muito bem o produto e pode fazer isso de maneira adequada. Portanto, deve estar disponível e atuando com uma equipe muito forte no dia a dia para direcioná-la corretamente. 
Por isso, pode-se dizer que suas atividades mais recorrentes são:

  • estar disponível para o time de execução;
  • deixar claro o alvo que deve ser atingido em relação ao negócio;
  • representar outros stakeholders de negócios/sponsors;
  • direcionar o que deve ser feito;
  • priorizar ações de acordo com a necessidade para o projeto/produto.

Outros membros de um projeto: conheça a importância

Embora os POs tenham papel de destaque em relação ao produto, eles não são os únicos a contribuírem para o sucesso do projeto/produto. De uma forma ou outra, eles exercem certa liderança de direcionamento de negócio sobre o time, mas isso não quer dizer que estejam sozinhos na busca pelos melhores resultados.

Analista de negócios

Como o próprio nome do cargo já adianta, esse analista é quem cuida das necessidades da organização, recomendando soluções para aprimorá-la e adequá-la ao modelo de negócio ligado ao projeto/produto em execução. 
É sua responsabilidade garantir que os objetivos do projeto/produto solucionem os problemas existentes. Também ajuda na definição do projeto/produto e na documentação de requisitos técnicos e comerciais.
Na prática, ele pode apoiar e até ser um braço do PO. Ainda assim, vale ressaltar que o Product Owner também pode exercer o papel de analista de negócio, dependendo das características e necessidades da organização. 

Patrocinador ou sponsor

É um membro da alta administração da empresa envolvido na execução. Ele legitima os objetivos da ação e integra o planejamento de projetos de alto nível. Também atua na resolução de conflitos, na aprovação de orçamento, na disponibilização de recursos e na tomada de decisões. 
Como ajuda a remover os obstáculos que ocorrem ao longo do projeto, geralmente obstáculos táticos ou estratégicos, ele abre os caminhos para que o PO o represente e direcione a execução do projeto em termos do negócio. 

Líder do time

Algumas equipes têm um líder específico, determinado previamente. Essa função é dada a alguém que possa chamar a atenção dos outros membros para o cumprimento dos objetivos associados a cada etapa do projeto.
Quem ocupa esse papel também precisa saber ouvir seus companheiros de time, negociar com os provedores de recursos e atuar diretamente na motivação dos membros para que as metas sejam alcançadas. Ele reporta diretamente ao gerente de projeto ou à um gerente funcional, além de se comunicar diretamente com o PO junto com o time, informando sobre o andamento dos trabalhos inerentes ao seu time. 

Scrum Master

O Scrum Master tenta fazer com que a equipe siga os valores e princípios de acordo com o framework Scrum. Ele também é responsável por remover os obstáculos levantados pela equipe, por exemplo, as informadas durante as reuniões diárias.
Esse papel é exercido por uma pessoa que conhece e possui experiência no Scrum. De forma resumida atua fortemente como um líder servil para o time e para o PO, é um grande facilitador para uma boa comunicação e convívio entre o time e PO, facilita cerimônias e garante que o framework Scrum está sendo executado de forma adequada.

Time de desenvolvimento

O time de desenvolvimento é composto, basicamente, pelos profissionais responsáveis pelo desenvolvimento do projeto. Eles devem ter habilidades que se relacionam ao produto em questão. Se ele for um software, por exemplo, será possível encontrar papéis de programadores, testadores, prototipadores, designers e assim por diante. Enfim, é um time multifuncional ou multidisciplinar capaz de realizar o trabalho necessário para a entrega dos incrementos do produto. É importante também os membros serem especialistas generalistas, onde um membro é especialista em algo, mas consegue realizar outras atividades/papéis.
O time é a autoridade técnica e deve possuir autonomia e empoderamento para as decisões técnicas. O PO define “o que deve ser feito”, o time decide “o como será feito”. Scrum Master e PO não devem interferir nas decisões técnicas do time. Eles podem ajudar provendo informações e facilitando cerimônias, mas a decisão técnica é do time.

Outros membros

Os membros são aqueles que trabalham ativamente em uma ou mais fases do projeto, podendo ser colaboradores internos, externos e/ou consultores. As funções variam, é claro, conforme as demandas do projeto, bem como o tempo de dedicação, que pode ser parcial ou integral.

Qual é a relação dessas funções com a gestão ágil?

Tanto o Product Owner e as demais funções têm grande influência na transformação e na gestão ágil. Como mencionado, o PO ainda atua na representação dos stakeholders de negócio, direcionando o time sobre o que precisa ser feito.
Nos métodos ágeis ou em um contexto de escala — no qual a agilidade está presente em todos os processos e etapas — o papel do PO deve ser aplicado e até escalado, tendo em vista que ele se comunica os times e níveis relacionados ao projeto/produto, e é o responsável para o direcionamento do produto que atua.
Como está relacionado a todas as áreas que têm interesse no projeto, ele centraliza diversas visões a respeito do produto. Apesar disso, mantém a integridade do conceito do produto, porque seu foco não recai na execução — função que cabe ao time de desenvolvimento.
Essa mescla de funções gera uma confiança mútua entre o PO e o time. Assim, surge a segurança de cada membro acreditar no desempenho dos outros, gerando a certeza de que há um direcionamento eficaz para todas as funções.
Enfim, o Product Owner pode atuar ajudando a área de finanças, projetos, gestão e políticas. Ele se mostra como um papel de extrema importância justamente por ser um pivô, que permeia várias áreas e pessoas. Com ele e com os outros membros, o desenvolvimento ágil gera valor para o produto e para o projeto, garantindo a excelência em todas as etapas e processos. 
Se você se interessou pelo tema e quer saber como o aplicar a gestão ágil em sua empresa, entre em contato com a gente — a Mooven pode transformar o seu negócio!
]]>

Os 3 desafios atuais da transformação lean

O Lean já está no mercado há algumas décadas. Trata-se de uma filosofia que foca em eliminar desperdícios continuamente e resolver problemas de maneira sistemática, aumentando a eficiência dos processos. Ou seja, tudo aquilo que não acrescenta valor ao que está sendo feito, focando em identificar problemas e em resolvê-los.
A Toyota, por exemplo, é uma empresa pioneira nessa questão, quando lançou o modelo de manufatura enxuta (Lean Manufacturing). Apesar de não ser uma novidade, o método continua atual e pode ser aplicado em qualquer contexto.
Outra filosofia para transformar a performance de pessoas e equipes é a filosofia ágil. São filosofias separadas mas muito aderentes. Quando estão unidas, a agilidade fica muito mais forte e aumenta ainda mais a probabilidade de oferecer muito mais valor
Pensando nisso, preparamos este artigo para que você entenda a filosofia Lean, suas definições e princípios e conheça os principais desafios atuais dessa transformação. Boa leitura!

O que é a filosofia Lean e como ela está associado à performance das empresas?

O termo Lean foi adotado para se referir ao método que a Toyota estabeleceu em sua linha de produção no final da década de 1980. Essa filosofia visa reduzir o desperdício de recursos, além de manter o foco na resolução de problemas. Dessa forma, tudo o que não agrega valor ao serviço ou produto deve ser afastado do processo.
Essa perda representa um custo que pode e deve ser evitado, principalmente de tempo, de mão de obra, de materiais e de outros recursos. O corte de custos desnecessários agiliza as entregas e aumenta a eficiência e a eficácia dos processos. Dessa forma, é possível fazer a coisa certa sem desperdícios.
Podemos resumir os fundamentos da melhoria de performance dos processos das companhias, baseado no Lean Manufacturing, em:

  • busca pela excelência no dia a dia;
  • alinhamento das atividades operacionais com o foco estratégico da organização;
  • criação de valor adequado aos processos internos;
  • valorização da motivação e da competência pessoal;
  • transformação da relação hierárquica convencional para um espírito de equipe;
  • simplificação dos processos;
  • poder de adaptação.

Quais os principais desafios da transformação Lean?

Um dos maiores desafios ao trabalhar com o Lean é conseguir aplicar os seus princípios em grandes empresas, cheias de processos, dependências e burocracias — ou seja, naquelas não ágeis e não Lean. Essa prática deve ocorrer em larga escala, de portfólios aos projetos e operações.
Confira, a seguir, outros desafios atuais da transformação Lean.

1. Falta de planejamento

Para ser possível atingir a excelência, é importante que a implementação do Lean seja tratada como um projeto, que deve estar no planejamento estratégico da organização. Além disso, os colaboradores precisam ser envolvidos de forma programada para que se alcance o comprometimento de toda a equipe dentro dos objetivos do projeto.
Outro fator importante é definir a estratégia da empresa dentro da proposta. É possível ter um plano para cada fase da implementação ou apenas um esquema tratado em correntes sucessivas. É importante deixar claro que a cada melhoria concretizada os benefícios percebidos podem ser cada vez menores — o que não invalida a ação.

2. Falta de abertura à mudança

O sucesso da transformação Lean depende de quanto a empresa está disposta a passar por uma mudança cultural. O corte de desperdícios deve ocorrer em toda a cadeia de produção, envolvendo as áreas de manufatura, marketing, comercial, recursos humanos, entre outras.
Existem muitas formas de colocar o método em prática, partindo de iniciativas internas ou de consultoria externa, por exemplo. Independentemente da origem, um grupo pode ficar responsável por mapear o fluxo de valor e iniciar a implementação em conjunto com as diversas áreas da organização.
Nesse momento, a complexidade da execução pode começar a aparecer. Ela dependerá da abertura da empresa para as mudanças. Além disso, é preciso envolver todas as pessoas — dos mais variados níveis hierárquicos e com diversos interesses relacionados ao sucesso da realização.

3. Falta de liderança

É imprescindível que os gestores estejam engajados na metodologia e na aplicação do Lean. Embora promova a autonomia, o método depende de uma transformação cultural que deve encontrar apoio nos líderes. Dessa forma, é possível gerar uma transformação na relações hierárquicas convencionais para um espírito de equipe.
Esse fator é ainda mais relevante na resiliência necessária durante o período de implementação do Lean, em que a lucratividade ou a produtividade pode diminuir temporariamente em razão da adequação dos processos. Lembre-se de que o sucesso do Lean depende da forma como a empresa enxerga a filosofia dentro do seu contexto.

Como implantar a filosofia Lean em uma empresa?

Sempre que há desperdícios em uma organização o Lean pode e deve ser aplicado. Sistemas arcaicos, paradigmas e status quo podem ser desafios para um mindset ágil dentro das empresas. Por isso, é preciso pensar em formas de transformar a rotina e aplicar o Lean de forma efetiva.
O método nasceu na área industrial, logo, está muito ligado aos processos e à eficiência dos fluxos operacionais. Seu foco está na eliminação de desperdícios e retrabalhos. Quando realizamos muitas tarefas ao mesmo tempo, estamos chaveando de uma função para outra. Esse chaveamento demanda tempo e nos faz perder o foco, colaborando para a questão geral do desperdício.
O cálculo da eficiência do fluxo deve ser feito considerando todas as etapas do processo. É preciso conhecer o tempo total de execução das tarefas e o tempo que, efetivamente, gerou valor. Às vezes, percebemos que metade do número de horas é o necessário para cumprir aquele trabalho.
Em qualquer meio que tenha processos, seja ele fabril ou não, é possível realizar as medições e indicar o desperdício para atuar neles. Dessa forma, trabalhar no que realmente agrega valor ao resultado e ao objetivo da operação é o que torna o processo verdadeiramente enxuto.
No setor da tecnologia da informação, por exemplo, os princípios da filosofia Lean fez surgir o Lean Software Development — abordagem usada também no desenvolvimento de softwares ágeis, na administração de aplicações e no suporte e prestação de outros serviços relacionados à área. O importante é eliminar as tarefas e as funcionalidades que não são úteis e potencializar o que for mais lucrativo.
Tudo que não acrescenta valor ao resultado é desperdício. Dessa forma, o Lean surge como uma forma de pensar e de agir para não atuar com os gastos desnecessários. Para isso, as empresas devem desenvolver uma visão do todo, não abrir mão da qualidade e saber aproveitar todos os seus processos de forma eficaz.
Quer eliminar os desperdícios na sua empresa e ganhar eficiência, solucionando os problemas do seu negócio? Então entre em contato conosco! Nossa equipe está pronta para atendê-lo com agilidade.
]]>

Saiba como otimizar o Product Backlog e deixá-lo saudável!

otimizar o Product Backlog e deixá-lo saudável

Gerar valor para o produto pode ser um dos grandes desafios em um projeto, concorda? Nesse contexto, muitos profissionais têm dúvidas sobre como otimizar o Product Backlog a fim de deixá-lo saudável. O que precisa ser feito? Quais processos alterar?

Para responder a essas e a outras questões, preparamos este conteúdo especial sobre o tema. Ao longo do texto, você encontrará uma série de dicas e informações relevantes para aprimorá-lo em seu negócio. Boa leitura!

Afinal, o que é Product Backlog?

De forma bastante resumida, o Product Backlog ou Backlog de Produto é uma lista que contém todas as funcionalidades desejadas para um determinado produto, cujo conteúdo é definido pelo Product Owner. Essa figura, também chamada de PO, é um dos membros das equipes que trabalham com Scrum ou outro método ágil de desenvolvimento — seja de projetos, seja de produtos. 

Em outras palavras, o Backlog é uma reunião dos requisitos, descritos em sua própria linguagem, que o cliente espera receber no final do projeto. Para muitas pessoas, sua criação é o ponto de partida do desenvolvimento ágil. 

No modelo tradicional da gestão de projetos, por exemplo, o escopo deve ser fechado antes do início da execução. No Scrum, em contrapartida, há um consenso de que o estágio inicial do projeto não é o momento ideal para isso. Isso porque, nas primeiras etapas, o projeto pode apresentar algumas indefinições. Isto é, algumas hipóteses ainda podem precisar de esclarecimento.

Geralmente, no primeiro sprint do projeto, não há um esforço que demanda muito tempo, como escrever os requisitos previsíveis ou todas as tarefas. A partir disso, o Product Backlog cresce e muda conforme se obtém conhecimento a respeito não só do produto, mas também dos stakeholders.

Qual é a sua importância para o negócio?

Em suma, ele é fundamental para capturar toda a lista de desejos dos stakeholders — o que eles esperam, como desejam, as funcionalidades primordiais e a forma como enxergam o projeto em questão.

Como são prioridades e requisitos estabelecidos por quem receberá as entregas, seu foco recai sobre os indivíduos e as interações que existem entre eles, tornando mais fácil a compreensão sobre os objetivos. Como é embasado nas finalidades do projeto e na comunicação dos envolvidos, as mudanças por ele abarcadas ditam novos direcionamentos que o desenvolvimento pode alcançar. 

Nele, o cliente pode descrever que deseja receber os feedbacks dos usuários do software por meio de uma caixa de comentários, por exemplo. Essa definição não é técnica, isto é, ela não delimita detalhes acerca de como a ação será desenvolvida pela equipe. Em vez disso, ela parte do contexto profissional de quem elegeu esse objetivo como uma prioridade do projeto, dando voz aos principais interessados no resultado. 

Vale lembrar que o Product Backlog permite mudanças. Dessa forma, é indicado partir dos requisitos óbvios e, aos poucos, definir os mais complexos. Afinal, um pouco de tempo é útil para o amadurecimento do escopo, possibilitando a captura e o controle de todas as demandas — algo indispensável para que o resultado final atinja as expectativas. 

Como otimizar o Product Backlog?

Ter um Backlog de Produto saudável requer uma lista cujas informações podem facilmente ser identificadas por todos os envolvidos no projeto. Apesar disso, vale ressaltar que a sua gestão e a sua priorização são responsabilidades atribuídas ao PO.

Dito isso, ter um Product Backlog saudável consiste em manter boas práticas ao fazer a manutenção desse componente tão importante. Sendo assim, haverá a possibilidade de aproveitar ao máximo a produtividade do time para entregar o maior valor viável em um intervalo de tempo mais curto. Veja, a seguir, algumas dicas para otimizá-lo em seus projetos!

Faça limpezas periódicas

Na maioria das vezes, POs mais adicionam do que removem itens do Backlog. A princípio, não há nada de errado nessa prática, desde que ela contemple os desejos dos usuários e/ou dos clientes.

Entretanto, é preciso ter bastante atenção à idade de cada item, visto que eles podem ficar inativos ou simplesmente perder a prioridade em relação a outras funcionalidades. De forma gradativa, alguns objetivos não têm mais motivos para constarem na lista, mas vão se acumulando e tendem a atrapalhar a compreensão sobre o projeto. Caso prefira não se livrar de alguns pontos, marque-os como “inativos” ou “sem prioridade”. 

Evite os exageros

É inegável que projetos grandiosos podem ter listas imensas. De qualquer modo, é fundamental analisar o Backlog de maneira crítica a fim de detectar eventuais desperdícios, principalmente os que estão ligados à criação de user stories que não serão utilizadas. 

Isso porque cada entrega realizada pela equipe pode mudar as percepções e, por consequência, os desejos dos stakeholders. Portanto, vários dos objetivos iniciais podem ficar pelo caminho — sem eles, a execução seria mais precisa, e a produtividade, maior.

Lembre-se de que não há um número mágico e a extensão da lista varia muito de acordo com o projeto. Ainda assim, trabalhar com até 100 itens é o indicado para boa parte dos casos. 

Mantenha a organização

Além das limpezas periódicas e da coesão, a organização é fundamental. Uma das estratégias aplicadas nesse sentido é a organização temática dos itens, pois isso permite a visualização dos impactos e como eles se relacionariam entre si. 

Com isso, o time terá clareza na visualização e poderá checar quais são os próximos desafios. Cabe ressaltar que é uma atribuição do PO manter a lista atualizada e de acordo com as necessidades dos stakeholders. Ela também deve estar disponível para que todos possam acessar e contribuir.

Como a Mooven pode ajudar nesse processo? 

Mooven foi criada em 2016 com o objetivo de auxiliar outras empresas por meio de entregas ágeis. Levando isso em conta, a Mooven pode ajudar em todo o processo de estruturação do modelo ágil, com a identificação do Product Onwer, com a geração do Product Backlog e com o processo de priorização a cada sprint.

Enfim, a otimização do Product Backlog pode ajudar o seu negócio a se aproximar do valor que os clientes esperam. Concentre seus esforços para deixá-lo saudável a fim de conquistar bons resultados.

Se você gostou do texto, entre em contato com a Mooven agora mesmo — nós podemos ajudar!

Como a transformação ágil pode mudar uma empresa?

Atualmente, muito se ouve falar sobre a transformação ágil e os benefícios que essa prática pode trazer para empresas dos mais variados segmentos e tamanhos. Mas você sabe o que significa realmente esse termo?

Baseada no ágil, a transformação ágil trabalha com a melhoria de processos de uma organização e impacta diretamente sua produtividade. Empresas que não seguem o ágil muitas vezes levam meses para aprovar projetos e planejar ações que, ao serem colocadas em prática após incontáveis meses, revelam já estar ultrapassadas.

Diversas instituições tradicionais e já consolidadas apostam na transformação ágil para se adaptarem a novas práticas do mercado, buscando aumentar consideravelmente sua produtividade, dinamismo, flexibilidade e qualidade dos serviços oferecidos, bem como diminuir o tempo de entrega dos trabalhos.

Como funciona a consultoria em transformação ágil?

Esse tipo de consultoria voltada à implantação do ágil em uma organização envolve algumas etapas para ser colocada em prática, que incluem, mas não se limitam a: entender os problemas da empresa que a contratou, planejar ações, executá-las, verificar os resultados e acompanhar o caso de perto para, se necessário, voltar ao começo do processo e fazer ajustes ocasionais.

É importante lembrar que não há fórmula pronta para solucionar os problemas apresentados. A consultoria avalia cada situação específica para identificar possíveis processos a serem melhorados dentro de uma empresa e aplicar um plano customizado para aquela instituição.

Essa consultoria será capaz não apenas de identificar fatores que devem ser trabalhados na empresa, mas também de planejar e colocar em prática as melhores ações para que a instituição passe por todo o processo de transformação ágil.

Em que setores a consultoria atua dentro de uma empresa?

Aonde for necessária.

Apesar de muitas vezes ter foco em uma área específica, uma consultoria de qualidade sabe que, para que suas ações sejam de fato efetivas, toda a empresa deve ser envolvida, o que significa que profissionais de cada um dos setores que a compõe serão afetados pelas mudanças propostas – e devem ser treinados para acompanhar o novo ritmo de forma, é claro, ágil.

Vale ressaltar que esse treinamento não é algo que acontece da noite para o dia, e que podem levar horas, dias, semanas ou até mesmo meses. Mas o resultado é observado e sentido com entregas constantes de alta performance. Se um funcionário não estiver alinhado com o ágil, principalmente gestores, que devem ser multiplicadores da transformação ágil para outros colaboradores, as chances de não atingir uma boa taxa de sucesso são altas, o que evidencia a necessidade de garantir a adesão de profissionais de diferentes níveis da empresa ao processo de mudança.

Como escolher a consultoria ideal?

Primeiramente, é necessário analisar o portfólio da consultoria que está pensando em contratar e observar as empresas para as quais ela prestou ou presta seus serviços, já que estas podem revelar muito sobre o tipo de trabalho que a mesma exerce.

É interessante prestar atenção também aos valores e objetivos dessa consultoria. Se eles não estiverem alinhados com os da sua empresa, é possível que a transformação não seja tão eficaz quanto poderia se ambos contratante e contratada estivessem em completo acordo.

Além disso, algumas empresas, com o intuito de economizar, selecionam seus próprios profissionais para introduzir a cultura ágil dentro da instituição – o que na grande maioria das vezes se revela um “tiro no pé”.

Isso porque profissionais internos muitas vezes já desenvolveram certos vícios na empresa, e não conseguirão se livrar deles com tanta facilidade, ou mesmo perceber que aquele hábito é ruim ou prejudicial para a instituição.

Por isso, escolher alguém que nunca teve um grande contato com os processos de sua empresa é o ideal, para que assim seja possível perceber mudanças que são necessárias no ambiente com mais facilidade.

Conheça a Mooven

A Mooven já nasceu, lá em 2016, com a premissa de auxiliar nessa evolução das empresas através do ágil, e vem ao longo de seus 3 anos de atuação trabalhando com grandes instituições e transformando suas rotinas com base em análises e estudos específicos para cada caso.

Entre em contato conosco para que possamos conversar sobre as possibilidades de transformação ágil na sua empresa!

]]>

Enfrentando e superando os desafios do desenvolvimento ágil de softwares

O desenvolvimento ágil de software é visto por muitas organizações como um método de extrema eficiência. No entanto, sua implementação pode gerar algumas dúvidas, não é mesmo? Afinal, quais seriam os principais obstáculos para aplicá-lo?

Foi pensando nisso que criamos este texto. Ao longo da leitura, você entenderá quais são os principais desafios dessa forma de desenvolver e o que pode ser feito para enfrentá-los. Aproveite o conteúdo!

Como funciona o desenvolvimento ágil?

Abertos às mudanças em qualquer fase do projeto, os modelos ágeis de desenvolvimento — Scrum, XP, ASD Crystal etc. — ganharam inúmeros adeptos durante o século 21.

Atualmente, são empregados por organizações que se destacam no mercado em relação a práticas inovadoras, como Google, Intel, Yahoo e Microsoft. A independência da equipe e foco na satisfação dos clientes são exemplificações nítidas dos benefícios que eles proporcionam. 

Quando aplicados à produção de softwares e soluções digitais em geral, eles viabilizam a elaboração de adaptações contínuas e incrementais para os projetos.

A visão ágil também contribui muito por definir prioridades específicas de acordo com o andamento dos processos. Assim, ocorrem entregas parciais, que possibilitam perspectivas prévias e a realização de testes para corrigir erros e alcançar os resultados esperados. 

Em poucas palavras, eles são mais recomendadas para desenvolvimentos que exigem mudanças com frequência ou cujos requisitos envolvidos são passíveis de alterações.

Também tendem a ser mais bem aproveitados em equipes pequenas, que têm até 10 integrantes — o que não quer dizer que eles não sejam aplicáveis em times numerosos. 

Quais os principais desafios do desenvolvimento ágil de softwares?

O desafio mais característico enfrentado pelas empresas que utilizam esses modelos é conseguir atingir por completo as expectativas de seus clientes.

Na maioria das vezes, isso acontece por uma questão de cultura organizacional, tendo em vista que muitos empreendimentos não se prepararam adequadamente para enxergar valor em entregas parciais.

Outro fator que ajuda a explicar esse impasse é o fato de a transformação digital ainda ser recente em muitas corporações. Assim, há certa dificuldade em conseguir demonstrar a eficiência que os métodos ágeis podem ter. 

Em algumas situações, o cliente pode querer ver algo pronto ou concretizado no projeto que está sendo desenvolvido. Contudo, grande parte das metodologias utilizadas (Scrum e afins), funciona a partir de entregas parciais e prioritárias, com o objetivo de chegar com agilidade ao MVP (Produto Viável Mínimo), que consiste no demonstrativo de funcionamento mínimo do software. 
 
Imagine um app com 10 funcionalidades, por exemplo. Nesse caso, há como priorizar e entregar as 3 principais e depois analisar quais serão entregues ao longo das etapas.

Depois disso, são feitas as entregas incrementais, que vão compondo o aplicativo até alcançar a versão final. Ao conhecer uma funcionalidade por vez, pode-se ter respostas e reações rápidas.

Sendo assim, é importante mostrar ao cliente que ele ganha tempo e pode chegar a um resultado bem mais satisfatório. Em contrapartida, a entrega não acontece de uma vez — o desenvolvimento evolui com o tempo e possibilita alternativas como a prototipação para reduzir erros e alinhar expectativas.

Lembre-se que essa noção pressupõe uma quebra de paradigma e é por isso que os benefícios devem ser ressaltados constantemente.

Como lidar com os prazos?

Para andar em dia com os prazos do projeto, é necessário definir o escopo e as prioridades. Com base nessas informações, há como fazer estimativas para saber quanto tempo leva cada estágio e assim definir sprints que vão de 1 a 4 semanas.

Com base na extensão do sprint e no tamanho do time alocado no projeto, a capacidade é definida. Isso é importante para contextualizar os clientes e deixá-los um pouco mais por dentro do desenvolvimento. 

Como montar uma equipe?

A montagem do time depende da necessidade e da natureza do projeto. Normalmente há o Scrum Master, alguém responsável pelo controle de qualidade e, caso seja necessário organizar a infraestrutura, um arquiteto de dados.

Eventualmente, podem aparecer outras necessidades, como desenvolvimento mobile web, mas tudo depende da demanda da cliente.

Quais são as vantagens do desenvolvimento ágil?

De acordo com um estudo publicado pelo Laboratório de Engenharia de Software do Departamento de Ciência da Computação UFMG, que desenvolveu alguns pilotos a partir de métodos ágeis, muitos benefícios foram observados.

Poder visualizar a situação e o progresso do projeto é extremamente vantajoso para a equipe responsável e para os stakeholders. Consequentemente, também cresce a capacidade de tomar decisões para contornar eventuais problemas.

Os pesquisadores também apontaram que, durante a execução dos pilotos, os desenvolvedores e outros membros do time se engajaram gradativamente, conforme percebiam os progressos alcançados.

Constatou-se, ainda, que o produto final teve maior valor, porque exigiu-se menos esforço para lidar com funcionalidades pouco relevantes. Sendo assim, a atenção adicional para os requisitos-chave foi recompensada. 

Ao concluir a pesquisa, os especialistas destacam que, apesar das dificuldades iniciais, as vantagens se mostraram muito significativas, levando o laboratório a priorizar a aplicação de metodologias ágeis em seus projetos. 

Por que sua empresa deve ser ágil? 

Para além de desenvolver apps com UX e UI impecáveis, é válido considerar o desenvolvimento ágil de softwares em sua empresa como uma rotina. Afinal de contas, como demonstramos ao longo do texto, são muitos os benefícios que ele proporciona, embora tenha, é claro, seus próprios desafios. 

Evidentemente, mudar uma cultura tradicional devidamente estabelecida não é algo simples de se fazer, bem como montar equipes totalmente adaptadas ao ágil. 

A integração entre pessoas e departamentos também deve ser considerada, porque promove a descentralização das autoridades. Desse modo, cada membro da equipe terá independência em sua área de atuação e, ao mesmo tempo, precisará se manter alinhado às demandas gerais do projeto. 

Para contar com todo o suporte necessário para essa implementação, uma consultoria de tecnologia é extremamente bem-vinda, porque pode ajudar na montagem da equipe e coordenar toda a execução. Dê preferência a uma empresa que seja 100% ágil, com uma maioria de profissionais formados em agilidade.

Enfim, o desenvolvimento ágil de software requer inovação e, por isso, também carrega consigo alguns obstáculos a serem superados. Ainda assim, ele pode fazer muita diferença em sua organização. 

Se você precisa de auxílio com métodos ágeis, tecnologias e inovações, entre em contato conosco — nós podemos ajudar!

Método ágil: o que é e quais são os seus princípios?

A velocidade de entrega dos resultados de uma empresa, muitas vezes, está diretamente relacionado à estrutura dos processos de produção. Quanto maior e melhor estruturado o planejamento, maior o sucesso dos procedimentos.
Hoje, a inserção de técnicas que agilizam as etapas de produção com foco na qualidade do produto é um desafio para grande parte das instituições. Por isso, no post de hoje, vamos conhecer as origens dos métodos ágeis e como sua aplicação se tornou indispensável para empresas de todos os portes. Acompanhe!

As origens do método ágil

Para entendermos o que são os métodos ágeis e como eles impactam diretamente as soluções das empresas, antes, precisamos revisitar um método mais antigo e robusto chamado Lean.
O Lean é uma série de práticas aplicadas inicialmente em “chão de fábrica” nos processos fabris, e era utilizado na produção de bens manufaturados. Com ele, os produtos e serviços eram criados e distribuídos em quantidades exatas, no local certo, na hora certa e para o público certo.
Esse método ficou muito famoso no Japão por causa da Toyota, que estruturou todo o seu processo de produção com a finalidade de eliminar eventuais desperdícios.
Por estarem inseridos em uma época de escassez, causada pelo período pós guerra — por volta de 1940 até meados de 1950 — a perda de tempo e de materiais poderia ruir qualquer negócio. Sendo assim, tornou-se necessário uma criatividade aguçada que fosse capaz de refletir no tempo total da entrega (Leadtime).
O grande autor desse movimento é conhecido como Taichi Ohno, naquela época chefe das linhas de produção da Toyota. Ohno descreveu em um dos seus livros “Gestão dos Postos de Trabalho” que sempre buscou a melhoria continua de sua linha de produção, com muita observação nos processos e experimentação, adaptando-se para uma melhor performance, eliminação de desperdícios e qualidade como diferencial positivo.
As práticas Lean inspiraram o que hoje chamamos de métodos ágeis, que também visam a otimização das estruturas de produção, somadas a tecnologias adequadas para cada modelo de negócio, como conheceremos melhor a seguir.  

A definição do método ágil

O Método ágil — derivado do termo americano Agile — é uma forma de agir e pensar na gestão da empresa, departamento ou projeto, que pode impactar diretamente na produtividade.
O método consiste na aplicação de técnicas inteligentes na rotina de um negócio, que visa uma forma de agilizar a comunicação, mensurar resultados, facilitar o acesso aos dados por todos os envolvidos na corporação e antecipar entregas que tenham valor para os clientes.
Toda estratégia que visa a eliminação de qualquer tipo de desperdício — seja de tempo, de capital, de material etc. — estrutura-se como um potencial ágil.
O termo “ágil” é novo. Contudo, desde 2006 já existem ações estratégicas voltadas a esse tipo de serviço. A novidade não está na existência do método, mas sim, no quão importante o “ágil” se tornou na resolução dos desafios empresariais.

Técnicas que andam em conjunto com o método ágil

Por consistir em uma forma de se fazer a gestão, os métodos ágeis podem ser aplicados em conjunto com algumas ferramentas, entre elas, o design thinking, e a prototipação.

Design Thinking

Design Thinking é o conjunto de métodos e práticas de abordagem que objetiva resolver problemas relacionados a aquisições de informações, análise de conhecimento de situações e propostas de soluções.
Essa prática conta com técnicas de entrevista, pesquisa de política da empresa, questionários com os clientes e muitas outras. Além disso, vem ganhando adeptos ao redor do mundo por ter estudos aprofundados em Berkley, Massachussets e outras grandes instituições de ensino.

Prototipação

A prototipação é uma etapa do desenvolvimento de softwares que impacta na produtividade da equipe e nos resultados entregues ao cliente. É o processo que colabora com o entendimento do software que será desenvolvido.
Propõe melhorias, diminui riscos e aumenta os lucros. Podem ser visuais, escritos ou interativos.
Caracterizam-se como grandes aliados dos métodos ágeis de desenvolvimento por garantirem um maior alinhamento entre a equipe e o cliente.

Aplicando ágil em projetos

Na prática, é preciso ter muito conhecimento para aplicar técnicas que auxiliem projetos se tornarem de fato ágeis.
Para adotar os projetos ágeis é preciso que as empresas tenham ou adquiram uma certa maturidade. Essa maturidade consiste no abandono de modelos tradicionais de negócio e na adoção de práticas modernas e integradas.
Um exemplo prático: a área de TI de uma empresa atende diversas demandas das áreas de negócio. Se a área de TI não tiver uma estratégia definida de como solicitar essas demandas em um modelo estruturado, não é possível fazer uma previsão de processos e entregas daquela operação. É preciso que a empresa adote ações estruturais para depois adotar um modelo ágil de gestão.

Projetos em Cascata e GoHorse

Um framework feito no método ágil demanda muita organização, então as empresas acabam se confundindo. Existe uma dicotomia que ronda o termo “ágil”. As empresas acreditam que trabalham ou em um método ágil, ou em um modelo cascata, quando, na verdade, trabalham com outro modelo chamado Go Horse.
O modelo cascata (ou top down), em engenharia de softwares, consiste no desenvolvimento de projetos sequenciais em que a primeira etapa de produção se direciona para a segunda e assim sucessivamente. É extremamente documental (texto, infográficos e simulações) e funciona como base para projetos modernos.
Porém, quando existe pressa, falta planejamento e as outras opções de desenvolvimento não são consideradas, o trabalho entra no método Go Horse (ou extreme Go Horse). É o famoso “sigo as minhas regras”, o que é muito comum nas empresas.
Nesse método, para cada problema resolvido, outros são criados, além de serem baseados no esforço e não na entrega.
Para diferenciar esses modelos, na prática, vamos considerar uma equipe hipotética de dez pessoas que trabalharão por um período de 5 meses em um projeto. O gestor cria métodos que ocupam o tempo dos funcionários por esse período. No modelo ágil, a preocupação não é com o volume de trabalho, e sim, com a entrega. Primeiramente analisa-se a demanda para depois definir a entrega, priorizar as etapas, fazer o planejamento e escalar a equipe por atributos.
Por isso é preciso a participação integrada de todos os envolvidos em uma corporação. Não adianta, por exemplo, uma equipe de TI que precisa de um novo profissional para entregar um projeto e a equipe de RH demorar 6 meses para contratar essa pessoa. Esse é um exemplo de imaturidade na operação.
Contudo, não existem limitações para adotar as práticas ágeis. Estudiosos acreditam que dentro de 10 anos não haverá outro modelo de produção.
E para adotar as práticas mais assertivas para o seu modelo de negócio, torna-se essencial o trabalho em conjunto com uma consultoria de tecnologia, que cria dinâmicas integradas, direciona as tomadas de decisão e insere na organização os melhores aceleradores para cada tipo de organização.

O trabalho da Mooven com os projetos ágeis

A Mooven é uma empresa de consultoria, design e tecnologia, especializada na entrega Ágil de estratégias e soluções digitais que trabalha de ponta a ponta em empresas das mais diversas maturidades.
A missão da Mooven é adicionar novas práticas de pensamento, filosofia, e técnicas de gestão eficazes para promover essa agilidade na empresa. E para isso, ela faz uso das práticas de comunicação mais eficientes do mercado, fazendo a transformação corporativa e da área de TI.
Por não acreditar em mágica e sim em processos estruturais, podemos destacar a agilidade dos resultados que são obtidos a curto prazo, e até, muitas vezes, de imediato.
Além de levar um “big picture” para as empresas, a Mooven é dotada de expertise em práticas vencedoras para cada tipo de negócio, seja ele muito ou pouco maduro, promovendo a parceria com a área de governança, seja de TI, ou corporativa.
Esse trabalho em conjunto é indispensável para desenvolver a maturidade das empresas. Quando é feito a análise dos problemas encontrados na corporação, muitas vezes são diagnosticados profissionais que não estão indo bem, pessoas que não concordam com os projetos apresentados, e outros impedimentos que só podem ser resolvidos com a ajuda da governança.
E dessa forma, foram entregues projetos de sucesso e responsáveis por alavancar os resultados de empresas conhecidas não só em território nacional, mas em todo o mundo.
Agora que você já sabe como os métodos ágeis podem otimizar os processos internos do seu negócio, entre em contato com a Mooven e conheça mais da nossa consultoria em método ágil.]]>