Tag: Scrum

Como transformar o Burndown Chart da sua equipe Scrum: crie uma corrida de Burndown Kart

Publicado em por .

Comecei um trabalho recente como Agile Coach para uma grande consultoria em um projeto para um grande cliente. Fui chamado para atuar com o projeto já em andamento para otimizar a aplicação de Agile — o primeiro trabalho foi ajudar a identificar um MVP que atendesse melhor o cliente, e em seguida trabalhar junto à equipe para calibrar o andamento dos sprints.

A equipe do projeto é formada por quinze pessoas divididas em três times que trabalham de forma bastante próxima e interdependente, inclusive compartilhando o mesmo Scrum Master, o mesmo Product Owner e as mesmas cerimônias de planejamento, revisão e retrospectiva.

O cliente usa o Jira para controlar o backlog das histórias e dos sprints, mas internamente a equipe faz o acompanhamento efetivo das tarefas em um quadro de kanban. A equipe não usa o Burndown Chart do próprio Jira, muito por conta da ferramenta não considerar sub-tarefas, o que cria um gráfico que não tem muita praticidade para a equipe. O kanban dá uma ótima visibilidade das tarefas em andamento e das pendências, mas a equipe sentia falta de informações de progresso de sprint que o burndown ajuda a visualizar. Decidimos então criar um burndown próprio, representado ao nível de sub-tarefas.

Fora do horário de trabalho, um dos hobbies da equipe, além dos happy-hours, é andar de kart. Uma corrida recente gerou histórias durante dias — quem ganhou, quem ficou para trás, quem saiu da pista e perdeu posições. Mais de uma pessoa contou sobre o momento em que saiu da pista e teve dificuldades para voltar, perdendo posições e comprometendo o resultado da corrida.

Foi nesse comentário sobre “sair da pista” que surgiu a ideia: e se criássemos o Burndown Chart justamente como uma corrida de kart?

O BURNDOWN KART

O Kart Azul está fazendo uma ótima corrida, adiantado em relação ao planejado. O Kart Vermelho saiu da pista, voltou, e está saindo novamente - equipe precisa reagir. O Kart Verde está fazendo uma corrida com muitos problemas e requer ação urgente da equipe

No exemplo acima o Kart Azul está fazendo uma ótima corrida, adiantado em relação ao planejado. O Kart Vermelho saiu da pista, voltou, e está saindo novamente — equipe precisa reagir. O Kart Verde está fazendo uma corrida com muitos problemas e requer ação urgente da equipe

Para criar um Burndown Kart tivemos que adaptar algumas ideias em relação ao burndown tradicional.

O primeiro ponto é que é legal treinar solo em um circuito próprio, mas é mais legal correr com mais carros na mesma corrida. No nosso caso, como temos três equipes bastante próximas em um mesmo projeto, temos o cenário ideal para projetar os três carros juntos. Mas ao mesmo tempo, cada equipe tem uma quantidade de pessoas, backlogs e story points diferentes umas das outras. Para termos os três carros no mesmo circuito, decidimos normalizar o eixo Y com porcentagens ao invés de horas ou story points. Dessa forma todos os carros começam juntos em 100% e correm juntos até chegarem em 0%, não importando quantas tarefas tem os seus backlogs ou quais as suas velocidades particulares. Vale adicionar que as três equipes começam e encerram os sprints nas mesmas datas — equipes que trabalham com datas diferentes já não caberiam na mesma corrida.

Representação da pista: linha tracejada representando o baseline planejado, e os limites da pista representando margens de desvio de 10%

O segundo ponto é em relação à própria pista. Em um gráfico de burndown tradicional nós temos um baseline de referência, e o mais comum durante o sprint é não seguir precisamente em cima da linha, mas flutuar acima ou abaixo do planejado. Já em um circuito de kart nós temos um espaço da pista por onde os carros andam, limitado pelas beiras da pista. Para o nosso gráfico nós não queríamos considerar a pista inteira como o baseline, porque os carros passariam a maior parte da corrida fora da pista, dando a impressão de fazerem uma corrida ruim. Nós queríamos que os carros corressem dentro da pista. Então decidimos considerar o meio da pista como o baseline (representado por uma faixa tracejada), e criar uma margem de desvio de 10% — ou seja, se uma equipe estiver até 10% atrasada ou até 10% adiantada, seu carro ainda estaria dentro da pista, o que representa que a corrida está indo bem. Mas se a equipe estiver mais de 10% atrasada ou adiantada, seu carro sairia da pista, exigindo ação imediata da equipe.

