O LSD (Lean Software Development) se baseia no Lean que é uma maneira de trabalhar que se concentra na remoção de resíduos de um processo.

Já falamos na nossa série Agile Methods sobre Crystal e sobre DSDM, hoje vamos falar um pouco de LSD.

Neste artigo, focaremos nos seguintes aspectos do Lean no desenvolvimento de software:

  • O que é o LSD (Lean software development) – Nesta seção, aprenderemos a história do Lean, quando e como o Lean foi inventado? Como evoluiu para a indústria de software a partir da indústria de transformação? O que é gerenciamento Lean no desenvolvimento de software?

  • Artefatos LSD– Vamos aprender sobre os artefatos primários do lean. Vamos começar a conhecer os adicionando valor e atividades adição de não-valor . Também discutiremos diferentes tipos de resíduos no Desenvolvimento de Software em detalhes.

  • Papéis e responsabilidades magras – Há três papéis importantes no processo de desenvolvimento de Lean – mestre Lean, Líder do Projeto Lean, e magras Equipe M brasas. Aqui conheceremos suas responsabilidades.

  • Fluxo do processo Lean – Aqui, falaremos sobre os princípios a serem seguidos durante todo o fluxo do processo Lean.

O que é LSD – desenvolvimento de software enxuto?

Lean Software DevelopmentEm primeiro lugar temos muitas outras metodologias em Agile como Scrum e Extreme Programming, então por que o Lean ? O que o diferencia de outros métodos?

Aqui está a resposta: a metodologia Lean Development diminui custos, esforços e desperdícios.

O desenvolvimento de software enxuto é uma metodologia de iteração desenvolvida inicialmente para a indústria de transformação para otimizar a produção e evitar desperdícios.

Primeiramente, muitos dos princípios e práticas do Lean Software Development vieram do movimento das empresas enxutas e foram inicialmente usados ​​por grandes empresas como a Toyota.

Desde que Mary e Tom Poppendieck1 trouxeram o Lean para o mundo do desenvolvimento de software eles converteram todos os valores, práticas e princípios de acordo com a indústria de software, documentaram todos eles em um único livro e os colocaram em prática.

Artefatos Lean

Todas as atividades em qualquer setor são divididas em Valor Agregado (VA) ou Valor Não Agregado (NVA).

Atividades de valor agregado

São todas as atividades que melhoram fisicamente um produto ou serviço para os clientes – o que significa que são as atividades que agregam valor!

Atividades sem valor agregado (NVA)

São as atividades que não agregam valor, mas são executadas. O cliente tem que arcar com o custo do NVA e, como não possui valor agregado, o cliente não deseja pagar por isso.

Desperdício

Para entender melhor o desperdício, podemos considerar um exemplo muito simples de um forno. O design de um forno é tal que, se você abrir a porta, ela para automaticamente e economiza eletricidade.

Da mesma forma, em termos técnicos, se um recurso não for útil, nenhuma codificação extra será necessária. Os japoneses chamam desperdício de “Muda”.

Enquanto o foco principal do Lean é remover resíduos e manter o que é obrigatório.

Os 7 Desperdícios de desenvolvimento de software (LSD)

Lean Manufacturing e Toyota Production Systems (TPS ) foram os primeiros a desenvolver o Lean Software Development . No TPS, eles dividiram o lixo em sete seções principais.

Mary e Tom Poppendeick2, interpretaram esses sete desperdícios de fabricação em sete desperdícios de desenvolvimento de software. Esses sete resíduos são agregados sem valor agregado e atuam como oponentes.

Eles nos fazem desperdiçar nossos esforços, tempo e custo.

Depois de entendermos todos os sete resíduos, poderemos identificar os resíduos no processo, independentemente da indústria.

Depois de identificá-lo, você pode eliminá-lo e, portanto, aumentar sua eficiência, produtividade e receita.

