ESTUDO, SÍNTESE E ANÁLISE DE VIABILIDADE DE

CONTRATOS ÁGEIS PARA O DESENVOLVIMENTO DE

SOFTWARE

Christian Rogério Câmara de Abreu 1, Pablo Schoeffel

2

Universidade do Estado de Santa Catarina crca.com@gmail.com

1, pablo.schoeffel@udesc.br

2

Resumo

Os métodos ágeis (MA) sugerem uma cultura diferente nas empresas que os utilizam, pois

trazem a colaboração dos clientes acima da negociação dos contratos e agilidade em responder a

mudanças além do plano pré-estabelecido. Contudo, mesmo com diversos benefícios é

necessário um bom planejamento para que não surjam problemas, como falta de um cronograma

inicial ou ainda problemas legais ocasionados pela falta de um contrato bem escrito, entre outros.

Existem diversas formas de contratação ágil, dentre as quais se destacam as técnicas de “Tempo

e Materiais (T&M)”, “Desenvolvimento Faseado”, entre outras, e, com este portfólio, uma

empresa com pouca experiência pode ter dificuldade ao fornecer ou adquirir serviços de software

utilizando MA, pois é imprescindível conhecer um compêndio de várias técnicas, métricas e

formas de contratação e saber compilá-las para então escolher qual melhor atende às suas

necessidades. Tendo em vista as ideias expostas anteriormente, percebe-se a complexidade da

contratação de serviços com MA e este trabalho apresenta uma compilação de técnicas e tipos

contratação ágil, propõe uma nova técnica baseada nas características não suportadas pelas

formas já existentes e sugere a criação de uma ferramenta para auxiliar a tomada de decisão da

escolha do melhor tipo de contrato ágil para os gerentes de projeto (GP) de software.

Palavras-chave: Contratos de software. Métodos ágeis. Contrato Ágil.

Abstract

Agile methods (MA) suggest a different culture in the companies that use them as they bring

customer collaboration over contract negotiation, and agility in answering to changes beyond

established plan. However, even with many benefits a good planning so that problems such as

lack of an initial Schedule or legal problems caused by the lack of a written addendum does not

arise among others is necessary. The market are various forms of agile contracts, among which

stand out the techniques of "Time and Materials (T&M)", "Development Phased" among others,

and with this portfolio, a company with little experience may have difficulty in supplying or

acquiring software services using MA as it is essential to know a compendium of various

techniques, metrics and forms of contracts and know then compile them to choose which best

suits your needs. Given the ideas outlined above, one realizes the complexity of contracting

services with MA and this paper presents a compilation of techniques and types agile hiring,

proposes a new technique based on not supported by existing features and suggests ways to

create a tool to aid decision making of choosing the best type of contract for agile project

managers software.

Keywords: Software Contracts. Agile Methods. Agile Contract.

1. Introdução

Os dados apresentados em Version One (2012, p. 3) mostram que, durante o ano de 2011, 84%

das empresas pesquisadas praticaram desenvolvimento ágil e isso representa um crescimento de

80% se comparado os dados de 2010. Aprofundando a análise, 83% delas ainda declararam que

planejam usar MA em seus projetos futuros, mesmo sabendo que 12% das falhas ocorridas em

projetos ágeis ocorreram por filosofias ou culturas da empresa divergentes dos princípios dos

valores ágeis centrais. Conforme Chiavenato (2008, p. 224), a cultura organizacional é um

padrão de assuntos básicos compartilhados dentro de algumas empresas composto de hábitos,

crenças, normas, valores atitudes e expectativas compartilhados por todos os membros, que

distingue a organização das demais.

Segundo Beck et al. (2001), ao usar MA é ideal a colaboração com o cliente mais que

negociação de contratos. Porém, segundo Rij (2012, p. 2), usar acordos mal elaborados podem

gerar uma desconexão entre as expectativas do cliente e do produto desenvolvido, o que tende a

acabar mal. Com tudo isso, o mais importante é que todas as dúvidas e expectativas do cliente

sejam sanadas já na fase de contratação, para que se possa obter o acordo adequado e satisfatório

a todas as partes envolvidas.

Segundo Arbogast et al. (2012, p. 40) é importante advogados compreenderem MA para que

adotem estas práticas no dia a dia das empresas fabricantes de software e para que evitem a

quebra de confiança e a perda da colaboração dos clientes nos projetos com contratos ágeis,

gerando, assim, contratos livres de vícios.

Dentre as obras que abordam a contratação ágil podemos citar Opelt et al. (2013) que

descreve alguns contratos ágeis e relatos das experiências do autor em times de desenvolvimento

de software, há também a última versão do guia PMBOK (PMI, 2013) que descreve pela

primeira vez a certificação PMI-Agile e cita alguns contratos que podem ser utilizados com MA.

Em uma pesquisa rápida em sites de consulta de trabalhos científicos, foi consultado o termo

"Agile contracts", em Janeiro de 2014, no Google Acadêmico (2014) foram encontradas apenas

85 resultados, no site ACM Digital Libray (2014) 9 resultados, e em IEEE Xplore Digital

Library (2014) apenas três obras, assim esse é um assunto emergente e carente de

aprofundamento.

Desta forma, este trabalho faz um estudo dos tipos de contratação ágil existentes, mostrando

exemplos práticos; propõe uma nova técnica de contratação ágil baseada nas abordadas nesta

obra e descreve uma ferramenta que visa auxiliar a escolha de contratos ágeis e ao final

demonstra uma ferramenta em Android.

Este artigo está estruturado da seguinte forma: na seção 2 e 3 são contextualizados os assuntos

relacionados aos MA e contratação ágil; na seção 4 são descritos trabalhos correlatos; na seção 5

e 6 é proposta uma nova técnica de contratação ágil e comparada a outras; a seção 7 apresenta

uma ferramenta para ajudar escolha do tipo de contrato ágil e, por fim, as considerações finais.

2. Métodos Ágeis e Contratos Ágeis

Processos ágeis priorizam mudanças para entregar ao cliente um produto diferenciado dos

concorrentes e, para isto, os analistas de negócios e desenvolvedores devem trabalhar juntos

durante todo o projeto.

Conforme Beck et al. (2001), em 2001 numa reunião em uma estação de esqui os

membros da The Agile Alliance criaram o Manifesto Ágil, que defende a prioridade em satisfazer

melhor as pessoas e o produto, onde mudanças nos requisitos são bem-vindas, mesmo que

tardiamente.

Segundo Lapham et al. (2011, p. 1) uma equipe de desenvolvimento de software que usa MA

é uma equipe multifuncional auto-organizável, onde os requisitos são expressos como histórias

de usuários (descrição dos itens de trabalho), que devem ser finalizados dentro de um período de

2 a 4 semanas e este espaço de tempo é um ciclo chamado de Sprint.

Conforme Rico et al. (2009, p. 1) existem quatro valores fundamentais em métodos ágeis, que

são a colaboração do cliente, o trabalho em equipe, o desenvolvimento cíclico e a adaptabilidade.

Alguns dos diversos tipos de metodologias utilizadas são Extreme Programming, Scrum,

Dynamic Systems Development, Feature Driven Development, Crystal Methods. Segundo

National IT and Telecom Agency (2010, p. 10) em um projeto de desenvolvimento de software

no qual se utilize MA o fornecedor não deverá incluir na sua proposta uma descrição real da

solução, pois o objeto de uma contratação ágil difere significativamente de contratos

tradicionais.

Conforme Poppendieck e Poppendieck (2003, p. 161) o uso de MA parece interessante para

as empresas, mas muitas não entendem como aplicar em seus contratos. Sem dúvida, o maior

obstáculo ao uso de práticas ágeis é a linha nítida que separa os interesses de fornecedores e

clientes, pois cada um tende a olhar para seus próprios interesses. Tendo em vista isso, parece

que a única abordagem segura é escrever um contrato incontestável e invulnerável, porque as

pessoas se deslocam para novos postos de trabalho, as regras mudam.

De acordo com Leybourn (2013, p. 18) nos MA valoriza-se a colaboração do cliente sobre

negociação de contratos. Porém, os acordos ainda são importantes, pois o cliente deve ser tratado

com um parceiro, e não como um adversário. Neste contexto, existem os contratos ágeis que tem

o objetivo de facilitar, em vez de apenas proteger as partes.

Conforme Sorsa (2011, p. 199) o contrato ágil é um modelo que descreve o projeto e seus

ciclos num processo ágil, não é uma declaração detalhada do trabalho, como é o caso dos

