Um pouco de Agile

Agile,para o seu dia ser mais feliz =)

Parte 01 de 02Lab @Zigotto23-12-2010

por @edercosta

quinta-feira, 23 de dezembro de 2010

O inícioTrabalhar com tecnologia ainda é desbravar um caminho obscuro, com a necessidade humana de criar e organizar processos, os primeiros envolvidos na área acreditaram na adaptação de regras e conceitos utilizados na industria e em outras áreas, trazendo toda esta cultura a realidade tecnológica, o resultado não foi animador:

Em pouco mais de 10 anos, gerou-se uma cultura de atrasos, stress e muitos clientes insatisfeitos.


Um pouco da evoluçãoWaterfall:

Inspirado nas fases de processos da construção civil, o Waterfall é um processo de gerenciamento de software documentado pela primeira vez em 1970 no paper de Winston W. Royce.


O quê o Waterfall sugere...como funcionaSystem

Requirements

Software Requirements

Analysis

Program Design

Coding

Testing

Operations

A intenção é que, terminada uma fase, o projeto siga para a próxima sem jamais retornar um trabalho já feito, assim como a água que corre numa cascata nunca volta para cima.


E...A bela filosofia resulta em:

Pilhas de papéis,Reuniões infundadas,Informações incorretas,Suposições,Distância do cliente,Atrasos,Apresentação do produto incompatível com a necessidade do cliente...

=(


A história continua...Muitas metodologias foram criadas para resolver os males criados pelo mau uso do Waterfall, dentre vários frameworks do mesmo princípio Unified Processes, o mais famoso é conhecido como RUP, Rational Unified Process

Agora vai =)


RUP na cabeça negão!Em 1999 a Rational foi severa em suas críticas, contra o Waterffal, deixando claro que os documentos sugeridos não eram mais necessários, e demonstrando que não existe uma solução com moldes específicos para gerenciamento de sistemas.

Maleável o RUP traz diversos moldes que podem ser implantados em seu projeto conforme sua necessidade.

Com foco maior nas decisões de risco, iterações curtas, somado ao feedback do cliente, o RUP é capaz de estimar com maior precisão a conclusão de um projeto.


Diagrama de BaleiaO diagrama abaixo mostra as atividades da equipe durante o desenvolvimento de um projeto.


E...Com a forma que o RUP se popularizou temos:

Pilhas de papéis,Reuniões infundadas,Informações incorretas,Suposições,Distância do cliente,Atrasos,Apresentação do produto incompatível com a necessidade do cliente...

