APLICAÇÃO DE MÉTODOS ÁGEIS EM UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE1 Cleo Hickmann Junior2 Anderson Yanzer3 – Orientador Universidade Luterana do Brasil (Ulbra) – Bacharelado em Sistemas de Informação – Câmpus Canoas Av. Farroupilha, 8.001 – Bairro São Luís – CEP 92420-280 – Canoas - RS

13 de junho de 2011

RESUMO O objetivo deste trabalho é pesquisar metodologias ágeis, destacando os benefícios que elas podem proporcionar em um processo de desenvolvimento de software, além de apresentar a situação atual de uma equipe de desenvolvimento e descrever uma proposta de solução com base nas metodologias estudadas. Palavras-chave: Métodos Ágeis; Desenvolvimento de Software; Programação Extrema; Scrum.

ABSTRACT Title: “Application of agile methods on a software development process” The aim of this work is to research the agile methodologies, highlighting the benefits they can bring in a software development process, beyond present the current status of a team of development and describe a proposed solution based on the methodologies studied. Key-words: Agile Methods; Software Development; Extreme Programming; Scrum.

1

INTRODUÇÃO

Mesmo com a evolução dos computadores, das técnicas e ferramentas nos últimos anos, a produção de softwares confiáveis, com o mínimo de erros possíveis e entregues dentro do prazo, sem extrapolar o custo estipulado ainda é uma tarefa muito difícil. Com base nestas necessidades surgiram os métodos e práticas ágeis no desenvolvimento de software, visando melhorar o processo e simplificar o trabalho da equipe. Tais práticas sugerem uma série de mudanças que vão de encontro ao que aborda a engenharia de software tradicional, acostumada a seguir padrões de projetos como o CMMI, por exemplo. Neste contexto de mudança de paradigma, migrando das metodologias pesadas ou tradicionais para a aplicação de processos ágeis de desenvolvimento de software existe uma questão de mudança cultural, o que muitas vezes dificulta a adoção das metodologias ágeis pela equipe de desenvolvimento. Há muitos exemplos que comprovam que em equipes grandes este processo de mudança é muito mais complicado, muitas vezes até mesmo inviável (YOSHIMA, 2011). Este artigo foi desenvolvido tendo como principal objetivo realizar um estudo sobre as metodologias ágeis mais aplicadas atualmente em equipes de desenvolvimento de software, falando sobre seus princípios e características. Com base nisso, pretende-se obter o embasamento suficiente para adotar se não todas, mas as melhores práticas das metodologias estudadas em um ambiente real de desenvolvimento. Para facilitar o entendimento do leitor, no artigo encontra-se uma breve descrição do processo de desenvolvimento atual da equipe utilizada no estudo de caso. Na Seção 2 deste artigo será abordado sobre o histórico das Metodologias Ágeis, enquanto na Seção 3 será falado sobre a metodologia XP, seus conceitos e principais características. Já a Seção 4 apresenta um resumo sobre a metodologia Scrum, falando um pouco de seus princípios, fases, entre outras particularidades. O cenário atual será apresentado na Seção 5, falando um pouco também sobre a metodologia direcionada a testes, utilizada atualmente. Na Seção 6 serão descritas as práticas dos métodos 1

Artigo elaborado para o Trabalho de Conclusão de Curso I em Sistemas de Informação, submetida ao Curso de Bacharelado em Sistemas de Informação da Universidade Luterana do Brasil, Câmpus Canoas. 2 Aluno do 7º semestre do curso de Bacharelado em Sistemas de Informação. 3 Professor orientador do Trabalho de Conclusão de Curso I em Sistemas de Informação e coordenador do curso de Bacharelado em Sistemas de Informação da Universidade Luterana do Brasil, Câmpus Canoas.

1

ágeis que se deseja implantar, obedecendo ao cronograma apresentado na Seção 7. As considerações finais serão expostas na Seção 8 e, por fim, o artigo é encerrado com as referências utilizadas para elaboração do mesmo.

2

METODOLOGIAS ÁGEIS

O termo “metodologias ágeis” se popularizou em 2001 quando um pequeno grupo composto por dezessete especialistas em processos de desenvolvimento de software se reuniu na cidade norte-americana de Utah e estabeleceram princípios comuns compartilhados por todos esses métodos. Com isso, houve a criação da Aliança Ágil, que posteriormente estabeleceu o “Manifesto Ágil” (Agile Manifesto). Os conceitos chave do Manifesto Ágil são:  Indivíduos e interações mais que processos e ferramentas;  Software em funcionamento mais que documentação abrangente;  Colaboração com o cliente mais que negociação de contratos;  Responder a mudanças mais que seguir um plano. Além dos conceitos, o Manifesto Ágil conta com doze princípios para aqueles que pretendem alcançar a agilidade. São eles:  Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.  Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.  Entregar freqüentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.  Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.  Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.  O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.  Software funcionando é a medida primária de progresso.  Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.  Contínua atenção a excelência técnica e bom design aumentam a agilidade.  Simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é essencial.  As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.  Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo. Mesmo que o Manifesto Ágil tenha sido assinado em 2001, as idéias subjacentes que guiam o desenvolvimento ágil não são tão recentes. No entanto, estas idéias começaram a ser materializadas somente na década de 1990. Vale ressaltar que em sua essência, os métodos ágeis foram desenvolvidos em um esforço para vencer as fraquezas percebidas e reais da engenharia de software convencional (PRESSMAN, 2006). Roger Pressman (2006) ainda afirma que o que diferencia as metodologias ágeis das metodologias tradicionais são o enfoque e os valores, ou seja, para uma metodologia ser considerada ágil deve enfatizar pessoas ao invés de processos e algoritmos. Além disso, também é enfatizado pelas metodologias ágeis o gasto de tempo que deve ser menor com documentação e maior com implementação.