tradicionais (tal como os softwares desenvolvidos no “Ciclo de vida em Cascata").

2.1 Scrum

Segundo Schwaber (2009, p. 3) uma metodologia ágil bem conhecida é o Scrum, que é utilizada

para o gerenciamento de projetos de desenvolvimento de software, sendo um framework

(conjunto de conceitos usado para resolver um problema de um domínio específico) que tem

diversos processos e técnicas adaptáveis. Seu papel é fazer transparecer a eficácia relativa das

suas práticas de desenvolvimento para que as partes possam melhorá-las, enquanto provê um

framework dentro do qual um produto complexo pode ser desenvolvido. O Scrum usa o ciclo

iterativo e incremental, que visa aperfeiçoar a previsibilidade das entregas.

Conforme Moreira (2013, p. 51) uma equipe de profissionais que trabalha dentro das regras

do Scrum é chamado de Scrum Team (Time Scrum), que é auto-organizável, os membros

sentem-se com poder de tomar decisões e proprietários de seu trabalho. O time Scrum é

composto dos seguintes papéis: Scrum Master – motivador do Scrum garante que as regras estão

sendo seguidas, é um facilitador; Product Owner (PO) representa o cliente, responsável primário

do Product Backlog (PB) - é repositório de histórias não implementadas; Time de

Desenvolvimento – grupo de engenheiros que criam as funcionalidades no produto de software.

De acordo com Pichler (2011, p. 57) no PB são descritas as histórias de usuário (User Story).

Estas podem conter nome, breve narração, critérios de aceitação, condições que precisam ser

verdadeiras para que ela esteja completa; pode ser abrangente ou detalhada. O PB pode conter

outros artefatos úteis como resumos de usuário, planilhas, esboços de protótipos de interface do

usuário, diagramas de fluxo de navegação entre as ações. Nas próximas seções veremos itens que

afetam a escolha de funcionalidades a ser desenvolvidas para obter um produto de software e em

seguida traz vários tipos de contratos que são indicados para MA.

2.2 Métricas para priorização de histórias de usuário para MA

De acordo com Rico et al. (2009, p. 101) a métrica Return on investment (tradução livre -

Retorno sobre o Investimento) (ROI) é de uso comum em negócios que apliquem MA para

criação de novos produtos de software. O ROI usa dos custos e benefícios para determinar o

valor do negócio, vide a Figura 1. Como exemplo, caso um projeto traga um milhão de dólares

de benefícios e tenha custos de 100 mil dólares, então o cálculo seria (US$1.000.000 –

US$100.000 x 100% = 900%). Assim, neste caso o fabricante de software obteve 900% de ROI. ROI = Benefícios – Custo x 100%

Custo Figura 1: Fórmula para calcular o ROI (RICO et al., 2009)

Os programadores devem ser direcionados a implementar primeiramente as funções com

maior valor agregado, ou seja, High Value First (tradução livre - primeiro maior valor agregado)

(HVF).

Conforme Bergin (2005), vide exemplo da Figura 2, se as histórias forem ordenadas pelo

HVF, é interessante com o passar do tempo não implementá-las todas, por gerarem menor lucro.

Neste caso, é sugerido que ao implementar 20% delas o projeto seja finalizado, pois 80% do ROI

do negócio foi alcançado. Entretanto a maioria dos programadores desenvolve na forma top-

down (das funcionalidades mais básicas para as mais complexas) e esta não é uma boa orientação

para o negócio, visto que se pode gastar muito tempo e dinheiro com algumas que dão pouco

retorno. Para Sutherland (2008, p. 24) o HVF e o ROI também são úteis na contratação “Changes

for free, Money for Nothing”, que é descrito em tópico abaixo nesta obra.

Figura 2 – 80% do ROI se obtém de 20% das funcionalidades do software (Adaptado de BERGIN, 2005)

3. Formas de contratos ágeis

Conforme Bombosch et al. (2010, p. 226) a abordagem de desenvolvimento de software ágil dá

aos compradores do produto uma alta flexibilidade na mudança das funcionalidades e de mudar

suas prioridades. Há vários modelos de contrato ágil e cada um com seu foco. No entanto, o

desafio é escolher um modelo de contrato que não comprometa a flexibilidade ágil.

Nos itens abaixo são descritos alguns contratos ágeis, suas características e exemplos práticos

de utilização.

3.1. Preço Fixo e escopo fixo (PFEF)

Conforme PMI (2013, p. 362), o contrato PFEF define um preço total fixo para um produto

definido, serviço ou resultado a ser fornecido. Neste acordo vendedores são legalmente

obrigados a concluir tais contratos, com possíveis prejuízos financeiros se não o fizerem, assim

os compradores devem especificar precisamente o produto ou serviço. Mudanças no escopo

geralmente geram aumento no preço final do contrato.

Segundo Opelt et al. (2013, p. 34), é focado na cooperação entre cliente e fornecedor de

software através da combinação de princípios de MA que tratam da colaboração e flexibilidade

0

200

400

600

800

1000

Tempo

Histórias do Projeto

20% das Histórias

na concepção das histórias. Neste contrato, o fornecedor, para a sua segurança financeira, aplica

o preço máximo na contratação e o escopo é dividido em Sprints, com base no Backlog inicial,

onde as histórias não precisam estar totalmente detalhadas. O elemento chave deste pacto

comercial é o preço máximo estimado para um projeto de software, que deve visar que a receita

atenda ao escopo do projeto.

3.2. Tempo e Materiais (T&M)

Conforme PMI (2013, p. 364) os contratos de T&M (também chamados de “cost-plus

agreements”), são utilizados para viabilizar a contratação de outros especialistas e apoio externo,

o que permite deixar em aberto a possibilidade de um aumento de custos para o comprador do

software. O valor total do acordo e a quantidade exata de itens a serem entregues não são

definidos pelo comprador no momento da assinatura do contrato inicial, para que seja possível

aumentá-lo depois. Muitas organizações exigem não exceder o teto de custo e prazos propostos

no contrato, para evitar o crescimento dos custos de forma ilimitada. O contrato T&M deve

conter preços unitários determinados por parâmetros sobre a unidade de trabalho; material; taxas;

categorias; recursos específicos, tais como especialista em Engenharia de Software e as taxas

especificadas por hora, ou categorias de materiais e as taxas especificadas por unidade.

Segundo Bullen et al. (2010, p. 113) a contratação de software do tipo T&M é usada quando o

fabricante é pago por custos atuais mais um lucro pré-determinado, com base em um valor fixo

ou em percentual. A principal vantagem deste tipo de acordo é que o cliente tem visibilidade

imediata sobre custos e detalhes da sua composição.

Microsoft (2012) cita um exemplo, vide Figura 3, de uma organização que oferece serviços de

desenvolvimento de software via T&M, nos quais fornece cinco consultores técnicos para

trabalhar em um projeto de desenvolvimento de software para um cliente pelos próximos seis

meses. O cliente concorda em pagar US$150 por cada hora de consultoria lançada no projeto. A

organização concorda em enviar uma fatura para o cliente no final de cada mês pelas horas

lançadas para o projeto no período. Por exemplo, no final do “Mês 1” o fornecedor receberá

US$132.000 (5 consultores x 22 dias úteis x 8 horas dia x $150), conforme os meses vão

passando o montante de receita e lucro tem uma crescente de progressão aritmética, fazendo o

gráfico da receita ser uma linha reta crescente e o lucro também, sendo este uma reta paralela

menor que a de receita.

Figura 3 – Contrato por tempo e materiais (Adaptado de STEVENS, 2009)

Para Opelt et al. (2013, p. 256) é relevante um contrato T&M possuir cláusulas tais como:

preços fixos por dia conforme o nível de experiência do recurso necessário; lista de funcionários

aprovados pelo cliente; cláusula que implica o cliente aceitar as trocas que o fornecedor escolhe,

com exceção se desejar um funcionário com melhor desempenho, com um prazo de

transferência; oferecer descontos baseado no volume de compras; deverá conter condições de

faturamento, de acordo com as planilhas que o cliente solicitou.

0

200000

400000

600000

800000

1000000

Mês 1 Mês 2 Mês 3 Mês 4 Mês 5 Mês 6

Receita

Lucro

3.3. Tempo e Materiais com escopo fixo e um teto de custos (T&MEFTC)

Ainda na visão de Bullen et al. (2010, p. 113), neste tipo de contratação, caso o fornecedor

consiga finalizar o projeto de software antes do prazo final, haverá menos custos ao cliente, que

ficará satisfeito por economizar dinheiro. Para o fornecedor, vide Figura 4, o ideal é entregar o

software exatamente no prazo, pois pode aproveitar a margem de lucro e não ter perdas pelo

estouro de prazo.

Figura 4 – Contrato por T&M com escopo fixo e teto de custo (Adaptado de STEVENS, 2009)

Segundo ASBCA (2000, p. 1), um exemplo ocorreu com a empresa Corbett Technology

Company Inc., que fez um contrato T&M com o governo dos EUA, mas não criou uma cláusula

de teto de custos, o que a obrigou a cobrir os custos extras. A empresa recorreu e apresentou ao

fórum ASBCA uma moção para reconsiderar o reembolso dos custos excedentes, onde alegou

defeito em equipamentos do governo e que ele agiu de má-fé por uma ordem de aceleração,

porém foi negado pela justiça que se baseou na falta de uma cláusula contratual que deveria

submeter o governo a cobrir o preço máximo do teto de custos. Ou seja, um contrato

T&MEFTC, vide Figura 4, poderia ter evitado tantas perdas ao atingir o custo máximo para a

referida companhia. Conforme PMI (2013, p. 363) uma empresa de software pode definir o teto

de custos para definir os valores que o cliente deverá pagar em caso o estouro de prazo.

3.4. Contrato por Tempo e Materiais com Escopo variável e Teto de Custo

(T&MEVTC)

De acordo com Opelt et al. (2013, p. 35) os projetos com escopo variável não tem uma precisão

do preço do valor acordado. Na prática, geralmente esta contratação é uma combinação do

acordo de preço fixo com os demais itens variáveis.

Bullen et al. (2010, p. 113) nos mostra que o acordo T&MEVTC pode aumentar o risco para o

cliente quando o orçamento está próximo a ser alcançado sem que o trabalho esteja próximo de

ser concluído, dado este que é visualizado na Figura 5. No entanto, esta contratação prevê uma

relação mais flexível entre o cliente e o fornecedor, incentivando-os a trabalhar de forma

cooperativa para alcançar mudanças de escopo dentro do cronograma. Conforme Stevens (2009,

p. 23) se o projeto atingir o teto de custo então deverá se comportar como um contrato de preço

fixo.

0

10000

20000

30000

40000

Mês 1 Mês 2 Prazo Entrega Estouro Prazo

Lucro

Teto de Custos

Receita

Figura 5 – Contrato por T&M com escopo variável e teto de custo (Adaptado de STEVENS, 2009)

3.5. Money for nothing, changes for free (MNCF)

Sutherland (2008, p.24) descreve a contratação Changes for Free como a que toma por base um

contrato de T&M, vide Figura 6, podendo o cliente, desta forma, trocar histórias não

implementadas por outras novas que tenham mesmo custo. Vide exemplo hipotético no qual o

cliente trocou a “História A” por uma história nova de mesmo custo, esta mudança é registrada

em um adendo contratual escrito e não há despesas para o cliente.

Figura 6 – Contrato MNCF (Adaptado de SUTHERLAND, 2008)

Conforme Santos (2011, p. 303) a cláusula Money for Nothing (dinheiro para nada) indica que

há uma taxa caso ocorrer a rescisão antecipada de contrato. Vide Figura 6, o cliente prioriza 100

histórias pelo HVF1 e opta por uma conclusão mais cedo do projeto no momento em que a falta

apenas 20% (20 histórias pendentes) para o fim do projeto. Neste caso o fornecedor é pago sobre

estes 20% remanescentes e o cliente finaliza o projeto com 80% do software concluído (80

histórias convertidas em código-fonte de software).

3.6. Contrato por Sprint (CS)

Segundo Zijdemans (2013, p. 41) neste tipo de contratação o pagamento de cada Sprint deve ter

um preço fixo e deve ser calculado de acordo com a velocidade de trabalho da equipe se as metas

forem alcançadas. É importante o contrato trazer cláusulas que descrevam desvio significativo de

1 HVF - High Value First - primeiro maior valor agregado. O cliente deve priorizar as histórias de usuário para a

equipe de desenvolvimento construir primeiro as essenciais;

0

10000

20000

30000

40000

50000

60000

Sprint 1 Sprint 2 Sprint 3 Sprint 4

Lucro

Teto de Custo

Receita

0

20

40

60

80

100

120

Tempo

Histórias Construídas

margem de 20%

Histórias não Construídas

História A

História A

horas trabalhadas, e, assim, se o ciclo for bem sucedido o fornecedor ganha um bônus e, caso

contrário, implica multa para ele.

Santos (2011, p. 303) relata que Centro de Operações da Agência Espacial Europeia utilizou

Scrum para um projeto com uma contratação estilo CS, que em papel era um contrato PFEF2. O

autor descreve como lição aprendida que o contrato deveria conter cláusulas para o uso de

Sprints, para definir a métrica de valor agregado entregue ao fim do Sprint e uma opção seria

utilizar o contrato MNCF para um próximo projeto similar, para melhorar a comunicação entre

cliente e fornecedor.

3.7. Desenvolvimento faseado (DF)

Segundo Bullen et al. (2010, p. 113) o acordo Phased Development divide o trabalho em fases,

com cada uma tendo seu próprio contrato de T&M, o que propicia limitar o risco do cliente para

um período de tempo individual.

Hayward (2000, p. 465) apresenta um estudo de caso hipotético onde uma empresa construirá

90 residências. Cada fase dura um ano e são construídas 30 casas, assim a duração total é de três

anos. Cada casa custa £85.000 para construir, mais uma taxa de £8.000 do governo. O

financiamento com o banco tem juros de 1,5% ao mês, assim são £85.000 * 0,18 (juros anuais),

que resulta £15.300 de juros, o montante de custo total é £15.300 + £85.000 + £8.000 que

resultam em £108.100. A empresa deseja um lucro de 10%, assim o preço mínimo para o imóvel

é de £119.130, que venderá por £150.000 para ter margem de segurança. Vide Figura 7, por fase

a receita é de £4.500.000 e o lucro é de £1.251.000. De forma similar uma empresa de software

pode definir as fases como anuais, que a cada marco aprovado pelo cliente são pagos fundos

adicionais ao fabricante.

Figura 7 – Contrato por fase (Adaptado de HAYWARD, 2000, p. 466)

3.8. Lucro fixo (LF)

Segundo Fitchett e Haslam (2003, p. 23) a contratação por LF contém mecanismos que fixam os

pagamentos caso ocorram atrasos no projeto. Dessa forma, estima-se o que trabalho restante e

seu lucro é reduzido numa porcentagem definida. Em casos extremos significa trabalhar a preço

de custo.

Conforme Berends (2004, p. 50), este contrato pode oferecer cláusulas de bônus e multas (é

exibido em tópico abaixo), que visam motivar a melhora do desempenho da equipe de

desenvolvimento de software.

2 PFEF – Contrato de Preço Fixo e escopo fixo.

0

1000000

2000000

3000000

4000000

5000000

Fase 1 Fase 2 Fase 3

Receita

Custo

Lucro

Figura 8 – Contrato por lucro fixo (Adaptado de STEVENS, 2009)

Como exemplo, vide a Figura 8, um projeto de desenvolvimento de software teve a sua

abertura com um marco de início; após a primeira iteração, ocorre o “Marco 1”, o fornecedor

teve uma receita de $5 mil, lucro de $2,5 mil dólares e ROI3 de 50%; no “Marco 2” o fornecedor

obteve uma receita de $10 mil dólares, lucro de $5 mil e ROI de 50%; porém o projeto atrasou,

não foi finalizada na data de entrega, logo a receita cobre apenas as despesas, onde a receita é

$18 mil, lucro de $7,6 mil dólares e o ROI cai para 42%.

3.9. Joint Ventures (JV)

Conforme Swaim (2011, p. 140) a JV é uma entidade formalizada com gestão própria, que é

formada de sócios numa aliança, onde todos os continuam com seus próprios entes empresariais.

As alianças permitem várias possibilidades de melhora, como redução de tempo, custo e risco.

Segundo Buxmann (2012, p. 115) o autor relata um estudo de caso real da empresa Software

AG e a iGate Global Solutions, as quais juntas criaram um setor de desenvolvimento de software

que agrega uma central de serviços, sob o nome Software AG Índia (SAG Índia). Uma das

principais vantagens da JV foi que SAG Índia tem profissionais de tecnologia qualificados pela

parceria com a iGATE, isso significava que a SAG podia se tornar operacional muito

rapidamente, assim a nova empresa foi constituída como uma sociedade anônima.

3.10. Cláusulas de Bônus e Multas (BM)

Segundo Marsh (2000, p. 134) as cláusulas de BM oferecem incentivos positivos (os bônus) e

negativos (as multas) para o fabricante reduzir o tempo de desenvolvimento. Em geral o bônus

estimula mais o fabricante que a ameaça de uma multa. Para calcular o valor do bônus e multa

deve-se considerar um esforço maior que o normal para atingir um objetivo.

Um exemplo hipotético de contrato PFEF com cláusulas BM é apresentado na Figura 9, onde

o projeto tem a receita de $10 mil, e o lucro final dependerá do prazo de entrega. Se o fornecedor

conseguir entregar o software antes da data de entrega pactuada haverá um bônus de dois mil

dólares. Baseado em Rich e Schmidt (2003, p. 197), pode-se notar uma semelhança de triângulos

da trigonometria, onde o mesmo ângulo da reta “Bônus” faz aumentar o lucro proporcionalmente

na reta “Bônus do Lucro”. Por outro lado, caso o projeto atrasar haverá “Multa”, que acarretará

em “Perda do Lucro”, devido ao estouro do prazo previsto na cláusula BM.

3 ROI - Return on investment - retorno sobre o investimento. Sua fórmula é: ROI = (Benefícios – Custo x

100%)/Custo.

0

5

10

15

20

Início Marco 1 Marco 2 Data Entrega Atrazo

Receita

Lucro

Figura 9 – Contrato com Bônus e Multas (Adaptado de STEVENS, 2009)

Em sua obra, Berends (2004, p. 85) traz um exemplo hipotético onde um cliente tem um

grande projeto de construção civil, que exige elevados padrões corporativos de segurança. Numa

região, a média de LTI (The Lost Time Injury – Incidente com Afastamento) para a indústria da

construção é de 4,0 LTI (quatro incidentes por 200.000 horas trabalhadas). O cliente contratará

fornecedores que tenham 2,0 LTI, com meta de 1,0 LTI. O fornecedor deverá receber um bônus

de 0,10 dólares por homem hora trabalhada para cada 0,1 que o LTI trimestral é inferior a 1,0. Se

o LTI é zero para o trimestre o fornecedor deverá receber um bônus adicional de $50.000.

Nenhum bônus é pago se houver uma fatalidade de um empregado ou subcontratado no canteiro

de obras durante o trimestre. O empreiteiro usa 400.000 horas de trabalho no trimestre e atinge

uma taxa de 0,8 LTI. Eles receberão um bônus de 400.000 X $0,10 X (1.0-0,8) / 0,1 = $80.000.

Caso o empreiteiro usar 600.000 horas de trabalho no trimestre, com um LTI de 1,2 e ocorrer

uma fatalidade então receberá uma multa de 600.000 X $0,10 X (1,2-1,0) / 0,1 + $100.000 =

220.000 dólares. Uma fabricante de software pode utilizar métricas de forma análoga para definir

BM.

3.11. Contrato Colaborativo Ágil

Thorup e Jensen (2009, p. 2) propõe em sua obra o Contrato Colaborativo Ágil. O objetivo é ter

um contrato que o risco é compartilhado de forma justa entre o cliente e o fornecedor. O

principal mecanismo é que o cliente paga as funcionalidades que recebeu (que é composta por

um conjunto de marcos), que se não forem alcançados então o pagamento é atrasado até ser

finalizado. Isto favorece o fabricante aumentar sua velocidade de desenvolvimento. O contrato

pode ser ajustado, para incluir novas funcionalidades, por meio de métricas e valores tal como é

usado em T&M4.

4. Trabalhos correlatos

Nos sites Google (2014), Google Acadêmico (2014), ACM Digital Libray (2014), e em IEEE

Xplore Digital Library (2014) foram pesquisados obras científicas correlatas a esta, para isto

utilizou-se o termo “agile contracts” (contratos ágeis), e nomes de contratos ágeis como “T&M”

(Tempo e Materiais) e outros. Também foram filtrados os trabalhos que trouxessem uma nova

técnica de contratação com MA ou ferramentas. No Google (2014) pesquisou-se por sistemas

4 T&M – Contrato de Tempo e Materiais.

-2

0

2

4

6

8

10

12

14

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Data de Entrega

Estouro de prazo

Lucro

Bônus

Receita

Multa

Bônus do Lucro

Perda do Lucro

para acordos de desenvolvimento de software, de preferência com metodologia ágil. Na

sequência é mostrada pesquisa bibliográfica e descritiva com objetivo de facilitar a compreensão

do leitor qual o foco desta obra, comparando-a a similares através de critérios-chave definidos

pelo autor.

Simplessus (2014) comercializa o software Simplessus Contracts, que permite fazer a gestão

de contratos do usuário, administrando compromissos, prazos, custos, receitas.

Em sua obra, Franklin (2008) descreve experiências práticas e contratações ágeis na sua

empresa e o relacionamento com seus clientes, onde foram citados os contratos T&M, PFEF e

híbrido de ambos. Ainda afirma que entre os principais fatores de sucesso em suas contratações

com MA é a criação de um novo contrato ágil próprio, o que permitiu a gestão da mudança de

escopo de software conforme a sua necessidade.

Thorup e Jensen (2009, p. 1) relatam experiências de contratação ágil e criaram um tipo de

contrato ágil chamado de Contrato Colaborativo Ágil. A obra apresenta análise dos contratos

ágeis PFEF, T&M e prazo determinado com preço fixo; uma versão nova de contrato

colaborativo que é proposta pelo autor. A obra indica os elementos necessários para um contrato

para MA que são escopo; preço por hora; cronograma dos marcos; processo de desenvolvimento

ágil a usar; prazo global e por Sprint. Os autores concluíram que a criação de um novo tipo de

contrato ágil permitiu um melhor relacionamento entre cliente e fornecedor. Contudo, ainda

assim, há muito a melhorar, pois geralmente é gasto dinheiro desnecessário devido a um mal

planejamento dos métodos, projetos e dos contratos ágeis. Dessa forma espera-se que isto

influencie o melhoramento destas práticas.

Na Tabela 1 são comparados os trabalhos mencionados e o presente trabalho, avaliando os

três objetivos desse trabalho como critérios de comparação. Simplessus

(2014)

Franklin

(2008)

Thorup e Jensen

(2009)

Esta

Obra

Método para Gestão de contratos X X X X

Comparação de contratos ágeis e nova

técnica

X X X

Ferramenta para auxiliar a escolha de

contrato ágil

X

Tabela 1 – Comparação dos trabalhos correlatos com esta proposta

5. Proposta de novo tipo de contratação ágil de software

Conforme Turban et al. (2008, p. 37), Charles Darwin, famoso cientista da natureza afirmou que:

“não é a espécie mais forte que sobrevive, nem a mais inteligente, mas a que melhor se adapta às

mudanças”. Da mesma forma, as organizações necessitam adaptar-se rapidamente. Devem

responder as oportunidades e transformar modelos, processos e demandas de mercado para

superar a concorrência.

Conforme relato de Faria (2013), a contratação da forma tradicional há muito tempo está

presente na humanidade, e a contratação para MA ainda é um campo pouco explorado e ainda

com algumas incógnitas. Tal situação ocorreu, com este autor, em seu trabalho como consultor

coaching (treinamento empresarial) num projeto para uma multinacional, que demorou um ano

até conseguir escrever um contrato ágil que satisfizesse as partes, para enfim fechar o negócio e

então iniciar o projeto. Desta forma, a contratação poderia ter sido mais rápida se as técnicas

para contratos ágeis estivessem mais bem estabelecidas e conceituadas, para serem aceitas no

mercado com facilidade.

Segundo a pesquisa de Chow e Cao (2008, p. 969) foram coletados dados de 109 projetos

ágeis de empresas de vários tamanhos, setores e localizações. Através da análise de regressão

múltipla (método estatístico para prever e validar observações com redução de erros), foram

identificados os seguintes fatores críticos para o sucesso: a) estratégia correta, b) prática

