Quando você é Ágil,

Você se torna Lean

Introdução
A manufatura Lean (ou simplesmente “Lean”) refere-se à
filosofia de manufatura estabelecida no Sistema Toyota de
Produção. Ao aplicar essa filosofia sistematicamente à
manufatura de carros, a Toyota tornou-se a líder global com
uma marca que é praticamente um sinônimo de qualidade.
O Lean integra cada passo da cadeia de fornecimento em
um fluxo de valor holístico. A redução de desperdício, um
princípio central da filosofia Lean, é o ato de eliminar o
desperdício de produção que ocorre no fluxo de valor,
preservando ou aumentando o valor do produto final para o
cliente.
Taiichi Ohno descreveu inicialmente os sete desperdícios
sob a ótica Lean em seu livro Toyota Production System:
Beyond Large-Scale Production (Sistema Toyota de
Produção: Além da Produção em Larga Escala).1 Embora
seja diferente da manufatura em importantes aspectos, o
desenvolvimento de software possui desperdícios análogos.
Uma vez que você começa a procurá-los, são
surpreendentemente fáceis de encontrar.
Nesse white paper vamos explorar como o conceito de
redução de desperdício Lean migrou da sua origem, na
manufatura, para a indústria de desenvolvimento de
software através do uso do Ágil. Primeiramente vamos
descrever, de forma breve, os sete diferentes tipos de
desperdício na manufatura e discutir suas analogias no
desenvolvimento de software. Em seguida iremos introduzir
princípios que as filosofias Lean e Ágil compartilham e
discutir algumas das suas implicações. Por fim, vamos
discutir as práticas Ágeis que incorporam esses princípios e
demonstrar como eles reduzem o desperdício no
desenvolvimento de software.
LEIA AGORA
____________________________

Os Sete Desperdícios Lean

1. Estoque
Estoque inclui todas as partes e materiais que foram
comprados e estão à espera de utilização. Isso também
inclui o trabalho em andamento (Work- In-Progress – WIP).
WIP é tudo que está em andamento e que, portanto, não
está pronto para envio ou venda. Estoque e WIP geram
desperdício porque, por definição, imobilizam recursos que
não estão aptos a gerar retorno. Adicionalmente, quanto
maior o estoque, maior o risco de obsolescência, perda e
write-off. Quanto maior o tempo que o modelo do último ano
fica em estoque, maior a probabilidade dele nunca ser
vendido. Da mesma forma, quanto maior o volume de
trabalho em andamento, maior é o risco de que alguma
parte desse trabalho nunca resulte em um produto acabado
e em uma venda.

Estoque em Desenvolvimento de Software

