Desenvolvimento gil de software

Origem: Wikipdia, a enciclopdia livre.

Desenvolvimento gil de software (do ingls Agile software development) ou Mtodo gil um
conjunto de metodologias de desenvolvimento de software. O desenvolvimento gil, tal como
qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de
engenharia de software.

ndice
1 Introduo

2 Valores

3 Princpios

4 Histria

5 Comparaes com outros mtodos

o 5.1 Comparao com o desenvolvimento iterativo

o 5.2 Comparao com o modelo em cascata

o 5.3 Comparao com a "codificao cowboy"

6 Aplicabilidade dos mtodos geis

7 Adaptabilidade dos mtodos geis

8 Mtodos geis e o gerenciamento de projeto

9 Metodologia

10 Processo

11 Crticas

12 Referncias

13 Futuras leituras
 14 Ligaes externas

Introduo
Existem inmeros frameworks de processos para desenvolvimento de software. A maioria dos
mtodos geis tenta minimizar o risco pelo desenvolvimento do software em curtos perodos,
chamados de iterao, os quais gastam tipicamente menos de uma semana a at quatro. Cada
iterao como um projeto de software em miniatura de seu prprio, e inclui todas as tarefas
necessrias para implantar o mini-incremento da nova funcionalidade: planejamento, anlise de
requisitos, projeto, codificao, teste e documentao. Enquanto em um processo convencional,
cada iterao no est necessariamente focada em adicionar um novo conjunto significativo de
funcionalidades, um projeto de software gil busca a capacidade de implantar uma nova verso
do software ao fim de cada iterao, etapa a qual a equipe responsvel reavalia as prioridades do
projeto.

Mtodos geis enfatizam comunicaes em tempo real, preferencialmente cara a cara, a

documentos escritos. A maioria dos componentes de um grupo gil deve estar agrupada em uma
sala. Isso inclui todas as pessoas necessrias para terminar o software: no mnimo, os
programadores e seus clientes (clientes so as pessoas que definem o produto, eles podem ser os
gerentes, analistas de negcio, ou realmente os clientes). Nesta sala devem tambm se encontrar
os testadores, projectistas de iterao, redactores tcnicos e gerentes.

Mtodos geis tambm enfatizam trabalho no software como uma medida primria de progresso.
Combinado com a comunicao cara-a-cara, mtodos geis produzem pouca documentao em
relao a outros mtodos, sendo este um dos pontos que podem ser considerados negativos.
recomendada a produo de documentao que realmente ser til.

Valores
Segundo a pgina Agile Manifest[1] os valores relacionados ao Desenvolvimento gil de software
so:

Indivduos e interaes mais que processos e ferramentas;

Software funcional mais que documentao abrangente;

Colaborao do cliente mais que negociao de contratos;

Responder a mudanas mais que seguir um plano

Ou seja, o item esquerda sempre tem maior importncia do que o tem direita

Princpios
Os princpios do desenvolvimento gil[2] valorizam

Garantir a satisfao do consumidor entregando rapidamente e continuamente software

funcionais;

At mesmo mudanas tardias de escopo no projecto so bem-vindas para garantir a

vantagem competitiva do cliente;

Software funcionais so entregues frequentemente (semanas, ao invs de meses);

Cooperao diria entre pessoas que entendem do 'negcio' e desenvolvedores;

Projetos surgem atravs de indivduos motivados, entre os quais existe relao de

confiana.

A maneira mais eficiente e efetiva de transmitir informaes conversas cara a cara;

Software funcionais so a principal medida de progresso do projeto;

Processos geis promovem desenvolvimento sustentvel. Os patrocinadores,

desenvolvedores e usurios devem ser capazes para manter um ritmo constante
indefinidamente.

Design do software deve prezar pela excelncia tcnica;

Simplicidade essencial;

As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas;

Em intervalos regulares, a equipe reflete sobre como para tornar-se mais eficaz, ento
sintoniza e ajusta seu comportamento apropriadamente.