O terceiro ponto era que inicialmente estávamos com receio de criar um sentimento de competição entre os times, ou uma equipe “ganhar” da outra. Mas na prática, como o eixo X representa tempo e todos os carros estão sempre no mesmo dia, a impressão é de estarem sempre alinhados, somente com a diferença de estarem dentro ou fora da pista. Com isso a leitura acaba sendo mais de estarem correndo juntos do que em uma competição um contra o outro.

grafico-equipe

E o quarto ponto e mais importante: definimos que o único critério para os carros se manterem na pista são tarefas no status de Done. Não contamos horas trabalhadas, porcentagens de andamento, tarefas In Progress ou In Review — somente Done.

E aí foi só esquentar os motores e preparar o grid de largada.

E FOI DADA A LARGADA

Durante a corrida o objetivo da equipe é manter o kart sempre dentro da pista. Quando um carro ameaça derrapar e sair da pista, o time precisa tomar alguma medida, replanejando tarefas para que o carro volte à pista. Por exemplo, observar se existem muitas tarefas em paralelo segurando o andamento do sprint, ou se temos muitas pendências de aprovação com o Product Owner. Nesse ponto o quadro de kanban ajuda muito a interpretar o andamento da corrida e a tomar decisões para reposicionar os karts.

Time Verde tem muitas tarefas In Progress e In Review e poucas Done - kart fora da pista. Time Vermelho está entregando uma boa quantidade de tarefas, mas a quantidade In Review está crescendo - kart ameaçando derrapar para fora da pista. Time Azul limita seu WIP e já tem várias tarefas Done - kart dentro da pista

No exemplo acima o Time Verde tem muitas tarefas In Progress e In Review e poucas Done — kart fora da pista. Time Vermelho está entregando uma boa quantidade de tarefas, mas a quantidade In Review está crescendo — kart ameaçando derrapar para fora da pista. Time Azul limita seu WIP e já tem várias tarefas Done — kart dentro da pista

E o mais importante é que os conceitos de Agile e Lean são aplicadas nessa corrida — impedimentos afetam a corrida e requerem atenção; muitas tarefas In Progress e In Review fazem o carro derrapar e sair da pista; limitar WIP e criar fluxo contínuo são praticamente um motor em turbo mode.

Estamos no segundo sprint usando essa ideia, e tivemos uma reação bem legal das equipes — a leitura é direta e intuitiva para a equipe e para o cliente, os karts saindo da pista estão gerando boas discussões e replanejamentos, e os retornos à pista estão gerando incentivos e torcidas. A brincadeira criou uma forma legal de acompanhar o sprint, de uma forma muito mais efetiva do que um gráfico de burndown tradicional.

FERRAMENTAS

No nosso projeto criamos duas ferramentas de Burndown Kart: uma exposta em uma das paredes em que usamos fitas adesivas, e outra no Google Sheets para controlar as tarefas e calcular as posições dos carros. No quadro na parede usamos fitas adesivas para delimitar a pista e o baseline, e os carros usamos botões magnéticos que encontramos na papelaria, mas colados com fita dupla face. Quem quiser incrementar o quadro com bandeiras, faixas de largada e chegada, torcidas etc, é só desenhar.

Planilha no Google Sheets que gera os gráficos

O cálculo detalhado da corrida é feito em uma planilha compartilhada no Google Sheets que gera os gráficos automaticamente. Os cálculos incluem as porcentagens de acordo com a quantidade de tarefas e de dias do sprint, as margens (-10% e +10%) para desenhar a pista, e o andamento dos nossos três karts. E também criamos linhas de tendência baseadas no histórico de andamento de cada carro para ajudar a prever o final da corrida. Aqui tem um exemplo com um sprint de três semanas e três karts para quem quiser adaptar para o seu próprio projeto.

Se tiverem comentários e sugestões fiquem à vontade para comentar. Quem decidir usar essa ideia compartilhem aqui os resultados. E boas corridas!

Agradecimentos: Douglas Monteiro

No alt text provided for this image

Scrum Guide: o manual que todo mundo deveria ler

Publicado em por .

