UNIVERSIDADE LUTERANA DO BRASIL CURSO DE CIÊNCIA DA COMPUTAÇÃO CÂMPUS GRAVATAÍ FERRAMENTA PARA GERENCIAMENTO DE REQUISITOS EM METODOLOGIAS ÁGEIS

Transcrição

1 UNIVERSIDADE LUTERANA DO BRASIL CURSO DE CIÊNCIA DA COMPUTAÇÃO CÂMPUS GRAVATAÍ FERRAMENTA PARA GERENCIAMENTO DE REQUISITOS EM METODOLOGIAS ÁGEIS Eduardo dos Santos Gonçalves Monografia desenvolvida durante a disciplina de Trabalho de Conclusão de Curso em Ciência da Computação II e apresentada ao Curso de Ciência da Computação da Universidade Luterana do Brasil, campus Gravataí, como pré-requisito para a obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof. Heitor Boeira dos Reis Filho Gravataí, dezembro de 2008.

2 2 Universidade Luterana do Brasil ULBRA Curso de Ciência da Computação Campus Gravataí Reitor: Pastor Ruben Eugen Becker Vice-Reitor: Eng. Leandro Eugênio Becker Diretor do Campus Gravataí: Prof. Felício Korb Coordenadora do Curso de Ciência da Computação (Campus Gravataí): Prof.ª Patrícia Nogueira Hübler Coordenador das Disciplinas de Trabalho de Conclusão de Curso (Campus Gravataí): Prof. Roland Teodorowitsch Banca Avaliadora composta por: Data da defesa: 12/12/2008. Prof. Heitor Boeira dos Reis Filho (Orientador) Prof. Leomar Rocha Pacheco da Costa Prof.ª Patrícia Nogueira Hübler CIP Catalogação na Publicação Gonçalves, Eduardo dos Santos Ferramenta para Gerenciamento de Requisitos em Metodologias Ágeis / Eduardo dos Santos Gonçalves; [orientado por] Heitor Boeira dos Reis Filho. Gravataí: p.: il. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação). Universidade Luterana do Brasil, Engenharia de Software. 2. Processo de Desenvolvimento. 3. Metodologias Ágeis. I. Reis Filho, Heitor Boeira dos. II. Título. Endereço: Universidade Luterana do Brasil Campus Gravataí Av. Itacolomi, Bairro São Vicente CEP Gravataí-RS Brasil

3 SUMÁRIO LISTA DE FIGURAS...5 LISTA DE ABREVIATURAS E SIGLAS...6 RESUMO...7 ABSTRACT INTRODUÇÃO METODOLOGIAS ÁGEIS EXTREME PROGRAMMING Valores Práticas Papéis Ciclo de vida SCRUM Características Fases A Equipe FEATURE-DRIVEN DEVELOPMENT Funcionalidade Ciclo de vida Papéis ANÁLISE DAS METODOLOGIAS REQUISITOS PRÁTICAS E CICLO DE VIDA PAPÉIS DEFINIÇÃO DA METODOLOGIA CICLO DE VIDA COLETA DOS REQUISITOS PRÁTICAS PAPÉIS ARTEFATOS PROJETO E IMPLEMENTAÇÃO DA FERRAMENTA PROPOSTA ITERAÇÃO ITERAÇÃO ITERAÇÃO

4 4 5.4 ITERAÇÃO ITERAÇÃO ITERAÇÃO ITERAÇÃO PROJETO E IMPLEMENTAÇÃO DO ESTUDO DE CASO ESTUDO COMPARATIVO ENTRE FERRAMENTAS PLANDORA PROJECT MANAGEMENT OSRMT ANÁLISE COMPARATIVA CONCLUSÃO DIFICULDADES ENCONTRADAS TRABALHOS FUTUROS...46 ANEXO A CARTÕES DE HISTÓRIAS...47 ANEXO B LISTA DE FUNCIONALIDADES...56 ANEXO C PRODUCT BACKLOG...57 ANEXO D SPRINT BACKLOG...58 ANEXO E MODELO DE DOMÍNIO DE NEGÓCIO...61 ANEXO F DIAGRAMA DE CLASSE DA CAMADA DE CONTROLE...62 ANEXO G DIAGRAMA DE CLASSE DA CAMADA DE VISÃO...63 ANEXO H DIAGRAMA DE CLASSE DA CAMADA DE ACESSO A DADOS...64 ANEXO I DIAGRAMAS DE SEQÜÊNCIA...65 ANEXO J DIAGRAMA DE PACOTES...71 ANEXO K DIAGRAMA ENTIDADE-RELACIONAMENTO...72 ANEXO L TELAS DE INTERFACE COM O USUÁRIO...73 ANEXO M CARTÕES DE HISTÓRIAS...75 ANEXO N LISTA DE FUNCIONALIDADES GERADAS PARA O ESTUDO DE CASO...77 ANEXO O PRODUCT BACKLOG GERADO PARA O ESTUDO DE CASO...78 ANEXO P SPRINT BACKLOG DO ESTUDO DE CASO...79 ANEXO Q TELAS DE INTERFACE COM O USUÁRIO...80 ANEXO R MODELO DE DOMÍNIO DO NEGÓCIO...81 ANEXO S DIAGRAMA DE SEQÜÊNCIA...82 REFERÊNCIAS...83 OUTRAS OBRAS CONSULTADAS...84

5 LISTA DE FIGURAS Figura 1 Ciclo de vida da XP...16 Figura 2 Fases do Scrum. Adaptado de Agile Software Development with Scrum...18 Figura 3 Exemplo de Template de Funcionalidade...20 Figura 4 Ciclo de Vida da FDD...21 Figura 5 Ciclo de vida da metodologia proposta Adaptado do site Figura 6 Cartão de história utilizado...29 Figura 7 Modelo de domínio do sistema...31 Figura 8 Fragmento do Diagrama de Entidade-Relacionamento...32 Figura 9 Classes CtrlUsuario e CtrlPapel, do pacote Controller...33 Figura 10 Classe UsuarioDao, do pacote Dao...33 Figura 11 Diagrama de Seqüência Figura 12 Diagrama de Seqüência Figura 13 Tela de Login no sistema...34 Figura 14 Tela de Cadastro de novo usuário no sistema...35 Figura 15 Fragmento do diagrama Entidade-Relacionamento...35 Figura 16 Classes CtrlRequisitos, CtrlProjeto e CtrlParticipante, do pacote Controller...36 Figura 17 Classes ParticipanteDao, RequisitoDao e ProjetoDao, do pacote Dao...36 Figura 18 Diagrama de Seqüência Figura 19 Diagrama de Seqüência Figura 20 Tela de cadastro de projeto...38 Figura 21 Tela de cadastro de requisito...38 Figura 22 Fragmento do diagrama Entidade-Relacionamento...39 Figura 23 Classe CtrlCodigoFonte, do pacote Controller...39 Figura 24 Classe CodigoFonteDao, do pacote Dao...39

6 LISTA DE ABREVIATURAS E SIGLAS XP FDD UML OMG WAE TDD PDCA PHP SVN SLDC JSP CVS AJAX ER IDE Extreme Programming Feature-Driven Development Unified Modeling Language Object Management Group Web Application Extension Test-Driven Development Plan, Do, Check, Act Programming Home Pages Subversion Software Development Life Cycle Java Server Pages Concurrent Version System Asynchronous JavaScript and XML Entidade-Relacionamento Integrated Development Environment

7 RESUMO Uma das tarefas mais complicadas em um processo de desenvolvimento de software é o gerenciamento dos requisitos, onde estes podem mudar a qualquer momento por solicitação do cliente, ou por necessidades que porventura apareçam no decorrer do projeto, causando impacto direto nas rotinas de desenvolvimento de software. Dentro deste contexto, esta monografia tem como objetivo projetar e implementar uma ferramenta para auxiliar na gerência destes requisitos. O desenvolvimento da ferramenta é apoiado por uma metodologia ágil que será definida após a análise de algumas metodologias em uso atualmente. Palavras-chaves: Engenharia de Software; Processo de Desenvolvimento; Metodologias Ágeis.

8 ABSTRACT Title: Tool for Management of Requirements in Agile Methodologies One of the most complicated in a software development process is the management of the requirements, where they can change at any time by request of the client, or perhaps needs that appear during the project, causing direct impact on the routines of software development. Within this context, this paper aims to design and implement a tool to assist in the management of these requirements. The development of the tool is supported by an agile methodology that will be defined after an analysis of some methods currently in use. Key-words: Software Engineering; Process of Development; Agile Methodologies.

