Pessoas Ou Processos

PESSOAS OU PROCESSOS?

Entenda o que a Toyota, os processos e as pessoas tem haver com o desenvolvimento de software

Quem sou eu?

Maurício LinharesBOT da lista de discussão do PBJUGDesenvolvedor da CodeVaderInstrutor da LinuxFiModerador do GUJ

Eu não posso ter pessoas E processos?

Se você valoriza as pessoas, os processos tornam-se menos importantes, eles tornam-se mais maleáveis, eles não pertencem aos chefes, mas as pessoas;

Eu não posso ter pessoas E processos?

Se você valoriza os processos, eles tornam-se mais importantes do que as pessoas que os executam (afinal, o processo já diz como as coisas devem ser), o trabalho das pessoas é apenas executar;

O que nós vemos no dia-a-dia?

Processos normalmente são mais importantes do que as pessoas

Mas em alguns lugares, as pessoas são mais importantes do que os processos

Onde?

Como tudo começou?

Japão, 1940;

Povo pobre, mercado pequeno;

Produção em massa era impossível, o mercado não seria capaz de absorver os produtos;

Como produzir carros em pequenas quantidades com o custo de carros produzidos em massa?

Elimine o desperdício!Essa foi a solução encontrada por Taiichi Ohno, pai do Toyota Production System, simples, não?

Simples, até ele dizer pra você o que é desperdício

Qualquer coisa que não gere valor para o cliente, é desperdício

Exemplos de desperdício segundo Ohno Estoque; Transporte; Movimento; Espera; Produzir algo antes da hora que ele é

necessário; Serviços extras; Defeitos;

Como funciona uma indústria de carros da velha guarda?

Vários departamentos diferentes produzem pilhas de produtos intermediários;

Estes produtos ficam estocados nas fábricas até que a linha de produção precise deles;

Como funciona uma indústria de carros da velha guarda?

Quando a linha de produção precisa de alguma coisa, vai ao estoque e pega os produtos que são necessários;

Após reunir as partes, eles começam a produção, se houver alguma falha em alguma das partes e ela só for descoberta agora, tudo o que está no estoque vai pro lixo;

E como a Toyota faz?

Só é produzido o que é necessário;

Não existem diversas equipes para se produzir um carro, apenas uma “célula” cuida de fazer todo o trabalho;

Se um defeito é encontrado, toda a linha de produção pára até que o defeito seja corrigido;

Onde entram as pessoas? Agora não é mais responsabilidade do

processo garantir que as coisas funcionem, é das pessoas, pois agora todos controlam a linha de produção e tem o dever de mandar parar tudo se houver algum problema;

Mas o que é que isso tem haver com sofware?

Você já teve que escrever “componentes” para uso futuro?

Já escreveu documentos que ninguém leu?

Já encontrou defeitos que impediam o uso de aplicações em produção?

Mas o que é que isso tem haver com software?

Já adicionou uma funcionalidade que ninguém havia pedido?

Já deixou o cliente esperando por uma ferramenta que nunca chega?

Toyota Production System – Lean Development

A prática do Lean Software development (e das metodologias ágeis no geral) tem como base os avanços da gestão industrial capitaneada pela Toyota e outras montadoras do Oriente;

Os 7 tipos de desperdícioIndústria Software

Estoque Trabalho feito “pela metade”

Processamento extra Processos extras

Superprodução Funcionalidades “extras”

Transporte Troca de tarefas

Movimento Movimento

Espera Espera

Defeitos Defeitos

Trabalho feito “pela metade” Sabe aquele seu framework “caseiro”,

ele mesmo;

Qualquer coisa que você faça que não vai ser utilizado imediatamente;

No dia que você realmente precisar, será que ele atende as necessidades?

Processos extras

Sabe aquele diagrama UML que ninguém olhou? Pois é, ficou obsoleto;

Já pensou em quem está lendo esses documentos que você anda fazendo? Traças letradas essas viu.

Cada folha de papel que você usa, é uma árvore a menos no mundo

Funcionalidades extras

“Olha, agora o menu aparece e desaparece!”

Cada linha de código a mais é uma linha de código que precisa ser testada, compilada e documentada;

Usuário + Opções = Problema

Troca de tarefas

“Olha, você tem 8 horas hoje, então são 16 bugs para corrigir, um a cada 30 minutos, agora começa que os primeiros 30 minutos já tão contando”;

Desenvolvimento de software é uma tarefa que se faz com o cérebro, quem trabalha com os dedos é digitador;