Abaixo estão os resíduos na indústria de transformação e são reconhecidos na indústria de software como abaixo:

Resíduos da indústria de transformaçãoResíduos da indústria de desenvolvimento de software
InventárioTrabalho incompleto / parcial realizado
Processamento extraExtra ou não necessário
SuperproduçãoProcessamento adicional ou documentação adicional
TransporteTroca de tarefas
EsperandoEspera / atraso
MovimentoNão interferir
DefeitoDefeito (parece contra-intuitivo neste momento, mais detalhes abaixo)

LSD 7 desperdícios

LSD RESÍDUOS 1: Trabalho incompleto / parcial concluído

O trabalho não agrega valor ao cliente até sua conclusão, o que, por sua vez, mantém os recursos ocupados. Além disso, até e a menos que não esteja completo, não podemos descobrir se funcionará ou não.

Exemplos:

  • Documentação de codificação incompleta
  • Código parcial ou incompleto
  • Código não verificado

Como reduzir?

  • Tente não deixar as coisas inacabadas
  • Limite e decida concluir o trabalho em andamento

LSD RESÍDUOS 2: recurso extra ou não necessário

Um recurso que não foi exigido pelo cliente ou não é sugerido pelo cliente, mas que faz parte do pacote, é chamado de Recurso Extra.

Por exemplo, se a calculadora científica for um software, existem muitos recursos, como ângulos (sin, cos, tan), raiz quadrada etc. que podem não ser usados ​​por todos, mas são parte do pacote.

Aí vem a regra 80:20 na indústria de software. Isso significa que 80% dos usuários usam apenas 20% dos recursos.

Exemplo

Às vezes, o cliente pode se deixar levar pela tecnologia mais recente e acabar exigindo um recurso como um controle deslizante em um site, que raramente será ou não será usado pelo usuário final.

Como reduzir? “Em vez de se preocupar em como desenvolver as coisas mais rapidamente, é muito melhor aprender a parar de desenvolver coisas que não são importantes e se concentrar nas coisas que terão o impacto real” – The Lean Mindset.

LSD RESÍDUOS 3: Processamento Extra ou Documentação Extra

No entanto o processamento extra é etapas adicionais incompetentes ou desnecessárias do processo que não agregam valor ao processo de desenvolvimento .

Exemplos:

  • Documentação muito detalhada
  • Atividades extras de gerenciamento / planejamento

Como reduzir?

  • Minimize atividades extras
  • Planejar conforme o requisito

LSD RESÍDUOS 4: Troca de tarefas (hand-off)

Toda vez que uma pessoa se desloca entre as tarefas, é necessário um tempo significativo para reunir as informações, pensamentos e entrar na nova tarefa.

Segundo a pesquisa, são necessários no mínimo 15 minutos de concentração para entrar no fluxo e, durante esse tempo, você não é produtivo.

Imagine – se um desenvolvedor for interrompido duas vezes por dia, mais de meia hora de trabalho será perdida.

Exemplo:

  • Uma pessoa trabalhando em dois projetos
  • Desenvolvedor interrompido para intervalos para conversas sobre outros projetos.

Como reduzir?

  • Minimize o embaralhamento e atribua recursos a um projeto por vez
  • Elimine o que não é importante
  • Minimizar interrupções
  • Priorizar as atividades

LSD RESÍDUOS 5: Aguardando / Atrasos

Ainda existem algumas atividades para as quais precisamos de aprovações ou alguma ação é requerida por outra equipe.

Então, essa espera pela aprovação ou a espera de informações leva ao desperdício chamado desperdício de “espera / atraso”.

Exemplos:

  • À espera de entradas / informações
  • Atrasos nas aprovações
  • Teste atrasado

Como reduzir?

  • Sentado no mesmo local que o cliente, isso ajuda nas aprovações rápidas.
  • Conversas cara a cara
  • Feedback regular

LSD RESÍDUOS 6: Transferência