9 1 INTRODUÇÃO A grande dinâmica dos negócios globais traz uma crescente necessidade de produtos de software que atendam suas necessidades. Um grande número de tecnologias e processos de desenvolvimento de software foram criados nas últimas décadas para tornar viável a construção de softwares confiáveis e que atendam às necessidades dos clientes finais. Uma das áreas mais críticas no processo de desenvolvimento de software é a engenharia de requisitos, pois, a partir destes, todo o desenvolvimento será realizado. O processo de engenharia de requisitos é um processo que funciona por realimentação de informações. À medida que o processo de software flui, as necessidades dos usuários são melhores compreendidas pelos desenvolvedores do sistema, graças ao feedback dos próprios usuários. Estas novas informações adicionadas ao sistema podem fazer com que alguns requisitos sejam modificados e o modelo do sistema se torne mais acurado. Modificações nos requisitos durante o processo são inevitáveis e devem ser previstas no documento de requisitos do software. A negligência na atualização do documento de requisitos leva o processo de software a um estado de inconsistência que pode ocasionar sérios problemas de manutenibilidade no futuro (SOMMERVILLE, 2007). Os requisitos não-funcionais são particularmente mais afetados pela evolução do hardware. Um sistema de grande porte é geralmente desenvolvido para durar vários anos, tempo no qual a capacidade das máquinas disponíveis no mercado irá se multiplicar algumas vezes. Por este e por outros motivos, deve-se prever que os requisitos não funcionais venham a ser modificados mesmo depois do software já estar em uso. O cuidado com a documentação dos requisitos também gera um novo problema relativo à constante atualização do documento. Normalmente, para se fazer a comunicação entre clientes e desenvolvedores, utiliza-se cópias impressas do documento de requisitos, ou mesmo durante o processo de desenvolvimento, é conveniente que se tenha sempre a mão uma cópia em papel deste material. Isto gera um problema ecológico de desperdício de papel além do problema organizacional de se acumular versões antigas de documentos. Como garantir que aquela cópia do documento de requisitos largada em cima do armário é a cópia mais recente? (SOMMERVILLE, 2007) A solução natural para este problema seria a utilização de documentos eletrônicos, aliados a um bom controle de versões. Entretanto, além do inconveniente de se ter que ir até o computador para ler o documento, os processadores de texto modernos são baseados em um conceito de forma livre, e quando a atualização de um documento é feita por várias pessoas é comum que o documento acabe saindo do padrão estabelecido. Além disto, é difícil e caro sincronizar todos os participantes do processo do software com a mesma versão do processador de textos de forma a evitar que uma pessoa não consiga abrir um documento gerado por outro em uma versão mais atualizada do programa (SOMMERVILLE, 2007).

10 10 Dentro deste contexto, este trabalho tem como objetivos, estudar algumas das metodologias ágeis mais utilizadas nos dias de hoje, com a finalidade de adaptá-las para tornar a atividade de levantamento, especificação e controle de requisitos um pouco mais formal, tendo em vista que este não é o ponto forte das metodologias ágeis. Outro objetivo será comparar e avaliar vantagens, desvantagens e aplicações, a fim de escolher a melhor metodologia que possa ser adaptada em um cenário de até dez colaboradores. Após, pretendese analisar, projetar e desenvolver uma ferramenta de gerenciamento de requisitos, que controle a evolução dos requisitos, bem como as mudanças de código ocorridas durante o desenvolvimento do requisito cadastrado. O desenvolvimento desta ferramenta será apoiado por uma metodologia ágil que será definida após a análise das metodologias. Por fim, é feita uma análise comparativa entre outros trabalhos e ferramentas existentes no mercado. No segundo capítulo, são detalhadas as metodologias ágeis que serão estudadas, Extreme Programming, Scrum e Feature-Driven Development, descrevendo seus valores, práticas, papéis e ciclo de vida. No terceiro capítulo, é descrita a comparação realizada entre as metodologias estudadas no capítulo anterior, descrevendo vantagens e desvantagens de cada uma, bem como é apresentado um modelo híbrido de processo de desenvolvimento, agrupando as melhores práticas estudadas. No quarto capítulo, é detalhada a análise e o projeto da ferramenta proposta, bem como os respectivos detalhes de implementação, descrevendo a evolução da mesma de acordo com o andamento das iterações. No quinto capítulo, é detalhada a análise e o projeto de uma ferramenta real, descrevendo sua evolução de acordo com a metodologia definida. No sexto capítulo, é descrito o estudo de duas ferramentas de natureza semelhante à ferramenta que foi projetada e implementada, visando comparar a mesma com as soluções estudadas. Por fim, no último capítulo, são apresentadas as conclusões obtidas após a execução deste trabalho, bem como apresentadas as dificuldades que foram encontradas no decorrer deste trabalho.

11 2 METODOLOGIAS ÁGEIS O termo Metodologias Ágeis tornou-se popular em fevereiro de 2001, quando um grupo de dezessete grandes pensadores em processo de desenvolvimento de software, se encontraram em uma estação de esqui em Utah, Estados Unidos, para que cada um explicasse a maneira como desenvolvia projetos de software (BECK e FOWLER, 2000). O objetivo desse encontro em 2001 não era somente deixar um marco na história do desenvolvimento de software, mas sim, juntar um grupo de mestres para oferecer ao mundo uma alternativa às metodologias pesadas e altamente dirigidas por documentação. Também não era objetivo desse encontro fazer que todos concordassem somente com uma única visão, muitos dos presentes eram até de empresas concorrentes entre si, mas, eles concordaram em um conjunto de valores ágeis que resumem todas as diferentes metodologias apresentadas. Foi então criada a Aliança Ágil e o estabelecimento dos valores do Manifesto Ágil, o consenso dos participantes do encontro. Os conceitos chave do Manifesto Ágil são: Indivíduos e interações são mais importantes do que processos e ferramentas; Software funcionando é mais importante que uma documentação extensa; O relacionamento com o cliente é mais importante que a negociação do contrato; Responder às mudanças é mais importante que seguir o planejamento. O Manifesto Ágil não rejeita os processos e ferramentas, a documentação, a negociação de contratos ou o planejamento, mas simplesmente mostra que eles têm importância secundária quando comparado com os indivíduos e interações, com o software estar executável, com a colaboração do cliente e as respostas rápidas a mudanças e alterações. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem a mudanças. Dentro deste contexto, nos próximos itens, apresentam-se três das metodologias ágeis mais utilizadas nos dias de hoje, são elas: Extreme Programming, Scrum e Feature-Driven Development, descrevendo as características, papéis, práticas e ciclo de vida de cada uma das metodologias. 2.1 EXTREME PROGRAMMING O Extreme Programming (XP) é um conjunto bem definido de práticas e valores que vem conquistando um grande número de adeptos. Começou a ser desenvolvido em 1996 por Kent Beck no departamento de computação da montadora de automóveis DaimlerChrysler, e possui muitas diferenças em relação aos outros, podendo ser aplicado a projetos com altos riscos e requisitos dinâmicos.

