Qual a diferença entre metodologias ágeis e agilidade ?

Para entendermos o que é cada um precisamos conceituar processos e cultura. Segundo o Wikipedia, cultura é um padrão integrado de conhecimento, crença ou comportamento humano que depende da capacidade de pensamento simbólico e de aprendizado social de um determinado grupo de pessoas. É também um conjunto de atitudes, valores, objetivos e práticas compartilhadas que caracterizam esse grupo de pessoas.

Ainda segundo o Wikipedia, processo é um conjunto de tarefas e atividades relacionadas que produzem um determinado produto ou serviço para um ou mais clientes de uma empresa. Pode ser visualizado com um fluxograma.

Sendo assim, processo é o “como” enquanto a cultura é o “porquê”.  Assim podemos afirmar que as metodologias ágeis, ou seja, os processos de desenvolvimento de software que as metodologias ágeis definem, são consequência da cultura ágil.

Sem dúvida o que mais importa é a cultura, já que sem o “porquê” é muito mais difícil seguir e manter o respectivo “como”.

A cultura ágil existe, tranquilamente, sem as metodologias ágeis. Se olharmos somente para o manifesto ágil e em seus princípios para alguém que nunca ouviu falar nas metodologias ágeis, é muito provável que essa pessoa acabe criando os processos necessários para viabilizar a cultura ágil.

Abordando o outro lado, o processo ágil, por exemplo o Scrum, é difícil entender o “porquê” esse processo deve ser seguido. Dá até para perceber que esse processo melhora o dia-a-dia do desenvolvimento de software, mas sem saber o “porquê” de o seguir, as chances de que o processo se mantenha ou, mais importante, de que o processo melhore, são bem baixas.

Daí a importância de entender a cultura ágil antes de implementar as metodologias ágeis. Porém, mudar uma cultura é tarefa cada vez maior, quando a cultura está intacta a muito tempo. Mudar essa cultura será algo custoso, longo prazo, gradual, que encontrará resistências e que é muito difícil de se estimar e prever. E como toda tarefa extensa  é pouco atraente e interessante aos olhos de quem ver como uma mudança isolada. Somente as pessoas que querem os resultados da mudança de cultura vão estar dispostas a entrar neste processo complexo. 

Em resumo metodologias ágeis são processos, agilidade é cultura. E é muito mais fácil implantar metodologias por serem algo bem definidos, já implementar uma nova cultura é um grande e extenso desafio. Porém, o processo sem uma cultura para justificá-lo se torna muito mais frágil e propensos a fracassos. 

Os três principais erros na implantação de Scrum

Estamos em uma era em que o uso das metodologias ágeis está em alta, muitos dizem que está na moda na área do gerenciamento de projetos. Porém temos muitos gerentes de projetos que afirmam que há certos problemas na implantação de Scrum em seu time. Ou que o jeito com que essa metodologia age não está funcionando. Porém poucos tentam parar e ver o que está acontecendo na verdade e, muitas vezes, descobrem que estão utilizando ScrumBut ao invés de Scrum, o que pode não ser adequado para determinados times.

Boris Gloger,  afirma que os 3 dos principais erros que ocorrem em equipes que estão querendo utilizar Scrum, são eles: 

• O Gerente nomear um líder de equipe para ser ScrumMaster.
• O ScrumMaster acreditar que o Scrum irá se adaptar a empresa e que  já está tudo pronto para misturar processos antigos com Scrum.
• O Product Owner não é presente ou então trabalha em muitos times ao mesmo tempo.

Os problemas abordados por Boris não se aplicam a todas as empresas e/ou projetos, visto que existem casos onde o Product Owner consegue dar conta de muitas equipes ao mesmo tempo. Porém tenha em mente que, se sua equipe possui algum desses problema, e o adoção do Scrum em seu projeto não está sendo amigável, tente extinguir os pontos supracitados pois eles podem ser a causa dos problemas. 

O primeiro ponto é de suma importância pois pode ocorrer do ScrumMaster ainda vestir a camisa de Gerente, expressando assim uma conduta mandatória sobre o time, o que não é recomendado, visto que o time tem que saber se gerenciar e não existe comando-controle nesse caso.

O segundo ponto se refere a tentar fazer com que as coisas saiam correndo e, ainda no começo da implantação, querer impor sua velocidade e suas idéias acima das do Scrum. Utilizar ScrumBut no começo da implementação não é uma boa idéia, pois seus processos ágeis muitas vezes ainda são imaturos. Com o amadurecimento do Scrum é absolutamente normal você adaptar o mesmo as suas necessidades, tornando ele mais flexíveis (lembre-se que você estará utilizando ScrumBut e não Scrum).

