Caracter´ısticas Comuns

Algumas caracter´ısticas est˜ao presentes em muitos dos m´etodos ´ageis, ou podem ser usadas in-dependentemente da metodologia escolhida, por isso optamos por apresent´a-las antes, e em alguns casos ressaltamos como elas diferem de caracter´ısticas equivalentes emm´etodos tradicionais. Depois, na descri¸c˜ao dos m´etodos, explicamos as pr´aticas que concretizam esses conceitos.

Testes

M´etodos tradicionais tratam a implementa¸c˜ao e os teste como fases completamente distintas. Em m´etodos ´ageis, esta segmenta¸c˜ao tende a desaparecer. Implementa¸c˜ao e testes acontecem muitas vezes juntos: o mesmo programador cria o c´odigo e tamb´em o testa.

A produ¸c˜ao de testes no in´ıcio do projeto facilita a identifica¸c˜ao de problemas e reduz o custo de desenvolvimento do software. Boehm et al. apontam que o custo de encontrar e corrigir erros depois que o software foi entregue pode chegar a 100 vezes mais do que durante as fases de explora¸c˜ao e design [14]. Por isso, em alguns m´etodos ´ageis o conceito de cedo ´e levado ao extremo usando uma t´ecnica que cria os testes antes da implementa¸c˜ao, o Test Driven Development (TDD), com um ciclo de testes e implementa¸c˜ao que dura apenas alguns minutos [6]. Jeffries e Grigori reuniram v´arios relatos de uso de TDD destacando os ganhos de qualidade com esta desta t´ecnica e o esfor¸co extra para a equipe implement´a-la [63].

6Todos os dados sobre o Manifesto ´Agil, a Scrum Alliance e o DSDM Consortium foram coletados em 10/11/2007

Criando testes no desde o in´ıcio do projeto, a equipe pode realiz´a-los com freq¨uˆencia para certificar-se que o software continua sempre atendendo aos requisitos. Para facilitar a realiza¸c˜ao freq¨uente dos testes, metodologias ´ageis os produzem no formato de testes automatizados, assim eles podem ser executados facilmente a qualquer momento, e em especial, sempre que novas imple-menta¸c˜oes forem realizadas.

Desenvolvimento Iterativo

O software ´e produzido iterativamente para oferecer a possibilidade de mudan¸cas funcionais e de prioridade durante a sua constru¸c˜ao. O desenvolvimento incremental prevˆe a possibilidade de entrega do software no fim de cada ciclo de desenvolvimento permitindo que ele entre em fase de produ¸c˜ao mais r´apido, assim o seu uso pode contribuir com feedback para direcionar o restante do desenvolvimento.

O crescimento incremental pode usar duas abordagens, conforme os interesses de neg´ocio. A primeira ´e acrescentar funcionalidades `a medida que o software cresce, a segunda ´e evoluir funciona-lidades junto com o sistema. Na primeira, as funcionafunciona-lidades s˜ao feitas completamente e entregues uma por vez, no segundo caso elas s˜ao implementadas de forma simplificada para entrarem em produ¸c˜ao rapidamente e depois podem ser completadas nas pr´oximas itera¸c˜oes.

Colabora¸c˜ao

Clientes e usu´arios est˜ao mais pr´oximos dos desenvolvedores e acompanham a evolu¸c˜ao do pro-duto. O contato constante com o cliente permite feedback r´apido e facilita a comunica¸c˜ao. Com mais comunica¸c˜ao a vis˜ao dos participantes sobre o andamento do projeto torna-se mais apurada, evitando que surpresas aconte¸cam no fim do projeto. A identifica¸c˜ao e resolu¸c˜ao de problemas torna-se mais r´apida e as prioridades, escopo e detalhes da implementa¸c˜ao podem ser negociados com mais facilidade.

Estimativas

Processos ´ageis usam estimativas ao inv´es de predi¸c˜oes. Estimativas s˜ao compostas por uma dupla de valores < v, p >, onde v ´e um palpite sobre determinado evento, e p ´e a probabilidade de v acontecer. Com a probabilidade associada ao valor estimado, a equipe sente-se mais confort´avel para fazer previs˜oes e o cliente toma ciˆencia do grau de incerteza associado a elas.

Estimativas de longo prazo geralmente possuem graus maiores de incerteza associados. `A medida que o tempo passa e o conhecimento sobre o assunto aumenta, as estimativas podem ser refeitas considerando um n´ıvel maior de detalhes e associando probabilidades de sucesso mais altas.