Ainda por cima existe conhecimento perdido toda vez que um produto / artefato é entregue (analista, designer, desenvolvedor e testador).

Enquanto entregamos, não podemos contar tudo em detalhes, por mais que tentemos; sempre faltava alguma informação

Como reduzir?

  • Menos alternância preferida
  • Uma pessoa deve receber uma atividade
  • A atividade deve ser entregue a alguém com experiência no mesmo campo

LSD RESÍDUOS 7: Defeito

Apesar de a resolução de defeitos levar muito tempo, primeiro aguarde até que seja reconhecida e, em seguida, aguarde a resolução.

Então as despesas incorridas com a correção de um defeito em um estágio inicial são significativamente menores do que as identificadas após a entrega do produto.

Como reduzir

  • Teste o mais cedo possível

Funções e Responsabilidades Lean:

Uma vez que queremos implementar o Lean em qualquer empresa, torna-se essencial considerar as pessoas como o principal ativo da empresa.

Os papéis principais no processo de desenvolvimento Lean são os seguintes:

Mestre Lean

Primeiramente qualquer equipe que trabalha em um ambiente enxuto consiste basicamente de três funções – Lean Master, Líderes de Projeto Lean e a equipe restante é chamada de “Membros da Equipe Lean”.

Em suma como o “Lean Master” deve ter experiência e ter trabalhado com o cliente no mesmo ambiente, ele estará mais ciente do projeto e do produto.

O Lean Master ajudará o cliente a:

  • Selecionar pessoas com as habilidades certas e relevantes, ou seja, alocar recursos.
  • Coach, Train e Mentor em Gestão Lean
  • Atualizar plano diretor
  • Gerenciar alterações
  • Fornecendo segurança de trabalho pela empresa
  • Compreende ferramentas e técnicas Lean
  • Entende o que esperar durante a transição e depois disso

Líderes de Projeto Lean

Inclusive Líder de Projeto Lean atua não só como um canal de comunicação entre o Lean Master e a equipe, mas também como motivador.

Suas principais responsabilidades incluem:

  • Liderar equipes e projetos enxutos o tempo todo
  • Relatar progresso e remover barreiras
  • Comunicador e organizador
  • Responsável pela melhoria da equipe

Membros da equipe Lean

Por conseguinte um projeto de tamanho pequeno, a equipe Lean será composta por 6-9 membros.

Suas funções e responsabilidades são as seguintes:

  • Representar todas as etapas do processo
  • Especialista no processo e no trabalho que eles fazem. Como desenvolvedores, testadores.
  • Trabalhem juntos para projetar e implementar uma solução.

Princípios de desenvolvimento de software Lean

Uma vez que Tempo, distância, tamanho da equipe, força de trabalho, e apesar de todas essas limitações no mundo real, o foco principal do Lean permanece o mesmo – remover o desperdício e, portanto, tornar seu processo mais eficaz e sempre buscando concluir seu trabalho com o mínimo de esforço possível.

LSD - Principios

Vamos dar um exemplo de restaurante para entender melhor o fluxo de trabalho enxuto. Em um domingo, vamos considerar, em média, 100 pessoas em uma hora para jantar neste restaurante. Agora, como proprietário do restaurante, o que você fará para alimentá-los com eficiência?

Eliminar desperdício

Na indústria de desenvolvimento de software, Códigos desnecessários, Transporte, Trabalho parcialmente concluído, Defeitos, Troca de tarefas e Processamento excessivo , estes são alguns dos exemplos dos sete resíduos mencionados acima.

Embora esses resíduos devem ser identificados e removidos em todos os estágios para fornecer recursos de funcionamento mais rápidos e melhores ao cliente, e os membros da equipe enxuta garantem que o façam corretamente.

Eles descobrem a fonte dos resíduos e depois trabalham na raiz.

Dados de uso de recursos, funções e documentos

A imagem acima mostra as funções gerais, recursos e dados de uso de documentos de uma empresa de desenvolvimento de software.

