fbpx

Kanban X Scrum: qual devo utilizar no meu projeto?

Kanban X Scrum, qual o melhor para o meu projeto?

Se você gosta de gestão ágil, com certeza já caiu nessa questão. Mas afinal de contas, qual devo usar para gerenciar meu projeto? E qual deles vai se adequar melhor a realidade da minha equipe?

Bom, nesse artigo vamos ver algumas comparações entre os dois, para entender melhor as características de cada um. E no final, você poderá avaliar com mais clareza, qual deles é melhor para o seu projeto.

Kanban: Uma breve visão

O método Kanban, foi inspirado no sistema de produção Just In Time (no momento certo). A ideia é que as tarefas sejam executadas em etapas, e sob demanda. Para utilizar os recursos de forma inteligente, sem desperdício e mantendo o fluxo de trabalho em funcionamento constante.

A partir dessa ideia, foi concebido o método Kanban e seus princípios. Ele, se tornou uma ferramenta importante, e que pode ser utilizado não só como uma metodologia de desenvolvimento de software, mas também como um gerenciador do seu fluxo de trabalho.

O Kanban, assim como outras metodologias ágeis, é um processo evolucionário. Por isso, você pode começar com uma implementação simples e evoluir isso com o tempo.

Se tiver mais interesse em Kanban, dá uma olhada nesse artigo!

Scrum: Entendendo como funciona

O scrum é um framework ágil, que pode ajudar muito na organização do seu projeto e também da sua equipe. O nome scrum veio de uma famosa jogada de Rugby, onde basicamente o time todo se une para conseguir marcar o ponto.

Por esse motivo, o scrum não é apenas uma boa ferramenta para o seu projeto, ele pode ajudar também, a melhorar o processo para a equipe como um todo.

O scrum possui 3 pilares, transparência, inspeção e adaptação. Ele considera todo o time de desenvolvimento, stackholders e cliente, e com isso pode gerar um engajamento maior dos envolvidos no projeto.

Além disso, ele também é um processo evolucionário, que pode ser melhorado com o tempo e se adequar ao que sua equipe precisa. 

Se você quer entender melhor sobre o Scrum, dá uma olhada nesse artigo!

Kanban X Scrum: Principais diferenças

Agora que já falamos resumidamente de cada um, vamos falar do Kanban X Scrum e entender as principais diferenças entre eles.

Kanban

  • Fluxo puxado: As atividades são adicionadas na “esteira de produção”, conforme a demanda do time.
  • Visualização do trabalho em andamento: O board auxilia muito o gestor do projeto, a ter uma ideia do status do projeto e por isso, na tomada de decisões também.
  • Terminar mais tarefas ao invés de começar novas: Por ter um fluxo puxado, no Kanban sempre prezamos em finalizar atividades em andamento. 
  • Limitação de WIP (Work In Progress): Limitar a quantidade de trabalho em andamento no board, ajuda o time a focar mais na entrega. E limitar o WIP por coluna do board, ajuda a evitar GAPs nas fases do projeto. 
  • Maior adaptabilidade em projetos de manutenção: Pelo trabalho ser passado ao time, com o princípio “on demand“, fica mais fácil encaixar demandas de última hora no fluxo. Como bugs por exemplo.

Scrum

  • Fluxo empurrado: Normalmente através do ritual de Planning Poker, o time define quantas atividade vai entregar no período da Sprint. 
  • Papéis definidos: Apesar de ser uma framework adaptável, o scrum exige papéis que são fundamentais para ele funcionar. 
  • Eventos determinados: O scrum possui eventos definidos, que podem ter sua cadência adequada as necessidades da equipe. E todos eles com um timebox recomendado.
  • Maior dificuldade com projetos de manutenção: Apesar de ser sim possível executar um projeto de manutenção com o scrum, ele é um pouco mais complicado. Isso devido ao controle de atividades da sprint, onde o time define previamente o que vai entregar. E quando surge um bug de última hora, é preciso encaixá-lo, podendo tirar uma tarefa que estava planejada.

Mas afinal, qual devo utilizar?

Isso tudo depende do que sue projeto precisa e de como seu time funciona. Eu recomendo utilizar scrum em projetos que estão começando, e depois o Kanban quando o projeto entrar em fase de manutenção. No entanto os dois funcionam nos dois cenários. 

Kanban

Se você deseja metrificar suas entregas por exemplo e ter maior previsibilidade, o Kanban pode funcionar muito bem. Afinal você não vai se basear em estimativas, mas em um histórico do que o time já entregou.

Algumas métricas como Lead Time e Througput, são simples de controlar com o uso do Kanban e também fáceis de entender. Se quiser saber mais do assunto, leia esse artigo: Como medir os resultados do Kanban?

Scrum

Já o scrum é muito bom para ajudar a organizar a “casa”. Equipes que estão com dificuldades de priorizar suas atividades, e não tem muita regularidade nas reuniões de projeto, podem se beneficiar muito do uso scrum. 

Fazer o planejamento do que será entregue, revisar o trabalho que foi feito. E fazer uma retrospectiva de como a equipe está trabalhando, são alguns dos eventos do scrum que podem ajudar nisso.

E claro, temos o melhor dos dois mundos o Scrumban, que reúne os rituais do scrum e modelo de gerenciamento do Kanban. É uma excelente forma de trabalho, que pode auxiliar você e seu time.

No artigo de Scrum no dia a dia, eu falo um pouco sobre o uso do Kanban em conjunto, e algumas outras dicas que podem ajudar na implementação do scrum.

Extras

Para finalizar, tem também esse vídeo onde falo um pouco sobre Kanban X Scrum.