Histria
As definies modernas de desenvolvimento de software gil evoluram a partir da metade de
1990 como parte de uma reao contra mtodos "pesados", caracterizados por uma pesada
regulamentao, regimentao e micro gerenciamento usado o modelo em cascata para
desenvolvimento. O processo originou-se da viso de que o modelo em cascata era burocrtico,
lento e contraditrio a forma usual com que os engenheiros de software sempre realizaram
trabalho com eficincia.

Uma viso que levou ao desenvolvimento de mtodos geis e iterativos era retorno a prtica de
desenvolvimento vistas nos primrdios da histria do desenvolvimento de software [1].
Inicialmente, mtodos geis eram conhecidos como mtodos leves. Em 2001, membros
proeminentes da comunidade se reuniram em Snowbird e adotaram o nome mtodos geis, tendo
publicado o Manifesto gil, documento que rene os princpios e prticas desta metodologia de
desenvolvimento. Mais tarde, algumas pessoas formaram a Agile Alliance, uma organizao no
lucrativa que promove o desenvolvimento gil.

Os mtodos geis iniciaiscriado a priore em 2000 incluam Scrum (1986), Crystal Clear,
Programao extrema (1996), Adaptive Software Development, Feature Driven Development,
and Dynamic Systems Development Method (1995).

Comparaes com outros mtodos

Mtodos geis so algumas vezes caracterizados como o oposto de metodologias guiadas pelo
planejamento ou disciplinadas. Uma distino mais acurada dizer que os mtodos existem em
um contnuo do adaptativo at o preditivo.[3] Mtodos geis existem do lado adaptativo deste
contnuo. Mtodos adaptativos buscam a adaptao rpida a mudanas da realidade. Quando uma
necessidade de um projeto muda, uma equipe adaptativa mudar tambm. Um time adaptativo
ter dificuldade em descrever o que ir acontecer no futuro. O que acontecer em uma data
futura um item de difcil predio para um mtodo adaptativo. Uma equipe adaptativa pode
relatar quais tarefas se iniciaro na prxima semana. Quando perguntado acerca de uma
implantao que ocorrer daqui a seis meses, uma equipe adaptativa deve ser capaz somente de
relatar a instruo de misso para a implantao, ou uma expectativa de valor versus custo.

Mtodos preditivos, em contraste, colocam o planejamento do futuro em detalhe. Uma equipe

preditiva pode reportar exatamente quais aspectos e tarefas esto planejados para toda a linha do
processo de desenvolvimento. Elas porm tem dificuldades de mudar de direo. O plano
tipicamente otimizado para o objetivo original e mudanas de direo podem causar a perda de
todo o trabalho e determinar que seja feito tudo novamente. Equipes preditivas freqentemente
instituem um comit de controle de mudana para assegurar que somente as mudanas mais
importantes sejam consideradas.

Mtodos geis tm muito em comum com tcnicas de Desenvolvimento rpido de aplicao de

1980 como exposto por James Martin e outros.

Comparao com o desenvolvimento iterativo

A maioria dos mtodos geis compartilha a nfase no Desenvolvimento iterativo e incremental

para a construo de verses implantadas do software em curtos perodos de tempo. Mtodos
geis diferem dos mtodos iterativos porque seus perodos de tempo so medidos em semanas,
ao invs de meses, e a realizao efetuada de uma maneira altamente colaborativa. estendendo-
se a tudo.

Comparao com o modelo em cascata

O desenvolvimento gil tem pouco em comum com o modelo em cascata. Na viso de alguns
este modelo desacreditado, apesar de ser um modelo de uso comum. O modelo em cascata
uma das metodologias com maior nfase no planejamento, seguindo seus passos atravs da
captura dos requisitos, anlise, projeto, codificao e testes em uma seqncia pr-planejada e
restrita. O progresso geralmente medido em termos de entrega de artefatosespecificao de
requisitos, documentos de projeto, planos de teste, reviso do cdigo, e outros. O modelo em
cascata resulta em uma substancial integrao e esforo de teste para alcanar o fim do ciclo de
vida, um perodo que tipicamente se estende por vrios meses ou anos. O tamanho e dificuldade
deste esforo de integrao e teste uma das causas das falhas do projeto em cascata. Mtodos
geis, pelo contrrio, produzem um desenvolvimento completo e teste de aspectos (mas um
pequeno subconjunto do todo) num perodo de poucas semanas ou meses. Enfatiza a obteno de
pequenos pedaos de funcionalidades executveis para agregar valor ao negcio cedo, e
continuamente agregar novas funcionalidades atravs do ciclo de vida do projeto.