Em qualquer empresa de software, geralmente há uma grande parte das funções e recursos desenvolvidos, mas nunca usados ​​ou raramente utilizados.

Além disso o mesmo vale para documentos que não são utilizados. Todos esses recursos, funções e documentos são um desperdício para o sistema e sua fonte deve ser identificada e removida.

No exemplo do nosso restaurante

Primeiramente, não podemos deixar que nenhum de nossos funcionários gaste seu tempo em atividades improdutivas, como encontrar números de mesas para servir comida, conversar desnecessariamente com pessoas, receber pedidos divertidos que não são aplicáveis ​​etc., para servir com eficiência, você precisa garantir que não exista desperdício de tempo, custo ou mão de obra no processo .

Capacitar a equipe

Além disso na indústria de software, devemos respeitar o conhecimento e a experiência dos membros da equipe, pois eles estão praticamente trabalhando no projeto do cliente. Em resumo, devemos preferir que a equipe, ao invés do processo, seja produtiva e bem-sucedida.

Ainda na indústria de software, você pode capacitá-los

  • Dando a eles oportunidades de inovar e experimentar;
  • Ao permitir que eles tomem decisões locais;
  • Fornecendo a eles treinamento em novas tecnologias etc.

Para o nosso exemplo de restaurante – Você fornecerá à sua equipe tudo o que é necessário, como equipamentos, temperos, vegetais, óleo, material de limpeza, fogões, etc. Você também os manterá motivados, oferecendo pequenos sinais de agradecimento. Você confiará no conhecimento do chef e solicitará que cozinhem o seu melhor. Além disso, eles precisam confiar em sua experiência e habilidades de trabalho.

Entregar rápido

No Lean, identificamos as etapas que estão nos atrasando, as eliminamos, pois elas nos ajudarão na entrega rápida da solução de software para o cliente. Na Lean, desenvolvemos e entregamos soluções de software de forma incremental para o cliente.

O Lean Project Leader mantém um controle e garante a entrega pontual.

Para o nosso exemplo de restaurante – adotamos um caso em que fizemos dois processos diferentes:

Processo 1:

LSD - Exemplo 1

Tempo total gasto : 1 hora por cada pessoa.

Processo 2 :

LSD - Exemplo 2

Tempo total gasto : 30 minutos

É bastante evidente que o Processo 2 tem uma vantagem clara sobre o Processo 1 porque

  • Como todos os trabalhadores estão sendo utilizados, não há desperdício no processo.
  • Foram necessários apenas 30 minutos para servir a comida para o cliente no Processo 2, em comparação com uma hora no Processo 1, levando, portanto, à entrega rápida também .

Portanto, o restaurante se livrou do Processo 1, pois está desacelerando e segue o Processo 2 para uma entrega mais rápida.

Otimize o Todo

Portanto nas organizações de desenvolvimento de software, os desenvolvedores podem sentir-se pressionados a cumprir cronogramas rigorosos e acabar escrevendo códigos desleixados, o que pode resultar em mais defeitos. Isso, por sua vez, aumenta a carga de trabalho apenas para desenvolvedores.

Da mesma forma, se os testadores estiverem sobrecarregados com o trabalho, eles não poderão compartilhar suas descobertas com os desenvolvedores a tempo. Enquanto isso, os desenvolvedores continuam escrevendo código, aumentando assim o atraso dos testadores.

Enquanto uma organização pode facilmente superar essas situações, entendendo melhor a capacidade de seus testadores / desenvolvedores.

Para o nosso exemplo, este restaurante observa mais clientes durante a temporada festiva. Há uma pressão crescente sobre o chef para atender a todos esses pedidos no prazo.

Como resultado, ele perdeu o equilíbrio certo de temperos em 2-3 pratos, resultando em pedidos devolvidos. Isso causa retrabalho tanto para o chef quanto para a pessoa responsável por servir.