Espero que tenham gostado do artigo e que ele possa auxiliar você e seu time no momento de fazer essa escolha. Se tiver alguma dúvida, deixe nos comentários. Até a próxima!

Como melhorar a gestão de projetos?

Como melhorar a gestão de projetos dentro da minha empresa?

Sempre que falamos de gestão de projetos esse e vários outros questionamentos surgem. A verdade é que na maioria das vezes as pessoas não acreditam muito que uma gestão de projetos bem feita possa ajudá-las no dia a dia. E por isso tendem a resistir e duvidar da maioria dos processos de gestão e planejamento.

E quando falamos em agilidade então? A maioria das pessoas já começa a apontar problemas e dificuldades, antes mesmo de começar a rodar o processo.

Mas hoje não vamos falar de agilidade, o foco é como melhorar a gestão de projetos. Independentemente da metodologia, framework ou processo de trabalho que você utilize em sua empresa.

Então vamos ao que interessa!

como melhorar a gestão de projetos

Como o uso de ferramentas pode melhorar a gestão de projetos?

É fato que utilizar ferramentas para monitorar e metrificar seus processos ajuda e muito na gestão. Mas devemos sempre lembrar que é uma relação de custo benefício. Ou seja, o tempo que você investe preenchendo dados e configurando suas ferramentas, deve proporcionar facilidade no dia a dia para tomada de decisão em tempo hábil, melhorias de processo e informações de qualidade.

No quesito de ferramentas, hoje em dia estamos muito bem servidos. Temos várias ferramentas de qualidade, e de graça no mercado. Como por exemplo:

  • Trello: É uma ferramenta bem versátil, e de fácil utilização. Além de ter vários “Power-ups” que se integram a uma infinidade de outras ferramentas. Porém hoje sua versão grátis limita a apenas um power-up por quadro.
  • Pipefy: Tão ou mais personalizável que o Trello, o pipefy traz um gama bem grande de templates prontos. Que vão muito além só do desenvolvimento de software, ele também tem quadros pre-definidos para marketing, RH e várias outras áreas.
  • Meister Task: Mais voltado para o gerenciamento de equipes de desenvolvimento, ele tem várias opções de personalização para os quadros. E até temporizador, caso queira contabilizar quanto tempo cada tarefa levou para ser desenvolvida.
  • Slack: É uma ótima ferramenta de comunicação, e que serve muito bem especialmente a times de desenvolvimento. Possibilita integração com vários aplicativos, tem webhooks e vários recursos nativos interessantes, como o remider por exemplo.

Além dessas existem várias outras, e o importante é encontrar aquela que se adeque melhor a realidade do seu dia a dia. Lembre-se que sempre que falamos em melhoria, devemos considerar um processo evolucionário, então comece pelo básico e evolua de acordo com suas necessidades.

como melhorar a gestão de projetos

Por que é importante ter um processo de gestão bem definido?

Quando falamos em processo, na maioria das vezes pensamos apenas em definir suas fases. Ficamos tão focados em montar o passo a passo do processo, que algumas vezes esquecemos da importância de definir bem o que cada fase representa e quais os critérios dela.

Principalmente em processo de desenvolvimento de software, que pode envolver profissionais de áreas com diferentes diferentes como por exemplo, desenvolvedores, profissionais de QA, devops, e até mesmo clientes. Nestes casos, é preciso ter bem claro o que cada fase representa, por isso devemos definir bem os critérios de entrada e saída de uma atividade em cada uma das fases do processo.

Quais fases devo definir para melhorar a gestão do projeto?

É claro que cada projeto tem seu próprio contexto, e suas dificuldades. Sendo assim, as fases mais importantes a serem definidas mudam de um projeto para o outro, mas no geral temos algumas que são essenciais para garantir a qualidade das entregas e fluidez do processo.

Pronto para ser desenvolvido

Quando uma atividade está realmente pronta para o time começar a trabalhar nela? Quais seus critérios de aceite? Precisa ter mockup anexado, caso de teste escrito? A história do usuário está clara? Enfim, são vários questionamentos, e cabe a equipe toda em conjunto, definir o que é necessário para considerar que uma atividade está pronta para ser desenvolvida.

Pode parecer que isso tudo é muito óbvio, mas como diz um amigo meu: “as vezes o óbvio precisa ser dito”. Afinal nada pior para atrasar um time, do que começar demandas que não estão bem definidas não é mesmo?

Pronto para ser testado

Se o time possui um profissional ou equipe de QA alocada no projeto, ou mesmo se faz testes cruzados entre os devs é muito importante definir isso. 

Coisas como publicar a feature ou a correção do bug no ambiente de QA, gerar a versão de teste do aplicativo, atualizar o modelo de dados quando houver alteração. Enfim, pense em tudo que é necessário, e coloque como critério aqui. 

Pronto para ser entregue

E finalmente, quando uma atividade está pronta para ser entregue? Ela está realmente utilizável e disponível nos canais de distribuição corretos para seu cliente acessá-la? 

Esse pronto é no ambiente de produção, pois a equipe está trabalhando em um projeto de manutenção, ou o pronto é estar disponível em um ambiente de homologação?

Mais uma vez, pode parecer óbvio. No entanto, essa é a fase que mais gera confusão. E muitas vezes o time fica com a sensação de estar terminando várias atividades, enquanto o cliente está achando que o projeto está parado.

Outros pontos importantes no fluxo

É claro que além de definir as fases do processo, temos vários outros pontos importantes. Como comunicação clara e centralizada, tanto com o cliente quanto entre os membros da equipe.

Além disso, priorização de atividades que agregam mais valor para o projeto também é algo muito importante a se considerar no momento de definir no que o time vai trabalhar.