Uma pequena pausa para um clássico Peopleware, DeMarco e Lister;

Desenvolvedores só produzem de verdade quando eles entram no estado de “flow”;

Você só entra em “flow” após algum tempo de trabalho concentrado e initerrupto;

Espera

“Seguinte, já tá quase pronto, mas eu só posso colocar em produção depois que o financeiro liberar a nota e o gerente terminar a planilha de horas”;

Quanto o seu cliente perde de dinheiro a cada segundo sem utilizar a aplicação?

Movimento

“Ei, você sabe se os testes passaram?” “Náo, vai ali e pergunta pra equipe de

testes”

“O analista já tá com o documento de requisitos?”

“Não, o arquiteto ainda tá validando ele”

Movimento

“Como assim eu vou ter que ir pro Amazonas pra poder fazer uma visita ao cliente?”

“Será que essa p&%%# só atende pelo call center?”

Defeitos

“Errrrrr... Cê sabe aquela piada do gato que subiu no telhado?”

“Sei.” “Sabe o banco de dados?” “Fala.” “Ele subiu no telhado.”

Mapeando o fluxo de valor

Ou, como descobrir o quanto de dinheiro você está jogando no lixo antes de ir a falência.

A vida de uma latinha de refrigerante

Estatísticas

Tempo total: 319 dias;

Tempo executando alguma coisa de valor: 3 horas

Fluxo de valor em uma fábrica de software comum

Fluxo de valor no desenvolvimento ágil

Amplificando o aprendizado

Porque desenvolver software ainda é explicar ao computador como o mundo funciona

Feedback é tudo

Equipes ágeis trabalham em iterações curtas, recebendo feedback dos clientes o tempo todo e aprendendo com os especialistas do problema;

Quanto menos tempo você perder fazendo a coisa do jeito errado, melhor;

Iterações e o aprendizado contínuo O desenvolvimento, assim como o

aprendizado, funciona melhor em pequenas doses;

É bem mais fácil aprender um pouco, aplicar e aprender mais um pouco do que “aprender tudo” e só depois aplicar;

Se você dá passos curtos, a chance de cair é menor;

Decida o mais tarde possível

Por que tomar a decisão agora se ela só precisa ser tomada amanhã?

Decidir ou não decidir, eis a questão Quanto mais cedo você decide, menos

informações você tem;

Maiores são os problemas causados por um erro nos seus cálculos;

Mais engessada fica a estrutura da aplicação;

Minimizando ações irreversíveis

As fontes de alimentação das impressoras da HP são específicas para cada país;

As impressoras são todas iguais;

Então impressoras não precisam ter uma fonte nelas;

Ao deixar a decisão para mais tarde... Você pode pensar e aplicar diversas

opções;

Pode aprender mais sobre o problema em questão;

Você tem mais tempo para mudar o caminho a ser seguido;

Entregue o mais rápido possível

Software com a metade das funcionalidades hoje é melhor do que software com metade das funcionalidades erradas amanhã

Pull systemsKanban e os estoques infinitos sem estoque

Pull systems e desenvolvimento de software

O cliente define as funcionalidades e as prioridades para o ciclo atual;

A equipe se reúne, diariamente, comenta o que já foi feito, o que está por fazer e os problemas encontrados;

Ao fim da iteração, avalia-se se tudo foi realmente feito;

Gerencia pela visibilidade

O preço do atraso Quando o cliente receber o sistema, quanto

ele vai deixar de gastar?

Ele poderia ter recebido antes? Quanto seria a economia de ter começado a usar antes?

Aprenda a fazer escolhas, ou lança, ou implementa todas as funcionalidades ou aumenta o preço, não dá pra ter tudo ao mesmo tempo;

O manifesto ágil

Individuals and interactions over processes and tools

Working software over comprehensive documentation 

Customer collaboration over contract negotiation 

Responding to change over following a plan 

Qual a importância de tudo isso? Nós somos novos demais, temos que

aprender com quem já administra a anos e já desenvolveu práticas melhores do que as nossas;

Não somos tão diferentes ao ponto de não podermos nos aproveitar do que eles já descobriram;

Questões?

Referências

DeMarco, Tom; Lister, Tim. Peopleware: Productive Projects and Teams. Dorset House Publishing.

Poppendieck, Tom & Mary. Lean Software Development: An Agile Toolkit. Addison-Wesley.

DeMarco, Tom. Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency. Broadway.