Para garantir a qualidade, evitar o retrabalho e a entrega pontual, a gerência do restaurante pode estabelecer um limite para o número máximo de clientes que eles atenderão a qualquer momento.

Assim que o número de clientes atingir esse limite, o restaurante não aceitará mais pedidos / clientes, o que ajuda a otimizar a produtividade, a qualidade da produção e o seu negócio como um todo .

Construir em qualidade

No setor de desenvolvimento de software, seu objetivo deve ser manter a qualidade desde o início e não testá-la em estágios posteriores.

Por exemplo, em primeiro lugar, o desenvolvedor deve tentar desenvolver uma codificação suave e sem erros.

Se ainda houver algum erro durante o teste de resolução, o desenvolvedor precisará garantir que:

  • A resolução do bug ocorre.
  • Uma análise minuciosa da causa raiz foi realizada.
  • Ele anota os detalhes para referência futura.

O motivo é que, se o mesmo bug existir em algum outro cenário, ele poderá ser corrigido durante o próprio estágio de desenvolvimento.

No exemplo do nosso restaurante, uma das expectativas básicas do cliente, do ponto de vista da qualidade, é a “higiene”, por isso é de extrema importância que todos os utensílios sejam cuidadosamente limpos em que a comida é servida. A gerência do restaurante gostaria de evitar qualquer risco por causa da “higiene”, portanto eles optaram por uma máquina de lavar louça, eliminando, assim, o risco potencial de reclamações de clientes por causa de pratos sujos.

Adiar decisão

Ainda que a maioria das decisões tenham um impacto direto no projeto. Sempre podemos tentar adiar as decisões até que sejam baseadas em fatos, porque as correções são difíceis na indústria de software, pois podemos precisar de aprovações e isso pode nos custar dinheiro também.

O mestre lean pode adiar decisões para evitar isso.

Para o nosso restaurante – caso algum cliente se queixe de que a comida é muito picante. Você sabe a quem questionar. Mas você não pode tomar decisões naquele momento; você precisa verificar os fatos e tentar resolver o problema, o que é mais importante do que tomar algumas decisões duras.

Ampliar o aprendizado

Quando se trata de um projeto bem-sucedido, o conhecimento desempenha um papel significativo no sucesso do projeto. O aprendizado é um processo contínuo que nunca é concluído.

Da mesma forma, precisamos continuar aprendendo com tudo o que codificamos, testamos, entregamos e descartamos. Precisamos manter esse conhecimento disponível para todos compartilhando e armazenando-o em algum local comum, como uma unidade compartilhada ou LMS.

O que, por sua vez, permite a todos no sistema:

  • Aprender coisas que fizeram bem no passado.
  • Evitar coisas que não funcionaram bem no passado.

Let´s Make Lean Software Development

Da mesma forma, em nosso exemplo, se o chef cria um prato muito saboroso, apreciado pelos clientes e recebe pedidos repetidos, sua receita deve ser compartilhada com o restante dos chefs.

Seria uma delícia para o restante dos chefs aprender o que o Chef fez de diferente para torná-lo ótimo.

Além disso, isso fará com que o restante da equipe esteja preparada para preparar um prato igualmente saboroso em sua ausência.

Como diria Walter Bishop3 “Excelent, lets make some LSD”

Com toda a certeza, depois de ler este artigo, podemos concluir:

O Lean é uma das metodologias altamente comprovadas e bem-sucedidas que ajudam a eliminar desperdícios, reduzir custos, melhorar a produtividade e ajudar a manter um alto nível de qualidade.