adequada das técnicas ágeis, c) uma equipe competente, d) um bom processo ágil de

gerenciamento de projeto, e) um ambiente de equipe amigável, f) forte envolvimento do cliente.

As várias formas de contratos ágeis descritas acima podem ser consideradas escassas caso

apenas uma delas for aplicada em sua forma original, ou seja, o planejamento da combinação das

técnicas poderá gerar um contrato mais adaptável. De acordo com os autores acima é

recomendado combinar uma técnica com outra, tal como visto em Berends (2004, p. 50), onde o

contrato de Lucro Fixo pode ter cláusulas de BM, ou em Sutherland (2008, p. 24) que afirma que

o contrato MNCF toma por base o T&M. Como ainda visto em Santos (2011, p. 303) onde o

contrato CS adapta-se de um PFEF com práticas ágeis.

Desta forma, os contratos ágeis estudados acima podem ser deficientes em três características,

que são: utilizar apenas uma técnica em sua forma pura; falta de uma técnica de contratação ágil

que indique o acordos mais adequados para marcos críticos no ciclo de vida de um projeto com

Scrum; dificuldade em escolher a técnica de contratação ágil para usar. Esta obra descreve uma

nova técnica de contrato ágil que propõe atender as duas primeiras deficiências e uma ferramenta

