ANÁLISE DO APOIO TECNOLÓGICO AO GERENCIAMENTO DE … · Este artigo estabelece uma visão...

209

Diálogo Canoas n. 14 jan-jun 2009

ANÁLISE DO APOIO TECNOLÓGICO AOGERENCIAMENTO DE PROJETOS QUE UTILIZAM

ABORDAGENS ÁGEIS

Reinaldo SchulzeAbraham Lincoln Rabelo de Sousa

ResumoEste artigo estabelece uma visão preliminar sobre

o estado da arte relacionado à adaptação de ferramentas deapoio ao Gerenciamento de Projetos Ágeis, e tem comoobjetivos, a criação de um processo de avaliação das ferra-mentas aplicado a vários cenários que constituem as neces-sidades de gerenciamento. Com isso, é possível obter o de-sempenho das ferramentas separadamente em grupos defuncionalidades, identificando os pontos fortes e tambémas lacunas que determinada ferramenta possui.

Palavras-chaveMetodologias ágeis, gerenciamento de projetos de

desenvolvimento de software.Abstract

This article looks forward on establishing apreliminary overview on the state of the art for adoptionof agile project management support tools and as objectives,the creation of an evaluation process of the tools appliedto some scenarios that configure the needs for management.Based on that, is possible to get a separately performanceof the tools in each feature groups, and identify the strengthsas well as the gaps that some specific tool have.

p. 209 - 230

210


KeywordsAgile Methodologies, software development project

management.

1 INTRODUÇÃOOs projetos com abordagens ágeis trazem uma mudança de paradigma

na questão do gerenciamento em comparação com projetos com abordagenstradicionais. Enquanto em projetos com abordagens tradicionais a gerência focao planejamento das atividades, em projetos com abordagens ágeis o foco está naexecução. Isso se deve pelo intenso interesse na aceleração do desenvolvimentodo projeto e em entregas rápidas ao cliente final.

Nas metodologias ágeis, o gerente não cria estimativas, cronogramas, issoé feito por toda a equipe. O gerente usualmente não diz o que cada membro daequipe deve fazer. E também não determina detalhados papéis e responsabilida-des para cada recurso do projeto (LARMAN,2003). Algumas das principais res-ponsabilidades do gerente de projetos ágeis são, permitir que o time seja auto-gerenciável, garantir e orientar o time a seguir corretamente as práticas, removerqualquer impedimento que o time encontre e facilitar as reuniões de projeto(AUGUSTINE e WOODCOCK, 2003).

Atualmente existem diversas ferramentas específicas para gerenciamentode projetos ágeis e, baseado no referencial teórico de algumas metodologias ágeisde desenvolvimento estudadas, é feita uma avaliação em algumas ferramentas, como intuito de verificar se estas são eficientes no apoio às tarefas de gerenciamento.

Este artigo apresenta uma avaliação da qualidade do apoio tecnológicooferecido por ferramentas, isto é, funcionalidades, qualidade, velocidade, usabili-dade, e o valor adicionado para as atividades de gerenciamento de projetos ágeis.

p. 209 - 230

211


2 METODOLOGIAS ÁGEISAs metodologias ágeis de desenvolvimento de software surgiram no final

da década de 1990 visando a solucionar o grave problema de prazos não cumpri-dos e orçamentos extrapolados das empresas que adotavam os métodos tradici-onais de desenvolvimento de software (MAGALHÃES, ROUILLER e VASCON-CELOS, 2005).

Metodologias ágeis, como Extremme Programming (XP), Scrum e Feature-Driven-Development (FDD) esforçam-se para reduzir custos em todas as partes doprocesso de desenvolvimento de software.

Uma das grandes diferenças entre os métodos de desenvolvimento tradi-cionais (por exemplo, Modelo Cascata e Modelo Incremental) e as metodologiaságeis é de que as metodologias ágeis são menos orientadas a documentos e maisadaptativas do que previsíveis.

Além disso, métodos tradicionais promovem um grande planejamentoou prevêem um grande número de atividades de desenvolvimento em um nívelde detalhe alto por um longo período de tempo, algo que funciona relativamentebem até que alguma mudança nos requisitos venha a ocorrer.