2

Conforme dito por Fowler (2005), a maioria dos projetos de software conta com três suposiçõeschave, e é justamente o que o processo ágil de desenvolvimento visa atender: 

É difícil prever antecipadamente quais requisitos de software vão persistir e quais serão modificados. Da mesma forma que é difícil prever como as prioridades do cliente serão modificadas durante o desenvolvimento do projeto.



Para muitos tipos de software, o projeto e a construção são intercalados, ou seja, as duas atividades devem ser realizadas juntas de modo que os modelos de projeto sejam comprovados à medida que são criados. É difícil prever o quanto de projeto é necessário antes que a construção seja usada para comprovar o projeto.



Análise, projeto, construção e testes não são tão previsíveis (do ponto de vista do planejamento) como gostaríamos.

Segundo consta na Wikipédia, o objetivo da maioria dos métodos ágeis é tentar minimizar o risco no processo de desenvolvimento de software. Métodos ágeis priorizam comunicação em tempo real a documentos escritos, ou seja, enfatizam trabalho no software como uma medida primária do progresso. Para Highsmith (2002), a definição de agilidade é a seguinte: “Agilidade é a habilidade de criar e responder a mudanças com respeito ao resultado financeiro do projeto em um turbulento ambiente de negócios. Agilidade é a habilidade de balancear flexibilidade com estabilidade.”

A visão de Ivar Jacobson (2002) sobre agilidade fornece uma discussão bastante útil, pois ele contextualiza o trabalho de engenharia de software: “Agilidade tornou-se atualmente uma palavra mágica quando se descreve um processo de desenvolvimento de software. Tudo é ágil. Uma equipe ágil é uma equipe esperta, capaz de responder adequadamente a modificações. Modificação é aquilo para o qual o desenvolvimento de software está principalmente focado. Modificações no software que está sendo construído, modificações nos membros da equipe, modificações por causa de novas tecnologias, modificações de todas as espécies que podem ter impacto no produto que eles constroem ou no projeto que cria o produto. O apoio para modificações deveria ser incorporado em tudo que fazemos em software, algo que se adota porque está no coração e na alma do software. Uma equipe ágil reconhece que o software é desenvolvido por indivíduos trabalhando em equipes e que as especialidades dessas pessoas e sua capacidade de colaborar estão no âmago do sucesso do projeto.”

O Quadro 1 (DYBÅ e DINGSØYR, 2008) apresenta as principais diferenças entre o desenvolvimento tradicional e o desenvolvimento ágil: Quadro 1 - Comparativo entre Desenvolvimento Tradicional e Desenvolvimento Ágil Desenvolvimento Tradicional

Desenvolvimento Ágil

Fundamental

Os sistemas são plenamente determináveis, previsíveis e são construídos através de um planejamento meticuloso e extenso

Software de alta qualidade adaptativa é desenvolvido por pequenas equipes que usam o princípio do design contínuo de aperfeiçoamento e testes com base no feedback rápido e mudanças

Estilo de Gestão

Comando e controle

Liderança e colaboração

Gestão do

Explícito

Tácito

Comunicação

Formal

Informal

Modelo de

Ciclo de vida do modelo (cascata, espiral ou alguma variação)

Modelo de entrega evolutiva

Mecanicistas (burocrática com a alta

Orgânico (flexível e participativa

Pressuposto

Conhecimento

Desenvolvimento Desejado

3

Organizacional Forma/Estrutura Controle de Qualidade

formalização), destinada a grandes organizações

incentivando a ação cooperativa social), destinada a pequenas e médias organizações

Planejamento pesado e controle rigoroso.

Controle contínuo dos requisitos de design e soluções.

Testes pesados

Teste contínuo

Para Stavarengo (2011), metodologia ágil é um conceito que visa trazer uma série de vantagens para a equipe, diminuindo os riscos que envolvem produzir um software e tem como característica a velocidade com que novas funções são implementadas quando comparadas com a metodologia convencional: semanas ao invés de meses. De acordo com Cockburn (2001), a idéia dominante no desenvolvimento ágil é que a equipe de software pode ser mais eficaz na resposta à mudança se puder:  Reduzir o custo de movimentação de informação entre as pessoas. Para fazer isso, a equipe ágil deve: 

Colocar as pessoas fisicamente mais próximas



Substituir documentos, falando em pessoa usando a lousa



Melhorar a amabilidade da equipe, seu senso de comunidade e de moral, de modo que as pessoas estão mais propensas a fornecer informações valiosas rapidamente

 Reduzir o tempo decorrido entre as tomadas de decisão para ver as conseqüências dessa decisão. Para fazer isso, a equipe ágil deve: 

Colocar usuários especialistas a disposição da equipe



Trabalhar de forma incremental

Porém, Ambler (2005) destaca que existem várias implicações interessantes no desenvolvimento ágil de software para profissionais de qualidade: 1. Maior qualidade implica uma menor necessidade de atividades de garantia de qualidade: Código de melhor qualidade implica uma menor necessidade de atividades de garantia de qualidade, tais como revisões e inspeções, em outras etapas do ciclo de vida do software. Agilistas são infectados de qualidade. 2. Acostume-se a artefatos “incompletos”: Modelos, documentos e código-fonte evoluem ao longo do tempo. Na única vez que agilistas pode dizer que alguma coisa está feita é quando eles estão prontos para liberá-la em produção. Uma equipe de desenvolvimento ágil normalmente tem comunicação em tempo real entre os integrantes da equipe quanto entre a equipe e as pessoas que conhecem a definição do programa – por exemplo, os clientes. Para tornar o processo mais ágil esta comunicação deve ser preferencialmente feita frente a frente ao invés de usar documentos. Entre as metodologias ágeis existentes atualmente, as mais conhecidas e utilizadas são a Extreme Programming (XP) e a Scrum.