No trabalho do conhecimento, como o desenvolvimento de
software, podemos pensar no inventário como sendo
mantido na documentação e no software não
implementado. Trabalho em andamento em software (WIP)
é toda a atividade (e portanto despesa) subsequente à
aprovação do business case, mas que precede à entrega
em produção. Isto inclui documentos de requisitos, planos
de projeto, especificações funcionais e de projeto, código
fonte, planos de teste, testes e o tempo gasto para criar
esses artefatos. Se um projeto tem a duração de um ano ou
mais, o WIP continua a crescer durante WIP projeto de
software em modelo de desenvolvimento cascata todo o
período anterior ao uso em produção. O WIP também
equivale à acumulação de risco de write-off para
investimentos em software porque se o projeto terminar
prematuramente ou nunca for lançado, nenhum valor de
negócio será gerado e o investimento deste trabalho será
perdido.
2. Movimentação
Movimentação é o deslocamento de pessoas ou
equipamentos além do essencial que contribua com valor.
Parafraseando as palavras de Shigeo Shingo, co-
desenvolvedor do Sistema Toyota de Produção (TPS) de
onde surgiu a manufatura Lean, é apenas o último giro de
um parafuso que o aperta – o resto é apenas movimento.2
Movimentação em Desenvolvimento de Software
Movimentação em membros de equipes aparece através de
tempo em viagens, preparação para reuniões, troca de
tarefas entre projetos e interrupções no trabalho. Uma
interrupção de 10 segundos no trabalho pode resultar num
tempo de 5 minutos para que um desenvolvedor possa
retomar seu foco. No trabalho do conhecimento, cada vez
que você troca de tarefa, você interrompe o fluxo dos seus
pensamentos e desperdiça poder do cérebro, perdendo o
investimento em WIP.
3. Espera
Espera é a demora entre passos em produção. Se um
pedido chega por e-mail e fica parado na caixa de e-mail, o
tempo gasto na caixa de e-mail é o desperdício de espera.
Se um item é montado, a demora antes dele ser
empacotado é o desperdício de espera.
Espera no Desenvolvimento de Software
Exemplos incluem espera por um milestone, aprovações de
requisição de mudança e sign-offs, espera por
esclarecimentos e refinamentos de sponsors e analistas,
espera por finalização de builds e testes, espera pela sua
vez em reuniões e conference calls, espera por cronograma
de deployment e revisões de código e arquitetura , etc.
Qualquer tempo gasto além do necessário
para executar passos que adicionam valor é uma forma de
espera. A espera é fácil de se encontrar quando você
começa a procurar por ela. Até mesmo no que inicialmente
parece ser a mais eficiente das operações há muitas
oportunidades para melhorias futuras.
4. Transporte
O desperdício de transporte é o movimento de materiais e
mercadorias que não são realmente necessários para
realizar o processamento. Também inclui avarias aos
materiais e mercadorias resultantes do transporte.
Transporte em Desenvolvimento de Software
O transporte físico de materiais ou mercadorias prontas é
de pouca preocupação, visto que software é informação
eletrônica armazenada e acessada. No entanto, há um
desperdício análogo no entendimento e repasse dos
requisitos do cliente através de fases subsequentes do
projeto como especificações funcionais, diagramas UML,
código fonte e testes. Perda de informação ou introdução
de ruído também pode ser prejudicial, assim como
mercadorias prontas são algumas vezes danificadas
através do transporte.
5. Superprodução
A superprodução é a produção acima da demanda. Por
exemplo, unidades vendáveis aguardando por compradores
em armazéns são desperdício de superprodução.
Superprodução em Desenvolvimento de Software
Como o modelo de uso de software é de uma unidade (i.e.,
um release) compartilhada por muitos usuários (realidade
amplificada em ambientes SaaS) e o custo físico material
da unidade de software é mínimo, a superprodução não é
expressa como a produção de unidades a mais em relação
à demanda. Ao invés disso, superprodução em
desenvolvimento de software ocorre quando construímos
features que serão (1) nunca ou raramente utilizadas ou (2)
entregue prematuramente. Na conferência XP de 2002, Jim
Johnson do Standish Group compartilhou o resultado da
pesquisa sobre features e funções redundantes (veja a
referência).3
6. Superprocessamento
O superprocessamento é o processamento feito em
excesso. Polir uma superfície um minuto a mais do que o
necessário para o próximo passo do processamento é um
minuto de desperdício de processamento.
Superprocessamento consome não apenas tempo e
recursos sem adicionar valor; ele pode danificar ou fazer
com que o produto final tenha menor valor e encurtar a vida
útil das ferramentas de processamento. O desperdício da
espera frequentemente leva ao desperdício do
superprocessamento. Preencher o seu tempo estando
“ocupado” pode reduzir a angústia da espera e favorecer a
ilusão de que pelo menos alguma coisa “produtiva” está
sendo feita, mas se não está adicionando valor aos olhos
do cliente, então está simplesmente tornando as coisas
piores.
Superprocessamento no Desenvolvimento de
Software
Superprocessamento ou processamento redundante em
software inclui reuniões e conference calls de pouco ou
nenhum valor, aprovações duplicadas, relatórios e
especificações redundantes, código rebuscado e
especificações “folheadas à ouro”, como também revisões
de design de projeto e código que não resultam em
melhorias técnicas. Detalhamento excessivo de Estruturas
Analíticas de Projetos e excesso de precisão em
estimativas também são formas de desperdício de
processamento.
7. Defeitos
O desperdício de defeitos se refere ao custo de procurar e
corrigir defeitos, como também ao impacto causado pelos
defeitos no fluxo de processamento.
Defeitos em Desenvolvimento de Software
Defeitos ou erros e o esforço e custo de testes de software
são bem conhecidos. No entanto, atividades e processos de
teste e inspeção que não encontram defeitos também são
considerados desperdício de defeito em desenvolvimento
de software. Outros exemplos são features que são
implementadas e nunca utilizadas, especificações
imprecisas, defeitos em produção, e experiência de usuário
insatisfatória.
Preencher o seu tempo estando “ocupado” pode
reduzir a angústia da espera e favorecer a ilusão de
que pelo menos alguma coisa “produtiva” está sendo
feita, mas se não está adicionando valor aos olhos do
 cliente, então está simplesmente tornando as coisas
