i

CENTRO UNIVERSITÁRIO SENAC

Leopoldo Carvalho de Lima

Desenvolvimento ágil de software, Lean Thinking em empresas e

empresas de software

São Paulo, Junho de 2013.

 ii

LEOPOLDO CARVALHO DE LIMA

Desenvolvimento ágil de software, Lean Thinking em empresas e

empresas de software

Trabalho de conclusão de curso

apresentado ao Centro Universitário
Senac – Campus Santo Amaro como
exigência parcial para obtenção do grau
de especialista em Gestão e
Governança da TI.

Orientador:
Prof. MSc. Marvin Oliver Schneider

São Paulo, Junho de 2013.

iii
 iv

Pxxx

Tema do TCC - xxxxxxxxxxxxx / Nome do Aluno1, Nome do Aluno2 ... [et

al.] - São Paulo, 2010.
163 f.

Orientador: Prof. Msc. xxxxxxxxx

Trabalho de Conclusão de Curso (Especialização em Gerenciamento de
xxxxxxxxxxxx) – Centro Universitário Senac – Campus Santo Amaro, São
Paulo, 2010.

1. GSI. 2. Projetos. 3. Gerenciamento de xxxxxxxx I. yyyyyyyyya,

xxxxxxxx. II. xxxxxxxx. III...

CDD xxxx.xxxx
 v

ALUNOS: LEOPOLDO CARVALDO DE LIMA

Título: Desenvolvimento ágil de

software, Lean Thinking em
empresas e empresas de software

Trabalho de conclusão de curso

apresentado ao Centro Universitário
Senac – Campus Santo Amaro como
exigência parcial para obtenção do grau
de especialista em Gerenciamento e
Governança da Tecnologia da
Informação.

Orientador:
Prof. MSc. xxxxxxxxx

A banca examinadora dos Trabalhos de Conclusão em

sessão pública realizada em __/__/____, considerou os
candidatos: ( ) aprovado ( ) reprovado

1) Examinador(a)

2) Examinador(a)

3) Presidente
vi
 vii

Aos espirítos de luz que conduziram

meu pensamentos durante todo o
tempo de pesquisa.
 viii

AGRADECIMENTOS

Aos professores do SENAC

xxxxxxxxxxxxxxxx.
 ix

“Que as matemáticas têm invenções

sutilíssimas e que muito podem servir
tanta para contentar os curiosos quanto
quanto para facilitar todas as técnicas e
diminuir o trabalho dos homens;”
René Descartes
 x

RESUMO

xxxxxxxx.

xxxxxxx.

xxxxxxxxx.

Palavras-chave: Gerenciamento xxxxxx, xxxxxxx

 xi

ABSTRACT

xxxxxxx.

xxxxxx.

xxxxxx.

Keywords: xxxxxxx, xxxxxxx

 xii

SUMÁRIO

1. INTRODUÇÃO ............................................................................................... 1
1.1. Contexto ....................................................................................................... 1
1.2. Objetivos....................................................................................................... 1
1.3. Abrangência ................................................................................................. 1
1.4. Trabalhos Relacionados ............................................................................... 1
1.5. Organização do Trabalho ............................................................................. 1

2. METODOLOGIA DE PESQUISA ................................................................... 3

2.1 Critérios de seleção da metodologia de pesquisa ........................................ 3
2.2 A Definição do Projeto de Pesquisa de Estudo de Caso .............................. 4
2.2.1 As Questões de Estudo ................................................................................ 5
2.2.2 As Proposições............................................................................................. 5
2.2.3 A Unidade de Análise ................................................................................... 5
2.2.4 A Lógica que Une os Dados às Proposições................................................ 5
2.2.5 Os Critérios para Interpretar as Constatações ............................................. 5
2.2.6 A Coleta de Evidências ................................................................................ 6
2.3 A Análise Qualitativa das Evidências ........................................................... 6

3. FUNDAMENTAÇÃO TEÓRICA DA PESQUISA ............................................ 7

3.1 Software ....................................................................................................... 7
3.2 Fábrica.......................................................................................................... 7
3.3 Fábrica de Software ..................................................................................... 7
3.3.1 Primeira fábrica de software ......................................................................... 9
3.4 Métodos e princípios ágeis ......................................................................... 10
3.4.1 Manifesto Agile ........................................................................................... 11
3.4.2 Scrum ......................................................................................................... 13
3.4.3 Extreme Programming ................................................................................ 16
3.4.4 Adaptive Software Development ................................................................ 19
3.4.5 Feature Driven Development ...................................................................... 23
3.5 Lean Software Development (Desenvolvimento enxuto de software) ........ 24
3.5.1 Continuar a melhorar .................................................................................. 26
3.5.2 xxxxxx ......................................................................................................... 27
3.6 xxxxx .......................................................................................................... 27
3.6.1 xxxxxx ......................................................................................................... 27

4. APLICAÇÃO PRÁTICA DO CONCEITO DA PESQUISA............................ 28

4.1 Base para trabalhos futuros........................................................................ 28

5. CONSIDERAÇÕES FINAIS ......................................................................... 32

GLOSSÁRIO ............................................................................................................. 33

REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 34

 xiii

LISTA DE FIGURAS

Error! Reference source not found. ......................... Error! Bookmark not defined.
 xiv

LISTA DE TABELAS

Tabela 1 – Situações relevantes para diferentes estratégias de pesquisa .................. 4

 1

1. INTRODUÇÃO

1.1. Contexto

O mercado de desenvolvimento de software

[Estabelece o tempo e espaço, do problema a ser endereça e contribuem para dar

significado e encadeamento ao TCC.]

1.2. Objetivos

Dado a existência de diversos príncipios de desenvolvimento de software, este

trabalho pretende estudar três desses príncipios: fábrica de software, agile e o
desenvolvimento enxuto de software. Além deste estudo, o trabalho pretente elicitar
todos os pontos de convergência entre os príncipios citados.

1.3. Abrangência

[Normalmente, o problema a ser endereçado é muito grande. Portanto, definir de

forma clara o universo do problema e estabelecer os limites/fronteiras e resultados
pretendidos. Declarar claramente, (i) o que será tratado e endereçado e (ii) o que
não será objeto deste trabalho (poderá ser de trabalhos futuros).]

1.4. Trabalhos Relacionados

[Pesquisar e relacionar os trabalhos relacionados com o tema proposto.]

1.5. Organização do Trabalho

Definida sua abrangência, este trabalho está organizado da seguinte forma:

 O capítulo 2 xxx;

 No capítulo 3 xxx;
 2

 xxx

 Finalmente, no capítulo 7 são apresentadas as considerações finais deste

trabalho.
 3

2. METODOLOGIA DE PESQUISA

Apesar do domínio do conhecimento da equipe em diversas dessas atividades, é

evidente que somente a somatória da percepção pessoal dos componentes da
equipe não é suficiente para a compreensão integral de uma operação tão ampla,
complexa e dinâmica.

Surge assim a necessidade da pesquisa e da escolha de sua metodologia.