Criado no início da  década de 90 como um método revolucionário de resolução de problemas e execução de projetos de software, o Scrum passa por atualizações eventuais. E não é para menos: estamos falando de um processo totalmente sintonizado com as novas demandas do mercado, razão pela qual seus idealizadores, Ken Schwaber e Jeff Sutherland, lançaram em 2017 a mais nova versão do Scrum Guide.

Trata-se de um guia simples e direto ao ponto que traz as principais inovações do Scrum. Aqui, você pode baixar a versão do manual em português gratuitamente.

No documento, os autores apresentam as principais funcionalidades deste método ágil:

  1. Pesquisar e Identificar mercados viáveis, tecnologias e funcionalidades de produtos; 
  2. Desenvolver produtos e melhorias; 
  3. Liberar produtos e melhorias frequentes, chegando a várias vezes por dia;
  4. Desenvolver e sustentar a Nuvem (online, segura, sob demanda) e outros ambientes operacionais para uso de produtos;
  5. Sustentar e renovar produtos;

Onde aplicar?

Estas metas podem ser aplicadas a várias áreas, e não apenas ao desenvolvimento de softwares, mas também em recursos humanos, redes de funções interativas, veículos autônomos, escolas, setor público, marketing, mobilidade urbana, entre outras atividades da produção de conhecimento e da economia.

Depois de muito se falar sobre Scrum – inclusive coisas pouco fundamentadas, os autores resolveram pacificar a questão no Scrum Guide ao mencionar a principal filosofia do método: a experiência com erros e acertos passados deve ser usada para tomar decisões com base no que é conhecido. Portanto, apesar de ser inovador, o método não pressupõe que a equipe vá reinventar a roda. Todos dão suas contribuições nas reuniões diárias (Daily  Scrum) para amortizar os riscos e aperfeiçoar o produto final.

O guia apresenta ainda as quatro etapas fundamentais de cada estágio do processo (sprint), que deve durar em média um mês: Planejamento do Sprint, durante a qual o líder (Scrum Master) e o responsável (Product Owner) dialogarão com a equipe a respeito das metas a serem empreendidas; Reunião Diária (Daily Scrum), que deve ser rápida e objetiva; Revisão do Sprint, com propositura de melhorias no produto em construção; Retrospectiva do Sprint, a partir da qual o time está apto para o próximo Sprint com a aplicação sistemática de kaizen de processo.

De acordo com o Scrum Guide, o Sprint é o “coração” do Scrum, e é por isso que essas etapas devem estar bem sintonizadas.

Definições

De um modo geral, a versão mais recente do Scrum Guide traz poucas alterações com relação ao documento de 2016. A seção de reuniões diárias foi atualizada, e agora é composta pelas seguintes perguntas – feitas pelos membros do time:

  • O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir a meta do Sprint? 
  • O que eu farei hoje para ajudar o Time de Desenvolvimento atingir a meta do Sprint? 
  • Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atingimento da meta do Sprint?

Para ajudar sua empresa ou sua equipe a entender melhor os propósitos dos métodos ágeis, a Massimus tem vários treinamentos específicos para cada profissional envolvido, como o Certified Scrum Master. Você pode solicitar um atendimento personalizado no próprio site, para receber nossas propostas pedagógicas mais indicadas para o seu perfil.

 

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.

Agile Software Development otimiza e diversifica novos projetos

Publicado em por .

Já mencionamos aqui como as os processos ágeis podem ajudar no funcionamento das organizações. O Agile, como é conhecido esse conjunto de princípios, prega o protagonismo dos indivíduos e das interações, dos produtos e dos serviços, e propõe um novo paradigma organizacional: a colaboração com os clientes vale mais que o fechamento de novos negócios. Já o Agile Software Development (desenvolvimento ágil de software) empresta esta filosofia para uma área crucial da inovação e da criação de novos produtos – a engenharia de softwares. Para entender melhor como isso funciona, vale lembrar as principais características dos processos ágeis: 

– Capacidade para funcionar em ambientes turbulentos;

– Ideal para momentos de constantes mudanças, como novos concorrentes, produtos ou modelos de negócio;

– Indicado para equipes novas, que eventualmente não tenham trabalhado juntas em outras oportunidades;

– E, claro, a agilidade;

