Estudo e Implementação de uma Ferramenta para Gerência de Projetos baseado em Metodologias Ágeis

Estudo e Implementação de uma Ferramenta para Gerência de Projetos baseado em Metodologias Ágeis Rafael Raymundo, Guilherme Lacerda Sistemas de Informação Universidade Ritter dos Reis (UNIRITTER) Rua Orfanotrófio, 555 Alto Teresópolis CEP 90840-440 Porto Alegre RS Brasil {rafael2000, guilhermelacerda} @gmail.com Abstract: In this article were studied agile methods and evaluated tools used for managing these methods. Through this study it was possible to develop a project management system based on agile development practices, integrated into the collaborative system Expresso 1. Thus, all users of that system, who wish to develop Groupware Expresso or some other project will have at its disposal a management module requirements based on agile methods. This suggestion of standardization development will facilitate communication and exchange of information between different teams. Resumo: Nesse artigo foram estudados métodos ágeis e avaliadas ferramentas de gerencia utilizadas por esses métodos. Através desse estudo foi possível desenvolver um sistema de gerência de projetos baseado em práticas de desenvolvimento ágil, integrado ao sistema colaborativo Expresso. Dessa forma, todos os usuários desse sistema, que pretendem desenvolver o Groupware Expresso ou algum outro projeto, terão à sua disposição um módulo de gerência de requisitos baseado em métodos ágeis. Essa sugestão de padronização de desenvolvimento facilitará a comunicação e troca de informações entre diferentes equipes. 1. Introdução O sistema colaborativo Expresso Livre, baseado no egroupware, 2 reúne as funções de correio eletrônico, agenda, catálogo de endereços, messenger, entre outras. O seu desenvolvimento conta com cinco empresas, todas nacionais sendo uma empresa privada. Dentre elas, o SERPRO 3 que possui, em Porto Alegre, uma equipe de nove pessoas para auxiliar no desenvolvimento desse sistema. Percebe-se que esse desenvolvimento ocorre muito rápido e necessita adotar uma metodologia padrão para que tantos desenvolvedores trabalhem em sincronia. Além disso, esse sistema encontrase disponível para análise do código e desenvolvimento (necessita liberação da comunidade expressolivre.org). 1 Expresso: Ferramenta colaborativa baseada em Groupware <www.expressolivre.org> 2 egroupware: Ferramenta alemã colaborativa <www.egroupware.org> 3 SERPRO: Serviço Federal de Processamento de Dados <www.serpro.gov.br>

Portanto muitas pessoas e empresas ainda podem contribuir como desenvolvedores desse projeto. Alguns módulos desse sistema são habilitados para os usuários e outros apenas para desenvolvedores ou administradores. Paralelamente, os desenvolvedores adotaram por padrão a utilização dos softwares Bugzilla 4 e Subversion 5, mas nenhuma ferramenta foi adotada para padronizar a metodologia de desenvolvimento. Para manter o dinamismo e foco em resultados é necessário adotar uma metodologia que seja moldada de acordo com a realidade de cada grupo de desenvolvedores. No livro Scrum XP from the trenches (Kninberg, 2007), Mike Cohn cita em seu prefácio Essas iterações são pensadas para serem curtas e com espaço de tempo definido. Esse livro apresenta a metodologia ágil sem formalidades e de forma prática, como se realmente a equipe estivesse iniciando esse processo, mostrando até como lidar com a resistência dentro e fora do time de desenvolvedores. A idéia de curtas iterações, com a certeza de rápidas mudanças e maleabilidade para o uso da metodologia são conceitos atribuídos ao método Scrum, que se enquadram no modelo de desenvolvimento colaborativo que foi adotado ao Expresso Livre. A seguir, estudaremos os modelos de processos e seus benefícios para o desenvolvimento. Posteriormente veremos os principais processos ágeis, uma comparação entre algumas ferramentas e a necessidade de um módulo de desenvolvimento ágil unido ao projeto Expresso. 2. Modelos de Processos Devido a crescente demanda por sistemas com prazos reduzidos, tem-se a necessidade de alterar a metodologia tradicional de desenvolvimento. É necessário aumentar o enfoque nas pessoas e reduzir a ênfase dada aos processos de desenvolvimento (Manifesto Ágil, 2001). Principalmente em projetos nos quais ocorrem rápidas mudanças com requisitos passíveis de alterações, e curtas datas de entrega do software o desenvolvimento ágil é fundamental. 2.1 Manifesto Ágil A partir da criação do manifesto ágil em 2001, os métodos anteriormente conhecidos por métodos leves, passaram a ser chamados de métodos ágeis. Esse manifesto foi definido por dezessete metodologistas representando os métodos: Scrum (Schwaber e Beedle, 2002), Extreme Programming (XP) (Beck, 1999) entre outros. Posteriormente eles formaram a Agile Software Development Alliance em fevereiro de 2001. O manifesto criado formula em quatro simples declarações um conjunto de princípios de desenvolvimento ágil de software. É importante salientar que essas declarações valorizam mais alguns conceitos e não são excludentes aos demais. Os valores definidos no manifesto ágil são: Indivíduos e interações valem mais que processos e ferramentas: Nesse ponto é importante considerar o valor dado as pessoas e como elas trabalham em conjunto, sendo esse fator mais importante do que qualquer ferramenta ou processo adotado por melhor que esses sejam. 4 Bugzilla: Ferramenta de controle de registro de bugs 5 Subversion: Sistema de versionamento usado por desenvolvedores

