Plano de Projeto de Software para o desenvolvimento do Bariatric Dashboard System

PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW from Lays Lopes

Como funciona o Kanban

O kanban é uma simbologia visual utilizada para registrar ações. A palavra kanban teve a sua origem no Japão, e pode ser traduzida como cartas em que você pode ver e tocar. Foi inventado pela Toyota, fazendo parte do famoso sistema Toyota de produção e está associado a sistemas puxados e ao conceito de entrega just-in-time de produtos.  Sua utilização não é algo novo na indústria brasileira, que começou a aplicar esta ferramenta na década de 80. É uma prática de gestão de estoque e controle de fluxo de peças dada pela utilização de cartões, chamado também de Gestão Visual. Estes cartões representam a necessidade de peças e itens para o processo produtivo e podem ser utilizados em meio impresso,  luzes coloridas ou mesmo locais demarcados. A utilização do kanban possibilita a sintonia entre a gestão do estoque e a produção. Ele pode ser subdividido em dois tipos: o de produção e o de movimentação.

Como funciona o Kanban

Imagine uma linha de produção de latas, onde o operador deve alimentar a máquina com chapas cortadas para que a máquina então produza latas. A quantidade de chapas que alimentam a linha pode ser representada por cartões, conforme abaixo:

No nosso exemplo devemos produzir 10 latas para tanto devemos alimentar a máquina com 10 chapas cortadas a cada hora. Caso estas chapas não sejam repostas no devido momento, a produção será afetada. Em uma primeira etapa, o operador recebe do estoque 10 chapas cortadas para produzir 10 latas e preenche todos os 10 cartões no quadro Kanban seguindo a ordem do verde para o vermelho.

Assim que começa a produção, o operador alimenta uma chapa na máquina e retira o primeiro cartão verde do quadro (Etapa2). Ele continua a produzir alimentando a máquina e retirando o cartão correspondente do quadro. Observando a Etapa3, podemos ver que ele já utilizou 4 chapas para alimentar a máquina e estas chapas ainda não foram repostas.

Na Etapa4, o nível de resposta já foi atingido. Isto significa que o sistema está em alerta, ou seja, ele está operando exatamente no tempo de resposta. Este tempo é o tempo necessário para que o repositor do estoque separe as chapas e leve elas até o operador.

Os cartões vermelhos representam uma faixa de segurança necessária para que a máquina não pare de produzir. Voltando ao nosso exemplo, se observarmos na Etapa5, percebemos que se existem apenas 2 chapas com o operador e que se não forem repostas imediatamente, a produção irá paralisar por completo (Etapa6).

Desvantagens do Kanban

Este é um sistema que funciona bem em um sistema de produção em série, visto que qualquer pedido não previsto, demanda instável ou pedido emergencial impacte em todo processo. A falta de disciplina dos operários pode também afetar todo o sistema.

Algumas dicas para implantar o Kanban

1.  Analise a necessidade do produto para cada item específico ou tarefa. A análise deve ser feita a fim de determinar o número de peças necessárias para cada produto vendido ou utilizado em cada tarefa. Deve ser revista a oferta e a demanda de cada produto e o tempo que leva para o que o fornecedor faça o reabastecimento.
2. Confeccione etiquetas de produtos para cada peça de mercadoria. As etiquetas devem ter o nome do produto, a quantidade de cada item em um recipiente cheio e quaisquer outros detalhes pertinentes.
3. Preencha dois recipientes separados com o número total de peças necessárias para cada produto. Com isto, podemos obter a mercadoria necessária no momento e a quantidade de reposição do estoque.
4. Anexe as tags dos produtos aos recipientes. As tags vão ficar com os recipientes em todos os momentos.
5. Crie áreas de distribuição para os recipientes. Para instalações industriais, podem ser utilizadas áreas de trabalho, salas de estoque ou fornecimento.
6. Atribua locais específicos para cada recipiente de produtos nas áreas de distruibuição. Coloque um no local onde é utilizado e outro na área de abastecimento.
7. Forneça instruções a todos estoquistas e funcionários envolvidos. O sistema Kanban só funciona se todas as pessoas seguem o processo.
8. Revise os resultados do processo Kanban e altere quantidades, se necessário, de forma a assegurar que as peças sempre serão repostas. Se ambos os recipientes estiverem sempre vazios, aumente o número necessário em cada recipiente para permitir mais tempo de reposição a partir da ordem do pedido.
9. Sempre tente manter a menor quantidade de cada peça sem correr o risco de ficar sem estoque.

