lean-software-development

Lean Software Testing: 2. Lean Software Development

Agora que já foi falado brevemente sobre as raízes do Lean no post anterior, vamos falar sobre Lean Software Development e, para tal, tomei a liberdade de ler e fazer um resumo do conteúdo que li no Livro “Lean Software Develpment: An Agile Toolkit” de Mary Poppendieck e Tom Poppendieck. Espero que gostem!

#1 Eliminar Desperdício

Desperdício é qualquer coisa que não adiciona valor a um produto, ou seja, valor percebido pelo cliente.

No pensamento lean, o conceito de desperdício é um grande obstáculo. Se um componente/peça, não está sendo usado, é um completo desperdício. Se uma fábrica produz mais do que realmente é necessário, isto é um desperdício. Assim, é necessário descobrir o que o cliente quer e, em seguida, desenvolvê-lo ou entregar exatamento o que ele quer. O que que que ficar no caminho entre produzir e satisfazer a necessidade do cliente é um desperdício. Logo, um defeito gerado em qualquer uma das etapas de desenvolvimento e que impacte no uso do cliente de um produto é também um grande desperdício.

Ainda podemos ir mais além, gastar com Gestão de Defeitos: é um completo desperdício!

#2 Amplificar o Aprendizado

“O desenvolvimento é um exercício de descoberta, enquanto a produção é um exercício de reduzir a variação” e, por esta razão, uma abordagem lean de desenvolvimento resulta em práticas que são um pouco diferentes do que uma produção lean. Desenvolver é como criar uma receita, enquanto que produzir é como criar um prato. Receitas são projetas por chefs experientes que desenvolveram o instinto para saber o que funcionar e o que não funciona, eles tẽm a capacidade de adaptar ingredientes disponíveis para atender a ocasião. No entanto, mesmo grandes chefs podem produzir muitas variações de um mesmo prato iterando o gosto e a facilidade de reprodução com uma mesma receita. Chefs não esperam obter uma receita perfeita na primeira tentativa. Espera-se que eles produzam várias variações como objeto de estudo e como parte do processo de aprendizagem. O processo de desenvolvimento é melhor concebido em um processo de aprendizagem similar com desafio adicional de que times de desenvolvimento são grandes e mais complexos do que uma receita. Logo, a melhor abordagem para melhorar a qualidade no desenvolvimento de software é amplificar o aprendizado do time e o crescimento pessoal e profissional.

#3 Decidir tão tarde quanto possível

As práticas de desenvolvimento que provisionam decisões tardias são eficazes em domínios que envolvem incerteza, porque elas fornecem uma abordagem orientada a “opções”. Em face da incerteza, a maioria dos mercados econômicos desenvolvem “opções” para fornecer uma forma dos investidores evitarem o bloqueio nas decisões até que o futuro esteja mais perto e mais fácil de se prever. Retardar decisões é uma prática valiosa porque melhores decisões podem ser feitas quando elas são baseadas em fatos, não em especulações. Uma das principais estratégias para atrasar decisões no desenvolvimento de um complexo sistema é construir uma sistema capaz de ceder à mudanças. A arquitetura dele deve tornar possível alterações frequentes. Para tal, é necessário que se tenha uma boa camada de testes desenvolvida que permita a realização de alterações na arquitetura mantendo o pleno funcionamento do sistema.

#4 Entregar tão cedo quanto possível

Até recentemente, desenvolvimento rápido de software não era valioso; uma abordagem de “não cometer qualquer erro” parecia ser mais importante e ser cuidadoso era essencial. Mas estamos na era dos mitos “velocidade custa mais” e “qualidade custa mais” que foram atualmente desacreditados. Desenvolvimento rápido de software tem muitas vantagens. Sem velocidade você não pode atrasar decisões, porque demoraria tempo demais na execução. Sem velocidade de execução, você não tem um feedback confiável. No desenvolvimento, o seguinte ciclo é crítico para o aprendizado: projetar, implementar, dar feedback, melhorar. Quanto mais curtos forem estes ciclos, mais você pode aprender com eles. A velocidade garante que clientes alcancem o que eles precisam agora, não o que eles precisavam ontem. Também lhes permite adiar o pensamento sobre o que eles realmente querem até que eles saibam mais sobre o que realmente querem. Comprimir o fluxo de valor, tanto quanto possível, é uma estratégia lean fundamental para a eliminação de desperdícios.

#5 Empoderizar o time

Uma execução de alto nível encontra-se em obter os detalhes certos, e ninguém entende os detalhes melhor do que as pessoas que realmente fazem o trabalho. Envolver desenvolvedores nos detalhes das decisões técnicas é fundamental para alcançar a excelência. As pessoas que estão na linha de frente devem combinar o conhecimento dos detalhes minuciosos com o poder de muitas mentes. Quando equipado com as competências necessárias e guiado por um líder, eles vão tomar melhores decisões técnicas e melhores decisões de processo do que qualquer um poderia fazer. Como as decisões são feitas tardiamente, e execução é rápida, não é preciso ter uma autoridade central para orquestrar atividades dos desenvolvedores.

Desta forma, as práticas lean usam técnicas de puxar a agenda de trabalho e contém mecanismos de sinalização locais para que então os trabalhadores possam deixar o outro saber o que precisa ser feito. No desenvolvimento lean de software, o mecanismo de tração é um acordo para entregar versões cada vez mais refinados de software trabalhando em intervalos regulares. A sinalização ocorre por meio de gráficos visíveis, reuniões diárias, a integração frequente e testes abrangentes.

#6 Construção de Integridade/Confiança

Um sistema é reconhecido por ter integridade quando um usuário pensa: “Sim! Isso é exatamente o que eu quero. Alguém entrou dentro da minha mente!”. Integridade conceitual significa que os conceitos centrais do sistema funcionam em conjunto como um todo refinado, coeso. O software precisa de um nível adicional de confiança – ele deve manter a sua utilidade ao longo do tempo e deve evoluir graciosamente, bem como se adaptar ao futuro. Software com integridade tem uma arquitetura coerente, alta usabilidade e adequação a um fim, e é de fácil manutenção, adaptável e extensível. A pesquisa mostra que a confiança vem de sábia liderança, conhecimentos especializados, uma comunicação eficaz, e disciplina saudável; processos, procedimentos e medidas não são substitutos adequados.

#7 Ver o todo

Confiança em sistemas complexos exige uma profunda expertise em diversas áreas. Um dos problemas mais difíceis de tratar com o desenvolvimento do produto é que os especialistas em qualquer área (por exemplo, base de dados ou GUI) têm uma tendência para maximizar o desempenho da parte do produto que representa a sua própria especialidade em vez de focar sobre o desempenho global do sistema. Muitas vezes, o bem comum sofre se pessoas defendem primeiro a seus próprios interesses específicos. Quando os indivíduos ou organizações são medidos na sua contribuição específica em vez de desempenho global, subotimização é provávelmente o resultado. 

Obrigada por apreciar o post, no próximo  vamos falar sobre “Lean Software Testing”.

Acompanhe deixando seu contato aqui!

Anúncios

Um comentário sobre “Lean Software Testing: 2. Lean Software Development

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s