Cada funcionalidade, ou grupo de funcionalidades, ´e estimado usando uma escala com valores pr´e-estabelecidos. Cohn sugere o uso de escalas com n´umeros de Fibonacci (1, 2, 3, 5, 8, 13,...) ou com potˆencias de 2 (1, 2, 4, 8, 16, 32,...), pois s˜ao seq¨uˆencias exponenciais que ir˜ao absorver parte do erro e da incerteza associada `as estimativas de tarefas grandes [25]. Opcionalmente, a equipe pode incluir o 0 (zero) na escala para estimar tarefas triviais, depois, muitas tarefas triviais podem ser agrupadas e receber tamanho 1, afinal, mesmo sendo triviais, tomar˜ao algum tempo para ser realizadas.

A escala usada para estimar pode representar pontos ou dias ideais. Os pontos s˜ao medidas abstratas definidas pela equipe a partir de uma tarefa pequena que ela considera como sua unidade, e os demais valores da escala s˜ao atribu´ıdos `as funcionalidades por compara¸c˜ao com esta unidade. Um dia ideal ´e o quanto seria produzido em um dia de trabalho se 100% do tempo fosse dedicado a uma atividade, sem interrup¸c˜oes ou distra¸c˜oes. Para este caso, a equipe precisa perceber a porcentagem de tempo que ela, de fato, se dedica ao projeto, para identificar o fator de convers˜ao entredias ideais e dias reais.

As duas medidas, pontos edias ideais, fornecem estimativas de tamanho, que s˜ao medidas sobre o volume de trabalho. Al´em dessas, ´e interessante obter estimativas de dura¸c˜ao, que prevˆeem a quantidade de tempo necess´aria para realizar o trabalho. Contudo, a partir deestimativas de tamanho e davelocidade de desenvolvimento da equipe⁷, ´e poss´ıvel obterestimativas de dura¸c˜ao.

De qualquer forma, ´e importante que medidas detamanhoedura¸c˜aofiquem separadas, pois a velocidade da equipe pode variar durante o projeto. Isso influencia as estimativas de dura¸c˜ao, que s˜ao as que os clientes est˜ao mais interessados, e obriga a equipe a refazˆe-las. Baseando as estimativas no tamanho, quando a velocidade de desenvolvimento mudar, basta identificar a velocidade atual e derivar as novas estimativas de dura¸c˜ao.

Negocia¸c˜ao

No desenvolvimento, de software, o planejamento e o produto final est˜ao relacionados com quatro vari´aveis interdependentes: tempo,custo,escopoequalidade, de forma que, a altera¸c˜ao do valor

7A velocidade da equipe ´e a quantidade de pontos estimados que ela consegue entregar a cada itera¸c˜ao.

de qualquer uma delas influencia as outras [9]. Portanto, assumindo essa dependˆencia, podemos representar essas rela¸c˜oes atrav´es de uma equa¸c˜ao:

α·Qualidade +β·Custo =γ·Tempo +δ·Escopo ondeα, β, γ e δ s˜ao constantes n˜ao negativas.

Agora, considerando as vari´aveis duas a duas, e fixando o valor das demais, a Tabela 2.2mostra o seu comportamento quando uma delas sofre altera¸c˜ao. Os s´ımbolos “+” e “−” representam, respectivamente, se a varia¸c˜ao de uma delas muda direta ou inversamente o valor da outra, ou seja, se o aumento da primeira eleva ou reduz o valor da segunda.

Tempo Custo Qualidade Escopo

Tempo + − + +

Custo − + + +

Qualidade + + + −

Escopo + + − +

Tabela 2.2: Rela¸c˜ao de dependˆencia entre vari´aveis do projeto, analisadas duas a duas.

Da Tabela 2.2, percebemos que h´a apenas duas rela¸c˜oes inversas: tempo e custo, e qualidade e escopo. Para as outras rela¸c˜oes, o aumento ou diminui¸c˜ao no valor de um dos lados, causa um efeito de mesma orienta¸c˜ao na outra vari´avel. Com essa an´alise vemos que n˜ao ´e razo´avel modificar essas vari´aveis isoladamente.

M´etodos ´ageis tem como objetivo sempre entregar software testado e com o m´ınimo de erros, por isso consideram a qualidade como uma vari´avel fixa com valor alto. O principal custo de de-senvolvimento fica definido pelo tamanho da equipe, desta forma, o planejamento e as negocia¸c˜oes com clientes baseiam-se em ajustes no tempo e no escopo, duas vari´aveis diretamente relacionadas de muito interesse dos clientes, que tendem a querer aumentar o escopo e diminuir o tempo. Para evitar planejamentos e negocia¸c˜oes inconsistentes, que diminuam o tempo sem mexer noescopo, ou que aumentem o escopo sem mudar o prazo, modelos ´ageis tˆem a proposta de guiar o desenvolvi-mento pelas prioridades de neg´ocio, permitindo que o cliente primeiro defina as datas de entrega, e a negocia¸c˜ao segue entre clientes e desenvolvedores para acordar sobre o escopo.

