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
[email protected], [email protected]
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 topdown (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.
1000
800
600
Histórias do Projeto
400
20% das Histórias
200
0
Tempo
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
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.
1000000
800000
600000
Receita
400000
Lucro
200000
0
Mês 1
Mês 2
Mês 3
Mês 4
Mês 5
Mês 6
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.
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.
40000
30000
Lucro
20000
Teto de Custos
10000
Receita
0
Mês 1
Mês 2
Prazo Entrega Estouro 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.
60000
50000
40000
Lucro
30000
Teto de Custo
20000
Receita
10000
0
Sprint 1
Sprint 2
Sprint 3
Sprint 4
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.
120
100
80
Histórias Construídas
60
margem de 20%
40
Histórias não Construídas
20
História A
História A
0
Tempo
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;
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 PFEF 2. 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.
5000000
4000000
3000000
Receita
2000000
Custo
1000000
Lucro
0
Fase 1
Fase 2
Fase 3
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.
20
15
Receita
10
Lucro
5
0
Início
Marco 1
Marco 2
Data Entrega
Atrazo
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.
14
12
Lucro
10
Bônus
8
Receita
6
Multa
4
Bônus do Lucro
2
Perda do Lucro
0
-2
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Data de
Entrega
Estouro de
prazo
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.
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)
Método para Gestão de contratos
X
X
X
Comparação de contratos ágeis e nova
X
X
técnica
Ferramenta para auxiliar a escolha de
contrato ágil
Tabela 1 – Comparação dos trabalhos correlatos com esta proposta
Esta
Obra
X
X
X
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
CI sem Anexos
Receita
Fixo
Lucro
Fixo
Prazo
Fixo
CI com Anexo de
substituição de
uma história de
mesmo tamanho e
custo
Fixo
Fixo
Fixo
CI com Anexo que
implica novas
histórias
Observação
O desenvolvimento ocorre sem
aumento de receita para a empresa.
Podem ocorrer mudanças de escopo
pequenas.
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.
A fábrica de software poderá ter um
lucro extra com aditivos no CI.
Sofre aumento
Sofre aumento
Sofre aumento
proporcional ao proporcional ao proporcional ao
anexo
anexo
anexo
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
CS
PFEF
a
sim
não
b
não
não
c
sim
não
d
sim
não
e
sim
não
f
variável
fixo
g
variável
fixo
h
variável
fixo
T&M
T&MEF
TC6
T&MEV
TC7
DF
BM
sim
sim
sim
sim
sim
sim
sim
não
sim
sim
variável
fixo
variável
fixo
variável
fixo
i
cliente
fornec
edor
mútuo
mútuo
sim
sim
sim
sim
sim
variável
fixo
variável
mútuo
sim
sim
sim
sim
sim
variável
fixo
variável
independ
não
independ sim
sim
variável independe variável
e
e
independ
não
sim
sim
sim
variável
fixo
variável
e
sim
sim
sim
sim
sim
fixo
fixo
variável
independ independe
independ sim
sim
variável
variável
independ
e
e
e
sim
sim
sim
sim independe variável
variável
variável
Tabela 3 – Comparação dos contratos ágil (baseado nas obras pesquisas acima)
mútuo
mútuo
LF
MNCF8
JV
CAAS
mútuo
mútuo
mútuo
mútuo
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/wpcontent/uploads/2013/10/Susan-Atkinson-The-Problem-with-Agile-and-Contracts01.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-MessagingApps>. 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. 269273.
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/ptbr/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%20fixoEduardo%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/Developmentcontract-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
<www.trainning.com.br download
do
Scrum.
2009.
Disponível
A D SCR M.pdf>. Acesso em: 30 mai. 2013.
em:
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_contractsagile2009.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-201305ShiHaoZijdemans.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
independe
indepe
nde
cliente_participa_cont
independe
inuo
passos_
burocraticos_governo
10
T&M
T&MEFTC
T&MEVTC DF
verda
de
independe
independe
independe
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 fabri
nte
cante cliente
compartilhad compartilhad compartilhad
o
o
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 traz_metricas traz_m infor
_e_formal
etricas mal
o_terminar_cedo
traz_metricas traz_metricas traz_metricas traz_metricas
_e_formal
_e_formal
_e_formal
_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.
LF12
money_for_no changes_for_
thing13
free14
MNCF15
terminar_mais_cedo_sem
falso
_perda16
falso
verdade
falso
verdade
trocar_estoria_por_outra
falso
_formal
falso
falso
verdade
verdade
foco_bonus_entrega_adia
verdade
ntada
falso
falso
falso
falso
foco_multa_entrega_atra
verdade
sada
falso
falso
falso
falso
foco_continuar_apesar_a
falso
trazo
verdade
falso
falso
falso
BM11
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, Verdade, Falso;
Classes: Independe, Verdade, Falso;
Classes: Independe, Verdade, Falso;
Classes: Independe, Verdade, Falso;
Classes: Independe, Verdade, Falso;
Classes: Independe, Verdade, Falso;
RISCO: De quem é o risco maior ou total?
o
17
Falso: Falso, não ocorre;
GERIR_RECURSOS: O projeto exige que sejam controlados os recursos humanos ou materiais?
o


