Hospedagem Profissional

Hospedagem Profissional
Clique aqui e ganhe US$ 10,00 para testar durante 1 mês a melhor hospedagem: Digital Ocean!

segunda-feira, 10 de outubro de 2011

Lean para desenvolvimento de Software. Afinal, o que é isto?

A filosofia "Lean Thinking" (ou "Pensamento Enxuto") nasceu em meados dos anos 90 com o lançamento do best seller "The Machine That Changed the World : The Story of Lean Production".  Os princípios de image

demanda puxada (pull systems), just-in-time, qualidade total, teoria das restrições, melhoria contínua e flexibilidade aplicados na indústria japonesa, mais precisamente na Toyota e conhecidos como Toyota Way inspiraram também a indústria de software e fez surgir a abordagem do Lean Software Development.

Mary e Tom Poppendieck (gurus de Lean voltado a TI, defensores do agile e autores do livro: "Lean Software Development - An Agile Toolkit" que mostra como os princípios Lean podem ser aplicados em abordagens de desenvolvimento de software ágil) usou a seguinte frase para definir Lean:

image

"What is Lean?

•  Deliver continually increasing customer value
•  Expending continually decreasing effort
•  In the shortest possible timeframe
•  With the highest possible quality
A journey, not a destination. "

E acrescentam:  "Acelerar a produção do desenvolvimento de Software é geralmente uma questão de melhorar o processo ao invés de adicionar pessoas. Pare de fazer coisas que o cliente não valoriza! Vista os óculos do cliente! "
Tentando resumir em uma frase, Lean é um princípio ágil cujo foco é cortar a "gordura" do processo de software, focando na eliminação de desperdícios.

Princípios Lean aplicados ao software:

  1.    Elimine Desperdícios
  2.    Inclua a Qualidade no Processo
  3.    Crie Conhecimento
  4.    Adie Decisões e Comprometimentos
  5.    Entregue o quanto antes
  6.    Respeite as Pessoas e "Empower" a equipe
  7.    Otimize o Todo
Vamos ver os 7 princípios de Lean e como transforma-los em práticas ágeis.

Princípio
#1 – Eliminar desperdícios
Desperdícios: tudo aquilo que não agrega valor para cliente final e que não são percebidos pelo cliente. Exemplo: passos extras, processo pesado e rígido, burocracia, documentação que nunca vai ser lida, que está na prateleira juntando poeira - não necessária, etc. Outro tipo de desperdício são trabalhos parcialmente prontos, tudo que começa e não termina, funcionalidades extras que não serão utilizadas, etc.image
  1. Enfim, software útil e de funcionando (de qualidade) é o que vai trazer valor ao cliente. Os sete desperdícios de software:
  2. Inventory = Requirements / Partially done work
  3. Extra Processing Steps = Extra processes, steps
  4. Overproduction = Extra features
  5. Transportation = Handoffs, tasks switching
  6. Waiting = Waiting
  7. Defects = Defects
  8. Motion = Finding Information

Não se iluda, embora alguns sejam gritantes não é fácil identificar alguns tipos de desperdício. É preciso aprender a enxergar os desperdícios e existem algumas práticas e exercícios que podem ajudar, tais como: Seeing waste e Value Stream mapping.

Vejamos os tipos de desperdícios mais detalhadamente:

1 - Requisitos

Requisitos, especificados muito cedo que perdem sua credibilidade, eficácia e compromete a usabilidade do sistema.

Trabalho incompleto (“em-progresso”) - Parcialmente feitos

Trabalhos parcialmente iniciados / terminados tendem a se tornar obsoletos.

O maior problema é não ter idéia se eventualmente funcionam ou não. Enquanto os trabalhos não são integrados, não podem ser utilizados e não temos como saber quais problemas podem aparecer. Funcionalidades pela metade apenas atravancam o caminho para trabalhos que poderiam ser feitos. Tornando-se facilmente obsoleto.

Consomem recursos sem trazer retorno.

Exemplos: Documentação não codificada, código não sincronizado, código não testado, código não implantado.

2 - Processos/Passos a mais

