Quais são as melhores técnicas e métodos da engenharia de software?

�

Como uma resposta �s crescentes press�es por inova��o em prazos cada vez mais reduzidos, �s necessidades de constantes mudan�as de requisitos e ao mau desempenho de grande parte dos projetos de desenvolvimento de software, houve um movimento na comunidade de desenvolvimento de software que deu origem aos M�todos �geis. Posteriormente, o conceito-base deste movimento evoluiu, de uma abordagem t�cnica para o �mbito gerencial, criando um novo enfoque de gerenciamento de projetos � o Gerenciamento �gil de Projetos.

Neste artigo s�o apresentados o hist�rico, o conceito, os valores e os princ�pios que norteiam os M�todos �geis, assim como s�o descritos os m�todos mais frequentemente utilizados pelas organiza��es. Tamb�m s�o exploradas as suas limita��es, as indica��es de aplica��o e os resultados obtidos por empresas que j� os adotaram. Por fim, s�o discutidos os fatores cr�ticos de sucesso de projetos de desenvolvimento de software conduzidos com o uso desses m�todos.

Defini��o e Origem dos M�todos �geis de Desenvolvimento de Software

Os M�todos �geis de Desenvolvimento de Software surgiram como uma rea��o aos m�todos cl�ssicos de desenvolvimento e do reconhecimento da necessidade premente de se criar uma alternativa a estes �processos pesados�, caracterizados pelo foco excessivo na cria��o de uma documenta��o completa (BECK, et al, 2001). Em meados dos anos 90, integrantes da comunidade de desenvolvimento de software come�aram a questionar estes processos, julgando-os pouco efetivos e, muitas vezes, imposs�veis de serem colocados em pr�tica (HIGHSMITH, 2002).

Sintetizando o pensamento deste grupo, Highsmith (Ibid.) menciona que a ind�stria e a tecnologia sofrem modifica��es t�o aceleradas que acabam por �atropelar� os m�todos cl�ssicos. Highsmith et al (2002) ainda acrescentam que os clientes, na maioria das vezes, s�o incapazes de definir de forma clara e precisa, os requisitos do software, logo no in�cio de um projeto de desenvolvimento, o que inviabiliza a ado��o dos m�todos cl�ssicos em muitos projetos.

Como resposta a esta situa��o, muitos especialistas criaram m�todos pr�prios para se adaptar �s constantes mudan�as exigidas pelo mercado e �s indefini��es iniciais dos projetos. O agrupamento desses m�todos deu origem � fam�lia dos M�todos �geis de Desenvolvimento de Software. Sendo assim,

�

�[...] os M�todos �geis podem ser considerados uma colet�nea de diferentes t�cnicas e m�todos, que compartilham os mesmos valores e princ�pios b�sicos, alguns dos quais remontam de t�cnicas introduzidas em meados dos anos 70, como os desenvolvimentos e melhorias iterativos� (COHEN et al, 2003, p.2).

�

De fato, Cockburn e Highsmith (2001a) j� haviam afirmado que a maioria das pr�ticas propostas pelos M�todos �geis n�o tem nada de novo e que a diferen�a recai principalmente sobre o foco e os valores que os sustentam.

Segundo Cohen et al (2003), um dos primeiros questionamentos aos m�todos cl�ssicos de desenvolvimento de software foi feito por Schwaber, criador do Scrum. Para entender melhor os m�todos cl�ssicos de desenvolvimento de software baseados no SW-CMM, Schwaber (2002) elaborou um estudo junto aos cientistas da DuPont, que tinha por objetivo responder a seguinte pergunta: �Por que os processos definidos e defendidos pelo SW-CMM n�o promovem entregas consistentes�? Ap�s analisarem seus processos de desenvolvimento de software, os cientistas chegaram � conclus�o que, apesar do SW-CMM buscar a consist�ncia, a previsibilidade e a confiabilidade dos processos de desenvolvimento de software, muitos destes processos ainda eram, de fato, imprevis�veis e imposs�veis de serem repetidos. A explica��o para tal reca�a na complexidade dos processos propostos pelo SW-CMM, na conseq�ente dificuldade de aplica��o e tamb�m na necessidade de mudan�as constantes e dif�ceis de serem antecipadas.

Schwaber (op. cit.) percebe que para que o desenvolvimento de software seja realmente �gil, deve-se aceitar as mudan�as, ao inv�s de dar foco extremo � previsibilidade. Quase que simultaneamente, outros especialistas no assunto chegam � conclus�o de que m�todos que respondam �s mudan�as, t�o rapidamente quanto estas venham a surgir e que incentivem a criatividade, s�o a �nica maneira de enfrentar e gerenciar os problemas do desenvolvimento de software em ambientes complexos (COCKBURN; HIGHSMITH, 2001a, SCHWABER, 2002).

