Tags: , , | Categories: Metodologia de Desenvolvimento Ágil Posted by Rafael on 06/05/2011 22:41 | Comentários (6)

Olá pessoal!

Nesse post comentarei sobre as principais vantagens e benefícios gerados a partir da adoção de processos baseados em metodologias ágeis, por qualquer empresa de Tecnologia da Informação.

"Metodologias ágeis têm sido apontadas como uma alternativa às abordagens tradicionais para o desenvolvimento de software. As metodologias tradicionais, conhecidas também como pesadas ou orientadas a planejamentos, devem ser aplicadas apenas em situações em que os requisitos do sistema são estáveis e requisitos futuros são previsíveis. Entretanto, em projetos em que há muitas mudanças, em que os requisitos são passíveis de alterações, onde refazer partes do código não é uma atividade que apresenta alto custo, as equipes são pequenas, as datas de entrega do software são curtas e o desenvolvimento rápido é fundamental, não pode haver requisitos estáticos, necessitando então de metodologias ágeis. Além disso, o ambiente das organizações é dinâmico, não permitindo então que os requisitos sejam estáticos." [SOARES, 2011].

Um projeto nunca é igual a outro projeto, e quanto maior a empresa, maior a diversificação de projetos, em relação a tamanho, escopo, requisitos, custo e prazo. Ao longo dos últimos anos, tenho atuado em projetos dos ramos bancário, securitário e previdenciário, e, todos eles possuíam características diferentes. Uns demandaram uma formalização e um planejamento intensos, enquanto outros, nem tanto. Um dos grandes problemas enfrentados foi ter que passar por todo o processo de desenvolvimento padrão, preenchendo muitos artefatos, muitas das vezes, desnecessários para o projeto. 

Muitas empresas acreditam que ser ágil é o mesmo que ser informal. E isso não é verdade. Ser ágil, dentre outras características, é ser formal apenas nos momentos os quais a formalidade é necessária, dando fluência ao projeto.

Empresas do ramo bancário, por exemplo, têm como um dos principais requisitos para terem o direito de ofertar seus papéis na Bolsa de Valores de Nova York, a adesão à Lei Sarbanes-Oxley, ou SOX, que estabelece a confecção de diversos artefatos, definindo um processo para o desenvolvimento de produtos de software. O que algumas empresas não sabem, é que é possível atender aos requisitos da SOX dentro de um processo baseado numa metodologia ágil, gerando apenas os artefatos que são realmente necessários e importantes, para que o projeto não seja afetado pelo excesso de documento a serem criados, sem necessidade.

Uma grande preocupação das empresas é o número de horas extras geradas em cada projeto. Esse, sem sombra de dúvida, é um assunto que gera muito estresse para o projeto, e conseqüentemente a todos os stakeholders. O fato gerador desse desconforto no decorrer do projeto, na maioria das vezes, é a dificuldade de se planejar um projeto como um todo. O grau de assertividade de um planejamento de 120 dias certamente é menor do que um de 15 dias. Metodologias ágeis estabelecem entregas semanais, quinzenais ou mensais (às vezes bimestrais e até semestrais, mas a ocorrência é bem pequena em relação aos demais prazos), o que facilita muito o planejamento. 

"a XP assume que não se deve fazer horas extras constantemente. Caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema sério no projeto que deve ser resolvido não com aumento de horas trabalhadas, mas com melhor planejamento, por exemplo. Esta prática procura ratificar o foco nas pessoas e não em processos e planejamentos. Caso seja necessário, os planos devem ser alterados, ao invés de sobrecarregar as pessoas." [SOARES, 2011].

É fato que, se temos um problema menor, podemos atuar pontualmente e sermos mais assertivos em relação aos prazos e custos. Com isso, diminuímos a ocorrência de horas extras e sobrecarga de pessoal em fases críticas do projeto.

Outro grande problema presente enfrentado pelas empresas quanto à utilização de processos baseados em metodologias não ágeis de desenvolvimento de software é entrega única, apenas ao final do projeto. Em alguns casos, o pior acontece. O cliente vira pra você e diz: “Mas não foi isso que eu pedi!”. Esse cenário é, sem dúvida, um dos mais críticos para um projeto, pois tempo, dinheiro, expectativa, confiabilidade “foram para o ralo”. 

"Entregas freqüentes visa à construção de um software simples, e conforme os requisitos surgem, há a atualização do software. Cada versão entregue deve ter o menor tamanho possível, contendo os requisitos de maior valor para o negócio. Idealmente devem ser entregues versões a cada mês, ou no máximo a cada dois meses, aumentando a possibilidade de feedback rápido do cliente. Isto evita surpresas caso o software seja entregue após muito tempo e melhora as avaliações do cliente, aumentando a probabilidade do software final estar de acordo com os requisitos do cliente." [SOARES, 2011].

Se adotarmos a técnica de entregas freqüentes, o risco de esse cenário acontecer tende a zero, pois a cada entrega, recebemos um feedback do cliente sobre o entregado, facilitando assim, ajustarmos as pendências para convergir às expectativas do cliente.

