Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- Optimize the whole
Eliminate wasteEdit
Lean philosophy regards everything not adding value to the customer as waste (muda). Such waste may include:
- Partially done work
- Extra features
- Relearning
- Task switching
- Waiting
- Handoffs
- Defects
- Management activities
In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Recursos extras como papelada e recursos não utilizados com freqüência pelos clientes são desperdício. Trocar pessoas entre tarefas é um desperdício. Esperar por outras actividades, equipas, processos é um desperdício. A reaprendizagem necessária para completar o trabalho é um desperdício. Defeitos e qualidade inferior são desperdício. Despesas gerais gerenciais que não produzem valor real são desperdício.
Uma técnica de mapeamento de fluxo de valor é usada para identificar desperdício. O segundo passo é apontar as fontes de desperdício e eliminá-las. A remoção de desperdício deve ocorrer iterativamente até mesmo processos e procedimentos aparentemente essenciais serem liquidados.
Amplify learningEdit
O desenvolvimento de software é um processo contínuo de aprendizagem baseado em iterações ao escrever código. O design de software é um processo de resolução de problemas envolvendo os desenvolvedores que escrevem o código e o que eles aprenderam. O valor do software é medido em adequação ao uso e não em conformidade com os requisitos.
Em vez de adicionar mais documentação ou planejamento detalhado, idéias diferentes poderiam ser tentadas escrevendo código e construindo. O processo de levantamento de requisitos do usuário poderia ser simplificado, apresentando telas aos usuários finais e obtendo sua contribuição. O acúmulo de defeitos deve ser evitado executando testes assim que o código é escrito.
O processo de aprendizado é acelerado pelo uso de ciclos curtos de iteração – cada um acoplado a testes de refatoração e integração. Aumentar o feedback através de sessões curtas de feedback com os clientes ajuda a determinar a fase atual de desenvolvimento e a ajustar os esforços para melhorias futuras. Durante essas curtas sessões, tanto os representantes dos clientes quanto a equipe de desenvolvimento aprendem mais sobre o problema do domínio e descobrem possíveis soluções para o desenvolvimento futuro. Assim, os clientes compreendem melhor suas necessidades, com base no resultado existente dos esforços de desenvolvimento, e os desenvolvedores aprendem como melhor satisfazer essas necessidades. Outra idéia no processo de comunicação e aprendizagem com um cliente é o desenvolvimento baseado em conjuntos – isto se concentra em comunicar as restrições da solução futura e não as soluções possíveis, promovendo assim o nascimento da solução via diálogo com o cliente.
Decidir o mais tarde possívelEditar
Como o desenvolvimento de software está sempre associado a alguma incerteza, melhores resultados devem ser alcançados com uma abordagem baseada em conjuntos ou em opções, atrasando as decisões o máximo possível até que elas possam ser tomadas com base em fatos e não em suposições e previsões incertas. Quanto mais complexo for um sistema, mais capacidade de mudança deve ser incorporada, permitindo assim o atraso de compromissos importantes e cruciais. A abordagem iterativa promove este princípio – a capacidade de se adaptar às mudanças e corrigir erros, que podem ser muito dispendiosos se descobertos após o lançamento do sistema.
Com o desenvolvimento baseado em conjuntos: Se for necessário um novo sistema de travagem para um automóvel, por exemplo, três equipas podem conceber soluções para o mesmo problema. Cada equipe aprende sobre o espaço do problema e projeta uma solução potencial. Como uma solução não é considerada razoável, ela é cortada. No final de um período, os desenhos sobreviventes são comparados e um é escolhido, talvez com algumas modificações baseadas na aprendizagem dos outros – um grande exemplo de adiamento do compromisso até o último momento possível. As decisões de software também poderiam se beneficiar desta prática para minimizar o risco trazido pelo grande projeto inicial. Além disso, haveria então múltiplas implementações que funcionariam corretamente, mas que são diferentes (implementações, internamente). Estas poderiam ser usadas para implementar sistemas tolerantes a falhas, que verificam todas as entradas e saídas para a correção, em todas as múltiplas implementações, simultaneamente.
Uma abordagem ágil de desenvolvimento de software pode mover a construção de opções mais cedo para os clientes, atrasando assim certas decisões cruciais até que os clientes tenham percebido melhor as suas necessidades. Isto também permite uma adaptação posterior às mudanças e a prevenção de decisões onerosas mais cedo ligadas à tecnologia. Isto não significa que nenhum planejamento deve ser envolvido – pelo contrário, as atividades de planejamento devem ser concentradas nas diferentes opções e adaptação à situação atual, bem como esclarecer situações confusas, estabelecendo padrões de ação rápida. Avaliar diferentes opções é eficaz assim que se percebe que elas não são livres, mas proporcionam a flexibilidade necessária para a tomada de decisões tardias.
Entregar o mais rápido possívelEditar
Na era da evolução rápida da tecnologia, não é o maior que sobrevive, mas o mais rápido. Quanto mais rápido o produto final for entregue sem grandes defeitos, mais rápido o feedback pode ser recebido, e incorporado na próxima iteração. Quanto mais curtas as iterações, melhor o aprendizado e a comunicação dentro da equipe. Com a rapidez, as decisões podem ser adiadas. A velocidade garante o cumprimento das necessidades atuais do cliente e não do que ele precisava ontem. Isto dá-lhes a oportunidade de adiar a tomada de decisão sobre o que realmente necessitam até adquirirem um melhor conhecimento. Os clientes valorizam a entrega rápida de um produto de qualidade.
A ideologia da produção just-in-time poderia ser aplicada ao desenvolvimento de software, reconhecendo os seus requisitos e ambiente específicos. Isto é conseguido apresentando o resultado necessário e permitindo que a equipe se organize e divida as tarefas para alcançar o resultado necessário para uma iteração específica. No início, o cliente fornece o input necessário. Isto poderia ser simplesmente apresentado em pequenos cartões ou histórias – os desenvolvedores estimam o tempo necessário para a implementação de cada cartão. Assim, a organização do trabalho muda para um sistema de auto-pulsão – todas as manhãs, durante uma reunião de stand-up, cada membro da equipe analisa o que foi feito ontem, o que deve ser feito hoje e amanhã, e pede quaisquer informações necessárias aos colegas ou ao cliente. Isto requer transparência do processo, o que também é benéfico para a comunicação da equipe.
O mito subjacente a este princípio é a pressa que faz desperdício. Entretanto, a implementação do lean tem proporcionado que é uma boa prática entregar rapidamente para ver e analisar os resultados o mais cedo possível.
Capacitar a equipeEditar
Há uma crença tradicional na maioria das empresas sobre a tomada de decisões na organização – os gerentes dizem aos trabalhadores como fazer seu próprio trabalho. Em uma técnica de work-out, os papéis são transformados – os gerentes são ensinados a ouvir os desenvolvedores, para que eles possam explicar melhor quais ações podem ser tomadas, bem como fornecer sugestões de melhorias. A abordagem lean segue o princípio ágil “construir projetos em torno de indivíduos motivados e confiar neles para fazer o trabalho”, encorajando o progresso, detectando erros e removendo impedimentos, mas não a micro-gestão.
Uma outra crença equivocada tem sido a consideração das pessoas como recursos. As pessoas podem ser recursos do ponto de vista de uma folha de dados estatísticos, mas no desenvolvimento de software, assim como em qualquer negócio organizacional, as pessoas precisam de algo mais do que apenas a lista de tarefas e a garantia de que não serão incomodadas durante a conclusão das tarefas. As pessoas precisam de motivação e um propósito maior para trabalhar – dentro da realidade alcançável, com a garantia de que a equipe pode escolher seus próprios compromissos. Os desenvolvedores devem ter acesso ao cliente; o líder da equipe deve fornecer suporte e ajuda em situações difíceis, bem como garantir que o ceticismo não arruine o espírito da equipe. Respeitar as pessoas e reconhecer seu trabalho é uma forma de capacitar a equipe.
Construir integridade emEdit
O cliente precisa ter uma experiência geral do sistema. Esta é a chamada integridade percebida: como ela está sendo anunciada, entregue, implantada, acessada, quão intuitiva é sua utilização, seu preço e quão bem resolve os problemas.
Integridade conceitual significa que os componentes separados do sistema funcionam bem juntos como um todo, com equilíbrio entre flexibilidade, capacidade de manutenção, eficiência e capacidade de resposta. Isto poderia ser alcançado através da compreensão do domínio do problema e da sua resolução ao mesmo tempo, e não sequencialmente. A informação necessária é recebida em pequenos lotes – não em um grande pedaço – de preferência por comunicação face a face e não por qualquer documentação escrita. O fluxo de informação deve ser constante em ambas as direções – do cliente para os desenvolvedores e vice-versa, evitando assim a grande quantidade de informação estressante após um longo desenvolvimento isolado.
Um dos caminhos saudáveis para uma arquitetura integral é a refatoração. À medida que mais funcionalidades são adicionadas à base de código original, quanto mais difícil se torna adicionar mais melhorias. A refatoração consiste em manter a simplicidade, clareza, número mínimo de recursos no código. As repetições no código são sinais de mau desenho de código e devem ser evitadas. O processo de construção completo e automatizado deve ser acompanhado por uma suíte completa e automatizada de testes para desenvolvedores e clientes, tendo a mesma versão, sincronização e semântica que o estado atual do sistema. No final, a integridade deve ser verificada com testes completos, garantindo assim que o Sistema faça o que o cliente espera que faça. Os testes automatizados também são considerados parte do processo de produção e, portanto, se não agregarem valor, devem ser considerados um desperdício. Os testes automatizados não devem ser um objetivo, mas sim um meio para um fim, especificamente a redução de defeitos.
Otimizar o WholeEdit
Sistemas de software modernos não são simplesmente a soma de suas partes, mas também o produto de suas interações. Os defeitos no software tendem a acumular-se durante o processo de desenvolvimento – ao decompor as grandes tarefas em tarefas menores, e ao padronizar diferentes estágios de desenvolvimento, as causas raiz dos defeitos devem ser encontradas e eliminadas. Quanto maior o sistema, mais organizações estão envolvidas no seu desenvolvimento e mais partes são desenvolvidas por diferentes equipes, maior a importância de ter relações bem definidas entre diferentes fornecedores, a fim de produzir um sistema com componentes que interajam de forma suave. Durante um período de desenvolvimento mais longo, uma rede de subcontratados mais forte é muito mais benéfica do que a optimização do lucro a curto prazo, que não permite relações ganha-ganha.
O pensamento delgado tem de ser bem compreendido por todos os membros de um projecto, antes de ser implementado numa situação concreta e real. “Pense grande, aja pequeno, falhe rapidamente; aprenda rapidamente” – estes slogans resumem a importância de entender o campo e a adequação da implementação dos princípios lean ao longo de todo o processo de desenvolvimento de software. Somente quando todos os princípios lean são implementados em conjunto, combinados com um forte “senso comum” com respeito ao ambiente de trabalho, existe uma base para o sucesso no desenvolvimento de software.