12 12 Segundo Kent Beck e Martin Fowler (2000), a XP enfatiza o desenvolvimento rápido do projeto e visa garantir a satisfação do cliente, além de favorecer o cumprimento das estimativas. As práticas e os valores da XP proporcionam um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos por quatro valores: comunicação, coragem, feedback e simplicidade Valores Equipes XP se baseiam em quatro valores adotados a fim de guiar o desenvolvimento, que correspondem a dimensões nas quais os projetos podem ser melhorados. XP oferece condições para que os desenvolvedores possam responder com confiança a alterações de requisitos propostas pelos clientes, mesmo em estágios finais do ciclo de vida do processo (BECK e FOWLER, 2000). Kent Beck e Martin Fowler (2000) definem estes valores como: Comunicação: Embora existam inúmeras formas de se comunicar idéias, algumas são mais eficazes que outras. Quanto maior a capacidade de compreensão, maior as chances de evitar problemas como ambigüidades, entendimento equivocado, entre outros. Diálogos são mais eficazes que videoconferências, que são melhores que telefonemas e são mais expressivos que s e assim sucessivamente. Conscientes disso, equipes XP priorizam o uso do diálogo presencial, com o objetivo de garantir que todas as partes envolvidas em um projeto tenham a chance de se compreender da melhor maneira possível; Coragem: XP não tem uma solução mágica para eliminar o risco de se quebrar o que já vinha funcionando, através de alterações em partes do sistema que já estavam prontas. Equipes XP acreditam que errar é natural e quebrar o que vinha funcionando pode acontecer eventualmente. É necessário ter coragem para lidar com esse risco, o que em XP se traduz em confiança nos seus mecanismos de proteção. As práticas são voltadas, entre outras coisas, para proteger o software de inúmeras formas. Equipes XP confiam na eficácia destas práticas e destes mecanismos de proteção e isso é o que as tornam receptivas a mudanças. Assim, ao invés de frear a criatividade do cliente e evitar mudanças, equipes XP as consideram inevitáveis e procuram se adaptar a elas com segurança e com coragem, isto é, com confiança em seus mecanismos de proteção; Feedback: projetos XP estabelecem formas de encurtar ao máximo a defasagem de tempo entre o momento em que uma ação é executada e o seu resultado é observado. Assim, por exemplo, desenvolvedores procuram entregar novas funcionalidades no menor prazo possível, para que o cliente compreenda rapidamente as conseqüências daquilo que pediu. Os clientes, por sua vez, procuram manterem-se próximos dos desenvolvedores para prover informações precisas sobre qualquer dúvida que eles tenham ao longo do desenvolvimento; Simplicidade: Assim como outras metodologias ágeis, a XP se baseia em premissas que, freqüentemente, representam o inverso do que as práticas habituais da indústria de software sugerem. A XP utiliza o conceito de simplicidade em inúmeros aspectos do projeto para assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se provou essencial.

13 Práticas A Extreme Programming possui doze práticas, agrupadas em quatro áreas, derivadas das melhores práticas da Engenharia de Software. Kent Beck e Martin Fowler (2000) descrevem-nas como segue: Feedback de escala perfeito: nesta área, encontram-se as práticas de Programação em Par, Jogo de Planejamento, Desenvolvimento Orientado a Testes e Cliente no Local : - Programação em Par: é uma técnica onde dois programadores trabalham juntos em uma máquina. Um programador (chamado de motorista) escreve o código enquanto o outro (chamado de observador, ou navegador) revisa cada linha de código escrita. Os dois programadores podem trocar de funções com freqüência. Revendo, o observador também considera a direção estratégica do trabalho, podendo apontar melhorias e futuros problemas. Isto libera o motorista para focar toda sua atenção nos aspectos táticos de concluir a tarefa atual, usando o observador como uma rede de segurança e guia; - Jogo de Planejamento: é uma reunião que ocorre uma vez por iteração, tipicamente uma vez por semana e determina o alcance do seguinte lançamento, combinando prioridades de negócios e estimativas técnicas; - Desenvolvimento Orientado a Testes (TDD): TDD é uma técnica de desenvolvimento de software composta de iterações curtas onde os novos casos de teste que cobrem a melhora desejada ou nova funcionalidade são escritos primeiro. Após, o código de produção necessário para realizar os testes é implementado, e finalmente o software é refatorado para acomodar modificações; - Cliente no Local: dentro da XP, o cliente não é aquele que paga a conta, mas aquele que realmente usa o sistema e que deve estar sempre à mão e disponível para perguntas. Processo contínuo: nesta área, encontram-se as práticas de Integração Contínua, Refatoração e Pequenos Lançamentos : - Integração Contínua: descreve um jogo de práticas da engenharia de software que aceleram a entrega de software reduzindo tempos de integração e construindo o sistema muitas vezes por dia, a cada tarefa concluída; - Refatoração: é a prática onde os programadores reestruturam o sistema sem modificar o seu comportamento, para retirar duplicações, redundâncias, eliminando funcionalidades não utilizadas, remodelando desenhos obsoletos, podendo ainda melhorar a comunicação, simplificar, ou acrescentar flexibilidades; - Pequenos Lançamentos: a entrega do software é feita em lançamentos predeterminados (chamados Builds). O plano de lançamento é determinado no início do projeto. Normalmente cada lançamento transportará um pequeno segmento do software total, que pode correr sem depender de componentes que serão construídos no futuro. Os pequenos lançamentos ajudam o cliente a ganhar confiança no progresso do projeto. Isto ajuda a manter o conceito de Cliente no Local, podendo o mesmo sugerir alterações no projeto; Compreensão compartilhada: nesta área, encontram-se as práticas de Codificação de Padrões, Propriedade de Código Coletiva, Desenho Simples e Metáfora de Sistema :

14 14 - Codificação de Padrões: nesta prática, a equipe de desenvolvimento decide um conjunto de regras que serão usadas por todo o projeto, especificando um estilo consistente de formatação de código-fonte, dentro da linguagem de programação escolhida. Pode ser convenções especificadas pela linguagem ou costumes definidos pela equipe de desenvolvimento; - Propriedade de Código Coletiva: significa que todos os programadores são responsáveis pelo código, permitindo que modifiquem qualquer parte dele a qualquer momento. Trabalhando em pares diferentes, todos os programadores poderão ter acesso a todas as partes do código, podendo corrigir qualquer erro que venha a ocorrer; - Desenho Simples: programadores devem tomar a premissa de que um desenho de software simples é melhor. Sempre que uma nova parte do código seja escrita, o autor deve se perguntar se está há um modo mais simples de introduzir a mesma funcionalidade?. Se a resposta for sim, a alternativa simples deve ser escolhida. A refatoração também deve ser usada, fazendo o complexo se tornar simples; - Metáfora de Sistema: é um conceito de nomeação de classes e métodos que devem torná-los fácil para qualquer membro da equipe tomar conhecimento da funcionalidade de uma determinada classe ou método, apenas lendo o seu nome. Passo Sustentável: conceito de que os programadores não devam trabalhar mais do que 40 horas semanais e de que as horas extras sejam incluídas a cada duas semanas, desde que os ciclos de desenvolvimento sejam curtos, de integração contínua e freqüente. Está incluída neste conceito também, a premissa de que funcionários descansados rendem melhor desempenho e maior criatividade Papéis Papéis em uma equipe XP não são fixos e nem rígidos. O objetivo é fazer com que cada um contribua com o melhor que tem a oferecer para que a equipe tenha sucesso. Em princípio, papéis fixos podem ser úteis para se aprender novos hábitos, como por exemplo, fazer com que as decisões técnicas sejam deixadas para o pessoal técnico e decisões de negócio, com pessoas de negócio. A partir do momento em que novas relações, respeitosas, sejam estabelecidas entre os membros da equipe, papéis fixos passam a interferir no objetivo de fazer com que cada um dê o melhor de si (BECK e FOWLER, 2000). Kent Beck e Martin Fowler (2000) descrevem os papéis como segue: Analistas de Teste: tem papel pró-ativo. No início de cada iteração, ajudam os clientes e os desenvolvedores a escreverem testes para as histórias, antes mesmo que elas sejam implementadas. Além disso, trabalham com os desenvolvedores ao longo da iteração, ajudando-os a automatizar os testes; Arquitetos: Arquitetos de software em um projeto XP ajudam os desenvolvedores no dia-a-dia através da programação em par. Além disso, utilizam seus conhecimentos para ajudar a equipe a fazer refatorações em larga escala, em passos curtos e seguros. Também podem ajudar a equipe a criar testes mais amplos, que exercitem a arquitetura como um todo. Ajudam a programar histórias para vivenciarem as conseqüências das decisões tomadas e tem autoridade para fazer mudanças em larga escala, precisando sofrer as conseqüências de suas decisões;

