Administração da Solução

Aula 05
Pessoas, Conhecimento e Velocidade

Objetivos Específicos
• Conhecer os conceitos de pessoas, conhecimento e velocidade conforme o
processo enxuto de software.

Temas

Introdução
1 Velocidade
2 Pessoas
3 Conhecimento
Considerações finais
Referências

Professor
André Filipe de Moraes Batista
 Administração da Solução

Introdução
A busca por uma entrega cada vez mais rápida de software nos faz produzir um produto
aquém das necessidades de nossos clientes e, então, ao invés de produzirmos valor, estamos
gerando decepções e frustrações, além de passar a imagem de baixa qualidade do trabalho
de desenvolvimento.

Normalmente, a velocidade é entendida como entregar mais rápido. De fato é, mas não
no conceito de uma rapidez desconsidere a qualidade. Pelo contrário, queremos ser mais
velozes por meio da redução de desperdícios e na adição constante da qualidade.

Nessa busca por velocidade e qualidade, temos que nos concentrar nas pessoas. Elas
são essenciais e quando atuam em equipe podemos ter um processo muito mais estruturado
para o desenvolvimento de nossos softwares.

Além disso, pessoas produzem conhecimento. É preciso representar, de alguma forma,

o conhecimento proveniente do processo de desenvolvimento de software. Logo, temos um
tripé: velocidade - pessoas - conhecimento, elementos essenciais à maturidade do processo
de software e para a produção de artefatos com qualidade.

Portanto, nesta aula abordaremos esses três elementos e como gerenciá-los na busca
por um software de qualidade e que atenda às necessidades de nossos clientes.

Bons estudos!

1 Velocidade
Podemos definir o conceito de velocidade na metodologia de desenvolvimento lean
de uma maneira bem direta: velocidade é a ausência de desperdício (POPPENDIECK;
POPPENDIECK, 2010).

O que essa frase quer nos dizer? A ideia por trás da frase remete a um dos princípios do
desenvolvimento lean que prega o trabalho voltado à eliminação do desperdício. Logo, se
nossas etapas são voltadas para eliminar o desperdício, empregaremos uma porção maior do
nosso tempo na adição de valor. Logo, nossa entrega de valor será mais rápida.

Para o casal Poppendieck, especialistas na metodologia lean, há sete desperdícios

que precisam ser eliminados para o aumento da entrega de valor e, consequentemente da
velocidade (POPPENDIECK; POPPENDIECK, 2010, p. 93):

Senac São Paulo- Todos os Direitos Reservados 3

 Administração da Solução

Figura 1 – Sete desperdícios a eliminar visando a entrega de valor

A seguir, detalhamos cada um dos desperdícios:

Trabalho inacabado: é o que chamamos de estoque em desenvolvimento de software.

O objetivo é que a partir do início do trabalho possamos gerar um código integrado, testado,
documentado e entregue, em um fluxo único e rápido. Uma das formas de conseguirmos isto
é dividir o trabalho em pequenos lotes ou iterações;

Funcionalidades extras: para Poppendieck e Poppendieck (2010, p. 95), este é o pior

dos desperdícios no desenvolvimento de software, pois estamos adicionando funcionalidades
que não são necessárias para que o trabalho dos clientes seja realizado. A ideia é a de que se
não existe uma necessidade econômica clara e atual para uma funcionalidade, ela não deve
ser desenvolvida;

Reaprendizagem: trata-se do desperdício em não se consolidar o conhecimento trazido

pelos envolvidos no projeto ao longo do ciclo de desenvolvimento. É fundamental alavancar
o conhecimento de todos os envolvidos, aproveitando a experiência que eles construíram ao
longo do tempo;

Transferência de controle: as transferências de controle sempre resultam em perda de

conhecimento sobre o projeto. Devemos evitar as transferências ao longo da execução de um
projeto. De acordo com Poppendieck e Poppendieck (2010, p. 97), em um projeto após cinco
transferências de controle, restam apenas 3% do conhecimento original deste, o que reduzirá
nossa velocidade, aumentando o desperdício;