Um software funcionando vale mais do que documentação extensa: A documentação é importante e deve ser produzida, mas o foco principal é o software. É necessário determinar bem esse objetivo para não acabar criando diagramas complexos para a documentação do usuário. Essa documentação deve ser um guia de utilização do sistema, dessa forma ela será muito útil, não sendo mais importante que o próprio sistema. A colaboração do cliente vale mais que a negociação de contrato: Na maioria das vezes os clientes não têm a visão geral do projeto que necessitam, e nem tem a obrigação de ter esse modelo completo. Um sistema deve ser desenvolvido em conjunto com o cliente, não necessariamente seguir apenas o contrato, pois nada substitui a comunicação. Caso o sistema seja desenvolvido remotamente em comunidade, ou não tenha a possibilidade de ter um cliente presente, é importante ter uma ferramenta para acompanhamento do desenvolvimento. De qualquer forma o cliente deve ser informado a cada nova característica do sistema. Responder a mudanças vale mais que seguir um plano: Como é difícil ter uma visão geral do sistema antes de ele ser criado, é comum ocorrer alterações e mudanças de planos. Todo o projeto deve iniciar com um plano definido, mas ele deve ser maleável para não se tornar irrelevante permitindo essas alterações. 2.2 Valores Através do manifesto ágil, as metodologias criaram prioridades a serem seguidas. Essas prioridades estão diretamente relacionadas com os indivíduos e iterações, encorajando o enfoque em determinadas áreas sem eliminar outras. Apesar de ter o foco no sistema, modelar também é preciso, no caso de uma modelagem ágil, não é necessário criar todos os artefatos, mas apenas aqueles que fornecem valor ao projeto dependendo das necessidades específicas. O valor é mais do que simplesmente fazer o que o cliente precisa. É fazer quando ele precisa (Shore e Warden, 2008). 2.3 Princípios Para uma melhor compreensão do desenvolvimento ágil, os membros da Aliança Ágil refinaram as filosofias contidas no manifesto em doze princípios aos quais as metodologias devem se adequar. Estes princípios são: Nossa maior prioridade é satisfazer o cliente através de entregas de software de valor em tempo hábil e continuamente. Receber bem as mudanças de requisitos, mesmo que em uma fase mais avançada do desenvolvimento. Processos ágeis aproveitam a mudança para obter vantagens competitivas para o cliente. Entregar software utilizável freqüentemente, de algumas semanas a alguns meses, de preferência com a menor escala de tempo. Equipes de negócios e de desenvolvimento devem trabalhar juntas diariamente durante o projeto.

Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e a ajuda que eles precisam e confie neles para ter o trabalho concluído. O método mais eficiente de levantar informações para uma equipe de desenvolvimento e fazê-las circular é conversa frente a frente. Software funcional é a medida primordial do progresso. Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários deveriam ser aptos a manter um ritmo constante indefinidamente. Atenção contínua à excelência técnica e a um bom projeto aumentam a agilidade. Simplicidade a arte de maximizar a quantidade de trabalho não-realizado é essencial. As melhores arquiteturas, requisitos e projetos surgem de um time autoorganizado. Em intervalos regulares, a equipe deve refletir em como se tornar mais eficaz e então se ajustar e adaptar seu comportamento. 2.4 Processos Ágeis Esses processos fogem do desenvolvimento tradicional, priorizando o desenvolvimento do software. Abaixo serão relacionados os principais processos que utilizam essa técnica. 2.4.1 Programação Extrema - extreme Programming (XP) A programação extrema é uma metodologia ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente (Beck, 1999). Dentre as principais diferenças entre essa metodologia e as demais estão: Feedback constante, abordagem incremental e uma constante comunicação entre as pessoas. O C3, da Chrysler foi o primeiro projeto a utilizar XP. Com isso o projeto ficou pronto em pouco mais de um ano (Highsmith, 2000). Inicialmente as regras de XP eram confundidas por serem entendidas individualmente, mas elas devem ser utilizadas em conjunto, pois não têm sentido se adotadas isoladamente. A prioridade na programação extrema é garantir a satisfação do cliente, além de favorecer o cumprimento das estimativas. Os quatro valores da XP 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. Os doze princípios adotados pela Aliança Ágil, vistos anteriormente no item 1.4, também são adotados pela programação extrema.

