Seminário - Negociação de Contratos

Seminário - Negociação de Contratos

Camila Santos Soprano RA: 0934462597

Tatiane Helena Pinaffi RA: 0970463119

Negociação de Contratos

Negociação de contratos em projetos utilizando desenvolvimento ágil

De uma forma geral, pode-se afirmar que os projetos de desenvolvimento de software têm sido de preocupação constante de cliente do sistema, gerentes de projetos e para os próprios desenvolvedores. Alterações nos prazos de entregas dos produtos, longas fases de análise de requisitos, estouro no orçamento, cancelamento de projetos, etc...

Para lidar com estes desafios, os métodos ágeis enfatizam comunicações em tempo real, preferencialmente face a face, a documentos escritos. Os métodos de desenvolvimento conhecidos como “Ágeis” (em inglês Agile Modeling, ou AG) possuem o objetivo de reduzir o ciclo de vida do software (e por conseqüência acelerar o seu desenvolvimento) através do desenvolvimento de versões mínimas. As funcionalidades são integradas por processos iterativos baseados na interatividade com o cliente e testes em conjunto e paralelo ao ciclo de desenvolvimento.

O termo “Metodologias Ágeis” tornou-se popular em 2001 quando dezessete especialistas em processos de desenvolvimento de software representando os métodos Scrum,Extreme Programming e outros, estabeleceram princípios comuns compartilhados por todos esses métodos. Foi então criada a “Aliança Ágil” e o estabelecimento do “Manifesto Ágil”.

Os conceitos chave do “Manifesto Ágil” são:

· Indivíduos e interações ao invés de processos e ferramentas.

· Software executável ao invés de documentação.

· Colaboração do cliente ao invés de negociação de contratos.

· Respostas rápidas a mudanças ao invés de seguir planos.

O “Manifesto Ágil” não rejeita os processos e ferramentas, a documentação, a negociação de contratos ou o planejamento, mas simplesmente mostra que eles têm importância secundária quando comparado com os indivíduos e interações, com o software estar executável, com a colaboração do cliente e as respostas rápidas a mudanças e alterações. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem a mudanças.

O Manifesto ágil possui os seguintes princípios:

· A maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

· Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

· Entregar software funcionando com freqüência, na escala de semanas até meses, com preferência aos períodos mais curtos.

· Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

· Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

· O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

· Software funcional é a medida primária de progresso.

· Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

· Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

· Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

· As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

· Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e aperfeiçoam seu comportamento de acordo.

Segue abaixo uma breve explicação de algumas metodologias ágeis:

Scrum

É um modelo de desenvolvimento ágil de software e não uma fórmula mágica que resolverá todos os problemas obtidos na empresa no processo de desenvolvimento. Hoje em dia no Brasil e na Europa o Scrum é a metodologia ágil mais utilizada pelas pequenas, médias e grandes empresas. O seu funcionamento acontece da seguinte forma: atividades de monitoramento e feedback, com reuniões rápidas e diárias com suas equipes de poucos integrantes, visando a identificação e correção de qualquer problema no processo de desenvolvimento. É uma mudança cultural na equipe de trabalho e não quer dizer que ao utilizá-lo, o método em si fará com que o seu cronograma seja cumprindo a risca, isso vai depender de toda a equipe técnica envolvida no processo. Um dos pontos fortes dessa metodologia é a maneira de se relacionar em equipe, ou seja, a parceria em times de profissionais cada um com sua especialidade têm o mesmo grau de comprometimento para a conclusão e o sucesso do projeto.

Extreme Programmimg (XP)

É um modelo de desenvolvimento ágil de software, mais utilizado pelas pequenas e médias empresas, tornou-se popular na década de 90 nos Estados Unidos e atualmente vem crescendo e sendo adotado com bastante freqüência no Brasil. O processo é composto por quatro atividades: Planejamento, Projeto, Codificação e Teste e por quatro diretrizes: Feedback, Comunicação, Simplicidade e Coragem. Um dos pontos propostos por essa metodologia é execução de reuniões de pé, para que cada membro da equipe possa descrever as atividades realizadas no dia anterior de forma clara, rápida e objetiva. Essa metodologia é muito utilizada em projetos cujos requisitos do projeto são sempre alterados. O cliente deve sempre se fazer presente e cabe a ele apontar as prioridades do projeto e dessa forma definir a ordem que as atividades serão executadas.