15 15 Designers de Interação: trabalham próximo aos clientes, ajudando a escrever histórias e escolher metáforas consistentes para o projeto. Além disso, ajudam a criar a interface e a refiná-la continuamente ao longo do tempo. Também avaliam o uso das funcionalidades pelos clientes à medida que vão sendo entregues no final de cada ciclo semanal; Executivos: ajudam na definição do escopo do projeto. Comunicam os objetos do projeto dentro do contexto geral da organização e asseguram que as histórias estejam alinhadas com tais objetivos. Além disso, ajudam a comunicar o progresso da equipe para as demais áreas da organização. Encorajam a equipe, permitindo que ela avance mais rapidamente e com menos transtornos oriundos de pressões dos usuários; Gerentes de Projeto: servem de ponte entre a equipe, os clientes e eventuais fornecedores. Ele assegura que as pessoas certas dialoguem dentro da equipe e fora dela, agindo como um facilitador no fluxo de comunicação do projeto. Seu propósito não é controlar a informação, mas assegurar que as pessoas consigam se comunicar prontamente. Também monitoram o progresso da equipe e ajudam a perceber continuamente tudo o que já foi conquistado; Gerentes de Produto: procuram definir histórias que ajudem o produto a tomar um corpo coerente e harmônico. Eles ajudam a definir prioridades e esclarecem aspectos das histórias ao longo do desenvolvimento. Ajudam a reduzir o escopo quando a equipe está atrasada por alguma razão; Programadores: trabalham em pares implementando histórias. Também estimam as histórias na prática de Jogo do Planejamento e automatizam tarefas repetitivas. Programadores são responsáveis pela criação de testes automatizados para tudo o que produzem. Isso é feito com a prática de Desenvolvimento Orientado a Testes. Além de criarem novas funcionalidades, também refatoram o sistema permanentemente para aprimorar a arquitetura, eliminar duplicações e tornar o código mais claro; Recursos Humanos: projetos XP afetam as práticas de recursos humanos de uma organização, em particular no que se refere a contratações e avaliações periódicas dos funcionários. O fato de os programadores trabalharem em pares, por exemplo, leva à necessidade de pessoas que não apenas tenham boas habilidades técnicas, mas também saibam interagir socialmente com naturalidade. Portanto, a contratação não pode se basear apenas em critérios técnicos e as avaliações individuais se tornam complexas porque é difícil isolar o rendimento do trabalho individual quando se trabalha em par a maior parte do tempo; Redatores Técnicos: ajudam a equipe a criar e manter a documentação do projeto. Se a equipe mantiver documentos extensos e muito elaborados, ela dificilmente será capaz de entregar um conjunto significativo de novas funcionalidades a cada iteração. Redatores técnicos asseguram que a documentação evolua de forma iterativa. Ao invés de investirem em documentar o projeto extensivamente desde o início de cada iteração, eles atualizam os documentos mais perto do fim das iterações, descrevendo o que foi feito de fato pelos desenvolvedores; Usuários: ajudam a escrever e selecionar histórias e tomam decisões relativas ao domínio do negócio durante o desenvolvimento. Sua participação é tão valiosa quanto for seu conhecimento sobre o domínio do negócio.

16 Ciclo de vida O ciclo de vida da XP é bastante curto e, à primeira vista, difere dos padrões dos modelos de processo convencionais. No entanto, esta abordagem pode fazer sentido em um ambiente onde as mudanças de requisitos do sistema são fatores predominantes. A Figura 1 representa de forma simplificada as quatro fases principais do ciclo de vida da XP. Figura 1 Ciclo de vida da XP Na fase de Planejamento os requisitos do cliente são cuidadosamente coletados em forma de histórias (user stories) através de reuniões de planejamento, de onde saem às histórias mais importantes para a versão, realizadas com freqüência. Também nesta fase, é criado um plano para a entrega de uma nova versão do produto, bem como é feita uma estimativa inicial da velocidade do projeto, além dos testes de aceitação que apresentaram problemas no ciclo anterior. A seguir, na fase de Teste, são elaborados a partir das especificações do cliente, testes unitários e testes de aceitação. Testes unitários são criados antes do código e armazenados em um repositório junto ao código que será testado. Testes de aceitação são escritos pelos clientes ou usuários finais, através das user stories. A fase de Codificação está focada nos métodos para a codificação dos módulos que compõem o projeto. Nesta fase, são utilizadas algumas práticas a fim de manter a qualidade do código, como: Programação em Par, Integração Contínua e a criação dos testes antes da criação do código. Além disso, a participação contínua do cliente é indispensável para que a equipe de desenvolvimento faça um bom trabalho. Por fim, na fase de Projeto, o sistema é novamente projetado (ou reconstruído) à medida que novas funcionalidades são incorporadas ou são requeridas alterações pelo cliente. Tal prática visa manter o código mais claro e simples possível, melhorando o sistema de uma forma confiável e usando a reconstrução, a fim de garantir um bom conhecimento dos padrões em termos de utilização, implementação simples, evolução e remoção, e saber como comunicar um projeto a pessoas que precisam entendê-lo usando códigos, diagramas e principalmente, conversação.

17 SCRUM Jeff Sutherland aplicou a primeira concepção do Scrum na Easel Corporation em 1993, mais tarde, por volta de 1995, Ken Schwaber refinou essa metodologia baseando-se em sua própria experiência no desenvolvimento de sistemas e processos. Segundo Ken Schwaber (2004), o Scrum assume-se como uma metodologia extremamente ágil e flexível, que tem por objetivo definir um processo de desenvolvimento interativo e incremental podendo ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa. Esta metodologia baseia-se no desenvolvimento incremental das aplicações centrado na equipe com ciclos de iteração curtos. Scrum aplica-se a projetos tanto pequenos como grandes. Esforçando-se para liberar o processo de quaisquer barreiras, o seu principal objetivo é conseguir uma avaliação correta do ambiente em evolução, adaptando-se constantemente ao caos de interesses e necessidades, indicadas e utilizadas para o desenvolvimento de softwares em ambientes complexos, onde os requisitos mudam com certa freqüência, sendo o caminho utilizado para aumentar produtividade nesses tipos de sistemas. A Scrum estabelece um conjunto de regras e práticas de gestão que devem ser adotadas para garantir o sucesso de um projeto. Centrado no trabalho em equipe, melhora a comunicação e maximiza a cooperação, permitindo que cada um faça o seu melhor, se sentindo motivado profissionalmente, proporcionando um aumento de produtividade. Englobando processos de engenharia, este método não requer nem fornece qualquer técnica ou método específico para a fase de desenvolvimento de software Características Ken Schwaber e Mike Beedle (2001) caracterizaram os projetos Scrum em sua obra Agile Software Development With Scrum como segue: Entrega flexível: o conteúdo da entrega é definido pelo ambiente, através das necessidades de negócio, competição, funcionalidade e tempo. Cronograma flexível: a entrega pode ser requerida mais cedo ou mais tarde do que o estabelecido pelo planejamento inicial. Times de desenvolvimento pequenos: cada time de desenvolvimento tem, no máximo, seis membros. Podem existir vários times em um mesmo projeto. Revisões freqüentes: a evolução do time, a complexidade do ambiente e os riscos são revistos freqüentemente. Para essas revisões o time deve preparar uma execução funcional. Colaboração: espera-se intra e intercolaboração durante o projeto. Orientação a Objeto: cada time trabalha em um conjunto de objetos com interfaces e comportamentos claros. Oferece um ambiente mais gerenciável. Não há processo de desenvolvimento pré-definido. Um princípio chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando uma abordagem tradicional de controle. Assim, o Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes (SCHWABER e BEEDLE, 2001).

18 Fases Os projetos Scrum são divididos em fases: Fase de Planejamento (Sprint Planning Meeting), Fase de Execução (Sprint), Fase de Revisão (Sprint Review) e Fase de Retrospectiva (Sprint Retrospective). A Figura 2 ilustra as fases do Scrum. Figura 2 Fases do Scrum. Adaptado de Agile Software Development with Scrum Conforme descrito por Schwaber e Beedle (2001), a Fase de Planejamento (Sprint Planning Meeting) é divida em duas partes e se dá no início de cada Sprint e é composta por todos os comprometidos, além de alguns envolvidos que podem ser convidados a participar em determinados momentos da reunião, desde que agreguem valor à mesma e tenham seu convite aprovado pelo Product Owner. Na primeira parte, o Product Owner e o time, sendo facilitados pelo Scrum Master, realizam uma revisão no Product Backlog, discutindo sobre o propósito e metas de cada item e dando a oportunidade para que o Product Owner exponha seus desejos. O time seleciona os itens que acredita que possam ser desenvolvidos no próximo Sprint e define a meta. O Product Backlog deve ter sido preparado pelo Product Owner antes da reunião de planejamento, auxiliado pelo Scrum Master. A segunda parte da reunião de planejamento deve ocorrer imediatamente após a finalização da primeira. Nesta, o Product Owner deve estar disponível para, caso necessário, detalhar algum item ou remover dúvidas quanto ao objetivo do mesmo. O time deve elaborar a estratégia de desenvolvimento que será utilizada para que a meta do Sprint seja atingida. Ao final desta reunião eles devem saber responder como construirão as funcionalidades do produto durante o Sprint. Estas estratégias são geradas a partir do detalhamento dos itens do Product Backlog. As tarefas geradas através desse detalhamento são chamadas de Sprint Backlog. Os membros do time devem escolher suas tarefas e então estimá-las em horas e devem ter de uma a dezesseis horas de duração. Tarefas maiores deverão ser quebradas em duas ou mais.