2.4.2 Planning Game (Jogo do Planejamento) O planejamento não deve durar mais que duas semanas, e nesse momento todos os envolvidos no projeto devem estar presentes e opinar, com isso eles terão seus papéis definidos dentro do projeto. Também é importante determinar como serão levantados os requisitos e quais as subfases do projeto. No planejamento buscamos atingir cronogramas mais próximos da realidade possível, muitas formas são utilizadas para buscar essas estimativas como média de notas representando a dificuldade de cada demanda, também se utiliza uma técnica de cartas chamada de planning poker 6 criado por James Grenning em 2002, entre outras, mas independente da técnica utilizada ao usar métodos ágeis o acompanhamento da demanda será tão grande que se tornará mais fácil perceber que determinada situação foge da estimativa esperada, com isso tomar medidas para evitar a perda de prazos. É importante assegurar que a equipe esteja sempre trabalhando naquilo que é mais importante para o cliente. Por isso o planejamento se torna fundamental. Por essa razão, temos dois passos chave no planejamento: Plano de Releases (Lançamentos) Nos releases o Cliente apresenta aos desenvolvedores as características desejadas, e os programadores estimam a dificuldade de cada implementação gerando um valor bem definido para o Cliente, com isso ele pode configurar um plano para o projeto (Teles, 2004). Os planos de Lançamentos iniciais são necessariamente imprecisos: nem as prioridades nem as estimativas são verdadeiramente sólidas, e até que o time comece a trabalhar, não saberemos quão rápido ele irá andar. Contudo, mesmo o primeiro plano de lançamentos é preciso o suficiente para a tomada de decisões, e o time XP revisa o plano de lançamentos de tempos em tempos. Plano de Iteração Iterações são períodos de tempo de poucas semanas (em torno de duas) no qual a equipe implementa um conjunto de funcionalidades acordado com o cliente. Durante o Planejamento de Iteração, o Cliente apresenta as características desejadas para as próximas duas semanas (Beck, 2004). Os programadores as transformam em tarefas, e estimam o custo de cada uma. Baseado na quantidade de trabalho realizada na última iteração, o time se escala para o que será realizado nessa iteração. Esses simples passos de planejamento fornecem informação muito boa, e excelente controle de gestão nas mãos do Cliente. A cada par de semanas, o progresso é inteiramente visível. Não existe o "noventa por cento concluídos": ou uma estória de cliente (requisito) foi completada, ou não. Este foco em visibilidade resulta em um pequeno mas interessante paradoxo: de um lado, com tanta visibilidade, o Cliente está em posição de cancelar o projeto se o progresso não é suficiente; por outro lado, o progresso é tão visível, e a capacidade de decidir o que será feito a seguir é tão completa, que os projetos tendem a produzir mais da funcionalidade necessária, com menos pressão e estresse. 6 Planning Poker: É uma prática que auxilia na estimativa da conclusão de tarefas.

2.4.3 Scrum Na gestão de um projeto é fundamental assegurar que a equipe de desenvolvimento esteja sempre trabalhando naquilo que irá gerar maior valor para o cliente. A chave para essa gestão é o equilíbrio entre o cliente e a equipe de desenvolvimento (Shore e Warden, 2008). O Scrum é um processo ágil voltado para as pessoas. Nele as demandas são dispostas para durarem entre 2-4 semanas, caso sejam maiores elas são separadas para não ultrapassar esse período. Como ele é um processo não uma metodologia, pode ser adaptado conforme cada necessidade. Essas iterações de 4 semanas são chamadas de sprints e tem suas datas de entrega definidas sem a possibilidade de mudança. É possível alterar apenas o número de requisitos do projeto. Além disso, são realizadas reuniões diárias de no máximo quinze minutos para que cada membro da equipe possa elencar suas tarefas e dificuldades. As tarefas de cada sprint podem ser dispostas em um quadro para que toda a equipe possa ter acesso tendo conhecimento de suas tarefas, é usual se utilizar o quadro de kanban. É fundamental a entrega incremental do software para o cliente, dessa forma ele pode começar a utilizar o sistema e obter benefícios a cada nova entrega, isso serve de incentivo para dar prosseguimento ao projeto. Segue um ciclo de iterações do processo Scrum: Figura 1 - Ciclo de processo do Scrum (COHN, 2005) Na figura 1 temos um modelo de ciclo Scrum, com a entrada das demandas do cliente (Product Backlog) e posteriormente dividido pelos desenvolvedores e chamado de Sprint Backlog. No centro da figura temos uma representação das iterações diárias, gerando o Sprint mensal, ao final desse ciclo temos novas características do produto potencialmente funcionais ao cliente. Durante toda a iteração temos constantemente a participação do cliente, inclusive nas reuniões e modificações do sistema, com isso todas as dificuldades são acompanhadas e alterações no projeto têm a participação do cliente, sem a necessidade de posterior retrabalho.

2.5 Planejamento e Metodologias Ágeis No XP, a definição de requisitos é feita a partir da escrita das user stories 7 pelos clientes. No Scrum, os requisitos conhecidos até o momento são listados dando origem ao Product Backlog(Schwaber e Beedle, 2002). De acordo com as suas prioridades, esses requisitos são agrupados e são agregadas as informações de tempo, responsável e sua descrição gerando tarefas para cada desenvolvedor. Com o planejamento das tarefas a serem realizadas em determinado período do projeto, elencamos os itens a serem desenvolvidos e podemos utilizar algum gráfico para um melhor acompanhamento das tarefas. Usando uma metodologia ágil, esse gráfico pode ser acompanhado diariamente e comparado com a estimativa esperada, um método muito usado é o gráfico de burndown 8. Nesse gráfico, (figura 2) caso a curva verde esteja muito acima do estimado pela reta preta é necessário remover alguns requisitos planejados, caso contrário adicionar itens. O ideal é ter o desenvolvimento, representado em verde, o mais próximo possível da reta preta que é o planejado anteriormente. Figura 2 - Gráfico de burndown No gráfico de burndown (figura 2), representando uma iteração de dez dias, é possível perceber que a equipe de desenvolvimento esteve constantemente com prazos atrasados durante todo o processo, isso é apresentado com o gráfico verde acima da reta preta. Essa reta corresponde ao tempo previsto para a conclusão das demandas. Apesar de o desenvolvimento ter ocorrido sempre com prazos brevemente atrasados, o seu término ocorreu como o previsto. 2.6 Projeto ExpressoLivre O projeto ExpressoLivre é atualmente composto por uma comunidade de cinco empresas que contribuem para o desenvolvimento em distintas atividades. Cada 7 User Stories: Breves descrições a respeito das funcionalidades do sistema (Beck, 2000) 8 Burndown: Forma visual e rápida de enxergar o status atual do projeto.