Princípios do Kanban

Basicamente um Kanban Board apresenta 6 colunas:

1. To Do: Para Fazer
2. Plan: Planejar
3. Develop: Desenvolver
4. Test: Testar
5. Deploy: Implantar
6. Done: Feito

Como  mostra a figura abaixo:


Alguns Kanban Borads são mais enxutos, como este:



Outros, são bem mais complexos e incluem até notações de modelagem BPMN.

SISTEMA KANBAN & JUST IN TIME - DEFINIÇÃO

Just in Time é um sistema de produção cujo princípio determina que nada deva ser comprado, produzido ou entregue antes da hora exata, sob pena de estar sendo gerado desperdício.

E Kanban é uma forma visual de controlar a produção e os estoques da empresa Ao invés de se utilizar listas de produção extraídas do MRP ou listas de pendências de vendas, a fabricação é controlada por sinais visuais. Mas aplicar os princípios do Just in Time em uma operação industrial vai muito além da gestão visual da produção, Além do Kanban, outras ferramentas também são importantes para a aplicação dos conceitos do Just in Time.

A implementação de um Sistema Kanban envolve primeiramente a mudança do sistema tradicional de produção empurrada para o sistema de produção puxada, seguindo-se a implementação de controles visuais de produção e estoque.

Princípios

O kanban procura identificar oportunidades de melhoria criando uma cultura Kaizen na equipe, na qual a melhoria contínua é responsabilidade de todos.

Os princípios básicos em torno dessa ferramenta são:

• Visualização da Cadeia de Valor: enxergando as fases do produto (por exemplo, um software, algo material ou até mesmo um serviço);
• Desenvolvimento Evolucionário (Adaptativo): através de gestão de mudanças simples, adaptando-se de forma ágil, entregando o que tem mais valor antes. Perceba que a palavra “ágil”, muitas vezes confundida com rapidez, aqui significa capacidade de se adaptar às mudanças com mais facilidade, mais agilidade;
• Restrição do trabalho e seu progresso em torno de seus estágios: permitindo medição, controle e melhoria contínua.

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

Certified Scrum Master – como é o processo para a certificação?

Ser um Certified Scrum Master (CSM) não é muito difícil. Basta fazer um curso por um Certified Scrum Trainer (CST) e no final responder uma média de 36 questões enviadas pela ScrumAlliance. E então, você é um Certified Scrum Master.

E pra que serve?

Ela é criticada por profissionais de TI, mas existem duas coisas importantes para analisar antes de criticar:

• Se você já tem um bom nome no mercado e você é o valor da sua empresa em si, não vai precisar de certificação nenhuma. Exemplo? Pessoas como Eike Batista e Steve Jobs podem abrir uma empresa amanhã e ela já começa com um valor X, só porque eles são os dirigentes e seus clientes não querem saber se a empresa deles tem profissionais certificado YHY. Isso porque a confiança é toda depositada neles e quem a deposita conhece o perfil de cada um e sabe o do seu nível de qualidade. Não precisa de nenhum órgão para testar isso, pois eles por si são os órgãos;

• Agora o contexto dois, no qual está a maioria de nós, pobre mortais. Aquele profissional que não tem esse valor todo no mercado e que precisa que algum órgão respeitado diga: “esse cara tem os conhecimentos mínimos; nos o certificamos” para conseguir vender seu produto. E então você precisa vender o seu certificado para ganhar alguns tipos de cliente. E é pra isso existem as certificações: para aproximar novos clientes incertos do seu serviço. Esta é a realidade do mercado, seja aqui no Brasil ou lá fora – claro com algumas particularidades de cada país, mas é muito similar.

Em resumo, se amanhã você pretende atuar como um consultor Agile, e um mercado já consolidado com seu nome impresso, ter as certificações pode te ajudar com os seus primeiros clientes.

A diferença