No esforço de responder à mudança constante de requisitos, as metodo-logias ágeis utilizam desenvolvimento iterativo para incorporar, ou adaptar ofeedback do cliente no ciclo de desenvolvimento, caracterizando o modelo entãocomo adaptativo.

A tabela 1 visa a estabelecer um comparativo dentre as principais aborda-gens ágeis de desenvolvimento, identificando suas principais características quantoà alocação de tempo, artefatos produzidos, atividades realizadas e papéis identifi-cados.

p. 209 - 230

212


Tabela 1: Características entre Processos Ágeis de Desenvolvimento

3 GERENCIAMENTO DE PROJETOSOs objetivos do Gerenciamento de Projetos de software são de fixar e

conhecer compromissos alcançáveis com relação a custos, cronograma, qualida-de e escopo entregue – como esses se aplicam ao desenvolvimento individual oumanutenção de projetos (FLORAC, PARK e CARLETON, 1997).

A teoria tradicional de gerenciamento de projetos recebeu maior atençãono início da década de 90, com publicações baseadas em áreas de conhecimentoextremamente detalhadas, sendo que a mais difundida é a proposta pelo ProjectManagement Institute (PMI), chamado PMBOK.

Mais recentemente, em meados de 2002, elaborado por profissionais daárea de desenvolvimento de software em busca de melhores desempenhos emseus projetos, surge o Gerenciamento Ágil de Projetos (Agile Project Management).

p. 209 - 230

213


O Gerenciamento Ágil de projetos visa a quebrar alguns conceitos dogerenciamento tradicional, trazendo uma nova abordagem, que quebra a visãodo forte planejamento prévio de atividades (CHIN, 2004).

A base do gerenciamento ágil de projetos consiste em cinco objetivosprincipais, são eles (HIGHSMITH, 2004):

• Inovação Contínua – Entrega de produtos que atendam os requisi-tos atuais do cliente;

• Adaptabilidade do Produto – Entrega dos produtos que atendamos requisitos futuros do cliente;

• Tempo de Entrega Reduzido – Visando a encontrar novos merca-dos e melhorando o retorno no investimento;

• Capacidade de Adaptação do Processo e das Pessoas – Respostasrápidas às mudanças de negócio e produtos;

• Resultados Confiáveis – Para apoiar o crescimento e o aumento dalucratividade.

Considerando a geração de um ambiente de aprendizado contínuo apli-cando-se o Gerenciamento Ágil de Projetos, um projeto ágil típico é estruturadopor uma etapa inicial seguida de várias iterações, que são ciclos do projeto.A cada nova iteração é realizado um novo planejamento de escopo, custo, quali-dade e prazos, visando à entrega de produtos ou resultados aliado a implementa-ção de novas funcionalidades conforme a necessidade do negócio. Ao final dasvárias iterações de um projeto ágil, dá-se o término do mesmo.

A tabela a seguir mostra um comparativo entre os processos do gerenci-amento tradicional com as fases do gerenciamento ágil, em que é possível visua-lizar de forma sintetizada a correspondência, ou a inexistência da mesma, entreos dois métodos.

p. 209 - 230

214


Tabela 2: Correspondência entre as abordagens tradicional e ágil de GP

Fonte: Dias, 2008.

4 MÉTRICAS DE AVALIAÇÃOPara estabelecer métricas de análise, é preciso primeiramente identificar

quais são as funcionalidades essenciais para um gerenciamento de projetos eficazbaseado no apoio ferramental tecnológico. Para tal, a tabela a seguir demonstraquais são as atividades de gerenciamento envolvidas em cada uma das áreas es-senciais do PMBOK (custo, tempo, escopo e integração).

p. 209 - 230

215


Tabela 3: Atividades de Gerenciamento com Abordagens Ágeis

p. 209 - 230

216


A partir da análise de requisitos, ou necessidades listadas anteriormente, épossível sugerir uma solução para a questão da escolha da ferramenta adequada.