para a última, descrita em outro tópico abaixo. A nova técnica e a ferramenta visam diminuir os

problemas existentes com os contratos atuais e facilitar a escolha por parte dos envolvidos.

Baseado nos tipos de contratos ágeis descritos nas seções anteriores, em seus passos e

cláusulas e também no Scrum, este trabalho propõe um novo tipo de contratação ágil de software

chamado Contrato Ágil Adaptável para Scrum (CAAS), que é como um arcabouço (modelo que

pode ser alterado) de contrato. A abordagem inicia-se construindo um contrato PFEF, este é

chamado de Contrato Inicial (CI), que contém um PB (repositório) com histórias de usuário

priorizadas pelo HVF prontas para iniciar o desenvolvimento de imediato. O CI também deve

prever a inclusão de novas cláusulas (aditivos contratuais) para que a empresa possa adaptar o

desenvolvimento. Este é um ciclo de vida no qual há adendos contratuais para cada Sprint, sendo

que estes poderão assumir as possíveis formas de substituição de um conjunto de funcionalidades

por outro, ou ainda uma nova função que agrega acréscimo de T&M, desta forma o

desenvolvimento pode se assemelhar ao Contrato Faseado, pois limita o risco do cliente para o

Sprint.

Para esta nova forma de contração ágil as normas do CI são adaptáveis via adendos, assim o

projeto pode ser adaptado durante a sua execução visando atender as práticas recomendadas pelo

MA, porém com diferencial de ser formalizado, documentado e embasado pela lei para proteger

as partes. No CAAS (que pode ser visto no apêndice F) o CI deve conter os seguintes itens:

Similar ao contrato T&M, vide PMI (2013, p. 364), no CAAS o CI deve descrever

unidades, medidas e valores monetários relacionados, custo homem por hora, custo da

complexidade via Use Case Point (UCP) (técnica para medir tamanho do software);

Cada UCP e seu valor, com custo total do projeto, caso o cliente deseje acrescentar

novos itens ao escopo o fabricante poderá fornecer um orçamento das alterações e com

aprovação do cliente poderá aumentar o UCP total e o custo total do projeto via

adendos. O UCP traz uma visão macro do projeto total sem ter de calcula-lo como um

todo em detalhes menores. Uma opção ao seu uso é descrever as histórias por meio de

técnicas ágeis, como o Planning Poker (técnica para estimar tamanho de histórias de

usuário);

O CI poderá ter um teto de custos, similar ao contrato T&MEVTC, no qual permite

definir um valor máximo para o projeto a ser desenvolvido, o que limita as mudanças

do cliente. Que caso ultrapasse, o fabricante deverá ser reembolsado pelos custos

excedentes;

O contrato deve especificar que poderá haver adendos, com valores baseados neste CI,

mas que poderão variar de acordo com a inflação, situação econômica no país e

escopo do adendo, atendendo às peculiaridades de cada caso e para que haja equilíbrio

financeiro a todas as partes envolvidas;

São definidos os Sprints esperados para um produto, e, com isso já é possível iniciar o

desenvolvimento do projeto. Estas são as fases do processo de software e, ao final de

cada fase, é entregue um marco do projeto, que deve conter um conjunto de

funcionalidades para validação do cliente;

Similar às cláusulas de BM, o contrato pode oferecer bônus ao fabricante do software

se terminar mais cedo o projeto e uma multa caso atrasar;

Uma opção ao uso de cláusulas BM é o CI ter cláusulas de Lucro Fixo, onde apesar de

um atraso no projeto o cliente se compromete a manter uma margem mínima de lucro

para dar continuidade do negócio. O contrato pode coexistir com BM e Lucro Fixo,

para o fabricante focar em manter o prazo;

O CI pode conter cláusulas MNCF, o que implica que, caso o cliente opte por terminar

um projeto mais cedo, então ele deve pagar um valor percentual para o fabricante

mitigar esta perda não esperada. Como também trocar histórias formalmente.

Similar ao Contrato por Fases durante o desenvolvimento (vide apêndice F), ao finalizar o

Sprint o cliente validará as alterações assinando um documento chamado “Validação de Sprint”

e rubricando após cada UC/história implantada para confirmar o aceite. Cada aceite diminui o