Já vi isso antes! =(


Só bola fora?Não é bem assim...

A Rational foi excelente em resolver os problemas gerados pelo Waterfall, mas ainda é incompatível com a necessidade do mercado, e também dos envolvidos com o desenvolvimento.

Tem com certeza muitos méritos na evolução do que conhecemos hoje, e pensando em evolução os métodos ágeis despertam alguns pontos interessantes para todos os envolvidos no desenvolvimento de um sistema.


O lab não era de Agilidade?OK!

Em resposta aos problemas encontrados no mundo inteiro, diversas metodologias foram criadas e comumente chamadas de “lightweight processes”, em protesto aos seus predecessores e tantas exigências.

Vendo similaridades entre estas novas metodologias, organizou-se um encontro com alguns idealizadores, deste encontro, quatro valores comuns foram destacados, assim surgiu o Manifesto Ágil.


Manifesto Ágil

“Estamos descobrindo formas melhores de desenvolver software ao fazer e ajudar outros a fazerem software.Por esse trabalho, passamos a valorizar:

Indivíduos e Interações sobre processos e ferramentasSoftware Funcionando sobre documentação compreensivaColaboração do Cliente sobre negociação de contratoResponder a Mudanças sobre seguir um planejamento

Isso quer dizer que, embora haja valor nos itens à direita, valorizamos mais os itens à esquerda.”


As coisas foram encaixandoEm poucos momentos, ou em praticamente nenhum momento até o Manifesto Ágil, pessoas se referiam a pessoas como sendo pessoas.

As linhas de produção estavam a todo momento sendo montadas usando de braços humanos sem analisar seu comportamento e necessidade, passando por cima de sua essência.

“Trabalhamos com máquinas, não somos máquinas.”


Manifesto Ágil no PopularIndivíduos e Interações sobre processos e ferramentas

// O que importa são as pessoas

Software Funcionando sobre documentação compreensiva

// O que é feito com documentação?

Colaboração do Cliente sobre negociação de contrato

// Participação obrigatória

Responder a Mudanças sobre seguir um planejamento

// Flexibilidade


Princípios ágeis:- Priorizar a entrega frequente de software de valor;- Receba bem mudanças de requisitos, mesmo em desenvolvimento. Ser ágil é enxergar na mudança vantagem competitiva ao cliente;- Pessoas de negócios e desenvolvedores devem trabalhar juntos;- Pessoas motivadas, proporcione um bom ambiente e suporte, confie que eles farão o trabalho;- Comunique-se no “cara-a-cara”;- Software funcionando é a primeira medida de sucesso;- Fluxo de desenvolvimento;- Atenção continua, excelência técnica e bom design;- Simplicidade;- As melhores arquiteturas, requisitos e design emergem de timesauto-organizados;- Reuniões periódicas para reflexão do trabalho e melhoria do mesmo.


Belas palavras...Com base nas declarações anteriores, um projeto de sucesso seria:

- Atende às necessidades do cliente;

- Mantém a equipe feliz: sem hora extra, sem tempo inativo;

- Código bem feito: permite manter o ritmo, facilita a manutenção;

- Lucro: tanto para o cliente, quanto para o time.


Vantagens da AgilidadeFeedback rápido: tanto para clientes, quanto para equipe e o relacionamento entre essas partes, o feedback constante e rápido permite tomar decisões e corrigir problemas antes que eles se tornem crônicos.

Motivação da equipe: o contato direto com o cliente torna mais fácil entender o valor do trabalho do time para o cliente. Não ter o sistema todo pré-modelado, poder tomar decisões, também valoriza o desenvolvedor.

Sem corpo mole: as práticas de engenharia de software incentivadas pelas metodologias também são importantíssimas. Quanto mais comunicação dentro do time, mais aprendizado. Quanto mais aprendem, melhor a qualidade do profissional.

Ver problema mais cedo: práticas como pareamento e reuniões diárias explicitam problemas na equipe mais cedo, possibilitando resolvê-los mais cedo.


Estão falando que...Não há documentação?Mentira. A documentação é feita a medida que é necessária. Não há regras em Agile contra documentação, mas sim contra trabalho desnecessário e contra planejar todo projeto no início.

Preciso de um time experiente?Não. Praticas ágeis nivelam seu time para cima. O crescimento pessoal é fomentado pela agilidade.

Agile é mais difícil?Verdade, em partes. Trabalhar de forma ágil é menos burocrático, para que de certo exige-se disciplina. Disciplina em seguir o processo e em se auto gerenciar. Os ganhos pessoais são visíveis.


Mais da essência...LeanO sistema Lean de produção foi desenvolvido pela Toyota e tem um princípio claro e simples: reduzir desperdício.

Em 2009, a Toyota vendeu mais carros nos EUA do que a nacional e tradicional Ford, tornando-se a segunda maior vendedora de carros naquele país. Como uma marca japonesa, ultrapassou a gigante Ford que popularizou o automóvel e revolucionou o sistema de produção?

A resposta é Simplificando


Segue...Lean tem seu foco em minimizar desperdícios, sejam eles no processo, no desenvolvimento ou no produto final.

Considere como desperdício tudo aquilo que não traz valor para o cliente, e como ganho tudo aquilo que agrega valor.

Com foco no desenvolvimento de software, podemos apontar o desperdício como sendo tudo aquilo que não é feito para o cliente, podendo ser: documentação excessiva, desenvolvedores parados por falta de informação, códigos e funcionalidades não requisitadas.

Como ganho tudo que traz valor e reduz o trabalho: testes, código de qualidade, entregas frequentes...


DesperdíciosLean divide desperdício em três categorias de igual importância:

Mura: desperdício por tentar prever possíveis necessidades futuras. Evitar Mura significa reduzir ao máximo o inventário, isto é, as partes paradas no meio do processo, aquele trabalho que começa e não termina...

Muri: desperdícios que podem ser evitados por planejamento. Nessa categoria enquadra-se o excesso de burocracia ou de complexidade num processo de produção.

Muda: desperdícios do dia a dia, criados por uma cultura anterior de trabalho.


Push vs. Pull SystemsNo sistema Ford de produção, cada estação da linha de montagem trabalha enquanto houver matéria prima para tal. A quantidade do que será produzido é regulada com base a previsões feitas sobre o mercado em um determinado período, e não há ligação entre os pedidos reais e a linha de produção.

Dois desperdícios são criados:

1- as muitas peças produzidas, esperando para serem usadas em outras estações, sem sequer saber se há demanda pelo produto. Chamamos estas peças de inventário;

2- o tempo livre dos trabalhadores superespecializados que trabalham nas funções terminadas mais cedo.


Push vs. Pull Systems...Esses são exemplos de Mura. Uma solução possível para tais desperdícios é trabalhar com sistema pull em vez dos tradicionais push, como descrito.

O sistema pull, trabalha com o mínimo possível de inventário, em vez do planejamento pouco maleável baseado em previsões do mercado utilizado pelo sistema push, no sistema pull a produção acontece de acordo com a demanda.


Push vs. Pull no popularVamos aplicar os dois modelos Pull e Push, em um ambiente mais simples.

Imagine um dia de produção na Pizzaria Leggero , usando do sistema Push. O proprietário faria uma previsão de quantas pizzas iria produzir durante uma semana, compraria todo material e iniciaria a produção dos sabores mais pedidos, em poucas horas teríamos um estoque de pizzas de Mussarela, Calabresa, Portuguesa...Ao final do dia algumas pizzas foram realmente vendidas, outras permaneceram um período maior em estoque ficando impróprias para o consumo, o estoque necessita ser usado para não perder validade.Subtraindo do Lucro o Desperdício, o proprietário obteve prejuízo =( #fail


Push vs. Pull no popular...Por estes motivos Pizzarias usam da metodologia Pull, onde existe um estoque mínimo para manter a pizzaria durante um dia de vendas, e todo conteúdo produzido é feito sob demanda.Assim ao final do dia, foram produzidas somente os sabores demandados.O controle de estoque é feito em tempo real, repondo somente o que foi usado e é necessário para mais um dia de vendas.

Ao final subtraindo do lucro o desperdício, resultamos numa conta positiva =) #win


Kanban, quadro de olharEntendendo uma linha de produção como uma sequência de passos para produzir algo, a representação obvia para o processo é o já consagrado Kanban.

Nele, é facilmente diferenciado o que existe a fazer, do que está sendo feito.


Exemplo de KanbanEm sistemas push, cada estação de trabalho faz sua parte, sem considerar o que já foi feito ou ainda vai ser feito, com o Kanban é fácil perceber o acúmulo de trabalho em algumas fases, e o tempo ocioso de outras.

A fazer Inventário 1 Inventário 2 Inventário 3 Produto

12

3

4

5

6

7

8

9

10

11


Exemplo de KanbanKanban representando o sistema pull de produção, há um limite de inventário claramente determinado. Dessa forma, a produção acontece somente com a demanda da mesma.

A fazer Inventário 1 Inventário 2 Inventário 3 Produto

12

3

46

7

82 2 2

59

10

11


Systems ThinkingProcessos, metodologias, frameworks são criados para facilitar o desenvolvimento.

Em muitos casos, grandes processos consagrados acabam atrapalhando uma equipe e não ajudando como deveria.

Pensar sempre no sistema, Systems Thinking, é pensar e repensar durante todo o andamento do projeto no que poderia ser melhorado no próprio processo de desenvolvimento e nas interações entre as pessoas envolvidas.


Work CellsNão é possível encontrar possíveis melhorias no processo se cada envolvido está focado exclusivamente em uma tarefa, na qual é especialista.Por isso, Lean, entende que as pessoas envolvidas em um projeto não podem ser superespecialistas, isto é, não podem se limitar a conhecimento apenas de sua etapa. Deveriam conhecer todas elas e saber executar pelo menos algumas delas.Cada membro da equipe é, desta forma, uma Work Cell: uma pessoa capaz de trabalhar no projeto como um todo, em algumas ou todas as suas partes. O conhecimento mais amplo sobre o projeto é incentivado, melhora-se as críticas e com isso é possível melhorar ainda mais o processo.


KaizenNa década de 1970, Frederich Brooks publicou um artigo chamado “No Silver Bullet”, apesar de tanto tempo o artigo ainda é verdadeiro, juntamente com “The Mythical Man-Month”, leitura obrigatória para todos aqueles na área de Engenharia e Gerenciameto de Software.

Em Lean, também acredita-se que não exista em processos uma bala de prata, capaz de resolver todos os problemas. Desta forma, é preciso que cada equipe adapte a metodologia e ferramenta à sua necessidade, a todo momento.

Kaizen, palavra japonesa para melhoria. Melhorias no processo, na forma de produção e no produto final são parte do dia a dia de quem trabalha com Lean.


Obrigado!O Labs Zigotto tem o intuito de compartilhar informações entre o time de desenvolvimento da Zigotto e pessoas próximas, é aberto a todos que queiram participar ou contribuir.

Todo conteúdo destes slides são baseados no treinamento PM-83 da escola Caelum. (Indico o mesmo para interessados) e experiências na empresa Zigotto.

Se encontrou algo que não concorda ou correções para o mesmo encaminhe para o e-mail [email protected]

@edercosta


mailto:[email protected]

mailto:[email protected]

Technology

Um pouco de Agile