Troca de tarefas: passar para uma tarefa diferente ao longo do desenvolvimento de

um projeto não somente gera distração, como toma tempo e, frequentemente, piora os
resultados de ambas as tarefas. Quando os profissionais do conhecimento possuem de três
a quatro tarefas para serem realizadas, eles passam mais tempo reinicializando suas mentes
para trocar de uma tarefa para outra do que de fato trabalhando nelas. Essa troca de tarefas
é um desperdício.

Senac São Paulo- Todos os Direitos Reservados 4

 Administração da Solução

Suponha que você possua três tarefas a serem realizadas: A, B e C. Cada tarefa dura uma
semana para ser concluída. Se você realizar uma tarefa por vez, ao final da primeira semana
a tarefa A será concluída e começará a gerar valor. No começo da segunda semana, a tarefa
B também estará gerando valor e, ao final da terceira semana, você terá concluído as três
tarefas e terá gerado bastante valor ao projeto.

Porém, se você decide trabalhar nas três tarefas ao mesmo tempo, você pode então
dividir cada tarefa em várias partes, por exemplo, mais uma mínima quantidade de tempo
necessária para a troca de tarefas. Nesse cenário, nenhuma delas estará concluída no final
das três semanas. Além disso, você deixou de agregar valor ao projeto, uma vez que elas
poderiam ter contribuído para as atividades do cliente assim que ficassem prontas. A Figura
2 apresenta uma visão do desperdício gerado na troca de tarefas.

Figura 2 - Tempo de conclusão de tarefas: abordagem sequêncial versus abordagem alternada

Fonte: Poppendieck e Popeendieck (2010, p. 98)

Atrasos: esperar pela disponibilidade de pessoas que estão trabalhando em outras áreas é
uma grande causa do desperdício proveniente do atraso. Equipes completas, compartilhando
a mesma sala e realizando interações curtas com feedback, frequentemente podem diminuir
os atrasos, ao mesmo tempo em que aumentam a qualidade das decisões;

Defeitos: Uma equipe boa e ágil tem uma taxa de defeitos extremamente baixa, pois o
foco primário está em produzir um código à prova de falhas e em tornar os defeitos algo raro
(POPPENDIECK; POPPENDIECK, 2010, p. 100). O foco secundário está em achar defeitos o mais
cedo possível, e procurar formas de impedir que aquele tipo de defeito ocorra novamente.

Logo, se a velocidade consiste na eliminação de desperdícios, pode-se adotar uma

estratégia que vise entregar funcionalidades rapidamente. A Figura 3 apresenta uma visão
na qual interações simultâneas são executadas ao longo de um conjunto de equipes de
desenvolvimento. Nota-se que semanalmente são feitas modificações no sistema, para correção
de pequenos erros e ajustes necessários provenientes do feedback dos clientes. Mensalmente
novas funcionalidades são entregues e trimestralmente novas aplicações são entregues.

Senac São Paulo- Todos os Direitos Reservados 5

 Administração da Solução

Em abordagens ágeis, os projetos podem ser divididos em ciclos de iterações denominados

sprints. Um sprint é um período de tempo no qual um conjunto de tarefas pré-definidas são
executadas, entregando valor ao final de sua iteração. É importante notar que cada sprint
(semanalmente, mensalmente e trimestralmente) resulta em um release de produção do
software, isto é, ao término dos sprints, eles somam valor ao software.

Figura 3 - Sobreposição de iterações para entrega de software

Fonte: Poppendieck e Poppendieck (2010, p. 113)

Note que se uma organização pretende, semelhante ao proposto na Figura 3, entregar

novas aplicações em 90 dias, ela necessita manter uma excelente qualidade para suportar tal
rapidez de entrega. O ciclo apresentado na Figura 3 é uma proposta da empresa PatientKeepper,
desenvolvedora de soluções de software para a medicina. Jeff Sutherland, CTO da PatientKeeper,
explica que o ciclo rápido de tempo (POPPENDIECK; POPPENDIECK, 2010, p. 115):

