O documento descreve a evolução de metodologias para desenvolvimento de software, começando pelo modelo cascata (waterfall) e suas limitações, e depois introduzindo modelos como RUP e métodos ágeis. O manifesto ágil valoriza indivíduos, software funcionando, colaboração com cliente e resposta à mudanças. Princípios como entregas frequentes, feedback rápido e motivação da equipe são destacados como vantagens da abordagem ágil.
1. Agile,
para o seu dia ser mais feliz =)
Parte 01 de 02
Lab @Zigotto
23-12-2010
por @edercosta
quinta-feira, 23 de dezembro de 2010
2. O início
Trabalhar 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.
quinta-feira, 23 de dezembro de 2010
3. Um pouco da evolução
Waterfall:
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.
quinta-feira, 23 de dezembro de 2010
4. O quê o Waterfall sugere
...como funciona
System A intenção é que, terminada uma fase, o
Requirements
projeto siga para a próxima sem jamais
Software retornar um trabalho já feito, assim como a
Requirements água que corre numa cascata nunca volta
para cima.
Analysis
Program
Design
Coding
Testing
Operations
quinta-feira, 23 de dezembro de 2010
5. 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...
=(
quinta-feira, 23 de dezembro de 2010
6. 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 =)
quinta-feira, 23 de dezembro de 2010
7. 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.
quinta-feira, 23 de dezembro de 2010
8. Diagrama de Baleia
O diagrama abaixo mostra as atividades da equipe
durante o desenvolvimento de um projeto.
quinta-feira, 23 de dezembro de 2010
9. 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! =(
quinta-feira, 23 de dezembro de 2010
10. 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.
quinta-feira, 23 de dezembro de 2010
11. 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.
quinta-feira, 23 de dezembro de 2010
12. 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 ferramentas
Software Funcionando sobre documentação compreensiva
Colaboração do Cliente sobre negociação de contrato
Responder a Mudanças sobre seguir um planejamento
Isso quer dizer que, embora haja valor nos itens à
direita, valorizamos mais os itens à esquerda.”
quinta-feira, 23 de dezembro de 2010
13. As coisas foram encaixando
Em 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.”
quinta-feira, 23 de dezembro de 2010
14. Manifesto Ágil no Popular
Indiví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
/
quinta-feira, 23 de dezembro de 2010
15. 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 times
auto-organizados;
- Reuniões periódicas para reflexão do trabalho e melhoria do mesmo.
quinta-feira, 23 de dezembro de 2010
16. 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.
quinta-feira, 23 de dezembro de 2010
17. Vantagens da Agilidade
Feedback 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.
quinta-feira, 23 de dezembro de 2010
18. 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.
quinta-feira, 23 de dezembro de 2010
19. Mais da essência...
Lean
O 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
quinta-feira, 23 de dezembro de 2010
20. 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...
quinta-feira, 23 de dezembro de 2010
21. Desperdícios
Lean 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.
quinta-feira, 23 de dezembro de 2010
22. Push vs. Pull Systems
No 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.
quinta-feira, 23 de dezembro de 2010
23. 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.
quinta-feira, 23 de dezembro de 2010
24. Push vs. Pull no popular
Vamos 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
quinta-feira, 23 de dezembro de 2010
25. 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
quinta-feira, 23 de dezembro de 2010
26. Kanban, quadro de olhar
Entendendo 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.
quinta-feira, 23 de dezembro de 2010
27. Exemplo de Kanban
Em 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
2 6 1
9
5 3
10
4 7
11
8
quinta-feira, 23 de dezembro de 2010
28. Exemplo de Kanban
Kanban 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
2 2 2
8 6 4 2 1
9 7 5 3
10
11
quinta-feira, 23 de dezembro de 2010
29. Systems Thinking
Processos, 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.
quinta-feira, 23 de dezembro de 2010
30. Work Cells
Nã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.
quinta-feira, 23 de dezembro de 2010
31. Kaizen
Na 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.
quinta-feira, 23 de dezembro de 2010
32. 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
@edercosta
mesmo encaminhe para o e-mail eder@zigotto.com.br
quinta-feira, 23 de dezembro de 2010