Essa solução vem através de um sistema de ranking entre as aplicações, emque é possível atribuir notas às ferramentas para cada funcionalidade analisada.

Ao realizar a análise das ferramentas, cada funcionalidade de cada aplica-ção recebeu uma classificação. Essas classificações são qualitativas e foram divi-didas em: Completa, Incompleta; Flexível ou Inflexível; ou Não Apresenta. Asdefinições destas classificações são explicadas a seguir.

Completo: indica que a funcionalidade não apresenta falhas ou ausênci-as relevantes na aplicação.

Incompleto: indica que a aplicação pode não atender por completo asnecessidades as quais ela deveria atender, ou apresenta alguma falha ou ausência.

Flexível: essa classificação indica que um usuário ou administrador dosistema utilize a funcionalidade da maneira que lhe convier. Permite adaptar epersonalizar a funcionalidade de acordo com a sua necessidade.

Inflexível: indica que a aplicação não permite a adaptações das açõesrelativas à funcionalidade.

Não Apresenta: indica que a aplicação não apresenta uma determinadafuncionalidade, levando em conta a instalação utilizada.

Tais combinações qualitativas recebem valores quantitativos entre 1 e 5,sendo que o valor 1 representa a pior qualificação, enquanto o valor 5 representaa melhor combinação. Com isso, foi possível classificar de acordo com a tabela aseguir, adaptada de Batista (2007):

p. 209 - 230

217


Tabela 4: Critérios de Classificação das Ferramentas

Fonte: Batista, 2007.

A estrutura do processo de avaliação desta pesquisa consiste em quatroníveis de hierarquia conforme mostrado na figura 6 a seguir. O nível 1 contém asalternativas, ou seja, as ferramentas selecionadas para o escopo da análise. O nível2 indica os nove grupos de atividades identificados anteriormente nesta seção.O nível 3 indica a aplicação dos critérios de classificação descritos na tabela 4 destaseção, aos grupos de atividades do nível 2. E o nível 4 é o objetivo, que é de identi-ficar a melhor ferramenta dentre o escopo analisado dentro de cada critério.

Figura 1: Processo de Avaliação elaborado pelo autor

p. 209 - 230

218


Para cada uma das funcionalidades durante a análise, foi aplicado umprocesso capaz de auxiliar na classificação individual dos itens, verificando assimo resultado de cada ferramenta submetida ao cenário descrito.

Figura 2: Etapas da Avaliação por Funcionalidade

5 RESULTADOSNesta seção são apresentadas as análises baseadas nos cenários definidos

considerando métricas descritas anteriormente.As matrizes construídas baseada nas análises nos dão uma visão geral de

como as funcionalidades levantadas estão caracterizadas nas ferramentas analisa-das. Mas o principal objetivo da construção dessas matrizes de notas é a suautilização como parâmetro visando identificar as ferramentas mais completaspara aquela determinada funcionalidade.

A análise visou a identificar funcionalidades diretamente associadas aoproposto da sua descrição, ou então funcionalidades similares.

p. 209 - 230

219


5.1 Plano de ReleaseDentre as funcionalidades esperadas para o plano de release, espera-se a

possibilidade do planejamento por etapas, com base em releases que possuemiterações com entregas definidas (resultados), ao invés de atividades e fases utili-zadas nos métodos tradicionais.

Os requisitos do cliente foram identificados em todas as ferramentas,com terminologias diferentes, mas com um mesmo objetivo, relatar de formasucinta aquilo que o cliente deseja ser implementado.

Os rankings de estórias (requisitos) e defeitos devem passar ao usuáriotanto uma visão analítica quanto sintética, da situação daqueles itens dentro darelease verificada. Essa visão consiste em identificar o percentual completo doitem, quem é o responsável e datas.

A caracterização dos problemas e impedimentos é fundamental para ogerente do projeto tomar decisões, priorizar suas atividades e identificar os pon-tos de maior risco dentro da release. Para esse item, é importante a existência deum registro com o andamento da solução do item, para que o gerente de projetotenha sempre a noção de rastreabilidade daquele item.