Neste mesmo per�odo, modelos de processos aplicados a outras ind�strias, come�am a ser analisados para servir como fonte de inspira��o ao aprimoramento do processo de desenvolvimento de software (POPPENDIECK, 2001). O Modelo Toyota de Produ��o foi alvo de aten��o especial: enquanto as unidades fabris americanas trabalhavam a 100% de sua capacidade e mantinham grandes volumes de invent�rio de mat�rias-primas e de produtos acabados, a f�brica da Toyota mantinha o n�vel de estoque suficiente para um dia de opera��o e produzia somente o necess�rio para atender aos pedidos j� colocados. Este modelo traduzido no princ�pio da Lean Manufacturing, visava � utiliza��o mais eficiente dos recursos e a redu��o de qualquer tipo de desperd�cio e estava totalmente alinhado � filosofia da Administra��o da Qualidade Total, criada pelo Dr. Edwards Deming (POPPENDIECK, 2001; FERREIRA et al, 2002). Deming (1990) acreditava que as pessoas desejavam fazer um bom trabalho e que os gerentes deveriam permitir que os trabalhadores do ch�o de f�brica tivessem autonomia para a tomada de decis�es e a resolu��o de problemas. Al�m disso, estimulava o estabelecimento de uma rela��o de confian�a com os fornecedores e defendia uma cultura de melhoria cont�nua dos processos e dos produtos. Enquanto as unidades fabris japonesas geravam produtos cada vez melhores e mais baratos, as f�bricas americanas n�o conseguiam fazer o mesmo.

Com base nesta avalia��o, Poppendieck (2001) listou 10 pr�ticas que tornavam a Lean Manufacturing t�o bem-sucedida e que, em seu entendimento, poderiam ser adaptadas e aplicadas ao desenvolvimento de software:

1.��� Elimina��o de gastos � eliminar ou reduzir diagramas e modelos que n�o agregam valor ao produto final;

2.��� Minimiza��o de invent�rio � minimizar artefatos intermedi�rios, como documentos de requisitos e de desenho;

3.��� Maximiza��o do fluxo � utilizar o desenvolvimento iterativo para redu��o do prazo de entrega do software;

4.��� Atendimento � demanda � atender �s mudan�as de requisitos;

5.��� Autonomia aos trabalhadores � compartilhar a documenta��o e dizer aos programadores �o que� precisa ser feito e n�o �como� deve ser feito;

6.��� Atendimento aos requisitos dos clientes � trabalhar perto dos clientes, permitindo que eles mudem suas opini�es ou seus desejos;

7.��� Fazer certo da primeira vez � testar o quanto antes e refazer o c�digo se necess�rio;

8.��� Aboli��o da otimiza��o local � gerenciar o escopo de forma flex�vel;

9.��� Desenvolvimento de parceria com os fornecedores � evitar rela��es conflitantes, tendo em mente que todos devem trabalhar juntos para gerar o melhor software;

10. Cultura de melhoria cont�nua � permitir que o processo seja melhorado, que se aprenda com os erros e se alcance o sucesso.

�

Highsmith (2002) afirma, que de forma independente, Kent Beck e Ron Jeffreis percebem a import�ncia dos princ�pios defendidos por Poppendieck (2001) durante um projeto de desenvolvimento de software na Chrysler e criam o� projeto Extreme Programming� (XP), um dos M�todos �geis de maior express�o atualmente. Simultaneamente, outras hist�rias come�am a ecoar pelo mundo, como a vivenciada por Alistair Cockburn, que entrevistando profissionais do IBM Consulting Group, percebe que equipes de projetos bem-sucedidos se desculpavam por n�o ter seguido os processos formais, por n�o utilizar as ferramentas de alta tecnologia e por ter �simplesmente� trabalhado de forma pr�xima e integrada, enquanto membros de projetos malsucedidos afirmavam ter seguido as regras e processos e que n�o entendiam o que havia dado errado. Com base nesta experi�ncia, Cockburn desenvolveu o Crystal Method, outro M�todo �gil (HIGHSMITH, 2002).

Face ao exposto, percebe-se que o mundo do desenvolvimento de software passa por uma importante transforma��o: os m�todos cl�ssicos s�o vistos como n�o adequados a todas as situa��es e os especialistas reconhecem a necessidade de cria��o de novas pr�ticas, orientadas a pessoas e flex�veis o suficiente para fazer frente a um ambiente de neg�cio din�mico (COCKBURN; HIGHSMITH, 2001a). Os principais desafios enfrentados e que devem ser endere�ados pelos novos m�todos de desenvolvimento de software s�o assim sumarizados por Cockburn e Highsmith (Ibid.):

1.��� A satisfa��o dos clientes passar a ter preced�ncia frente � conformidade aos planos;

2.��� As mudan�as sempre ocorrem � o foco deixa de ser como evit�-las e passa a ser como abra��-las e como minimizar o seu custo ao longo do processo de desenvolvimento;