Este é o diferencial do CSM: ao sair do curso você não é Scrum Master. Por quê? Simples, você não compra liderança, motivação de equipe, etc. Você desenvolve essas habilidades e são os pontos chaves para atuar como um Scrum Master – pouco importa se você é ótimo em Java, ou .NET, mas se não sabe lidar com equipe, remover as barreiras, ou ter um bom relacionamento, você está perdido. Agora vem a sensação de outras certificações, como Java e algumas do PMI, que ao terminar você olha e pensa: “mas eu estudei isso e aquilo. Agora eu sei exatamente como fazer X. Já sei usar generics e entendi threads, ou aprendi como calcular custo do projeto com menos erros, depois da prova PMI xxx”.

Quem for fazer certificação Agile deve esquecer qualquer uma dessas sensações – pelo contrário! Você sai de lá com mais dúvidas e mais confuso ainda. No início achei meio estranho, porém com o passar de um ou dois dias achei que isso era um ponto-chave excelente, pois fiquei motivado a buscar como resolver aquelas confusões e para isso tinha que estudar mais, aumentar o faturamento da Amazon.com, etc. E quando fazemos as certificações tradicionais isso não acontece. Afinal, após termos sido aprovados, temos a falsa segurança que dominamos o assunto e nem abrimos mais o livro de estudo.  E então começamos outra jornada: o esquecimento daquilo que não se usa com frequência.

O treinamento

São dois dias de treinamento, no qual abordam os pontos core de Scrum, com conceitos teóricos, práticos e cases. Há muita discussão e aprendizado nesses dois dias. Não é um curso comum; o aprendizado é grande e muito valioso. E sabe por quê? Vou responder a seguir.

A sacada da ScrumAlliance

É fácil criticar quando não conhecemos, mas a ScrumAlliance fez algo que achei interessante. Ser um CST não é para qualquer um. Ou seja, só quem teve e tem vivência pratica em Agile pode ser um CST. E isso garante que o conteúdo do curso será com um profissional que tem conhecimento e experiência de fato (ou seja, teve muito conflitos para resolver). E isso enriquece todo o curso de uma forma que é difícil descrever. Na maioria da faculdade temos professores “doutores” que nunca tiveram uma experiência profissional e assim, o o curso só fica no meio acadêmico. Mas quando o aluno chega ao mercado vê que a coisa é bem diferente. No treinamento da ScrumAlliance isso não tem como acontecer.

Ao sair do curso

Bem, ao sair do curso não dá para ter a síndrome do estudante e achar que é o ScrumMaster. Talvez, os menos experientes profissionalmente possam sair com essa síndrome. A certificação não prova que você tem todas as habilidades de ScrumMaster expert. Porém, é esperado que o aluno tenha o conhecimento suficiente para rodar uma Scrum, mas isso não quer dizer que ele vai conseguir rodar bem ou vai rodar a melhor Scrum do mundo. No curso você percebe se é aquilo o que de fato que deseja para você. O framework Scrum deixa transparente o papel e o que um SM vai viver no dia-dia sem maquiagem.

Compensa?

Essa é pergunta que muitos fazem. Bom, responderia dizendo que sim. É um bom curso, com aprendizado diferenciado, baseado em experiência e case e não é só formado por conteúdo teórico. É como o meu CST, Michel Goldenberg, falou: “se fosse teórico e explicar o que já tem no Wikipedia, ninguém precisava estar aqui, pois isso já está disponível de graça”.

Valor do investimento

R$ 1.950,00. É isso que você vai ter que investir. Não posso dizer que é um valor fácil. A única coisa que invisto sem estar muito preocupado é no conhecimento, então nunca vejo um investimento em conhecimento como perdido. Mesmo se um dia fizer um curso e ele for ruim, eu vou conseguir aprender algo com ele. Do lado negativo sempre dá pra tirar algo de positivo para o seu aprendizado, mesmo que não seja no conteúdo do curso.

O mercado

Como o mercado vai ver essa certificação? Da mesma forma que ele vê as demais – talvez essa aqui ainda pior, porque um dos problemas ainda existentes é saber se quem analisa sabe interpretar e conhecer o curso e como ele qualifica o aluno.

Conclusão

Foi um curso muito produtivo, conheci pessoas diferentes, o Michael é de fato um cara muito experiente e com uma boa didática. Ele fez o que pouco fazem, ensina o porquê das coisas. Como eu não sou muito preso a esses papéis de parede, faria o curso mesmo sem certificado – não estou muito preocupado com ele, exceto se eu precisasse vender para um cliente que gosta de ver esses títulos “in english” de preferência.