As dependências da release são fundamentais quando existem diversosprojetos concorrentes e existam dependências de hardware ou software entreestes.

As análises, cujos resultados são apresentados na tabela 5, demonstram queas ferramentas possuem na sua maioria funcionalidades que atendem a demandaexigida por um gerente no planejamento de uma release, sendo que o gerenciamentodas estórias foi certamente a funcionalidade mais constante identificada, e por ou-tro lado, o controle de dependências das releases, um item de extremo valor para ogerente, acabou por ser a funcionalidade com maior carência.

p. 209 - 230

220


Tabela 5: Análise quanto ao Plano de Release

Legenda: XL - XPLive; XP - XPlanner; FDD – FDD Tools; VO -VersionOne; RA – Rally

5.2 Plano de IteraçãoUm gerente de projeto possui necessidades similares quando busca in-

formações de uma release e de uma iteração específica.A equipe deve trabalhar reunida para definir o planejamento das estórias,

em que o gerente deve poder criar uma ou mais tarefas referente a uma estóriaespecífica designando o tempo, severidade, e o responsável pela sua execução.

Os testes são criados por membros da equipe, contudo o acompanha-mento da criação e execução dos mesmos deve ser visível ao controle do gerentepara que possa principalmente medir a estabilidade do time bem como a veloci-dade com que o desenvolvimento está sendo feito em relação à qualidade.

Os problemas, impedimentos e dependências seguem a mesma regra doplano de release; entretanto, iterações ocorrem em períodos menores e deve seralgo muito claro a forma com que são disponibilizados estes dados ao gerente.

As análises, cujos resultados são apresentados na tabela 6, demonstramque as ferramentas analisadas possuem discrepâncias quanto às funcionalidades

p. 209 - 230

221


do plano de iteração. As ferramentas de código fechado atendem de forma ple-namente satisfatória todas as funcionalidades, porém nas ferramentas de códigoaberto a maioria das funcionalidades foi identificada de forma incompleta docomportamento esperado ou a funcionalidade não existia.

Tabela 6: Análise quanto ao Plano de Iteração


5.3 Plano de TestesOs testes, dentro das metodologias ágeis, ocorrem em paralelo junto ao

desenvolvimento em meio a uma iteração. Por essa razão o gerente de projetosprecisa ter o acesso a ambos, o quadro de andamento de tarefas bem como oquadro de andamento de testes daquelas tarefas que vão sendo completadas.

Uma visão customizada da situação dos casos de teste e sua situaçãopermitem ainda que dentro do time, membros com papéis diversificados consi-gam extrair informações de acordo com sua necessidade.

As análises, cujos resultados são apresentados na tabela 7, demonstramum equilíbrio bastante positivo quanto às funcionalidades de testes. Embora se

p. 209 - 230

222


tratando de metodologias de desenvolvimento não focadas em testes, as funcio-nalidades desta área possuem atenção especial, especialmente no controle de ta-refas e defeitos. Verificou-se uma lacuna quanto a funcionalidades de armazena-mento e controle de casos de teste em todas as ferramentas.

Tabela 7: Análise quanto ao Acompanhamento de Testes


5.4 Tamanho do ProjetoO tamanho do projeto deve ser considerado na escolha da ferramenta

para apoio ao gerenciamento devido ao fato de que a forma de apresentação dedados, interação do usuário bem como capacidade de expansão das tarefas doprojeto devem ser apresentadas de formato transparente para o usuário.

As análises, cujos resultados são apresentados na tabela 8, demonstramuma informação relevante para um gerente de projetos. Muitas vezes, uma ferra-menta por mais eficiente que seja, precisa suportar uma demanda de projetosmaiores, e neste aspecto, percebe-se uma lacuna das ferramentas de código aber-to, que possuem características de apresentação de funções e telas direcionadaspara projetos com pequeno volume de informações.

p. 209 - 230

223


Tabela 8: Análise quanto ao Tamanho do Projeto

Legenda: XL - XPLive; XP - XPlanner; FDD – FDD Tools; VO - VersionOne; RA – Rally