3

EXTREME PROGRAMMING

Mais conhecida pela sigla XP, esta metodologia é voltada mais para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se modificam freqüentemente. As principais diferenças da metodologia XP para as metodologias tradicionais são:  Feedback constante;  Abordagem incremental;  Comunicação encorajada entre pessoas.

4

O objetivo da XP é garantir a satisfação do cliente favorecendo o cumprimento das estimativas, por isso ela enfatiza o desenvolvimento rápido do projeto. Os quatro valores que a XP se baseia são: comunicação, simplicidade, feedback e coragem (BECK, 1999). A finalidade do princípio de comunicação é manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação. A XP também encoraja a comunicação entre os desenvolvedores e o gerente do projeto. Já a simplicidade visa permitir a criação de código simples que não deve possuir funções desnecessárias. Por código simples entende-se implementar o software com o menor número possível de classes e métodos. Outra idéia importante da simplicidade é procurar implementar apenas requisitos atuais, evitando-se adicionar funcionalidades que podem ser importantes no futuro. A aposta da XP é que é melhor fazer algo simples hoje e pagar um pouco mais amanhã para fazer modificações necessárias do que implementar algo complicado hoje que talvez não venha a ser usado, sempre considerando que requisitos são mutáveis. A questão do feedback constante significa que o programador terá informações constantes do código e do cliente. A informação do código é dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado. Com relação ao cliente, o feedback constante significa que ele terá freqüentemente uma parte do software totalmente funcional para avaliar. O cliente deve então sugerir constantemente novas características e informações aos desenvolvedores. Eventuais erros e não conformidades são rapidamente identificados e corrigidos nas próximas versões. Baseado nisso, a tendência é que o produto final esteja de acordo com as expectativas reais do cliente. Coragem é um item fundamental, pois é necessário coragem para aplicar os três valores anteriores. Por exemplo, não são todas as pessoas que possuem facilidade de comunicação e têm bom relacionamento. A coragem também dá suporte à simplicidade, pois assim que a oportunidade de simplificar o software é percebida, a equipe pode experimentar. Além disso, é preciso coragem para obter feedback constante do cliente. Segundo Beck (1999), a metodologia XP baseia-se nas 12 práticas listadas a seguir:  Planejamento: é onde se decide o que deve ser feito e o que pode ser adiado no projeto, lembrando que a XP se baseia em requisitos atuais para desenvolvimento e não em requisitos futuros.  Entregas freqüentes: a construção do software deve ser simples e conforme os requisitos surgem, há uma atualização do mesmo.  Metáfora: são as descrições do software sem os termos técnicos, facilitando o entendimento do cliente e guiando o desenvolvimento de software.  Projeto simples: o programa desenvolvido pelo método XP deve ser o mais simples possível e satisfazer os requisitos atuais, sem a preocupação de requisitos futuros.  Testes: a XP focaliza a validação do projeto durante o processo de desenvolvimento, fazendo com que os programadores desenvolvam o software criando primeiro os testes.  Refatoração: deve ser feita apenas quando é necessário, ou seja, quando um desenvolvedor da dupla, ou os dois, percebe que é possível simplificar o módulo atual sem perder nenhuma funcionalidade.  Programação em pares: a implementação do código é feita em dupla, ou seja, dois desenvolvedores trabalham em um único computador. Enquanto um desenvolvedor está com o controle do teclado e do mouse implementando o código, o outro observa continuamente o trabalho que está sendo feito, procurando identificar erros sintáticos e semânticos e pensando em como melhorar o código que está sendo implementado. Esses papéis podem e devem ser alterados continuamente, possibilitando que um aprenda com o outro.  Propriedade coletiva: o código do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode adicionar valor a um código, mesmo que ele próprio não o tenha desenvolvido, pode fazê-lo, desde que faça a bateria de testes necessária. Uma grande vantagem desta prática é que, caso um membro da equipe deixe o projeto antes do fim, a

5

equipe consegue continuar o projeto com poucas dificuldades, pois todos conhecem todas as partes do software, mesmo que não seja de forma aprofundada.  Integração contínua: a idéia é interagir e construir o sistema de software várias vezes por dia, mantendo os programadores em sintonia, possibilitando processos rápidos.  40 horas de trabalho semanal: a XP assume que não se devem 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.  Cliente presente: o cliente deve estar sempre disponível para sanar todas as dúvidas de requisitos, evitando atrasos e até mesmo construções erradas de software.  Código padrão: padronização na arquitetura do código, para que este possa ser compartilhado entre todos os desenvolvedores da equipe. Além das práticas destacadas, vale salientar que a XP defende a não especialização dos membros da equipe. Isso quer dizer que todos devem participar de todas as atividades, em pares e com sistema de rodízio de pares. A XP também é a favor do desenvolvimento de infraestruturas e frameworks durante o desenvolvimento da aplicação, além da comunicação face a face por meio de testes eficientes e código cuidadosamente escrito (BECK, 1999). Em resumo, os fundamentos da XP incluem:  Distinguir entre as decisões que devem ser tomadas por interesses dos negócios e aquelas a serem tomadas pelos envolvidos no projeto;  Escrever testes de unidade antes de programar e manter todos os testes executando o tempo todo;  Integrar e testar todo o sistema várias vezes ao dia;  Produzir o software em pares, dois programadores diante de uma tela;  Começar o desenvolvimento com um projeto simples, que evolui constantemente a fim de adicionar a flexibilidade necessária e eliminar a complexidade desnecessária;  Colocar um sistema mínimo em produção rapidamente e desenvolvê-lo na direção que se mostrar mais favorável.

4

SCRUM