3.��� A elimina��o das mudan�as pode significar menosprezar condi��es importantes do neg�cio, ou seja, pode levar ao insucesso de uma organiza��o;

4.��� O mercado espera um software inovador, com alta qualidade, que atenda aos requisitos do neg�cio e que esteja dispon�vel em prazos cada vez menores.

Manifesto para o Desenvolvimento �gil de Software

No in�cio de 2001, criadores e representantes dos chamados M�todos �geis de Desenvolvimento de Software � Extreme Programming, Scrum, Dynamic Systems Development Method, Adaptative Software Development, Crystal Methods, Feature-Driven Development, Lean Development, entre outros � se reuniram nos Estados Unidos para discutir alternativas aos tradicionais �processos pesados� de desenvolvimento de software (BECK et al, 2001). Estes especialistas foram enf�ticos em dizer que n�o eram contra m�todos, processos ou metodologias, sendo que muitos at� mencionaram o desejo de resgatar o verdadeiro significado e a credibilidade destas palavras. Defendiam a modelagem e a documenta��o, mas n�o em excesso. Planejavam, mas reconheciam os limites do planejamento e da previsibilidade num ambiente turbulento (BECK et al, 2001).

A ess�ncia deste movimento � a defini��o de novo enfoque de desenvolvimento de software, calcado na agilidade, na flexibilidade, nas habilidades de comunica��o e na capacidade de oferecer novos produtos e servi�os de valor ao mercado, em curtos per�odos de tempo (HIGHSMITH, 2004, p. xix). Como agilidade deve-se entender �a habilidade de criar e responder a mudan�as, buscando a obten��o de lucro, em um ambiente de neg�cio turbulento� (HIGHSMITH, 2004, p. 16); ou ainda, �a capacidade de balancear flexibilidade e estabilidade� (Id., 2002). A agilidade n�o deve ser vista como falta de estrutura, mas est� diretamente relacionada � capacidade de adapta��o a situa��es diversas e inesperadas. Highsmith (2004, p. 16) enfatiza que a aus�ncia de estrutura ou de estabilidade pode levar ao caos, mas que estrutura em demasia gera rigidez.

Como resultado do encontro, foi criada a Agile Alliance, sendo publicado o Manifesto para Desenvolvimento �gil de Software ou o Manifesto for Agile Software Development (BECK et al, 2001), cujo conte�do � apresentado abaixo:

�

�N�s estamos descobrindo melhores maneiras para desenvolver software, praticando e auxiliando os outros a faz�-lo. Atrav�s deste trabalho n�s valorizamos:

-������ Os indiv�duos e suas intera��es acima de processos e ferramentas;

-������ Software em produ��o acima da documenta��o exaustiva;

-������ Colabora��o do cliente acima da negocia��o de contratos;

-������ Respostas �s mudan�as acima da execu��o de um plano.

Ou seja, embora haja valor nos itens � direita, n�s valorizamos mais os itens � esquerda.�

�

Segundo Cohen et al (2003, p. 6), este Manifesto tornou-se a pe�a-chave do movimento pelo desenvolvimento �gil de software, uma vez que re�ne os principais valores dos M�todos �geis, que os distingue dos m�todos cl�ssicos de desenvolvimento.

Al�m do Manifesto, foram definidos os princ�pios que regem a maioria das pr�ticas dos chamados M�todos �geis de Desenvolvimento de Software (AGILE ALLIANCE, 2005).� Estes princ�pios s�o apresentados na Tabela 1 abaixo, de acordo com a ordem originalmente proposta.

�

Princ�pios

1.� Nossa maior prioridade � satisfazer o cliente atrav�s da entrega r�pida e cont�nua de um software de valor

2.� Pessoas de neg�cio e programadores devem trabalhar juntos, diariamente, ao longo de todo o projeto

3.� Aceite as mudan�as de requisitos, mesmo que numa etapa avan�ada do desenvolvimento

4.� Entregue novas vers�es do software frequentemente

5.� O software em funcionamento � a medida prim�ria de progresso do projeto

6.� Construa projetos com pessoas motivadas. Ofere�a a elas o ambiente e todo o apoio necess�rios e acredite em sua capacidade de realiza��o do trabalho

7.� As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas

8.� O m�todo mais eficiente e efetivo de distribuir a informa��o para e entre uma equipe de desenvolvimento � a comunica��o face a face

9.� Processos �geis promovem desenvolvimento sustentado

10. A aten��o cont�nua na excel�ncia t�cnica e num bom projeto aprimora a agilidade

11. Simplicidade � essencial

12. Equipes de projeto avaliam seu desempenho em intervalos regulares e ajustam seu comportamento de acordo com os resultados

Quais são as melhores técnicas da engenharia de software?

Qual é o método mais eficiente de desenvolvimento de software?

Qual o modelo mais usado na engenharia de software?

Quais as principais metodologias utilizadas para desenvolvimento de software?