E um último ponto, escreva bem as atividades em que a equipe vai trabalhar. Se quiser saber um pouco mais sobre isso, dá uma olhada nesse artigo aqui: Como escrever tarefas para o time de desenvolvimento?

E o que mais pode ajudar a melhorar a gestão de projetos?

Bom, no começo eu disse que não ia falar de metodologias ágeis, mas não tem como fugir disso.

Porém não vou me alongar no assunto neste artigo. Vou deixar aqui link de dois outros artigos que escrevi, um sobre Scrum e outro sobre Kanban. Pra quem se interessar.

O uso de métodos ágeis ajuda e muito a melhorar a gestão de projetos!

É isso pessoal, por hoje ficamos por aqui. Qualquer dúvida, deixe nos comentários.

Até a próxima!

Scrum no dia a dia: saiba como utilizá-lo

Scrum no dia a dia, como utilizar?

Bom esse é o terceiro artigo de uma trilha onde falo sobre este framework. Neste artigo, vou abordar algumas dicas e ferramentas que podem auxiliar você e seu time na utilização do scrum no dia a dia.

Mas primeiro, vamos recordar um pouco do que já vimos. O primeiro artigo desta trilha eu falei sobre Scrum na prática: Introdução, e depois continue falando sobre o assunto em Scrum na prática: Entendendo o fluxo.

Se você não conhece scrum, ou mesmo que já conheça, porém ainda tem alguma dúvida. Recomendo que faça a leitura desses dois primeiros artigos antes desse aqui.

Bom, agora que já estamos alinhados sobre o que é scrum e como entendemos um pouco do fluxo dele. Vamos falar do scrum no dia a dia das equipes.

Scrum no dia a dia: Primeiros passos

Uma dica importante para começar com o scrum no dia a dia, é fazê-lo de forma gradativa. Ele é uma framework sensacional é bem instrutivo, mas sejamos sincero, ele também é muito prescritivo. Por isso, mesmo que seja definido como um “framework simples, para gerenciar projetos complexos”, é necessário um bom tempo para a equipe se adaptar a ele.

Devido a isso, sugiro que comecem sempre adotando os eventos, primeiro a reunião de planejamento, depois as dailys e uma review apenas para comparar o que foi planejado e o que foi entregue.

Depois comece a se preocupar e fazer uma review onde é dada manutenção do backlog, e quando a equipe tiver maturidade comece a praticar a retrospectiva. Mas evolua isso de forma gradativa, sem exageros e também sem perder tempo com reuniões demoradas que não levam a nada.

É sempre importante evoluir o processo junto com a maturidade da equipe.

scrum no dia a dia - to do
Ter a visualização de atividades pendentes e em andamento pode ajudar muito no dia a dia.

Como melhorar a visibilidade e transparência do Scrum no dia a dia?

Uma ferramenta que pode ajudar muito no acompanhamento das atividades, e que por isso garante o pilar da transparência no scrum. É o kanban!

Obviamente que aqui estamos falando do quadro kanban, e não da metodologia Kanban em si. Apesar de até existir uma abordagem chamada Scrumban que combina o melhor dos dois, e funciona muito bem diga-se de passagem, porém não é objetivo do artigo de hoje abordar este assunto.

O quadro kanban basicamente é composto pelas colunas que formam o workflow completo do processo de desenvolvimento daquele time. Neste quadro ficam dispostos os cartões com as atividades a serem desenvolvidas e que estão em desenvolvimento. E no caso do que está em andamento, sempre tem um responsável pela atividade. Ou seja é um quadro que mostra exatamente o que está sendo feito no projeto em tempo real (se estiver atualizado pela equipe).

Ele pode dar previsibilidade do esforço para se terminar uma demanda, mostra em qual atividade cada membro do time está alocado e em qual fase cada tarefa está, sendo assim, ele é uma ferramenta perfeita para você utilizar com o scrum no dia a dia.

 

ACABOU?

Bom pessoal, chegamos ao final da nossa trilha de artigos sobre Scrum. No entanto ainda existe muito mais a se falar sobre este framework. Então continuem de olho no nosso blog pois com certeza vamos postar mais material sobre agilidade.

Além do Scrum, temos artigos também sobre Kanban aplicado ao desenvolvimento de software – origem e conceitos. E muita coisa no nosso canal do Youtube.

Por fim, vou deixar para vocês um vídeo curto onde fiz uma comparação simples entre Scrum e Kanban:

E qualquer dúvida, é só deixar nos comentários. Até a próxima pessoal!

Scrum na prática: Entendendo o fluxo

Para dar continuidade em nossa trilha de como utilizar scrum na prática, neste segundo artigo vou falar sobre o fluxo do scrum.

Caso você ainda não tenha ouvido falar de scrum, ou não esteja familiarizado com os termos deste framework. Sugiro que leia o primeiro artigo da nossa trilha “Scrum na prática: Introdução“.

Bom, agora que já temos a introdução aos termos e conceitos, é hora de começar a entender o fluxo do scrum. Vamos lá?

Scrum na prática

Visão do produto

O primeiro passo para um time que vai utilizar o scrum na prática, começa um pouco antes dos tradicionais eventos que sempre ouvimos falar.

Antes de por o scrum pra rodar, é importante que o P.O., passe para o time uma visão clara do produto. Esse visão pode ser dada de uma forma macro, para que a equipe possa visualizar os seguintes pontos:

  • Qual o objetivo do produto que estamos construindo
  • O que queremos alcançar com este produto
  • Quais os objetivos de negócio envolvidos no nosso projeto
  • Quais são as expectativas do cliente com esse produto

Enfim, tudo que está relacionado a direção do produto em si. Desta forma, teremos uma equipe alinhada com os objetivos daquele projeto e fazendo parte da concepção do mesmo.