5.5 IntegraçãoOs quesitos de integração são de extrema relevância para o gerenciamen-

to do projeto, uma vez que diversas documentações e evidências durante o ciclode vida do projeto são produzidas, utilizando-se variados aplicativos de suporte,tais como editores de texto, planilhas eletrônicas, enfim, arquivos de diversosformatos que tem grande importância para o projeto.

As análises, cujos resultados são apresentados na tabela 9, demons-tram que numa análise geral, as ferramentas possuem um bom nível de inte-gração com os principais recursos selecionados, exceto wiki, um conceitoainda novo em gerenciamento de projetos, mas que tende a crescer rapida-mente, como um formato eficiente de controle de todos os documentos doprojeto.

p. 209 - 230

224


Tabela 9: Análise quanto a Integração


5.6 Configuração da AplicaçãoA customização de funcionalidades, processos e terminologias traz o be-

nefício da identificação da ferramenta junto à empresa, além do que favorece aotime uma melhor aceitação uma vez que a configuração fica de acordo com oscritérios definidos pelo mesmo.

As análises, cujos resultados são apresentados na tabela 10, demons-tram que dentre as ferramentas selecionadas, o quesito de configuração é par-cialmente atendido por ferramentas de código aberto, tendo aí uma oportuni-dade de melhoria explícita. Por outro lado, as ferramentas de código fechadopossuem funcionalidades eficientes que atendem na sua maioria as funcionali-dades selecionadas.

p. 209 - 230

225


Tabela 10: Análise quanto a Configuração da Aplicação


5.7 ImplantaçãoA implantação da ferramenta ocorre na fase em que o time está prepa-

rando-se para iniciar o projeto, sendo assim, a ferramenta deve adequar-se aoprocesso que o time pretende utilizar, levando em conta que a ferramenta deve seadaptar ao processo determinado pelo time, e não o contrário. Atualmente, am-biente baseado na Web, facilita, principalmente quando existem times remotos, epermite que qualquer pessoa mesmo que em locais distantes da base do timeconsiga interagir e verificar a situação do projeto.

As análises, cujos resultados são apresentados na tabela 11, demonstramque há opções de ferramentas não baseadas na internet (Web), mesmo levandoem conta o fato de equipes remotas serem algo comum em desenvolvimento desoftware, o que dificulta o controle gerencial.

p. 209 - 230

226


Tabela 11: Análise quanto a Implantação

5.8 RelatóriosRelatórios são as funcionalidades mais importantes em termos de geren-

ciamento de projetos. Baseado em relatórios de qualidade, um gerente possuidiversos ângulos no qual pode verificar o andamento do projeto, riscos, proble-mas, oportunidades, etc. Em abordagens ágeis, alguns gráficos são largamenteutilizados, como o burndown, velocidade e escopo atendido das iterações e/oureleases. Além disso, outros gráficos citados na tabela a seguir têm vital importân-cia para um gerenciamento eficaz.

As análises, cujos resultados são apresentados na tabela 12, demonstrama importância que relatórios possuem para o gerente de projetos, tanto que osresultados foram satisfatórios, com a maioria dos relatórios considerados essen-ciais em métodos ágeis disponíveis de forma completa ou parcialmente comple-ta, ou seja, alguns com um detalhamento de informações ou opções de critériosde entrada mais elaborados do que outros.


p. 209 - 230

227


Tabela 12: Análise quanto aos Relatórios


5.9 Times MultifuncionaisEm abordagens ágeis, a equipe de projeto possui um envolvimento mui-

to grande, em que uma ferramenta designada precisa representar via software omesmo ambiente colaborativo que deve existir no dia a dia, ou seja, pessoas comdiferentes papéis dentro do projeto colaborando entre si inclusive nas entregassubmetidas ou coletadas da ferramenta.

As análises, cujos resultados são apresentados na tabela 13, demonstramque ambientes colaborativos foram plenamente identificados nas ferramentas de

p. 209 - 230

228


código fechado, em contrapartida, de forma insatisfatória nas ferramentas decódigo aberto, determinando assim uma lacuna que pode impactar diretamentenas atividades do gerente de projeto.