Neste capítulo, é apresentada a metodologia de pesquisa adotada,

detalhando as seguintes etapas:

 Os critérios e fundamentação utilizados na seleção da metodologia de

pesquisa;

 A definição do projeto de pesquisa, apresentando: as questões de estudo,

as proposições, unidade de análise, a lógica que une os dados às
proposições, critérios para interpretar as constatações e a coleta de
evidências;

 Fundamentação da escolha da análise qualitativa das evidências.

2.1 Critérios de seleção da metodologia de pesquisa

Para a escolha da metodologia de pesquisa, Yin (2005) sugere a análise de

três fatores:

 O tipo de problema a ser resolvido;

 O controle que o pesquisador tem sobre os acontecimentos;

 O grau de foco em eventos contemporâneos em contraste com eventos

históricos.

A tabela a seguir relaciona os três fatores às cinco principais metodologias de

pesquisa: experimento, levantamento, análise de arquivos, pesquisa histórica e
estudo de caso. (YIN, 2005, p.23)
 4

Grau de foco em
Tipo de problema a ser Controle sobre
Estratégia eventos
resolvido acontecimentos
contemporâneos

Experimento Como, por que Sim Sim

Levantamento Quem, o que, onde, quanto Não Sim

Análise de arquivos Quem, o que, onde, quanto Não Sim/Não

Pesquisa histórica Como, por que Não Não

Estudo de caso Como, por que Não Sim

Tabela 1 – Situações relevantes para diferentes estratégias de pesquisa

Portanto, o estudo de caso é a metodologia de pesquisa mais adequada, pois

investiga fenômenos contemporâneos em seu contexto prático, em situações em
que as fronteiras entre o fenômeno e o contexto não são facilmente perceptíveis.
(YIN, 2005)

2.2 A Definição do Projeto de Pesquisa de Estudo de Caso

Para cada pesquisa proposta, deve ser definido um projeto, que é o esquema
lógico que conecta os dados empíricos coletados às questões iniciais e às suas
conclusões.

Acompanhando a estrutura indicada por YIN (2005), foram definidos os

seguintes componentes para o projeto de pesquisa:

 As questões de um estudo;

 Suas proposições;

 Suas unidades de análise;

 A lógica que une os dados às proposições;

 Os critérios para interpretar as constatações.

 5

2.2.1 As Questões de Estudo

Como alcançar a xxxxxx.

2.2.2 As Proposições

As proposições determinam os objetos de estudo que podem contribuir com

evidências relevantes.

xxxxx.

2.2.3 A Unidade de Análise

A unidade de análise representa o caso estudado xxxx

2.2.4 A Lógica que Une os Dados às Proposições

Este componente do projeto define como os dados coletados durante a

pesquisa se relacionam com as proposições iniciais.

xxxxx

2.2.5 Os Critérios para Interpretar as Constatações

O critério fundamental para análise dos dados coletados é a pesquisa

bibliográfica, incluindo o estudo de trabalhos recentemente públicados em livros,
teses, artigos de revista, anais de congressos, em bibliotecas e na Internet. Assim, é
ampliado o número de fontes relativas à pesquisa, possibilitando validar os dados
coletados através do cruzamento das diversas fontes de evidências.
 6

2.2.6 A Coleta de Evidências

Além de pesquisa bibliográfica, são válidas as seguintes fontes para a coleta

de evidências: registros em arquivos, entrevistas, observação direta e observação
participante.

2.3 A Análise Qualitativa das Evidências

A análise qualitativa é válida na elaboração das deduções específicas sobre

um acontecimento fundamentado na presença dos objetos em análise e não na
freqüência da sua ocorrência, em cada comunicação individual. (BARDIN, 1977)

Portanto, o estudo xxxxx.

 7

3. FUNDAMENTAÇÃO TEÓRICA DA PESQUISA

Neste capítulo são abordados xxxxx

3.1 Software

Software, segundo Cussomano(1989), é algo que se difere dos demais

produtos físicos(hardware) que são feitos através de componentes substituíveis e

construídos através de um processo sequencial de montagem. O software é

primeiramente um processo repetitivo de concepção, codificação, testes e

reconcepção.

Ou seja, software é algo vivo, em constante mudança, e que de maneira ou

outra o processo de concepção e construção de uma primeira versão e as

modificações subsequentes seguem em si um processo sequêncial, tal qual para a

produção de produtos físicos .

3.2 Fábrica

Segundo o dicionário Houaiss, a acepção econômica da palavra Fábrica é “o

parque industrial onde se processa a transformação de matéria-prima, ou de peça,

em produto para o mercado”. Para Flusser(2007), “fabricar significa apoderar-se de

algo da natureza e convertê-lo em algo manufaturado, dar-lhe uma aplicabilidade e

usá-lo”.

Assim, podemos concluir que fábrica é um local de conversão de uma

material em outro.

3.3 Fábrica de Software

Com base nos conceitos desmembrados de Fabrica e Software citados

acima, podemos supor que uma Fábrica de Software é um lugar onde se produz
 8

Softwares. Entretanto, ainda resta uma lacuna, de qual seria a materia prima de uma

fábrica de software.

O termo fábrica de software começou a ser utilizado por empresas e

engenheiros de software por volta da década de 1960, quando consideraram que

este conceito seria o mais eficiênte para o desenvolvimento de software. Segundo

Cussomano(1989), a movimentação dos engenheiros de software buscava uma

nova revolução industrial, mas dentro do segmento de software. Nesta época,

haviam dois pensamentos distintos o de R. W. Bemer da GE e, M.D. MCIlroy da

empresa AT&T.

Bemer acreditava que uma fábrica de software deveria ser um ambiente onde

houve um foco restrito em programação e que fosse controlado por computador. A

construção do programa, o check-out do código fonte e o seu uso deveriam ser

feitos somente naquele ambiente, usando as ferramentas que lá houvessem. Bermer

também propunha que uma fábrica de software deveria ter métricas e controles para

produtividade e qualidade.

Para Mcllory, fábrica de software era um lugar especifico que produziam

familias de pedaços de software, parametrizaveis ou rotinas, que serviriam como

blocos de programas adaptados que seriam reutilizados entre diferentes

computadores. (nascimento do java será?)

Seguindo o pensamento de Mcllory e Bermer, AT&T, GE e IBM, durante os

anos 60, fizeram muitas descobertas de como ou não gerenciar projetos de

desenvolvimento de software quando esse último é montado por milhares ou mais

de programadores(Cussomano, 1989).
 9

3.3.1 Primeira fábrica de software

Apesar das pesquisas de Bermer e Mcllory serem datadas de 1969, a

primeira fábrica de software que se tem registros históricos nasceu no Japão em

1969.

A dona desta primeira fábrica de Software foi a Hitachi e, seus engenheiros

tinham em mente duas grande metas. 1 – produtividade e melhoria confiável através

da padronização de processos e controles e 2 – a transformação do “software” de

um serviço desestruturado em um produto com níveis de qualidade garantidos.

Essa divisão de software da Hitachi tornou-se independente do resto da