Algumas equipes geis usam o modelo em cascata em pequena escala, repetindo o ciclo de
cascata inteiro em cada iterao. Outras equipes, mais especificamente as equipes de
Programao extrema, trabalham com atividades simultaneamente.

Comparao com a "codificao cowboy"

A codificao cowboy, tambm chamada de Modelo Balbrdia, a ausncia de metodologias de

desenvolvimento de Software: os membros da equipe fazem o que eles sentem que correto.
Como os desenvolvedores que utilizam mtodos geis freqentemente reavaliam os planos,
enfatizam a comunicao face a face e fazem o uso relativamente esparso de documentos,
ocasionalmente levam as pessoas a confundirem isto com codificao cowboy. Equipes geis,
contudo, seguem o processo definido (e freqentemente de forma disciplinada e rigorosa).

Como em todas as metodologias, o conhecimento e a experincia dos usurios definem o grau de

sucesso e/ou fracasso de cada atividade. Os controles mais rgidos e sistematizados aplicados em
um processo implicam altos nveis de responsabilidade para os usurios. A degradao de
procedimentos bem-intencionados e organizados pode levar as atividades a serem caracterizadas
como codificao cowboy.

Aplicabilidade dos mtodos geis

Embora os mtodos geis apresentem diferenas entre suas prticas, eles compartilham inmeras
caractersticas em comum, incluindo o desenvolvimento iterativo, e um foco na comunicao
interativa e na reduo do esforo empregado em artefatos intermedirios. (Cohen et al., 2004)[4]
A aplicabilidade dos mtodos geis em geral pode ser examinada de mltiplas perspectivas. Da
perspectiva do produto, mtodos geis so mais adequados quando os requisitos esto emergindo
e mudando rapidamente, embora no exista um consenso completo neste ponto (Cohen et al.,
2004).[4] De uma perspectiva organizacional, a aplicabilidade pode ser expressa examinando trs
dimenses chaves da organizao: cultura, pessoal e comunicao. Em relao a estas reas
inmeros fatores chave do sucesso podem ser identificados (Cohen et al., 2004):[4]

A cultura da organizao deve apoiar a negociao.

 As pessoas devem ser confiantes.

Poucas pessoas, mas competentes.

A organizao deve promover as decises que os desenvolvedores tomam.

A Organizao necessita ter um ambiente que facilite a rpida comunicao entre os

membros.

O fator mais importante provavelmente o tamanho do projeto (Cohen et al., 2004)..[4] Com o
aumento do tamanho, a comunicao face a face se torna mais difcil. Portanto, mtodos geis
so mais adequados para projetos com pequenos times, com no mximo de 20 a 40 pessoas.

De forma a determinar a aplicabilidade de mtodos geis especficos, uma anlise mais

sofisticada necessria. O mtodo dinmico para o desenvolvimento de sistemas, por exemplo,
prov o denominado 'filtro de aplicabilidade' para este propsito. Tambm, a famlia de mtodos
Crystal prov uma caracterizao de quando selecionar o mtodo para um projeto. A seleo
baseada no tamanho do projeto, criticidade e prioridade. Contudo, outros mtodos geis no
fornecem um instrumento explcito para definir sua aplicabilidade a um projeto.

Alguns mtodos geis, como DSDM e Feature Driven Development, afirmam se aplicar a
qualquer projeto de desenvolvimento gil, sem importar suas caractersticas (Abrahamsonn et al.,
2003).[5]

A comparao dos mtodos geis ir revelar que eles suportam diferentes fases de um ciclo de
vida do software em diferentes nveis. Estas caractersticas individuais dos mtodos geis podem
ser usadas como um critrio de seleo de sua aplicabilidade.