O terceiro ponto, que segundo Boris Gloger é essencial e primordial,  é ter muitas pessoas não dando importância ao P.O., pois ele demorar a aparecer. A presença do P.O no desenvolvimento é essencial. O time com certeza terá dúvidas no decorrer do Sprint, o time terá sugestões, e se essa comunicação TIME-P.O não for feita de forma natural e eficaz, a probabilidade de fazer algo que o cliente não queria é alta.

Esse são 3 dos principais erros citados por Boris.

Gerência de Riscos no SCRUM

Realizar uma gerência de riscos é uma atividade importante, crucial e indispensável precisa ser realizada ao decorrer de um projeto. Seu objetivo é manter o controle sobre possíveis impedimentos que possam ameaçar a boa execução do projeto. Além disso, é imperativa a sua realização para alcançar o nível de maturidade de processos do MPS-BR (Melhoria de Processos de Software Brasileiro) e do CMMI (Capability Maturity Model Integration).

Esta gestão não foi bem definida nos manifestos das metodologias ágeis, porém não pode ser deixada de lado, na verdade, fechar os olhos para a gerência de risco pode fazer com que a implantação da metodologia ágil seja fracassada. 

Em projetos tradicionais, a Gerência de Riscos segue um processo de identificação, análise, desenvolvimento de respostas e monitoramento dos riscos. Estas atividades serão sempre realizadas antes do início do desenvolvimento do software e revisadas, posteriormente, em marcos estabelecidos do projeto. Todo o processo é documentado formalmente e comunicado aos steakholders no gerenciamento dos riscos.

 

O SCRUM não fala explicitamente sobre um processo formal de Gerência de Riscos, mas é possível realizá-lo sem sacrificar a agilidade desta metodologia. Sendo assim, ele pode ser realizado de maneira natural. No primeiro caso, os riscos são identificados naturalmente, frutos de reuniões diárias, plannings ou revisões. No segundo caso, basta incluir a realização desta atividade, explicitamente, na pauta de alguma reunião do SCRUM. Seja qual for o caso, após a identificação, é necessário realizar as demais atividades do processo. 

Uma boa prática é a manutenção de um quadro de riscos. A ideia é elaborar um quadro bem semelhante ao quadro de tarefas do SCRUM, em casos se confunde com o quadro de atividades do Kanban, porém dividido em três partes: conter, aceitar e evitar, que são as categorias básicas de respostas aos riscos.

• Evitar um risco é a ação de eliminar a causa deste inviabilizando a sua ocorrência (ex: mudança de interface do sistema).
• Contenção de um risco é a suavização das consequências, ou a diminuição da probabilidade de um risco por meio de um plano de mitigação (ex: compra de um plano de backups clouds).
• Aceitação de um risco é a ação de simplesmente aceitar suas consequências, podendo haver ou não um plano de contingência para o caso deste ocorrer.

De acordo com a descoberta de riscos, vai se fazendo identificação do mesmo, eles vão sendo adicionados ao quadro, de acordo com o modo de gerenciamento escolhido para os mesmos. O ponto crucial é que o quadro precisa estar visível para todos os interessados e envolvidos do projeto.

Seminário Scrum , Kaban e XP

Olá pessoal,
Mais conhecimento sobre Scrum , Kaban e XP através do seminário que apresentamos. 

Seminário - Scrum , Kaban e XP from Lays Lopes

Valores do manifesto ágil

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:

• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Com o manifesto ágil foi necessário uma organização que se configurasse permanente e o representasse. Então, no final de 2001, nasceu a Agile Alliance. Trata- se de uma organização sem fins lucrativos que procura promover o conhecimento e discussões sobre os vários métodos ágeis, hoje, existentes no mundo. Muitos dos membros do manifesto ágil, citados anteriormente, são integrantes dessa aliança.

Cada método ágil existente hoje carrega consigo os valores e princípios arraigados no manifesto ágil, métodos como SCRUM, KANBAN e XP os trazem, por isso são denominados ágeis. Os melhores métodos para desenvolvimento de software devem ser encorajados, e acredito fielmente que os processos ágeis são cabíveis desse encorajamento, já que em sua totalidade conseguem agregar o maior conjunto de benefícios na construção de um sistema.

Fonte: https://www.culturaagil.com.br/manifesto-agil-como-tudo-comecou/

Surgimento das Metodologias Ágeis

Caros leitores do nosso blog,

Até o momento falamos de Scrum, Kaban e Extremming Programming (XP). Mas vocês precisam saber um pouco mais sobre o surgimento das metodologias ágeis.Nesse post vocês iram descobrir como se deu o surgimento das metodologias ágeis.