• Aumenta tremendamente o aprendizado;

• Elimina erros de software, pois não se consegue lançar uma nova versão de software
enquanto não corrigi-los;

• Corrige o processo de instalação, pois, se você tiver que fazer mais de 45 instalações do
software em um ano e estas instalações forem difíceis, você não conseguirá corrigi-las;

• Melhora o processo de atualização, porque há um fluxo constante de atualizações

que são obrigatórias. Torna, portanto, as atualizações mais fáceis;

Se estamos nos referindo à velocidade, logo, vamos falar de um termo universal que sempre
está relacionado a ela: o tempo. Para Poppendieck e Poppendieck (2010, p. 115), tudo o que
dá errado em um processo acaba sendo um atraso de tempo. Por exemplo: defeitos aumentam
o atraso; complexidade retarda as coisas; baixa produtividade aparece tomando mais tempo;
intolerância à mudança faz as coisas irem muito devagar; construir a coisa errada adiciona um
enorme atraso; coisas demais no processo criam filas e geram, portanto, retardo.

Senac São Paulo- Todos os Direitos Reservados 6

 Administração da Solução

Temos um círculo virtuoso dos problemas:

• defeitos aumentam o atraso;

• complexidade retarda as coisas;

• baixa produtividade aparece tomando mais tempo;

• intolerância à mudança faz as coisas irem muito devagar;

• construir a coisa errada adiciona um enorme atraso. Coisas demais no processo criam
filas e geram, portanto, retardo.

A busca por entregas mais rápidas de um software, quando não inseridas em um processo
maduro e voltado para a entrega de valor, pode gerar o que Vazquez, Albert e Simões (2013)
definem como a dinâmica do pânico, exibida na Figura 4. É um círculo virtuoso que resulta
em um atraso da entrega, mas com sérias consequências, tais como maior número de erros,
menor controle de qualidade, desgaste da equipe etc.

Figura 4 - A dinâmica do pânico no desenvolvimento de software

Fonte: (VAZQUEZ et. al., 2013. p. 21)

Por que então dizemos que com iterações menores entregamos mais rapidamente? A
resposta a essa questão pode estar relacionada a um conceito muito utilizado para o estudo
de filas de espera: a teoria das filas (POPPENDIECK; POPPENDIECK, 2010).

É fato que boa parte das organizações que desenvolvem software possuem diversas filas
no desenvolvimento, tais como listas de requisições de clientes e listas de defeitos que se
pretende corrigir.
Senac São Paulo- Todos os Direitos Reservados 7
 Administração da Solução

Proveniente da teoria de fila, podemos fazer uso da Lei de Little para nos auxiliar na
gestão dessas filas. A Lei de Little diz que, em um sistema estável, a quantidade média de
tempo que algo leva para atravessar um processo é igual ao número de coisas no processo
dividido por sua taxa de conclusão média. A Lei de Little pode auxiliar uma organização a
aumentar a velocidade de seu processo de desenvolvimento. Para isso, a organização deve
reduzir o tempo de ciclo (POPPENDIECK; POPPENDIECK, 2010).

Unindo a Lei de Little com os conceitos lean, podemos definir que o tempo de ciclo é
dado por (POPPENDIECK; POPPENDIECK, 2010, p. 118):

Coisas no processo
Tempo de ciclo =
Taxa média de conclusão

Uma forma de reduzir o tempo de ciclo é então fazer as coisas mais depressa, isto é,
aumentar a taxa média de conclusão. Isso geralmente significa gastar mais dinheiro. Se
não temos dinheiro para gastar com isto, a outra maneira é reduzir o número de coisas no
processo.

Veja que a Lei de Little é definida para sistemas estáveis, isto é, para sistemas nos
quais a taxa de chegada de coisas a serem feitas e a taxa média de conclusão destas se
mantêm estáveis.