empresa possui um responsável que tem acesso para corrigir problemas no trunk 9 com o código do ExpressoLivre, dessa forma, todas as empresas tem acesso as correções e podem distribuir melhorias que tenha feito. Tudo isso com um prévio cadastro no track 10 da comunidade, essa ferramenta é usada para documentação e controle do que está sendo feito, por quem e quando a atividade é concluída, seu status é alterado para fechada. Além de promover a troca de correções e novas implementações, a comunidade realiza duas reuniões presenciais para definir os novos rumos do projeto. Uma delas ocorre no Fisl(Fórum Internacional de Software Livre em Porto Alegre) e o outro encontro é realizado no Latinoware(Fórum Latino Americano de Software Livre em Foz do Iguaçu). Nesses encontros, são realizadas reuniões que antecedem os fóruns e elencam novos rumos para melhorar o software. Apesar das distintas necessidades das cinco empresas, foi possível moldar a ferramenta para atender a todas as necessidades. As características muito específicas são implementadas de forma configurável. Atualmente as empresas estão unificando suas funcionalidades ao código principal do ExpressoLivre para ter uma única versão, gerando assim mais força de trabalho ao desenvolvimento da ferramenta, pois todos terão um único foco. No caso de integrar um novo módulo para gerência ágil do desenvolvimento, é necessário conhecer os Softwares Utilizados e o Modelo Atual de Desenvolvimento. 2.6.1 Softwares Utilizados Para o desenvolvimento do ExpressoLivre utilizamos uma série de ferramentas em paralelo. Todas as empresas trabalham com software da comunidade e outros internos. No caso do SERPRO, temos internamente o sistema Bugzilla para controle de versões, nele geramos padrões para criação, testes e fechamento de cada bug. Utilizamos o sistema Subversion para ter versões estáveis dos tipos: trunk, tag ou branch. Essas ferramentas são usadas da forma mais integrada possível através de padrões criados pela equipe. Para o desenvolvimento usamos NetBeans/Eclipse, juntamente com software de debug chamado Xdebug. Na comunidade temos o Fórum para tirar dúvidas dos usuários, um Wiki para que seja postada toda documentação, um track para o cadastro de bugs e novas funcionalidades e o repositório do Subversion. Dessa forma, as empresas criam internamente suas soluções e posteriormente repassam para o código na comunidade, onde todos podem ter acesso. 2.6.2 Modelo de Desenvolvimento Na equipe do SERPRO de desenvolvimento do projeto ExpressoLivre, foi adotada a metodologia ágil Scrum, pelo fato de realizarmos diversas modificações no processo para atender determinadas especificidades. Vimos à importância de ter uma metodologia que auxiliasse no processo de desenvolvimento, mas que pudesse ser maleável, se adaptando a nossa realidade. Criamos um quadro de kanban e elencamos 9 Trunk: Repositório de arquivos versionados do Subversion 10 Track: Sistema de cadastro de funcionalidades e bugs <http://trac.expressolivre.org>

os atores para gerencia do processo, efetuado curtas reuniões diárias para apresentar o andamento das tarefas. Através do uso do método ágil Scrum, teve-se uma visível melhora no controle das tarefas e solução de bugs, isso foi constatado nos relatórios de atividades observados pelo Scrum Master 11. O andamento das atividades ficou mais claro para todos os membros da equipe e isso tornou mais fácil o auxílio nas dificuldades individuais. 3. Estado da Arte Foram analisadas quatro ferramentas para controle do desenvolvimento ágil. Todas elas podem ser acessadas através de um navegador, possibilitando que múltiplas equipes de desenvolvimento trabalhem em sincronia. 3.1 AgileFant 12 AgileFant é uma ferramenta livre para o gerenciamento e desenvolvimento ágil de software. Ela foi desenvolvida por Software Business and Engineering Institute (SoberIT) da Universidade de Tecnologia de Helsínquia 13. Desenvolvida com a linguagem Java, seu uso é livre através da licença MIT, e através de um navegador podemos ter acesso as facilidades da ferramenta. Na área administrativa é possível habilitar características ainda experimentais da ferramenta. AgileFant ainda possui quatro grandes áreas para navegação: Timesheets: Registro resumido de todas as atividades realizadas por determinado usuário em um período. As atividades são totalmente relacionadas ao backlog. Portifólio de Desenvolvimento: É uma lista de trabalhos a serem desenvolvidas, contendo os responsáveis e o andamento de cada atividade.essa estrutura também tem ligação com o backlog. Backlog: Lista de requisitos, que o cliente deseja, descritas sucintamente, utilizando a terminologia do cliente. Nessa ferramenta foi integrado ao Backlog o gráfico de burndown, citado na figura 2 desse trabalho. Trabalhos do dia (figura 3): Sua primeira aba apresentada uma tabela com as estimativas para o dia e semana, com isso os desenvolvedores podem acompanhar suas atividades. 11 Scrum Master: Não é o líder da equipe, mas atua como mediador entre a equipe e qualquer influência desestabilizadora. 12 AgileFant: Ferramenta para desenvolvimento ágil <http://www.agilefant.org/> 13 Universidade de Tecnologia de Helsínquia: Universidade Técnica Finlandesa <http://www.tkk.fi/fi/>