Burocracia, atividades, métricas, etc que não geram valor e que diminui o tempo de resposta.

Você alguma vez já se perguntou, toda aquela documentação e papelada é realmente necessária?

Documentação desnecessária e documentação que são esquecidos ou perdem valor e se tornam obsoletos ou documentos que ninguém se importa em ler.

O seu cliente realmente acha que isso torna o produto dele mais eficiente?

Dica: Faça esse questionamento para descobrir quando a documentação tem valor agregado : Tem alguém esperando ou dependendo do que você esta produzindo?.

Ainda assim lembre-se: Mantenha-o enxuto, em alto-nível e documente o mais tardar possível.

3 - Funcionalidades a mais

80% das funcionalidades implementadas não são utilizadas.

20% das funcionalidades é que são realmente úteis.

Código não-utilizado introduz complexidade e a complexidade é um inimigo da manutenção. Mais código para ser mantido. Mais testes para serem realizados. Mais documentos de especificação para serem criados. Se o código não é necessário agora colocá-lo no sistema é desperdício.

4 - Troca de tarefas (Task switching, Handoffs)

Corrida de revezamento deve ser substituída pela equipe multi-funcional.

Quanto maior os handoff’s maior é a perda de conhecimento. Organizar pessoas em múltiplos projetos é outra forma de desperdício.

Quanto tempo se perde para parar uma determinada atividade e iniciar outra, relembrar onde parou, concentrar-se e finalmente produzir algo?

5 - Atrasos

Atrasos na entrega, atrasos em geral são puro desperdício e irão gerar aumento do custo do projeto.

Em muitos casos, atrasos são apenas a ponta do iceberg para problemas muito maiores.

Espera: Um dos maiores desperdícios no desenvolvimento de Software é a espera para que as coisas aconteçam. Espera para o início do projeto, pela montagem da equipe, espera pela produção de documentação extensa, espera por processo de revisão ou aprovação, espera para testar, etc.  Veja, analise o que deve ser mantido, o que agrega valor e o que é puro despedício.

6 - Defeitos

Equipes ágeis se esforçam ao máximo para evitar defeitos.

“Inspecionar para prevenir defeitos é bom;

Inspecionar para encontrar defeitos é desperdício” -- Shigeo Shingo

Defeitos (Bugs) não agregam valor, não satisfazem o cliente, e custam muito muito caro.

7 - Movimento

Tempo e esforço gasto para encontrar informações.

Equipes ágeis valorizam a conversa e por isso trazem o cliente para perto, não devemos perder tempo lendo páginas e páginas de um documento para encontrar uma informação que ao mesmo tempo por estar na forma escrita muitas vezes são imprecisas e pode trazer mais dúvidas do que resolver o problema.

Princípio #2 – Qualidade embutida

Qualidade é inegociável. Entregue qualidade intrínseca e explícita aos seus clientes, se eles perceberem isso, significa que foi uma entrega de qualidade. Mary e Tom Poppendieck em seu livro identificaram duas dimensões de integridade: integridade percebida e integridade conceitual. A integridade percebida significa que a totalidade do produto alcança um equilíbrio entre as funções, usabilidade, confiabilidade, economia e isso encanta o cliente. A integridade conceitual significa que os conceitos centrais do sistema de trabalho em conjunto são facilitados e coesos. Essa última é fator crítico de sucesso para a integridade percebida.

Um produto possui integridade percebida quando o cliente o experimenta e diz: Isso! Era exatamente isso que eu queria! Software com integridade possui boas arquiteturas, possuem um alto nível de usabilidade e facilidade de uso, são fáceis de dar manutenção, de adaptar e de estender.

Dicas:

  • Não verificar a qualidade só no final, verificar durante todo processo e também toda equipe testa!
  • Quanto antes um problema é verificado mais barato ficará
  • Foco na prevenção, não na verificação no final do processo - Ao invés de se esforçar para gerenciar defeitos, evite-os.
  • "Logar" defeitos é desperdício, corrija-os imediatamente.