empresa e isso deu maior autonomia para seus gerentes no desenvolvimento de

software. A partir desse momento, inicialmente, os gerentes da divisão de software

da Hitachi focaram seus esforços em determinar os padrões para a produtividade e

os custos em todas as fases do desenvolvimento de software com a finalidade de,

segundo Cusomano(1989), alimentar um banco de dados para suportar o

gerencimento de projetos e o controle de qualidade.

O segundo passo dado pelos executivos da divisão de software da Hitachi foi

padronizar a concepção de software com base nas técnicas de programação

estruturada e, reforçou esses novos padrões com treinamentos para novos

funcionários e gerentes.

Para Cusomano(1989), os executivos da Hitachi houveram aspectos positivos

nessa empreitada cuja intenção era melhorar e padronizar a média dos perfis dos

profissionais que trabalhavam para eles e, ainda para Cusomano, a empreitada teria

sucesso completo se houvessem também procedimentos a serem aplicados a cada

projeto e em cada fase do desenvolvimento de software.

 10

Os executivos da Hitachi, após a empreitada de padronização e melhoria do

perfil dos trabalhadores , ainda investiram ostensivamente em ferramentas de

automatização para o gerenciamento de projetos, suporte a concepção de software

testes, geração automática de códigos e rotinas prontas. Entretanto, para

Cusomano, a Hitachi subestimou o quão dificil seria implementar conceitos de

reusabilidade e padronização de processos em uma fábrica de software que

desevolvia softwares padrões, como sistemas operacionais e aplicações

customizadas, o que em 1985 resultou em uma nova divisão da Hitachi para

aplicações customizadas.

3.4 Métodos e princípios ágeis

Diante um mundo corporativo impactado por mudanças constantes, os

princípios ágeis para o desenvolvimento de softeware, segundo Coram e

Bohner(2005), compartilham o objetivo comum das equipes responderem

velozmente à mudanças.

Segundo Wang, Conboy e Cawley(2012), métodos ágeis são geralmente

denotadas as familias de métodos que estão debaixo o “guarda-chuva” do Agile

Alliance, instituição que tem por missão suportar quem explora e aplica os princípios

e práticas ágeis a fim de tornar a industria de software mais produtiva, humana e

sustentável.

A ideologia ágil teve início em 2001 com o Manifesto Agile. Segundo Wang,

Conboy e Cawley(2012), os princípios agile mais comuns são: Scrum, Extreme

Programing, Adaptive Software Development e Feature Driven Development.

 11

3.4.1 Manifesto Agile

O manifesto ágil foi lançado em 2001 por um grupo de 17 profissionais, cuja

ideologia era independente de empresas e, todos praticantes de diversas

metodologias de desenvolvimento de software. Esse manifesto, agregou 12

princípios, literalmente traduzidos como abaixo:

1. Nossa principal prioridade é satisfazer o cliente através de

entregas antecipadas e continuas de software de valor

agregado;

2. Mudanças em requisitos são bem-vindas, mesmo quando o

software já se encontre desenvolvido. Processos ágeis

aproveitam mudanças para vantagens competitivas de seus

clientes;

3. Entregar frequentemente softwares que funcionem, entre meses

ou semanas, dando sempre preferência a escalas curtas de

tempo;

4. Pessoas das áreas de negócios devem trabalhar e

desenvolvedores de software devem trabalhar diariamente e

juntos, durante todo o projeto de desenvolvimento de software;

5. Construir projetos em torno de pessoas motivadas. Dando a

esses indivíduos um ambiente de trabalho propício e o suporte

que eles precisarem, confiando que concluirão o trabalho

designado à eles;

6. O método mais eficaz de se transmitir informações dentro de

uma equipe de desevolvimento de software é através de

conversas cara-à-cara;
 12

7. A medida primária do progresso é o software funcionando.

8. Processos ágeis promovem o desenvolvimento sustentável. Os

patrocinadores, desenvolvedores e usuários devem ser capazes

de manter uma passada constante e por tempo indeterminado.

9. Atenção continua à excelência técnica e uma boa concepção

aumentam a agilidade;

10. Simplicidade: A arte de maximizar a quantidade de trabalho que

não precisa ser feito. É essencial;

11. As melhores arquiteturas, requisitos e concepções surgem de

equipes auto-organizaveis e;

12. Em intervalos regulares, a equipe replete o quão mais efetiva se

tornou, então ajustam e afinam seu comportamente de acordo

com o cenário atual.

Segundo o Agile Alliance, apesar dos 17 profissionais não concordarem sobre

muita coisa, existe entre eles um consenso a respeito de 4 itens fundamentais do

desenvolvimento ágil de software a serem valorizados em detrimento a valores

comumente exaltados pela comunidade ortodoxa de desenvolvimento de software:

1. Valorizar mais os indivíduos e suas interações do que

ferramentas e processos;

2. Valorizar mais o software que funciona do que uma

documentação compreensiva;

3. Valorizar mais a colaboração do cliente do que a negoviação de

contrato e;

4. Valorizar mais a resposta à mudanças do que seguir um plano.

 13

3.4.2 Scrum

Na literatura, o termo Scrum aparece a primeira vez em Takeuchi e

Nonaka(1981) em um artigo de autoria deles chamado The new new product

development game, onde é feita uma alusão entre o esporte Rugby e o processo de

desenvolvimento de novos produtos. Onde, diz Takeuchi e Nonaka(1981), esse

processo emerge da constante interação de uma equipe multidisciplinar e bem

escolhida, cujos membros trabalhavam do início ao fim do projeto.

Em entrevistas com CEOs e jovens engenheiros, Takeuchi e Nonaka(1981)

apreenderam que empresas bem-sucedidas apresentavam 6 caracteristicas em sua

filosofia de gerenciamento do processo de desenvolvimento de novos produtos:

1. Formação instavel;

2. Equipes de projetos auto-organizaveis;

3. Sobreposição das fases de desenvolvimento;

4. Multi-aprendizado;

5. Controle sutil e;

6. Transferência organizacional de aprendizado.

Até aquí, vemos que o termo Scrum foi cunhado especificamente para a

engenharia de produtos, entretanto, segundo Srinivasan e Lundqvist(2009), o

conceito foi formalizado dentro da engenharia de software por Ken Schaber, em

1995 e, após está formalização, o Scrum foi amplamente adotado como padrão para

na industria de engenharia de software.

Segundo a Scrum Alliance, o Scrum é um framework ágil de desenvolvimento

de software com três papéis e responsabilidades(tabela 3.4.2.1), três

cerimônias(tabela 3.4.2.2) e três artefatos (tabela 3.4.2.3). Coram e Bohner(2005)

 14

consideram que o Scrum se concentra em como equipes podem ser organizadas

para produzir softwares em um ambiente com constante mudanças.

A palavra chave para entendimento do Scrum é Sprint. Segundo Schwaber e

Sutherland, autores do Guia do Scrum, o Sprint é o coração do Scrum. Ele é a faixa

de tempo, cuja duração é de 1 mês ou menos, no qual a equipe de desenvolvimento

