Por Sergio Crespo

Transcrição

1 Por Sergio Crespo

2 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 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.

3 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), definiram assim o Lean:

4 Entregar, aumentando continuamente valor para o cliente; Continuamente diminuir o esforço gasto; No prazo mais curto possível; Com a melhor qualidade possível a jornada, não um destino. De forma mais concisa, o Lean Manufacturing é uma filosofia que quando implementada reduz o tempo desde o pedido até à entrega ao cliente eliminando fontes de desperdício no fluxo de produção (Liker, 1996). Liker, J. (1996). Becoming Lean. New York:Free Press

5 Podemos ainda definir desperdício (Guedes, 2011) como alguma interrupção desnecessária, falta de coordenação, trabalho desnecessário, ou redundâncias que não adicionam qualquer valor ao cliente (Kleiner, 2005). Kleiner, A. (2005). Leaning toward utopia. Jorge F. Guedes, Introdução de conceitos Lean às Tecnologias de Informação: um caso de estudo em Banca, dissertação de mestrado, Faculdade de Engenharia da Universidade do Porto, 2011

6 Segundo o estudo CHAOS, conduzido pelo Standish Group em 1995, apenas 29% dos projectos de IT conseguem ser bem sucedidos, sendo que 53% conseguem ser completados com atrasos ou aumentos de orçamento e 18% simplesmente falham. Estes valores são já muito superiores aos 16% de sucesso em 1994, com 53% de deslizes e 31% de falhas.

7 O fraco planejamento das aplicações deve também ser considerado visto que, segundo o mesmo estudo (Standish Group, 2004), 64% das aplicações desenvolvidas não são usadas ou são usadas raramente. Um outro estudo publicado em 2001 indica que apenas 5% do código era útil ou até mesmo usado (Cohen, Larson and Ware, 2001). Pensando que cada linha de código desenvolvida tem um custo, somado ao custo do desenho, implementação e manutenção do mesmo, tornando estes dados realmente preocupantes. Cohen, D., Larson, G. & Ware, B. (2001). Improving Software Investments through Requirements Validation

8 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

9 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.

10

11

12 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.

13 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?

14 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.

15 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?

16 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 desperdício.

17 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.

18 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.

19 Qualidade é inegociável. Entregue qualidade intrínseca e explícita aos seus clientes, se eles perceberem isso, significa que foi uma entrega de qualidade. Um produto possui integridade percebida quando o cliente o experimenta e diz: Isso! Era exatamente isso que eu queria! Software com integridade percebida 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.

20 Criar conhecimento e partilhá-lo sempre que há alguma lição aprendida. Desta forma, não só a mesma pessoa não comete o mesmo erro duas vezes, como há partilha dessa experiência para outros não cometerem o mesmo erro. Desta forma é possível evitar erros e defeitos, bem como contribuir para uma maior formação dos colaboradores. Práticas sugeridas para promover o conhecimento: Ciclos de feedback e inspeções e adaptações; Desenvolvimento iterativo; Equipes pequenas; 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; Jorge F. Guedes, Introdução de conceitos Lean às Tecnologias de Informação: um caso de estudo em Banca, dissertação de mestrado, Faculdade de Engenharia da Universidade do Porto,

21 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.

22 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.

23 Envolver os desenvolvedores nos detalhes das decisões técnicas é fundamental para o atingimento da excelência. Práticas sugeridas para promover o capacitação/agregação do time: Auto-gestão Trabalho em equipe feedback

24 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 : Tempo de ciclo +Mapa de Fluxo de Valor ROI + Modelo de Lucros e Perdas Satisfação do Cliente + Entendimento das suas necessidades

25 Segundo Fadel e Silveira (2010), a metodologia Lean utiliza técnicas de produção puxada (pull) para agendar o trabalho e são dotadas de mecanismos com sinalizações locais, os quais ajudam os outros desenvolvedores a identificarem o trabalho que precisa ser realizado. A sinalização local é feita através de gráficos visuais, reuniões diárias, integrações frequentes e testes automatizados. No desenvolvimento de software Lean, esta técnica de produção puxada é correspondente à entrega de versões refinadas e incrementais do software em intervalos de tempo regulares. FADEL, Aline Cristine. SILVEIRA, Henrique da Mota. Metodologias ágeis no contexto de desenvolvimento de software: XP, Scrum e Lean. Limeira, Disponível em:< > Acesso em: 18 jun 2012.

26 Kanban é um termo de origem japonesa e significa literalmente cartão ou sinalização. É um conceito relacionado com a utilização de cartões (post-it e outros) para indicar o andamento dos fluxos de produção em empresas de fabricação em série. Nesses cartões são colocadas indicações sobre uma determinada tarefa, por exemplo, para executar, em andamento ou finalizado.

27 O Kanban é definido como um processo adaptativo de produção, extremamente simples e altamente eficiente. Essa definição é ótima pois sintetiza bem o que ele é. Primeiro ele é um processo, podemos entender processo como um conjunto de passos que cooperam para um objetivo definido, segundo, ele é adaptativo, quer dizer que ele foi feito para se adaptar a qualquer realidade, qualquer tipo de produção.

28 A utilização de um sistema Kanban permite um controle detalhado de produção com informações sobre quando, quanto e o que produzir. O método Kanban foi inicialmente aplicado em empresas japonesas de fabricação em série e está estreitamente ligado ao conceito de just in time. Just in time (JIT) significa no momento certo. É um modelo japonês que procura eliminar estoques e agilizar a produção. Armazena-se o mínimo de matéria prima em estoque, apenas em quantidade que permita manter o processo produtivo no momento. O número de fornecedores também é reduzido para o modelo funcionar de forma eficiente.

29

30

31 TargetProcess LeanKit Kanban Kanban tools Free License: Free for Teams of 5 Users or less View Video Commercial : Free License: Free for 5 Users/1Board Commercial : Hansoft View Video Kanbanery Free License: Free for 2 Users and unlimited projects Commercial : View Video Free License: 1 Board, 2 Users, 1GB space Commercial : AgileZen Free License: Free for 1 Project Commercial : View Video JAM Circle Free License: Free Commercial : Free Download (

32