Desenvolvimentos geis vm sendo amplamente documentados (ver Experincias relatadas,

abaixo, como tambm em Beck,[6] e Boehm & Turner[7] ) como funcionando bem para equipes
pequenas (< 10 desenvolvedores). O desenvolvimento gil particularmente adequado para
equipes que tm que lidar com mudanas rpidas ou imprevisveis nos requisitos.

A aplicabilidade do desenvolvimento gil para os seguintes cenrios ainda uma questo aberta:

esforos de desenvolvimento em larga escala (> 20 desenvolvedores), embora estratgias

para maiores escalas tenham sido descritas.[8]

esforos de desenvolvimento distribudo (equipes no co-alocadas). Estas estratgias tem

sido descritas em Bridging the Distance[9] e Using an Agile Software Process with
Offshore Development[10]

esforos crticos de misso e vida.

Companhias com uma cultura de comando e controle.

Barry Boehm e Richard Turner sugeriram que anlise de risco pode ser usada para escolher entre
mtodos adaptativos ("geis") e preditivos ("dirigidos pelo planejamento").[7] Os autores sugerem
que cada lado deste contnuo possui seu ambiente ideal"

Ambiente ideal para o desenvolvimento gil:

Baixa criticidade

Desenvolvedores senior

Mudanas freqente de requisitos

Pequeno nmero de desenvolvedores

Cultura que tem sucesso no caos.

Ambiente ideal para o desenvolvimento direcionado ao planejamento:

Alta criticidade

Desenvolvedores Junior

Baixa mudana nos requisitos

Grande nmero de desenvolvedores

Cultura que procura a ordem.

Adaptabilidade dos mtodos geis

Um mtodo deve ser bastante flexvel para permitir ajustes durante a execuo do projeto. H
trs problemas chaves relacionados ao tpico de adaptao dos mtodos geis: a aplicabilidade
dos mtodos geis (no geral e no particular), e finalmente, o suporte ao gerenciamento de
projeto.

Mtodos geis e o gerenciamento de projeto

Os mtodos geis diferem largamente no que diz respeito a forma de serem gerenciados. Alguns
mtodos so suplementados com guias para direcionar o gerenciamento do projeto, mas nem
todos so aplicveis.[5]

PRINCE2 tem sido considerado como um sistema de gerenciamento de projeto complementar

e adequado.[11]
Uma caracterstica comum dos processos geis a capacidade de funcionar em ambientes muito
exigentes que tem um grande nmero de incertezas e flutuaes (mudanas) que podem vir de
vrias fontes como: equipe em processo de formao que ainda no trabalhou junto em outros
projetos, requisitos volteis, baixo conhecimento do domnio de negcio pela equipe, adoo de
novas tecnologias, novas ferramentas, mudanas muito bruscas e rpidas no ambiente de
negcios das empresas: novos concorrentes, novos produtos, novos modelos de negcio.

Sistemas de gerenciamento de projetos lineares e prescritivos, neste tipo de ambiente, falham em

oferecer as caractersticas necessrias para responder de forma gil as mudanas requeridas. Sua
adoo pode incrementar desnecessariamente os riscos, o custo, o prazo e baixar a qualidade do
produto gerado, desgastando a equipe e todos os envolvidos no processo.

A abordagem Scrum, para gesto de projetos geis, leva em considerao planejamento no

linear, porm de maneira mais exaustiva e est focada em agregar valor para o cliente e em
gerenciar os riscos, fornecendo um ambiente seguro. Pode ser utilizada na gesto do projeto
aliada a uma metodologia de desenvolvimento como Programao Extrema, FDD, OpenUP,
DSDM, Crystal ou outras.

Metodologia
Programao extrema

Processo
Scrum

Albert Joseph ; Ercilia Chilaule ; Francelino Itc(I2cv)

Feature Driven Development

DSDM

Adaptive Software Development

Crystal

Pragmatic Programming

Test Driven Development (em portugus)

Crticas
O mtodo de desenvolvimento gil algumas vezes criticado como codificao cowboy. O incio
da Programao extrema soava como controverso e dogmtico, tal como a programao por
pares e o projeto contnuo, tem sido alvo particular de crticos, tais como McBreen[12] e Boehm e
Turner.[7] Contudo, muitas destas crticas tm sido vistas pelos defensores dos mtodos geis
como mal entendidos a respeito do desenvolvimento gil.[13]