trabalha em uma lista pré-definida de requisitos, chamada de Sprint Backlog(Tabela

3.4.2.1), que foi criada na última Reunião de Planejamento da Sprint(Tabela 3.4.2.3)

com base no Backlog do produto(Tabela 3.4.2.1) e priorização feita do Product

Owner(Tabela 3.4.2.2).

Artefatos Função

O backlog do produto são todos os requisitos e entendimentos

Backlog do produto
necessários para produzir os requisitos daquele produto.

É o conjunto de itens selecionados do Backlog do produto, que serão

trabalhados na Sprint.
Sprint backlog
Também pode ser considerado a previsão de trabalho que a equipe de

desenvolvimento deverá realizar naquele período.

É a soma dos esforços restantes, geralmente mensurados em Sprints,

Burndown Chart
para a finalização do Backlog do produto ou da Sprint.

Tabela 3.4.2.1 – Scrum – Artefatos

Papel Responsabilidade

Define as funcionalidades do produto, prioriza os requisitos do usuário

baseados na expectativa de valor agregado ao negócio, gerência o

Product Owner
backlog do produto ajustando e priorizando as atividades e aceita os

produtos criados pela equipe de desenvolvimento.

Certifica que a equipe esteja funcional e produtiva, protege a equipe

Scrum Master
de interferências externas, coordena reuniões e cuida das atividades
 15

de gerenciamento do projeto.

Faz o trabalho efetivo, suporta as estimativas de esforço para o

backlog do produto, cria e compartilha o objetivo do sprint e seleciona

Equipe de desenvolvimento
um pacote funcional de pendências do backlog para entregar na

próxima sprint.

Tabela 3.4.2.2 – Scrum – Papéis e Responsabilidades

Cerimônias Função

Neste evento, a equipe, composta pelos três papéis citados na tabela

3.4.2.2, trabalha na estimativa da funcionalidade que será

Reunião de planejamento do desenvolvida durante o próximo Sprint.

Sprint Os pontos de partida para este evento são: o backlog do produto, o

incremento mais recente feito e a capacidade de entrega da equipe de

desenvolvimento.

Neste evento, a equipe, composta pelos três papéis citados na tabela

3.4.2.2, se reune diáriamente em um mesmo local e horário, cujo

Reuniões diárias ou stand-up
tempo máximo de reunião são 15 minutos.
meetingsou Daily Scrum
A função deste evento é inspecionar o trabalho que foi feito desde a

última Reunião Diária.

Neste evento, a equipe, composta pelos três papéis citados na tabela

3.4.2.2, discute o que foi construído na última Sprint, e adequa o

backlog do produto caso se faça necessário.

Reunião de revisão do Sprint
Geralmente, este evento tem 4 horas para Sprints que tenham

duração de 1 mês, sendo o tempo de duração da reunião

proporcionalmente menor se o tempo de duração da Sprint for menor.

Tabela 3.4.2.3 – Scrum – Cerimônias

 16

3.4.3 Extreme Programming

Para Coram e Bohem(2005), Extreme Programming, doravante chamada

apenas de XP, é o mais conhecido método ágil, que tem como objetivo primordal “ter

o projeto pronto em mãos”, o que em Crawford, Barra, Soto e Monfroy(2012),

significa uma metodologia concebida para para entregar o software que o cliente

precisa, quando ele precisar.

Segundo consta em Beck(1999), as práticas individuais(tabela 3.4.3.1)

contidas no XP não eram novidades para a época. Muitas pessoas chegaram a

conclusões similres sobre os melhores meios de entregar softwares funcionais em

ambientes onde os requisitos eram alterados violentamente.

O XP, assim como o Scrum, trabalha em meio a interações e cada interação

dessas carrega em si a prática de Cascata de desenvolvimento de software,

entretanto as interações são pequenas, ou seja, o escopo do projeto é dividido em

escopos menores e cada um desses são tratados em interações no XP.

Prática Função

Os clientes decidem o escopo e o tempo das versões

basesadas nas estimativas dos programadores. Os

Planejamento do jogo
programadores somente implementam funcionalidades que

estejam descritas naquela interação.

O sistema é colocado em produção em poucos meses, antes de

que todos os requisitos sejam implementados. Novas versões

Pequenas versões
são lançadas frequentemente. Ou seja, o sistema é colocado

em operação com o básico para seu funcionamento no negócio.

As formas do sistemas são definidas como metáforas, que são

Metaforas
compartilhadas entre o cliente e os programadores
 17

A todo momento, a concepção do software executa por si todos

os testes, comunica tudo o que os programadores desejam

Concepção simples
comunicar e não contém nenhum código duplicado e tem a

quantidade menor possível de métodos e classes.

Os programadores escrevem os casos unitários de teste a cada

minuto, a cada pequena funcionalidade codificada e executa

esse teste.

Além de testes unitários, são executados testes funcionais,

Testes
assim que uma funcionalidade que atende por completo o

requisito de um usuário é contruída. Geralmente, esse tipo de

teste é feito com base no caso de uso da funcionalidade e

executado por usuários ou clientes.

Geralmente, um sistema é composto por diversas

funcionalidades e, mais baixo nível, ele é composto por diversos

procedimentos codificados que operando em conjunto atendem

aquela funcionalidade.
Recomposição
A recomposição quer dizer que, através dos requisitos dos

usuários, desmontamos todo o sistema em partes

compreenssíveis, identificamos onde é que a alteração deve ser

feita, alteramos e em seguida recompomos o sistema.

Todo código escrito usando a prática do XP deve ser elaborado

por duas pessoas ao mesmo tempo. Segundo Beck(1999), este

Programação em pares
método mitiga a questão da rotatividade dos programadores em

uma equipe de XP.

Os programadores são encorajados a integrar os requisitos

codificados ao código original do sistema que está em

Integração contínua funcionamento, em poucas horas após o código estar pronto.

Após integrado, o sistema é compilado desde o início e testado.

Se não houver sucesso nos testes, a alteração é descartada.

Propriedade coletiva Todo programador é encorajado a melhorar qualquer código

 18

encontrado em qualquer parte do sistema, caso exista de fato a

oportunidade.

Cliente no mesmo local da equipe O cliente fica no mesmo local físico e próximo a equipe.

Ninguém da equipe deve trabalhar mais que 40 horas semanais,

mesmo nos casos isolados onde frequentemente horas-extras

40 horas semanais
são indicadas como oportunas para investigar problemas que

precisem ser enderaçados à solução.

A equipe trabalha em uma sala ampla, com pequenas baias ao

Espaço de trabalho aberto redor. Os programadores, em pares, trabalham em

computadores configurados no centro da sala.

Integrantes de uma equipe XP concordam em seguir

determinadas regras, entretanto, as regras poderão ser

Apenas regras mudadas a qualquer momento em que a equipe decidir mudá-

las e, como serão tratados todos os efeitos que poderão ocorrer

nessa mudança.

Tabela 3.4.3.1 – XP – Práticas, segundo Beck(1999), Smith e Stolecklin(2001)

Fase Função

