REVISTACIENTIFICAMULTIDISCIPLINARNUCLEODOCONHECIMENTO

Revista Científica Multidisciplinar

Pesquisar nos:
Filter by Categorias
Administração
Administração Naval
Agronomia
Arquitetura
Arte
Biologia
Ciência da Computação
Ciência da Religião
Ciências Aeronáuticas
Ciências Sociais
Comunicação
Contabilidade
Educação
Educação Física
Engenharia Agrícola
Engenharia Ambiental
Engenharia Civil
Engenharia da Computação
Engenharia de Produção
Engenharia Elétrica
Engenharia Mecânica
Engenharia Química
Ética
Filosofia
Física
Gastronomia
Geografia
História
Lei
Letras
Literatura
Marketing
Matemática
Meio Ambiente
Meteorologia
Nutrição
Odontologia
Pedagogia
Psicologia
Química
Saúde
Sem categoria
Sociologia
Tecnologia
Teologia
Turismo
Veterinária
Zootecnia
Pesquisar por:
Selecionar todos
Autores
Palavras-Chave
Comentários
Anexos / Arquivos

Gestão e planejamento de projetos de software com scrum

RC: 28127
328
5/5 - (3 votes)
DOI: ESTE ARTIGO AINDA NÃO POSSUI DOI
SOLICITAR AGORA!

CONTEÚDO

ARTIGO ORIGINAL

ALMEIDA, Hugo Leonardo Nascimento [1]

ALMEIDA, Hugo Leonardo Nascimento. Gestão e planejamento de projetos de software com scrum. Revista Científica Multidisciplinar Núcleo do Conhecimento. Ano 04, Ed. 03, Vol. 09, pp. 114-123. Março de 2019. ISSN: 2448-0959.

RESUMO

Atualmente, Planejamento e Gestão Estratégica são áreas com grande potencial para pesquisas e aplicações práticas em organizações privadas e públicas. Conceitos de gerenciamento vem crescendo bastante e chamando a atenção dos mais variados tipos de profissionais, que visam, por meio de técnicas, métodos e melhoria de processos, alcançar os objetivos de suas organizações. Profissionais da área de Tecnologia da Informação (TI) se utilizam de padrões e metodologias no gerenciamento e planejamento dos seus respectivos projetos. Equipes menores e com tempo reduzido para desenvolver um produto optam por metodologias ágeis em meio ao planejamento como forma de gerir o projeto, e, dentre as metodologias existentes, o Scrum é uma das mais difundidas em Engenharia de Software. O objetivo do artigo é apresentar a metodologia ágil Scrum indicando as possíveis vantagens na adoção desta metodologia nos projetos de TI. A ideia é trazer ao leitor conceitos básicos do gerenciamento de projetos conduzidos por SCRUM, evidenciando relações diretas entre planejamento, gestão estratégica e projetos de TI.

Palavras-chave: Scrum, Gestão. Projeto, Software, Ágil.

1. INTRODUÇÃO

O interesse nas áreas de planejamento gestão estratégica e gestão de projetos vem crescendo e chamando a atenção de diversos profissionais e estudiosos. Devido os resultados visíveis nas empresas, que aderem as técnicas desenvolvidas na área, os estudos nas áreas se intensificam a cada dia. E é com esse interesse que este trabalho surgiu, sendo direcionado na metodologia ágil Scrum, que se apresenta como uma metodologia moderna, vantajosa e bastante difundida nas diferentes áreas de gestão. A oportunidade de poder colaborar com estudos na área, citando e estudando as técnicas desenvolvidas na metodologia ágil escolhida, se tornou como um desafio e coincidiu com o interesse do autor nesta área. Surgiu assim a oportunidade de desenvolver um artigo que apresente conceitos correlatos ao framework Scrum.

2. SCRUM

Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum. As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog. (DesenvolvimentoAgil, 2016)

Ainda conforme o grupo DesenvolvimentoAgil, a cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia. Ao final de cada Sprint, a equipe do projeto apresenta as funcionalidades implementadas para os envolvidos do projeto em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint.

É perceptível a enorme quantidade de conceitos básicos relacionados ao framework Scrum, tais conceitos são necessários para um entendimento básico do funcionamento desta ferramenta e consequentemente para um entendimento melhor de como funciona o gerenciamento de projetos de software que, muitas vezes por sua própria essência, são geridos por meios de técnicas ágeis.