Segundo MILLER (2002), em meados da  década  de  90  as  bases  das  metodologias  tradicionais  começaram a ser questionadas. Os fatores que desencadearam tal questionamento foram:   a  alta  freqüência  com  que  os  projetos  de  software  deixavam  de  cumprir  seus cronogramas e extrapolavam seus orçamentos e  a dificuldade de uso das metodologias pesadas. 

Como fruto dos questionamentos levantados em torno destes problemas ao longo dos  últimos  anos,  surge  um  novo  paradigma  para  o  desenvolvimento  de  software: as metodologias  leves  ( lightweight  metodologies )  também  chamadas  de  metodologias ágeis.

Em fevereiro de 2001, 17 pessoas desenvolvedoras de software e que ajudam outros a conhecê-lo se reuniram nas montanhas de Wasatch (Utah) para encontrar um censo comum entre as suas diferentes abordagens para o desenvolvimento de software. O resultado desta reunião é o Manifesto para Desenvolvimento de Software Ágil. Vários membros dessa discussão passaram a fundar a Aliança Ágil.

12 Princípios do Manifesto Ágil

1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
3. Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.
4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Fonte:

•  Agile Alliance
•  Monografia Ebenezer Silva Oliveira
• MILLER, David. SLAYING THE DRAGONS: AN AGILE APROACH TO SOFTWARE DEVELOPMENT – A Management Overview
• Princípios do Manifesto Ágil

Características das Certificações Scrum Master no Mercado

Existem pelo menos 5 entidades Internacionais que são reconhecidas e que emitem certificação como Scrum Master. Todas elas emitem o Certificado de Scrum Master, porém vou detalhar abaixo suas principais características

Certified Scrum Master da Scrum Alliance

Esta certificação é bem reconhecida também, porém ela exige que você faça um treinamento presencial de dois dias, normalmente durante a semana.

O custo deste treinamento normalmente é bastante alto cerca de R$ 2.500,00 a R$ 3.500,00.

Logo após você ainda precisa passar por um teste online com 35 questões com nota mínima de 68%. O ponto mais crítico é que você ainda precisa pagar uma taxa anual de mais R$ 500 reais para manter a certificação.

O Investimento é alto e a preparação demanda um curso de dois dias.

Certificação Professional Scrum Master – PSM I da Scrum.org

A Professional Scrum Master É a principal certificação Scrum Master do mercado.

A Certificação PSM é a mais reconhecida e também a que demonstra realmente o seu conhecimento como Scrum Master.

Essa certificação tem uma credibilidade incrível, porque o Scrum.org foi criado pelos fundadores do Scrum, o Jeff Sutherland e o Ken Schwaber. Além de signatários do Manifesto Ágil são as maiores autoridades do Scrum no mundo.

Para esta certificação você apenas precisa estar preparado para um exame de 100 questões a serem realizadas em uma hora, com uma taxa mínima de aprovação de 85%.

O custo do exame oficial é o menor de todas as Certificações, custa 150 dólares e não há custos para renovação da certificação.

Ocorre que a prova exige do profissional, pois dada sua credibilidade e o alto nível da nota para passar, o Scrum Master precisa estar preparado.

PMI – ACP

O PMI é o Instituto de Gerenciamento de Projetos mais famoso pelo PMBOK e pela certificação PMP.

Ocorre que você precisa de no mínimo 2.000 horas em projetos ágeis como requisito. Você ainda precisa fazer 21 horas de treinamento formal em uma instituição credenciada. O custo deste treinamento é de R$ 2.500,00 na média.

Além disso você precisa pagar a taxa do exame ao PMI que é de R$ 1.700,00.

A prova dura 3 horas com 120 questões e você precisa de no mínimo 70% de acertos para passar. Você ainda tem que renovar sua certificação todo ano com um custo superior a R$ 500,00.

Além de ser muito cara, exige muito tempo de preparação, em um curso muito longo  e ainda não é muito reconhecida pelo mercado de trabalho.

Conclusão:

Essas são algumas opções de certificação que achei interessante, cabe a você saber qual a se encaixa no seu perfil.

Kanban: 4 passos para implementar em uma equipe

Como usar Kanban em quatro passos

O kanban pode ser utilizado em diversas áreas, como por exemplo, desenvolvimento de software, gestão de TI, novos negócios, design, finanças, marketing, operações, entre outras.

O uso adequado dessa ferramenta pode trazer agilidade e organização. Agilidade em responder às mudanças que surgem ao longo da execução de tarefas e projetos, e organização, formando um time que trabalha de forma mais eficiente sem gerar muito ruído nas comunicações.

Sendo assim, uma forma simples de implantar o kanban em sua equipe, em quatro passos, é mostrada a seguir:

1. Equipe