Essa capacidade de resiliência se deve ao potencial dos métodos ágeis em reduzir os riscos inerentes ao desenvolvimento de softwares. Enquanto nos processos convencionais as funcionalidades do programa são adicionadas apenas ao final do projeto, nos métodos ágeis as novas ideias são testadas ao fim de cada etapa – chamadas aqui de iteração. Como um dos pilares é a comunicação, os projetos são movidos a diálogos e feedbacks em tempo real entre todos os players. Ao final, além de softwares simples e intuitivos, o cliente obtém resultados rapidamente e com arquiteturas competentes, uma vez que são empreendidas por equipes diversificadas e multifuncionais. 

O papel ​do Scrum 

O Scrum é uma das metodologias ágeis mais disseminadas e que melhor recepciona o desenvolvimento ágil de softwares. Isso porque seu roteiro de procedimentos tem tudo a ver com as iterações. Os sprints (etapas normalmente mensais) ajudam a equipe a planejar o trabalho (Sprint Planning Meeting), que será avaliado diariamente (Daily Scrum). As funcionalidades são apresentadas em uma nova etapa (Sprint Review Meeting) e revistas no Sprint Retrospective. Ao final, o ciclo é reiniciado. O esquema funciona tão bem que já há muito tempo não é adotado apenas nas organizações, mas também no contexto do serviço público. Em 2015, o então Ministério da Fazenda ​utilizou técnicas de Scrum para elaborar a gestão das edificações do órgão público. 

Capacite-se! 

Temas como o Agile Software Development e as potencialidades do Scrum fazem parte da rotina de muitas empresas, e você e sua equipe podem conhecer melhor estes procedimentos nos treinamentos oferecidos pela Massimus. Se você quer transformar a cultura organizacional de seu time, os seus objetivos estão sintonizados com os nossos. Com programas certificados internacionalmente, a empresa chancela diariamente novos perfis de gestores e colaboradores, cada vez mais integrados ao espírito de liderança, colaboração e retorno imediato. Para fazer parte dessa transformação organizacional por meio do Agile Software Development (ASD), basta clicar aqui.

Métodos ágeis são a aposta de várias carreiras

Publicado em por .

Assinado em 2001, o Manifesto para o Desenvolvimento Ágil de Software revolucionou a cultura organizacional de muitas corporações. Ao contrário do que muita gente pensa, contudo, os métodos ágeis não estão mais circunscritos apenas à rotina da programação – e hoje já são adotados em várias companhias que se valem de um ou mais pilares da cultura ágil. Vamos lembrar deles?

  • “Indivíduos e interações mais que processos e ferramentas”;
  • “Software em funcionamento mais que documentação abrangente”;
  • “Colaboração com clientes mais que negociação de contratos”;
  • “Responder a mudanças mais que seguir um plano”;

Como percebemos no dia-a-dia, muitas atividades econômicas, áreas do conhecimento e carreiras levam essas diretrizes em suas rotinas, razão pela qual a metodologia ágil já superou há muito tempo a exclusividade do desenvolvimento de softwares. Há exemplos de bancos, empresas de monitoramento, startups, produtores de jogos digitais e firmas de gestão de pessoas que já adotam esses procedimentos.

No caso dos recursos humanos, por exemplo, as técnicas ágeis podem ser aplicadas nos processos de delimitação das vagas, recrutamento de profissionais e prospecção de novos talentos. Na medida em que a empresa sabe o time que quer formar, fica mais fácil estabelecer processos rápidos de seleção: é possível, por exemplo, suprimir a necessidade de entrevistas com todos os candidatos, apenas com uma triagem mais competente dos currículos. Reuniões diárias – uma das sugestões do Scrum – podem dar aos responsáveis pelo recrutamento uma noção mais clara sobre o perfil dos concorrentes que buscam pelo cargo ofertado.

Todos os portes

Cada vez mais em evidência, os clubes de assinatura de serviços, na maioria das vezes ligados a dispositivos móveis, são pequenas ou médias empresas para as quais as metodologias ágeis têm sido muito úteis. Ao estabelecer uma rotina eficiente e enxuta de definição de público-alvo, captação de clientes e distribuição, a empresa consegue atingir o que o cliente mais almeja neste mercado: a rapidez.

Um outro case conhecido é o da Toyota, famosa pela criação da técnica Kanban – modelo que ajuda a equipe a visualizar as tarefas a serem executadas por meio de uma distribuição espacial alternativa das atividades. À equipe, cabe respeitar o fluxograma de trabalho e propor adaptações, sempre que necessário.