Tabela 13: Análise quanto a Times Multifuncionais

Legenda: XL - XPLive; XP - XPlanner; FDD - FDD Tools; VO - VersionOne; RA - Rally

5.10 Gerenciamento IntegradoEm se tratando de gerenciamento de projetos, em que diferentes equipes

possuem diferentes entregas dentro do escopo de suas atividades, a integraçãodas funcionalidades torna-se um item relevante uma vez que o gerente de proje-tos ganha em velocidade e confiabilidade de dados.

As análises, cujos resultados são apresentados na tabela 14, demonstramque todas as ferramentas analisadas possuem algum tipo de integração entre asfuncionalidades, em níveis de aceitação diferenciados. Contudo, a amostra evi-dencia que o gerenciamento integrado é realmente fundamental para o gerentede projeto.

p. 209 - 230

229


Tabela 14: Análise quanto ao Gerenciamento Integrado

Legenda: XL - XPLive; XP - XPlanner; FDD - FDD Tools; VO - VersionOne; RA - Rally

Os resultados obtidos em um âmbito geral da análise apresentam dadossatisfatórios para a escolha de uma ferramenta baseada na qualidade de atendi-mento separado por funcionalidades, ou seja, a grande maioria dos itens relacio-nados para essa análise foi identificada de alguma maneira nas ferramentas, po-rém vale destacar uma grande diferença dentre as ferramentas de código fechadoe código aberto, pois a qualidade de apresentação e a riqueza de detalhes podemser fundamentais para um gerenciamento mais eficiente.

6 CONSIDERAÇÕES FINAISConclui-se que o apoio ferramental é imprescindível a um gerente de proje-

tos, devido ao fato do volume de informações que este precisa controlar paralelamen-te ao andamento do projeto com características ágeis, verificando informações depessoas trabalhando em atividades diferentes, realizando ajustes de uma forma trans-parente que não cause impacto e desconforto para o time de desenvolvimento.

O processo de avaliação elaborado permitiu que fossem realizadas análi-ses equivalentes para todas as funcionalidades de todas as ferramentas de umaforma que o resultado fosse o mais justo possível, considerando o desempenhoda mesma diante de uma funcionalidade específica, e não considerando um de-sempenho geral.

p. 209 - 230

230


Foi possível identificar que, os softwares de gerenciamento de projetospossuem tendência de apresentar funcionalidades de acompanhamento contí-nuo das mudanças necessárias no decorrer do projeto.

REFERÊNCIASAUGUSTINE, S.; WOODCOCK, S. Agile Project Management. CC PaceSystems - 2003.BATISTA, A. L. Proposta de um sistema para ranqueamento de sistemasgerenciadores de conteúdo baseado em análises comparativas. Dissertação(bacharelado) – Universidade Federal de Lavras, Curso de Ciência da Computa-ção - 2007.CHIN, G. Agile Project Management–How to Succeed in the Face ofChanging Project Requirements. Amacom Books – 2004.FLORAC, W.; PARK, R.; CARLETON, A. Practical Software Measurement:Measuring for Process Management and Improvement. SEI, Carnegie MellonUniversity. Abril, 1997.HIGHSMITH, J. Agile Project Management – Creating Innovative Products.Addison Wesley - 2004.LARMAN, C. Agile & Iterative Development: A Manager’s Guide. Mass.:Addison-Wesley, 2003.MAGALHÃES, A. de C.; ROUILLER, A. C.; VASCONCELOS, A. L. OGerenciamento de Projetos de Software Desenvolvidos à Luz dasMetodologias Ágeis: Uma visão corporativa. ProQualiti - Volume 1 - Univer-sidade Federal de Lavras, 2005.

p. 209 - 230

ANÁLISE DO APOIO TECNOLÓGICO AO GERENCIAMENTO DE … · Este artigo estabelece uma visão...

Documents

Transcript of ANÁLISE DO APOIO TECNOLÓGICO AO GERENCIAMENTO DE … · Este artigo estabelece uma visão...