19 19 Na Fase de Sprint, não há atividades bem definidas, e o trabalho vai sendo planejado durante a execução, sendo o líder o responsável pela comunicação com o cliente. Nesta fase, cada time recebe uma parte do backlog para desenvolvimento, mas o mesmo não sofre modificações durante o Sprint. Este ciclo é previsto para durar de uma a quatro semanas e sempre deve resultar em um arquivo executável ao final dele. Uma vez que o Sprint tenha sido iniciado, emergem então uma das principais práticas do Scrum, as reuniões diárias (Scrum Daily Meetings). As reuniões diárias duram cerca de quinze minutos, sendo gerenciadas pelo líder de cada equipe. Tais reuniões trazem como benefícios uma maior integração entre os membros da equipe, rápida resolução de problemas, promovendo o compartilhamento de conhecimento, sendo o progresso medido continuamente, buscando a minimização de riscos. Os intervalos entre reuniões podem variar entre duas horas e dois dias e o Scrum Master é responsável por resolver os problemas levantados na reunião. Os problemas não são discutidos na reunião, mas sim depois dela entre os membros que vão se ajudar. Após a reunião diária, os membros do time atualizam o montante de tempo que falta para completar cada tarefa do Sprint Backlog. Esta informação é gravada em um gráfico denominado Sprint Burndown. Este gráfico mostra, dia após dia, a quantidade de horas que faltam ser completada para o cumprimento da meta do Sprint, e através deste gráfico, a equipe consegue rapidamente identificar problemas no ritmo do time e tomar as providências necessárias. As Revisões (Sprint Review) devem obedecer às datas de entrega, permitindo a diminuição de funcionalidades. São feitas apresentações do produto que foi gerado (incrementado) durante o Sprint, focando nas tarefas do Sprint Backlog. Participam da Sprint Review, o Product Owner, o Scrum Master, os membros do time, clientes, stakeholders, executivos, e qualquer pessoa que esteja interessada no resultado da Sprint. O produto lançado nesta fase já poderá ser comercializado. Esta fase traz como benefícios a apresentação dos resultados concretos ao cliente, integrar e testar uma boa parte do software e motivar a equipe. A Fase de Retrospectiva (Sprint Retrospective) é uma das ferramentas mais importantes para que você obtenha sucesso com o Scrum. É a oportunidade que o time tem para discutir sobre o que funcionou e o que não funcionou durante o Sprint. Participam desta retrospectiva, o Product Owner, o Scrum Master e os membros do time. A estrutura do Sprint Retrospective é bem simples, onde se divide um quadro branco ou um pôster em duas áreas, separando o que funcionou bem com o que pode ser melhorado. Após isso, cada membro deve colocar post-its em cada uma das áreas indicando os itens que, em sua opinião, merecem estar ali. Após, o time visualiza os itens citados, discute sobre e planeja ações a serem tomadas para o próximo Sprint A Equipe A equipe em um processo Scrum é co-locada e aberta, com comunicação constante e deve ser multidisciplinar, autogerenciada, podendo variar de dois a sete membros comprometidos com o objetivo e com si mesmo. Estes membros possuem autoridade para fazer o que for necessário para atingir o objetivo, porém, equipes Scrum não se enquadram em níveis hierárquicos nem papéis, mas com várias especialidades. Ressalta-se a presença do Dono do Produto (Product Owner) e o Scrum Master. O dono do produto fornece a visão do negócio, gerenciando o retorno de investimentos e priorizando itens do backlog a cada iteração. Decide também as datas de releases e seus

20 20 conteúdos, aceitando ou não, o que foi produzido. Na maioria das vezes, o dono do produto pode ser o próprio cliente ou um representante interno. O Scrum Master é o facilitador, realiza o intermédio da comunicação entre o dono do produto e a equipe de desenvolvimento. Conduz reuniões e eventos, porém não tem autoridade, apenas resolvendo problemas que porventura apareçam como problemas logísticos e de conhecimento/habilidade e protegendo a sua equipe de riscos e interferências externas, bem como excesso de otimismo. Um membro do time é alguém que esteja comprometido a fazer o trabalho necessário para atingir a meta de um Sprint. No Scrum, não se tem arquitetos, testadores ou programadores, mas sim membros com perfis de arquitetos, de testadores ou de programadores, podendo atuar em papéis secundários também, visando garantir o alcance da meta. Os membros possuem responsabilidades de definir a meta do Sprint, estar comprometido com o trabalho e com a alta qualidade, trabalhar seguindo a visão do produto e a meta do Sprint, colaborar com outros membros do time e ajudar a torná-lo autogerenciado, estimar os itens do Backlog e garantir o esforço necessário para que as estimativas sejam realistas, participar de reuniões diárias e manifestar impedimentos (SCHWABER, 2004). 2.3 FEATURE-DRIVEN DEVELOPMENT Feature-Driven Development (FDD) é uma abordagem direta criada por Jeff De Luca e Peter Coad para desenvolvimento de software que combina as principais vantagens de outras abordagens ágeis com técnicas centradas no modelo, que podem escalar para equipes e projetos maiores. A FDD também é caracterizada por uma ênfase na qualidade por todo o processo e um monitoramento de progresso direto, preciso e com baixa ocupação. A FDD inicia com a criação de um modelo de objetos do domínio do problema, em colaboração com os especialistas no domínio. Usando a informação vinda da atividade de modelagem e de quaisquer outras atividades de coleta de requisitos que já possam ter ocorrido, os desenvolvedores prosseguem para a criação da lista de funcionalidades. A seguir, é elaborado um plano para cada funcionalidade e são atribuídas responsabilidades. Então, equipes pequenas e formadas dinamicamente desenvolvem as funcionalidades, realizando repetidamente iterações de projeto (design) e construção, que duram não mais do que duas semanas e, geralmente, são muito mais curtas Funcionalidade Funcionalidades (features) são expressões granulares que representam algum valor para o cliente e podem ser nomeadas através do uso de um template, como demonstra a Figura 3. <ação> <resultado> <objeto> Figura 3 Exemplo de Template de Funcionalidade Funcionalidades devem ter granularidades que não ultrapassem o tamanho de suas iterações, como por exemplo, se for definido que um projeto terá iterações de duas semanas,

21 21 não se devem possuir funcionalidades que ultrapassem este tempo e caso ocorra, deve-se decompô-la em mais features Ciclo de vida Segundo Stephen Palmer (2000), o ciclo de vida da FDD é composto por cinco práticas. As três primeiras práticas abrangem todo o projeto, sendo executada uma única vez no ciclo. A Figura 4 apresenta de forma simplificada o ciclo de vida da FDD. Figura 4 Ciclo de Vida da FDD Na prática Desenvolver um Modelo Abrangente, é formado um time de modelagem no qual é composto por especialistas de negócio e programadores, sendo facilitados por um arquiteto com experiência em modelagem. Nela, os especialistas de negócio apresentam ao restante da equipe uma visão do produto e juntos estudam a documentação apresentada. Após o estudo, desenvolvem-se modelos sem detalhamento para as partes de negócio que foram apresentadas. O modelo escolhido é incluso no modelo abrangente do produto, sendo este o resultado da junção de todos os modelos escolhidos por cada parte de negócio. Por fim são escritas notas e observações sobre o modelo. Na prática Construir a Lista de Funcionalidades, é formado um time de lista de funcionalidades, no qual é composto unicamente pelos programadores-chefes que participaram da prática anterior. Esta equipe constrói então, através das áreas de negócio identificadas anteriormente, uma lista das funcionalidades que compõem as atividades daquela área de negócio específica. Na prática Planejar por Funcionalidade, é formado um time de planejamento no qual é composto pelos gerentes de projeto e desenvolvimento e pelos programadores-chefes. Este time determina a seqüência do desenvolvimento baseando-se nas dependências entre elas, na carga de trabalho da equipe de desenvolvimento e também na complexidade das funcionalidades a serem implementadas. São atribuídas ainda nesta fase, as atividades de negócio aos programadores-chefes, onde cada um fica responsável por um conjunto de