Scrum não só reforçou o interesse em gerenciamento de projetos de software, mas também desafiou as ideias convencionais sobre essa gestão. Scrum é voltado para instituições de gerenciamento de projetos, onde é difícil planejar o futuro com mecanismos de controle de processos empíricos, como loops de feedback, onde constituem o elemento central do desenvolvimento do produto em comparação com a gestão de comando e controle tradicionais orientado. Ela representa uma abordagem radicalmente nova para o planejamento e gerenciamento de projetos de software, trazendo poder de decisão ao nível das propriedades operação e certezas. Scrum reduz defeitos e torna o processo de desenvolvimento mais eficiente, bem como reduzindo os custos de manutenção a longo prazo.” (BRASPORT LIVROS E MULTIMIDIAS LTDA, 2016, p.174).

Segundo Kniberg (2007) o melhor e o pior do Scrum é que você é forçado a adaptar o processo para sua situação específica. Logo, mesmo com tantos conceitos e possíveis regras que o Scrum pode vir a ter ou até mesmo um projeto venha a ter, percebemos que a ferramenta citada é flexível e viabiliza mais flexibilidade para o projeto no qual está inserida também.

2.1 METODOLOGIA

“A metodologia da pesquisa num planejamento deve ser entendida como o conjunto detalhado e sequencial de métodos e técnicas científicas a serem executados ao longo da pesquisa, de tal modo que se consiga atingir os objetivos inicialmente propostos e, ao mesmo tempo, atender aos critérios de menor custo, maior rapidez, maior eficácia e mais confiabilidade de informação.” (BARRETO; HONORATO, 1998).

O presente trabalho se identifica como uma pesquisa qualitativa de cunho bibliográfico, pois foi desenvolvida com base em materiais anteriormente elaborados, constituído principalmente por livros, artigos científicos (Gil, 2008) e sites disponíveis na Web. Conforme Marconi e Lakatos (1992), a pesquisa bibliográfica é o levantamento de toda a bibliografia já publicada, em forma de livros, revistas, publicações avulsas e imprensa escrita. A finalidade de uma pesquisa bibliográfica é levar o pesquisador diretamente até as informações disponíveis em todo o material escrito sobre um determinado assunto, auxiliando o cientista na análise de suas pesquisas ou na manipulação de suas informações.

O trabalho se trata de uma pesquisa qualitativa que preocupa-se com aspectos da realidade que não podem ser quantificados, centrando-se na compreensão e explicação da dinâmica das relações sociais. Para Minayo (2004), a pesquisa qualitativa trabalha com o universo de significados, motivos, aspirações, crenças, valores e atitudes, o que corresponde a um espaço mais profundo das relações, dos processos e dos fenômenos que não podem ser reduzidos à operacionalizações de variáveis.

O termo metodologia pode indicar o referencial teórico, ou quadro de referência. Trata-se da linha filosófica, religiosa, política e ideológica de um autor, pesquisador ou estudioso (RAMPAZZO; LINO, 2005). Diante da definição do termo fica evidente a preocupação na escolha da bibliografia no que diz respeito ao tema da monografia.

Pesquisa-se portanto publicações referentes a Engenharia de Software, Métodos Ágeis, o Scrum propriamente dito, Gestão de Projetos, Planejamento, Gestão Estratégica e conceitos relacionados às áreas citadas.

2.2 ENGENHARIA DE SOFTWARE

Uma das fases mais importantes na área de desenvolvimento de sistemas de pequeno, médio e grande porte, a engenharia de software está voltada à especificação, ao desenvolvimento e a manutenção dos mesmos. Os caminhos que o time responsável por desenvolver o projeto irá seguir são definidos nessa fase baseado nas especificações concedidas pelo cliente. Para SOMMERVILLE (1992) a engenharia de software é definida como a área interdisciplinar que engloba vertentes tecnológica e gerencial visando a abordar de modo sistemático (modular), os processos de construção, implantação e manutenção de produtos de software com qualidade assegurada por construção segundo cronogramas e custos previamente definidos.

Ainda segundo SOMMERVILLE (1992) a engenharia de software envolve questões técnicas e não-técnicas, tais como a especificação do conhecimento, técnicas de projeto e implementação, conhecimentos dos fatores humanos pelo engenheiro de software e ainda, gestão de projetos.

Para MAFFEO (1992) a engenharia de software é a área interdisciplinar que engloba vertentes tecnológica e gerencial visando a abordar de modo sistemático (modular), os processos de construção, implantação e manutenção de produtos de software com qualidade assegurada por construção segundo cronogramas e custos previamente definidos.

