Prix final au consommateur, toutes taxes comprises (TTC)

Dentro desta vis˜ao de focar nos requisitos que agregam valor ao cliente, alguns arti- gos e trabalhos apontam para uma tendˆencia de m´etodos ´ageis para endere¸car este fator e alcan¸car a produtividade. Muitas pr´aticas mapeadas nos m´etodos ´ageis s˜ao boas es- trat´egias para melhoria de produtividade, entretanto suas origens s˜ao de uma coletˆanea de trabalhos cient´ıficos e estudos de casos publicados e comentadas ao longo dos anos. As estrat´egias - mapeadas como pr´aticas nas metodologias ´ageis - foram documentadas neste trabalho, mas dando o m´erito da estrat´egia para os autores da primeira cita¸c˜ao. De qualquer maneira, a populariza¸c˜ao desta coletˆanea justifica uma boa descri¸c˜ao.

3.5 ´ultimas contribui¸c˜oes (2000-2009) 42 [Highsmith 01b], onde representantes de v´arias metodologias ´ageis se uniram para, se- gundo os assinantes do manifesto, descobrir formas melhores para desenvolver software. O manifesto defende os seguintes valores:

• Indiv´ıduos e itera¸c˜ao sobre processos e ferramentas; • Software execut´avel sobre documenta¸c˜ao extensa;

• Colabora¸c˜ao com o cliente sobre negocia¸c˜ao de contratos; • Responder a mudan¸cas sobre seguir o plano.

A id´eia dominante do desenvolvimento ´agil ´e que o time pode ser mais efetivo na resposta a mudan¸cas, por reduzir o custo de mover a informa¸c˜ao entre as pessoas e ainda por reduzir o tempo entre a tomada de decis˜ao e realizar o que foi decidido e ver suas conseq¨uˆencias [Cockburn 01]. Cocoburn e Highsmith afirmam que o desenvolvimento ´agil foca no talento e habilidade dos indiv´ıduos, moldando o processo para pessoas espec´ıfi- cas e times espec´ıficos. Os autores ainda apontam que os times ´ageis ficam fisicamente pr´oximos, substituem documenta¸c˜ao por conversas e s˜ao auto-organizados. Em outro artigo no mesmo ano os autores afirmam que a estrat´egia dos m´etodos ´ageis ´e reduzir o custo das mudan¸cas o que pede que os times ´ageis realizem a primeira entrega em sema- nas, criem solu¸c˜oes simples e melhorem sua qualidade continuamente fazendo a pr´oxima implementa¸c˜ao mais barata, e testando constantemente. Tudo isso com proximidade e itera¸c˜ao cont´ınua [Highsmith 01a].

Mais uma vez temos a afirma¸c˜ao de que cada organiza¸c˜ao e ainda cada projeto deve ser tratado separadamente pelas suas caracter´ısticas espec´ıficas. N˜ao existe um modelo ideal ou uma estrat´egia ideal para todas as organiza¸c˜oes, ´e preciso analisar as caracter´ısticas de cada projeto e ainda a cultura da organiza¸c˜ao para defini¸c˜ao de seu conjunto de estrat´egias.

Autores j´a citados neste trabalho apontam para a ado¸c˜ao de um processo iterativo e adaptativo como a melhor maneira de lidar com estas mudan¸cas. Os modelos de processo incrementais ou evolutivos tentam lidar com esses problemas, assim como as metodologias ´

ageis e os processos ´ageis tamb´em.

Uma das justificativas para a classe ´agil de processo de software ´e que requisitos dos clientes mudam com freq¨uˆencia [Reed 04]. Os autores comentam que segundo a sabedoria convencional, mudan¸ca de requisitos continua inevit´avel e at´e pode ter um efeito positivo no ambiente, neg´ocios ou entendimento das opera¸c˜oes de desenvolvimento ao longo do tempo. Por outro lado, eles afirma que a coleta informal das solicita¸c˜oes de mudan¸cas

3.5 ´ultimas contribui¸c˜oes (2000-2009) 43 de requisitos pode aumentar a probabilidade de caracter´ısticas mais importantes n˜ao serem implementadas inicialmente, o que normalmente quer dizer que elas nunca ser˜ao implementadas. Os autores ainda apontam a prototipa¸c˜ao como uma estrat´egia conhecida para lidar com problemas de defini¸c˜ao dos requisitos do cliente quando o sistema finalizado pode ter um grande impacto nas expectativas do cliente.

Ainda em [Reed 04], os autores definem o termo time-box como ciclos de desenvolvi- mento bem definidos. Segundo eles estas janelas de tempo definem momento de in´ıcio e fim para ciclos de desenvolvimento, prevenindo grandes mudan¸cas de esfor¸co durante o projeto. A id´eia ´e que qualquer que seja o tamanho desta janela, o cliente seleciona os requisitos mais importantes para serem desenvolvidos e os desenvolvedores fazem o m´a- ximo poss´ıvel para ficarem de fato pronto dentro daquela janela de tempo. Essas janelas, quando definidas para atividades, normalmente s˜ao de quatro a dezesseis horas.

Beck aponta que XP (eXtreme Programming ou Programa¸c˜ao Extrema) ´e uma metodologia para times pequenos e m´edios que desenvolvem software em face a requi- sitos vagos, que se modificam rapidamente [Beck 04]. A estrat´egia de gerenciamento no XP est´a na tomada de decis˜ao descentralizada. Numa vis˜ao geral da metodologia, o autor descreve as pr´aticas de XP, dentre elas algumas podem ser entendidas como es- trat´egias para endere¸car alguns fatores, e ser˜ao mapeadas posteriormente em conjunto com estrat´egias semelhantes. Entre elas:

• Jogo do planejamento - envolvimento de todos no planejamento, onde a ´area de neg´ocios precisa da ´area de desenvolvimento para tomar decis˜oes t´ecnicas, antecipar riscos t´ecnicos.

• Entregas freq¨uentes - uma entrega com o menor tamanho poss´ıvel, com o maior valor para o neg´ocio.

• Projeto simples - a coisa mais simples que pode funcionar. A equipe de um projeto simples se comunica melhor; a simplicidade garante a f´acil execu¸c˜ao; um r´apido feedback j´a que o projeto simples termina rapidamente; por fim, a coragem de fazer apenas uma pequena parte do projeto, sabendo que se for necess´ario acrescenta-se depois.

• Propriedade coletiva - todos conhecem pelo menos um pouco de todo o sistema, a qualquer momento ao observar uma oportunidade de melhoria no c´odigo ela ser´a implementada.

3.5 ´ultimas contribui¸c˜oes (2000-2009) 44 • Cliente presente - um cliente real - que v´a de fato usar o sistema - deve estar

dispon´ıvel para responder as quest˜oes.

• Padr˜oes de codifica¸c˜ao - o padr˜ao adotado deve exigir a menor quantidade de tra- balho poss´ıvel, consistentes com a regra “uma e somente uma vez”(sem c´odigo du- plicado).

Da vis˜ao apresentada foi mapeada a participa¸c˜ao da equipe t´ecnica no planejamento, as entregas freq¨uentes em conjunto com modelos iterativos, simplicidade no c´odigo, ado¸c˜ao de padr˜oes e ainda a participa¸c˜ao do cliente quando poss´ıvel. Quanto `a sim- plicidade do c´odigo, levantamos que a¸c˜oes para efetivar esta premissa s˜ao extremamente relevantes, j´a que a complexidade do software foi um dos fatores mais citados nesta pesquisa bibliogr´afica. Portanto este foi um ponto endere¸cado neste trabalho. A partici- pa¸c˜ao do cliente tamb´em ´e uma pr´atica relevante, citada por muitos trabalhos analisados como sendo positiva para a produtividade, tamb´em ´e uma estrat´egia a ser adotada quando poss´ıvel.

H´a autores que defendem que a ado¸c˜ao de apenas algumas pr´aticas sugeridas pela metodologia ´agil n˜ao ´e eficaz. Shore e Warden [Shore 08] afirmam que criar um m´etodo ´

agil totalmente novo n˜ao ´e uma id´eia muito boa, j´a que existe muito mais no desenvolvi- mento ´agil do que suas pr´aticas. De qualquer maneira, algumas pr´aticas citadas pelos autores, s˜ao vistas como estrat´egias para melhoria de produtividade. Algumas cita¸c˜oes dos autores s˜ao corroboradas por outros autores e ser˜ao apontadas no mapeamento das estrat´egias. Dentre elas destacamos: “Prefira melhor `a maior.”, onde os autores se referem a pessoas mais experientes do que a um n´umero maior de pessoas; e “sua produtividade pode melhorar instantaneamente remanejando pessoas para apenas um projeto de cada vez... A atribui¸c˜ao fracionada ´e extremamente contra-produtiva.”

O livro ´e uma rica referˆencia para quem deseja seguir o conselho dos autores e adotar toda a XP ou em nossa vis˜ao parte dela, pela simplicidade adotada e abrangˆencia na descri¸c˜ao de cada pr´atica. Dentre as pr´aticas citadas, as mais relevantes para este tra- balho s˜ao: trabalho energizado, espa¸co de trabalho informativo, confian¸ca, sentar junto, reuni˜oes r´apidas, ado¸c˜ao de padr˜oes e equipes inter-funcionais e auto-organizadas.

J´a o Scrum ´e um processo simples para lidar com projetos complexos [Schwaber 04]. A metodologia adota algumas das estrat´egias j´a citadas - uso do time-box, times pequenos, auto-organizados entre outros - e afirma conseguir: uma gest˜ao efetiva de requisitos de- sconhecidos ou em mudan¸ca; simplifica¸c˜ao da cadeia de comando com a auto-gest˜ao; constru¸c˜ao de produtos e entrega em 30 dias; e evitar perdas atrav´es de inspe¸c˜oes regu- lares, maximizando o retorno do investimento.

3.5 ´ultimas contribui¸c˜oes (2000-2009) 45 Para encerrar esta breve revis˜ao da contribui¸c˜ao dos m´etodos ´ageis para estrat´egias de melhoria de produtividade, temos uma vis˜ao comparativa entre a abordagem tradicional baseada em processo e baseada na agilidade por Boehm e Turner [Boehm 03]. Suas observa¸c˜oes mostraram que as duas abordagens, tanto a ´agil quanto a tradicional com foco em processo, s˜ao dois meios para o mesmo fim: satisfazer clientes com software que atendem suas necessidades, dentro dos custos e prazos. O artigo ´e apenas um resumo de um trabalho mais aprofundado realizado tamb´em em conjunto com Turner. Os autores defendem que ambas as abordagens podem ser caracterizadas como “lead bullets”. Por fim eles afirmam que estrat´egias vˆem surgindo para integrar as duas abordagens de forma a tirar vantagem dos pontos fortes e evitar os pontos fracos. Mesmo analisando apenas o resumo do trabalho ´e evidente que o ideal ´e somar as boas pr´aticas, os sucessos e n˜ao ter que escolher de forma excludente. Para gerir um projeto ´e preciso todas as armas dispon´ıveis, sejam elas oriundas de uma vis˜ao mais ´agil ou de uma vis˜ao mais focada em processo.