Your SlideShare is downloading. ×
PRÁTICAS DE MÉTODOS ÁGEIS E POSSIBILIDADE DE EXECUÇÃO EM                     AMBIENTES DE TRABALHO CONHECIDOS             ...
identificar os problemas mais importantes (KNIBERG; SKARIN, 2009, p.67). Recomenda-sesua realização em pé para mantê-la cu...
4   ESTIMATIVA ATRAVÉS DE PLANNING POKER       Técnica comumente utilizada em desenvolvimento ágil de software para estima...
A retrospectiva do Sprint é o momento em que o time “olha para traz” para analisarcomo foi o último sprint. Neste momento ...
pois o cliente tem que esperar muito tempo para ver o resultado do trabalho da equipe dedesenvolvimento.   9   METÁFORA   ...
programação em pares o código produzido é sempre revisto por duas pessoas, diminuindo apossibilidade de erros, além de se ...
comportamento não foi alterado é feita pela utilização de testes automatizados(REFATORAÇÃO, 2012).       Refatoração faz p...
metodologia XP não recomenda que se trabalhe horas extras numa segunda semanaconsecutiva pois, embora aumente a produtivid...
19 UTILIZAÇÃO DE CRCS       CRC é acronimo de Class, Responsibility, Collaborator, é uma tecnica que se utilizade cartões ...
FIGUEIREDO, Alexandre Magno. Scrum e as armadilhas das reuniões diárias. Visão Ágil,Ano I, Edição 01, página inicial e fin...
TEST DRIVEN DEVELOPMENT. In: WIKIPÉDIA, a enciclopédia livre. Flórida:Wikimedia Foundation, 2012. Disponível em:<http://pt...
Upcoming SlideShare
Loading in...5
×

Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de Trabalho Conhecidos

465

Published on