piores.
Princípios e Práticas: Metodologia ou
Mindset?
As metodologias são tipicamente estruturadas como um
conjunto de práticas definidas em termos de regras e
procedimentos. Para alguém trabalhando com uma
metodologia, o conhecimento de quais princípios estão por
detrás das práticas é menos importante do que seguir as
regras e aprender os procedimentos. Podemos pensar o
encapsulamento dos princípios em um procedimento como
um “benefício” de uma metodologia: o profissional pode
aplicar o que os experts determinaram previamente como
melhores práticas, sem ter que pensar muito. Com o Ágil e
Lean a história é diferente. É esperado que os profissionais
compreendam os princípios, além de aprender as práticas.
Quando profissionais concordam em adotar práticas Ágeis,
eles também aceitam a responsabilidade de alcançar os
objetivos dos princípios corporificados nas práticas. Esse é
o significado de declarações Ágeis como: “indivíduos mais
que processos”, “colaboração com o cliente mais que
negociação de contratos”, e “responder à mudança mais
que seguir um plano”.4 Processo é necessário, mas não
suficiente para garantir resultados de alto valor. Assim como
um pelotão em campo de guerra, o time Ágil enfrenta um
ambiente de mudança rápida e mais do que procurar pela
resposta correta num manual de campo, ele precisa tomar
decisões prudentes em como melhor aplicar os princípios
orientadores. Se os resultados não são ideais, é
responsabilidade do profissional fazer os ajustes
necessários (frequentemente no seu prórpio
comportamento) para alcançar os resultados desejados.
Quando profissionais adotam práticas Ágeis, espera-se que
eles pensem mais, não menos. Podemos resumir essa
distinção afirmando que Lean e Ágil são orientados a
princípios e não orientados a regras. Por essa razão, muitos
profissionais Ágeis sentem-se mais confortáveis referindo-
se à sua comunidade de prática como um mindset, mais do
que uma metodologia.
Agora vamos introduzir três princípios que Ágil e Lean têm
em comum. Embora haja muitos outros princípios que
poderíamos discutir, esses princípios em particular deixam
evidente o quanto Ágil e Lean compartilham em termos de
mindset e filosofia. Após cada princípio forneceremos
exemplos de práticas Ágeis que corporificam o princípio e
demonstraremos como eles reduzem o desperdício em
desenvolvimento de software.
Quando profissionais adotam práticas Ágeis, espera-
se que eles pensem mais, não menos
1. Entregue o mais cedo possível
Em essência, a produção deve ser organizada de maneira
que valores tangíveis estejam nas mãos do cliente final o
quanto antes. Quanto mais cedo você entrega o produto
final, mais cedo você recebe um retorno tangível. O poder
desse princípio aumenta à medida que a incerteza no
ambiente de operação aumenta. Sob condições incertas,
aprender enquanto se faz é uma necessidade. Quanto mais
curto o ciclo de entrega, mais rápido você aprende a partir
do feedback do mercado. Quanto maior a frequência de
entrega, mais oportunidades você tem de aprender a fazer
melhor. Afinal de contas, é melhor falhar mais cedo do que
tarde e, quando você falha, é melhor aprender a partir da
sua falha.
Corolário: Nunca adie uma correção
Barry Boehm demonstrou há muitos anos atrás que quanto
mais tarde no processo você encontra um defeito, mais alto
é o custo da correção. 5 A tônica para este problema –
tomar medidas afim de eliminar as causas dos defeitos e
corrigí-los o quanto antes – é crucial em Ágil e Lean. Como
veremos, embora há trabalho que você deseja adiar e até
mesmo evitar fazê-lo inteiramente, isso nunca deveria
acontecer à custa de adiar correções que você sabe que
precisam ser feitas e você não deveria, conscientemente,
dar um passo que pode aumentar uma futura incidência de
defeitos. Defeitos custam mais para serem corrigidos
quanto mais eles se deterioram, visto que muito foi
investido e agora precisa ser retrabalhado ou removido.
Somando-se a isso, quanto mais o tempo passa, mais
stakeholders serão afetados. Além disso, defeitos que se
acumularam no decorrer do tempo viram “bolas de neve”
que multiplicam o dano que causam.
Práticas Ágeis
Entrega antecipada e contínua
A entrega antecipada e contínua é definida como o
encurtamento do tempo da entrega do primeiro release e
redução do tempo entre releases. Você obtém a entrega da
forma mais antecipada possível delimitando o primeiro
release ao Minimum Markeatable Features (MMF).
A entrega antecipada e contínua tem o maior impacto na
redução do WIP, a forma mais significativa de desperdício
de estoque. Limitando a sua entrega de acordo com MMF,
você também reduz o desperdício de superprodução. Como
existirão inúmeras oportunidades de entregar novas
features em entregas subsequentes, a pressão de fazer
deploy de features de valor duvidoso numa entrega em
abordagem big bang diminui. Como encurtar o ciclo de
entrega automaticamente diminui o WIP, a probabilidade de
você incorrer em desperdício de espera ou superprodução
diminui de maneira correspondente. Entregar
continuamente significa mais oportunidades de obter o
feedback do usuário final, o que reduz o desperdício de
defeito. O desperdício de defeito também é reduzido pelo
encurtamento do tempo entre a origem do defeito, a
descoberta do defeito, e a sua correção.
Desenvolvimento Iterativo e a Definição de Pronto
Se a entrega antecipada e contínua é o melhor caminho
para alcançar valor, o desenvolvimento iterativo é o meio
pelo qual alcançamos isso. Desenvolvimento iterativo
significa completar todas as fases do desenvolvimento para
uma fatia do total de requisitos dentro de um espaço de
tempo bem curto. A ênfase aqui é na palavra “completar”.
Times ágeis preocupam-se tanto com isso que criam e
reforçam o que é chamado de definition of done (DoD) –
definição de pronto. No mínimo, o DoD é uma lista de tudo
que precisa ser finalizado para a entrega de código
deployable. Isso engloba todo a extensão das tarefas de
desenvolvimento, da definição de requisitos ao teste de
aceitação do usuário. Isso também significa que a nova
fatia de trabalho é completamente integrada com toda o
trabalho que a antecede, o que minimamente engloba
testes de regressão e integração de sistemas, aplicados de
forma abrangente. À medida que o time Ágil amadurece, ele
estende o DoD para, progressivamente, encurtar a jornada
da “última milha” para produção. Alguns times Ágeis
(especialmente aqueles que fazem deploy na web ou
ambientes cloud) têm estendido a lógica do DoD a partir da
implementação de “entrega contínua” e deploy de código
em produção depois de cada iteração. Em alguns casos,
código pode ser enviado para produção uma ou mais vezes
por dia.
Ao completar tudo o que precisa ser feito para uma
pequena fatia do trabalho, o WIP é drasticamente reduzido.
O único trabalho que não é finalizado durante a iteração é a
migração de código do ambiente de staging para o
ambiente de produção. Ao nos concentrarmos em fazer o
trabalho que podemos fazer dentro da iteração, evitamos
esperar por insumos e informações que não estão
imediatamente disponíveis para a equipe de
desenvolvimento.
Quando usamos Scrum como o nosso framework de
gerenciamento de projeto, a espera é reduzida ainda mais
através dos papéis de duas pessoas: O Scrum Master e o
Product Owner. O Scrum Master dedica-se a remover
obstáculos que causam atraso para produção. Enquanto
isso, o Product Owner dedica-se a fornecer respostas sobre
os requisitos em tempo hábil. Adicionalmente, a reunião
diária do Scrum (standup) fornece uma oportunidade para
que todos os membros do time atualizem a equipe em
relação ao seu progresso, o que torna os obstáculos
imediatamente visíveis.
Como o escopo da iteração é fixado num conjunto pequeno
de requisitos, o risco de superprodução é restringido.
Adicionalmente, como o DoD reforça um alto padrão de
completude, incluindo a finalização de todos os testes
dentro da iteração, o risco de defeitos é dramaticamente
reduzido. Como muito trabalho precisa ser finalizado num
período muito curto de tempo, o time pode mover-se
rapidamente para um modo de triagem afim de descartar
qualquer tarefa que não seja crítica para que o trabalho seja
finalizado. Consequentemente há pouca tolerância para
superprocessamento.