Montando a lista de funcionalidades

Depois de alinhar com o time os pontos citados acima, é hora do P.O. definir uma lista de funcionalidades para atingi-los. Ou seja, ele precisa definir quais as funcionalidades e recursos necessários que precisarão ser desenvolvidos para criar um produto alinhado com os objetivos do cliente.

Por ser uma missão um pouco complexa, o P.O. pode pedir auxílio para o S.M. e até mesmo para membros mais experientes do Dev Team no momento de definir essa lista.

Priorizando as funcionalidades

Após ter a lista completa de funcionalidades, o P.O. deve fazer a priorização delas. Ou seja, ele precisa definir a ordem em que todas as atividades serão desenvolvidas.

Além disso, é muito importante que o P.O. sempre leve em conta o valor agregado que cada recurso irá trazer para o produto. Dessa forma ele conseguirá juntamente com o Dev Team, desenvolver um projeto que entrega valor para o cliente frequentemente.

E com essa lista de funcionalidades definida e priorizada, temos o nosso primeiro artefato do scrum. O Product Backlog, será o pontapé inicial para a equipe começar a usar o scrum na prática.

scrum na prática - fluxo

Começando o scrum: Planejamento

Com o product backlog pronto, vamos começar nosso fluxo. Mas para falarmos deste fluxo, precisamos entender primeiro sobre o principal ciclo de trabalho do scrum, a sprint.

A sprint nada mais é do que o ciclo de trabalho onde o time desenvolve uma lista de funcionalidades pré-selecionadas. Normalmente com duração de duas a quatro semanas. É importante enfatizar também, que as sprints do projeto devem ter tamanho fixo, ou seja, se a sua primeira sprint durou duas semanas, esse ciclo de duas semanas deverá se repetir até a conclusão do projeto.

Com isso entendido, vamos continuar falando do fluxo. E aqui vamos entender o primeiro evento do scrum, o Sprint Planning.

No evento de sprint planning, o time se reuni e seleciona quais atividades do product backlog, irão formar o sprint backlog. Sempre respeitando a ordem de priorização da primeira lista, não se pode por exemplo pegar o primeiro e terceiro item do product backlog, deixando o segundo pra trás.

A ideia é planejar os itens que iremos conseguir entregar ao final da sprint. Claro, que é difícil tem essa previsão. Mas para isso podemos utilizar o Planning Poker. E com o tempo, a equipe vai entendendo melhor os pontos, e o que consegue fazer em cada sprint.

Além disso, o sprint planning não deve ser utilizado apenas para definir “o que será entregue”, mas também “o como isso será desenvolvido”. Então é importante que o time discuta tecnicamente sobre os itens, e sane com o P.O. as dúvidas relacionadas as regras de negócio. Por isso, o timebox recomendado para este evento, varia de 4 até 8 horas, dependendo do tamanho da equipe e duração da sprint a ser planejada.

Continuando com o Scrum: O Fluxo de trabalho

Após definirmos o nosso sprint backlog, é hora de começar a rodar nossa sprint. Então o dev team inicia o desenvolvimento das atividades efetivamente, de acordo com o que foi definido no sprint planning.

Durante esse ciclo, a equipe deve realizar diariamente a daily scrum, no horário combinado. Para que seja alinhado como está o andamento do projeto, devemos lembrar que inspeção e transparência são pilares do scrum.

Garantir que o evento da daily seja realizado todo dia, que a equipe participe ativamente e respeite o timebox máximo de 15 minutos, é papel do S.M. Isso é tão importante quanto remover os impendimentos que possam surgir no caminho, e está contemplado na atuação dele dentro do projeto.

Um pouco mais de Scrum: O fechamento do fluxo de trabalho

Ao terminarmos a sprint, entramos na fase final do fluxo de trabalho. A etapa onde iremos revisar e avaliar tudo que foi desenvolvido e praticado durante a sprint.

A primeira reunião de fechamento é a sprint review, que como já mencionei no artigo anterior serve para avaliarmos se os itens desenvolvidos na sprint, estão de acordo com o esperado. Nela o P.O.  também pode dar manutenção no product backlog.

Depois da review, acontece a retrospectiva. Esta é a reunião aonde avaliamos como está nossa execução do processo, e como anda nossa prática do scrum. Como também já falei anteriormente, nesse espaço a equipe pode discutir sobre o que precisa parar de fazer, ou melhorar na próxima sprint.

Além disso, no final deve acontecer o incremento do produto. Devemos lembrar, que no scrum o time é sempre responsável por manter uma versão estável e utilizável do produto. Por isso a entrega deve agregar novos recursos funcionais, mas sem prejudicar o que já existe.

Concluindo o ciclo do scrum

Bom pessoal, esse é um resumo de como o fluxo do scrum funciona. E apesar de parecer muita coisa, o importante é entender os conceitos e começar a aplicá-los no dia a dia.

O próximo e último artigo dessa trilha fala sobre Scrum no dia a dia, e nele dou algumas dicas de como aplicá-lo. E também falo de ferramentas complementares, que podem auxiliar na utilização deste framework.

Scrum na prática: Introdução

Como utilizar o scrum na prática? E como aplicá-lo no dia a dia de forma efetiva?

Se você trabalha com gestão de projetos, ou desenvolvimento de software, com certeza já ouviu falar de Scrum. E provavelmente sobre alguns dos cases de sucesso famosos com sua aplicação, como no Spotify por exemplo.

Apesar de sempre vermos o scrum definido como “um framework simples para gerenciar projetos complexos”. A verdade é que ele é bastante prescritivo, e leva um tempo para a equipe se adequar a todas as suas práticas. Mas com certeza podemos alcançar bons resultados com ele.