GERIR_TEMPO: O projeto exige que seja controlado o tempo e o valor hora de cada recurso?
o

Verdade: Verdadeiro, ocorre;
PRECO_TOTAL_VARIAVEL: O preço total do projeto poderá ser aumentado ou diminuído?
o


PRECO_FIXO_NA_FASE: Para cada fase (ou Sprint) o preço será fixo?
o

Independe: Pode ocorrer ou não, não é obrigatório para existência;
DIVIDIDO_EM_SPRINTS: O projeto deve utilizar Sprints?
o


CLIENTE_PARTICIPA_CONTINUO: Metodologia obriga o cliente a participar continuamente
no processo de desenvolvimento do software, ou nos Sprints17;
o

Classes:
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;
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

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


TRAZ_METRICAS_E_FORMAL: A metodologia e o contrato preveem
cláusulas para criar adendos e seus custos, com métricas de T&M 18estabelecidas
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;
Classes: Independe, Verdade, Falso;
ESCOPO_FIXO_NA_FASE: Cada Sprint tem o escopo fixo?
o

Classes:
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;
FABRICANTE_REDUZ_CUSTO_TERMINAR_CEDO: Cliente poderá terminar mais cedo o
projeto? Sendo que o fabricante garante um valor percentual neste caso;
o

Classes: Independe, Verdade, Falso;
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.

20
Desenvolvimento_Faseado: Desenvolvimento faseado.
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

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;
CONTRATO:
o
21
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;
FOCO_MULTA_ENTREGA_ATRASADA: Se o fabricante do software terminar o projeto
atrasado deverá receber multa?
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;
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.
MNCF – Contrato Money for nothing, changes for free (dinheiro por nada, mudanças de graça).
APÊNDICE E – Ferramenta Consultor de Contrato Ágil
act Decidir Contrato_layout
Início
Exibir mensagem
"Nov a Técnica"
Exibir
mensagem
"PFEF"
[Independe]
Exibir mensagem
"Nov a Técnica"
[Independe]
Exibir mensagem
"Nov a Técnica"
[Falso]
Cliente deve
[Verdade]
[Independe]
De quem é risco?
participar
Projeto deve ter
Escopo é fixo
Exibir
continuamente
[Compartilhado]
[Falso]
teto de custos
para cada
mensagem
no projeto? [Verdade]
[Verdade]
para o
[Falso] Sprint?
"T&MEVTC"
fabricante?
[Fabricante]
[Cliente]
Exibir
Exibir mensagem
mensagem
"Desenv
olv
imento
Exibir
Exibir
"T&MEFTC"
Faseado"
mensagem
mensagem
"CS"
"T&M"
Fim
(I) – Ferramenta para escolha de contrato ágil com foco no ciclo de desenvolvimento (baseado nos autores
acima)
act Decidir Cláusula - layout
Entrega adiantada
Início ganha bônus?
[Falso]
Exibir
mensagem
"BM"
[Verdade]
[Falso]
Continuar projeto atrasado?
Cliente pode
terminar mais
[Verdade]
cedo?
Cliente pode trocar
histórias?
[Verdade]
Exibir
mensagem
"Lucro Fixo"
Exibir
mensagem
"Changes for
Free"
[Falso]
Exibir
mensagem
"Money for
Nothing"
[Falso]
Fim
Exibir
mensagem
"MNCF"
[Verdade]
(II) – Ferramenta para cláusulas atrasos e adiantamentos (baseado nas pesquisas acima)
act Ferramenta
Início
Informar e
Decidir Contrato
Ágil
Informar e
Decidir Clásulas
para atrazo e
adiantamento de
entrega
Exibir contrato e
clásula obtido
(III) – Ferramenta para auxiliar escolha de contratos ágeis
Fim
(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;

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




GP – Gerente de Projetos;
Java - é uma linguagem de programação orientada a objeto;
da equipe de desenvolvimento de software;




PM - Preço Máximo;

Scrum – É um processo ágil de desenvolvimento iterativo e incremental para
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;
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).