Além da XP, outra metodologia que apresenta uma, comunidade grande de usuários é a Scrum. Segundo Schwaber e Beedle (2002), o objetivo da Scrum é fornecer um processo conveniente para projeto e desenvolvimento orientado a objeto. A Scrum apresenta uma abordagem empírica que aplica algumas idéias da teoria de controle de processos industriais para o desenvolvimento de softwares, reintroduzindo as idéias de flexibilidade, adaptabilidade e produtividade. O foco da metodologia é encontrar uma forma de trabalho dos membros da equipe para produzir o software de forma flexível e em um ambiente em constante mudança. A idéia principal do Scrum é que o processo de desenvolvimento de software envolve muitas variáveis técnicas e do ambiente, tais como requisitos, recursos e tecnologia, que correm o risco de mudar durante o processo. Isso faz com que o processo de desenvolvimento se torne imprevisível e complexo, exigindo flexibilidade para acompanhar as mudanças. Para Schwaber (1995), o resultado do processo deve ser um software realmente útil para o cliente. A metodologia do Scrum é baseada em princípios bem semelhantes aos da XP, ou seja, equipes pequenas, requisitos pouco estáveis ou desconhecidos e iterações curtas. Porém, as dimensões em Scrum se diferem de XP. A Scrum divide o desenvolvimento em iterações (também chamadas de sprints) de aproximadamente trinta dias. Equipes pequenas, de até dez pessoas, são formadas por programadores, projetistas, engenheiros e gerentes de qualidade. Estas equipes trabalham em cima de funcionalidades (ou requisitos) definidas na fase inicial de cada sprint. Assim, a equipe fica responsável pelo desenvolvimento desta funcionalidade. A Figura 1 ilustra um modelo de Kanban utilizado na prática da metodologia Scrum.

6

O desenvolvimento de software é um desafio constante, além de ser uma atividade complexa. Todo processo complexo exige uma intensa comunicação entre os membros da equipe. Este é justamente o ponto que o Scrum apresenta a Scrum Daily Meeting. Nestes encontros diários, que são preferencialmente de curta duração (normalmente de quinze minutos), são discutidos pontos relevantes do andamento do projeto, onde todos os membros do Scrum Team devem responder a três perguntas fundamentais: 1. O que eu fiz desde a última Scrum Daily Meeting? 2. O que vou fazer hoje? 3. O que pode me impedir? Com esta prática, é promovida a comunicação entre a equipe de desenvolvimento, facilitando a identificação das dificuldades encontradas e os fatores de impedimento, tornando a resolução destes problemas muito mais rápida. O ciclo de vida da Scrum é dividido em três fases principais, que por sua vez subdivide-se em subfases:  Pré-planejamento: os requisitos são descritos em um documento chamado backlog. Posteriormente eles são priorizados e são feitas estimativas de esforço para o desenvolvimento de cada requisito. Dentre as atividades do planejamento estão: a definição da equipe de desenvolvimento, as ferramentas a serem usadas, a identificação dos possíveis riscos do projeto e as necessidades de treinamento. Por fim, é proposta uma arquitetura de desenvolvimento.  Desenvolvimento: nesta fase o software é desenvolvido em ciclos (sprints) em que novas funcionalidades são adicionadas. Cada um desses sprints é desenvolvido de forma tradicional, ou seja, primeiramente se faz a análise, para em seguida o projeto, implementação e testes. Cada um destes ciclos é planejado para durar um pequeno espaço de tempo, podendo variar de uma semana até um mês.  Pós-planejamento: posterior à fase de desenvolvimento, são realizadas reuniões com o intuito de analisar o progresso do projeto e demonstrar o software atual para os clientes. Nesta fase são implementadas as etapas de integração, testes finais e documentação.

Figura 1 – Ilustração de um modelo de Kanban (KNIBERG, 2007)

7

5

CENÁRIO ATUAL

O cenário atual do processo de desenvolvimento de software na empresa onde foi realizado o estudo de caso não é completamente tradicional, ou seja, não é seguido à risca o que prega a engenharia de software clássica. Atualmente a equipe de desenvolvedores faz uso da Test Driven Development (TDD) através de um framework derivado da DUnit, do Delphi (disponível a partir da versão 2005). A TDD é uma técnica de desenvolvimento de software dirigido por testes, ou seja, o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade. Então é produzido código que possa ser validado pelo teste para posteriormente o código ser refatorado para um código sob padrões aceitáveis. Segundo Beck (2003), TDD encoraja designs de código simples e inspira confiança. Assim como qualquer metodologia de desenvolvimento ágil, a TDD também é composta por pequenos ciclos de desenvolvimentos (STAVARENGO, 2011). Estes ciclos são formados por cinco passos: 1. Criar um teste; 2. Executar o novo teste; 3. Criar a nova função; 4. Executar os testes novamente; 5. Refatorar o código. Porém, a criação de testes unitários a cada nova implementação ou funcionalidade ainda não é uma realidade na empresa. Existem algumas classes de validação para as rotinas mais complexas como a importação de dados, mas há o reconhecimento por parte da equipe de que isso pode e deve ser melhorado e explorado de uma forma mais correta. A idéia é agregar ao que se tem hoje, as melhores práticas das metodologias Scrum e XP, fazendo com o que processo de desenvolvimento de software se torne mais produtivo e eficaz. O objetivo é realizar um estudo de caso com o intuito de implantar estes métodos em um primeiro momento numa pequena equipe composta por um gerente de desenvolvimento, cinco programadores e dois técnicos em qualidade de software. Inicialmente deverá ser feita uma análise da viabilidade da aplicação da metodologia Scrum, bem como levantamento de requisitos e material de apoio (documentos e sistema de controle de requisições) utilizados na prática do Scrum. Aplicar a metodologia XP é um segundo passo a ser tomado, mas para que isso se realize, devem ser realizadas algumas reuniões a fim de apresentar para a gerência as vantagens que a XP pode trazer. A aceitação da equipe de desenvolvimento também é importante e, para isso, deve ser realizada uma pesquisa entre os desenvolvedores para obtenção de uma estimativa de quem já conhece XP ou algum tipo de metodologia ágil e até mesmo quem não conhece, mas tem interesse em conhecer e colocar em prática estas técnicas. A intenção é fazer com que a equipe se sinta motivada e engajada com a idéia de mudar a abordagem de desenvolvimento de software, pois com a aplicação de métodos ágeis todos tendem a ganhar.

