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