Geralmente leva alguns dias, semanas ou meses, dependendo

do tamanho do projeto, para que os clientes forneçam os

Exploração requisitos para a primeira versão. Ao mesmo tempo que a

equipe se torna familiar com as ferramentas, tecnologias e

praticas que serão utilizadas no projeto.

A equipe do projeto gasta diversos dias trabalhando em parceria

com o cliente priorizando as capacidades necessárias do

Planejamento software para a primeira versão. Os desenvolvedores estimam o

esforço necessário e o líder da equipe esboça o sumário da

versão, cuidando para que isso não ultrapasse 2 meses.

Interações para produção de Consiste em diversas interações para a produção da primeira

 19

versões versão. Cada interação desses gasta entre 1 e quatro semanas

e, no final de cada interação, testes funcionais são

executados(tabela 3.4.3.1). Completando a última interação

necessária para a versão em questão, o software está pronto

para a fase de Produção.

A equipe de projetos conduz testes adicionais de desempenho,

e certifica que a versão entregue cumpri todos os requisitos do

usuário. Novas alterações poderão ser introduzidas aqui e, a

desição deverá ser feita se essas alterações podem de fato ser

Produção
incluidas nessa versão. Caso não possa ser incluída nessa

versão, essas alterações deverão ser registradas e incluídas em

versões posteriores.Essa fase concluí a versão que será

entregue para o cliente.

Nesta fase, a equipe produz novas interações no software com

a finalidade de implementar mudanças e novas funcionalidades

Manutenção levantadas na fase anterior. Isso inclui mudanças corretivas,

perfeccionistas e adaptações necessárias levantadas durante a

fase de manutenção.

Quando o software se aproxima da obsolência, o cliente tem

poucas funcionalidades viáveis para implementar. Então, o

Morte sistema está na fase de morte. Esta fase envolve a

complentação de toda documentação e a desativação do

sistema é plajenada.

Tabela 3.4.3.2 – XP – Fases, segundo Coram e Bohner(2005) e Crawford, Barra, Soto e

Monfray(2012)

3.4.4 Adaptive Software Development

Para Koch(2005), quem trouxe pela primeira vez o Adaptive Software

Development, a partir de agora ASD, à luz acadêmico-teórica foi Jim Highsmith por
 20

volta de 1990, trazendo em si o entendimento de Highsmith sobre a teoria do

Complex Adaptive Systems, ou em português, Sistemas Adaptivos Complexos ou

SAC.

O SAC, segundo Dodder e Dore(2005), são maneiras de entender a auto-

organização dinâmica e espontânea do mundo, os SAC são compostos de uma rede

de muitos agentes que coletam informações, aprendem e agem em paralelo em um

ambiente produzido por esses próprios agentes.

Highsmith(2002) diz que seu interesse pelo SAC começou a adicionar um

histórico conceitual para os aspectos das práticas da sua equipe e foi o catalizador

para que essas práticas se chamassem Adaptive Software Development(ASD).

Highsmith(2002), considera que o ASD é constituído para trabalhar com mudanças,

ao invés de lutar contra elas, tendo como principal objetivo prosperar em ambientes

turbulentos e, diante disso, o ADS tem práticas que abraçam, engajam e respondem

rápidamente as mudanças e, inclusive as suas práticas são adaptaveis.

As práticas do ASD são dirigidas por uma profunda crença na adaptação

contínua, com uma filosofia e um ciclo de vida orientados na aceitação de mudanças

continuas, diferente do conceito tradicional de desenvolvimento de software, o

cascata, esse ciclo de vida estático de construção de software é substituido por um

ciclo de vida dinâmico de conjecturação/especulação, colaboração e aprendizado.

O ciclo de vida em cascata de desenvolvimento de software é baseado no

presuposto de um ambiente de negócios relativamente estável e, esse ciclo de vida

se torna sobrecarregado por alto números de mudanças já, a proposta de ciclo de

vida de Highsmith(2002) é dedica ao aprendizado constante e orientada à

mudanças, re-avaliações, perscrutações da inconstância do futuro e, uma intensa

colaboração e entre desenvolvedores, gerentes e clientes.

 21

Segundo Highsmith(2002), o conceito de planejamento é o mais difícil de ser

re-pensado por engenheiros e gerentes, principalmente por aqueles que foram

formados em conceitos reducionista e, que tenham uma crença quase religiosa de

que um planejamento cuidadoso e seguido de um processo rigoroso de engenharia

produziria um resultado desejado, além é claro da impressão de se ter controle

sobre o processo. A palavra plano, quando usada na maioria das organizações,

indica um nível razoavelmente alto de certeza sobre os resultados desejados.

No ASD existem três fases em seu ciclo de vida: conjecturação, colaboração

e aprendizado.

Fase Descrição

Aqui, existe espaço para explorar o que será desenvolvido, são feitos

diversos ensaios de soluções, sendo conhecida também como a dase

dos pre-supostos, explorações e simulações. Assim, dá-se também a

percepção de que não há certeza de fato do que está sendo proposto

e é deixado claro que apesar de selecionada uma das soluções, a

solução pode mudar no decorrer do projeto.

Conjecturação
Isto não significa que o planejamento é obsoleto, quer dizer que ele é

reconhecidamente leve, assim, a conjecturação reconhece a natureza

incerta dos problemas complexos e o divide em partes menores,

gerando interações de entregas curtas e se houverem mudanças ao

longo do projeto, o que já foi construído é adaptado à nova realidade.

Para o ASD, aplicações complexas não são construídas. Elas evoluem

Aplicações complexas requerem que um grande número de

informações sejam coletadas, analisadas e aplicadas à determinado

Colaboração problema e, esse volume de informação é tão grande que um

indivíduo não poderia tratar por si só. Então, advém a colaboração de

indivíduos com os mais diferentes conhecimentos.

 22

Para o ASD, os diferenciais, para produção de resultados, são que os

indivíduos envolvidos no projeto tenham a capacidade de trabalhar em

conjunto seja no compartilhamento de seus conhecimentos seja em

tomadas de decisões.

O ASD considera que todos os integrantes de uma equipe devem ser

capazes de testar seus conhecimentos constantemente, seja em

práticas como retrospectivas de projetos ou em eventos para

Aprendizado discussão de problemas com clientes.

Assim, o ASD aconselha que todas revisões devem ser feitas

imediatamente após cada de interação de produção de resultado e no

final do projeto.

Tabela 3.4.4.1 – ASD – Fases

O ciclo de vida do ASD têm 6 característiscas básicas: foco em missão,

baseado em funcionalidades, interatividade, temporal, risco calculado, tolerante à

mudanças,

Característica Descrição

Manter o foco em uma missão fornece aos integrantes da equipe os

Foco em missão limites que o trabalho deve ter, ao contrário de estabelecer um ponto

fixo de destino.

Se basear em funcionalidades quer dizer que os resultados do

Baseado em funcionalidade trabalho da equipe são as funcionalidades entregues, e não apenas

tarefas executadas.

Interatividade Toda funcionalidade é desenvolvida em interações.