Teste Unitário Automatizado e Alta Cobertura de Teste

O uso de frameworks de testes automatizados de terceiros
permite que times implementem testes unitários no menor
incremento de código (ex., single method, procedure ou
validação). A capacidade de automatizar facilmente os
testes enquanto o código está sendo escrito amplifica a
viabilidade em alcançar o compromisso de testar de forma
abrangente todo o código fonte dentro da iteração.
Outros benefícios da automação de testes:
• Menor espera para o resultado dos testes;
 • Não há necessidade de adiar o teste para o futuro, o
que reduz o WIP;
• Tempo de espera reduzido porque faz parte da
automação de teste o teste de regressão automatizado
e frequente;
• Redução de teste manual, o que por sua vez reduz
deslocamento físico;
• Redução da necessidade de debugging futuro porque o
teste é abrangente e a movimentação de código é
reduzida;
• Redução da probabilidade de defeitos: quanto mais o
teste é abrangente e antecipado, menor a
probabilidade que erros entrem em produção;
• Menor quantidade de erros gerados por manipulação
de código de um lado para o outro entre
desenvolvedores e testadores.
Enquanto isso, um alto percentual de cobertura de teste
unitário reduz o superprocessamento através da redução da
necessidade e probabilidade de teste de aceitação
redundante.
Desenvolvimento Orientado a Testes
Em poucas palavras, o test-driven development (TDD) –
desenvolvimento orientado a testes, é a prática de escrever
testes unitários antes de escrever o código. O teste então é
executado e imediatamente falha, visto que o código ainda
não foi escrito. A tarefa do desenvolvedor é escrever código
necessário para o teste passar. Essa sequencia é então
repetida para o próximo teste unitário e dessa maneira um
objeto ou serviço de software é implementado um passo de
cada vez. O desenvolvimento orientado a testes é quase
sempre praticado em conjunto com teste unitário
automatizado.
Assim como entregas curtas e desenvolvimento iterativo
reduz o WIP no nível macro, TDD reduz o WIP a nível
micro. Usado em conjunto ao entendimento de requisitos
just-in-time (discutido abaixo), uma tarefa pode ser
completamente finalizada (projetada, testada e codificada)
dentro de 60 minutos após a sua definição. A tarefa é
pequena, mas é implementada sem incorrer no desperdício
da espera enquanto o WIP é mantido pequeno. Como o
código é restringido pelo teste que o precede, o
desenvolvedor limita-se a escrever apenas código
necessário e nada mais, o que reduz o desperdício de
superprocessamento e superprodução. E como o código
não avança sem ser testado, os defeitos são reduzidos.
Integração Contínua e “Não Quebre o Build”
Continuous Integration (CI) – Integração Contínua, é a
prática de integrar cada incremento de código no repositório
de código logo após ele ser escrito e testado unitariamente
com sucesso.6 Isso é geralmente feito de uma maneira
automática utilizando um servidor de CI. O sistema de CI
não apenas compila e realiza o build do código, mas
executa todo o teste unitário, de regressão, integração e de
aceitação para todo o build ou projeto.
Assim como o Definition of Done pode ser estendido para
ser mais completo, o CI também pode. Testes de aceitação
de usuário, testes de performance, e análise de código
também podem ser adicionados ao sistema de CI,
estendendo assim, a capacidade do time e o escopo de
garantia da qualidade. Estender o escopo do sistema de CI
também reduz a quantidade de trabalho que, de outra
forma, seria realizado nas fases subsequentes de teste,
staging e deployment. Adicionalmente, no código fonte
podem ser aplicados tags, de maneira a rastreá-lo às
atividades de requisitos e desenvolvimento. A frequência
típica e mínima de um membro de time Ágil integrar seu
código é de pelo menos uma vez por dia. Espera-se que
times Ágeis de alta performance integrem código muitas
vezes durante o dia, e muitas vezes tão frequentemente
como a cada alguns poucos minutos. Isso significa que o
tempo do ciclo do processo de CI precisa ser extremamente
curto; caso contrário um desperdício perceptível de espera
começar a ocorrer.
Uma prática madura de CI carrega uma expectativa de que
os membros do time “não quebrem o build”. Esse
compromisso é frequentemente especificado no Definition
of Done do time. “Não quebre o build” significa que se um
incremento de código gera uma condição de “falha” à
medida que ele é integrado, então o build deve ser corrigido
imediatamente. Isto provavelmente envolve remover o
código fonte que ocasionou a falha. No entanto, pode
também incluir corrigir ou mudar código fonte ou teste que
pode ter sido escrito por um diferente membro do time em
outro local no projeto. Tipicamente, isso significa que outra
prática Ágil – propriedade coletiva de código (discutido
abaixo) – também é empregada.
CI reduz o WIP automatizando a completude de testes e
integração de maneira que um Definition of Done rigoroso
pode ser mantido para cada tarefa realizada. A automação
reduz o movimento de trabalho manual e disponibiliza as
métricas de performance de forma a serem diretamente
consumíveis pelo time e stakeholders. A espera pela
finalização do processamento é similarmente reduzida
através da automação. Como os problemas são resolvidos
à medida que eles são identificados, eles não se agravam,
reduzindo o que, ao contrário, resultaria em processamento
adicional. Defeitos são reduzidos pela facilidade do teste
frequente e abrangente e o compromisso de identificar e
corrigir erros rapidamente. Esta prática também torna
prático medir a qualidade técnica para além da simples
contabilização de defeitos, incluindo itens como qualidade
de código, cobertura de teste e aceitação do usuário.
Review da Iteração (Sprint)
Uma iteração, ou Sprint como é chamado no Scrum, é o
período de tempo durante o qual o time trabalha na unidade
de valor que eles esperam entregar no final desse período.
Times de alta performance frequentemente fazem uso de
uma review da iteração (ou Sprint Review) para
compartilhar os resultados da iteração com stakeholders.
Esse processo de review é, em verdade, um miniteste de
aceitação de usuário. Representantes do negócio vêem o
novo código em ação e podem avaliar se a implementação
fornece o valor por trás dos requisitos. Essas
demonstrações ajudam os representantes do negócio a
fornecerem feedback útil para o próximo passo do projeto.
Review de iteração adiciona um outro nível de garantia de
que o código implementado terá valor de negócio prático.
Como ele é feito após cada iteração, a aprovação do
trabalho pelo negócio é obtida antecipada e
frequentemente, o que reduz o WIP. O time não precisa
esperar a aprovação do negócio e o negócio não precisa
aguardar o time para ter uma ideia tangível do progresso.
Os defeitos são reduzidos a partir da medição prática da
validação e aceitação do usuário.
2. Adiar ao máximo as decisões
À primeira vista, esta prática parece o sonho de um
procrastinador se tornando real. No entanto, há uma
diferença chave: aplicar esse princípio requer que uma
negociação seja possível, desejada e realizada sem atraso.
O poder desse princípio aumenta na medida que a
magnitude da incerteza no ambiente operacional aumenta.
Em Ágil, você evita tomar uma decisão agora se você pode
obter informação no futuro que pode melhorar a sua
decisão, desde que o atraso não cause danos
irreversíveis.7
Corolário: Faça apenas o necessário e nada mais
Times Ágeis aplicam essa prática em todas as atividades
envolvidas no desenvolvimento de software, incluindo
criação de documento, planejamento, design de projeto,
codificação e teste. Isso significa que um indivíduo faz
apenas o que é essencial para atender o passo necessário
atual e nada mais. Também significa evitar esforço
duplicado e gerar informação redudante. O que é “apenas
suficiente” não é sempre evidente, especialmente quando
múltiplos stakeholders são envolvidos. Diálogos para
conciliar diferentes perspectivas e estabelecer acordos
sobre como o trabalho deve ser finalizado e se ele deve ou
não ser finalizado são bem-vindos em estruturas ágeis.
Práticas Ágeis
Requisitos Just-In-Time e a Dinâmica do Backlog de
Produto
Requisitos Just-in-time é uma prática de adiar a elaboração
completa do requisito até um pouco antes de quando você
planeja implementá-lo. Requisitos são gerenciados através
de uma dinâmica de Backlog de Produto com os itens mais
prioritários no topo. Estes são os requisitos mais detalhados
porque eles são os próximos a serem implementados. Itens
de prioridade baixa, localizados mais abaixo no Backlog,
são menos detalhados. A prioridade pode mudar, e
requisitos podem ser adicionados ou excluídos a qualquer
momento pelo representante do negócio (conhecido como
Product Owner no Scrum). Os primeiros passos de cada
ciclo de iteração de desenvolvimento são: puxar requisitos
do topo do Backlog, completar as especificações e estimar
o esforço necessário para a implementação.
O WIP é limitado pela finalização da especificação dos
requisitos apenas dos itens que a equipe pretende finalizar
durante a iteração e puxar do Backlog. O desenvolvimento
pode começar mais cedo, uma vez que não há necessidade
de esperar pela conclusão de uma especificação completa
do produto antes do início das tarefas de desenvolvimento.
Os desperdícios de superprocessamento e movimento são
reduzidos porque você evita documentar requisitos que
podem não ser necessários ou podem mudar antes que o
desenvolvimento seja iniciado. Similarmente, o custo de
mudar a prioridade e escopo são dramaticamente
reduzidos. Além disso, uma vez que os requisitos são
priorizados, há mais chances de que, se o escopo for
reduzido, as features de maior valor entrem na release.
Como o escopo pode ser alterado à vontade, pode-se tomar
melhores decisões (e desfazê-las) sobre quais features
serão incluídas, reduzindo, portanto, a superprodução. É
menos provável que a implementação apresente defeitos,
visto que o esforço mental está concentrado num pequeno
segmento de trabalho e o trabalho é iniciado logo após que
o time recebe a melhor e mais atual informação disponível
sobre os requisitos e os seus critérios de aceitação.
Planejamento Multinível
Planejamento multinível é fazer o nível de planejamento
adequado e criar planos no tempo adequado. Quanto maior
o nível, mais resumido o plano. Quanto maior o tempo
coberto, menos frequente é a atividade de planejamento.
Em um extremo está o produto ou visão do sistema, que
pode ser revisitado trimestralmente. O roadmap pode ser
revisto mensalmente ou a cada dois meses e o plano de
entrega quinzenalmente. No outro extremo, a definição e o
planejamento de tarefas são realizados de forma contínua,
uma vez que as tarefas muitas vezes não são totalmente
definidas até pouco antes de serem implementadas e
podem ter apenas alguns minutos de duração. O
planejamento multinível enfatiza o planejamento em vez de
planos. Isso significa que o planejamento detalhado do
trabalho é realizado durante e não antes do processo de
produção, favorecendo assim a discussão, colaboração e
implementação mais do que manutenção de
documentação. Como o planejamento a nível de tarefas é
limitado ao trabalho eminente, o planejamento de estoque e
o WIP são mínimos. Como resultado, agendar o trabalho de
quebra de tarefas com semanas de antecedência é tanto
desnecessário, como também propenso a gerar desperdício
de processamento, visto que o escopo é frequentemente
ajustado através do uso da dinâmica de Backlog. A agenda
de comunicação sobre tarefas entre a gerência do projeto e
o time de desenvolvimento gera desperdício de movimento
e transporte que são reduzidos através do planejamento
multinível. Planejar em diferentes níveis significa menor
espera de aprovação de planos e tempo para atualizações
entre a gerência e o time de desenvolvimento.
Colaboração de Negócios
Colaboração de negócios é o compromisso entre o time de
desenvolvimento e os representantes do negócio de
trabalharem juntos continuamente. Esse engajamento
contínuo durante o projeto se distancia da abordagem
tradicional, onde o contato com o negócio está concentrado
no início e no fim (do ciclo de vida de desenvolvimento). Em
muitas organizações, isso significa que o representante do
negócio está co-alocado junto ao time (de
desenvolvimento). No mínimo, isso significa que o
representante do negócio está altamente disponível a
responder perguntas, fornecer feedback e orientação, e a
participar do planejamento da iteração e revisão da
iteração. Como discutido previamente, ao invés de planejar
e especificar tudo no início, essas atividades são feitas
incrementalmente durante o projeto.
A colaboração do negócio reduz o desperdício de espera
através da redução de atrasos no trabalho causados pela
espera por respostas e aprovações. Reduz o WIP
possibilitando a definição incremental das especificações
que por sua vez facilita a entrega incremental de valor.
Estabelecer e manter uma colaboração contínua e eficaz
conduz a um entendimento mútuo melhor, reduzindo,
portanto, a causa de muitos defeitos. Manter um diálogo
contínuo sobre a iniciativa através do planejamento em
conjunto e em paralelo à revisão iterativa do trabalho
recentemente finalizado significa reduzir a necessidade de
“salvar o estado atual” do projeto através de documentação
provisória. Isso reduz não apenas o desperdício de
movimento e processamento através da redução da
elaboração e revisão de documentos, como também reduz
o desperdício de transporte através da redução de
interpretações e repasse de atividades.