Mas, sabemos que no desenvolvimento de software há diversos elementos que não

permitem essa estabilidade. Há variação nos lotes de entregas. Por exemplo, se há a necessidade
de integrar um código-fonte a um sistema e essa integração vai demorar 6 semanas, haverá
um conjunto grande de problemas a serem corrigidos nesse tempo. Porém, se a integração
dura apenas 60 minutos, é provável que os problemas serão menores. Portanto, as taxas
tanto de chegada de lotes quanto de conclusão destes não ficarão estáveis (POPPENDIECK;
POPPENDIECK, 2010).

A Figura 5 nos apresenta como a teoria de filas pode ser utilizada para aumentar a
velocidade na entrega de valor. Lotes grandes permitem uma alta variação no tempo de ciclo,
em função de defeitos, complexidade etc. Porém, com lotes pequenos temos uma baixa
variação e, consequentemente, o tempo de ciclo pode ser menor, tornando a entrega de
valor mais veloz. Note também que não podemos saturar a utilização de nossos recursos. Pelo
gráfico, a partir de 80% de utilização dos recursos, o tempo de ciclo começa a aumentar. O
ideal defendido pela metodologia lean é atribuir trabalho em pequenas cargas e se concentrar
no fluxo de entrega.

Senac São Paulo- Todos os Direitos Reservados 8

 Administração da Solução

Figura 5 - A dinâmica do pânico no desenvolvimento de software

Fonte: Poppendieck e Poppendieck (2010, p. 119)

Podemos, então, aumentar a velocidade de nossas entregas de valor por meio de alguns
princípios da teoria de filas, quais sejam (POPPENDIECK; POPPENDIECK, 2010, p. 120):

1. Ajuste a chegada de trabalho;

2. Minimize o número de coisas no processo;

3. Minimize o tamanho das coisas no processo;

4. Estabeleça uma cadência regular;

5. Limite o trabalho pela capacidade;

6. Use um cronograma puxado, de modo que cada etapa produza apenas aquilo
solicitado pela etapa posterior.

2 Pessoas
As pessoas formam um dos princípios mais fortes do desenvolvimento lean de software.
De acordo com Poppendieck e Poppendieck (2010 p. 130), lean é um sistema de gerência
que cria pessoas pensantes e comprometidas em todos os níveis da organização e, mais
particularmente, na linha de frente. Para os autores, se implementarmos todos os princípios
lean exceto um - o respeito pelas pessoas - colheremos apenas sombras de vantagens
potenciais que o lean pode proporcionar.

Senac São Paulo- Todos os Direitos Reservados 9

 Administração da Solução

Porém, se implementarmos apenas o princípio de respeito pelas pessoas, permitiremos

que as pessoas da organização se posicionarem de tal forma a descobrir e implementar os
demais princípios lean.

Muitas das boas práticas preceituadas pela metodologia lean para o respeito das pessoas
são provenientes dos princípios estabelecidos pelo estatístico norte-americano W. Edwards
Deming, inventor do ciclo (PDCA - Plan, Do, Check, Act).

Figura 6 – Tradução do ciclo PDCA

Um dos princípios estabelecidos por Deming é que números não contam a história
toda e, quando se trata de pessoas, as coisas que fazem a diferença são perícia, orgulho,
competência, confiança e cooperação (apud POPPENDIECK; POPPENDIECK, 2010, p. 135).

Para Deming (2000 apud Poppendieck e Poppendieck, 2010, p. 136), a qualidade pode
ser alcançada por meio de 14 pontos de gerenciamento conforme a seguir. Note como seus
princípios estão voltados às pessoas. O autor chega a citar até um termo normalmente dito
como sucesso para gestão de pessoas: trabalho em equipe. Mas, o que vem ser uma equipe?

1. Preveja as necessidades de sua empresa a longo prazo; não se concentre em

rentabilidade a curto prazo. A meta é ficar no negócio e criar empregos.