Figura 3: AgileFant apresentando os Trabalhos do Dia 3.2 IceScrum 14 É uma ferramenta livre bem completa com funcionalidades como Backlog, planejamento de release, funcionalidades para todos os papéis do Scrum, auxílio ao planning poker, gráficos diversos. A ferramenta foi desenvolvida em Java e JSP com a licença GPL. Ela possui uma interface muito amigável aos usuários com inúmeras opções, inclusive foi adicionado um chat para que os desenvolvedores possam trocar idéias no próprio ambiente. O grupo de desenvolvedores contou com a entrada de quadro programadores da Universidade de Toulouse (França). Figura 4: Tarefas geradas no IceScrum Atualmente o IceScrum está na versão 2 e tem plena atividade de desenvolvimento com uma comunidade bem ativa, isso é importante para o crescimento de um projeto tão bem elaborado. Seu site possui inúmeras sugestões e uma interface prática, assim como a ferramenta, apresentada na figura 4. 14 IceScrum: Ferramenta para o desenvolvimento ágil <http://www.icescrum.org/>

3.3 GreenAgile 15 Ferramenta desenvolvida em RubyOnRails e Javascript. Figura 5: Tela de abertura após instalação do sistela GreenAgile Ela está no início de seu desenvolvimento, portanto muitas funcionalidades ainda precisam ser aperfeiçoadas. No próprio site que se encontra o código da ferramenta é possível ler discuções relativas ao desenvolvimento e andamento do projeto, que demonstra muita integração com Ruby 16 (figura 5). Em junho desse ano foi lançada sua primeira versão com um quadro de kanban. Essa versão está sendo aprimorada e estão sendo discutidos alguns fatores relativos a sprints, backlogs e limites para o quadro de kanban. 3.4 Pronto 17 Pronto é um sistema de controle de tarefas baseado no método ágil Scrum, utilizando licença GPL. Desenvolvido sobre a plataforma Java, banco de dados PostgreSQL. Ao acessar o sistema é possível visualizar quatro importantes opções: backlogs, sprint, kanban e burndown. A ferramenta Pronto não possui uma vasta série de funcionalidades como o IceScrum, mas as funções presentes se mostraram muito bem estruturadas. Figura 6: Quadro de kanban do software Pronto No quadro de kanban, apresentado na figura 6, é possível arrastar as tarefas entre as colunas, interagindo como o quadro real feito com post-its. O gráfico de burndown foi 15 GreenAgile: Ferramenta para desenvolvimento ágil <http://github.com/dwildt/greenagile> 16 Ruby: Linguagem de programação orientada a objetos <http://ruby-lang.org> 17 Pronto: Software brasileiro para desenvolvimento ágil Scrum <http://pronto.bluesoft.com.br/>

desenvolvido em flash contendo marcações diárias referentes ao andamento do projeto e possui um histórico de todos os sprints realizados, esse histórico possui integração com todas as demais opções da ferramenta, ao selecionar um sprint, a ferramenta apresenta em todas as suas opções dados relativos a esse sprint. A ferramenta possui apoio das empresas bluesoft e uplexis, além de quatro desenvolvedores ativos. 3.5 Quadro Comparativo entre as Ferramentas Estudadas AgileFant IceScrum Pronto GreenAgile Versão atual 1.6.2 2 R14.2 0.9 0.1 (versão expert) Licença MIT GPL GPL GPL Linguagem Desenvolvida Possui Guia de Instalação Demonstração no site Facilidade Uso Comunidade Ativa de Integração com outra ferramenta Múltiplos projetos Prós Contras Java Java e JSP Java e Flash Ruby e Javascript Possuem fórum site e blog Subversion Ferramenta leve de uso intuitivo Não possui quadro de kanban Possuem fórum site e blog Ferramenta com inúmeras opções e ótimo layout Muitas opções atrapalham muitas vezes seu uso Em vídeo Apenas site e blog Ferramenta simples, intuitiva e com bom quadro de kanban Múltiplos projetos e comunidade não muito participante Precisa ser aprimorado Site em Desenvolvimento Ferramenta leve desenvolvida de forma bem colaborativa Está em início de desenvolvimento. Esse quadro comparativo foi elaborado após a instalação de todas as ferramentas. Muitas dessas características foram obtidas com suas especificações técnicas, apenas o