Para PAULA FILHO (2001) a engenharia de software é conexa, porém distinta, e envolve múltiplas variáveis, tais como arte, atendimento das necessidades humanas, 11 conhecimentos científicos, conhecimentos empíricos, habilidades específicas, recursos naturais, formas adequadas, dispositivos, estruturas e processos. Não deve ser confundida com a ciência e fornece problemas para seus estudos.

Segundo CARVALHO e CHIOSSI (2001) a engenharia de software é uma disciplina que reúne métodos e ferramentas a serem utilizados, desde a percepção do problema até o momento que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software.

Podemos encontrar várias outras definições de engenharia de software que tendem frequentemente a omitir a parte gerencial do conceito concentrando-se apenas nos aspectos tecnológicos do contexto. Os aspectos gerenciais do desenvolvimento de software devem receber uma atenção cada vez maior nessa disciplina (PRESSMAN, 2011).

Sendo assim, a engenharia de software pode ser caracterizada por um desenvolvimento prático de software, ordenado e medido para produzir sistemas satisfatórios aos usuários e que respeitem prazos e orçamentos (PETERS; PEDRYCZ, 2001).

Atualmente, com o intenso uso dos métodos ágeis para auxiliar no desenvolvimento, existem alguns confrontos dentro da engenharia de software que chegam a criar algumas discussões no projeto de sistemas. Elaborar uma documentação detalhada e extensa pode ajudar no sucesso de um projeto, embora seja desgastante e tome um tempo significativo nesta etapa.

Empresas constantemente sofrem rotatividade e os conhecimentos e especificações dos projetos não devem ser levados embora junto com pessoas deixando novos membros sem norte para começar a entender e trabalhar nos objetivos do projeto. Por outro lado, custos relacionados a correções de defeitos podem aumentar bastante de acordo com a fase em que são detectados. Do lado ágil, documentação abrangente não é o foco do time, é preferível software em funcionamento, o que vem a satisfazer as necessidades do cliente em um menor prazo.

Working software over comprehensive documentation” (BECK, Kent et al. 2001). Esta frase define bem qual o verdadeiro foco da engenharia de software que as metodologias ágeis tanto dão ênfase.

Contudo, o foco no funcionamento não quer dizer que a engenharia de software voltada para os métodos ágeis seja totalmente isenta de documentação, existem artefatos que servem como documentos e que mantém a equipe ciente do que está sendo implementado.

Outros elementos têm fundamental importância na engenharia de software, o uso de ferramentas proporciona um apoio automatizado ou semi-automatizado aos métodos, que por sua vez proporcionam os detalhes de “como fazer” para construir o software e envolvem um conjunto de tarefas que incluem: planejamento e estimativa de projeto, análise de requisitos de software, projeto de estrutura de dados, codificação, testes, manutenção, entre outros.

De modo geral, considera-se que os objetivos primários da Engenharia de Software são o aprimoramento da qualidade dos produtos de software e o aumento da produtividade dos engenheiros de software, além do atendimento aos requisitos de eficácia e eficiência, ou seja, efetividade. Pode-se dizer que a Engenharia de Software é uma metodologia para desenvolvimento de soluções em software, ou seja, um roteiro que pode utilizar diversas técnicas. Uma sequência de passos preestabelecidos que permite optar e variar de técnicas e ferramentas nas suas diversas fases.

2.3 MÉTODOS ÁGEIS

O desenvolvimento de software precisa ser reconhecido como um processo imprevisível e complicado. Reconhecer que um software nunca foi construído da mesma forma, com a mesma equipe, sob as mesmas circunstâncias antes é a grande mudança do pensamento tradicional de desenvolvimento de software. Mas, o mais importante é reconhecê-lo como um processo empírico: que aceita a imprevisibilidade e tem mecanismos de ação corretiva (LIBARDI; BARBOSA, 2010).

Uma característica das metodologias ágeis é que elas são adaptativas ao invés de serem preditivas. Dessa forma, elas se adaptam a novos fatores durante o desenvolvimento do projeto, ao invés de tentar analisar previamente tudo o que pode ou não acontecer no decorrer do desenvolvimento. Essa análise prévia é sempre difícil e apresenta alto custo, além de se tornar um problema quando for necessário fazer alterações nos planejamentos. O problema não é a mudança em si, mesmo porque ela ocorrerá de qualquer forma. O problema é como receber, avaliar e responder às mudanças. Numa metodologia clássica pode acontecer de que um software seja construído por inteiro e depois se descubra que ele não serve mais para o propósito que foi desenvolvido porque as regras mudaram e as adaptações tornem-se complexa demais para o desenvolvimento (LIBARDI; BARBOSA, 2010).