2. O mundo mudou, e gerentes precisam adotar uma nova forma de pensar. Atrasos,
enganos, defeitos de fabricação e serviços de má qualidade não são mais aceitáveis.

3. Deixe de depender de inspeções para encontrar defeitos e começe a construir qualidade

nos produtos enquanto são construídos. Use controle de processo estatístico.

4. Não escolha fornecedores apenas com base na oferta mais baixa. Minimize o custo
total estabelecendo relacionamentos de longo prazo com fornecedores que se
baseiem na lealdade e na confiança.

5. Trabalhe continuamente para melhorar o sistema de produção e serviço. Melhoria

não é um esforço aplicado de uma só vez; cada atividade no sistema deve ser
continuamente melhorada para reduzir o desperdício e melhorar a qualidade.

6. Institua treinamento. Gerentes deveriam saber como fazer o trabalho que

supervisionam e serem capazes de treinar trabalhadores. Gerentes também precisam
de treinamento para entender o sistema de produção.
Senac São Paulo- Todos os Direitos Reservados 10
 Administração da Solução

7. Institua liderança. O trabalho de gerentes é ajudar pessoas a fazer um trabalho melhor

e remover barreiras no sistema que os impedem de fazer seu trabalho com orgulho.

8. Afaste o medo. As pessoas precisam se sentir seguras para fazerem bem seu trabalho.
Nunca deve haver um conflito entre fazer o que é melhor para a empresa e cumprir
as expectativas do trabalho imediato de uma pessoa.

9. Derrube as barreiras entre departamentos. Crie equipes multifuncionais para que

todos possam compreender a perspectiva uns dos outros. Não sabote a cooperação
de equipe recompensando desempenho individual.

10. Pare de usar slogans, exortação e metas. É o sistema, não os trabalhos, que cria defeitos e
baixa produtividade. Exortações não mudam o sistema; essa é responsabilidade do gerente.

11. Elimine cotas numéricas para os trabalhadores e objetivos numéricos para pessoas na
gerência. Elimine prazos arbitrários para equipes de desenvolvimento.

12. Elimine barreiras que roubam das pessoas o seu direito ao orgulho pelo trabalho realizado.

13. Encoraje a educação e o autoaprimoramento para todos. Uma força de trabalho e

uma gerência educadas são a chave para o futuro.

14. Tome as medidas para realizar a transformação. Uma ótima equipe de gerência deve
conduzir o esforço com ação, não apenas com apoio.

Pessoas que trabalham lado a lado não são necessariamente uma equipe, mesmo quando
somam seus esforços individuais em um resultado coletivo. Um grupo de trabalho é considerado
uma equipe, ou um time, quando os membros mantêm-se mutuamente responsáveis para
produzir um “produto de trabalho coletivo” (POPPENDIECK; POPPENDIECK, 2010).

Isto é, quando uma organização coloca pessoas para trabalhem juntas, isto não faz delas
uma equipe. Aquilo que transforma um grupo em uma equipe, de acordo com o Poppendieck
e Poppendieck (2010, p. 139), é o compromisso dos membros de disponibilizarem suas várias
habilidades e trabalharem juntos para um propósito comum.

O desenvolvimento de software é um trabalho a ser feito em equipe. Ele envolve a solução

constante de problemas. As pessoas tomam decisões complexas muitas vezes por dia, muitas
vezes com implicações que estão além de seu trabalho. Membros de uma equipe dependem
um dos outros e ajudam uns aos outros. Uma organização sábia concentrará sua atenção,
treinamentos e recursos de modo a criar um ambiente onde as equipes são desafiadas por
seus trabalhos e os membros estão comprometidos com seus colegas de equipe para fazer o
melhor trabalho que puderem (POPPENDIECK; POPPENDIECK, 2010).

Normalmente as equipes de desenvolvimento de software são compostas por membros

com distintas habilidades: alguns são programadores, outros são arquitetos, outros testadores
e assim por diante. A metodologia lean tem como princípio que a especialização é importante,
Senac São Paulo- Todos os Direitos Reservados 11
 Administração da Solução