item facilidade de uso que foi definido utilizando os dez princípios da heurística e usabilidade, definidos por Jakob Nielsen 18. 4. Solução Implementada Através desses conceitos, foi implementado um módulo integrado a ferramenta Expresso, com instalação via setup da aplicação, respeitando a estrutura padrão e os recursos da API do Groupware. Esse módulo foi desenvolvido com total independência das demais funcionalidades, podendo ser instalado nas mais variadas versões da aplicação. Sua utilização é suportada nos navegadores Firefox 3.x, IE 6, 7 e 8 além do navegador Chrome 7.x. Foram utilizadas tecnologias para facilitar a interação com o módulo, tornando transparente a gerência de projetos pelas equipes de desenvolvimento e padronizando o controle e acompanhamento das atividades. A solução consiste em realizar quatro etapas para a gerência de um produto: Cadastro de um novo projeto, inserindo os participantes Criação de todas as tarefas planejadas para a execução desse projeto Criação e execução de curtas interações, chamadas de sprints, que serão blocos das tarefas cadastradas Uso do quadro de kanban com atualização constante das atividades pelos desenvolvedores. 5. Problema O desenvolvimento da ferramenta Expresso conta com cinco equipes trabalhando constantemente em seu código, além de outros desenvolvedores da comunidade, realizando melhorias, correções e novas implementações. Esse desenvolvimento não possui um padrão para Engenharia ou Gerência. Sem esse controle, por vezes as rápidas mudanças necessárias para o projeto se tornam extremamente custosas para as equipes. Sendo que as características aqui apresentadas da ferramenta Expresso se enquadram perfeitamente no modelo ágil de gerência. Além disso, os desenvolvedores que utilizam métodos ágeis não detêm um histórico de suas atividades, adotando práticas isoladas nas suas equipes. Para solucionar isso, foi desenvolvido um módulo para suprir a necessidade de padronização do modelo de gestão de projetos, facilitar a gerência entre equipes distribuídas permitindo a troca de experiências entre diferentes projetos e equipes. Essa padronização não se resume ao desenvolvimento do projeto Expresso Livre, mas se estende a qualquer projeto que vier a utilizar essa ferramenta, portanto trata-se de um módulo multi projetos e multi tarefas. 18 Jakob Nielsen: Cientista alemão da computação com Phd em interação homem-máquina. - <http://www.useit.com/jakob/>

6. Implementação Além de desenvolver uma ferramenta desde seu estágio inicial, foi necessário seguir todos os padrões já existentes no Groupware Expresso, o que dificultou muito o processo de desenvolvimento, pois inclusive a comunicação entre o banco de dados é realizada de forma diferenciada. Para seguir esses padrões foi utilizada a API que provê manuseio de sessão, usuários e grupos, múltiplas bases de dados e um padrão para a interface. A estrutura do Expresso está definida com diversos subdiretórios a partir de um diretório principal (raíz /expresso), que representam cada módulo do sistema. Por exemplo, o módulo de email está no diretório /expresso/expressomail, dessa forma o módulo de projetos ágeis foi criado em /expresso/agileprojects. 6.1 Estrutura de banco de dados Para o banco de dados, foram criadas quatro tabelas de acordo com o padrão estabelecido pelo Groupware, veja a figura seguinte. Esse padrão determina o nome das tabelas e um incremento através de uma sequence quando necessário. Figura 7: Estrutura das quatro tabelas criadas Foi criada uma tabela para compor os projetos criados, uma para as tarefas desses projetos e outra para os sprints, além disso, foi criada uma tabela para interações usuário/projeto. Além dos nomes dessas tabelas terem seguido um padrão, os seus atributos também mantêm uma padronização de acordo com o nome de cada uma das tabelas. Um exemplo do uso das tabelas é no quadro de kanban, onde cada interação realiza uma operação em Ajax para atualizar o posicionamento da tarefa correspondente na tabela phpgw_agile_tasks. 6.2 Tecnologias utilizadas A principal linguagem da ferramenta é PHP, tendo em vista que todo o Groupware segue esse padrão. Para uma maior integração com o Expresso, foram feitas buscas LDAP para inserir participantes, buscando diretamente da base do Expresso. Além disso, todas as iterações do módulo foram realizadas de forma assíncrona, otimizando o processamento da página. Para a modelagem assíncrona, foi utilizado o framework

Jquery 19 que facilitou a implementação da funcionalidade em abas e movimentação dos post-its no quadro de kanban. 6.3 Estrutura da ferramenta Além de adotar um padrão na estrutura de banco de dados, foi necessário seguir a estrutura de comunicação dentro da aplicação. A requisição dos dados é realizada através dos arquivos index.php de cada módulo, esses arquivos são encarregados de tratar as requisições com os arquivos de interface, classes de negócios e objetos de armazenamento, quando necessário. Figura 8: Estrutura da ferramenta Expresso É possível visualizar essa estrutura através da figura acima, com a requisição sendo feita na parte superior da figura e tendo a resposta através de um template. Perceba que essa estrutura permite que o banco de dados seja acessado apenas pelas classes SO, inviabilizando o acesso direto as informações do banco pelos usuários. 7. Utilização do módulo Para utilizar a ferramenta é necessário que o grupo do usuário logado no sistema tenha permissões para acesso ao módulo. Essas regras são estabelecidas pelo administrador do Groupware. Dessa forma o administrador pode liberar o acesso apenas para as equipes de desenvolvimento. 7.1 Criando um projeto Ao acessar a ferramenta, a primeira tela apresentada consiste em uma listagem de projetos caso tenha sido cadastrados, do contrário apenas será apresentada a opção de 19 Jquery: Framework para o desenvolvimento assíncrono - <http://jquery.com>