Ligadas ao desenvolvimento de softwares, as plataformas de educação a distância podem e devem aderir à cultura ágil. Ao desburocratizar processos e entender com competência as dificuldades dos alunos, os grupos pedagógicos conseguem otimizar o aprendizado por meio de sistemas informativos e intuitivos. E a técnica vai ao encontro do mercado atual: no ano passado, as ofertas de cursos em EaD aumentaram 17,6%, de acordo com o Censo da Educação Superior.

Outras áreas receptivas às metodologias ágeis

  • Instituições financeiras;
  • Marketing;
  • Serviços;
  • Indústrias criativas e inovação;
  • Gestão de marcas;
  • Setor público;

Se você procura capacitação para entender ainda mais sobre as metodologias ágeis, por mais diversificada que seja sua área de atuação, a Massimus pode ajudar você e sua equipe com treinamentos competentes e definitivos. Se quiser conhecer um deles, basta clicar aqui.  

 

O que é PMBOK e como ele atua na gestão de projetos?

Publicado em por .

O PMBOK é um guia desenvolvido para sistematizar e divulgar as melhores práticas no gerenciamento de projetos. PMBOK é a sigla em inglês para Project Management Body of Knowledge, que em português pode ser traduzido como Guia do Conhecimento em Gerenciamento de Projetos.

Elaborado pelo PMI – Project Management Institute, uma das maiores associações para profissionais de gerenciamento de projetos do mundo, e que oferece treinamentos, formações e certificações de padrão global, o PMBOK está atualmente em sua 6ª edição.

A primeira edição do Guia foi lançada em 1996, e de lá para cá, geralmente, as atualizações são lançadas de 4 em 4 anos. A última edição, a de número 6, foi lançada em 2017.

Como o Guia PMBOk propõe-se a oferecer uma visão ampla sobre o gerenciamento de projetos, ele identifica e classifica técnicas, ferramentas, áreas de conhecimento e processos. Ele, no entanto, não é uma metodologia, ou seja, não é prescritivo, mas sim um compilado das melhores práticas e experiências do gerenciamento de projetos em nível global.

Estrutura do PMBOK

Os três primeiros capítulos dizem respeito ao gerenciamento de projetos de forma ampla, com a definição de conceitos, elementos, estruturas organizacionais e sobre o gerente de processos e as competências que dele se espera.

Nos capítulos seguintes, do quarto para frente, é que são descritos e apresentados, em detalhes, os processos e como eles interagem entre si.

 O Guia PMBOK está estruturado em 10 áreas do conhecimento, a saber:

  • Gerenciamento da Integração
  • Gerenciamento do escopo
  • Gerenciamento do cronograma
  • Gerenciamento dos custos
  • Gerenciamento da qualidade
  • Gerenciamento dos recursos
  • Gerenciamento da comunicação
  • Gerenciamento dos riscos
  • Gerenciamento das aquisições
  • Gerenciamento das partes interessadas

Além das 10 áreas de conhecimento, há também 5 grupos de processos, que são os seguintes:

  • Iniciação
  • Planejamento
  • Execução
  • Monitoramento e controle
  • Encerramento.

Cada um desses grupos de processos prevê o emprego e gerenciamento de determinadas áreas do conhecimento. Por exemplo, dentro do grupo iniciação são trabalhados processos referentes às áreas de conhecimento “gerenciamento da integração” e “gerenciamento das partes interessadas”

A 6ª edição do PMBOK traz, ao todo, 49 processos. Esses processos, por sua vez, podem ser compreendidos por meio de fluxos que sucedem uns aos outros ou, em algumas fases do projeto, ocorrem simultaneamente.

A grande vantagem do PMBOK é oferecer uma base comum de compreensão das fases para todos os envolvidos no projeto. Ou seja, todos os envolvidos compreendem o que precisam fazer para a estruturação do projeto. 

A dinâmica e fluxo dos processos

O primeiro grupo de processos é a iniciação. Nele, desenvolve-se o Termo de Abertura do Projeto (integração) e delimita-se as partes interessadas, os stakeholders indispensáveis à consecução do projeto (partes interessadas).

A fase seguinte é a do grupo de processos do planejamento. Aqui, o gerenciamento do escopo, do cronograma, dos custos, dos recursos, da qualidade e da integração são colocados em prática, dando corpo para a fase seguinte do projeto, que é a execução.

Agora que o projeto está planejado é, portanto, hora de colocá-lo em prática. Antes de mais nada, vale dizer que é aqui também que os grupos de processos relacionados ao monitoramento e controle também ocorrem. Ou seja, ao mesmo tempo em que executo, também analiso o que estou fazendo. É um processo contínuo.