5.1

Sobre a empresa

A Data Cempro é uma empresa que há mais de vinte anos atende o mercado de sistemas contábeis com produtos de fácil usabilidade e com a melhor relação custo x benefício para o uso das tecnologias modernas. Desde 1986, a Data Cempro Informática vem acompanhando as contínuas mudanças tecnológicas exigidas pelo mercado. E é através da agilidade neste processo de mudança que seus clientes hoje podem atestar a segurança que a Data Cempro proporciona através dos seus sistemas e serviços, o que também lhe garantiu a conquista do prêmio Top Informática Rio Grande do Sul e o sucesso em todas as feiras e eventos das quais participou. Situada na cidade de Cachoeirinha, na região da Grande Porto Alegre, atualmente a empresa possui em sua equipe de desenvolvimento cinco núcleos compostos por um gerente, um técnico em qualidade de software, dois técnicos de suporte e uma quantidade de desenvolvedores que varia de dois a três por núcleo. Os núcleos estão divididos em:  Núcleo Comercial  Núcleo Departamento Pessoal  Núcleo Fiscal 8

 Núcleo Contábil  Núcleo Web Cada núcleo é responsável pelos seus sistemas, de acordo com a área de atuação, mas todos os sistemas são integrados visando um trabalho com maior conforto e amigabilidade, tanto para os clientes quanto para a equipe de desenvolvimento. Optou-se por realizar o estudo de caso na Data Cempro Informática por se tratar de uma empresa moderna que, no papel de seus gestores, encoraja os programadores a melhorar o processo de desenvolvimento agregando novas idéias, novas tecnologias e novas metodologias. Este trabalho é só o início de um projeto que tende a se estender pelos demais setores da empresa, de acordo com os resultados obtidos.

5.2

Processo atual de desenvolvimento de software

Conforme foi descrito na seção anterior, a Data Cempro Informática conta com cinco núcleos de desenvolvimento onde o trabalho da equipe funciona de forma integrada. Porém, o processo de desenvolvimento de software atualmente segue uma metodologia tipicamente tradicional e se estabelece resumidamente da seguinte forma:  Cada núcleo é responsável por um ou mais sistemas de acordo com a sua área de atuação, portanto cabe ao técnico em qualidade de software definir quais requisições farão parte da próxima liberação de versão.  As requisições são armazenadas em um sistema de suporte, com acesso comum entre todos os membros da equipe, onde podem ser realizados diversos processos como incluir, modificar e excluir requisições, consultar e emitir relatórios, consultar dados de clientes, etc.  Os técnicos em qualidade (também chamados de testadores) organizam as requisições por prioridades, definindo prazos para a liberação das mesmas. Além disso, são eles que encaminham as requisições para o programador responsável.  Após as requisições serem passadas para o programador, este só passará a mesma para a fase de testes posterior às implementações das alterações solicitadas pelo técnico em qualidade de software.  Com os devidos testes bem sucedidos, as requisições são liberadas e estão prontas para sair na liberação de versão do sistema seguinte.  Uma liberação de versão pode englobar mais de um sistema, portanto cabe aos técnicos em qualidade de software dos núcleos chegarem a um consenso para definição da data de liberação, bem como os prazos para execução dos testes. O procedimento descrito acima exemplifica o que engenharia de software denomina como Modelo Cascata, conforme Sommerville (2000) e Pressman (2001). Este modelo também chamado de “ciclo de vida clássico” sugere uma abordarem sistemática e seqüencial para o desenvolvimento de software, conforme pode ser visto na Figura 2.

9

Figura 2 – Modelo Cascata (SOMMERVILLE, 2000) Diferente do Scrum, que possui reuniões diárias, cada núcleo realiza uma reunião semanal de uma hora em horários normalmente pré-estabelecidos. O objetivo é a troca de idéias entre os membros da equipe e exposição de problemas ou dúvidas que possam estar travando o processo de desenvolvimento. Outro fator positivo é a constante troca de idéias entre os desenvolvedores, mantendo um espírito de colaboração e troca mútua de opiniões, críticas e sugestões. De certa forma, algumas premissas do Manifesto Ágil já são cumpridas na Data Cempro Informática. Software em funcionamento é uma preocupação constante da equipe de desenvolvedores, pois isso vai de encontro com manter a satisfação do cliente. Sempre que existe a necessidade, seja por uma falha do sistema ou mudança da legislação, é dada prioridade a manter os sistemas em funcionamento do que cumprir requisições planejadas anteriormente. Nestes casos as prioridades são alteradas de acordo com a demanda e a urgência das requisições.

6

APLICAÇÃO DOS MÉTODOS ÁGEIS