Em particular, a Programao extrema revista e criticada por Matt Stephens' Extreme

Programming Refactored.[14]

As crticas incluem

falta de estrutura e documentao necessrias

somente trabalhar com desenvolvedores de nvel snior

incorpora de forma insuficiente o projeto de software

requer a adoo de muita mudana cultural

poder levar a maiores dificuldades nas negociaes contratuais

Referncias
1.

"Manifesto for Agile Software Development". www.agilemanifesto.org. Consultado em 2015-

10-23.
"Principles behind the Agile Manifesto". www.agilemanifesto.org. Consultado em 2015-
10-23.
B. Boehm (2004). Balancing Agility and Discipline: A Guide for the Perplexed 2 ed.
Addison-Wesley [S.l.] ISBN 0-321-18612-5. Parmetro desconhecido |Pginas= ignorado (|
pginas=) (Ajuda)
Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. In
Advances in Computers (pp. 1-66). New York: Elsevier Science.
Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on
Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-254 Erro de citao:
Invalid <ref> tag; name "Abrahamsson2003" defined multiple times with different content
K. Beck (1999). Extreme Programming Explained: Embrace Change Addison-Wesley
[S.l.] ISBN 0-321-27865-8. Parmetro desconhecido |Pginas= ignorado (|pginas=) (Ajuda)
B. Boehm (2004). Balancing Agility and Discipline: A Guide for the Perplexed Addison-
Wesley [S.l.] ISBN 0-321-18612-5. Parmetro desconhecido |Pginas= ignorado (|pginas=)
(Ajuda)
"Supersize Me".
"Bridging the Distance".
"Using an Agile Software Process with Offshore Development".
Agile Alliance at http://agilealliancebeta.org/article/file/904/file.pdf:
 P. McBreen (2003). Addison-Wesley [S.l.] ISBN 0-201-84457-5. Parmetro desconhecido
|Titulo= ignorado (|titulo=) (Ajuda); Falta o |titulo= (Ajuda)
"sdmagazine".

1 "Extreme Programming Refactored".

Futuras leituras
Fowler, Martin. Is Design Dead?. Appeared in Extreme Programming Explained, G.
Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001.

Riehle, Dirk. A Comparison of the Value Systems of Adaptive Software Development and
Extreme Programming: How Methodologies May Learn From Each Other. Appeared in
Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley,
Boston. 2001.

Tomek, Ivan. What I Learned Teaching XP.

http://www.whysmalltalk.com/articles/tomek/teachingxp.htm

M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case Against XP.

Apress L.P., Berkeley, California. 2003. (ISBN 1-59059-096-1)

D. Rosenberg, M. Stephens. Agile Development with ICONIX Process. Apress L.P.,

Berkeley, California. 2005. (ISBN 1-59059-464-9)

Beck, et. al., Manifesto for Agile Software Development. [2]

Larman, Craig and Basili, Victor R. Iterative and Incremental Development:A Brief
History IEEE Computer, June 2003

Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on
Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-254.

Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software
Development Methods: Review and Analysis. VTT Publications 478.

Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004). An Agile Information
Systems Development Method in use. Turk J Elec Engin, 12(2), 127-138

Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. (2005). On the Adaptation of
An Agile Information Systems Development Method. Journal of Database Management
Special issue on Agile Analysis, Design, and Implementation, 16(4), 20-24
 Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. In
Advances in Computers (pp. 166). New York: Elsevier Science.

Karlstrom, D., & Runeson P. (2005). Combining agile methods with stage-gate project
management. IEEE Software, 22(3), 43-49

Metodologias geis de desenvolvimento de software

As metodologias geis tm o objetivo de acelerar o desenvolvimento do software visando a
melhoria contnua do processo, gerando benefcios como o aumento da comunicao e interao
da equipe, organizao diria para o alcance da meta definida, evitar falhas na elaborao,
respostas rpidas s mudanas e aumento significativo da produtividade.
A BRQ utiliza o processo Scrum de metodologia gil. Saiba mais:

O que Scrum?