As metodologias ágeis trabalham com constantes feedbacks, o que permite adaptar rapidamente a eventuais mudanças nos requisitos. Alterações essas que são, muitas vezes, críticas nas metodologias tradicionais, que não apresentam meios de se adaptar rapidamente às mudanças. Um outro ponto positivo das metodologias ágeis são as entregas constantes de partes operacionais do software. Desta forma, o cliente não precisa esperar muito para ver o software funcionando e notar que não era bem isso que ele esperava (SOARES 2004).

A integração e o teste contínuo também possibilitam a melhora na qualidade do software. Não é mais necessário existir uma fase de integração de módulos, uma vez que eles são continuamente integrados e eventuais problemas são resolvidos constantemente (LIBARDI; BARBOSA, 2010).

Segundo o site da BRQ, as metodologias ágeis têm o objetivo de acelerar o desenvolvimento do software visando a melhoria contínua do processo, gerando benefícios como o aumento da comunicação e interação da equipe, organização diária para o alcance da meta definida, evitar falhas na elaboração, respostas rápidas às mudanças e aumento significativo da produtividade.

Embora os métodos ágeis tenham diferenças entre suas próprias práticas, eles compartilham inúmeras características em comum, incluindo o desenvolvimento iterativo, o foco na comunicação interativa e na redução do esforço empregado em artefatos intermediários (Cohen et al., 2004).

A aplicabilidade dos métodos ágeis em geral pode ser examinada de múltiplas perspectivas. Da perspectiva do produto, métodos ágeis são mais adequados quando os requisitos estão emergindo e mudando rapidamente, embora não exista um consenso completo neste ponto (Cohen et al., 2004).

De uma perspectiva organizacional, a aplicabilidade pode ser expressa examinando três dimensões chaves da organização: cultura, pessoal e comunicação. Em relação a estas áreas inúmeros fatores chave do sucesso podem ser identificados (Cohen et al., 2004):

      • A cultura da organização deve apoiar a negociação.
      • As pessoas devem ser confiantes.
      • Poucas pessoas, mas competentes.
      • A organização deve promover as decisões que os desenvolvedores tomam.
      • A Organização necessita ter um ambiente que facilite a rápida comunicação entre os membros.
      • O fator mais importante é provavelmente o tamanho do projeto.

2.4 PRÁTICAS DO SCRUM

Conforme especificado na introdução, a metodologia ágil Scrum abrange vários conceitos, o site do grupo DesenvolvimentoAgil destrinchou os conceitos básicos de forma bem simples e esclarecedora:

A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.

Os Daily Scrums normalmente são realizadas no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho.

Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas também podem estar presentes, mas só poderão escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informações sobre o estado do projeto.

O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

Ainda sobre os conceitos abordados no site do grupo DesenvolvimentoAgil temos a funcionalidade do Product Owner, que é a pessoa que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings. O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final de um Sprint (iteração). Estes itens transformam-se no Sprint Backlog.

Em um projeto Scrum, a equipe monitora seu progresso em relação a um plano atualizando um Release Burndown Chart ao final de cada Sprint (iteração). O eixo horizontal de um Release Burndown Chart mostra os Sprints; o eixo vertical mostra a quantidade de trabalho que ainda precisa ser feita no início de cada Sprint. O trabalho que ainda resta pode ser mostrado na unidade preferencial da equipe: story points, dias ideais, team days e assim por diante.

O Scrum Master procura assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint. O Scrum Master atua como facilitador do Daily Scrum e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões.

Já o Scrum Team é a equipe de desenvolvimento. Nela, não existe necessariamente uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint.

O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades.

O Sprint Planning Meeting é uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente. Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog.

O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.

O grupo Desenvolvimento Agil trás ainda mais conceitos de práticas do Scrum: ao final de cada Sprint é feito um Sprint Review Meeting. Durante esta reunião, o Scrum Team mostra o que foi alcançado durante o Sprint.

Os participantes do Sprint Review tipicamente incluem o Product Owner, o Scrum Team, o Scrum Master, gerência, clientes e engenheiros de outros projetos.

Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint, mas o importante mesmo é que a equipe atinja o objetivo geral do Sprint.