total de pontos remanescentes do CI, e, que caso contrário continua contando seu valor no custo

total do projeto. No fim do Sprint o cliente poderá solicitar novas funcionalidades de mudança de

escopo, o fabricante calculará a estimativa das alterações de escopo, custo monetário e com isto

entregará ao cliente um contrato de prestação de serviço no estilo adendo, o qual este deverá

assinar para iniciar seu desenvolvimento num próximo Sprint. Na Tabela 2 há exemplos de

cenários, para ilustrar o uso do CAAS. Cenário Receita Lucro Prazo Observação

CI sem Anexos Fixo Fixo Fixo O desenvolvimento ocorre sem

aumento de receita para a empresa.

Podem ocorrer mudanças de escopo

pequenas.

CI com Anexo de

substituição de

uma história de

mesmo tamanho e

custo

Fixo Fixo Fixo Durante a execução do projeto o

cliente pode identificar alguma

funcionalidade emergente, e poderá

solicitar mudança de uma história por

outra sendo que esta ainda não foi

desenvolvida.

CI com Anexo que

implica novas

histórias

Sofre aumento

proporcional ao

anexo

Sofre aumento

proporcional ao

anexo

Sofre aumento

proporcional ao

anexo

A fábrica de software poderá ter um

lucro extra com aditivos no CI.

Tabela 2 – Cenários possíveis para o uso do CAAS

O CAAS tem escopo variável (em geral via adendos), o risco é compartilhado, pois o cliente

pode propor alterações de escopo e o fabricante está aberto a uma demanda nova, assim também

o prazo e o preço são variáveis. A nova técnica não supre outros contratos ágeis que não foram

citados nesta obra ou outras metodologias ágeis.

6. Comparação da contratação CAAS com as já pesquisadas

Adaptado de critérios de contratos ágeis vistos nas obras de Atkinson e Law (2013, p. 21) e Peres

(2010, p. 5) e nos autores acima foi construída a Tabela 3, a qual compara os contratos descritos

nesta obra. Os critérios utilizados na comparação são respectivamente nominados pelos

marcadores com as letras “(a, b, c, d, ...)” da listagem abaixo e relacionados a Tabela 3 com as

siglas5 de cada contrato ágil. Segue abaixo esta listagem:

5 Uma listagem completa das siglas dos contratos está no apêndice G, que é o glossário.

a) Solução evolutiva e emergente: conforme Pressman (2006, p. 42) os modelos

evolucionários são iterativos (é repetido várias vezes), permitem engenheiros de

software versões cada vez melhores a cada ciclo;

b) Abordagem experimental: segundo Bramer e Milne (1993, p. 35) envolve utilizar

métricas para estimar, validar e testar partes de um software em critérios específicos;

c) Ciclos de retorno e aprendizagem rápida: usa fases, ciclos ou Sprints para dividir as

entregas de curto prazo;

d) Resposta rápida para abraçar mudanças: deve permitir mudanças rapidamente;

e) Relação de colaboração: cliente deve participar continuamente do desenvolvimento;

f) Preço: define se o preço é fixo desde o início ao fim do software, ou se é variável;

g) Prazo: define se o prazo de entrega do ciclo é fixo ou variável;

h) Escopo: conforme PMI (2013, p. 105) o escopo do produto envolve suas características

e funções que o definem como produto ou serviço e escopo do projeto envolve o

trabalho para realizar a entrega do produto. Este item define se o escopo é fixo ou

variável;

i) Risco: define qual parte sofre os danos caso estourar o prazo do projeto.

contrato a b c d e f g h i

CS sim não sim sim sim variável variável variável cliente

PFEF não não não não não fixo fixo fixo fornec

edor

T&M sim sim sim sim sim variável variável variável mútuo

T&MEF

TC6

sim sim sim não sim fixo fixo fixo mútuo

T&MEV

TC7

sim sim sim sim sim variável fixo variável mútuo

DF sim sim sim sim sim variável fixo variável mútuo

BM independ

e

não independ

e

sim sim variável independe variável mútuo

LF independ

e

não sim sim sim variável fixo variável mútuo

MNCF8 sim sim sim sim sim fixo fixo variável mútuo

JV independ

e

independe independ

e

sim sim variável variável independ

e

mútuo

CAAS sim sim sim sim independe variável variável variável mútuo

Tabela 3 – Comparação dos contratos ágil (baseado nas obras pesquisas acima)

O CAAS é uma compilação de outros contratos ágeis, desta forma ele pode assumir

características destes de forma a adaptar-se à necessidade do projeto.

7. Ferramenta para escolha de contrato ágil baseado nas pesquisas

De acordo com Thums (2003, p. 80) temas amplos permitem múltiplas escolhas de caminhos que

poderão conduzir-nos ao erro. A identificação de um tema com precisão permite caminhar a um

rumo claro e objetivo. De forma similar, a escolha por uma empresa entre os vários tipos de

6 T&MEFTC – Contrato de Tempo e Materiais com escopo fixo e um teto de custos.

7 T&MEVTC - Contrato por Tempo e Materiais com Escopo variável e Teto de Custo.

8 MNCF – Contrato Money for nothing, changes for free.

contratos ágeis pode ser facilitada via uma linha guia que a oriente a escolha do acordo mais

adequado para um projeto de software.

Desta forma, este trabalho traz a ferramenta Consultor de Contrato Ágil (CCA), que visa

auxiliar no processo de decisão de contratos ágeis. A ferramenta é um algoritmo (fluxograma)

que pode ser executado manualmente por um leitor, porém foi construído um aplicativo para o

sistema operacional Android a fim de facilitar e automatizar o processo. A intenção de fazer um

aplicativo é apresentar uma interface mais simples e acessível que um fluxograma, onde uma

pessoa por meio de simples toques na tela poderá encontrar uma resposta. Também intenta em

divulgar os resultados deste trabalho num software que resume sua essência e ainda é uma

tentativa de divulgar o uso dos MA.

Segundo Gartner (2014) mais de 1 bilhão de aparelhos (entre smartphones e tablets) com

Android serão vendidos em 2014, e conforme Flurry (2014) em 2013 ocorreu um aumento 115%

de uso de aplicativos móveis. Segundo Version One (2012, p. 9) há 11% de projetos com MA

que falham por não conseguir usar totalmente a metodologia ágil, a disseminassão desta obra via

um aplicativo é uma colaboração na tentativa de reduzir estes números negativos.

Segundo Brookshear (2003, p. 398) um sistema especialista (SE) é um software projetado

para ajudar os seres humanos em situações nas quais é imprescindível a presença de um

especialista. Por exemplo, um SE pode diagnosticar certas doenças, onde a partir de perguntas

feitas a um paciente o software afirma que há 80% de chance de uma doença reumática.

Conforme Maia (2012, p. 123), uma estrutura inferencial (simula mente humana) pode ser

representada por uma árvore, formada por nós e ramos. Uma árvore de decisão pode exibir um

esquema de representação do conhecimento, como também um método de raciocínio sobre o que

se sabe de um problema. A partir dela pode-se construir um software que a automatize.

Segundo Primak (2008, p. 45) na árvore os nós internos da árvore são chamados

características, tal como “dor de garganta” ou “febre” e seus valores “Sim” ou “Não”. Seus nós

folhas (os resultados) são chamados de classes, como “paciente está gripado” ou “paciente

saudável”.

De acordo com Ansari et al. (2012, p. 803), a ferramenta Weka (Waikato Environment for

Knowledge Analysis) contêm vários algoritmos de máquina de aprendizado, que pode ser

aplicada na resolução de problemas de Data Mining (mineração de dados) e pode gerar uma

árvore de decisão. Weka foi desenvolvida pela Universidade de Waikato, da Nova Zelândia, com

código-fonte livre sob licença GNU (General Public License). Ela permite a entrada de arquivos

como CSV (arquivos separados por vírgula), BSI (Binary Serialized Instances) e ARFF

(Attribute-Relation File Format, que é o padrão do Weka).

Baseado nos autores relatados nesta obra foram montadas duas tabelas (vide apêndice A e

apêndice B) com as características e classes vistas no apêndice C e D. A tabela do apêndice A é

focada no contrato que abrange todo o ciclo de software; a do apêndice B mostra as cláusulas

para entrega atrasada e adiantada. Em ambas foram classificadas as características baseadas nos

autores pesquisados nos tópicos acima. Não foi utilizado JV, pois esta forma de contratação

depende da forma que a parceria é realizada.

Segundo Zhao e Zhang (2008, p. 4), o algoritmo Random Tree tem características aleatórias

que, a partir de cada folha é gerada uma árvore aleatória baseada no conjunto de possibilidades.

Este algoritmo foi aplicado nas tabelas, do apêndice, para gerar as árvores de decisão, devido as

suas características, e dos testados realizados foi o que obteve soluções ideais a este problema.

As tabelas dos apêndices A e B foram convertidas em dois arquivos CSV que foram

importados para o software Weka 3.6.10, onde foi executado o algoritmo

“weka.classifiers.trees.RandomTree -K 0 -M 1.0 -S 1”. Feito isto, foi obtida uma árvore de

decisão para os tipos de contratos ágeis que focam o ciclo de vida do software (vide apêndice

E(I)) e outra árvore para auxiliar a escolha de cláusulas sobre atrasos ou adiantamentos de

cronograma do projeto (apêndice E(II)). Toda a ferramenta está vide apêndice E(III).

Um exemplo hipotético prático mostra um GP que precisa decidir qual contrato ágil usar para

um novo projeto de software, que possui as seguintes características: a) cliente deve participar

continuamente do desenvolvimento; b) o risco é compartilhado; c) deve ter um teto de custos e

d) o escopo é variável para cada Sprint. Inicialmente, o GP utilizará o software descrito no