Além do gerenciamento da execução do projeto propriamente dita, é também aqui que será gerenciado o conhecimento do projeto, ou seja, garantir que as lições sejam aprendidas. É nesta etapa que a qualidade, riscos e a comunicação são gerenciados, os recursos humanos e materiais são adquiridos etc.

Por fim, segue-se para o encerramento do projeto ou da fase, analisando-se os dados obtidos e comparando as entradas com as saídas do projeto.

Métodos ágeis no PMBOK?

O Guia PMBOK, como vimos, traz uma série de processos concomitantes e encadeados, que se sucedem em fases. Ele é, portanto, considerado por muitos um guia para projetos em cascata, em que primeiro se planeja, depois se executa e monitora e, somente no final, entrega-se algo com valor.

A 6ª edição, no entanto, tem como um de suas principais novidades a inserção de ferramentas específicas dos métodos ágeis em cada uma das áreas do conhecimento. Há em cada capítulo uma seção com Considerações para Ambientes Ágeis/Adaptativos, que mostra como as abordagens “tradicionais” e ágeis podem se complementar.

Há também diversas outras alterações nesta última edição. Dentre elas, podemos citar que: os 3 primeiros capítulos foram reescritos, houve uma expansão da descrição dos tipos de estruturas organizacionais, mudanças nos nomes de 2 áreas de conhecimento, inclusão de novos processos, remoção e alteração de outros. Um resumo das alterações pode ser visualizado aqui, em um vídeo da própria PMI (está em inglês).

Um curso que explora a convergência entre o Scrum e o PMBOK

Para quem busca uma abordagem completa sobre a interação entre a abordagem tradicional e os métodos ágeis, o curso Scrum & PMBOK para Gerentes de Projetos, da Massimus, traz tudo o que você precisa para compreender plenamente os dois mundos. O curso é divido em 3 aulas, que abordam os seguintes tópicos:

  • Modelo Tradicional vs Agile: Comparando os dois mundos, entendendo as opções.
  • Modelo APM: Fases e artefatos, entendendo as fases de um projeto e seus aspectos. 
  • Gestão de risco: Como ir além da gestão de risco tradicional.
  • Gestão de custo Real vs estimado:  Como fazer acompanhamento e controle de budget do projeto por sprint.
  • Gestão de stakeholders: sprint Release, Gerenciamento de contratos por sprint e por Release.
  • Gestão de tempo: Sprint Burndown, visão do produto, acordos de trabalho, elevator speech, road map e muito mais.

Para mais informações sobre o curso, clique aqui.

Scrum Master exerce mediação e liderança no Scrum

Publicado em por .

Com perfil sóbrio, transparente e solícito, o Scrum Master é um dos líderes-chave durante o desenvolvimento de softwares ou de outros produtos que adotam o Agile. Muito mais do que alguém que dá ordens, esse personagem é responsável por organizar a equipe durante os Sprints e ajudar o time a encontrar soluções para os obstáculos que inevitavelmente aparecem.

Antes de seguir, vamos rever alguns conceitos essenciais para esse método?

O Scrum

É um dos métodos ágeis mais adotados no desenvolvimento de softwares, baseado em Sprints (etapas) independentes, caracterizados por alta flexibilidade e participação do cliente. Ao final, o produto é entregue mais rapidamente e com maior aderência às pretensões do contratante.

Os Sprints

São caracterizados por reuniões periódicas, nas quais o time revela o que está dando certo e o que precisa ser alterado. Tudo é muito rápido, e o Papel do Scrum Master se mostra indispensável nesta hora.

De um lado, temos o product owner, focado em construir o produto da forma como foi solicitado. De outro, temos os desenvolvedores, que detêm a expertise da programação, mas nem sempre dominam a arte do diálogo e da conciliação de interesses.

O Scrum Master

Atuará como um coach para ajudar a equipe a se livrar de interferências indesejadas no processo, bem como para reunir as habilidades de cada membro do time e designar novas funções assim que os problemas acontecem.

Este profissional rompe totalmente o conceito clássico de líder – figura centralizadora e autoritária. Pelo contrário, o Scrum Master se mostra um líder servidor, que oferece ajuda para resolver os impasses, em vez de apenas cobrar resultados. Dotado de alto poder de percepção, paciência e equilíbrio, esta figura acaba agregando para si uma autoridade espontânea e respeitosa, adquirida pelo tato e pela competência.