Conforme citado no capítulo anterior do presente artigo, o primeiro passo para a aplicação de técnicas e métodos ágeis de desenvolvimento de software é a aceitação por parte da equipe. Importante lembrar que quando se fala em equipe, não se trata apenas de desenvolvedores, mas também analistas e técnicos em qualidade de software. Com base nisso, uma das primeiras atividades deste projeto é reunir a equipe a fim de expor o objetivo e os benefícios que o processo ágil de desenvolvimento poderá agregar ao time de desenvolvimento, além de esclarecer possíveis dúvidas sobre este novo paradigma que se pretende implantar, ao mesmo tempo em que se busca motivar a equipe para a aplicação das práticas ágeis. Em razão do impacto que uma mudança cultural deste porte pode provocar, a aplicação dos métodos ágeis deverá ocorrer de forma gradual. O escopo da aplicação das metodologias englobará apenas um ou dois núcleos de desenvolvimento, inicialmente de forma experimental e sem muita rigidez, ou seja, é possível que apenas algumas práticas ágeis sejam aplicadas. Apesar disso, a ideia é evitar os principais gargalos gerados pelo modelo em cascata, aplicando o modelo iterativo das metodologias ágeis. Importante salientar que, mesmo que a aplicação das práticas ágeis de desenvolvimento de software seja implantada de forma flexível, a idéia é de que o trabalho seja realizado de forma que as característicaschave da equipe sejam valorizadas. Conforme dito por Pressman (2006), se os membros de uma equipe de software tiverem que estabelecer as características do processo que é aplicado para construir softwares, as 10

mais importantes são:  Competência: Esta característica inclui talento inato, habilidades específicas relacionadas a software e conhecimento global do processo que a equipe decidiu aplicar.  Foco comum: Isso estabelece que todos os membros da equipe devem estar focados em uma meta, como entregar um incremento de software em funcionamento ao cliente dentro do prazo prometido, por exemplo. Para isso, a equipe deve concentrar-se em adaptações contínuas que farão o processo satisfazer as necessidades da equipe.  Colaboração: Sobre este item, a engenharia de software diz respeito a avaliar, analisar e usar as informações que são comunicadas à equipe; criar informações que ajudarão o cliente e outros a entender o trabalho da equipe; construir informações que forneçam valor de negócio ao cliente. Para que sejam realizadas estas tarefas, é preciso que haja colaboração entre os membros da equipe, incluindo o cliente e o gerente de negócio.  Capacidade de tomada de decisão: A equipe precisa de autonomia para a tomada de decisão sobre tópicos técnicos e de projeto, pois qualquer boa equipe de software deve ter liberdade de controlar seu próprio destino.  Habilidade de resolver problemas vagos: Uma equipe ágil terá de lidar continuamente com ambigüidades e será continuamente confrontada por modificações. Este tópico salienta também que a equipe precisa entender que, em alguns casos, o problema que está sendo resolvido hoje pode não ser o problema que será resolvido amanhã.  Respeito e confiança mútua: Uma equipe consolidada exibe a confiança e o respeito necessários para torná-la “tão fortemente aglutinada que o todo é maior que a soma das partes.” (PRESSMAN, 2006 apud DEMARCO, 1998)  Auto-organização: No contexto de desenvolvimento ágil, a auto-organização implica três coisas: (1) a equipe ágil organiza-se para o trabalho a ser feito; (2) a equipe o processo para melhor acomodar seu ambiente local; (3) a equipe organiza o cronograma de trabalho para conseguir melhor entrega do incremente de software. Não é de hoje que se tem conhecimento sobre um acirrado debate na comunidade de Engenharia de Software sobre a aplicabilidade das metodologias clássicas em detrimento das metodologias ágeis. Eventualmente este debate também é chamado de “guerra metodológica” (GLASS, 2001). Ainda sobre esta questão polêmica, Glass (2001) afirma que as crenças conflitantes servem de base para a discordância entre os defensores das metodologias ágeis e das clássicas, indicando que a “disputa” pode se tratar de um problema de atitudes individuais e/ou organizacionais, hábitos de trabalho e visões precipitadas sobre as diferentes metodologias e seus relacionamentos. Baseado neste conflito cultural entre as metodologias tradicionais e ágeis pode-se afirmar que a implantação de métodos ou práticas ágeis em uma empresa que possui uma identidade própria de desenvolvimento, como é o caso da Data Cempro, só poderá ocorrer com muita cautela. É importante salientar que a empresa apóia este tipo de iniciativa no papel de seus gestores, mas isso não quer dizer que a aceitação seja geral por parte da equipe. Este sem dúvida será o maior desafio neste projeto. Dependendo do cenário, a transição para o Agile em uma organização é muito complicada e, muitas vezes, até inviável. “Toda empresa busca ser ágil e para tal, existe um caminho a ser seguido.” (YOSHIMA, 2011), conforme retrata a Figura 3. Porém, é sabido que não é qualquer empresa que está preparada para adotar uma cultura ágil de desenvolvimento.

Figura 3 – Transição do Estado Atual para o Agile (YOSHIMA, 2011)

11

Yoshima (2011) lembra que se criou um mito chamado “Cultura Agile” onde é bastante comum o fato de pessoas ligadas à comunidade ágil culparem a cultura pelas dificuldades em transitar do estado atual para o Agile. Yoshima (2011) ainda reforça que é uma falha tentar mudar a cultura empresarial, impondo-lhe uma própria. É preciso tomar decisões focando as metas do negócio da empresa, baseado no sistema de gestão adotado.

6.1

Aplicação da metodologia Scrum

A aplicação dos métodos ágeis terá início pela adoção de práticas da metodologia Scrum, onde o sistema de suporte utilizado para controle de requisições servirá para gerar o documento de backlog. O texto das requisições, em sua maioria, é descrito pelos técnicos em qualidade de software, o que torna o conteúdo menos técnico, tornando-o mais entendível aos olhos dos usuários. Com isso, o texto da requisição poderá formar a user story que, por conseqüência, cada pacote de requisições incluídas na liberação de versão do sistema, seria o sprint da equipe de desenvolvimento. O que pode ser melhorado neste ponto é a questão do grau de importância (prioridade) da user story que passará a ser definido pelo técnico em qualidade de software ou ainda pelo gerente de desenvolvimento. Algumas equipes Scrum fazem uso e possuem modelos próprios de cartões, onde são descritas as user stories. Um modelo pode ser visto na Figura 4, onde existem campos para descrever o que seria a o texto da requisição, um breve descritivo de como demonstrar o problema a ser resolvido ou a solução, o grau de importância e a estimativa de tempo.