apêndice E(III) e então, este deve lhe indicar um contrato T&MEVTC como sendo o mais

indicado. Neste ponto, com contrato ágil definido, poderá verificar cláusulas para atraso ou

adiantamento de entrega caso o cliente queira terminar o projeto mais cedo ou trocar uma

história de usuário por outra ainda não implementada. Caso isso ocorra o mais indicado seria

adicionar a cláusula de MNCF no contrato T&MEVTC.

Esta ferramenta foi implementada utilizando um aplicativo para o sistema operacional

Android, em Java, e a sua execução pode ser visualizada no apêndice E(IV). Pretende-se

disponibilizar este aplicativo na Google Play Store, focado nos públicos-alvo acadêmico e

profissional de tecnologia da informação.

8. Considerações Finais

A contratação com MA permite formalizar práticas que já são comuns nas negociações de

projetos.

A nova técnica CAAS apresentada nesta obra visa compilar as práticas recomendadas pelos

autores, em sequências adaptadas para facilitar o trabalho dos fabricantes e GPs. O grande

diferencial dos outros métodos é combinar técnicas já conhecidas em uma solução única,

formalizando as mudanças em contratos e aditivos contratuais para, desta forma, garantir a

segurança jurídica do projeto. O CAAS pode ser aplicado na prática, mas até o momento não foi

testado totalmente em projetos reais devido à falta de tempo adequado.

A ferramenta CCA objetiva auxiliar a escolha do contrato ágil mais adequado para um

projeto, que pode auxiliar um GP nesta tomada da decisão gerencial. Atualmente o aplicativo

para Android está disponível no Google Play Store no link

<https://play.google.com/store/apps/details?id=br.christian.rogerio.camara.abreu.agilecontractco

nsulting>, lá é chamada de AGILE CONTRACT SCRUM.

Para trabalhos futuros é sugerido:

Pesquisar outros contratos ágeis para adicionar às referências, ao CAAS e ao CCA;

Desenvolver software que una o CCA e o CAAS (na ferramenta ao criar um projeto

definir o tipo de contrato e suas cláusulas via CCA e após calcular o custo total a cada

adendo ou história concluída via o CAAS);

Aplicar o CCA e o CAAS em projetos reais, analisar os resultados obtidos, sugerir

melhorias.

Referências

ACM DIGITAL LIBRAY. ACM Digital Libray. Association for Computing Machinery, Nova

York, 2014. Disponível em: <http://dl.acm.org>. Acesso em: 17 jan. 2014.

ANSARI, Nazneen et al. Data Mining in Online Social Games. In: PROCEEDINGS OF

INTERNATIONAL CONFERENCE ON ADVANCES IN COMPUTING, 1., 2012, India.

Anais… India: Ramaiah Institute of Technology, 2012.

ARBOGAST, Tom et al. Agile contracts primer. Boston: Agile Contracts, 2012. Disponível

em: <http://www.agilecontracts.org/agile_contracts_primer.pdf>. Acesso em: 30 mai. 2013.

ASBCA. Opinion by administrative judge todd on appellant's motion for reconsideration:

Appeal of Corbett Technology Company. Acórdão em decisão judicial pela Armed Services

Board of Contract Appeals em ASBCA Número 49478 apelado por Corbett Technology

Company, Inc. Juíz Administrativo: Lisa Anderson Todd. 28 jul. 2000. Disponível em: <

http://www.asbca.mil/Decisions/2000/49478a.pdf>. Acesso em: 23 nov. 2013.

ATKINSON, Susan; LAW, Keystone. The Problem with Agile & Contracts. In: AGILE

BUSINESS CONFERENCE, 9., 2013, Reino Unido. Anais… Reino Unido: Agile Business

Conference Organisers, 2013. Disponível em: <http://www.agileconference.org/wp-

content/uploads/2013/10/Susan-Atkinson-The-Problem-with-Agile-and-Contracts-

01.10.13.pdf>. Acesso em: 22 jan. 2014.

BASAVA, Shibani. Supporting Team Performance: An Empirical Study of Software Teams,

Processes and Tools to Enhance Software Development. Colorado: ProQuest, 2008. 259p.

BECK, Kent et al. Manifesto for Agile Software Development. Utah: Agile Alliance, 2001.

Disponível em: <http://www.agilemanifesto.org> Acesso em: 08 set. 2012.

BERENDS, William R. Price & Profit: The essential guide to product & service pricing and

profit forecasting. Canada: William R. Berends, 2004. 142p.

BERGIN, Joseph. Patterns for Agile Development Practice. In: TENTH EUROPEAN

CONFERENCE, 10., 2005, Irsee, Alemanha. Anais… Irsee: Universidade de Konstanz, 2005.

Disponível em: <http://csis.pace.edu/~bergin/patterns/xpPatternsEuroV7.html>. Acesso em: 20

out. 2013.

BOMBOSCH, Uwe et al. Applying Scrum and XP in An Enterprise Context. In: MEETING OF

THE GI JAHRESTAGUNG, 2., 2010, Lípsia. Anais... Lípsia: Universidade de Lípsia, 2010. p.

221-226 Disponível em: <http://subs.emis.de/LNI/Proceedings/Proceedings176/237.pdf>.

Acesso em: 20 jan. 2014.

BRAMER, M. A.; MILNE, R. W. Research and Development in Expert Systems IX. Reino

Unido: Cambridge University Press, 1993. v. 9.

BROOKSHEAR, J. Glenn. Ciência da Computação: Uma Visão. São Paulo: Editora Bookman,

2003.

BULLEN, Christine V. et al. Implementing Strategic Sourcing: A Manager's Guide to World

Class Best Practices. Holanda: Van Haren Publishing, 2010. 359p.

BUXMANN, Peter; DIEFENBACH, Heiner; HESS, Thomas. The Software Industry:

Economic Principles, Strategies, Perspectives. Nova York: Springer, 2012. 223p.

CHIAVENATO, Idalberto. Administração Geral e Pública. 2. ed. Rio de Janeiro: Elsevier,

2008.

CHOW, Tsun; CAO, Dac-Buu. A survey study of critical success factors in agile software

projects. The Journal of Systems and Software, Minneapolis, v. 1, n. 81, p. 961-971, ago.

2008. Disponível em:

<http://www.ccunix.ccu.edu.tw/~kcchen/PM/Presentations/2012.05.25/Team4.pdf>. Acesso em:

25 jan. 2014.

COLLIER, Ken. Ten mistakes to avoid in an Agile BI transformation. 1. ed. Renton: The

Data Warehousing Institute, 2013. Disponível em:

<http://tdwi.org/~/media/947D124FCEEC476AB1590741F6BD836B.pdf>. Acesso em: 30 mai.

2013.

FARIA, Leandro. AgileTalk Podcast #003: Contratos ágeis. Minas Gerais, Leandro Faria, 2013.

Disponível em: <http://leandrofaria.com.br/agiletalk-podcast-003-contratos-ageis>. Acesso em:

25 jan. 2014.

FITCHETT, Paul; HASLAM, Jeremy. Writing Engineering Specifications. 2. ed. Nova York:

Taylor & Francis, 2003. 224 p.

FLURRY. Mobile Use Grows 115% in 2013. São Francisco: Flurry, 2014. Disponível em:

<http://blog.flurry.com/bid/103601/Mobile-Use-Grows-115-in-2013-Propelled-by-Messaging-

Apps>. Acesso em: 23 jan. 2014.

FRANKLIN, Teresa. Adventures in Agile Contracting: Evolving from Time and Materials to