Práticas sugeridas para promover a qualidade:

  • 4 quadrantes de teste
  • TDD  - Test Driven Development
  • Refactoring
  • Integração contínua
  • Code review / code inspection
  • Standards
  • Testes contínuos e automatizados

Princípio #3 – Criar conhecimentos

Desenvolvimento é um exercício de descoberta, enquanto produção é um exercício de reduzir a variação. Desenvolvimento é como fazer uma nova receita, enquanto produção é como fazer um prato. Receitas são formuladas por chefes de cozinha experientes que de certa forma desenvolveram habilidades e capacidade de combinar os ingredientes disponíveis para produzir o prato desejado. Desenvolver uma receita é um processo de descoberta, até os chefes mais experientes produzem diversas variações de um novo prato, fazem iterações, experimentações, até encontrar a melhor combinação de ingredientes que resulte em um prato rápido e sabor agradável. Não se espera que os chefes obtenham uma receita perfeita de primeira; espera-se produzir diversas variações como parte do processo de aprendizagem. Desenvolvimento de software é melhor concebido se este fizer parte de um processo de aprendizado similar ao de criar uma nova receita. A melhor abordagem para melhorar o ambiente de desenvolvimento de software é pela expansão do conhecimento.

Práticas sugeridas para promover o conhecimento:

  • Ciclos de feedback e inspeções e adaptações;
  • Desenvolvimento iterativo;
  • Equipes pequenas e cross-functional;
  • Treinamentos e Mentoring;
  • Criação e utilização de standards, guidelines e qualquer outro artefato;
  • Code Reviews;
  • Meios de compartilhamento de informações como um Blog ou Wiki;

Princípio #4 – Adiar decisões / compromissos

O principal conceito deste princípio é diminuir as incertezas retardando as decisões até que possam serem feitas com base em acontecimentos mais firmes, previsíveis e conhecidos. Decisões tardias tendem a ser mais acertadas porque as melhores decisões são feitas baseadas em fatos, e não em suposições ou especulações. Uma estratégia chave para adiar decisões/comprometimentos quando desenvolvendo um sistema complexo e com muitas incertas é usar a capacidade e práticas que permitam abraçar as mudanças tardiamente.

Práticas sugeridas para adiar compromissos:

  • Iterações
  • Planning meetings
  • Behaviour/Feature Driven Development
  • Outros

Princípio #5 – Entregar rápido
Sem entregas rápidas não é possível colher feedback. Sem entregas rápidas não é possível aprender com erros. Velocidade na entrega garante que o cliente receberá o que ele precisa hoje e não o que ele precisava ontem.

Práticas sugeridas:

Princípio #6 – Respeitar as pessoas

Envolver os desenvolvedores nos detalhes das decisões técnicas é fundamental para o atingimento da exelência.

Dicas:

  • Um ambiente que favoreça o desenvolvimento das pessoas.
  • Uma empresa que respeita as pessoas, assim as pessoas irão respeitar a empresa

O Software produzido é como um espelho da equipe de desenvolvimento.

Para que as pessoas possam assumir responsabilidades, se sentir motivados e atuar como uma equipe eles precisam de confiança e de respeito.

Práticas sugeridas para promover o empowering do time:

  • Auto-gestão
  • Trabalho em equipe
  • feedback


Princípio

#7 – Otimizar o todo

Otimizar desde o começo até o final:

  • Utilize Métricas
  • Diminua o número de métricas de desempenho individual mas valorize o desempenho da equipe.
  • Meça para cima:
  • Tempo de ciclo +Mapa de Fluxo de Valor
  • ROI + Modelo de Lucros e Perdas
  • Satisfação do Cliente + Entendimento das suas necessidades

Para tornar o seu processo ágil, pense Lean!
Mas lembre-se Lean requer uma mudança da cultura e dos hábitos organizacionais para que esta possa usufruir das melhorias de performance que um processo enxuto pode proporcionar.

É UMA MUDANÇA DE MENTALIDADE E COMPORTAMENTO !

Por : Juliana Berossa Steffen

Certified Scrum Product Owner
Certified Scrum Master
Certified Professional Scrum Master