"Para prevenir a degradação da qualidade devido a entregas muito curtas, dá-se alta ênfase a testes do produto ao longo do ciclo de vida. Métodos ágeis requerem testes de integração ao longo do processo de desenvolvimento. Automação dos testes é importante para que as "builds" diárias passem por testes de regressão." [ABRANTES, 2011].

Outro benefício que a adoção de entregas menores e mais freqüentes traz para o projeto é a sobrecarga de testes dos requisitos classificados como críticos, ou de alta complexidade. Durante o planejamento do projeto, os requisitos são classificados segundo sua complexidade e criticidade. É uma boa prática de desenvolvimento baseado em metodologias ágeis a implementação dos requisitos de maior complexidade, pois, a cada nova entrega, todos os requisitos são retestados, o que diminui exponencialmente o risco de não conformidade com a especificação dos mesmos.

A cooperação e interação entre cliente e equipe de desenvolvimento do projeto também é um ponto forte nos processos de desenvolvimento baseados em metodologias ágeis.

"Interação aberta e com proximidade entre os vários stakeholders (especialmente entre cliente e desenvolvedores); o cliente deve tomar parte ativa no processo de desenvolvimento e prover opinião de forma regular e freqüente." [ABRANTES, 2011].

Quando o cliente faz parte do projeto, interagindo com a equipe, dando opinião e agindo realmente como parte integrante do projeto, alguns problemas enfrentados hoje por algumas empresas "caem por terra". Alguns usuários muitas das vezes mal explicam o que querem, aprovam as especificações dos requisitos às vezes sem se preocupar muito em ler todo o documento, pensando que o que não está escrito, está implícito, largando a equipe do projeto durante todo o desenvolvimento, retornando apenas no período de homologação. Essa atitude é muito freqüente em empresas que adotam apenas a forma não ágil de desenvolvimento. A metodologia ágil prega que o cliente precisa estar junto, participar, interagir, registrar feedbacks, ou seja, fazer parte do projeto.

"Todo dia, é feita uma reunião de 15 minutos onde o time expõe à gerência o que será feito no próximo dia, e nestas reuniões os gerentes podem levantar os fatores de impedimento, e o progresso geral do desenvolvimento." [SANTOS, 2011].

Outra característica muito importante dos métodos ágeis é a realização de rápidas reuniões diárias, onde são expostos de maneira pontual quais são as tarefas a serem executadas no próximo dia, o que ajuda a guiar a atenção e foco da equipe para o que realmente é importante naquele momento, ou seja, o sprint atual, fazendo o que é importante e necessário agora, e postergando o que pode ser postergado, sem causar impacto para o projeto. Algumas empresas realizam reuniões com o mesmo objetivo, porém, para tratar questões de tarefas de semanas ou meses, o que aumenta muito o escopo da reunião, prejudicando a tomada de decisões, ocupando grande parte do tempo e com foco menos pontual, o que dificulta a resolução dos problemas.

"Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adéquam a mudanças, para que o cliente possa tirar vantagens competitivas." [BECK, 2011].

A única certeza que temos quando começamos um projeto é a de que os requisitos serão alterados. Muitas equipes têm uma resistência enorme às alterações de requisitos ao final do projeto, principalmente pelo custo e esforço enormes necessários para a realização da mudança. Em métodos ágeis esse custo e esforço tende a ser menor, o que facilita muito a vida de todos os envolvidos no projeto. 

"Lei do foco, ou da concentração: menos é mais" e "Lei do progresso: podemos criar mais com menos" [KOCH, 2009].

Uma das técnicas, ou teorias, aplicadas em métodos ágeis (largamente aplicado na administração de empresas e auto-ajuda) é o Princípio de Paretto, também conhecimento como Princípio 80/20, que prega basicamente que podemos atingir 80% dos resultados esperados focando em apenas 20% das tarefas. Essa explanação parece muito simplista, mas quando aplicada à realidade de uma empresa, no que concerne o desenvolvimento de aplicativos com métodos ágeis, faz todo sentido. Ao invés de gastarmos uma grande parte do tempo fazendo planejamentos enormes, criando artefatos gigantescos sem necessidade, vamos direto ao foco, separando as atividades por risco e complexidade, o que facilita a compreensão de cada parte do problema, mantendo o foco no que é realmente importante, gerando os resultados esperados com muito menos esforço e desperdício de tempo e dinheiro.

Esses são os principais pontos que uma empresa deve levar em consideração para a adoção de um processo de desenvolvimento de software baseado em métodos ágeis. Sem dúvida, é interessante para qualquer tipo de empresa que faz uso da tecnologia da informação, para condução do seu negócio, fazer uso de métodos ágeis para o desenvolvimento de seus softwares.

Mais informações em http://agilemanifesto.org/

Até a próxima!

 

 

Referências Bibliográficas

SOARES, Michel Dos Santos Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software, disponível em http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf em 04/05/2011.