Fixed Price, Fixed Scope Contracts. In: PROCEEDINGS OF THE AGILE 2008 (AGILE '08), 1.,

2008, Washington. Anais… Washington: IEEE Computer Society Washington, 2008. p. 269-

273.

GARTNER. Gartner Says Worldwide Traditional PC, Tablet, Ultramobile and Mobile

Phone Shipments On Pace to Grow 7.6 Percent in 2014. Stamford: Gartner, 2014. Disponível

em: <http://www.gartner.com/newsroom/id/2645115>. Acesso em: 23 jan. 2014.

GOOGLE. Google. Mountain View, Google Inc, 2014. Disponível em:

<https://www.google.com>. Acesso em: 21 jan. 2014.

GOOGLE ACADÊMICO. Mountain View, Google Inc, 2014. Google Acadêmico. Disponível

em: <http://scholar.google.com.br>. Acesso em: 17 jan. 2014.

HAYWARD, R. E. H. Valuation: Principles Into Practice. Inglaterra: Estates Gazette, 2000. 807

p.

IEEE XPLORE DIGITAL LIBRARY. IEEE Xplore Digital Library. Piscataway, IEEE, 2014.

Disponível em: <http://ieeexplore.ieee.org>. Acesso em: 17 jan. 2014.

LAPHAM, Mary Ann et al. Agile Methods: Selected DoD Management and Acquisition

Concerns. Pittsburgh: Carnegie-Mellon University, Software Engineering Institute, 2011. 129 p.

Disponível em: <http://www.sei.cmu.edu/reports/11tn002.pdf>. Acesso em: 16 jan. 2014.

LEYBOURN, Evan. Directing The Agile Organisation: A lean approach to business

management. Reino Unido: IT Governance Ltd, 2013. 275 p.

MAIA, Wagner de Azevedo. Percepção & Inteligência Artificial: Conceitos, Considerações e

Arquitetura. São Paulo: Biblioteca 24 horas, 2012. 318 p.

MARSH, Peter. Contracting for Engineering and Construction Projects. Burlington: Gower

Publishing, 2000. 232 p.

MICROSOFT. Criar um contrato de projeto para faturar por tempo e material. Redmond:

Microsoft TechNet, 2012. Disponível em: <http://technet.microsoft.com/pt-

br/library/hh208965.aspx>. Acesso em: 12 de nov. 2013.

MOREIRA, Mario E. Being Agile: Your Roadmap to Successful Adoption of Agile. Nova York:

Apress, 2013. 268 p.

NATIONAL IT AND TELECOM AGENCY. Agile Methods in IT-Based Business Projects:

Guide to Agile Development in the Public Sector. Copenhagen: The National IT and Telecom

Agency, 2010. 56 p. Disponível em:

<http://digitaliser.dk/resource/1643009/artefact/Agile,+eng.ver.pdf>. Acesso em: 6 jan. 2014.

OPELT, Andreas et al. Agile Contracts: Creating and Managing Successful Projects with

Scrum. Nova Jérsia: John Wiley & Sons, 2013. 304 p.

PERES, Eduardo Meira. Utilizando SCRUM em contratos de preço fixo. In: AGILE BRAZIL,

1., 2010, Porto Alegre. Anais... Porto Alegre: Faculdade de Informática da PUC-RS, 2010.

Disponível em: <

http://www.agilebrazil.com/2010/material/Scrum%20em%20contratos%20de%20preco%20fixo-

Eduardo%20Peres.pdf>. Acesso em: 22 jan. 2014.

PICHLER, Roman. Gestão de Produtos com Scrum: Implementando métodos ágeis na criação

e desenvolvimento de produtos. Rio de Janeiro: Elsevier Brasil, 2011.

PMI. PMBOK Guide. 5. ed. Atlanta: PMI, 2013.

POPPENDIECK, Mary; POPPENDIECK, Tom. Lean Software Development: An Agile

Toolkit. Nova Jérsia: Addison-Wesley Professional, 2003. 203 p.

PRESSMAN, Roger S. Engenharia de software. 6. ed. São Paulo : McGraw-Hill, 2006.

PRIMAK, Fabio Vinicius. Decisões com BI (Business Intelligence). Rio de Janeiro: Editora

Ciência Moderna, 2008. 152p.

RICH, Barnett; SCHMIDT, Philip A. Geometria: Teoria e Problemas. Porto Alegre: Bookman,

2003. 359p.

RICO, David F. et al. The Business Value of Agile Software Methods: Maximizing ROI with

Just-in-time Processes and Documentation. Fort Lauderdale: Ross Publishing, 2009. 214 p.

RIJ, Stuart Van. Is your development contract broken? Wellington: Wigley+Company

solicitors, 2012. Disponível em: <http://www.wigleylaw.com/assets/Uploads/Development-

contract-broken.pdf>. Acesso em: 10 jan. 2014.

SANTOS, Rui. Agile Technical Management of Industrial Contracts Scrum Development of

Ground Segment Software at the European Space Agency. In: AGILE PROCESSES IN

SOFTWARE ENGINEERING AND EXTREME PROGRAMMING: 12th International

Conference, 12., 2011, Madrid. Anais… Madrid: Springer, 2011. p. 290.

SCHWABER, Ken. Guia do Scrum. 2009. Disponível em:

<www.trainning.com.br download A D SCR M.pdf >. Acesso em: 30 mai. 2013.

SIMPLESSUS. Simplessus Contracts. Neuengörs, Simplessus Software Ltd, 2014. Disponível

em: <http://www.simplessus.com/pt/software.html>. Acesso em: 21 jan. 2014.

SORSA, Kaisa. Proactive Management and Proactive Business Law: a handbook. Finlândia:

Turku University of Applied Sciences, 2011. Disponível em: < http://julkaisut.turkuamk.fi/isbn9789522162458.pdfhttp://julkaisut.turkuamk.fi/isbn9789522162

458.pdf>. Acesso em: 20 jan. 2014.

STEVENS, Peter. 10 Contracts for your next Agile Software Project. In: SCRUM ALLIANCE

GERMANY SCRUM GATHERING, 1., 2009, Munique. Anais... Munique: Scrum Alliance,

Hilton Munich City Hotel, 2009. Disponível em:

<http://members.scrumalliance.org/resources/1119>. Acesso em: 22 jan. 2014.

SUTHERLAND, Jeff. Agile contracts: Money for nothing and your change for free. In: AGILE

2008 CONFERENCE, 1., 2008, Toronto. Anais... Toronto: Agile Alliance, 2008. Disponível em:

<http://jeffsutherland.com/Agile2008MoneyforNothing.pdf>. Acesso em: 20 out. 2013.

SWAIM, Robert W. The Strategic Drucker: Growth Strategies and Marketing Insights from the

Works of Peter Drucker. São Francisco: John Wiley & Sons, 2011. 280 p.

THORUP, Lars; JENSEN, Bent. Collaborative Agile Contracts. In: PROCEEDINGS OF THE

2009 AGILE CONFERENCE (AGILE '09) IEEE COMPUTER SOCIETY, 19., 2009,

Washington. Anais… Washington: IEEE Computer Society, 2009. p. 195-200. Disponível em:

<http://www.bestbrains.dk/wp-content/uploads/2011/06/collaborative_agile_contracts-

agile2009.pdf>. Acesso em: 4 jun. 2013.

THUMS, Jorge. Acesso a Realidade. 3. ed. Canoas: Universidade Luterana do Brasil, 2003.

TURBAN, Efraim et al. 6. ed. Tecnologia da Informação para Gestão: Transformando os

Negócios na Economia Digital. São Paulo: Bookman, 2008.

VERSION ONE. State of Agile Survey. Alpharetta: Version One, 2012. Disponível em: <

http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf>. Acesso

em: 30 mai. 2013.

ZHAO, Yongheng; ZHANG, Yanxia. Comparison of decision tree methods. Advances of Space

Research, Irsee, China, v.41, 1955-1959, ago., 2008. Disponível em: <

http://www.researchgate.net/publication/222577136_Comparison_of_decision_tree_methods_for

_finding_active_objects/file/e0b4951d77977deaf5.pdf >. Acesso em: 6 jan. 2014.

ZIJDEMANS, Shi Hao. Contracting in Agile Software Projects: Current Challenges and New

Possible Solutions. 2013. 60f. Dissertação (Tese de Licenciatura em Ciência da Computação) -

Leiden Institute of Advanced Computer Science (LIACS), Leiden University, Leiden.

Disponível em: <http://www.liacs.nl/assets/Bachelorscripties/2012-2013-

05ShiHaoZijdemans.pdf>. Acesso em: 10 dez. 2013.

APÊNDICE A – Tabela para gerar árvore de decisão do contrato ágil

A tabela abaixo foi utilizada para gerar a árvore de decisão da escolha de contratos ágeis da ferramenta

CAAS.

CAAS9 CS

PFE

F T&M T&MEFTC T&MEVTC DF

passos_

burocraticos_governo10

independe

indepe

nde

verda

de independe independe independe independe

cliente_participa_cont

inuo independe

verdad

e falso verdade verdade verdade verdade

dividido_em_sprints verdade

verdad

e falso verdade verdade verdade verdade

preco_fixo_na_fase falso

verdad

e falso falso falso falso falso

preco_total_variavel verdade falso falso verdade verdade verdade verdade

gerir_tempo verdade falso falso verdade verdade verdade verdade

gerir_recursos verdade falso falso verdade verdade verdade verdade

Risco

Compartilha

do

fabrica

nte

fabri

cante cliente

compartilhad

o

compartilhad

o

compartilhad

o

teto_de_custo independe

indepe

nde falso falso verdade verdade falso

trocar_estoria_por_o

utra formal

inform

al falso formal formal formal formal

9 No apêndice G há o glossário, que contém o descritivo das siglas dos contratos ágeis.

10 No apêndice C estão descritas as características dos contratos ágeis.

fabricante_reduz_cust

o_terminar_cedo

traz_metricas

_e_formal

traz_m

etricas

infor

mal

traz_metricas

_e_formal

traz_metricas

_e_formal

traz_metricas

_e_formal

traz_metricas

_e_formal

escopo_total_fixo independe falso

verda

de falso verdade falso falso

escopo_fixo_na_fase independe

verdad

e

verda

de verdade verdade falso verdade

APÊNDICE B – Tabela para gerar árvore das cláusulas de atrasos e adiantamentos

A tabela abaixo foi utilizada para gerar a árvore de decisão da escolha de cláusulas de atraso e

adiantamento de contratos ágeis da ferramenta CAAS.

BM11

LF12

money_for_no

thing13

changes_for_

free14

MNCF15

terminar_mais_cedo_sem

_perda16

falso falso verdade falso verdade

trocar_estoria_por_outra

_formal falso falso falso verdade verdade

foco_bonus_entrega_adia

ntada verdade falso falso falso falso

foco_multa_entrega_atra

sada verdade falso falso falso falso

foco_continuar_apesar_a

trazo falso verdade falso falso falso

11 BM - Cláusulas de Bônus e Multas.

12 LF – Contrato de Lucro fixo.

13 Cláusula Money for nothing.

14 Cláusula Changes for free.

15 MNCF – Contrato Money for nothing, changes for free (dinheiro por nada, mudanças de graça).

16 No apêndice D estão descritas as características das cláusulas de atrasos e adiantamentos.

APÊNDICE C – Características e classes de contratos ágeis

Este apêndice contêm descritas características de contratos ágeis, que são relacionadas com tipos de

acordos na tabela presente no apêndice A.

PASSOS_BUROCRATICOS_GOVERNO: O cliente exige ser tratado com escopo fixo e segue

regras, tal como um órgão de governo?

o Classes:

Independe: Pode ocorrer ou não, não é obrigatório para existência;

Verdade: Verdadeiro, ocorre;

Falso: Falso, não ocorre;

CLIENTE_PARTICIPA_CONTINUO: Metodologia obriga o cliente a participar continuamente

no processo de desenvolvimento do software, ou nos Sprints17

;

o Classes: Independe, Verdade, Falso;

DIVIDIDO_EM_SPRINTS: O projeto deve utilizar Sprints?

o Classes: Independe, Verdade, Falso;

PRECO_FIXO_NA_FASE: Para cada fase (ou Sprint) o preço será fixo?

o Classes: Independe, Verdade, Falso;

PRECO_TOTAL_VARIAVEL: O preço total do projeto poderá ser aumentado ou diminuído?

o Classes: Independe, Verdade, Falso;

GERIR_TEMPO: O projeto exige que seja controlado o tempo e o valor hora de cada recurso?

o Classes: Independe, Verdade, Falso;

GERIR_RECURSOS: O projeto exige que sejam controlados os recursos humanos ou materiais?

o Classes: Independe, Verdade, Falso;

RISCO: De quem é o risco maior ou total?

o Classes:

Cliente: o risco é do cliente, o Product Owner;

Fabricante: o risco é do fabricante do software;

Compartilhado: o risco é de ambos, cada um pode ter uma penalidade ou bônus;

17 Sprint – É um ciclo de desenvolvimento de software, é usado como unidade de desenvolvimento no Scrum.

Tendem a durar entre uma semana e um mês. No apêndice G estão descritos outros termos técnicos.

TETO_DE_CUSTO: O projeto precisa manter um teto de custos?

o Classes: Independe, Verdade, Falso;

TROCAR_ESTORIA_POR_OUTRA: O cliente poderá trocar uma história por outra (não

implementada) com custo e peso igual de forma formal?

o Classes: Independe, Verdade, Falso;

FABRICANTE_REDUZ_CUSTO_TERMINAR_CEDO: Cliente poderá terminar mais cedo o

projeto? Sendo que o fabricante garante um valor percentual neste caso;

o Classes:

TRAZ_METRICAS_E_FORMAL: A metodologia e o contrato preveem

cláusulas para criar adendos e seus custos, com métricas de T&M 18

estabelecidas

desde o primeiro contrato;

TRAZ_METRICAS: A contratação pode trazer métricas de T&M para prever

custos de um adendo, mas pode ser informal esta mudança;

INFORMAL: A mudança para este caso é informal, o contrato não prevê

métricas desde o primeiro contrato;

ESCOPO_TOTAL_FIXO: O escopo total desta contratação é fixo, não deve ser alterado durante

o desenvolvimento do software.

o Classes: Independe, Verdade, Falso;

ESCOPO_FIXO_NA_FASE: Cada Sprint tem o escopo fixo?

o Classes: Independe, Verdade, Falso;

CONTRATO: Tipo de contrato ágil;

o Classes:

Nova_Tecnica: Nova técnica (CAAS) proposta nesta obra;

CS: Contrato por Sprint;

PFEF: Preço Fixo e escopo fixo;

TM: T&M;

TMEFTC: T&MEFTC19

;

TMEVTC: T&MEVTC20

;

18 T&M – Contrato de Tempo e Materiais.

19 T&MEFTC – Contrato de Tempo e Materiais com escopo fixo e um teto de custos.

Desenvolvimento_Faseado: Desenvolvimento faseado.

20 T&MEVTC - Contrato por Tempo e Materiais com Escopo variável e Teto de Custo.

APÊNDICE D – Características e classes para cláusulas de atrasos e adiantamentos

Este apêndice contêm descritas características de cláusulas de atrasos e adiantamentos, que são

relacionadas com contratos ágeis na tabela presente no apêndice B.

TERMINAR_MAIS_CEDO_SEM_PERDA: O Product Owner pode optar por terminar o projeto

mais cedo, sem o fabricante ter perdas de faturamento?

o Classes: Independe, Verdade, Falso;

TROCAR_ESTORIA_POR_OUTRA_FORMAL: O cliente poderá trocar uma história por outra

(não implementada) com custo e peso igual de forma formal?

o Classes: Independe, Verdade, Falso;

FOCO_BONUS_ENTREGA_ADIANTADA: Se o fabricante do software terminar o projeto

mais cedo deverá receber bônus?

o Classes: Independe, Verdade, Falso;

FOCO_MULTA_ENTREGA_ATRASADA: Se o fabricante do software terminar o projeto

atrasado deverá receber multa?

o Classes: Independe, Verdade, Falso;

FOCO_CONTINUAR_APESAR_ATRAZO: Se o projeto atrasar o fabricante deverá continuar o

projeto com redução a um lucro fixo (para dar continuidade ao negócio)?

o Classes: Independe, Verdade, Falso;

CONTRATO:

o Classes:

Clausulas_BM: Cláusulas de Bônus e Multas;

Lucro_Fixo: Lucro fixo;

Money_For_Nothing: Money for Nothing;

Changes_For_Free: Changes for free;

MNCF: MNCF21

.

21 MNCF – Contrato Money for nothing, changes for free (dinheiro por nada, mudanças de graça).

APÊNDICE E – Ferramenta Consultor de Contrato Ágil

(I) – Ferramenta para escolha de contrato ágil com foco no ciclo de desenvolvimento (baseado nos autores

acima)

(II) – Ferramenta para cláusulas atrasos e adiantamentos (baseado nas pesquisas acima)

(III) – Ferramenta para auxiliar escolha de contratos ágeis

act Decidir Contrato_layout

Início

Cliente deve

participar

continuamente

no projeto?

De quem é risco?Projeto deve ter

teto de custos

para o

fabricante?

Escopo é fixo

para cada

Sprint?

Exibir mensagem

"Nov a Técnica"

Exibir mensagem

"Nov a Técnica"

Exibir

mensagem

"CS"

Exibir

mensagem

"T&MEVTC"

Exibir

mensagem

"T&M"

Exibir

mensagem

"PFEF"

Exibir

mensagem

"T&MEFTC"

Exibir mensagem

"Desenv olv imento

Faseado"

Exibir mensagem

"Nov a Técnica"

Fim[Cliente] [Fabricante]

[Compartilhado]

[Falso]

[Independe]

[Verdade]

[Falso]

[Verdade]

[Independe]

[Falso]

[Verdade]

[Independe]

act Decidir Cláusula - layout

InícioExibir

mensagem

"BM"

Exibir

mensagem

"Lucro Fixo"

Cliente pode

terminar mais

cedo?

Cliente pode trocar

histórias?

Entrega adiantada

ganha bônus?

Continuar projeto atrasado?

Exibir

mensagem

"Money for

Nothing"

Exibir

mensagem

"MNCF"

Exibir

mensagem

"Changes for

Free"

Fim

[Verdade][Falso]

[Falso]

[Verdade]

[Verdade]

[Falso][Falso]

[Verdade]

act Ferramenta

Informar e

Decidir Contrato

Ágil

Informar e

Decidir Clásulas

para atrazo e

adiantamento de

entrega

Início

Fim

Exibir contrato e

clásula obtido

(A) (B)

(IV) –Aplicativo Android para auxiliar escolha de contratos ágeis

APÊNDICE F – Fluxo do CAAS22

22 No apêndice G há um glossário com descritivo de alguns termos técnicos presentes na figura acima.

APÊNDICE G – Glossário

Abaixo estão descritos resumidamente alguns termos técnicos usados neste texto:

Android – Sistema operacional para dispositivo móvel fabricado pela Google;

ARFF - Attribute-Relation File Format, que é o padrão do Weka;

BM - Cláusulas de Bônus e Multas;

BSI - Binary Serialized Instances;

CAAS - Contrato Ágil Adaptável para Scrum;

CI - Contrato Inicial;

CS - Contrato por Sprint;

CSV - Comma-separated values - arquivos separados por vírgula;

DF – Contrato de Desenvolvimento faseado (Phased Development);

GNU - General Public License - Licença Pública Geral;

Google Play Store – plataforma de aplicações para Android;

GP – Gerente de Projetos;

Java - é uma linguagem de programação orientada a objeto;

JV - Joint Ventures (parceria, sociedade);

LF – Contrato de Lucro fixo;

LTI - The Lost Time Injury – Incidente com Afastamento;

HVF - High Value First - primeiro maior valor agregado. O cliente deve priorizar as histórias de

usuário para a equipe de desenvolvimento construir primeiro as essenciais;

MA – Métodos Ágeis;

MNCF – Contrato Money for nothing, changes for free (dinheiro por nada, mudanças de graça);

T&M – Contrato de Tempo e Materiais;

PB - Product Backlog - repositório de histórias de usuário que ainda não foram codificadas em

software;

PFEF – Contrato de Preço Fixo e escopo fixo;

Planning Poker - técnica para estimar tamanho de histórias de usuário, baseia-se na experiência

da equipe de desenvolvimento de software;

PM - Preço Máximo;

PO - Product Owner - representa o cliente que contrata o desenvolvimento do software;

Random Tree – algoritmo para gerar árvores de decisão;

ROI - Return on investment - retorno sobre o investimento. Sua fórmula é: ROI = (Benefícios –

Custo x 100%)/Custo;

Scrum – É um processo ágil de desenvolvimento iterativo e incremental para

gerenciamento e desenvolvimento de projetos de software;

SE - sistema especialista;

Sprint – É um ciclo de desenvolvimento de software, é usado como unidade de

desenvolvimento no Scrum. Tendem a durar entre uma semana e um mês;

T&M – Contrato de Tempo e Materiais;

T&MEFTC – Contrato de Tempo e Materiais com escopo fixo e um teto de custos;

T&MEVTC - Contrato por Tempo e Materiais com Escopo variável e Teto de Custo;

UCP - Use Case Point (Pontos de Caso de Uso);

Weka - Waikato Environment for Knowledge Analysis (Weka é uma coleção de algoritmos de

aprendizado de máquina para tarefas de mineração de dados).