Fonte: http://imasters.com.br/artigo/24284/agile/certified-scrum-master--como-e-o-processo-para-a-certificacao?trace=1519021197&source=single

Kanban e a facilidade visual

  A capacidade do cérebro de processar informações visuais é muito maior do que a de processar informações textuais. Usando o Kanban é possível ver todo o trabalho e entender com mais facilidade quais tarefas precisam ser realizadas e quais já foram cumpridas. Assim a ferramenta permite que vc observe o fluxo e consiga identificar gargalos e  filas.

  Quando você olha para seu processo graficamente, fica mais fácil organizar e limitar a quantidade de tarefas em processo ou inacabadas e com isso priorizar atividades. Outra grande vantagem do Kanban é que ele facilita a troca de informações, contribuindo para uma cultura de colaboração dentro da empresa.Você vai notar que, conforme for usando o Kanban, conseguirá detectar problemas escondidos, atrasos e falhas em sua gestão. Assim, essa é uma ferramenta que também te ajuda a encontrar soluções mais eficientes e melhorar seus processos.

   Essa ferramenta é muito útil tanto para grandes indústrias, como para pequenas e médias empresas. Afinal, mesmo que você tenha uma startup, o ritmo de vida e de produção imposto pelo mercado exige das empresas muita eficiência nos processos.O Kanban pode ser usado, por exemplo, para te ajudar no controle de estoque, e também para acompanhar processos ligados à serviços e atendimentos de demanda ou para gerir o seu funil de vendas.

   Para você aplicar o kanban nos processos da sua empresa é preciso, antes de mais nada, engajar toda a sua equipe. Ora, se é um sistema que funciona justamente por ser simples de manejar e alterar informações, todos devem saber como operar ele e participar ativamente desse fluxo. É responsabilidade de cada um manter o painel escolhido sempre atualizado e completo.

Fonte:https://endeavor.org.br/kanban/

A Ideia Central do Kanban

  O Kanban é baseado numa ideia muito simples. As Atividades em andamento devem ser limitadas. Algo novo só deve ser iniciado quando uma peça de trabalho existente é liberada ou quando uma função automática inicia isso.

  O Kanban, ou cartão de sinalização, é um sinal visual produzido indicando que novo trabalho pode ser iniciado e que a atividade atual não coincide com o limite acordado. Isso não soa muito revolucionário nem parece afetar profundamente o desempenho, cultura, capacidade e maturidade de uma equipe e a organização na qual está inserida. Mas o impressionante é que afeta! O Kanban parece uma mudança pequena e, no entanto, muda tudo a respeito de uma empresa.

  O que percebemos sobre o Kanban é que ele é uma abordagem para mudança gerencial. Ele não é um processo ou ciclo de vida de gerenciamento de projetos ou de desenvolvimento de software. O Kanban é uma abordagem para introduzir mudanças em um ciclo de desenvolvimento de software ou metodologia de gerenciamento de projetos. O princípio do Kanban é que você inicia com o que estiver fazendo agora. Você entende seu processo atual ao mapear o fluxo de valor e ao concordar, em seguida, em limitar as Atividades em andamento (do inglês WIP) para cada estágio desse processo. A partir daí você começa a rastrear as atividades pelo sistema para iniciá-las quando os sinais do Kanban aparecerem.

  O Kanban tem sido útil para equipes ágeis de desenvolvimento de software, mas tem ganhado popularidade, igualmente, em equipes que utilizam uma abordagem mais tradicional. Ele está sendo introduzido como parte de uma iniciativa Lean (enxuta) para moldar a cultura das organizações e encorajar a melhoria contínua.Porque o WIP é limitado em um sistema Kanban, tudo que fica bloqueado por qualquer motivo tende a parar o sistema.Se certa quantidade de itens de trabalho fica bloqueada, todo o processo pára de funcionar. Isso cria a necessidade de concentrar toda a equipe e toda a empresa na solução do problema para desbloquear o item e restaurar o fluxo.

Fonte: https://www.infoq.com/br/minibooks/kanban-scrum-minibook