Neste artigo vou falar dos conceitos deste framework. Este será o primeiro de uma trilha que irei escrever, que irá desde da teoria até o scrum na prática. Vamos lá?

Scrum na Prática

PILARES

Transparência

Todo o time pode e deve ter acesso a todas as informações relacionadas ao projeto. A ideia é que a informação fique compartilhada, e assim, gestores, clientes e stakeholders possam acessá-la a qualquer momento.

Por isso é importante que a equipe defina quais ferramentas irá utilizar para se comunicar, e quais documentos irá gerar no decorrer do processo. Já que isso não é definido pelo Scrum, que deixa essa parte por conta do próprio time, para que faça da melhor forma.

Uma ferramenta que pode auxiliar nisso, originada de outra metodologia ágil é o quadro kanban. Que pode dar visualização de como estão todas as atividades do time.

Inspeção

Tanto o desenvolvimento das atividades, quanto a execução do próprio processo podem ser inspecionados a qualquer momento. A intenção da inspeção é que todos fiquem sempre alinhados sobre a situação do projeto. Mas essa inspeção, não deve ser excessiva a ponto de atrapalhar o desenvolvimento das atividades, ou de micro-gerenciar as pessoas.

Na parte do desenvolvimento a inspeção ocorre através de dois eventos, que são “Daily Scrum” e “Sprint Review”. Já o processo, pode ser inspecionado durante a “Sprint Retrospective”. Todos esses eventos, serão explicados mais abaixo.

Adaptação

O último pilar, garante que o processo do Scrum seja sempre adaptado quando necessário. O mesmo é válido para as diretrizes do produto, que como possui ciclos menores de interação com o cliente, também tem a possibilidade de ser adaptado com maior facilidade.

Scrum na prática

PAPÉIS

Product Owner (P.O.)

Responsável por direcionar o produto, é ele quem define quais as funcionalidades que serão desenvolvidas. E também faz a priorização delas para o time. Além disso, ele deve sempre deixar claro quais são os objetivos daquele projeto e passar a visão do produto para sua equipe.

Scrum Master (S.M.)

É o membro da equipe que deve dominar as práticas do Scrum. Conhecido como facilitador, ele sempre auxilia e garante que o time está executando o processo corretamente.

Dev Team

É quem propriamente desenvolve o produto, e tem o poder de decidir a melhor forma de fazer isso. No Scrum o time de desenvolvimento tem autonomia para escolher de qual maneira irá desenvolver suas tarefas, para atingir os objetivos do projeto. A equipe deve ser auto organizada e multifuncional.

EVENTOS

Sprint Planning

Nessa reunião, o dev team conversa sobre os itens do product backlog e seleciona o que entrará na sprint backlog. Sempre respeitando a ordem de priorização definida pelo P.O.

Além disso, o time também aproveita para debater como a demanda será desenvolvida, e nessa hora o P.O. pode explicar os requisitos e objetivos daquela estória de usuário. Assim a equipe conseguirá ter um entendimento mais claro, e poderá definir em conjunto qual a melhor forma de atender a demanda.

Daily Scrum

Reunião que deve acontecer diariamente para que toda a equipe fique alinhada sobre o andamento do projeto. Deve ser feita com todos os membros de pé, pois precisa ser algo rápido, durando no máximo 15 minutos.

Normalmente os desenvolvedores respondem a 3 perguntas:

  • O que foi feito ontem?
  • O que planeja fazer hoje?
  • Teve ou tem algum impedimento?

Sprint Review

Realiza ao final de toda sprint, essa reunião serve para avaliar se todos os itens de trabalho da sprint estão de acordo com o que cliente espera. Aqui o time apresenta o que foi desenvolvido para o P.O., e ele irá avaliar a entrega.

Nesta reunião, é comum a participação de stakeholders do produto. E nela também, que podemos realizar a manutenção do product backlog.

Sprint Retrospective

Realizada após a review, a reunião de retrospectiva serve para equipe avaliar como está trabalhando como o framework em si. Ou seja, como estão utilizando o scrum na prática e quais os resultados disso.

Alguns textos falam sobre levantar pontos negativos e positivos da sprint. Mas eu prefiro os autores que sugerem utilizar os seguintes questionamentos:

  • O que fizemos de bom?
  • O que precisamos melhorar?

E para tudo aquilo que precisamos melhorar, a equipe pode definir uma ação.

Scrum na prática

ARTEFATOS

Product Backlog

Lista de funcionalidades do produto, é criada, priorizada e mantida pelo P.O., utilizada pelo time durante o sprint planning.

Sprint Backlog

Funcionalidades selecionadas do product backlog, pelo time de desenvolvimento durante o planning. O ideal é que essa lista de itens, seja entregue no final da sprint.

Entregas Incrementais

Ao final de toda sprint, a equipe deve incrementar o produto com um entrega funcional.

Este foi o primeiro artigo da trilha de “Scrum na prática”. Onde dei uma introdução dos conceitos deste framework. E no segundo artigo, você pode conferir como funciona o fluxo do scrum.

Como escrever tarefas para o time de desenvolvimento?

Qual a melhor forma de passar demandas para o time de desenvolvimento? Sempre que falamos de gerenciamento de projetos, caímos nesse impasse. Mas como podemos fazer isso de uma maneira efetiva?

Como já falei em outro post do blog, o Kanban é uma boa alternativa pra organizar o fluxo de desenvolvimento. Mas além disso, é importante também, criar tarefas bem descritas para a equipe.

Para isso, podemos utilizar alguma estrutura padrão ao montar nossos cards no board.

Claro que os rituais como Refinement, ou Planning são de extrema importância para compartilhar as demandas com o time de desenvolvimento.