Existe um tempo pré-definido para as interações ou para o projeto.

Usar o limite de tempo como maneira de coagir a equipe, é uma

Temporal
maneira também de colocar em risco a colaboração dos integrantes da

equipe.

Risco calculado A análise de riscos em ASD determina os planos para as interações.

 23

O ASD não ve mudanças como problemas, ele ve as mudanças como

a habilidade de incorporar mudançass como uma vantagem

Tolerante à mudanças
competitiva. Sendo assim, as interações curtas fornecem a

possibilidade de mudanças rápidas.

Tabela 3.4.4.2 – ASD – Características

3.4.5 Feature Driven Development

O Feature Driven Development ou FDD, segundo Chowdhury e Huda(2011),

foi introduzido no mercado de desenvolvimento de software em 1997, por Jeff de

Luca e Peter Coad, quando ambos trabalhavam em um projeto no United Overseas

Bank em Singapura.

Anderson(2004) diz que as funcionalidades no FDD devem ser escritas em

linguagem comum a áreas de negócios, de maneira que as partes interessadas

tenham um entendimento único do que está sendo proposto. Para Pang e

Blair(2004), a funcionalidade no FDD deve ser considerada como algo que agregue

valor ao cliente e que possa ser implementada em duas semanas ou mentos.

O FDD se caracteriza também pelo desenvolvimento de software incremental,

onde novas funcionalidades são planejadas, criadas e agregadas ao que já existe, a

fim de se criar e demonstrar resultados solidos e tangiveis à curto prazo.

Para Chowdhury e Huda(2011), o FDD tem, a princípio, duas grandes fases

sendo a primeira, a descoberta da lista de funcionalidades e, nesse estágio, a

participação dos clientes ou partes interessadas deverão ser em tempo integral. Na

segunda fase, parafraseando Anderon(2004), o FDD tem 6 marcos que deverão ser

seguidos para cada funcionalidade indentificada na fase anterior, como o a seguir:

Marco Descrição

Passo à passo Explicação da funcionalidade para os desenvolvedores. Isso deve

 24

acontecer em reuniões face-à-face.

Modelagem Criação de diagramas de seqüência

Uma revisão de modelagem acontece por um dos integrantes da

Revisão da modelagem equipe, que não seja o mesmo que tenha modelado, com a finalidade

de conferir se o que foi modelado atende o requisito/funcionalidade.

A funcionalidade são escritas em códigos de programação, com a

Codificação
finalidade de encerrar a modelagem.

É a revisão do que foi códificado e se isso está aderente aquilo que foi
Revisão de código e testes
modelado. A revisão acontece por uma pessoa da equipe diferente
unitários
daquela que codificou. Após a revisão, é feito o teste unitário.

Aquela funcionalidade construída e testada unitariamente é

incorporada ao sistema e, este último é compilado, testado conforme o

Promoção
impacto da funcionalidade e se os testes forem bem sucedidos, o

sistema é colado em produção.

Tabela 3.4.5.1 – ASD – Marcos FDD

3.5 Lean Software Development (Desenvolvimento enxuto de

software)

Para Ebert, Abrahamsson e Oza(2012), o Lean Software Development é um

paradigma no desenvolvimento de produtos com foco, de ponta à ponta, na criação

de valor para o cliente, eliminando o desperdício, otimizando a cadeia de valor,

empoderando pessoas e na melhoria contínua. Eles ainda consideram que o cerne

do Lean Software Development a simplicidade e parafraseiam Antonie de Saint-

Exupery, autor de O pequeno princípe, que diz que “a simplicidade não é quando

não existe mais nada a ser adicionado mas se refere quando não se existe mais

nada que possa ser retirado”.

 25

Essa é uma sabedoria relativamente antiga no desenvolvimento de software,

dizendo que a maioria das funcionalidades dos produtos de software não agregam

nenhum valor de fato ao produto, que ao contrário, criam complexidades

desnecessárias e degradarem progressivamente os produtos. Ainda Ebert,

Abrahamsson e Oza(2012) acreditam que a demanda por redução de custos, nos

anos mais recentes, forçou a indústria de software a olhar para os princípios Lean

com a ambição de aplicá-los ao desenvolvimento de software.

Segundo Poppendieck e Cusumano(2012), o termo Lean foi aplicado

primeiramente em gerenciamento de processo de produção e, então, no

desenvolvimento de produtos no MIT(Massachusetts Institute of Technology),

durante a década de 1980, firmando uma data específica quando um engenheiro da

Toyota, John Krafcik, em 1986 ingressou no MIT para estudar um mestrado.

O termo e os conceitos de Lean tiveram origem no Japão em meados de

1940, especificamente na Toyota, quando o país passava por uma crise econômica

influênciada pela 2a Guerra Mundial, que gerou uma escasses de matéria prima,

levando os executivos da Toyota a racionalizar ao máximo o uso delas. Assim, o

Lean não é por si só um processo ou metodologia, ele é uma sabedoria de vida e

uma maneira de olhar para o mundo, tornando-se uma verdadeira corrente de

pensamento e, segundo Maglyas, Nikula e Smoleander(2012) a filosofia Lean

sugere que se concentrem em um conjunto de princípios/maneiras de pensar, que

aumentam a eficiência e a eficácia.

Para Maglyas, Nikula e Smoleander(2012), a filosofia Lean é composta por 5

princípios fundamentais a saber:

Princípio Descrição

Valor agregado A proposta principal de cada produto ou serviço é fornecer valor

 26

adicional para o cliente. A identificação do valor de um produto, para

um cliente específico, está ligado firmemente com a visão e a

estratégia do desenvolvimento do produto. Este é o primeiro conceito,

que também é o entendimento da razão da empresa existir no

mercado.

Identificação do valor agregado do produto, é necessário estabelecer a

sua cadeia de valor, que inclui o mapeamento de todos os passos

Cadeia de valor desde a concepção do produto até sua entrega. O objetivo desse

mapeamento é identificar e remover qualquer passo que não crie valor

ao produto.

Entender o valor através do processo de criação do produto e, para

alcançar esse objetivo o Lean sugere focar em todo processo de

criação do que trabalhar da maneira tradicional que foca em

Fluxo
departamentos isolados, organizando assim a cadeia produtiva para

que exista um fluxo contínuo evitando o enfileiramento, afim de reduzir

erros e a quantidade de recursos necessários.

Assim como o conceito de “just-in-time”, o cliente envia uma requisição

Sob-demanda de produto e a empresa o entrega rápido, satisfazendo a necessidade

do cliente.

Analisa-se todo o resultado e os planos para qualquer produção, afim

Perfeição
de identificar problemas e feedbacks para melhoria contínua.

Tabela 3.5.1 – Princípios Lean – Segundo Maglyas, Nikula e Smoleander(2012)

3.5.1 Continuar a melhorar

Asfg
 27

3.5.2 xxxxxx

xxxxxx

3.6 xxxxx

3.6.1 xxxxxx

xxxxxx
 28

4. APLICAÇÃO PRÁTICA DO CONCEITO DA PESQUISA

