Um pouco de Agile

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

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.


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.


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


E...
A bela ﬁlosoﬁa 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
Uniﬁed Processes, o mais famoso é conhecido
como RUP, Rational Uniﬁed 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íﬁcos 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 Baleia
O 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 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.”


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


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
/


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, conﬁe
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 reﬂexã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 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 proﬁssional.

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...
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 é Simpliﬁcando


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

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í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 signiﬁca 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 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.


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 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 ﬁnal do dia algumas pizzas foram realmente vendidas,
outras permaneceram um período maior em estoque ﬁcando
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 ﬁnal 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 ﬁnal subtraindo do lucro o desperdício, resultamos numa
conta positiva =) #win


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.


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


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

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.


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.


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 ﬁnal 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
@edercosta
mesmo encaminhe para o e-mail eder@zigotto.com.br


Um pouco de Agile

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Um pouco de Agile

Mais de Zigotto Tecnologia

Um pouco de Agile