• É importante que a equipe esteja preparada para assimilar os conceitos e princípios do kanban. Pode haver resistência, uma vez que a transparência traz como consequência a visualização de quem é produtivo e também de quem é improdutivo;
• Apresente os conceitos, princípios, e um exemplo básico de uso do kanban e dos benefícios que a equipe poderá obter com seu uso;
• Sempre é bom lembrar que, independentemente da ferramenta, a equipe é a parte mais importante. Uma equipe capacitada funciona bem com qualquer ferramenta, enquanto que uma equipe incapaz geralmente falha utilizando até mesmo o melhor dos métodos.

Tendo entendido o básico da ferramenta, é possível construir o kanban que mais irá atender as necessidades da sua equipe;

2. Identificando Estágios do Trabalho

• Identifique os Estágios de Trabalho que sua equipe segue para concluir um produto, projeto ou serviço. O fluxo mais comum começa em “TO DO” e termina em “DONE”, geralmente com “WIP” (Working In Progress) no meio, mas pode ser alterado para o que melhor se adaptar ao seu contexto;
• Identifique as Classes de Trabalho, como, por exemplo [user storie], [bug], [defeito], [melhoria], [teste], [requisito], etc. que vão ajudar a categorizar o trabalho e melhor organizar o quadro;
• Tente definir limites de tempo que cartões podem ficar em determinados estágios, por exemplo, um cartão não pode ficar mais que duas horas em “TO DO” se for do tipo [defeito].

Com o quadro montado e as regras definidas e claras para todo o time, é possível avançar para a parte mais importante do kanban: a priorização do trabalho. A priorização é especialmente importante, pois mantém o foco do que realmente se deve fazer em primeiro lugar, que vai entregar valor primeiro para o cliente ou para a organização.

Figura 1: Exemplo de Kanban com tarefas.

3. Priorização

• Posicione o que é mais prioritário (tem que ser feito antes) sempre na parte superior do kanban. Se desejar, pode separar o quadro em categorias, mas mantendo entre elas essa estrutura de priorização. Isso permite entregar valor rapidamente (produto que já pode ser usado/vendido), seguindo o princípio de Pareto (princípio 80/20) aplicado ao desenvolvimento, onde 80% do valor de seu produto pode ser gerado com 20% do trabalho total;
• Mantenha um controle constante do que é prioritário identificando, sempre que possível, mudanças na ordem ou novos cartões que sejam necessários. Dessa forma você melhora a qualidade e reduz os custos, eliminando/adiando o trabalho desnecessário.

Problemas que a priorização ajuda a evitar: entrega de software inútil, cliente insatisfeito, metas ou sprints (no caso do SCRUM) não atingidas, demora em entregar bugs e melhorias, dificuldade realocação de times e suas capacidades dentro da equipe.

Na Figura 1 é mostrado um exemplo de kanban priorizado, onde os itens com marcas em vermelho são mais prioritários em relação ao com marca em azul, ou seja, os itens em vermelho geram mais valor ao produto final que os itens em azul. Por isso, uma boa prática consiste em a equipe iniciar as tarefas realizando os itens com maior prioridade.

Figura 2: Exemplo de kanban priorizado.

Finalmente, é bastante importante ter métricas o fluxo de trabalho, principalmente para atingir a melhoria contínua.

Medição e Melhoria Contínua

• Estabeleça um sistema de medição simples como: trabalho que precisa ser feito e o que foi feito até o instante (no SCRUM utiliza-se bastante o burndown chart, ou gráfico de consumo), lead time, etc.
• Simule os riscos durante a execução do trabalho, procurando encontrar os gargalos antes que eles apareçam. Isso ajuda a determinar planos de ação preventivos, que diminuem consideravelmente os riscos. Existem tanto métodos de simulação como ferramentas automáticas que ajudam nessa tarefa;
• Para atingir a melhoria contínua (Figura 3), adaptação é a palavra-chave. Não cometa o erro de achar que aquele kanban que você e sua equipe montaram no início vai permanecer igual para sempre. É necessário mente aberta para identificar oportunidades de melhoria, como, por exemplo, adaptar o fluxo com mais ou menos estágios ou aprender a priorizar o que gera mais valor.

Figura 3: Melhoria contínua.

Em resumo, kanban é disciplina, transparência, priorização e adaptação. Sua correta utilização pode trazer muito valor para uma organização, para uma equipe ou até mesmo para um projeto pessoal.

Ele é fácil de montar e de se manter atualizado, sempre respondendo às mudanças que aparecem no meio do caminho.

Vale ressaltar que, apesar de uma boa ferramenta, o mais importante para um projeto ou organização funcionar é que a equipe seja boa.


Fonte:http://www.devmedia.com.br/kanban-4-passos-para-implementar-em-uma-equipe/30218