Os conceitos pesquisados neste trabalho poderão ser usados para dois fins

principais, o primeiro é servir como base para futuros trabalhos acadêmicos

relacionados aos temas pesquisados e, o segundo é servir como base para a

implementação dos conceitos pesquisados em empresas ou no relacionamento

inter-empresas de desenvolvimento de software e seus clientes.

Existem diversos benefícios na utilização dos conceitos aqui pesquisados e, o

principal deles é a diminuição do “time-to-market”, ou seja, o tempo que uma

empresa leva para idealizar um novo produto e colocá-lo no mercado. Esse

benefício vem na agilidade da empresa em responder mais rápido às mudanças do

mercado, podendo assim ter uma vantagem diante as concorrentes.

Outros beneficios colaterais são a mitigação de problemas ocasionados pela

alta-rotatividade de profissionais, que é muito comum no mercado de trabalho, já que

eles conduzem o desenvolvimento de software em quatro mãos, difundindo assim o

conhecimento.

Também podemos entender que outro benefício é a retenção de pessoas,

desestimulando a alta-rotatividade, já que em todos os conceitos pesquisados as

pessoas tem a oportunidade de trabalhar em diversas partes de um projeto, o que,

em muitos, pode representar uma forma de desenvolvimento profissional anti-

estagnação.

4.1 Base para trabalhos acadêmicos futuros

Pesquisadores de desenvolvimento de software poderão se valer da

qualidade da bibliografia e dos conceitos aqui utilizados para nortear suas

pesquisas.
 29

4.2 Implementação dos conceitos em empresas

Dada a tríade básica, pessoas, processos e contratos que, direcionam o

desenvolvimento de software diratamente em organizações ou em empresas

terceirizadas por essas organizações, este trabalho pretende ser o ponto de partida

para empresas que desejem preparar estratégias que influenciem a tríade citada,

afim adotar os conceitos abordados nesse trabalho.

4.2.1 Pessoas

O ponto comum para a implementação de príncipios ágeis e do pensamento

Lean são as pessoas. Geralmente em empresas é comum ouvir questionamentos de

pessoas como os a seguir: “qual é a metodologia de desenvolvimento de software

utilizada aqui?” ou “se não houver uma metodologia de desenvolvimento de

software, sempre teremos problemas”.

É abordado aqui, os modelos de pensamento relacionados á desenvolvimento

de software ágil e Lean, o que contrapõe quando é citado o desenvolvimento de

software como metodologia, já que isso denota um processo, ou simplesmente um

caminho a ser seguido, com uma definição clara de resultados. O processo de

produção de um software, conforme indicado na bibliografia pesquisada, pode sofrer

mudanças constantes, que variam conforme seus requisitos e necessidades

específicas.

Sendo assim, empresas interessadas em implementar práticas e

pensamentos de desenvolvimento descritos neste trabalho deverão, primeiramente,

focar seus esforços mais em pessoas menos que em processos de desenvolvimento

 30

de software, afim de criar uma transição cultural e através de workshops e exemplos

partidos de superiores hierárquicos alcançar esse objetivo.

4.2.2 Processos

Nota-se que nos conceitos pesquisados existe pouca ênfase em processos

bem definidos, já que esses conceitos consideram que cada produto de software

pode passar por processos de desenvolvimento diferentes, muitas vezes inéditos.

Os conceitos acreditam que o software não é obra acabada, ou seja, ele

nunca está definitivamente pronto, crescendo a cada novo requisito que é

acrescentado a ele, sendo o software, em ambientes corporativos, volátil, oscilando

conforme vo movimento do mercado.

Então, uma empresa que, prende adotar os conceitos discutidos aqui,

precisará de maneira crítica rever todos os teus processos de desenvolvimento de

software, excluíndo todos aqueles passos e documentos que não agreguem valor ao

software.

Em primeira instância, pode ser que passos importantes sejam retirados,

entretanto, dentro dos conceitos pesquisados, existe a flexibilidade também se se

agregar novamente passos que foram tomados como inadequados na primeira

revisão, assim também como ele é flexivel para agregar outros procedimentos que

jamais foram utilizados.

4.2.3 Contratos

Em todos os conceitos pesquisados, os contratos parecem ser mais

importantes que processos, para que haja engajamento entre todas as organizações

envolvidas. Utilizamos organizações, pois todos os conceitos pesquisados podem

 31

ser utilizados diretamente por uma empresa que tenha uma área de

desenvolvimentos de sistemas que suporte seus negócios ou tenha uma empresa

terceirizada que faça esse suporte.

Nos contratos, segundo os conceitos utilizados, é resaltada a importância de

cláusulas que regulamentem a performance das organizações envolvidas, tendo

como base bonificações e penalidades para o cumprimento de metas, como por

exemplo o atraso ou antecipação de entregas, além de serem cláusulas auto-

ajustável, para garantir assim um processo de melhoria continua.

Contratos entre organizações para desenvolvimento de software também

regulamentão as questões de produção de conhecimento, principalmente quando as

equipes utilizam os príncipios Lean e ágeis, já que isso acaba por si criandos novos

conhecimentos para a organização cliente.

 32

5. CONSIDERAÇÕES FINAIS

xxxx

xxxx
 33

GLOSSÁRIO

Anti-skimming – dispositivo eletrônico, utilizado nos ATMs, cuja finalidade é evitar a

substituição do leitor de cartão magnético original por outro, que lê e armazena os
dados, possibilitando fraudes originadas a partir da clonagem de cartões com tarja
magnética.

ATM – Automatic Teller Machine - Terminal de auto-atendimento

As built – documento que incorpora as modificações realizadas sobre o projeto

original, durante a implementação deste.

Brainstorming – técnica de dinâmica de grupo para geração de idéias, que difere das
outras por não exigir que estas, primariamente, tenham compatibilidade racional com
o problema em estudo.
 34

REFERÊNCIAS BIBLIOGRÁFICAS

- Cesar Gon da CI&T - The Software Factory Model Doesn't Work Anymore -
na Brasscom Global IT Forum, November 3, 4 - 2011 - São Paulo, SP.
- Atul Vashistha, CEO of Neo Advisory - Brazil's 'Anti-Factory' Model - -
na Brasscom Global IT Forum, November 3, 4 - 2011 - São Paulo, SP.

BETTI, Sandra. “Formando equipes de alta performance”; ENDEAVOR - Brasil.

Disponível em: <www.endeavor.org.br/endeavor_mag/gente-
gestao/produtividade/equipes-de-alta-performance-como-chegar-la>. (Acessado em:
15/05/2013).

FLUSSER, Vilém. O Mundo Codificado. São Paulo. Cosac Naify, 2007.

KOCH, Alan S.. Agile Software Development: Evaluating the Methods for Your
Organization, Boston, Artech House, 2005.

GREENFIELD, J.. SHORT, K.. Software Factories: Assembling Applications with

Patterns, Models, Frameworks and Tools. John Wiley & Sons. ©
2004. Books24x7. Disponível em
<http://common.books24x7.com/toc.aspx?bookid=9155> (Acessado em:
15/05/2013).