No entanto, neste post vou falar apenas em como escrever os cards de atividades e os resultados que podem ser obtidos.

Motivação

Pra começar, é sempre bom definir qual a motivação daquela tarefa. A ideia é que ao ler esse tópico, o desenvolvedor entenda o porquê de estar realizando aquela atividade. E além disso, qual o objetivo dessa funcionalidade dentro do sistema, o motivo dela existir e precisar ser desenvolvida naquele momento.

Pode parecer desnecessário, ou que isso está sempre subentendido. Porém, ter essa descrição na tarefa pode trazer muitos benefícios, como por exemplo:

  • Sensação de pertencimento do desenvolvedor, pois ele percebe que pode ajudar a pensar na solução.
  • Empatia pelo usuário. Quando se entende o problema que será solucionado e como o recurso será utilizado, fica mais fácil ter essa visão.
  • Alternativas de soluções mais eficientes. Quando o desenvolvedor consegue enxergar o todo, ele pode sugerir alternativas menos custosas em tempo de desenvolvimento, e por isso pode solucionar o problema com menos recursos.
  • Facilidade no entendimento. Ao entender os motivos relacionados a atividade, a compreensão do todo fica mais clara.

Critérios de aceite

Essa é uma parte fundamental ao escrever as tarefas. Quando listamos os critérios de aceite, estamos definindo o escopo do que será entregue e o que deve ser considerado no desenvolvimento dessa atividade. Portanto, é vital definir muito bem todos os critérios de aceite.

Os critérios de aceite precisam ser claros e objetivos, e além disso devem garantir a qualidade da entrega. Afinal é a partir destes critérios, que iremos alinhar com o time as expectativas dos stakeholders envolvidos. Portanto, esse tópico certamente é o mais importante a ser considerado no momento de escrever nossas tarefas.

Além dos pontos citados acima, a definição bem feita dos critérios de aceite contribui para o foco naquilo que deve ser entregue. Ou seja, o time de desenvolvimento sabe exatamente o qual o resultado esperado e investe seu tempo apenas no necessário.

Membro do time de desenvolvimento realizando teste
Os critérios de aceite e casos de teste, auxiliam o time de desenvolvimento na validação das atividades.

Casos de teste

Um outro ponto importante a se considerar no momento de escrever as tarefas, são os casos de teste.

Além dos critérios de aceite, é muito importante criar casos de teste para garantir que a entrega esteja alinhada com a expectativa do cliente.

Quando você define como testar uma atividade, consequentemente contribui para que o desenvolvedor entenda melhor o que precisa fazer.

E acima de tudo, os casos de teste servem para validar a qualidade da entrega. Auxiliando o time de desenvolvimento a realizar testes mais precisos que podem verificar funcionalidades específicas de suas atividades.

Uma boa ferramenta para auxiliar na escrita destes casos de teste é o Forrest.

Extra: Mockups!

Não é para toda demanda, mas mockups das telas são essenciais na maioria dos casos. Ter o desenho do resultado final da tela, pode ajudar e muito o time de desenvolvimento no momento de entender e desenvolver uma atividade.

Existem alguns casos, como demandas onde já existe um padrão de tela, que isso não é necessário, mas devemos utilizar deste recurso sempre que possível.

Conclusão

Resumindo, quando vamos escrever tarefas para o time de desenvolvimento, devemos adicionar os detalhes que irão contribuir para a qualidade da entrega e que valem o esforço.

Ou seja, não devemos investir tempo demais adicionando informações que ninguém irá utilizar, ou que não ajudarão efetivamente a equipe.

Sabemos que não existe um modelo perfeito e nem um padrão único, que possa se adequar a todas as equipes ou projetos.

No entanto, com essa estrutura você pode ter bons resultados. E com o tempo pode evoluir isso da forma que for melhor para o seu time.

Caso esteja com dificuldades ao alinhar as expectativas ou garantir a qualidade das entregas. Ou até mesmo, se estiver tendo muito retrabalho com o seu projeto, experimente escrever as tarefas seguindo essa estrutura. Você pode ter bons resultados com o seu time de desenvolvimento!

Se tiver alguma dúvida, deixe nos comentários.

Entenda como a gestão de software ágil pode ajudar sua empresa

Desde que a tecnologia vem sendo empregada nos negócios, algumas premissas de agilidade e eficiência passaram a ganhar um novo significado. Novas funcionalidades, como automação e virtualização de recursos, vêm materializando uma nova metodologia de trabalho denominada DevOps.

Esse novo conceito de governança de Tecnologia da Informação tem sido uma proposta bastante interessante para o atual mercado, indo ao encontro das exigências de redução de tempo de resposta para o cliente e de redução dos custos empregados nessa ação.

Mas, o que é DevOps? Quais são as melhorias propostas para os negócios? Essas e outras respostas você terá no decorrer deste conteúdo. Continue a leitura e saiba mais!

O que é DevOps?

Antes de falarmos sobre sua definição propriamente dita, vamos começar explicando que a palavra DevOps pode ser entendida a partir de duas partes: adequação de processos de desenvolvimentos (Dev) e operação (Ops) para um ciclo contínuo de execução.

Esse processo facilita a integração e os processos entre os recursos envolvidos e reduz o tempo de resposta com foco em eficiência e eficácia. Assim, é possível dizer que o DevOps surge como uma opção de reunir pessoas, processos e produtos e permitir a entrega contínua de valor aos usuários finais. Mas, afinal, o que é DevOps?