Prioriza¸c˜ao

M´etodos ´ageis baseiam-se fortemente na adapta¸c˜ao a mudan¸cas. As estrat´egias de planejamento focam em planos detalhados para o curto prazo e mais superficiais para o futuro distante. Desta forma, ´e poss´ıvel uma vis˜ao panorˆamica para guiar as decis˜oes no longo prazo e precis˜ao nas atividades do dia-a-dia. As duas principais vantagens desta abordagem s˜ao: 1) economia de esfor¸co ao abrir m˜ao do detalhamento de longo prazo, pois ´e dif´ıcil fazer previs˜oes sobre o futuro e a alta chance de mudan¸cas durante a execu¸c˜ao invalida facilmente especifica¸c˜oes minuciosas; 2) detalhes no longo prazo trazem a falsa sensa¸c˜ao de certeza, pois os indiv´ıduos passam a tratar previs˜oes detalhadas como predi¸c˜oes [94].

Equipes ´ageis revˆeem seus planos constantemente. A cada planejamento, ela tem a oportunidade de avaliar as condi¸c˜oes do projeto, e baseada nesses fatos, tra¸car o melhor caminho para atingir seus objetivos. Esta estrat´egia mant´em os planos e a execu¸c˜ao sempre adequados `a realidade, que inexo-ravelmente est´a em muta¸c˜ao. Isso significa identificar prioridades para cada momento do projeto.

Identificar prioridades nem sempre ´e ´obvio ou natural. Jim Jonhson j´a ressaltou as conseq¨uˆencias de m´a prioriza¸c˜ao: 64% das funcionalidades raramente ou nunca s˜ao usadas [67]. Isto explicitamente significa desperd´ıcio, pois essas funcionalidades poderiam n˜ao ter sido produzidas, ou sido substitu´ıdas por outras mais relevantes. Para resolver este problema, a prioriza¸c˜ao pode ser guiada pelo valor de neg´ocios das funcionalidades. Algumas t´ecnicas determinam as prioridades baseadas em estimativas de volume de trabalho, tempo de desenvolvimento e dificuldade de implementa¸c˜ao (fornecidas pela equipe de desenvolvimento), combinadas com dependˆencias associadas `as regras de neg´ocio e `a vis˜ao do cliente. Em especial, destacamos trˆes t´ecnicas que utilizam esses dados como insumo para a obten¸c˜ao das prioridades: aPondera¸c˜ao por Pesos Relativos[25], aPrioriza¸c˜ao por Valor e Risco[25], e oModelo de Satisfa¸c˜ao do Cliente [70].

A Pondera¸c˜ao por Pesos Relativosconsidera trˆes valores para cada funcionalidade: ocusto, representado pelas estimativas de tamanho (pontos) feitas pela equipe de desenvolvimento; obenef´ıcio definido pelo cliente considerando o valor que a funcionalidade agrega ao software; e umapenalidade, que corresponde a um potencial preju´ızo caso a funcionalidade esteja ausente⁸.

8Por exemplo, alguns sistemas da ´area m´edica e financeira precisam que todas as suas opera¸c˜oes atendam a exigˆencias legais. Do ponto de vista do usu´ario, essas conformidades n˜ao s˜ao percept´ıveis, por isso o benef´ıcio dessa caracter´ıstica

´

e muito baixo, ou zero, e a penalidade ´e alta, pois sua ausˆencia implica em um grande risco para o projeto ou para a empresa, expondo-a a multas e a processos jur´ıdicos e criminais.

Para cada funcionalidadef, os pontos debenef´ıcio e depenalidade s˜ao somados e depois divididos pela soma dos totais das duas medidas no projeto. O valor obtido ser´a o% de valorda funcionalidade:

%valor_f = benef iciof +penalidadef

Pn

k=1(benef icio_k+penalidade_k)

Para o custo tamb´em ´e calculado o % do custo de cada funcionalidade no projeto:

%custo_f = pontos_f Pn

k=1pontosk

Aprioridadeent˜ao ´e naturalmente conseguida pela rela¸c˜ao entre os percentuais devalor ecusto:

P rioridade_f = %valorf

%custo_f

A Prioriza¸c˜ao por Valor e Risco considera estas duas vari´aveis: o valor de neg´ocios e a dificuldade de implementa¸c˜aode cada funcionalidade, ou seja, o risco de n˜ao ser poss´ıvel, ou demorar para desenvolver. O cliente determina a primeira, e a equipe de desenvolvimento, a segunda medida a as exp˜oe em um gr´afico onde os eixos s˜ao justamentevalor e risco (Figura 2.3). Para esta t´ecnica n˜ao ´e preciso definir uma escala e pontuar valor e risco com precis˜ao num´erica porque ao dispˆo-los no gr´afico, ser´a poss´ıvel visualizar as funcionalidades, e comparativamente determinar as que mais agregam valor ou acrescentam dificuldades.

Depois que as funcionalidades estiverem dispostas no plano, a prioriza¸c˜ao ´e feita dividindo-o em quadrantes e a prioridade mais alta vai para as funcionalidades do quadrante comvalor erisco altos.

Fazˆe-las primeiro ´e interessante porque quando estiverem conclu´ıdas, haver´a uma grande quantidade de valor agregado ao software e ao mesmo tempo, uma grande quantidade de risco ter´a sido eliminada do projeto. Caso n˜ao seja poss´ıvel produz´ı-las, ou a dificuldade torne a implementa¸c˜ao muito mais demorada do que o previsto, isso ´e identificado cedo e as estimativas s˜ao ajustadas no in´ıcio do projeto.

Em seguida, conforme a Figura 2.4, s˜ao feitas as funcionalidades do quadrante comalto valor e baixo risco, depois aquelas com baixo valor e baixo risco, e por ´ultimo, se ainda forem necess´arias, as funcionalidades que de grande dificuldade que agregam pouco valor. Algumas vezes, o ´ultimo

Figura 2.3: Exemplo de constru¸c˜ao do gr´afico de Valor e Risco.

quadrante n˜ao chega a ser implementado porque o software j´a atende as necessidades dos usu´arios e o investimento para produzir funcionalidades dif´ıceis que acrescentam pouco valor n˜ao compensa.

Figura 2.4: Prioridade dos quadrantes do gr´afico de Valor e Risco.

O Modelo de Satisfa¸c˜ao do Cliente proposto por Noriaki Kano para o desenvolvimento de produtos, n˜ao necessariamente software, classifica as preferˆencias os usu´arios em rela¸c˜ao `as carac-ter´ısticas do produto em seis categorias. Dessas categorias, trˆes delas influenciam na satisfa¸c˜ao:

• Caracter´ısticas B´asicas (B): causam descontentamento se estiverem ausentes mas n˜ao levam

`

a satisfa¸c˜ao quando presentes.

• Caracter´ısticas de Desempenho (D): a quantidade e a qualidade influem diretamente na satisfa¸c˜ao, podendo levar o usu´ario `a satisfa¸c˜ao ou ao descontentamento.

• Caracter´ısticas Excitantes (E): aumentam a satisfa¸c˜ao quando presentes, e n˜ao causam descontentamento se estiverem ausentes.

As outras categorias menos relevantes s˜ao: Reverso (R), Question´avel (Q) e Indiferente (I). Na Figura2.5, podemos ver como a presen¸ca das trˆes principais categorias se relaciona com a satisfa¸c˜ao do cliente.

Figura 2.5: Rela¸c˜ao entre a satisfa¸c˜ao do cliente e a presen¸ca de caracter´ısticas b´asicas, de desempenho e excitantes.

Para identificar a qual categoria cada caracter´ıstica (ou funcionalidade, no caso de software) per-tence, Kano recomenda a aplica¸c˜ao de duas perguntas sobre ela, uma funcional e outra desfuncional:

• Q1 - Como vocˆe se sentiria se esta caracter´ıstica estivesse presente?

• Q2 - Como vocˆe se sentiria se esta caracter´ıstica n˜ao estivesse presente?

Para cada quest˜ao, uma das cinco alternativas deve ser escolhida como resposta:

• R1 - Eu gostaria.

• R2 - Eu espero que seja assim.

• R3 - Tanto faz.

• R4 - Eu posso viver assim.

• R5 - Eu n˜ao gostaria.

O cruzamento das respostas no gabarito da Tabela 2.3 classifica a funcionalidade entre as cate-gorias e determinam se ela influi ou n˜ao na satisfa¸c˜ao do cliente.

Q2

R1 R2 R3 R4 R5

R1 Q E E E D

Q1 R2 R I I I B

R3 R I I I B

R4 R I I I B

R5 R R R R Q

Tabela 2.3: Tabela de Avalia¸c˜ao de Kano