MORGAN, James. M.. LIKER, Jeffrey K.. The Toyota Product Development
System: Integrating People, Process, and Technology. Productivity Press , 2006.
Books24x7. Disponível em <http://common.books24x7.com/toc.aspx?bookid=14459>
(Acessado em: 15/05/2013).

OSIAS, Claudio de Souza. FÁBRICA DE SOFTWARE: um estudo de caso na

Dataprev, sob a ótica da estrutura organizacional. 2008. 155 f. Dissertação
(Mestrado em Administração Pública) – Fundação Getúlio Vargas, Rio de Janeiro,
2008.

DODDER, R.. DARE, R.. Complex Adaptive Systems and Complexity Theory:
Inter-related Knowledge Domains, ESD.83: Research Seminar in Engineering
Systems, Massachusetts Institute of Technology, October 31, 2000.

POPPENDIECK, Mary. “Principles of Lean Thinking”; leanessays - EUA.

Disponível em: <http://www.leanessays.com/2002/11/principles-of-lean-
thinking.html>. (Acessado em: 15/05/2013).

QUINTELLA, Heitor L. M. M.. ALMEIDA, José L. I.. Fábrica de Software: análise do

impacto na competitividade. In: III SEGeT – Simpósio de Excelência em Gestão e
Tecnologia, 3º, 2006, Resende. Anais. Resende: Associação Educacional Dom
Bosco, 2006. “página 1 – página 13”.
 35

SOUSA, C. L.. SOUZA, J. G.. Metodologia de Desenvolvimento de Software para

a Fábrica de Software do CEULP/ULBRA. In: ENCONTRO DE COMPUTAÇÃO E
INFORMÁTICA DO TOCANTINS, 14., 2012, Palmas. Anais... Palmas:
CEULP/ULBRA, 2012. p. 122-130. Disponível em <http://ulbra-
to.br/encoinfo/artigos/2012/Metodologia_de_Desenvolvimento_de_Software_para_a
_ Fabrica_de_Software_do_CEULP_ULBRA.pdf> (Acessado em: 15/05/2013).

WILLIAMS, Laurie. “What agile teams think of agile principles”. Communications

of the ACM. Volume 55, Nº 4, 2012. “página 71 – página 76”.

WILLIAMS, Laurie. BROWN, G.. MELTZER, A.., NAGAPPAN, N.. “Scrum +

Engineering Practices: Experiences of Three Microsoft Teams”. IEEE, Nº 978-0-
7695-4604-9, 2011. “página 463– página 471”.

KELLY, Allan. Changing Software Development: Learning to Become Agile. John

Wiley & Sons(EN). 2008. Books24x7. Disponível em
<http://common.books24x7.com/toc.aspx?bookid=24285>(Acessado em:
15/05/2013).

LIKER, Jeffrey K.. “The Toyota Way: 14 Management Principles from the World's
Greatest Manufacturer”. McGraw-Hill. © 2004. Books24x7.
<http://common.books24x7.com/toc.aspx?bookid=7105> (Acessado em:
15/05/2013).

EBERT, C.. ABRAHAMSSON, P.. OZA, N.. “Lean Software Development”. IEEE
Software, Nº 0740-7459, Setembro/Outubro, 2012. “página 22 – página 25”.

POPPENDIECK, Mary. CUSUMANO, M. A.. “Lean Software Development: A

Tutorial” . IEEE Software, Nº 0740-7459, Setembro/Outubro, 2012. “página 16 –
página 32”.

MAGLYAS, A.. NIKULA, U.. SMOLANDER, K.. “Lean Solutions to Software

Product Management Problems” . IEEE Software, Nº 0740-7459,
Setembro/Outubro, 2012. “página 40 – página 46”.

HIGHSMITH, Jim.. “What Is Agile Software Development?” . The Journal of

Defense Software Engineering, Nº 4, Volume 15, 2002. “página 4 – página 9”.

CUSUMANO, M. A.. “The Software Factory: A Historical Interpretation” . IEEE,

Nº 0740-7459, Março, 1989. “página 23 – página 30”.

WANG, X.. CONBOYB, K.. CAWLEYC, O.. “’Leagile’ software development: An

experience report analysis of the application of lean approaches in agile
software development”, Journal of Systems and Software, Nº 6, Junho, 2012,
“página 1287 – página 1299”.

ROCKWELL, R.. GERA, M. H.. “The Eureka Software Factory CoRe: A

Conceptual Reference Model for Software Factories”. IEEE, Nº 0-8186-4460,
1993. “página 80 – página 93”.
 36

AMBLER, S. W.. “Scaling Agile Software Development Through Lean

Governance”. IEEE, Nº 978-1-4244-3736-8, 2009. “página 1 – página 1”.

CRAWFOR, B.. BARRA, L.. SOTO, R.. MONFROY, E.. “Agile Software
Engineering as CreativeWork”. Cooperative and Human Aspects of Software
Engineering (CHASE) - 2012 5th International Workshop on, 5ª edição, 2012,
Zurique. “página 20 – página 26”.

BARNES, A.. DWGHT, Z.. “Laboratory Driven, Lean-to-Adaptive Prototyping in

Parallel for Web Software Project Identification and Application Development in
Health Science Research”. Journal of Software Engineering and Applications, Nº
Nº 5, 2012. “página 62 – página 68”.

CHOWDHURY, A. F.. HUDA, M. N.. “Comparison between Adaptive Software

Development and Feature Driven Development”. IEEE, Nº 978-1-4577-1587-7,
2011. “página 363 – página 367”.

SMITH, S.. STOECKLIN, S.. “What we can learn from extreme programming”.
Journal of Computing Sciences in Colleges, Volume 17, 2a Edição, 2001. “página
144 – página 151”.

BECH, K.. “Embracing change with extreme programming”. Computer

Magazine, Volume 32, 10a Edição, Outubro/1999. “página 70 – página 77”.

HAZZAN, O.. DUBINSKY, Y.. “A Cognitive Perspective on Software

Development Methods: The Case of Extreme Programming”. In: International
Conference on Software Engineering, 28º, 2006, Shangai.. “página 53 – página 56”.

ANDERSON, D. J.. “Feature-Driven Development: towards a TOC, Lean and Six

Sigma solution for software engineering”. In: TOC ICO World Conference,
Outubro/2004.

PANG, J.. BLAIR, L.. “Refining Feature Driven Development - A methodology for
early aspects”. In: Early Aspects: Aspect-Oriented Requirements Engineering and
Architecture Design, Março/2004, Lancaster, RU. “página 86 – página 91”.

SRINIVASAN, J.. LUNDQVIST, K.. "Using Agile Methods in Software Product

Development: A Case Study". In: International Conference on Software
Engineering: New Generations, 6º, 2009, Las Vegas. “página 1415 – página 1420”.

CORAM, M.. BOHNER, S.. "The Impact of Agile Methods on Software Project
Management". In: Proceedings of the 12th IEEE International Conference and
Workshops on the Engineering of Computer-Based Systems (ECBS’05).