Avaliação de algumas práticas de Metodologias Ágeis escrito como trabalho para disciplina de Métodos Ágeis.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
465
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de Trabalho Conhecidos"

  1. 1. PRÁTICAS DE MÉTODOS ÁGEIS E POSSIBILIDADE DE EXECUÇÃO EM AMBIENTES DE TRABALHO CONHECIDOS Silvio Gonçalves silvio@vexta.com.br Prof. Pablo Schoeffel, Métodos ÁgeisRESUMO: Avaliação de algumas práticas de Metodologias Ágeis escrito como trabalhopara disciplina de Métodos Ágeis.Palavras-chave: Metodologias Ágeis, Scrum, XP, Modelagem Ágil 1 INTRODUÇÃO Extreme Programming (XP) é uma metodologia de desenvolvimento de software,nascida nos Estados Unidos ao final da década de 90. Seu sucesso se deve ao fato ajudar acriar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma maiseconômica que o habitual. Para alcançar tais objetivos baseia-se em um pequeno conjunto devalores, princípios e práticas, que diferem substancialmente da forma tradicional de sedesenvolver software. Scrum é uma metodologia ágil voltada para a gestão e planejamento de projetos desoftware. Os projetos são dividos em ciclos chamados de Sprints, dentro do qual um conjuntode atividades deve ser executado. A lista de funcionalidades a serem implementadas em umprojeto é denominada Product Backlog. O Sprint inicia-se pela reunião de planejamento naqual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividadesque ela será capaz de implementar durante o Sprint. As tarefas alocadas em um Sprint sãotransferidas do Product Backlog para o Sprint Backlog. No final do Sprint, a equipe apresentaas funcionalidades implementadas e faz uma Retrospectiva, partindo para o planejamento dopróximo Sprint, reiniciando o ciclo. 2 REUNIÕES DIÁRIAS EM PÉ A reunião diária, ou Daily Scrum, é uma das práticas utilizadas pelo Scrum paradifundir informação sobre o que está acontecendo, planejar o trabalho do dia em curso, e
  2. 2. identificar os problemas mais importantes (KNIBERG; SKARIN, 2009, p.67). Recomenda-sesua realização em pé para mantê-la curta, por isto chamada reunião em pé. Alguns cuidados devem ser tomados para que a reunião consiga atingir seus objetivos.FIGUEREDO (2007, p.18) alerta que “muitas equipes tem confundido os quinze minutos dareunião diária com momentos de desabafo” em seu artigo sobre as armadilhas das reuniõesdiárias. Nestes casos, cabe ao Scrum Master manter o foco da reunião, fazendo com que aequipe se atenha somente a resposta das questões propostas pela prática: a)o que fiz desde aúltima reunião diária? b)o que farei até a próxima? E c)estou tendo algum impedimento? A difusão do informação por todo o time considero como umas das melhoresjustificativas para sua utilização. Isto auxilia na formação de equipes homogêneas, aondetodos tomam conhecimento dos problemas a serem resolvidos e das soluções encontradas. Aexplanação de um problema, por si só, já faz com que pensem nele com uma visão maiscrítica, fazendo que com isto se chegue a uma solução mais rapidamente. A aplicação isolada em uma empresa seria possível, provavelmente não com tantaeficiencia que se aplicado com as outras prátivas ágeis, mas o objetivo principal – difindir ainformação – certamente poderia ser alçado. 3 SCRUM BOARD É um quadro onde deverá contemplar todas as tarefas que serão realizadas dentro deum Sprint e listadas de acordo com as prioridades de cada item. Mostra visualmente oprogresso do trabalho para os membros da equipe e as partes interessadas. Antes ou durante areunião diária o quadro é atualizado para refletir sempre a posição atualizada. O quadro garante transparência e inspeção no processo de desenvolvimento.Transparencia pois todos os comprometidos com o projeto podem acompanhar como está odesenvolvimento de cada história e os problemas encontrados nelas. A inspeção é feita pelainterpretação do mesmo. Quando é identificado muitos impedimentos, certamente indicaproblemas, bem como uma tarefa que está muito tempo sendo feita. Assim, problemascomplexos podem facilmente serem diagnosticados, de forma visual e intuitiva(O QUADRODE TAREFAS NO SCRUM, 2012). A visualização rápida da posição das tarefas é o maior benefício da utilização doquadro. Para que sua aplicação tenha efeito prático é necessário utilizar em conjunto com asoutras práticas do scrum, como a reunião diária, aonde é feita a atualização do quadro.
  3. 3. 4 ESTIMATIVA ATRAVÉS DE PLANNING POKER Técnica comumente utilizada em desenvolvimento ágil de software para estimar oesforço ou o tamanho relativo de histórias. É uma técnica baseada no concenso. Este métodoevita a influência dos outros participantes nas escolhas, e força com que cada participantepense independentemente ao propor seus números ao mesmo tempo (PLANNING POKER,2012). Os participantes que definirem a menor e a maior pontuação devem justificar suasescolhas e, caso necessário, novas rodadas serão executadas até que o concenso sejaalcançado. O fato de os participantes terem que justificar sua escolha faz com que repensem atarefa e exponham seus pontos de vistas e dificuldades visualizadas. Isto faz com que sejamelencadas dificuldades que outro participante pode não ter visto. Esta prática abre espaço paraque todos os participantes da equipe possam expressar sua opinião, reforçando o conceito decolaboração e aumentando o comprometimento. Individualmente, em qualquer atividade que necessite estimantiva, acredito serpossível utilizar esta tecnica, pelo fato de que a opinião de um participante sobre o outro sejaminimizada. 5 CLIENTE OU REPRESENTANTE DO CLIENTE JUNTO À EQUIPE Dentre os papéis definidos pelo Scrum, o Product Owner é quem representa o cliente.O Product Owner “é o responsável pelo Retorno do Investimento (ROI) do projeto, cabe a elepriorizar os itens no Product Backlog (PB) de forma a obter o maior retorno possível” (OPAPEL DO PRODUCT OWNER E PRIORIZAÇÃO DO PRODUCT BACKLOG, 2008).Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões. A proximidade do cliente junto a equipe de desenvolvimento agrega valor ao produtofinal pelo fato de que o cliente, representado pelo Product Owner, é quem define asprioridades, fazendo com que a equipe se concentre nas atividades que tragam mais valor paraele. Além de um maior compromentimento do cliente. Acredito que esta aproximação feita de forma desordenada ou sem que umconhecimento/entendimento do scrum por parte do Product Owner pode trazer conseguenciasdesagradaveis para a equipe. 6 RETROSPECTIVA
  4. 4. A retrospectiva do Sprint é o momento em que o time “olha para traz” para analisarcomo foi o último sprint. Neste momento ele responde a três questões principais sobre osprint: O que deu errado? O que deu certo? O que poderia ser melhorado para o próximosprint? (SCRUM, 2012). Uma boa aplicação da reunião de retrospectiva resulta em melhoria contínua, sempreanalisando o que foi feito de errado e tomando cuidado para que estes erros não se repitam. Éo momento de colher o feedback do time sobre a aplicação do scrum em si. A retrospectiva é importante não só para o scrum. No final do ano, por exemplo,analise os pontos em que você logrou exito e aonde você errou. Certamente no próximo anovocê irá errar menos, ou pelo menos evitar os mesmos erros que você identificou. 7 JOGO DO PLANEJAMENTO (PRIORIZAÇÃO PELO CLIENTE) O jogo do planejamento refere-se a reunião inicial do sprint aonde todos participam, eo cliente (no papel do Product Owner), prioriza e seleciona as histórias que serãodesenvolvidas. O envolvimento do cliente neste fase gera maior comprometimento por partedeste, pois ao definir as prioridades ele está sinalizando o que tem mais valor para ele nestemomento, alem de ele estar ciente do que está acontecendo e o que vai acontecer no projeto. 8 ENTREGAS FREQUENTES (SPRINTS) Um dos principios do Manifesto Ágil sugere entregas frequentes de softwarefuncionando. Entregas rápidas e frequentes fazem com que se tenha também um feedbackrápido do cliente, o que pode evitar o desenvolvimento de funcionalidades desnecessárias oucom um comportamento indesejado pelo cliente. O retorno sobre o investimento do clientetambém é acelerado, “já que na maioria das vezes o ROI real só será recebido pelo clientecom o produto em produção” (RELEASE: O QUÃO CURTO E FREQUENTE FORPOSSÍVEL, 2011). Entregas rápidas faz com que se consiga respoder rapidamente com uma correção aum bug, por exemplo, ou a uma melhoria solicitada. Isto melhora a relação com o cliente,pelo fato dele visualizar progresso neste processo: algo que ele solicitou (e que tenha a devidaprioridade) seja entregue mais rapidamente. Mesmo que sejam pequenas melhoras, masrápidas e frequentes contribuem para um ambiente de melhoria contínua, em vez de grandesliberações que muitas vezes também o são demoradas e que geralmente geram desconforto
  5. 5. pois o cliente tem que esperar muito tempo para ver o resultado do trabalho da equipe dedesenvolvimento. 9 METÁFORA Metáfora é um recurso que pode ser utilizado para transmitir idéias complexas deforma mais simples, facilitando o entendimento de um assunto (SANTOS, 2010). Seriamdescrições de um software sem a utilização de termos técnicos com a intenção de conduzir odesenvolvimento de software de forma mais transparente possível para o cliente. A dificuldade de encontrar material sobre o assunto me leva a crer que a utilizaçãodeste artefado da metodologia ágil não é muito difundido. Mesmo porque não é fácilencontrar uma metáfora que se encaixe em todos as histórias e ou projetos que estamostentando aplicar o método. 10 PROJETO SIMPLES Refere-se ao décimo principio do manifesto ágil: “Simplicidade: a arte de maximizar aquantidade de trabalho que não precisou ser feito.” Aplicando este princípio ao processo dedesenvolvimento é possível reduzir o trabalho ao mínimo e permitir o foco da equipe nasolução mais simples possível para criar valor ao negócio (10º PRINCÍPIO DO MANIFESTOÁGIL – SIMPLICIDADE, 2011). Em resumo, faça o essencial. A importancia da abordagem simples vem do fato deserem mais facilmente mudadas, adaptadas. O objetivo é satisfazer os requisitos atuais, sem apreocupação com requisitos futuros. A visão minimalista faz com que estejamos desenvolvendo o minimo possível,basicamente o essencial para a existencia do produto, reduzindo desta forma as chances deinsucesso, pois estaremos implementando o que o cliente realmente quer e precisa. Destaforma mantemos o foco em realmente criar valor para o cliente, controlando os custos poisestamos o que é realmente essencial. 11 PROGRAMAÇÃO EM PARES É a programação em duplas em um único computador. Um fica em frente aocomputador codificando e o outro ao lado, acompanhando e ajudando o desenvolvimento. Na
  6. 6. programação em pares o código produzido é sempre revisto por duas pessoas, diminuindo apossibilidade de erros, além de se conseguir uma evolução da equipe e uma melhora noscódigos gerados (PROGRAMAÇÃO EXTREMA, 2012). Os papéis devem ser alternadosconstantemente assim como as duplas para que haja melhor aproveitamento desta prática. Os benefícios desta prática num primeiro momento podem ser ofuscados pela ideia deque os custos dobrarão, mas na prática, muitos autores tem mostrados que o ganho naqualidade do código, diminuindo retrabalhos e erros, aumento no nível de conhecimento daequipe pelo troca de conhecimento, acabam equilibrando esta conta. Ainda assim, acreditoque seja benefica esta prática pelo fato de melhorar a satisfação do cliente, por estarrecebendo softwares com menor taxa de erros. 12 TESTES AUTOMATIZADOS / TDD Na metodologia XP, testar é parte da rotina diária dos desenvolvedores. A execução detestes em um sistema é uma tarefa maçante e que demanda um grande esforço em tempo. Daía necessidade de automatizar o processo de testes, que nada mais é do que a utilizando umsoftware específico para efetuar testes em outro (AUTOMAÇÃO DE TESTE, 2012). O Test Driven Development (TDD) é uma técnica que define que primeiro sedesenvolve os casos de teste e depois se implementam os códigos que devem ser testados.Depois da implementação passar pelos teste ele pode ser refatorado para um código sobpadrões aceitáveis. O TDD garante, quando usado adequadamente, que todo o código sejacoberto por um teste, isto gera em toda equipe um nivel maior de confiança no software(TEST DRIVEN DEVELOPMENT, 2012). Testes são essenciais para que a qualidade do software seja mantida. Sob este ponto devista acredito ser importante a automatização dos teste e, mais ainda, que se façam testes paraconseguir melhorar a qualidade dos softwares entreges. 13 REFATORAÇÃO Consiste em modificar um sistema com objetivo de melhorar sua estrutura,simplificando, sem comprometer seu funcionamento, também melhorando o entendimento docódigo, facilitando a manutenção e evitando a inclusão de defeitos. A garantida de que o
  7. 7. comportamento não foi alterado é feita pela utilização de testes automatizados(REFATORAÇÃO, 2012). Refatoração faz parte do processo de melhoria continua do software, desde queacompanhada dos testes que garantam o correto funcionamento do código refatorado. 14 PROPRIEDADE COLETIVA Todo código escrito pertence a equipe. Todos podem alterar qualquer parte do sistema.É o que prega a metodologia XP. Um dos benefícios disto é a dissiminação do conhecimento,o que permite que um membro da equipe possa tirar férias, por exemplo, pois os outrosconhecem os códigos que este implementa. Mas para que esta prática possa ser aplicada é necessário, pelo menos, a utilização depadrão de codificação. 15 INTEGRAÇÃO CONTÍNUA Consiste na integração do trabalho diversar vezes ao dia, assegurando que o códigopermaneça consistente ao final de cada integração atraves de testes principalmente. Aintegração contínua aplica pequenas alterações ao todo em vez de aplicar todo o código aofinal do desenvolvimento, reduzindo também o tempo de entrega (CONTINUOUSINTEGRATION, 2012). Para a aplicação da integração contínua faz-se necessário a utilização de testesautomatizados para garantir a qualidade do código que está sendo integrado, bem como autilização de repositórios para os códigos (controle de revisão). Com a integração contínua é possível identificar divergências nos códigos antes queelas virem problema. Também comentários do tipo “isso funcionava na minha máquina”. Devido a necessidade de aplicação desta prática em conjunto com outras já citadas,como controle de revisão e automação dos teste, acredito ser difícil aplicar esta práticaindividualmente. 16 SEMANA DE 40 HORAS Por ser o desenvolvimento de software uma atividade que demanda lógica ecriatividade, a premissa de que horas extras aumentam a produtividade não é válida. A
  8. 8. metodologia XP não recomenda que se trabalhe horas extras numa segunda semanaconsecutiva pois, embora aumente a produtividade nos primeiros dias, os efeitos colateraisaparecerão assim que os envolvidos se cansam (SANTOS, 2010). Horas extras numa segundasemana consecutiva é sintoma de problema no projeto e este não deve ser resolvidoaumentando a carga horária, mas melhorando o planejamento (CONCEITOS BÁSICOSSOBRE METODOLOGIAS ÁGEIS PARA DESENVOLVIMENTO DE SOFTWARE,2012). Esta prática, acima de tudo, gera melhor qualidade de vida para quem a utiliza, e por sísó, acredito que isto justifique sua aplicação. 17 PADRÕES DE CODIFICAÇÃO Entende-se por padrão de codificação a adoção de um estilo único de codificação portodos os programadores do projeto. Esta prática ajuda a manter o código legível por todos noprojeto (SANTOS, 2010). O padrão de codificação é imprescindível para uma melhora aplicação de outraspráticas já citadas aqui, como por exemplo programação em pares, propriedade coletiva,refatoração. 18 UTILIZAÇÃO DE USER STORIES User Stories é uma sentença escrita na liguagem cotidiana ou de negócio, que visacapturar o que o usuário faz ou precisa fazer. Muito importantes nas metodologias ágeis, elasdefinem o que deve ser contruido no projeto de software (USER STORIES, 2012). Sãodescrições simples dos requisitos do sistema, escritas sob o ponto de vista do usuário(ESCREVENDO “USER STORIES” EFICAZES, 2012). Descrevem cenários com situaçõesde utilização que os usuários gostariam que o software viesse a oferecer. Elas são a base paraa criação de estimativas de tempo e para a elaboração dos testes de aceitação. A user story normalmente é descrita no formato “Como um (usuário), Eu quero(funcionalidade), Para que (necessidade)”. O uso adequado das user stories traz diversos benefícios a equipe, pois de uma formasimples e objetiva consegue-se identificar qual é a funcionalidade, qual é o usuário que vaiutilizar e para que ela serve.
  9. 9. 19 UTILIZAÇÃO DE CRCS CRC é acronimo de Class, Responsibility, Collaborator, é uma tecnica que se utilizade cartões de papel. Baseia-se em identificar em cada cartão uma classe e suas propriedades eas associações entre as classes (CRC - VOCÊ JÁ OUVIU FALAR NESTA TÉCNICA?,2007). Esta técnica permite que todos os integrantes da equipe contribuam com o design equanto mais pessoas ajudarem, maior a quantidade de boas ideias que podem serincorporadas. 20 REFERÊNCIAS10º PRINCÍPIO DO MANIFESTO ÁGIL – SIMPLICIDADE. 2011. Disponível em:<http://blog.scrumhalf.com.br/en/2011/09/10%C2%BA-principio-do-manifesto-agil-%E2%80%93-simplicidade/> Acessado em 11 Set 2012.AGILE SOFTWARE DEVELOPMENT. In: WIKIPÉDIA: a enciclopédia livre. Flórida:Wikimedia Foundation, 2012. Disponível em:<http://en.wikipedia.org/w/index.php?title=Agile_software_development&oldid=509809158>. Acessado em: 30 ago 2012AUTOMAÇÃO DE TESTE. In: WIKIPÉDIA, a enciclopédia livre. Flórida: WikimediaFoundation, 2012. Disponível em:<http://pt.wikipedia.org/w/index.php?title=Automa%C3%A7%C3%A3o_de_teste&oldid=31694317>. Acesso em: 13 set. 2012.CARTÕES CRC. 2003. Disponível em: < http://www.zemoleza.com.br/carreiras/12293-cartoes-crc.html> Acessado em: 13 Set 2012.CONCEITOS BÁSICOS SOBRE METODOLOGIAS ÁGEIS PARADESENVOLVIMENTO DE SOFTWARE. Disponível em:<http://www.devmedia.com.br/conceitos-basicos-sobre-metodologias-ageis-para-desenvolvimento-de-software-metodologias-classicas-x-extreme-programming/10596>Acessado em 12 Set 2012CONTINUOUS INTEGRATION. In: WIKIPÉDIA: a enciclopédia livre. Flórida: WikimediaFoundation, 2012. Disponível em:<http://en.wikipedia.org/w/index.php?title=Continuous_integration&oldid=511429041>Acessado em 11 Set 2012;CRC - VOCÊ JÁ OUVIU FALAR NESTA TÉCNICA?. 2007. Disponível em:<http://www.infoblogs.com.br/view.action?contentId=2654&CRC-Voce-ja-ouviu-falar-nesta-tecnica.html> Acessado em 13 Set 2012.ESCREVENDO “USER STORIES” EFICAZES. In: daily scrum blog, 2012. Disponível em:<http://www.dailyscrumblog.com/posts/221> Acessado em 13 Set 2012.
  10. 10. FIGUEIREDO, Alexandre Magno. Scrum e as armadilhas das reuniões diárias. Visão Ágil,Ano I, Edição 01, página inicial e final, Julho de 2007. Disponível em:<www.visaoagil.com/edicoes>. Acesso em: 09 Set 2012.KNIBERG, Henrik; SKARIN, Mattias. Kanban e Scrum: obtendo o melhor de ambos. 2009.Disponível em: <http://www.infoq.com/br/minibooks/kanban-scrum-minibook> Acessadoem: 09 Set 2012.MANIFESTO ÁGIL. Disponível em: <http://agilemanifesto.org/iso/ptbr/principles.html>Acessado em 10 Set 2012.O PAPEL DO PRODUCT OWNER E PRIORIZAÇÃO DO PRODUCT BACKLOG. In:Antonio Carlos Silveira: Blog, 2008. Disponível em:<http://www.acarlos.com.br/blog/2008/02/papel-do-product-owner-e-priorizacao-do-product-backlog/> Acessado em 09 Set 2012.O QUADRO DE TAREFAS NO SCRUM. 2012. Disponível em:<http://blog.scrumhalf.com.br/2012/01/o-quadro-de-tarefas-no-scrum/> Acessado em 11 Set2012PLANNING POKER. In: WIKIPÉDIA: a enciclopédia livre. Flórida: Wikimedia Foundation,2012. Disponível em:<http://en.wikipedia.org/w/index.php?title=Planning_poker&oldid=508312745> Acessadoem 09 Set 2012.PROGRAMAÇÃO EXTREMA. In: WIKIPÉDIA, a enciclopédia livre. Flórida: WikimediaFoundation, 2012. Disponível em:<http://pt.wikipedia.org/w/index.php?title=Programa%C3%A7%C3%A3o_extrema&oldid=31918373>. Acesso em: 13 set. 2012.REFATORAÇÃO. In: WIKIPÉDIA, a enciclopédia livre. Flórida: Wikimedia Foundation,2012. Disponível em:<http://pt.wikipedia.org/w/index.php?title=Refatora%C3%A7%C3%A3o&oldid=31680365>.Acesso em: 13 set. 2012.RELEASE: O QUÃO CURTO E FREQUENTE FOR POSSÍVEL. 2011. Disponível em:<http://www.adaptworks.com.br/blog/2011/01/27/release-o-quao-pequeno-e-frequente-for-possivel/> Acessado em 11 Set 2012.SANTOS, Tiago dos. Utilizando metodologias ágeis em projetosde software. 2010. 44 Folhas.Trabalho de Conclusão de Curso – Faculdade Comunitária de Taubaté da AnhangueraEducacional S.A., Taubaté. Disponível em: <http://www.scribd.com/doc/61603274/TCC-Metodologias-Ageis-V-Final>.SCRUM. In: WIKIPÉDIA, a enciclopédia livre. Flórida: Wikimedia Foundation, 2012.Disponível em: <http://pt.wikipedia.org/w/index.php?title=Scrum&oldid=32095022>. Acessoem: 9 set. 2012.SCRUM. Disponível em: <http://epf.eclipse.org/wikis/scrum> Acessado em: 10 Set 2012
  11. 11. TEST DRIVEN DEVELOPMENT. In: WIKIPÉDIA, a enciclopédia livre. Flórida:Wikimedia Foundation, 2012. Disponível em:<http://pt.wikipedia.org/w/index.php?title=Test_Driven_Development&oldid=30097216>.Acesso em: 13 set. 2012.USER STORIES. In: WIKIPÉDIA, a enciclopédia livre. Flórida: Wikimedia Foundation,2012. Disponível em :<http://en.wikipedia.org/w/index.php?title=User_story&oldid=510407570> Acessado em: 13Set 2012.

×