Vantagens do desenvolvimento de software enxuto (LSD)

  1. A eliminação de resíduos leva à eficiência geral do processo de desenvolvimento. Por sua vez, acelera o processo de desenvolvimento de software, o que reduz o tempo e o custo do projeto . Isso é absolutamente vital no ambiente de hoje. Qualquer coisa que permita às organizações entregar mais projetos no mesmo período será popular!

  2. A entrega antecipada do produto é uma vantagem definitiva. Isso significa que sua equipe de desenvolvimento pode fornecer mais funcionalidades em um período mais curto, permitindo, portanto, a entrega de mais projetos. Isso agradará apenas o seu departamento financeiro, mas também os clientes finais.

  3. O empoderamento da equipe de desenvolvimento ajuda no desenvolvimento da capacidade de tomada de decisão dos membros da equipe que, por sua vez, cria uma equipe mais motivada. Esse benefício realmente não pode ser estressado o suficiente. Os desenvolvedores odeiam nada mais do que ser microgerenciados e ter decisões impostas a eles. Dessa forma, eles podem determinar a melhor forma de desenvolver a funcionalidade que normalmente resultará em um produto final muito melhor.

Desvantagens do desenvolvimento de software enxuto (LSD)

1 Dependência

O projeto é altamente dependente da coesão da equipe e dos compromissos individuais dos membros da equipe. Na maioria das profissões, esse pode ser um fator muito importante, mas em TI o trabalho por horas longas e pouco sociáveis ​​é a norma, portanto não deve ser uma grande desvantagem.

E, é claro, se você não percebeu que os desenvolvedores e testadores de TI trabalham por longas e longas horas, então terá um despertar rude.

Por exemplo, gerencio grandes projetos e programas e, no fim de semana passado, trabalhei 33 horas das 48 horas disponíveis para liderar o diagnóstico e a correção de um problema grave que afetava meu projeto.

2 Disciplina

O sucesso no projeto depende de quão disciplinados os membros da equipe são e de quão excepcionais são suas habilidades técnicas.

Se você não possui uma equipe de pessoas com boas habilidades que se complementam, então você tem um problema imediato.

3 Decisão

Os patrocinadores e clientes do projeto precisam saber o que desejam e tomar decisões a que se aterão. No desenvolvimento de software lean, essas decisões podem ser tomadas mais tarde do que quando se usa metodologias em cascata, o que deve ser uma vantagem.

Mas o problema é que os patrocinadores do projeto tendem a ficar paralisados ​​pelo medo quando se trata de tomar decisões difíceis.

E, no lean, todo o objetivo de usar essa metodologia ágil, por exemplo, é permitir que seu desenvolvimento seja feito mais rápido e mais barato do que seria possível.

Obviamente, isso significa que as decisões devem ser tomadas prontamente quando necessário e atendidas.

4 Análise de negócios

O papel de um analista de negócios é vital para garantir que a documentação de requisitos de negócios (BRD) seja entendida corretamente.

Se você não tem uma pessoa com as habilidades corretas de analista de negócios, pode descobrir rapidamente que isso se torna uma causa do aumento do escopo .

5 Evolução

No lean, você permite que a especificação de requisitos de software (SRS) evolua. No entanto, isso causa problemas próprios.

A flexibilidade é ótima, mas muito dela levará rapidamente a um desenvolvimento que perde de vista seus objetivos originais e que nunca termina.

As vantagens e desvantagens do desenvolvimento de software enxuto (LSD)- Dica

Se você estiver lidando com as partes interessadas no gerenciamento de projetos que não conseguem tomar decisões rápidas e cumpri-las, ou estão gerenciando uma equipe de projeto que é menos do que estelar, não use a metodologia lean.

Em suma é um processo que, em certas circunstâncias, funciona bem, mas para a maioria dos projetos que abrangem um ciclo de vida de desenvolvimento de software , é muito restritivo para o trabalho pretendido, o que leva a terríveis consequências.

Referências

  1. Mary e Tom Poppendieck –  http://www.poppendieck.com/people.htm
  2. Mary e Tom Poppendeick – ‘Lean Software Development – An Agile Toolkit
  3. Fringe – Série 2008
Tags:, , , , ,

Leave a Reply