no sentido de que os processos de software devem possuir um conjunto de especialistas que

permitam que o objetivo seja atingido.

Porém, os membros da equipe deveriam comprometer-se mutuamente com os objetivos

específicos da equipe e alcançar essas metas por meio do trabalho conjunto, compartilhando
suas especialidades e ajudando uns aos outros sempre que necessário.

É importante ter em mente que o processo de respeito pelas pessoas constrói equipes
nas quais cada pessoa é antes de tudo um membro da equipe e, depois um especialista em
alguma disciplina em particular. Ninguém, porém, na equipe ganha crédito por terminar até
que todo o trabalho que a equipe se comprometeu a fazer seja finalizado (POPPENDIECK;
POPPENDIECK, 2010, p. 143).

Se falamos de equipe, temos que falar também de liderança. Um dos princípios que o
lean adotou da Toyota é que o trabalho em equipe é essencial, mas sempre alguém precisa
ser responsável. Para o desenvolvimento de software um líder pode auxiliar proporcionando
um profundo conhecimento do que o mercado precisa e das tecnologias que possam atender
a essa necessidade.

3 Conhecimento
Estamos vivendo na era do conhecimento. Com a explosão no volume de dados, a maior
riqueza para uma organização é o conhecimento. De nada adianta possuir um grande volume
de dados, sem que possamos compreendê-los e torná-los úteis.

Não é raro encontrar em projetos de desenvolvimento de software a figura isolada de um

programador, cuja função é desenvolver soluções para a demanda dos clientes e a única peça
que temos de conhecimento é o próprio código. A gestão do conhecimento no desenvolvimento
de software é uma questão fundamental (POPPENDIECK; POPPENDIECK, 2010).

O conhecimento é importante por permitir uma maior longevidade na produtividade de

uma equipe, e permite, então, reduzir a complexidade das manutenções futuras no software.

Normalmente, quando se pensa em conhecimento, vem logo à mente a ideia de

documentação. Documento de requisitos, casos de uso, manual do usuário etc. Não que
esses documentos não sejam importantes, mas normalmente eles não representam o
conhecimento. Eles representam apenas o resultado final de um processo, não nos deixando
informações sobre os planos que foram analisados, as possíveis decisões a serem consideradas
etc. São esses elementos que, de fato, formam o conhecimento.

Para criar conhecimento, temos que pensar não no processo de escrita, mas sobre as
pessoas que usarão o que está sendo escrito. Uma ferramenta interessante proveniente
da Toyota é o relatório A3 (POPPENDIECK; POPPENDIECK, 2010, p. 168). A ideia consiste em
condensar o pensamento complexo em uma única folha de papel A3. Isso faz com que as
Senac São Paulo- Todos os Direitos Reservados 12
 Administração da Solução

pessoas filtrem e refinem seus pensamentos, de tal forma que qualquer um que leia o relatório
A3 tenha todas as perguntas respondidas em uma única folha de papel (POPPENDIECK;
POPPENDIECK, 2010).

O objetivo do relatório A3 é capturar o conhecimento crítico de uma forma fácil de ser

armazenada em um banco de dados, fácil de ser publicada em uma área de trabalho, enviada
a um gerente, assim como incorporada em futuros experimentos.

A Figura 7, a seguir apresenta um exemplo de relatório A3 que se baseia no ciclo de

Deming (PDCA – Plan, Do, Check e Act) e que pode ser criado para gestão do conhecimento.
Temos uma página A3 que pode ser dividida em duas partes: de um lado temos o “Planejar”
do PDCA, no qual colocamos elementos que representem nosso planejamento e definição
do trabalho a ser executado. Do outro lado, por sua vez, temos as atividades “Fazer, Checar
e Agir” do PDCA, e nele inserimos elementos como cronogramas, validações a serem feitas e
passos de melhoria. A ideia por trás da elaboração deste documento é a de capturar como se
deu a construção do conhecimento em um projeto.