22 22 atividades. Estes deverão nomear programadores que serão donos das classes que compõem o conjunto de funcionalidade que o programador-chefe ficar responsável. Na prática Projetar por Funcionalidade, os desenvolvedores responsáveis por cada classe envolvida são convocados para formarem uma equipe. Com a equipe formada, desenvolvem-se diagramas de seqüência relacionados àquela funcionalidade e é refinado o modelo abrangente feito na primeira prática, onde é incluído métodos e atributos nas classes envolvidas no desenvolvimento da funcionalidade. Por fim, são escritos os prólogos de métodos e classes, através das informações geradas pelos diagramas de seqüência e é realizada uma inspeção de design, na qual o programador-chefe da funcionalidade avalia o que foi feito durante esta prática. Na prática Construir por Funcionalidade, são implementadas classes e métodos pelos seus desenvolvedores, de acordo com a visão abrangente e o detalhamento realizado nos processos anteriores. Cada desenvolvedor deve avaliar o que foi feito com sua classe durante este processo, juntamente com outro membro da equipe. Por fim, são realizados testes de unidade nos métodos de suas classes, visando garantir o alcance das necessidades do negócio, podendo ser promovidas a build Papéis Membros de uma equipe FDD podem assumir vários papéis, sendo que o mesmo papel pode ser assumido por vários membros e cada membro pode assumir vários papéis simultaneamente. Na obra A Practical Guide to Feature-Driven Development, publicada no ano de 2002, Stephen Palmer e John Felsing sugerem a existência destes papéis. São eles: Gerente de Projeto: responsável por todos os assuntos administrativos do projeto, tais como gerenciamento de recursos humanos, orçamento, equipamentos e outros. Sua principal meta é fornecer subsídios para que nenhum fator externo atrapalhe a produtividade da equipe do projeto. Arquiteto: responsável por facilitar a absorção das regras de negócio pela equipe. Gerente de Desenvolvimento: responsável por liderar o dia-a-dia do desenvolvimento do produto. Programador-Chefe: responsável por liderar pequenos grupos de desenvolvedores durante a construção das funcionalidades do produto. Atua também como desenvolvedor e é responsável por absorver conhecimento de negócio no planejamento das funcionalidades. Programador (Dono de Classe): responsável por programar, diagramar, testar e documentar as funcionalidades que lhe são atribuídas pelo programador-chefe da equipe. Especialista do Negócio: apresenta à equipe do projeto as necessidades para que o software possua valor real para o cliente, fornecendo aos desenvolvedores um maior detalhamento sobre determinada funcionalidade. A FDD fornece, ainda, para aqueles projetos maiores e/ou mais complexos, papéis auxiliares, tais como: Gerente de Release, Testadores, Escritores Técnicos, Gurus das Linguagens, Administradores de Sistema, Implantadores, entre outros.

23 3 ANÁLISE DAS METODOLOGIAS Após a apresentação das metodologias, bem como um estudo realizado sobre as mesmas, analisando as características de cada uma, como papéis, práticas, valores e ciclo de vida, optou-se por implantar uma metodologia híbrida, na qual juntou o que cada uma das três metodologias tem de melhor para apoiar o desenvolvimento da ferramenta objeto desta monografia. A implantação da metodologia híbrida foi escolhida a fim de possibilitar uma melhor capacidade gerencial dos processos da FDD juntamente com as práticas da Scrum e da Extreme Programming, por se adequar em equipes e projetos pequenos e por ter um ciclo de vida focado no desenvolvimento do modelo do negócio, característica básica da FDD. A fim de justificar tal escolha, detalha-se abaixo, os pontos de maior relevância que foram observados durante o estudo das mesmas. 3.1 REQUISITOS A metodologia Extreme Programming trata os requisitos em forma de histórias coletadas dos usuários pelos Designers de Interação. Estas histórias são escritas pelos usuários, utilizando uma linguagem natural visando especificar as tarefas que o sistema precisa realizar, sempre focando na necessidade do usuário. De acordo com Beck e Flower (2000), as histórias são também utilizadas para a criação de testes de aceitação, que verificam se o requisito (a história) foi corretamente implementado. Tais histórias devem possuir detalhes suficientes para estimar, com baixo risco, quanto tempo levará a implementação. Para cada história, a equipe de desenvolvedores estima inicialmente qual seria o tempo ideal para o desenvolvimento. Conforme citado no livro Extreme Programming Explained: Embrace Change, este tempo é necessário para codificar a história supondo que não existam distrações ou outras tarefas a serem feitas e os desenvolvedores saibam exatamente como codificar o problema. Se o tempo ideal resultante for menor que uma semana, essa história é considerada como um detalhe, e deve ser combinada à outra história de escopo mais amplo. Se o tempo ideal for maior do que três semanas, deve-se analisar a possibilidade de subdividir a história em tarefas mais específicas. A metodologia Scrum trata os requisitos em forma de Backlogs, e são definidos pelo Product Owner, juntamente com o Scrum Master. Após a definição dos backlogs, o Product Owner prioriza quais backlogs deverão compor o Product Backlog que na seqüência do ciclo

24 24 de vida será transformado em Sprint Backlog e que será decomposto pelas equipes de desenvolvimento a fim de realizar tais tarefas. Por ser uma metodologia voltada para gerenciamento de processos de desenvolvimento de software, a Scrum não se pronuncia na forma de como estes requisitos sejam coletados, se em forma de Diagramas de Casos de Uso, Histórias ou outra técnica, bastando sim à priorização e a inserção dos requisitos nos backlogs. A metodologia Feature-Driven Development também não se pronuncia na forma de como os requisitos sejam coletados, mas parte da premissa de que o ciclo de vida só inicia no momento em que os requisitos estiverem bem definidos pelos membros da equipe. Em função do que foi apresentado nesta seção, optou-se por adotar a prática de User Stories da XP como atividade de coleta de requisitos na metodologia híbrida que foi definida, tendo em vista os fatores de simplicidade, agilidade e compreensão que a mesma possui, tanto para o cliente, que as escreve como para os membros do time de desenvolvimento, que as implementa. 3.2 PRÁTICAS E CICLO DE VIDA Na metodologia Extreme Programming, as práticas bem definidas ocasionam a necessidade de uma alta disciplina e espírito colaborativo entre os membros da equipe. A adoção das práticas depende da situação e do contexto em que o projeto está inserido e deve ser adotada em pequenos passos. Cabe ressaltar que, a presença da prática de Programação em Par inviabiliza a implantação da metodologia para equipes com até quatro colaboradores, como foi o caso deste trabalho, tendo em vista a necessidade de se alocar dois profissionais para a realização desta prática (BECK e FLOWER, 2000). Na metodologia Scrum, Ken Schwaber (2004) destaca, no que diz respeito às práticas e o seu ciclo de vida, a possível combinação com outras metodologias de desenvolvimento de software, como a XP, a FDD, entre outras. Ele destaca ainda uma implementação de Scrum existente, chamada de Scrum Solo, onde um desenvolvedor apenas implementa as práticas e o ciclo de vida do Scrum, elaborando os backlogs e monitorando os Sprints através de ferramentas que a metodologia sugere, como gráficos burndown e quadros kanban. Para as práticas de reuniões diárias, cabe ao desenvolvedor reservar um tempo diário para refletir sobre as ações tomadas naquele dia, bem como refletir sobre suas próximas ações. Na metodologia Feature-Driven Development, a descrição dos processos são relativamente curtas e não ultrapassam duas folhas de tamanho A4, devendo ser de fácil assimilação e fornecendo resultados rápidos e satisfatórios, mesmo com equipes inexperientes. Durante o ciclo de vida da FDD, Stephen Palmer (2000) cita algumas práticas que são executadas, visando atingir níveis máximos de qualidade. São elas: Modelagem de Objetos de Domínio que consiste na exploração e explicação do domínio do problema; Desenvolvimento por Feature que consiste no desenvolvimento e acompanhamento do processo através da lista de funcionalidades; Posse individual de Classe que consiste na premissa de que cada classe possui um único desenvolvedor responsável, podendo este desenvolvedor ser responsável por várias outras classes;