3. Liberte o Poder dos Times

Potencializar o empoderamento dos times tem sido um
componente central do pensamento Lean desde o início.
Práticas ágeis são projetadas para estabelecer e apoiar o
rápido desenvolvimento de equipes de alta performance de
forma deliberada e disciplinada. Organizações que levam a
sério a aplicação dos princípios Agile e Lean devem
assumir compromissos profundos e duradouros para
desenvolver e sustentar seus times. Isso inclui estabelecer
condições para que os times se formem e prosperem, além
de transferir responsabilidade dos supervisores para os
times.
Corolário: Não subutilize o poder criativo do cérebro
Esse princípio é frequentemente referido como o oitavo
desperdício Lean e é fundamental no pensamento Lean. A
ideia é que se tudo o que esperamos das pessoas é que
elas realizem as suas tarefas sem considerar como as
coisas podem ser melhoradas, nós estamos jogando fora o
melhor das pessoas, incluindo a chave para o nosso futuro
sucesso. Uma parte integral da manufatura Lean é o
conceito de que os trabalhadores da produção são
responsáveis por reduzir o desperdício Lean, e não algum
gerente distante ou engenheiro de processo. Espera-se que
as pessoas mais próximas ao problema usem os seus
cérebros para melhorar o ambiente de operação. Isso está
muito longe da atitude gerencial de que os funcionários não
são “pagos para pensar”.
É irônico que o Lean – o campeão do empoderamento do
trabalhador – tenha emergido da manufatura, a indústria
que deu origem à ideia de que a produção é otimizada a
partir da transformação das pessoas em autômatos da linha
de montagem. O que é duplamente irônico é quando
noções ultrapassadas de gerenciamento são aplicadas em
um trabalho do conhecimento como o desenvolvimento de
software, onde as pessoas são pagas para pensar! No
entanto, isso é precisamente o que acontece quando
espera-se que desenvolvedores de software se submetam
sem reservas à metodologias e políticas excessivamente
prescritivas.
Corolário: O time é a unidade de produção
Desenvolvedores de software gastam muito mais tempo em
atividades de design do que construindo de acordo com as
especificações. Realizar o design envolve experimentação
com ideias. O livro “Where Good Ideas Come From”
demonstra como a colaboração habilita a inovação no
decorrer do tempo.8 Através da colaboração, ideias que
nascem na mente de indivíduos criam raízes no mundo real
e são nutridas até que elas gerem frutos na forma de valor
de negócio tangível.
Além de fornecer uma plataforma para a necessária
colaboração nas atividades de design, os times podem
remover obstáculos a partir do trabalho colaborativo dos
seus membros, resolvendo em horas problemas que
indivíduos trabalhando sozinhos talvez nunca resolvessem.
Os times também são robustos e se auto-corrigem de uma
maneira que indivíduos simplesmente não conseguiriam.
Por essas razões, organizações Ágeis medem
produtividade a nível do time e não a nível dos indivíduos.
Práticas Ágeis