ABRANTES, José Fortuna e Guilherme Horta Travassos Caracterização de Métodos Ágeis de Desenvolvimento de Software, disponível em http://reuse.cos.ufrj.br/wdra2007/images/artigos/30188.pdf em 04/05/2011.

SANTOS, Rogério Guaraci Dos e Giulian Dalton Luz Métodos Ágeis, disponível em http://www.ime.usp.br/~gdaltonl/ageis/ageis_6pp.pdf em 04/05/2011.

BECK, Kent Manifesto Ágil, disponível em http://manifestoagil.com.br/principios.html em 04/05/2011.

KOCH, Richard, O Estilo 80/20, Rio de Janeiro: Sextante, 2009.

Comentários

Ana Carla Brazil on 09/05/2011 01:21 Rafa...

Legal esse post, porém, acredito que essa agilidade não se aplica somente ao desenvolvimento de sistemas, mas em todos os segmentos de TI dentro de uma empresa. "agil e descomplicado" esse é o lema!

beijos.
Rafael Brazil on 09/05/2011 01:44 Rafa...

Legal esse post, porém, acredito que essa agilidade não se aplica somente ao desenvolvimento de sistemas, mas em todos os segmentos de TI dentro de uma empresa. "agil e descomplicado" esse é o lema!

beijos.




Olá Ana,



Com certeza. Técnicas ágeis podem ser aplicadas a qualquer área de TI, mas depende da técnica.



O Scrum, por exemplo, foi concebido, em sua essência, para estabelecer métodos ágeis para desenvolvimento de sistemas, somente. O XP, de eXtreaming Programing, é dedicado a desenvolvimento de sistemas, pregando a programação pareada.



Porém, nada impede que implementemos uma outra técnica ágil na nossa empresa, não é mesmo? =)

Acredito que, se cada área da empresa aplicar o Princípio de Paretto na resolução de problemas, os mesmos seriam resolvidos num menor espaço de tempo, em maior proporção, sem esquecer da eficácia da solução. De nada adianta ser eficiente, sem ser eficaz.



Isso é ser ágil.

Pri Brazil on 10/05/2011 03:59 Rafa,

to fazendo o trabalho aqui e de repente vejo que você é da minha sala... Hahahaha só pq achei animal o q vc escreveu! Ferrou meu trabalho! Vou procurar tudo de novo!
Rafael Brazil on 10/05/2011 05:55 Rafa,

to fazendo o trabalho aqui e de repente vejo que você é da minha sala... Hahahaha só pq achei animal o q vc escreveu! Ferrou meu trabalho! Vou procurar tudo de novo!


Pri,



Opa, desculpa aí, haha!



Você vai encontrar muito material bom na rede.

Dá uma olhada em http://www.scrum.org/ que tem muita coisa boa lá...
Frederico Batista Emídio Brazil on 09/06/2012 04:50 Logo no começo você cita:

"Entretanto, em projetos... onde refazer partes do código não é uma atividade que apresenta alto custo, as equipes são pequenas, as datas de entrega do software são curtas e o desenvolvimento rápido é fundamental, não pode haver requisitos estáticos, necessitando então de metodologias ágeis"



Isso exclui uma gama enorme de projeto, por exemplo um projeto de 3 anos com uma equipe enorme espalhada entre Brasil e Índia.



Porém, acho que até mesmo nesse cenário que estou citando os métodos ágeis são uma boa opção, afinal por que em sã consciência uma pessoa não gostaria de ser ágil? Ela então estaria fazendo um escolha consciente por ser lenta se não quisesse ser ágil? O que é necessário em toda equipe é apenas adotar a metodologia que mais se encaixa ao cenário dela, ou ao projeto, mas todos os projetos deveriam ser ágeis, mesmo que seja com uma metodologia única ou uma mescla de todas, sem necessidade de ser tão puritano.

Acredito que o puritanismo é o começo da falta de agilidade.



Marco Filgueiras Brazil on 20/07/2012 03:47 Grande, Rafael ! Excelente post !

Quebramos um projeto enorme em meu trabalho atual em fases (para termos mais entregas e baixarmos os riscos - mas foi feito um trabalho com o usuário, como dito no post - trazê-lo pra perto -, pois algumas entregas podem não trazer todo o benefício que ele precisa no momento, mas facilita a entrega que importa, que pode ser a seguinte). As fases do projeto foram quebradas em pedaços menores, da forma possível, e o planejamento era revisto constantemente, usando os conceitos de Sprints do Scrum... As coisas andaram muito bem e deram mais certo. Mas o principal de tudo foi trazer o usuário pra perto e fazer com que ele enxergasse a responsabilidade dele no que seria entregue e, claro, ver os benefícios que esta integração traria... E isso gerou os grandes frutos, pois pegamos os problemas de "explicação mal feita" e "entrelinhas" num tempo curto, antes da homologação oficial e "a tempo", pois o famoso "não era bem isso que eu queria" sempre dá dores de cabeça, principalmente quando ocorre na homologação... Isso melhorou muita a vida de todos e criou uma parceria TI-Negócios!! Abs!
Os comentários estão fechados