25 25 Equipes de Features consiste na formação de pequenas e dinâmicas equipes de desenvolvedores; Inspeções consistem no uso dos melhores métodos conhecidos de detecção de erros; Builds Regulares consiste na garantia de um sistema disponível e demonstrável para o cliente; Gerenciamento de Configuração consiste no acompanhamento do código-fonte, podendo ser utilizado um software para controle de versões; Relatório de Visibilidade de Resultados consiste no acompanhamento através de análises nas informações do software, verificando-se o andamento dos processos de desenvolvimento e com base nestes resultados, gerando um relatório. Em função do que foi apresentado acima, optou-se por adotar as práticas da FDD, juntamente com as práticas gerenciais da Scrum, formando assim, um ciclo de vida composto que será discutido na seção seguinte. Da XP, além da já citada prática de coleta de requisitos por User Stories, utiliza-se apenas mais algumas das suas práticas, tais como a Refatoração, a Codificação de Padrões e o Design Simples. 3.3 PAPÉIS No que cabem aos papéis, as metodologias apresentam funções em comum, como por exemplo, a presença do Gerente de Projeto que é responsável por facilitar a comunicação entre os times de desenvolvimento e o cliente, eliminando possíveis conflitos e entraves que possam ocorrer no decorrer do processo. Na Scrum, o papel do Gerente de Projeto pode-se comparar ao papel do Scrum Master. Na Scrum, não há definição dos papéis da equipe de desenvolvimento, tendo em vista que a metodologia é voltada para a gerência de processo de desenvolvimento de software e não para o desenvolvimento de fato. Portanto, a Scrum não se pronuncia quanto a estes papéis, tratando apenas de equipe em geral. Alguns papéis se sobressaem em comparação entre as metodologias, como por exemplo, a presença de Programadores-Chefes, responsáveis por liderar pequenas equipes de desenvolvimento na FDD e Analistas de Testes, responsáveis por escrever e automatizar testes para as histórias na XP. Além do papel de Gerente de Projeto, FDD e XP possuem ainda alguns papéis em comum, mas com funções diferentes, como os papéis de Arquitetos, que na FDD são responsáveis por facilitar a absorção das regras de negócio pela equipe, e na XP são responsáveis por ajudar os desenvolvedores com a programação pareada, ajudar a equipe na realização de refatoração em larga escala, elaboração de testes completos, bem como ajuda no desenvolvimento de histórias. Programadores, em XP trabalham em par, implementando histórias, refatorando código e automatizando testes de tudo que produzem, enquanto que na FDD os programadores se tornam donos de classes, onde cada programador é responsável por diagramar, implementar, testar e documentar as classes que lhe foram denominadas pelo Programador-Chefe. Nas três metodologias estudadas nesta monografia, todas apresentam o papel do cliente presente, que monitora e opina as atividades feitas pela equipe de desenvolvimento no decorrer do ciclo de vida. A diferença está na atuação dos mesmos. Na Scrum, o cliente é

26 26 representado pelo Product Owner, que define e prioriza juntamente com o Scrum Master os itens do Backlog. Na XP, o cliente é representado pelos usuários do sistema, onde estes ajudam os desenvolvedores a criarem e priorizarem as histórias no decorrer do ciclo de vida, bem como tomam decisões relativas ao domínio do negócio durante o desenvolvimento. Na FDD, o Especialista do Negócio fica responsável por apresentar à equipe do projeto as necessidades para que o software possua valor real para o cliente e fornece um maior detalhamento sobre uma determinada funcionalidade aos desenvolvedores. Tendo em vista que o foco principal da metodologia híbrida definida é a FDD, optouse por adotar os papéis já utilizados pela metodologia ágil Feature-Driven Development.

27 4 DEFINIÇÃO DA METODOLOGIA Conforme os fatores já apresentados e discutidos na seção anterior, optou-se por definir uma metodologia híbrida que englobasse as melhores práticas de cada metodologia estudada, a fim de apoiar o desenvolvimento da ferramenta proposta. A ferramenta se propõe a auxiliar na atividade de gerência de requisitos, controlando a evolução dos mesmos, bem como as mudanças de código ocorridas no desenvolvimento do requisito cadastrado. A ferramenta se propõe ainda a fornecer uma visão gerencial do requisito, provendo informações como prazos estimados e tempo real de conclusão, versionamento do requisito, atribuição de medidas de qualidade e andamento. Provê também uma visão de responsabilidade do Arquiteto, fornecendo informações como as funcionalidades do requisito que já foram implementadas, o gerenciamento e versionamento dos códigos-fonte, bem como ter noções de rastreabilidade visando saber qual participante realizou alguma modificação nos requisitos cadastrados. 4.1 CICLO DE VIDA Conforme relatado em parágrafos anteriores, a metodologia híbrida foi definida através da união das melhores práticas das metodologias Extreme Programming, Scrum e Feature-Driven Development. A Figura 5 representa graficamente o ciclo de vida resultante desta junção. Figura 5 Ciclo de vida da metodologia proposta Adaptado do site

28 28 Como pode ser observado, o ciclo inicia-se com a obtenção dos requisitos. Logo após esta etapa, é projetado um modelo abrangente do domínio do sistema, com base nas histórias coletadas. Com estes artefatos, é gerado também na fase inicial, um Backlog de Produto, no qual contém a lista de funcionalidades do sistema. Neste Backlog, além de listar, as funcionalidades também são estimadas e priorizadas, projetando assim, o ciclo de iterações e os lançamentos futuros da aplicação após a conclusão de cada iteração. Após esta etapa iniciam-se os ciclos de iterações nos quais podem variar de acordo com o esforço que foi estimado para cada história. É também nesta etapa que são realizadas reuniões diárias de no máximo 15 minutos, a fim de verificar o andamento da iteração. Para esta prática, tendo em vista que o projeto foi implementado por uma pessoa apenas, as reuniões diárias foram em forma de pequenas reflexões sobre o que foi produzido naquele dia. Durante o ciclo de iterações, cada funcionalidade selecionada é projetada e implementada individualmente. Estas ações equivalem aos passos 04 e 05 da metodologia Feature-Driven Development, nas quais se detalham por funcionalidade, incrementando o modelo abrangente feito no início do ciclo, projetando diagramas de seqüência a fim de auxiliar na geração de código-fonte e ainda desenvolvem-se por funcionalidade, aonde são escritos os códigos-fonte e realizados os testes para cada funcionalidade. Ao término de cada iteração, é lançado então, um release da aplicação, na qual já se pode colocar em produção o que foi implementado. Nesta etapa, é realizada também uma retrospectiva da iteração passada, visando resolver entraves que ocorreram durante ela para que não ocorra nas próximas, bem como decidir certos rumos e fatores durante o ciclo de desenvolvimento da aplicação. 4.2 COLETA DOS REQUISITOS Para tal atividade, optou-se por adotar a prática da Extreme Programming de elaboração de histórias do usuário, pelo fato de que as mesmas são menores e mais simples se comparado com a elaboração de Diagramas Casos de Uso da UML ou com a descrição formal dos requisitos, e também por serem escritas em uma linguagem natural com o mínimo de detalhamento possível para posterior elaboração de estimativas. O modelo de cartão utilizado segue representado pela Figura 6, e para uma melhor visualização e entendimento das funcionalidades do sistema, os cartões de histórias que foram coletados encontram-se nos anexos desta monografia.

29 29 Figura 6 Cartão de história utilizado O cartão de história é composto, além da identificação do requisito, de uma descrição informal do mesmo, bem como as tarefas que este deve realizar. O cartão apresenta ainda um espaço para descrição de validações (testes de aceitação) nas quais devem ser implementadas para garantir a integridade do requisito. 4.3 PRÁTICAS Como relatado anteriormente, a metodologia une as melhores práticas das três metodologias estudadas. Tais práticas já foram detalhadas na seção 2, cabendo aqui nesta seção apenas enumerar as práticas que foram utilizadas durante o ciclo de vida da metodologia. São elas: Coleta de requisitos em cartões de histórias, Codificação de Padrões e Refatoração, da Extreme Programming; Elaboração de Backlogs, gráficos de Burndown, reuniões pré e pós-iteração e reuniões diárias, da Scrum; Desenvolver um Modelo Abrangente, Construir uma lista de funcionalidades, Planejar por funcionalidade, Detalhar por funcionalidade e Construir por funcionalidade, da Feature-Driven Development. Cabe-se ressaltar ainda, que na etapa Construir por Funcionalidade, foi incluído a prática de Testes Exploratórios, a fim de testar o comportamento final do release ao invés da prática de Testes Unitários, sugeridos pela metodologia FDD, tendo em vista que a prática escolhida se comporta melhor para sistemas com ambiente de trabalho voltados para a web. 4.4 PAPÉIS Os papéis que a metodologia abrange são compostos em sua maioria por papéis oriundos da metodologia Feature-Driven Development, com algumas pequenas modificações.