Times Pequenos
A diretriz geral para o tamanho de um time Ágil é sete, mais
ou menos dois, ou aproximadamante o tamanho de uma
família grande. O time deve ser pequeno o suficiente para
facilitar o desenvolvimento de relações interpessoais
sólidas. Times pequenos reduzem tempo de espera e
desperdício no processo, visto que profissionais que se
conhecem bem comunicam-se eficientemente, gerando
menor ruído na comunicação. Relacionamentos sólidos
significa que é mais provável que as pessoas se ajudem
para remover obstáculos, reduzindo, portanto, o tempo de
espera e o desperdício de processamento. Uma boa
comunicação conduz a uma finalização de tarefas mais
rápida, o que reduz o WIP. Reduzir mal entendidos também
reduz a causa de alguns defeitos. O desperdício de
transporte de repasses incompletos e erros de interpretação
é reduzido diretamente através de relações de equipe
coesas.
Times Perenes
Times precisam de tempo para se formar. Com o tempo,
sua produtividade e eficiência se tornam cada vez
melhores. Todas as vantagens de redução de desperdício
em times pequenos se fortalecem à medida que o time
amadurece. O investimento no desenvolvimento do time é
perdido se o time não persiste. Esse é frequentemente o
caso quando o negócio decide separar os membros do time
e redistribuí-los em outros times, e nos casos piores, em
times não Ágeis.
Retrospectivas
A retrospectiva é uma das cerimônias do Scrum. O time
investe tempo após cada iteração refletindo no que está
funcionando e no que não está funcionando e então faz um
compromisso de ajustar o seu comportamento de uma
maneira tangível. É um processo leve e auto-dirigido que o
time usa para melhorar incrementalmente.
O foco da retrospectiva é tipicamente na melhoria do bem
estar do time, tornando-o mais efetivo e aumentando a
qualidade de seus resultados. Como as restrospectivas
podem melhorar todos os aspectos da performance do time,
todas as vantagens na redução de desperdício em equipes
pequenas são fortalecidas através do seu uso.
Times Cross-Funcionais
Times cross-funcionais possuem todas as capacidades
funcionais necessárias para completar o trabalho de acordo
com a Definição de Pronto (veja acima). Isso no mínimo
inclui todas as habilidades de desenvolvimento necessárias
para construir e testar as tecnologias que são integradas
para formar o produto ou sistema para a entrega. Funções
adicionais que podem ser necessárias em alguns times são
arquitetura, análise de negócio, usabilidade, design de
interface de usuário, escrita técnica, produção de conteúdo
e operação de produção.
Times cross-funcionais reduzem WIP, espera,
superprocessamento, desperdício de interpretação e de
repasse de atividades, mantendo mínimas as dependências
de funções fora do time e ampliando o impacto positivo da
colaboração do time. O desperdício de defeito também é
reduzido através de uma melhor coordenação da integração
de tecnologias e através de ciclos de desenvolvimento e
teste fortemente acoplados.
Times Auto-Organizáveis
Auto-organização é o processo orgânico no qual indivíduos
interagem e formam um time. Organizações podem dar
suporte a esse processo não interferindo nele
desnecessariamente (i.e evitando micro-gerenciamento em
planejamento e atribuição de tarefas) e disponibililzando um
ambiente que facilite o desenvolvimento e sustentabilidade
do time. Times auto-organizáveis são encorajados a serem
o mais auto-dirigidos possível, especialmente no que diz
respeito a como o trabalho é definido, organizado e
implementado.
Times auto-organizáveis reduzem a necessidade de
supervisão e gerenciamento de tarefas do gerente de
projeto, o que reduz o desperdício de processamento
adicional, espera, interpretação e WIP. Adicionalmente,
times auto-organizáveis têm mais controle em relação a
como eles fazem as coisas, e são capazes de assumir
compromissos mais profundos e significativos sobre o que
podem completar e como melhorar ao longo do tempo.
Propriedade Coletiva de Código
Propriedade coletiva de código é o princípio no qual o time,
não um indivíduo, é responsável por todos os produtos de
trabalho que são produzidos. Isso tem um grande impacto
na redução do desperdício de espera porque ele evita
gargalos em uma única pessoa. Isso também tem um
grande impacto na redução de defeitos. Além disso, o time
gasta menos tempo decidindo quem deve ser o responsável
por corrigir os defeitos (reduzindo também movimento e
superprocessamento), e mais tempo coletivo com um
objetivo compartilhado de eliminar defeitos. Um
compromisso com código de propriedade coletiva é o que
torna possível para o time se comprometer com altos
padrões de Definição de Pronto e se comprometer a não
“quebrar o build”.
Atribuição a Um Único Projeto
Atribuição a um único projeto (também conhecido como
“times dedicados”) significa simplesmente que a maioia dos
membros do time, se não todos, estão em apenas um
projeto por vez. Comprometimentos significativos dos times
– e, portanto, muitos dos benefícios da adoção Ágil – são
impossíveis sem um comprometimento de tempo integral
dos membros do time, visto que se faz necessário um foco
único para atender os compromissos de curto prazo do
desenvolvimento iterativo, semana a semana. No entanto,
pode fazer sentido que alguns membros do time se
envolvam em meio período se as suas contribuições são
necessárias apenas ocasionalmente (ex: administração de
banco de dados).
Atribuição a um único projeto por definição reduz o
desperdício de troca de tarefas (transporte). Também não
há necessidade de esperar que membros do time voltem ao
trabalho. O WIP é reduzido, visto que o rendimento de um
projeto aumenta se ele obtém a capacidade total dos
membros do time.
Co-Localização e Facilitação da Comunicação do Time
Co-localização face a face é o ideal para a comunicação de
times pequenos, visto que é de longe a melhor maneira de
facilitar uma colaboração efetiva. Mesmo assim, times
distribuídos são uma realidade no ambiente de negócios
atual, o que impossibilita o requisito de que os times sejam
co-localizados. Essa barreira para colaboração pode ser
suavizada através do uso de diferentes canais que ajudam
a aumentar a banda de comunicação entre os times,
incluindo: viagens, vídeo conferência, mídia social,
ferramentas de colaboração, co-alocando quando possível,
como também através de todos os outros esforços
necessários para assegurar que os membros do time
distribuído são capazes de se comunicar e colaborar
efetivamente.
Sem um investimento sólido e um comprometimento
continuado de facilitar a comunicação, você não será capaz
de desenvolver ou sustentar um time Ágil efetivo. À medida
que a comunicação do time melhora e cresce
continuamente, os tempos de espera são reduzidos e o
entendimento geral melhora entre os membros do time. Isso
reduz a incidência de mal entendidos, o que significa menos
defeitos. Adicionalmente, a necessidade de interpretar
(transporte) é reduzida, como também o movimento
necessário para se trabalhar conjuntamente.
Programação em Par
Programação em par é quando dois programadores
trabalham juntos numa estação de trabalho para produzir
testes unitários e código fonte. Por mais contra-intuitivo que
possa parecer, programação em par é geralmente mais
eficiente e apresenta resultados de maior qualidade do que
a alternativa comum. Uma maneira que a programação em
par reduz o tempo de espera é através da prática contínua
de revisão de código, onde uma pessoa revisa o código
enquanto outra pessoa o está escrevendo. Como pode ser
visto no diagrama abaixo, revisões de código contínuas
reduzem estados de espera e repasse de atividades,
tornando um processo de dois passos em um único passo e
reduzindo processamento extra através da redução de
retrabalho.
Quando todos os membros do time pareiam uns com os
outros no decorrer do tempo, as relações são fortalecidas,
resultando em uma polinização cruzada de habilidades e
conhecimento, diminuindo ainda mais o tempo de espera
através da eliminação de dependências em uma única
pessoa e do aumento da habilidade coletiva do time em
produzir resultados de alta qualidade.
Conclusão
A tabela abaixo resume nossa discussão em como as
práticas Ágeis implementam os conceitos Lean de redução
de desperdício.
Todas as oportunidades de redução de desperdício
discutidas nesse paper e outras mais estão disponíveis
para qualquer organização que implementa Scrum e
eXtreme Programming. Algumas das práticas, como
entrega antecipada e contínua e desenvolvimento iterativo,
podem ter um impacto imediato e dramático que pode ser
facilmente medido em termos financeiros como o aumento
no retorno do investimento, custos de desenvolvimento
menores e risco de depreciação reduzido.9 Outras (práticas)
têm um efeito incremental que continua a gerar valor ano
após ano.
O mindset e filosofia de redução de desperdício Lean
transformou a manufatura. Hoje, o movimento Ágil,
inspirado no Lean, está transformando o mundo do
desenvolvimento de software. O Lean iniciou como uma
vantagem competitiva que impulsionou a Toyota para uma
liderança global. Na manufatura de hoje, não importa onde
você esteja no mundo, se você não é Lean voce não
consegue competir. Temos todas as razões para acreditar
que este também é o caso da indústria de software onde,
se você não é Ágil, você não será capaz de competir.
Referências
1 Toyota Production System: Beyond Large-Scale
Production. Ohno, Taiichi. 1988
2 A Study of the Toyota Production System. Shingo, Shigeo.
1989
3 http://www.martinfowler.com/articles/xp2002.html. Fowler,
Martin. 2002
4 Manifesto for Agile Software Development. 2001
5 Software Engineering Economics. Boehm, Barry. 1981
6 Continuous Integration. Fowler, Martin. 2006
7 Lean Software Development: An Agile Toolkit.
Poppendieck, Mary and Tom. 2003
8 Where Good Ideas Come From. Johnson, Steven. 2011
9 The Business Value of Agile Transformation. Rudd, John.
2015