O Scrum um processo de desenvolvimento iterativo e incremental para gerenciamento de

projetos e desenvolvimento gil de software. utilizado para trabalhos complexos nos quais
impossvel predizer tudo o que ir ocorrer.

Como Funciona?
 Sprints

No Scrum, os projetos so divididos em ciclos (tipicamente mensais) chamados de Sprints. O

Sprint representa um tempo definido dentro do qual um conjunto de atividades deve ser
executado. Metodologias geis de desenvolvimento de software so iterativas, ou seja, o trabalho
dividido em iteraes, que no Scrum so chamadas de Sprints e geralmente duram de 2 a 4
semanas.

Product Sprint Backlog

As funcionalidades a serem implementadas no projeto so mantidas em uma lista que

conhecida como Product Backlog. No incio de cada Sprint, faz-se um Sprint Planning Meeting
(uma reunio de planejamento), na qual o Product Owner (quem representa os envolvidos)
prioriza todos os itens do Product Backlog e a equipe seleciona as funcionalidades que ela ser
capaz de implementar durante o Sprint que se inicia. As funcionalidades alocadas em um Sprint
so transferidas do Product Backlog para o Sprint Backlog.

Kanban (Quadro de Trabalho)

O time tambm pode possuir um quadro de trabalho, tambm chamado de Kanban, para
organizar as atividades dos itens de Backlog da Sprint, separando-as em basicamente em quatro
estados (isso pode variar de projeto a projeto): A fazer, Em andamento, Em Testes e Concludo.
Esse quadro muito produtivo, pois basta olhar para ele para realizar a leitura do progresso da
Sprint.

Daily Scrum

Diariamente, em uma Sprint, a equipe faz uma breve reunio de no mximo 15 minutos com
todos os participantes em p, chamada Daily Scrum. O objetivo cada integrante dizer o que fez
no dia anterior, o que pretende fazer no dia que se inicia e se existe algum impedimento que est
atrapalhando o seu trabalho.

Sprint Review Meeting

Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint

Review Meeting onde o time mostra o que foi alcanado neste sprint. Finalmente, faz-se uma
Sprint Retrospective para identificar o que funcionou bem e o que pode ser melhorado e a equipe
inicia o planejamento do prximo Sprint.

Burn Down Chart

O Burndown um simples grfico, com dois eixos X e Y, baseado nas atividades que no
ultrapassem um dia de trabalho. O eixo X indica o nmero de tarefas existentes no Sprint e o
eixo Y os dias que representam o tamanho do Sprint.

Papis e Responsabilidades

So 3 os papis principais: o Product Owner, o Scrum Team, e o Scrum Master:

Product Owner

Define os requisitos do produto, decide a data de release e o que deve conter nela.

responsvel pelo retorno financeiro (ROI) do produto.

Prioriza os requisitos de acordo com o seu valor de mercado.

Pode mudar os requisitos e prioridades a cada Sprint.

 Aceita ou rejeita o resultado de cada Sprint.

Scrum Master

Garante que o time esteja totalmente funcional e produtivo.

Facilita a colaborao entre as funes e reas e elimina os impedimentos do time.

Protege o time de interferncias externas.

Garante que o processo est sendo seguindo. Participando das reunies dirias, reviso da
Sprint, e planejamento.

Scrum Team

Multifuncional, entre 5-9 membros.

Seleciona, entre os itens priorizados, os que iro ser executados durante a Sprint.

Tem todo o direito de realizar o que quiser dentro da Sprint

Saiba mais nos links abaixo:

Site Manifesto gil Histria da origem do paradigma de desenvolvimento gil

http://www.agilemanifesto.org/iso/ptbr/

Site Scrum Overview Projeto Eclipse

http://epf.eclipse.org/wikis/scrumpt/

Site Implementing Scrum

http://www.implementingscrum.com/

Site Agile Atlas

http://agileatlas.org/

Mind Master
http://www.mindmaster.com.br/scrum/
 Rush Mtodo gil de gerenciamento de projetos priorizando prazo
http://pmpath.com.br/rush-metodo-agil-de-gerenciamento-de-projetos-priorizando-prazo/

Compartilhe isso:

inShare21