Em linhas gerais, DevOps utiliza a capacidade máxima da empresa para aumentar seu desempenho por meio de um conjunto de ferramentas e culturas, ou seja, distribuir serviços em alta velocidade. Nesse sentido, podemos dizer que é uma prática de TI que visa unir o desenvolvimento de software com as operações e os processos da empresa, integrando as áreas e alcançando uma maior qualidade nas entregas.

Quando as áreas não são integradas, há uma maior possibilidade de ocorrerem atrasos na entrega e falhas de comunicação dos times, o que pode resultar em retrabalhos e, até mesmo, baixa qualidade. Uma das características dessa situação é uma entrega de atualizações mais frequente, porém pequena. Assim sendo, com o DevOps o gestor tem um ciclo de desenvolvimento menor e as liberações são mais seguras e com melhor alinhamento aos objetivos do negócio.

Esse tipo de prática tem ajudado muitas empresas na integração contínua e na entrega eficiente dos seus produtos e/ou serviços. Por meio dela, é possível alcançar a padronização de ambientes de desenvolvimento, homologação e produção, além de auxiliar no gerenciamento e no controle sobre o ambiente e a infraestrutura.

Quais são os benefícios do DevOps?

Integrar comunicação e processos automatizados possibilita um entrosamento maior entre os times de desenvolvimento e operação. Além disso, a utilização de DevOps reduz o gap entre o desenvolvimento e a operação, já que cria um esquema de atuação que conta com uma equipe multidisciplinar.

Por sua vez, esta usa ferramentas automatizadas para construir códigos, testar, controlar incidentes e resolver problemas em um fluxo integrado e sinérgico. Entre outros benefícios, podemos destacar os que seguem.

Possibilita maior controle do produto desde a produção inicial

Por muito tempo, os processos de criação e de controle de qualidade foram divididos. Além disso, a elaboração de um software que contemplasse essa junção nem sempre atendeu seus objetivos com precisão, resultando em falhas na comunicação entre eles.

A cultura do DevOps tem como premissa que um bom controle de qualidade deve ser feito pelo mesmo grupo desde o início. Isso porque quando as pessoas já estão engajadas no que deve ser feito, a produção passa a ter maior agilidade, facilidade de comunicação e eficiência de todos os envolvidos.

Tanto as equipes de infraestrutura quanto de desenvolvimento precisam caminhar em prol de um só objetivo: entregar o produto ao cliente dentro do prazo e com a qualidade desejada.

Agrega inovação aos processos

As áreas de desenvolvimento e de infraestrutura passam a integrar suas fases de comunicação. Isso possibilita que as atualizações de softwares possam ser feitas simultaneamente, sem perder tempo na resolução de problemas.

A prática de DevOps prega que os objetivos devem ser correlatos, ou seja, um produto deve ser atualizado conforme as tendências de mercado ou de seus concorrentes. Quando isso não ocorre, ele se torna falho logo em seu núcleo.

Busca investimento em automação e infraestrutura tecnológica

Com a aplicação de recursos em infraestrutura tecnológica e automação dos processos, é possível reduzir custos financeiros e temporais, além de aumentar a qualidade do produto final. Utilizar DevOps exige que o gestor invista em automação dos processos, o que consequentemente reduz a incidência de erros e retrabalhos, economizando em gastos e gerindo melhor a equipe de trabalho.

É uma metodologia que evolui

A metodologia DevOps também evolui com o tempo. No entanto, é necessário que os gestores e toda a equipe conheçam os gargalos que persistirão em cada fase.

Como você pode perder dinheiro com DevOps próprios?

Tendo em vista as explicações acima, fica mais fácil entender o fundamento do DevOps, que junta desenvolvimento e operações de sistemas em uma única abordagem.

A aplicação do DevOps utiliza desenvolvimento ágil, porém, em vez de estar restrita apenas ao departamento de sistemas, ela pode ser aplicada para as atividades da equipe de infraestrutura, integrando práticas em um só modelo.

Isso possibilita que haja uma comunicação eficiente entre desenvolvedores e operações (infraestrutura) no ciclo de vida de desenvolvimento, na entrega e na operação de sistemas e serviços.

Abaixo, saiba mais sobre os principais fatores que explicam como você pode perder dinheiro com DevOps próprios.

Não investir em inovação

Para se manterem competitivas no mercado, as empresas precisam estar em constante evolução e desenvolvimento (Dev). Por sua vez, também necessitam estar atentas e certificar-se de que a infraestrutura e os sistemas (Ops) estejam devidamente preparados para receber as inovações da equipe de desenvolvimento. Caso as áreas não estejam compatíveis com as novas proporções de cultura organizacional, o investimento pode acabar sendo um tiro no pé.

Não capacitar e integrar a equipe

A implementação de DevOps exige que haja uma mudança cultural em toda a organização. Essa mudança requer capacitação e treinamento dos colaboradores, de modo que busquem ferramentas adequadas que efetivamente auxiliem no seu trabalho.

Quando a empresa utiliza DevOps, mas não integra ao máximo seus times de desenvolvimento e de operações, acaba perdendo os benefícios dessa prática. Assim, em vez de ter uma equipe que especifica o software e a outra que programa, tais setores devem trabalhar integrados, visando à criação de um ciclo ideal de projetos.

Esse ciclo permite uma rápida entrega, mesmo que existam atualizações, automatizando processos e melhorando a colaboração entre todos os integrantes do time. As tarefas podem ser realizadas com maior segurança e estabilidade, já que as equipes de testes e qualidade também podem (e devem) ser integradas.

Não realizar entregas de atualizações constantes

Sem dúvida, não realizar entregas de atualizações com frequência é o grande erro de muitos empreendedores que acabam perdendo com o DevOps. Efetuando modificações semanais, é possível entregar inovação e valor mais rápido e constantemente aos clientes.