30 30 Tais papéis já foram detalhados na seção 2, cabendo aqui neste parágrafo apenas enumerar os papéis que foram sugeridos durante o ciclo de vida da metodologia. São eles: Product Owner e Scrum Master, da Scrum; Gerente de desenvolvimento, arquiteto-chefe, programadores-chefe, desenvolvedores, especialistas do domínio do negócio, da FDD. Cabe-se ressaltar ainda, que para projetos maiores, onde haja necessidade, assim como na metodologia FDD, sugerem-se os seguintes papéis: Gerente de versão, guru da linguagem, criador de ferramentas, testadores, implantadores e redator técnico. 4.5 ARTEFATOS Os artefatos gerados durante o ciclo de desenvolvimento são: Backlogs de produto e iterações; Gráficos de Burndown das iterações; Diagramas UML (Classe, Seqüência, etc.); Lista de funcionalidades; Cartões de histórias; Códigos-fonte; Protótipos de sistema. A maneira como serão armazenado estes artefatos será feita de acordo com a equipe que estará implantando esta metodologia, podendo ser armazenados por sistemas, ou armazenados em meio físico, como em papel, por exemplo.

31 5 PROJETO E IMPLEMENTAÇÃO DA FERRAMENTA PROPOSTA Com a metodologia definida, começa-se então o desenvolvimento da ferramenta proposta. A mesma será desenvolvida para ambiente Web, utilizando a linguagem de programação PHP e técnicas de orientação a objetos, sistema gerenciador de banco de dados MySQL e o Subversion, que se trata de um sistema para controle de versão de software. A mesma será projetada e implementada no padrão MVC (Model-View-Controler), no qual separa a lógica de negócio das camadas de acesso a dados e de apresentação, facilitando assim a manutenção e o reuso das classes desenvolvidas. Conforme citado anteriormente, a atividade de coleta de requisitos foi realizada na forma de histórias e coletadas em cartões, que podem ser vistos nos anexos desta monografia. Foram coletados 16 cartões de histórias e desses cartões extraiu-se um modelo de domínio do sistema, conforme mostra a Figura 7. Figura 7 Modelo de domínio do sistema

32 32 O diagrama de classes representa de forma inicial a estrutura básica do sistema, contendo as classes necessárias para comporem o modelo de negócio do sistema. Com base neste modelo, bem como com o auxílio dos cartões coletados, extraiu-se uma lista com as funcionalidades do sistema e o Product Backlog, contendo estimativas coletadas por User Story Points e prioridades para cada história. A partir daí, foram definidas as iterações e quais histórias comporiam tais iterações, como segue: Para a Iteração 01, foram priorizadas as histórias 01 e 02; Para a Iteração 02, foram priorizadas as histórias 03 e 04; Para a Iteração 03, foram priorizadas as histórias 05 e 06; Para a Iteração 04, foram priorizadas as histórias 07, 08 e 09; Para a Iteração 05, foram priorizadas as histórias 10 e 11; Para a Iteração 06, foram priorizadas as histórias 12, 13, 14 e 15; E por fim, para a Iteração 07, foi priorizada a história 16. Também se definiu após esta etapa que as iterações seriam de 05 dias e que ao final de cada iteração, seria lançado uma versão do sistema, com as funcionalidades implementadas até o momento. Ressalta-se ainda que todos os diagramas gerados, bem como as telas de interface com o usuário encontram-se localizadas nos anexos desta monografia, cabendo apenas, nos próximos tópicos, apresentar os mesmos de forma simplificada. 5.1 ITERAÇÃO 01 Conforme apresentado anteriormente, para esta iteração, foram selecionadas as funcionalidades e da Lista de Funcionalidades, que são respectivamente: Usuário deve se logar no sistema e Realizar cadastro de novo usuário. A classe Usuário se relaciona com a classe Papel, de modo a definir para cada usuário, um papel na equipe. Primeiro, com base no modelo de negócio abrangente gerado na etapa anterior, iniciase com a criação do schema de banco de dados, bem como o diagrama ER do mesmo schema, iniciando pela tabela Usuários e Papeis, conforme apresento na Figura 8. Figura 8 Fragmento do Diagrama de Entidade-Relacionamento

33 33 Após, refina-se o modelo abrangente do sistema e geram-se também as respectivas classes para controle e acesso a dados relacionados à classe Usuário, do pacote Model, conforme apresentado pelas Figuras 9 e 10, respectivamente. Vale salientar que no pacote Dao (Data Access Layer), as operações sobre a classe Papel são realizadas diretamente pela classe ParticipanteDao, tendo em vista que a classe Participante, do pacote Model, herda as propriedades da classe Papel, do mesmo pacote. Figura 9 Classes CtrlUsuario e CtrlPapel, do pacote Controller Figura 10 Classe UsuarioDao, do pacote Dao Nesta etapa também, são gerados diagramas de seqüência para cada funcionalidade, nos quais apresentados pelas Figuras 11 e 12, respectivamente. Figura 11 Diagrama de Seqüência 1.1.1

34 34 Figura 12 Diagrama de Seqüência Após esta etapa, então, segue-se para o desenvolvimento das funcionalidades. Primeiro implementando os prólogos das classes geradas pelos diagramas de seqüência. Com as classes necessárias já desenvolvidas, parte-se então para o desenvolvimento das telas de interface com o usuário, sempre seguindo a prática de Design Simples, optando por fazer tudo da maneira mais simples possível. As telas de login e cadastro no sistema são representadas pelas Figuras 13 e 14, respectivamente. Figura 13 Tela de Login no sistema

35 35 Figura 14 Tela de Cadastro de novo usuário no sistema 5.2 ITERAÇÃO 02 Conforme apresentado anteriormente, para esta iteração, foram selecionadas as funcionalidades e da Lista de Funcionalidades, que são respectivamente: Cadastrar novo projeto no sistema e Cadastrar novo requisito no sistema. A classe Projeto se relaciona com as classes Participante e Requisito, da mesma forma que a classe Requisito se relaciona com as classes CodigoFonte, Testes e Tarefas, de modo a definir para cada projeto, seus participantes e para cada requisito, suas tarefas, seus códigos-fonte e seus testes de aceitação. Incrementando o diagrama ER iniciado na iteração 01, adicionam-se as tabelas Participantes, Projeto e Requisito, conforme apresento na Figura 15. Figura 15 Fragmento do diagrama Entidade-Relacionamento

36 36 Após, refina-se o modelo abrangente do sistema e geram-se também as respectivas classes para controle e acesso a dados relacionadas às classes Projeto, Participante e Requisito, do pacote Model, conforme apresentado pelas Figuras 16 e 17, respectivamente. Figura 16 Classes CtrlRequisitos, CtrlProjeto e CtrlParticipante, do pacote Controller Figura 17 Classes ParticipanteDao, RequisitoDao e ProjetoDao, do pacote Dao Nesta etapa também, são gerados diagramas de seqüência para cada funcionalidade, nos quais apresentados pelas Figuras 18 e 19, respectivamente.

37 37 Figura 18 Diagrama de Seqüência Figura 19 Diagrama de Seqüência Após esta etapa, então, segue-se para o desenvolvimento das funcionalidades. Primeiro implementando os prólogos das classes geradas pelos diagramas de seqüência. Com as classes necessárias já desenvolvidas, parte-se então para o desenvolvimento das telas de interface com o usuário, sempre seguindo a prática de Design Simples, optando por fazer tudo da maneira mais simples possível. As telas de cadastro de projetos e requisitos no

38 38 sistema são representadas pelas Figuras 20 e 21, respectivamente. Cabe salientar ainda, que após o cadastramento do requisito, o sistema apresenta ainda mais duas telas, uma para cadastramento de tarefas para o requisito cadastrado e outra para cadastramento de testes de aceitação, também para o requisito cadastrado. Figura 20 Tela de cadastro de projeto Figura 21 Tela de cadastro de requisito 5.3 ITERAÇÃO 03 Conforme apresentado anteriormente, para esta iteração, foram selecionadas as funcionalidades e da Lista de Funcionalidades, que são respectivamente: Cadastrar novo código-fonte no sistema e Pesquisar projetos cadastrados no sistema. Incrementando o diagrama ER iniciado na iteração 01, adiciona-se a tabela CodigoFonte, conforme apresento na Figura 22.