Figura 4 – Modelo de cartão de usuário (KNIBERG, 2007) Outro fator a ser esclarecido perante a equipe diz respeito às reuniões diárias de Scrum, pois deverá ser consenso entre os membros da equipe o melhor horário para aplicá-las. Será sugerido o horário matutino, pois “A primeira reunião diária é essencial para o lançamento onde todos decidem começar a trabalhar.” (KNIBERG, 2007, p.48). No entanto, conforme a demanda de serviço e disponibilidade dos stakeholders, o horário da reunião diária poderá ser flexibilizado. Conforme foi dito na introdução deste artigo, a idéia é aproveitar as melhores práticas de cada metodologia, de acordo com a realidade da equipe. A prática do Kanban deve ser adotada pela equipe, até porque outros núcleos de desenvolvimento da empresa já adotaram esta prática anteriormente e obtiveram relativa satisfação por parte da gerência. Entende-se que com este recurso o processo de desenvolvimento se tone mais transparente perante os membros da equipe, estimulando uma cobrança natural entre si pelo alcance do resultado na resolução das tarefas (user stories).

6.2

Aplicação da metodologia XP

O intuito de aplicar a metodologia XP na equipe de desenvolvimento de software é tornar o trabalho mais produtivo e eficaz, pois conforme foi dito por Beck (1999) um dos fundamentos da XP é adicionar a flexibilidade necessária e eliminar a complexidade desnecessária no processo de desenvolvimento de software. Baseado nisso, o objetivo é de que a equipe consiga visualizar na XP uma metodologia que, com o passar do tempo, torne o processo de desenvolvimento mais eficiente e produtivo. Para cumprir a etapa de planejamento da XP, alguns detalhes terão que ser adaptados para a 12

realidade da empresa. Uma das premissas da metodologia XP é a de que a equipe e o cliente trabalham juntos e que deve haver comunicação entre eles. Bom, neste caso vamos incluir mais um membro na equipe de desenvolvimento: o técnico de suporte. Este será o porta-voz do cliente na equipe. A ordem natural de comunicação dentro da empresa é a seguinte: 1. Cliente entra em contato com técnico de suporte; 2. Técnico de suporte entra em contato com técnico em qualidade de software; 3. Técnico em qualidade de software entra em contato com programador. Esta é uma seqüência de comunicação que já é (ou deveria ser) uma prática comum nas equipes de desenvolvimento da empresa. Em nenhuma hipótese o cliente deve se comunicar diretamente com o programador. Este é um paradigma que dificilmente será quebrado. Poderá ser sugerido que o técnico de suporte possa ter contato direto com o programador para “encurtar o caminho”, mas essa é uma questão a ser debatida nas reuniões iniciais de implantação do projeto. Com relação ao documento de backlog, deverá ser seguido o modelo descrito na aplicação da metodologia Scrum (Seção 6.2). Esta é a vantagem de se utilizar as práticas de Scrum e XP, pois ambas tem características comuns e que podem ser reaproveitadas entre elas. A etapa de projeto da XP segue o princípio KIS (keep it simple – mantenha a simplicidade), e aí surge outro paradigma a ser quebrado. Atualmente a equipe de desenvolvimento da empresa é sempre motivada a codificar de forma que problemas futuros possam ser resolvidos desde agora. Isso vai de encontro ao que prega a XP onde o projeto de funcionalidade extra (porque o programador considera que será exigida depois) é desencorajado. Este é um contraponto da XP em relação às práticas atuais de desenvolvimento, pois a XP valoriza o projeto simples em relação a uma representação mais complexa. No entanto, é nesta mesma etapa de projeto que surge um ponto apontado como benéfico por ser comum a pratica da XP e o que se busca no processo atual de desenvolvimento: a refabricação (ou refatoração). Fowler (2000) define a refabricação da seguinte forma: “Refabricação é o processo de modificar um sistema de software de tal modo que ele não altere o comportamento externo do código, mas aperfeiçoe a estrutura interna. É um modo disciplinado de limpar o código (e modificar/simplificar o projeto interno) que minimiza as chances de introdução de defeitos. Em essência, quando você refabrica está aperfeiçoando o projeto do código depois que ele foi escrito.”

O projeto de codificação da XP tem como ponto de partida o desenvolvimento de testes unitários para as funcionalidades descritas nas user stories. Conforme descrito na Seção 5, atualmente já existe um processo semelhante, isto é, existe um framework de testes que é alimentado a cada vez que uma nova funcionalidade é desenvolvida. Mas como já foi dito, esta prática precisa ser revista e aplicada de uma melhor forma, pois em muitos casos ela não é explorada como deveria. Além deste framework de testes, os sistemas da Data Cempro possuem algumas classes de validação utilizadas principalmente na importação de dados de sistemas de terceiros. Estas classes funcionam como uma espécie de teste unitário, garantindo que haja integridade nos dados que estão sendo importados.

6.3

Apresentação dos resultados

Ao término do período experimental de aplicação de métodos ágeis de desenvolvimento, será elaborado um relatório contendo um quadro comparativo com as métricas de produção da equipe. Para alimentar este estudo, deverá ser utilizada a média de requisições concluídas pela equipe nas últimas liberações de versão, por exemplo. Como a idéia é avaliar o desempenho da equipe, não será feito nenhuma média individual. O objetivo é demonstrar com os resultados apresentados que uma empresa ou equipe de desenvolvimento pode ser considerada ágil apenas com a aplicação de algumas práticas de determinadas metodologias, dependendo da sua necessidade. O que se espera também é que os resultados motivem os gerentes de desenvolvimento a pensar em métodos ágeis como um agente facilitador na execução das tarefas diárias da equipe, motivando assim o grupo a procurar cada vez mais a agilidade na tarefa de desenvolver software. Os resultados serão demonstrados basicamente de duas formas: quantitativa e qualitativa. Para a apresentação dos resultados na forma quantitativa, será tomado por base o número médio de requisições que 13