Feature Driven Development (FDD)

É uma metodologia ágil com grande eficiência e aderência a requisitos, muito utilizada em softwares de tamanho médio e grande. Tornou-se conhecida em 1997, definida por duas fases que são: Concepção e Planejamento e a de Construção, é uma metodologia que agrada tanto o cliente, como os gerentes e desenvolveres. A FDD chama a atenção por algumas características peculiares:

· Resultados úteis a cada duas semanas ou menos;

· Blocos bem pequenos de funcionalidade valorizada pelo cliente, chamados "Features";

· Planejamento detalhado e guia para medição;

· Rastreabilidade e relatórios com incrível precisão;

· Monitoramento detalhado dentro do projeto, com resumos de alto nível para

clientes e gerentes, tudo em termos de negócio;

· Fornece uma forma de saber, dentro dos primeiros 10% de um projeto, se o plano e a estimativa são sólidos;

· O lema da FDD é: "Resultados freqüentes, tangíveis e funcionais."

Adaptive Software Development (ASD)

É uma metodologia utilizada em sistemas grandes e complexos. Ele propõe atualizar o ciclo de desenvolvimento baseado em planejamento, projeto e construção, trocando-o por um com as fases de especulação, colaboração e aprendizado. Para que o desenvolvimento seja realmente adaptativo é necessário que esse novo ciclo tenha as seguintes características: foco na Missão, baseado em funcionalidades, iterativo, períodos fechados (time-boxes), dirigido a risco e tolerante a mudanças.

Modelagem ágil

Quando se fala em software, temos basicamente quatro atividades principais:

· Compreender o que o usuário quer;

· Definir como os elementos de software resolverão as necessidades do usuário;

· Escrever esses elementos de software e integrá-los;

· Testar os elementos e homologá-los com o usuário;

A vantagem em se fazer com que os clientes e usuários participem da modelagem do sistema utilizando artefatos e ferramentas simples, como rascunho em papel, ou no quadro branco, é promover a colaboração e ganhar agilidade na captura de requisitos. Porém, algumas pessoas ou empresas sofrem com o excesso de cerimônia, de forma a não reconhecer artefatos em papel como “Válidos” no processo de desenvolvimento. Isso leva a uma burocratização desnecessária na captura de requisitos ou mesmo na fase de projeto.

A idéia de trabalhar com rascunhos é rapidamente transformá-los em “software funcionado”, de forma que da próxima vez que haja o encontro do engenheiro de requisitos com o cliente possa ser entregue o software a ser homologado e não documentos a serem aprovados.

O desenvolvimento se dá de forma interativa e com entrega constante de software pronto para os stakeholders. Dessa forma, os usuários olham o software e solicitam alterações no próprio software e não nos documentos. Software é a única coisa concreta que realmente validamos com os usuários.

A documentação de requisitos tem como objetivo registrar o que os usuários esperam da aplicação independente da solução técnica.

O Manifesto Ágil buscava (e ainda busca) uma maior valorização do cliente, deixando a negociação de contratos em segundo plano. Entretanto, muitos projetos que fazem uso de metodologias ágeis gastam muito tempo e esforço em negociações contratuais com os clientes.

Um dos grandes desafios para as equipes que trabalham com metodologias ágeis são os contratos estabelecidos entre o vendedor (equipe desenvolvedora) e o cliente. Esses contratos definem o escopo, características, plano, tempo, requisitos e preço do projeto.

Como forma de definir o escopo destes contratos, os gerentes de projetos levam em consideração aspectos como:

· Clientes precisam saber o escopo, tempo e preço para escolher entre múltiplas ofertas em um processo licitatório;

· Clientes acham que eles não terão riscos em seus negócios se a equipe não entregar o que foi acordado;

· Clientes acham que não terão nenhum risco financeiro, pois o preço já foi acordado no início do projeto. Entretanto, muitos gestores de projetos acabam elevando os preços na fase de definição do projeto.

Podemos ainda identificar alguns casos em que o contrato pode funcionar corretamente, tais como:

· Quando a equipe desenvolvedora tem pleno conhecimento do domínio da aplicação, obtendo então uma análise de requisitos com maior eficácia, assim como, evitando os possíveis riscos;

· A equipe de desenvolvimento conhece a tecnologia utilizada e já realizara projetos similares com a mesma;

· Quando o gerente, ou Scrum Master do time, conhece sua equipe. A performance da equipe depende bastante do talento e experiência individual, mas acima de tudo, depende de como os membros da equipe consegue se relacionar entre si. A técnica de programação em pares é uma ótima alternativa para a adaptação de novos membros à equipe de desenvolvimento de forma extremamente rápida;

· Quando a equipe já trabalhou com sistemas de mesmo porte e nível de complexidade antes, pois o gerenciamento de vários times é sempre mais complexo que o gerenciamento de apenas alguns desenvolvedores.

Mudança do comportamento dos gerentes

Ainda há uma grande dificuldade em trabalhar com contratos fixos, pois uma das desvantagens discutidas é que nele os prestadores de serviços incluem acréscimos no orçamento, prevendo uma eventual falha no planejamento.

Vejamos algumas vantagens na utilização dos contratos fixos:

· Foco no valor de negócio: possibilidade de o cliente determinar a ordem de prioridade de acordo com as necessidades do negócio, e não pelos interesses de implementação técnica;

· Maior controle do produto de software por parte do cliente: possibilidade de discutir as inúmeras configurações (features) que serão usadas durante o projeto, como por exemplo, a compatibilidade do browser utilizado pela aplicação, caso ela seja uma aplicação web;

· Facilidade em implementação e modificação dos requisitos no decorrer do projeto: facilidade para inclusão e/ou alteração de novas funcionalidades do software tornando os requisitos estáveis, mas não congelados.

Diferentes opções de trabalho

Outra opção para trair os clientes na adoção de metodologias ágeis é encorajando-os a comprar algumas interações ao invés de assinar contratos para todo o projeto. É importante observar que neste caso deverão ser considerados pequenos módulos de sistemas que possam ser utilizados como piloto nesta avaliação para que não haja a interrupção do projeto.

Além desta, existe a possibilidade de a equipe permitir ao cliente o uso de uma versão experimental do software desenvolvido com a adoção de metodologia ágil, permitindo assim o desenvolvimento com o cliente e provendo a cobertura de risco. Uma vez que os clientes tenham testado algumas interações, então são oferecidas opções de compra de mais interações ou novas features. Com isso o cliente terá a possibilidade de comprovar que não terá riscos eminentes com a adoção da nova metodologia, permitindo-lhe a possibilidade de abortar o projeto, ou seja, se os clientes estiverem insatisfeitos com os resultados, eles terão a liberdade de sair do projeto.

Mantendo o Cliente

O processo de negociação torna-se eficiente quando utilizado para manter um bom relacionamento entre o cliente e os desenvolvedores, uma vez que ambos estão bem informados para justificar as possíveis mudanças de requisitos durante os ciclos de desenvolvimento. É importante manter o cliente sempre na equipe de desenvolvimento, assim ele vai entender o que está sendo construído e confirmar o atendimento das suas necessidades e avaliar o produto funcionando (sempre que possível).

Através da presença freqüente do cliente durante o ciclo de execução do projeto, a equipe consegue medir sua eficácia, assim como definir os ajustes necessários para garantir o alcance dos resultados esperados,o desenvolvimento colaborativo assegura comunicação permanente e produtiva entre a equipe e o cliente, aumentando o nível de aderência do produto final, além de reduzir ocorrências de mal-entendidos e surpresas nas etapas do projeto.

Conclusão

Este conceito de negociação com requisitos mutáveis, auxiliando e motivando as pessoas envolvidas no processo de construção de software, além de propiciar o melhor aproveitamento do tempo e acompanhamento dos custos do projeto, realizando pelos gestores e clientes. Mas ainda encontramos muitos clientes e empresas que adotam a negociação com contrato com metodologias tradicionais.

O desenvolvimento ágil não se limita a um processo que deve ser seguidos a risca para se desenvolver softwares de qualidade, é na verdade, um conjunto de valores importantes no desenvolvimento para que um software consiga obter sucesso.