Apesar desse perfil agregador, o líder servidor também deve ter discernimento para perceber quando o grupo não está conseguindo remover os impedimentos, e fazê-lo por conta própria.

Ficha técnica

Algumas características são desejáveis a todo Scrum Master: amplo conhecimento, não necessariamente da técnica (como fazer), mas dos objetivos (o que fazer) e do processo (quais caminhos percorrer); espírito de colaboração, a fim de estimular a troca de conhecimentos e contornar egos; transparência, sem a qual os Sprints não funcionam por pura falta de noção dos estágios; senso de proteção e responsabilidade, com intuito de manter a equipe agregada.

De um modo geral, a rotina do Scrum Master se divide entre as atividades do Scrum, no início de cada Sprint, o coaching do time, o auxílio às demais peças (product owner, por exemplo), à comunicação e à remoção de impedimentos. O tempo despendido com cada estágio varia conforme o dia do sprint.

Tantas habilidades não são adquiridas de uma hora para outra – é necessário muito treinamento e capacitação. Se interessou pela tema? A Massimus oferece treinamento específico para que você torne um Certified Scrum Master – além de disponibilizar e-books e outros materiais para ampliar seu entendimento a respeito do tema. Solicite um atendimento em nossos canais!

 

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!

Quer ajudar seu Time Scrum a organizar suas atividades? Conheça o Trello!

Publicado em por .

Considerado um “aplicativo de gerenciamento de projetos”, o Trello é uma mão na roda para quem trabalha com métodos ágeis. Disponível no browser e em app para dispositivos móveis, o programa ajuda a organizar metas, distribuir tarefas, controlar prazos, compartilhar informações e projetar os resultados. É um complemento que ajuda no gerenciamento dos projetos, não é mesmo?

A primeira vantagem do Trello é que ele é super intuitivo. São necessários poucos minutos no app para que você entenda quais suas principais funcionalidades. Mesmo assim, a gente já antecipa algumas delas por aqui.

A principal palavra para quem trabalha com este aplicativo é o “quadro”, ou board. É por meio de quadros que os projetos são gerenciados – e cada um deles pode ser compartilhado com pessoas diferentes.

Informações muito estratégicas ou que envolvam recursos humanos, por exemplo, podem compor um quadro compartilhado apenas entre o Product Owner e o Scrum Master. Cada sprint, por sua vez, pode ser distribuído para todo o time de desenvolvedores, com delimitação de prazos. 

Em cada quadro, é possível criar subdivisões (cards), nas quais você pode inserir as pautas do Daily Scrum. Ao criar o card, você já menciona quem poderá visualizá-lo – e isso pode ser alterado a qualquer momento.

Quer chamar a atenção de algum membro específico? Basta escrever algo com a @ do usuário que ele receberá uma notificação no celular e no email, se as contas estiverem vinculadas. Quer conversar com todo mundo? É só escrever @board que todos os inscritos no cartão terão acesso à mensagem.

Em anexo

Nos cards, é possível subir arquivos e colocar links com materiais de referência. Para cada tarefa concluída, basta um clique para que o material vá para o arquivo. Cards coloridos ajudam a visualizar competências e distribuição de ações.

Epa, mas isso tudo parece familiar, não? Pois é, o Trello é baseado no paradigma do Kanban – mas em vez de entupir a parede da empresa com post-its, dá para deixar tudo mais organizado por meio do app.

O mais legal é que você consegue personalizar os cartões com logo da empresa, fotos das equipes e até um cartão de descontração, no qual o grupo pode organizar o happy hour do fim do expediente, centralizar datas de aniversário e programar eventos informais.

Outras funções

Embora pareça ter sido feito para os métodos ágeis, o Trello é muito adotado também em outras áreas, como gestão de imóveis, planejamento de aulas, distribuição de tarefas em laboratórios de pesquisa, gerenciamento de casos em escritórios de advocacia e contabilidade e muitas outras atividades que envolvam times, organização de tarefas e prazos.

Mas atenção! No caso do Scrum, de nada adianta uma ferramenta como essa se falta a seu time as competências para entender os métodos ágeis e a melhor forma de organizar a equipe e se auto-organizar. Nos treinamentos da Massimus, você vai entender como isso funciona, incluindo a capacitação para postulantes a Scrum Master.