Com isso, o risco de problemas nas implementações é reduzido, porque fica fácil perceber quando houver um erro, já que pouca coisa muda em uma alteração e outra.

Implementar o DevOps exige que o gestor tenha um conjunto de boas práticas que envolvem desenvolvimento de soluções agregadas com aspectos operacionais e de infraestrutura. Ou seja, é uma forma de pensar no desenvolvimento de um software com foco na qualidade do produto e com entrega rápida e eficaz.

Nosso conteúdo foi útil? Aproveite que está por aqui e complemente seus conhecimentos, entendendo como a gestão de software ágil pode ajudar sua empresa. Boa leitura!

Entenda de uma vez por todas o que é metodologia ágil

Muito comum no desenvolvimento de software, a metodologia ágil ganhou espaço dentro de um mercado concorrido que passou a exigir cada vez mais projetos que fossem desenvolvidos rapidamente. Cada nova proposta começou a ser mais bem-feita e sob medida para cada cliente.

Entretanto, poucas pessoas entendem bem o que é de fato a metodologia ágil, o que pode gerar perda de produtividade e qualidade. Então, vamos aprender de uma vez por todas o que é metodologia ágil?

O que é metodologia ágil?

A metodologia ágil, também chamada de Agile, nada mais é do que uma alternativa para ser mais produtivo dentro da gestão de projetos. A base dessa metodologia é o valor que o produto proporcionará ao cliente e a relação de todas as pessoas que estão envolvidas no projeto (clientes, desenvolvedores, …).

Os projetos que são geridos através da metodologia ágil são desenvolvidos por meio de entregas incrementais, isso significa que em cada entrega feita ao cliente, é desenvolvida uma ou mais funcionalidades do software e não o software todo de uma vez. Com isso, os trabalhos são divididos em etapas, que após finalizadas são enviadas para o cliente, e a partir do seu feedback, pode-se melhorar o que foi feito e o que será realizado.

Manifesto ágil

No ano de 2001, 17 desenvolvedores criaram uma espécie de manifesto para o desenvolvimento de uma metodologia ágil de softwares. Esse manifesto tem como aplicação 4 bases de métodos, são eles:

  1. Indivíduos e suas interações mais que processos e ferramentas

  2. Software em funcionamento mais que documentação abrangente

  3. Colaboração com o cliente mais que negociação com contratos

  4. Responder a mudanças mais que seguir um plano

De forma geral, esse tipo de manifesto é feito para comprovar tudo o que foi dito até aqui dentro da metodologia ágil. O contato entre a equipe deve ser prioridade assim como o contato da equipe com os clientes. Portanto, o mais importante no trabalho é atender as necessidades dos clientes e se adaptar quando for preciso. Isso vale muito mais do que só seguir processos rígidos e ferramentas definidas como era feito no modelo tradicional.

Ágil vs Tradicional

O desenvolvimento ágil, como já explicado anteriormente, é feito com ciclos contínuos, pequenas entregas, grande participação do cliente e múltiplas metodologias. A metodologia ágil possui seis passos definidos: definição das necessidades, planejamento, design, desenvolvimento, publicação e monitoramento do projeto. Após realizar todos esses passos, o ciclo recomeça.

Já a metodologia tradicional define um escopo antes de começar um projeto, ou seja, define todas as suas funcionalidades e a partir do momento que esse projeto começa a ser desenvolvido, nada pode ser alterado, e para isso são utilizados contratos. A abordagem tradicional segue uma sequência de passos: definição das necessidades, design, implementação, verificação e manutenção.

Agora que você entendeu o que é metodologia ágil, você deve estar se perguntando, por que é tão recomendado utilizar esta metodologia já que a tradicional foi empregada por muitos anos?

Benefícios da metodologia ágil

Um dos principais benefícios está voltado ao método de trabalho, que se torna muito mais eficaz e fácil de ser realizado pois é feito por funcionalidade do software. Essa metodologia apresenta diversas vantagens dentro da área da tecnologia da informação, por exemplo:

  • Melhorias na comunicação: quando o trabalho é dividido em etapas, isso permite que as várias partes do software possam ser testadas de maneira individual. Assim é possível melhorar o que for preciso, e o entendimento do cliente a respeito do seu serviço irá facilitar o trabalho da equipe.

  • Equipes ficam mais produtivas: os famosos bloqueios criativos, causados pelo excesso de informação, papelada demais e burocracias, são evitados pelo uso das metodologias ágeis. A equipe deixa de se preocupar com o serviço final que contém muitas funcionalidades e acaba se preocupando com a funcionalidade que deve entregar naquele pacote, se tornando assim, mais produtivas.

  • Definição de objetivo: com a definição de cada etapa dentro do projeto, redução da burocracia e ainda o uso de uma linguagem mais fácil, acaba sendo mais eficaz do que ter um objetivo final já traçado e cumprir isso.

  • Satisfação do cliente: com o uso da metodologia ágil, cada pedaço do seu produto final é validado com o cliente por meio de feedbacks, e graças a isso, a chance do seu produto final satisfazer as necessidades do cliente se torna alta, pois quaisquer erros, alterações ou melhorias que forem necessárias ao longo do projeto serão realizadas durante o processo, fazendo com que o cliente não se frustre no final do mesmo.

E aí, aprendeu bem o que é metodologia ágil? A ez.devs já trabalha com essa metodologia e os clientes que conhecem o nosso fluxo de trabalho aprovam. Que tal implementar essa metodologia na empresa na qual trabalha?

Para falar mais com a gente sobre metodologias ágeis ou sobre outros assuntos relacionados a área de tecnologia, mande um e-mail em oi@localhost. Teremos o maior prazer em bater um papo com você! 🙂