cadastro de novos projetos. Nessa área é possível realizar ações com os projetos cadastrados de acordo com as permissões do usuário logado no Expresso. O dono de um projeto pode realizar todas as ações: Executar, Editar e Excluir. Aos demais usuário é apenas permitida a ação de Executar o projeto. Com essa ação serão apresentadas nas demais abas, todas as tarefas do projeto e seu andamento. O usuário que realizar o cadastro de um novo projeto, será o dono dele. Para realizar esse cadastro, é necessário informar um título para o projeto, sua descrição e seus participantes. Figura 9: Criação de um novo projeto A inclusão de um projeto consiste em inserir dados nas tabelas da aplicação. Os usuários participantes do projeto são pesquisados na base Ldap e inseridos seus códigos de identificação (uidnumber). Dessa forma, caso tenham alterações de nome ou email através da aplicação, essas alterações serão replicadas automaticamente para o os projetos em que esses usuários estejam cadastrados. 7.2 Inserindo tarefas Antes de inserir novas tarefas, é necessário executar um projeto na aba inicial do módulo, dessa forma, todas as tarefas criadas farão referência ao projeto selecionado.

Figura 10: Inclusão de uma nova tarefa ao projeto selecionado É importante lembrar que devem ser criadas todas as tarefas desejadas para esse produto, pois elas serão executadas em pequenos blocos. Ao criar uma tarefa (Figura 9), é possível selecionar o sprint desejado para a mesma, o responsável pela tarefa e uma indicação de urgente, caso necessário. Também é importante definir uma clara descrição para a tarefa criada e uma estimativa em pontos definida pela equipe. A finalização de um projeto consiste em executar, em blocos, todas as tarefas cadastradas para o mesmo. 7.3 Executando um sprint Os sprints são pequenos conjuntos de tarefas. É importante que essas iterações sejam curtas (30 dias) para evitar retrabalhos pela equipe em imprevistos ou mudanças no projeto. Essas mudanças devem ser esperadas em todo o projeto e tratadas da mesma forma que uma nova tarefa. É fundamental registrar uma retrospectiva de cada sprint após o seu término, com isso será mantido um histórico de todas as dificuldades encontradas e melhorias aplicadas ao processo. 7.4 Kanban Kanban é uma palavra japonesa que significa placa visível, e é exatamente o que se propõe esse kanban virtual, se tornar visível para todos os envolvidos no projeto, mesmo que estejam distantes ou desenvolvendo em diferentes turnos. Basta acessar o Expresso e selecionar um projeto para visualizar o sprint que está sendo executado no momento por determinada equipe de desenvolvedores. Para interagir com o quadro de kanban é necessário executar um sprint, mas caso esse já tenha sido executado, ele permanecerá dessa forma até a conclusão do sprint e alteração para o próximo bloco de iterações. Com o sprint backlog selecionado, todas as tarefas contempladas nessa pequena interação serão apresentadas no kanban. Cada tarefa é representada por um post-it que possui algumas informações importantes: responsável, urgência, título, descrição e estimativa em pontos.

Figura 11: Andamento de um sprint, representado por um quadro de Kanban A urgência é representada por um marcador, como pode ser visto na figura acima, verde como padrão ou vermelho caso a tarefa seja urgente, dessa forma as tarefas urgentes são facilmente visualizadas no quadro, sem a necessidade de leitura. A descrição de cada atividade é por padrão suprimida, liberando maior espaço em cada uma das colunas do quadro, para que mais atividades sejam inseridas no sprint. Essa descrição pode ser expandida selecionando o botão ao lado do título da tarefa, isso não impede o posterior movimento da atividade. A estimativa é definida em pontos, cada equipe é responsável por determinar um padrão para a dificuldade de suas tarefas. Quando uma dessas tarefas evolui, o desenvolvedor move a demanda para a próxima coluna do kanban. Dessa forma, todos os demais envolvidos no processo podem tomar conhecimento de como está o andamento das demandas, apenas visualizando o posicionamento delas no quadro. 8. Benefícios e dificuldades Uma grande dificuldade enfrentada nas organizações é apresentar uma mudança para o fluxo de trabalho e essa ser aceita pelo grupo. Apesar de ser necessário ter uma gerência de projetos bem definida, ter o apoio de todas as empresas envolvidas no processo é algo extremamente custoso. Essa incerteza, se todos iriam abraçar a idéia ou apenas descartar, foi tida desde o início do desenvolvimento. Foi necessário utilizar tecnologias que não apenas cumprissem o papel de gerenciar os projetos, mas que fossem transparentes e inovadoras para os desenvolvedores. Dessa forma foram estudadas tecnologias de desenvolvimento assíncrono para a Web, juntamente como o framework Jquery, que possibilitou uma iteração de forma instantânea no quadro de kanban e uma otimização da ferramenta, pois cada ação é realizada apenas para o elemento necessário ao invés de remodelar todos os elementos da página. Como benefícios, teremos uma padronização e maior controle das demandas. A utilização de métricas e ferramentas para a gerência possibilitará um total conhecimento