Vale ressaltar que, nessa figura, o mais importante é a disposição do esquema no A3.

Figura 7 - Exemplo de relatório A3

Amostra de Relatório em A3
Planejar Desempenhar, Checar, Atuar
( Plan ) ( Do, Checar, Atuar )

Fonte: Martin (2011, p. 6)

Senac São Paulo- Todos os Direitos Reservados 13

 Administração da Solução

A seguir, tem-se um roteiro para a escrita de um relatório A3 (POPPENDIECK;

POPPENDIECK, 2010, p. 168):

• Utilize o menor número de possível de palavras;

• Uma imagem vale por mil palavras. Utilize figuras, gráficos e tabelas;

• Tudo deve se ajustar em um lado de uma folha A3;

• Relatórios A3 são documentos dinâmicos. Utilize e altere em função de seu feedback.

Podemos fazer uso do relatório A3 para distintas atividades, a se destacar: representar

uma resolução de um problema, compartilhar um conhecimento sobre um problema e
descrever um conjunto de características úteis de um software.

No caso de representar o processo de resolução de um problema, o relatório A3 necessita

conter um resumo do problema, uma análise da causa raiz, contramedidas sugeridas,
experimentos planejamentos, medições realizadas e feedback.

Já no caso de um compartilhamento comum de conhecimento sobre a resolução de um

travamento de uma base de dados, por exemplo, sugere-se que o relatório apresente a identificação
do problema, gráficos que analisem a situação, lista de possíveis gatilhos que estão ocasionando o
tratamento e as discussões a serem feitas para diagnóstico de cada possível causa.

No caso de um relatório A3 descrevendo um conjunto mínimo de características de um

software, este pode conter uma descrição do trabalho do cliente a ser feito com o software,
qual o valor econômico do software para o cliente, o que os clientes poderão fazer quando o
software ficar completo, um diagrama mostrando o que está e não está incluso, um diagrama
mostrando a interação com outros sistemas.

Existem diversas ferramentas para gerar o relatório A3, assim como

templates para as mais diversas situações. Consulte a bibliografia disponibilizada
nesta aula e conheça mais sobre a ferramenta lean para criação do relatório A3.

Considerações finais
Então, vimos que velocidade, pessoas e conhecimento são elementos essenciais para a
busca da qualidade no processo de desenvolvimento de software.

Para obtermos velocidade, necessitamos reduzir desperdícios e a abordagem de entregas

pequenas, mas que agreguem valor ao cliente apresenta-se como uma excelente alternativa.

Senac São Paulo- Todos os Direitos Reservados 14

 Administração da Solução

Na gestão de pessoas, é fundamental que estas atuem como uma equipe e não um
grupo. Além disso, o conhecimento é fundamental. Todo processo produz conhecimentos
e uma organização necessita mapear tal conhecimento. Os artefatos de software de nada
servem se não representarem o conhecimento gerado ao longo do processo. O relatório A3,
por sua vez, é uma das possíveis formas de se capturar esse conhecimento.

Um abraço e até breve!

Referências
LEAN ENTERPRISE INSTITUTE. The A3 Creator App. 2015. Disponível em: < http://www.lean.org/
a3app>. Acesso em: 26 abr. 2015.

MARTIN, Karen. A3 Management: Lean Enterprise Program. UCSD Extension, 2011. Disponível
em: <http://pt.slideshare.net/KarenMartinGroup/ucsd-class-a3-management-and-root-cause-
analysis>. Acesso em: 11 abr. 2015.

POPPENDIECK, Mary; POPPENDIECK, Tom. Implementando o desenvolvimento lean de

software: do conceito ao dinheiro. Porto Alegre: Bookman, 2010.

VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira; ALBERT, Renato Machado. Análise de
pontos de função: medição, estimativas e gerenciamento de projetos de software. São Paulo:
Érica, 2013.

Senac São Paulo- Todos os Direitos Reservados 15