3. CONSIDERAÇÕES FINAIS

Este trabalho teve um objetivo de expor conceitos básicos relacionados ás práticas da metodologia Scrum. O modelo adotado pelo autor se caracterizou como uma pesquisa qualitativa de cunho bibliográfico. Inicialmente, foram introduzidos conceitos e definições diretamente associados ao Scrum, bem como informações importantes sobre as vantagens de sua utilização. Em seguida, foi explicada a forma como o trabalho se desenvolveu através da metodologia de trabalho. Os conceitos mais abrangentes de áreas da tecnologia da informação como Engenharia de Software e Métodos Ágeis foram explorados no artigo como embasamento para se entender melhor o assunto principal. Desta maneira o leitor foi preparado para entender melhor sobre o Scrum percebendo sua importância e enfim verificar as práticas comuns da metodologia ágil que mais cresce no mundo. Foi apresentado detalhes básicos do SCRUM e a junção dessas informações constituem os resultados deste trabalho.

A principal contribuição deste trabalho é a explicação do Scrum e a demonstração de sua eficácia através da literatura, mas também pode ser citada a descrição dos referenciais teóricos que contribuíram no processo de pesquisa como mais uma contribuição.

REFERÊNCIAS

BARRETO, Alcyrus Vieira Pinto; HONORATO, Cezar de Freitas. Manual de sobrevivência na selva acadêmica. Rio de Janeiro: Objeto Direto, 1998.

BECK, Kent et al. Manifesto para Desenvolvimento Ágil de Software. Disponível em:

http://www.agilemanifesto.org/iso/ptbr/manifesto.html. Acesso em 12 set. 2016.

BRASPORT LIVROS E MULTIMIDIAS LTDA. 40 + 16 Ferramentas e Técnicas de Gerenciamento. 6ª edição. Rio de Janeiro, 2016.

BRQ. Disponível em: http://www.brq.com/metodologias-ageis/. Acesso em 12 set. 2016

CARVALHO, A.; CHIOSSI, T. Introdução à Engenharia de Software. São Paulo: Unicamp, 2001.

COHEN, D., LINDVALL, M., & COSTA, P. An introduction to agile methods. InAdvances in Computers. Elsevier Science (p. 1-66). New York, 2004.

DesenvolvimentoAgil. O que é Scrum. Disponível em: http://www.desenvolvimentoagil.com.br/scrum/. Acesso em 08 set. 2016.

FILHO, WILSON DE PÁDUA PAULA. Engenharia de Software (Fundamentos, métodos e padrões). 3º edição, 2005.

GIL, Antonio Carlos. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, 2008.

HENRIK KNIBERG. Scrum e XP direto das trincheiras. Como nós fazemos Scrum. C4Media Inc, 2007.

LIBARDI, PAULA L. O.; BARBOSA VLADIMIR. Métodos Ágeis. Campinas, São Paulo, 2010.

MAFFEO, BRUNO. Engenharia de Software e Especificação de Sistemas. Rio de Janeiro: Campus, 1992.

MARCONI, Marina de Andrade; LAKATOS, Eva Maria. Metodologia do trabalho científico. São Paulo: Editora Atlas, 1992. 4a ed. p.43 e 44.

MINAYO, Maria Cecília de Souza(ORG.). Pesquisa social : teoria, método e criatividade.  23.ed. Petrópolis: Vozes, 2004.

PETERS, JAMES; PEDRYCZ, WITOLD. Engenharia de Software. 3ª Ed., 2001.

PRESSMAN, R. Engenharia de Software: Uma Abordagem Profissional. 7ª Ed., São Paulo: McGraw-Hill, 2011.

RAMPAZZO, Lino. O conhecimento. In. Metodologia científica. Para os alunos do curso de graduação e de pós-graduação. São Paulo. Edições Loyola, 2005.

SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. 2004.

SOMMERVILLE, IAN F. Software Engineering. 1992.

[1] Mestre em Design, Especialista em Planejamento e Gestão Estratégica, Bacharel em Ciência da Computação, Técnico em Informática, Pesquisador Industrial.

Enviado: Abril, 2018.

Aprovado: Março, 2019.

5/5 - (3 votes)
Hugo Leonardo Nascimento Almeida

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

POXA QUE TRISTE!😥

Este Artigo ainda não possui registro DOI, sem ele não podemos calcular as Citações!

SOLICITAR REGISTRO
Pesquisar por categoria…
Este anúncio ajuda a manter a Educação gratuita