a equipe costuma entregar concluída a cada liberação de versão, controlando também a questão de prioridade, complexidade e horas trabalhadas pelo time. O objetivo é ter um parâmetro para as futuras avaliações que só terão um resultado mais apurado em um prazo mais longo, com todos os membros da equipe adaptados ao processo ágil de desenvolvimento de software. A apresentação qualitativa de resultados será baseada em entrevistas realizadas com todas as pessoas envolvidas no projeto de alguma forma, seja direta ou indireta. Com isso pretende-se avaliar o grau de satisfação da equipe e também dos clientes. Esta será uma avaliação considerada mais real, com resultados apresentados de forma mais confiável.

7

CRONOGRAMA DE ATIVIDADES

Aplicar uma técnica ou método de desenvolvimento não é uma tarefa das mais simples, haja vista que pode se tratar de uma quebra de paradigma. Uma equipe de desenvolvimento de software que trabalha há certo tempo sem uma metodologia específica pode sentir o impacto de adotar o uso do Scrum ou XP, por exemplo. Por isso que será adotada a aplicação em etapas, ou seja, primeiro uma coisa depois outra. A adoção das duas metodologias em paralelo poderia ser radical demais e acabar tendo um efeito contrário ao que se espera. Além da XP e Scrum, a melhora da TDD, já utilizada pela equipe da Data Cempro, é outro desafio a ser cumprido. Haja vista que esta etapa requer menos tempo por já estar sendo utilizada, é preferível que seja tais melhorias comecem a serem revistas após o impacto inicial da aplicação das práticas desconhecidas pela equipe. O cronograma de atividades é descrito no Quadro 2 para destacar o que se pretende executar e em quais períodos: Quadro 2 – Cronograma de atividades Ago/2011 Set/2011 Out/2011

Nov/2011

Reunião para definições Aplicação de práticas Scrum Aplicação de práticas XP Revisão das práticas TDD Apresentação dos resultados

8

CONSIDERAÇÕES FINAIS

Este artigo teve o importante papel de realizar um estudo sobre algumas das metodologias ágeis mais utilizadas atualmente com o objetivo de colocá-las em prática em uma próxima etapa. Com base nas referências utilizadas para o desenvolvimento deste documento, foi adquirido um maior conhecimento sobre as melhores práticas de desenvolvimento de software, considerando e analisando o que foi dito e escrito pelos autores referenciados. Entende-se que este é apenas o início de um projeto que visa alcançar resultados mais relevantes, não apenas agregando para a empresa no sentido de melhorar a produtividade, como também expandindo a visão da equipe de desenvolvimento. Foram apresentados valores, princípios e práticas das metodologias Scrum, XP e TDD, traçando um paralelo com as metodologias tradicionais aplicadas na maioria das fábricas de software. Isso não representa nenhuma preferência nesta disputa entre engenheiros de software e agilistas, apenas fortalece o que cada um dos dois lados tem de melhor. O objetivo não é apontar se um leva vantagem sobre o outro, mas sim mostrar que ambos possam trabalhar em conjunto. Levando em consideração tudo o que foi estudado, o próximo passo deste trabalho será aplicar as práticas ágeis de desenvolvimento de software em uma equipe educada com base na Engenharia de Software tradicional. Durante a realização prática deste projeto, será verificado se a aplicação das práticas abordadas neste artigo atende ao que foi proposto, tirando-se mais conclusões cabíveis baseando-se nos resultados apresentados ao final da etapa de implementação.

14

REFERÊNCIAS AGILE MANIFESTO, Disponível em: . Acesso em: 13 abr. 2011. BECK, Kent. Programação Extrema Explicada. Boston, Bookman, 1999. BECK, Kent. Test-Driven Development by Example. Addison-Wesley, 2003. FOWLER, Martin. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 2000. FOWLER, Martin. The New Methodology, 2005. Disponível em: . Acesso em: 22 mai. 2011. GLASS, R.L. Agile Versus Traditional: Make Love Not War. Cutter IT Journal, 2001. HIGHSMITH, Jim. Agile Project Management, 2002. JACOBSON, Ivar. A Resounding “Yes” to Agile Processes – But Also More. Cutter IT Journal, 2002. KNIBERG, Henrik. Scrum e XP direto das Trincheiras. C4Media, 2007. PRESSMAN, Roger S. Engenharia de Software. 6ª ed. McGraw-Hill, 2006. MADEIRA, Fernando. Métodos Ágeis. Dev Day, Sisnema, 2011. SANTANA, Célio; GUSMÃO, Cristiane. Melhoria de Processo de Software no Desenvolvimento Ágil. Revista Engenharia de Software. Ano 2, 14ª ed. DevMedia, 2009. SCHWABER, Ken & BEEDLE, Mike. Agile Software Development with SCRUM, Prentice-Hall, 2002. SCHWABER, Ken. Scrum Development Process. OOPSLA'95 Workshop on Business Object Design and Implementation. Springer-Verlag, 1995. SOMMERVILLE, Ian. Software Engineering. 6 ª ed. Addison-Wesley, 2000. STAVARENGO, Rafael. Desenvolvimento ágil. Revista Clube Delphi. Ano 9, 125ª ed. DevMedia, 2011. YOSHIMA, Rodrigo. O mito da Cultura Ágil. 03 abr. 2011. Disponível em: . Acesso em: 30 mai. 2011. WIKIPEDIA, Desenvolvimento ágil de software. Disponível em: . Acesso em: 13 abr. 2011.

15