monografia gerenciamento de projetos
TRANSCRIPT
CURSO DE PÓS-GRADUAÇÃO LATO SENSU EM GERENCIAMENTO DE PROJETOS
JORGE DA SILVA SANTOS
GERENCIAMENTO DE PROJETOS DE SOFTWARE E MÉTODOS ÁGEIS
CAMPOS DOS GOYTACAZES/RJ2011
JORGE DA SILVA SANTOS
GERENCIAMENTO DE PROJETOS DE SOFTWARE E MÉTODOS ÁGEIS
Monografia apresentada a FIJ – Faculdades Integradas Jacarepaguá, como requisito para conclusão do Curso de Pós-Graduação lato sensu em Gerenciamento de Projetos.
Orientador: Jorge Washington S. dos Santos
CAMPOS DOS GOYTACAZES/RJ2011
JORGE DA SILVA SANTOS
GERENCIAMENTO DE PROJETOS DE SOFTWARE E MÉTODOS ÁGEIS
Monografia apresentada a FIJ – Faculdades Integradas Jacarepaguá, como requisito para conclusão do Curso de Pós-Graduação lato sensu em Gerenciamento de Projetos.
Aprovada em xx de xxxxxxxx de 2011.Banca Avaliadora:
.......................................................................................................................................Prof. Jorge Washington S. dos Santos
.......................................................................................................................................Prof.
.......................................................................................................................................Prof.
CAMPOS DOS GOYTACAZES/RJ2011
AGRADECIMENTOS
Primeiramente agradeço a Deus, Doutor e Mestre por essência e excelência.
Aos parentes e amigos que estiveram sempre presentes a apoiar-me em
minhas dificuldades, bem como fornecer o devido auxílio, seja ele moral ou material.
Enfim, a todos que colaboraram de alguma forma para que este trabalho
fosse concluído com êxito.
As dificuldades crescem à medida que nos aproximamos do nosso objetivo.
Johann Wolfgang Von Goethe
RESUMO
Este trabalho destina-se a fazer uma abordagem sistemática dos métodos de
gerenciamento de projetos, voltados especificamente para a área de
desenvolvimento de software. Descreveremos os métodos mais importantes e suas
respectivas vantagens e desvantagens, visando atender as necessidades dos
clientes.
ABSTRACT
This work is intended to make a systematic approach to project management
methods, specifically tailored to the area of software development. We describe the
most important methods and their advantages and disadvantages, to meet customer
needs.
LISTA DE ABREVIATURAS
LISTA DE FIGURAS
SUMÁRIO
1. INTRODUÇÃO
A era de Globalização trouxe consigo mudanças que têm afetado
sobremaneira os diversos processos de Gerenciamento de Projetos, dessa forma
tornando o mercado mais competitivo e, com isso, criando expectativas maiores no
que se refere à agilidade e qualidade. Estamos diante de pessoas mais exigentes e
criteriosas com relação a produtos e serviços. Diante disso, forçosamente, temos
que nos atualizar e nos adaptar aos novos rumos prescritos pela Era Moderna.
A competitividade nos mercados internacionais é fator preponderante dessa
nova realidade, onde aqueles que ficaram estagnados no tempo perderam seus
lugares para outros que procuraram acompanhar tamanha evolução, que em certas
áreas é tão rápida que se não estivermos atentos nos distanciaremos dela.
Para que possamos atender as expectativas inseridas no contexto da
demanda atual, faz-se necessário que nos detenhamos na utilização de recursos
que nos levarão à realização efetiva daquilo para o qual fomos designados ou
contratados. Assim sendo, tornamo-nos parte de um sistema onde gerenciamos ou
somos gerenciados.
Em toda organização são desenvolvidos algum tipo de trabalho e esses são
executados por pessoas – em maior ou menor número, dependendo deles -,
envolvendo planejamento, recursos e controle, eles são divididos em projetos e
tarefas. Aquele, segundo define o PMBOK (2004), é um empreendimento temporário
com o objetivo de criar um produto ou serviço único. Dessa forma, a temporalidade
aqui, significa que ele depois de concluído é, em sua essência, diferente dos outros.
A alocação de recursos e o tempo de execução de um projeto são fatores
determinantes para avaliar sua complexidade e nos levar a agir para que
efetivamente levemos a cabo sua conclusão.
Ainda no tocante à definição de projeto, podemos citar, por exemplo,
KERZNER (2005), que define projeto como um empreendimento com objetivos bem
definidos, consumindo recursos e operando sob pressões de prazo, custo e
qualidade.
A ABNT (NBR 10006) define que projeto é um processo único, consistindo
de um grupo de atividades coordenadas e controladas com datas para início e
término, empreendido para alcance de um objetivo, conforme requisitos específicos,
incluindo limitações de tempo, custos e recursos.
A Gerência de Projetos é definida, segundo o Project Management Body of
Knowledge (PMBOK, 2004) é a aplicação de conhecimentos, habilidades,
ferramentas e técnicas em atividades do projeto, com o intuito de satisfazer ou
exceder as necessidades e as expectativas dos stakeholders1
Como este trabalho está voltado para a área de software, podemos
acrescentar a definição de Gerência de Projetos dada por Pressman (1995) que diz
que ela é uma tarefa de vital importância no processo de desenvolvimento de um
produto, sendo definida como a primeira camada deste processo e não é visto como
uma etapa clássica do desenvolvimento, desde que ela acompanha todas as etapas
do desenvolvimento, ou seja, da concepção à obtenção do produto. Pressman
também diz que para que um projeto de software seja bem sucedido, é necessário
1 Stakeholders são pessoas ou organizações que são afetadas pelo sistema e que tem influência direta ou indireta nos requisitos do sistema [PMBOK (2004)].
que alguns parâmetros sejam corretamente analisados, a saber: o escopo, os riscos
envolvidos, os recursos necessários, as tarefas a serem realizadas, os indicadores a
serem acompanhados, os recursos e custos aplicados e a sistemática que deverá
ser seguida.
1.1. GERENCIAMENTO DE PROJETO DE SOFTWARE
Para que possamos nos deter com maior profundidade no tema deste
trabalho, torna-se necessário falarmos um pouco sobre o gerenciamento de projetos
de software,
Começaremos falando sobre pesquisas realizadas na década de 90, onde
eram demonstradas que as principais causas do fracasso – falhas na execução e
atraso na entrega – de um projeto de software estariam ligadas ao desempenho do
gerenciamento do projeto. No ano de 1993, o Software Engineering Institute (SEI),
verificou que o problema de maior relevância que preocupa as organizações de
software é aquele relacionado com o aspecto gerencial.
Darci Prado (PRADO, 2008), em seu livro intitulado ‘Maturidade em
Gerenciamento de Projetos’, fala sobre o Relatório Chaos Report (2004), ao analisar
os projetos de TI que falharam, afirma que isto não aconteceu, em sua maioria, por
falta de recursos ou acesso à tecnologia, mas antes por falta de conhecimento em
gestão de projetos e que esse não é aplicado somente à figura do gestor, mas
também de todos os integrantes da equipe.
O Relatório Chaos realizado pelo Standish Group (1995) identificou que as
empresas americanas gastaram $ 81 milhões em projetos de software que foram
cancelados em 1995. Destes, 31% foram cancelados antes da sua conclusão; 53%
dos que foram concluídos excederam mais de 50% em sua estimativa de custo.
Somente 9%, referentes às grandes organizações, foram entregues no tempo e
orçamentos previstos. No que se refere às pequenas e médias empresas, o
números melhoraram em 28% e 16% respectivamente. Esse relatório assinala o
gerenciamento como principal responsável pelo sucesso ou falha de um projeto de
software.
1.1.1 Partes envolvidas no Projeto de Software
No projeto de Software há o envolvimento de várias pessoas que exercem
diversos papéis, a saber:
- Gerente de Projeto;
- Desenvolvedor (Analistas, Projetistas, Programadores e Engenheiros de
Testes);
- Gerente de Qualidade;
- Clientes;
- Usuários.
Denomina-se equipe o conjunto de pessoas que trabalham num projeto em
diferentes tarefas, mas com os mesmos objetivos. Isso não se aplica somente aos
projetos de software, mas a toda atividade.
Os papéis de cada um devem ser bem definidos, considerando-se que a boa
formação de uma equipe depende disto. Também deve-se levar em conta alguns
elementos como relacionamento interpessoal, criatividade, tipo de projeto, entre
outros.
Segundo Pressman (PRESSMAN, 2005), no tocante à estrutura das
equipes, podemos classificá-las em vários tipos:
- Democrática Descentralizada: nesta, não há um líder permanente, mas o
consenso do grupo é quem determina a tomada de decisões;
- Controlada Descentralizada: aqui há um líder, ainda que a comunicação
seja horizontal;
- Controlada Centralizada: há um líder e a comunicação entre ele e a equipe
é vertical.
1.1.2 O Processo do Gerenciamento do Projeto de Software
A composição do processo de gerenciamento de software envolve três
etapas principais:
- Planejamento: é um plano bem organizado que define, no início do projeto,
como esse será elaborado. Ele tem como função abordar as definições do
escopo do software, do processo de software do projeto, da realização de
estimativas, da elaboração de cronograma, da identificação e solução para
os riscos agregados ao projeto;
- Acompanhamento: No início do projeto existe pouca informação que
possibilite evitar o comprometimento da precisão do escopo, das estimativas
feitas e do cronograma desenvolvido. Pela própria natureza dos projetos, o
conhecimento aumenta na medida em que estes avançam e, dessa forma,
podemos ajustar e fazer um refinamento dos elementos supracitados.
Como os projetos são dinâmicos e, assim sendo, estão sempre sujeitos à
modificações, torna-se fundamental acompanhar o seu progresso, fazer
alterações no processo do projeto e no cronograma, fazer refinamento no
escopo e, por fim, monitorar riscos e tomar ações corretivas;
- Encerramento: Após o término do projeto, passa-se para a análise do que
deu certo e o que não funcionou conforme as especificações do projeto.
Aqui podemos fazer comparações entre o estimado e o realizado, identificar
os problemas e suas causas. Tudo isso deve ser feito com o envolvimento
de toda a equipe, de forma a se tornar um aprendizado para futuros
projetos.
1.1.3 Áreas de Conhecimento em Gerenciamento de Projetos
Conforme cita o PMBOK (2004), existem nove áreas de conhecimento em
gerenciamento de projetos, a saber: gerenciamento de integração, do escopo, de
tempo, de custos, da qualidade, dos recursos humanos, das comunicações, de
riscos e de aquisições. Abaixo faremos uma breve descrição de cada uma das
referidas áreas.
1.1.3.1 Gerenciamento de Integração
Segundo Vieira, o Gerenciamento de Integração é a área responsável pela
identificação e gerenciamento dos pontos de interação entre os elementos do projeto
e o estabelecimento e manutenção da boa comunicação entre esses pontos.
1.1.3.2 Gerenciamento de Requisitos
A definição para requisitos, segundo SAYÃO E BREITMAN (2005) é: “uma
capacidade de software que deve ser disponibilizada por um sistema ou componente
de um sistema de modo a satisfazer um contrato, padrão, especificação ou outra
formalidade imposta”.
1.1.3.3 Gerenciamento de Escopo
De acordo com Vieira, escopo é todo trabalho envolvido na criação dos
resultados do projeto (VIEIRA, 2003). O Gerenciamento de Escopo faz a descrição
dos processos envolvidos na verificação de que o projeto inclui, tão e somente, o
trabalho necessário para que seja concluído com sucesso.
1.1.3.4 Gerenciamento de Tempo
Envolve o controle das atividades para o cumprimento do cronograma e a
confirmação dos marcos do projeto dentro das estimativas de prazo (VIEIRA, 2003).
É a área que descreve os processos relacionados ao término do projeto dentro do
prazo estimado.
1.1.3.5 Gerenciamento de Custos
Descreve os processos envolvidos no planejamento, na estimativa, no
orçamento e controle de custos, visando o término do projeto dentro do orçamento
aprovado. De acordo com VIEIRA (2003), o importante é não determinar custos
antes da definição do requisito e do escopo, além de estuda bem a tecnologia a ser
utilizada.
1.1.3.6 Gerenciamento de Qualidade
Este tem por base a descrição dos processos envolvidos na garantia de que
o projeto irá satisfazer as metas definidas a serem alcançadas por ele, no que está
implícita a satisfação dos clientes e usuários finais. Vieira (2003) diz que a qualidade
está ligada ao atendimento das necessidades do usuário final e, em alguns casos,
ao desempenho do sistema.
1.1.3.7 Gerenciamento de Recursos Humanos
Como é uma das principais fontes da produtividade no desenvolvimento de
sistemas, o gerenciamento e o planejamento das pessoas envolvidas no projeto são
de fundamental importância, especialmente para que os prazos sejam cumpridos.
1.1.3.8 Gerenciamento de Comunicações
O gerenciamento de comunicações descreve os processos relacionados à
geração, coleta, armazenamento e destinação final das informações do projeto, de
forma oportuna e adequada (VIEIRA, 2003).
1.1.3.9 Gerenciamento de Aquisições
Aqui são descritos os processos de compra ou aquisição de produtos,
serviços ou resultados, além dos processos de gerenciamento de contratos (VIEIRA,
2003).
Depois de darmos algumas definições relacionadas ao Gerenciamento de
Projetos e, em especial, ao de software, avançamos neste trabalho, cuja temática
envolve gerenciamento de projetos de software, lidando com os métodos ágeis, mas
sem deixar de falar sobre os métodos tradicionais.
No Capítulo 3 faremos uma abordagem sobre os métodos tradicionais e ágeis. Descrevendo de maneira sucinta suas vantagens e desvantagens e quando é mais viável utilizá-los.
O Capítulo 4 será destinado a uma pequena comparação entre os dois métodos.
1.2. JUSTIFICATIVA
A acirrada competição no mercado de software tem como exigência principal
a melhoria nos processos de desenvolvimento. Melhoria essa, que têm sua
fundamental atenção voltada para a qualidade dos processos e da produtividade,
assim como para a redução de riscos.
O desenvolvimento de software requer muita habilidade, visto que na prática
é, em grande parte, uma atividade normalmente muito confusa, comumente
marcada pelos verbos: codificar e consertar.
Quando o sistema é pequeno, as indefinições do plano inicial do projeto,
com as múltiplas decisões a serem tomadas em curto prazo, não interferem,
sobremaneira, no andamento do sistema. Entretanto, se o projeto é de maior vulto,
torna-se mais difícil implantar-lhe novos recursos e os defeitos que se subseguem,
tornam-se cada vez mais arraigados e, consequentemente, difíceis de serem
suprimidos.
O sistema acima citado carrega consigo, como característica, uma longa
fase de testes que confronta diretamente com o cronograma estabelecido, visto que
as atividades de testes não deixam margem para uma previsão exata de tempo para
a execução delas.
Segundo FOWLER (2000), metodologias impõem um processo disciplinado
no desenvolvimento de software com a finalidade de torná-lo mais eficiente e
previsível. Elas fazem isso desenvolvendo um processo detalhado com uma forte
ênfase em planejamento e inspiradas em outras disciplinas de engenharia, motivo
pelo qual Fowler se refere a elas como “Metodologias de Engenharia”.
Sendo as metodologias supracitadas consideradas como burocráticas, surge
um novo grupo que reage a elas. A princípio eram chamadas de metodologias
“leves”, mas hoje o termo mais aplicado é metodologia ágil.
Essas metodologias tentam criar um meio termo entre a escassez e o
excesso de processos, de forma a prover o suficiente deles, para ter uma resposta
plausível.
Conforme FOWLER (2000), o resultado disso é que os métodos ágeis têm
algumas mudanças de ênfase significativas em relação aos métodos burocráticos ou
tradicionais. E continua, dizendo que os métodos ágeis são menos centrados em
documentação e de várias formas são mais voltados ao código-fonte do programa.
Ainda que os métodos ágeis ainda sejam vistos com desconfiança pelo
gerenciamento tradicional, a cada dia surgem novos adeptos daqueles.
Pela utilização de uma abordagem simplificada, os métodos ágeis vêm se
popularizando no Brasil nos últimos anos.
De acordo com HIGHSMITH (2004), Agilidade é a habilidade de criar e
responder a mudanças com respeito ao resultado financeiro do projeto em um
turbulento ambiente de negócios. Agilidade é a habilidade de balancear flexibilidade
com estabilidade. Ele ainda enfatiza que a ausência de estrutura ou estabilidade
pode levar ao caos, ainda que acrescente que a estrutura em demasia gera a
rigidez.
Não se trata aqui de colocar os métodos ágeis como a única alternativa para
o desenvolvimento de software, pois existem casos em que é mais aconselhável
adotar a metodologia tradicional.
Nossa proposta é analisar os métodos ágeis na sua função de alcançar a
melhoria no desenvolvimento de software, atingindo, assim, o objetivo de atender os
requisitos propostos e a qualidade esperada pelos envolvidos no projeto.
1.3. OBJETIVOS
A seguir, apresentaremos o objetivo geral e os específicos que serão
desenvolvidos no decorrer deste trabalho.
1.3.1 Objetivo Geral
O Objetivo principal deste trabalho é fazer uma análise das metodologias
ágeis no gerenciamento de projetos de software em contraste com as metodologias
tradicionais, levantando seus pontos comuns e divergentes.
1.3.2 Objetivos Específicos
Os objetivos específicos, que aqui serão tratados, são baseados nos
seguintes itens:
Citar as metodologias ágeis mais relevantes no mercado;
Demonstrar, através de pesquisas, a aceitação da metodologia ágil no
mercado;
Fazer uma breve comparação entre os métodos ágeis e os tradicionais;
1.4. METODOLOGIA DE PESQUISA
A metodologia de pesquisa utilizada neste trabalho foi, em sua grande parte,
marcada pela pesquisa bibliográfica e também a eletrônica. Essas duas
modalidades de pesquisa foram a base dos estudos necessários para que fosse
possível adquirir conhecimentos que levasse a concretização do referido trabalho.
Também foram coletadas informações com professores do IFF – Campos
dos Goytacazes, bem como a utilização de aulas da disciplina de Gerenciamento de
Projetos do curso de Análise e Desenvolvimento de sistemas da referida Instituição.
Buscou-se também subsídios nos relatórios do Ministério da Ciência e
Tecnologia, sobre desenvolvimento de software.
2. CAPÍTULO I
2.1. INTRODUÇÃO
Neste capítulo abordaremos a metodologia ágil nos seus diversos aspectos,
a partir de um enfoque do Manifesto Ágil, o qual prega que a “prioridade é satisfazer
o cliente através de entregas antecipadas e contínuas de software de valor”.
De acordo com FOWLER (2000), metodologias ágeis buscam criar um
equilíbrio entre nenhum processo e muito processo, fornecendo o suficiente de
processo para a obtenção de um retorno aceitável. Ele acrescenta que a maior
diferença mais clara entre essa modalidade e a tradicional é que as metodologias
ágeis são menos centradas em documentação, ainda que menos documentação
seja apenas um sintoma de duas diferenças mais profundas:
Metodologias ágeis são adaptativas ao invés de
predeterminantes. Metodologias de engenharia tendem a
tentar planejar uma grande parte do processo de
desenvolvimento detalhadamente por um longo período de
tempo. Isso funciona bem até as coisas mudarem. Então a
natureza de tais métodos é a de resistir à mudança. Para os
métodos ágeis, entretanto, mudanças são bem-vindas. Eles
tentam ser processos que se adaptam e se fortalecem com
as mudanças, até mesmo ao ponto de se auto-modificarem.
Métodos ágeis são orientados a pessoas ao invés de serem
orientados a processos. O objetivo dos métodos de
engenharia é de definir um processo que irá funcionar bem,
independentemente de quem os estiverem utilizando.
Métodos ágeis afirmam que nenhum processo jamais será
equivalente à habilidade da equipe de desenvolvimento.
Portanto, o papel do processo é dar suporte à equipe de
desenvolvimento e seu trabalho.
Para SOMMERVILLE (2003), em geral, as metodologias ágeis dispõem de
uma abordagem iterativa para especificação, desenvolvimento e entrega de
software.
Nossa abordagem não fará menção às controvérsias em torno do assunto,
mas somente expor, de maneira sucinta e clara, a metodologia ágil com suas
características de usabilidade das principais metodologias utilizadas.
2.2. HISTÓRICO
Entre os dias 13 e 13 de fevereiro 2001, um grupo de dezessete
especialistas (gestores e desenvolvedores) em desenvolvimento de software se
reuniu em Utah, nos Estados Unidos da América, para discutir que práticas
poderiam ser usadas para melhorar o desempenho de seus projetos. Nesse
encontro foi assinado um documento chamado de “Manifesto para desenvolvimento
ágil de software”, cujo intuito era determinar qual a visão de uma equipe de
desenvolvimento de software.
O Manifesto Ágil e formado por princípios e valores que devem servir de
base para as equipes. Nele são valorizados:
Indivíduos e interações mais que processos e ferramentas;
Software em funcionamento mais que documentação abrangente;
Colaboração com o cliente mais que negociação de contratos;
Responder a mudanças mais que seguir um plano.
Não são descartados os valores à direita, mas se dá preferência àqueles que
estão colocados à esquerda.
Os princípios que norteiam o Manifesto são 12, a saber:
1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado;
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente;
3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo;
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto;
5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho;
6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face;
7. Software funcionando é a medida primária de progresso;
8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente;
9. Contínua atenção a excelência técnica e bom design aumenta a agilidade;
10. Simplicidade - a arte de maximizar a quantidade de trabalho não realizado-é essencial;
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis;
12. Em intervalos regulares, a equipe deve refletir sobre como tornar-se mais
efetiva, e então, ajustar-se de acordo com seu comportamento;
Não significa, contudo, que ser ágil é radicalizar ou defender que exista
apenas uma solução para os projetos de desenvolvimento de software, mas antes,
que ser Ágil é identificar e focar em objetivos bem definidos, procurar para que haja
conscientização da equipe, assim como a sua união.
2.3. CONSIDERAÇÕES SOBRE METODOLOGIA E MÉTODO
Existem diversas definições ou interpretações para metodologia e método.
No entendimento de YOURDON (1995), metodologia incorpora todo o processo de
desenvolvimento de software e método é aplicado em uma ou mais fases desse
desenvolvimento. Yourdon dá a seguinte definição para metodologia e método:
“Plano de batalha” ou livro de receitas passo a passo para se chegar
a um resultado desejado. Uma metodologia de software comumente
identifica as principais atividades (análise, projeto, codificação,
testes) a serem executadas e indica quais pessoas (usuários,
gerentes, técnicos) devem estar envolvidas em cada atividade e que
papéis deverão desempenhar. As metodologias frequentemente
descrevem os critérios de entrada (essas condições devem ser
satisfeitas antes de iniciar a fase de projeto), os critérios de saída e
os pontos de conferência para decisões de prosseguir/não prosseguir
(os usuários devem decidir ao final da análise se desejam continuar a
financiar o projeto) (YOURDON, 1995).
Método: abordagem técnica passo a passo para se realizar uma ou
mais das principais tarefas indicadas numa metodologia global.
Dessa forma, a análise estruturada é um método para se realizar a
fase de análise de um projeto, enquanto o projeto orientado a objetos
é um método orientado para se executar a fase do projeto
(YOURDON, 1995).
Já PRESSMAN entende que método incorpora todo o processo de desenvolvimento de software, definindo-o assim:
Os métodos de engenharia de software proporcionam os detalhes de “como fazer” para construir o software. Os métodos envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projeto, análise de requisitos de software e de sistemas, projeto da estrutura de dados, arquitetura de programa e algoritmo de processamento, codificação, teste e manutenção. Os métodos da engenharia de software muitas vezes introduzem uma notação gráfica ou orientada à linguagem especial e introduzem um conjunto de critérios para a qualidade do software (PRESSMAN, 1995).
2.4. METODOLOGIAS DE GERENCIAMENTO DE PROJETOS
De acordo com REHMAN (2007), uma metodologia fornece um plano, em
nível estratégico, para planejar e controlar os processos de software. É uma mistura
de processos que nos dizem “o que deve ser feito”, mas não “como deve ser feito”.
KERNER (2001) diz que não é possível atingir a maturidade da gerência de
projetos sem um processo repetitivo que possa ser usado em todos os projetos, o
qual se refere como metodologia do gerenciamento de projetos. Ele acrescenta que
boas metodologias integram outros processos na gerência de projetos e, durante a
década de 90, várias organizações dos mais diversos ramos de atuação, integraram
numa única metodologia de gerência de projetos, os seguintes processos:
- Gerência de Projetos;
- Gerência da Qualidade total;
- Engenharia concorrente;
- controle de Mudança de Escopo;
- Gerência de Risco.
KERNER (2001) também enumera as características de uma boa
metodologia, baseada processos integrados, a saber:
• Um recomendado nível de detalhe;
• Utilização de modelos;
• Técnicas de planejamento, programação e controle dos custos
padronizado;
• Formato de relatórios padronizado, tanto os internos quanto para os
clientes;
• Flexibilidade para a aplicação em todos os projetos;
• Flexibilidade para uma rápida introdução de melhorias, conforme
necessário;
• Fácil para que o cliente possa entender e seguir;
• Prontamente aceito e utilizado em toda organização;
• Uso de fases do ciclo de vida padronizado;
• Baseado em orientações e não em políticas e procedimentos;
• Com base em um bom trabalho ético.
2.5. METODOLOGIAS ÁGEIS
De acordo com FOWLER (2003), várias são as metodologias que estão
dentro da categoria de ágeis. Ainda que todas compartilhem algumas
características, existem algumas diferenças significativas entre elas. Abaixo faremos
a descrição de algumas dessas metodologias para um maior entendimento de seus
processos.
2.5.1 SCRUM
O SCRUM foi concebido por Takeuchi e Nonaka, no artigo “The New
Project Development Game”, como um estilo em gerenciamento de projetos em
indústrias de automóvel e materiais de consumo. Takeuchi e Nonaka perceberam
que projetos que se utilizavam de equipes pequenas e multidisciplinares produziam
os melhores resultados.
A função primária do SCRUM é ser usado para o gerenciamento de
projetos de desenvolvimento de software. Ele tem sido usado com êxito para esse
fim, assim como outras metodologias de desenvolvimento, ainda que também possa
ser utilizado em qualquer contexto, onde um grupo de pessoas precise trabalhar
junto para alcançar um objetivo comum.
SCRUM é um processo ágil e leve que utiliza práticas iterativas e
incrementais para gerenciar e controlar o desenvolvimento de software. Ele aumenta
significativamente a produtividade e reduz o tempo e reduz o tempo para obter
resultados, tendo em vista que facilita a adaptação a processos empíricos de
desenvolvimento de sistemas.
O SCRUM foi adotado como ferramenta padrão de gerenciamento de
projetos nas metodologias MSF for Agile e Open Up, além de atender aos padrões
CMMI e PMBOK.
2.5.1.1 Papéis do SCRUM
Como qualquer metodologia, o SCRUM é baseado em papéis e
responsabilidades, como indicado abaixo:
- Product Owner: Pode se tratar do financiador ou de alguém importante,
interessado no projeto. Suas responsabilidades são:
Definir as funcionalidades do produto;
Concentrar as informações vindas dos usuários, stakeholders
ou do mercado, de forma que se obtenha uma visão única
dos requisitos do sistema;
Priorizar o Product Backlog;
Poder alterar as prioridades fora do Sprint;
Aceitar ou rejeitar os resultados do trabalho.
- Team Members: pode ser considerado como um grupo de pessoas, antes
que um papel. O Team Members é o grupo de pessoas ligadas diretamente ao
trabalho a ser feito, que garantirá que o projeto seja entregue com todas as
funcionalidades necessárias. As características do Team são:
Multifuncional;
Formado por até 7 pessoas;
Define o objetivo do Sprint e especifica o resultado do
trabalho;
Faz o que é necessário dentro das diretrizes do projeto, para
alcançar o objetivo do Sprint;
Auto-organizável;
Demonstra o resultado do Sprint para o Product Owner e
outros Stakeholders.
- SCRUM Master: Sua função está relacionada ao papel de líder. Gerencia
os interesses do Product Owner através do Time. Para ser eficiente, o SCRUM
Master deve atender os seguintes requisitos:
Melhorar a vida e a produtividade do time de desenvolvimento
promovendo o conhecimento e a criatividade;
Proteger o time das interferências externas;
Estimular uma cooperação muito próxima entre todas as
pessoas do time;
Remover impedimentos;
Remover barreiras entre o desenvolvimento e o cliente, a fim
de garantir que o cliente é quem realmente está direcionando
as funcionalidades desenvolvidas;
Garantir que o processo está sendo respeitado;
Promover práticas de engenharia para que cada parte de
funcionalidade seja potencialmente implantável;
2.5.1.2 Etapas de um Projeto com SCRUM
Num projeto SCRUM existem, basicamente, as seguintes etapas (TEAM SYSTEM, 2004):
Preparação: onde é definido o business-case, game concept, Product Baccklog inicial e outras premissas ligadas ao projeto;
Sprints: são iterações realizadas, uma após outra, para entregar gradativamente as estórias que compõem o jogo. Dentro de cada Sprint são realizadas algumas atividades, tais como:
- SCRUM Planning Meeting: é o início de um Sprint, onde o Product
Owner tem a oportunidade de atualizar a priorização dos itens do
Product Backlog e definir juntamente com a equipe, um Product
Increment a ser entregue ao cliente ao final do Sprint.
- Daily SCRUM Meeting: É um encontro diário realizado pela equipe,
onde os membros discutem aquilo em que trabalharam, no que irão
trabalhar e possíveis impedimentos que estejam atrapalhando o o
progresso do trabalho. Este encontro é uma maneira eficiente de
manter os membros cientes dos objetivos e evitar que o projeto se
desvie do seu objetivo.
- Criação do Product Increment: A finalização das estórias definidas
para um determinado Sprint marca a realização do Product Increment.
- Sprint Review: é o momento em que a equipe exibe o Product
Increment construído ao Project Owner, que é responsável por validar
e/ou solicitar ajustes para que o jogo se torne adequado aos anseios
do cliente.
- Sprint Restrospective: tem como objetivo identificar os pontos
positivos e negativos do Sprint que entregou o último Product
Increment e busca corrigir os erros encontrados.
- Atualização do Product Backlog: O Product Owner é responsável
por re-priorizar toda lista de itens do Product Backlog para que um
próximo Sprint possa ser iniciado, motivado pelos itens mais
prioritários.
- Encerramento: Como sugere o próprio nome, é a última etapa de
um projeto utilizando o SCRUM. Ele ocorre, após a finalização de
todos os Sprints e é marcada pela entrega do produto final que foi a
causa da criação do projeto.
Figura 1 – Ciclo do SCRUM. Fonte: http://mundoti.info/wp-content/uploads/2009/10
2.5.2 Extreme Programming (XP)
De acordo com BECK (2004), o idealizador da Extreme Programming, ela é
uma metodologia ágil, para pequenas e médias equipes, onde os requisitos para o
desenvolvimento de software são vagos e estão em constante mudança.
A Equipe da Extreme, se reúne diariamente com o cliente e, com a ajuda de
formulários simples, onde o cliente define o que será feito em seguida, é possível
ajustar suas necessidades a uma situação próxima do ideal.
Existem alguns valores na Extreme Programming, que definem como será o
procedimento da equipe durante o processo de desenvolvimento. Esses valores
devem ser observados para que se tenha um melhor resultado da metodologia em
questão. São Eles:
- Feedback: segundo TELES (2004), esse é o primeiro e talvez o mais
importante dos valores do XP. Os outros o complementam e lhe dão suporte. É o
Feedback que garante um sistema ágil e consistente.
- Simplicidade: No XP, simplicidade significa que o código deve ser
simples, mas funcional. Não deve ser confundido com se fazer de qualquer maneira
e, tampouco, digitar menos código, mas antes ir de encontro à funcionalidade
desejada pelo cliente, para que ocorra o Feedback.
- Comunicação: A equipe de desenvolvimento deve, durante toda fase de
desenvolvimento, trocar informações com o cliente, no intuito de dar continuidade ao
projeto. Essa comunicação poderá ser feita de várias maneiras, ainda que a mais
utilizada seja a escrita em forma de documentação.
Figura 2 – Ciclo de Vida do XP. Fonte: http://www.devmedia.com.br/imagens/javamagazine/Figura_01-
CicloVidaXP.JPG
2.5.3 FDD
FDD - Feature Driven Development (Desenvolvimento Guiado por
Funcionalidades) é um método iterativo e incremental que tem um bom
funcionamento com iterações curtas de até duas semanas. Ele foi criado em 1997
por Jeff De Lucca.
O FDD prega a visibilidade do estado do projeto e, dessa forma, é possível
saber quantas funcionalidades já foram desenvolvidas e quantas ainda restam para
se desenvolver.
2.5.3.1 Fases
O FDD possui duas fases:
Concepção e Planejamento: nessa fase acontece a triagem de
requisitos.
Construção: Aqui temos um detalhamento por funcionalidade. É
Especificado mais o que deve ser feito.
2.5.4 TDD
O Test Driven Design (TDD) é a combinação de duas técnicas de
programação: Test-First Development (TFD) e Refactoring (Refatoração). Antes de
se escrever um código funcional, em qualquer linguagem de programação, deve-se
primeiro escrever um pequeno pedaço de código para testar o resultado.
2.5.4.1 Ciclo de Desenvolvimento do TDD
O ciclo de desenvolvimento do TDD pode ser elaborado conforme discriminado abaixo;
- Red, Green, Refactor. Onde:
Escrevemos um Teste que inicialmente não passa (Red);
Adicionamos uma nova funcionalidade do sistema;
Fazemos o Teste passar (Green);
Refatoramos o código da nova funcionalidade (Refactoring);
Escrevemos o próximo Teste;
Figura 3 – Ciclo de Desenvolvimento do TDD. Fonte: http://alexandregama.files.wordpress.com/2010/11/tdd3.png
REFERÊNCIAS
BREITMAN, Karin Koogam; Sayão, Miriam. Gerência de Requisitos. Mini-Cursos do 20º SBBD e 19º SBES. Outubro, 2005.
FOWLER, Martin. The New Methodology. Artigo publicado em julho de 2003. Disponível em: <http://martinfowler.com/articles/newMethodologyOriginal.html>. Acesso em 24 de outubro de 2010.
GERENCIA de PROJETOS. Disponível em http://gerpro2008.googlecode.com/files/Apostila_GERENCIA_DE_PROJETOS_DE_SOFTWARE.pdf. Acesso em 10/09/2010.
HIGHSMITH, J., Agile Project Management, Creating innovative products, Addison Wesley, 2004.
KERZNER, H. Gestão de Projetos: As Melhores Práticas. Porto Alegre, Bookman, v.2. 2005.
PMBOK - Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK®) Terceira edição 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 EUA.
PMI - Project Management Institute (PMI) (2004) “A Guide to the Project Management Body of Knowledge”, 3a. edição, EUA.
PMTECH. Disponível em http://www.pmtech.com.br/artigos/CMM&PMBOK.pdf. acesso em 14/092010.
PMTECH. Gerenciamento de Projetos de Software. Disponível em <http://www.pmtech.com.br/artigos/Gerenciamento_Projetos_Software.pdf>. Acessado em 12/09/2010.
PRADO, Darci. Maturidade em Gerenciamento de Projetos. Editora INDG-Tecs, 2008.
PRESSMAN, R. S. Engenharia de Software. São Paulo: Makron, 1995.
PRESSMAN, R. S. Engenharia de Software. São Paulo: Makron, 2006.
UFES. Projetos de Software. Disponível em <http://www.inf.ufes.br/~falbo/files/GerenciaProjetosSoftware.pdf>. Acesso em 20/09/2010.
VIEIRA, Marconi Fábio. Gerenciamento de Projetos de Tecnologia da Informação. Rio de Janeiro: Campus, 2003.
SOMMERVILLE, Ian. Engenharia de Software. 6. ed. São Paulo: Addison Wesley, 2003
Manifesto para Desenvolvimento Ágil de Software. Disponível em <http://agilemanifesto.org/iso/ptbr/>. Acesso em 10 de novembro de 2010.
YOURDON, E. Declínio e Queda dos Analistas e dos Programadores. São Paulo. 1995.
KERZNER, H. (2001). Project Management. 7ª. Edição. John Wiley & Sons.
REHMAN, A. (2007). Software Project Management Methodologies/Frameworks Dynamics “A Comparative Approach”. In Proceedings of the IEEE International Conference on Information and Emerging Technologies (ICIET), pp. 1 - 5.