das equipes de desenvolvimento. Dessa forma os gestores dos projetos terão informações para realizar planejamentos mais precisos e melhorias nas atividades. Além disso, a gerência distribuída facilitará a comunicação entre desenvolvedores e melhor distribuição de tarefas. 9. Considerações finais Após o desenvolvimento do novo módulo, foi fundamental apresentar para as cinco empresas que representam o Comitê Gestor do Expresso todos os benefícios oferecidos pela ferramenta. Essa oportunidade foi conquistada na 7 a Conferência Latino Americana de Software Livre, em Foz do Iguaçu. Essa conferência promoveu a segunda edição do concurso de melhor funcionalidade para o Expresso, sendo que a ferramenta aprovada teria que passar pela aceitação das cinco empresas. Dessa forma foi possível encaminhar o módulo de projetos ágeis, tornando uma ferramenta conhecida por toda a comunidade, participar de um evento internacional e ter a honra de ganhar o prêmio de melhor software livre desenvolvido para o Groupware Expresso Livre. Além de ter sido premiado em uma conferência internacional, a ferramenta foi apresentada no AgileDay, evento que promove a colaboração e comunicação entre os participantes da comunidade ágil. Essas apresentações geraram repercussões na mídia e muitos emails de desenvolvedores ansiosos pelo uso da ferramenta, mas ainda é necessário realizar pequenos ajustes, melhorias e testes de segurança. Todo o desenvolvimento da ferramenta foi realizado em um repositório separado da comunidade, com o sistema de controle de versões subversion. Com a aprovação do Comitê Gestor, todas as documentações e códigos da ferramenta serão migrados para o repositório do Expresso, na área de contribuições. Juntamente com o Groupware, será mais fácil concluir o desenvolvimento e realizar melhorias à ferramenta, trabalhando agora em comunidade. Como produto do presente estudo obtém-se o desenvolvimento de uma ferramenta de gerência de projetos ágeis, integrada ao Groupware Expresso Livre. Atualmente é possível acessar o código e toda a documentação da ferramenta em: <http://code.google.com/p/expressoalpha/>. Essa ferramenta permitirá padronizar e ampliar a qualidade do sistema, possibilitando a especificação de métricas de acompanhamento. Além disso, será possível ter um maior conhecimento das equipes envolvidas no processo de desenvolvimento do Expresso e outros projetos que utilizarem a ferramenta. A partir do conhecimento das variáveis do processo de desenvolvimento será possível estabelecer estratégias de melhoria, indicando adequações aos procedimentos de gerência distribuída.

Referências AGILEFANT Ferramenta para desenvolvimento ágil <http://www.agilefant.org/> AMBLER, Scott - Modelagem Ágil: Práticas eficazes para a Programação Extrema e o Processo Unificado, 2004. 352p. BORGONOVO, Ana Marta; SILVA, Roberta Santos da. - Aplicação de Metodologia Ágil em Grandes Empresas com Pequenos Grupos de TI. Florianópolis: artigo, 2007. 2p. BECK, K. - Agile Manifesto. 2001. Disponível em: <http://www.agilemanifesto.org>. Acesso em: 10/10/2009 BECK, K. Embracing Change with Extreme Programming. 1999. <http://www.cs.umd.edu/class/spring2003/cmsc838p/process/extreme.pdf>. Acesso em 10/10/2009 COHN, Mike Modelos de gerência de projetos utilizando Scrum <http://www.mountaingoatsoftware.com/scrum/figures >. Acesso em: 20/10/2010. CORDEIRO, Lucas Metodologia Ágil Scrum: O Caso XMPM. Manaus: apresentação, 2006. 31p. FAGUNDES, Priscila B., DETERS Janice e SANTOS, Sandro da S. dos Comparação entre os Processos dos Métodos Ágeis: XP, Scrum, FDD e ADS em Relação ao Desenvolvimento Iterativo Incremental, 2008. 46p. GREENAGILE Ferramenta para o desenvolvimento ágil <http://github.com/dwildt/greenagile> HIGHSMITH, J. Orr, K. Cock burn, A. Extreme Programming. E-Business Application Delivery, Feb., p. 4-17, 2000. ICESCRUM Ferramenta para o desenvolvimento ágil http://www.icescrum.org/ NIELSEN, Jacob, LORANGER Hoa - Prioritizing Web Usability, 2006. 406p. KNINBERG, Henrik - Scrum Xp From The Trenches, InfoQ, 2007. 145p. PACHECO, Diego FDD, Um Método Ágil e Eficiente, 2009. Disponível em <http://diego-pacheco.blogspot.com/2009/06/fdd-um-metodo-agil-e-eficiente.html>. Acesso em: 13/10/2009 PRESSMAN, Roger S. - Engenharia de Software. 6. ed. McGraw-Hill, 2006. 720p. PRONTO Ferramenta para o desenvolvimento ágil <http://pronto.bluesoft.com.br/> SHORE Jim e WARDEN Shane - A Arte do Desenvolvimento Ágil, Alta Books, 2008. 430p. SCHWABER, Ken e BEEDLE, Mike Agile Software Development with Scrum, Prentice Hall, 2002. 158p. TELES, Vinícius Manhães Extreme Programming, Novatec Editora, 2004, 316p. Site da Comunidade Expresso Livre. Disponível em http://www.expressolivre.org/ Acesso em: 9 de dezembro de 2009.