Metodologias ágeis

Modelo ágil para a gestão de projetos de software

As metodologias ágeis são conjuntos de práticas para gerenciar projetos mais adaptável às mudanças. Elas são estruturadas em pequenos ciclos de trabalho, que geram entregas, essas entregas acrescentam um incremento ao produto final, assim, a cada novo ciclo, é entregue um conjunto de funcionalidades no produto.

Fonte: Shutterstock.

Deseja ouvir este material?

Áudio disponível no material digital.

Praticar para aprender

Caro aluno, prezada aluna, seja bem-vindo, seja bem-vinda! Aqui estamos para mais uma seção do nosso conteúdo de Engenharia de Software. Embora as empresas de software tenham prosperado durante décadas utilizando uma única metodologia (ou, na melhor das hipóteses, variações dela), parecia claro para a comunidade de engenheiros de software que algo precisava ser melhorado. A presunção dos requisitos estáveis, os longos períodos sem interações entre cliente e desenvolvedor e o entendimento de que uma linha de produção linear seria adequada para a produção de software tornaram-se gatilhos para que, no começo do século XXI, um grupo de profissionais da computação lançasse um manifesto contendo as bases para uma nova experiência de criação de software.

Chamado genericamente de desenvolvimento ágil, esse novo paradigma começou a ganhar adeptos mundo afora e hoje é adotado por importantes organizações. Como qualquer mudança proposta sobre algo que já se faz há muito tempo da mesma forma, essa renovação também provocou desconfiança, e as inevitáveis comparações entre metodologias (a tradicional e a ágil) foram frequentes.

Para que você forme suas próprias bases comparativas e seja capaz de extrair os pontos positivos de cada paradigma, esta seção se propõe a apresentar as metodologias ágeis, com ênfase no Extreme Programming e no Scrum, introduzindo suas próprias aplicações e ferramentas. Além disso, a seção também estabelecerá comparações, sempre que possível, das práticas que cada uma das metodologias consagrou, a fim de verificarmos juntos se, de fato, o esforço de mudança de paradigma tem valido a pena.

Aqui estamos em nosso segundo desafio da unidade e, logo de início, vale a pena relembrarmos as circunstâncias em que ele se desenrola. Ao iniciar as atividades em uma empresa de desenvolvimento de software, você encontrou uma situação de ausência de padrão nos projetos e, mediante as circunstâncias de urgência e de falta de familiaridade das equipes com modelos, resolveu implementar o Ciclo de Vida Clássico como padrão de desenvolvimento dos seus produtos de software.

Embora a iniciativa tenha sido muito bem-sucedida, o modelo implementado não era exatamente adequado às novas demandas que a organização vinha assumindo e, mesmo sendo uma forma bastante estruturada de desenvolvimento, apresentava falhas que provocavam muito retrabalho e atrasos nas entregas. Por isso, você decidiu dar um passo adiante e implementar uma metodologia ágil de desenvolvimento na empresa.

Depois de um período planejando a mudança, eis que chega o momento de a empresa assumir o primeiro projeto a ser desenvolvido sob os princípios e práticas do Scrum. Considerando sua natureza simples e estruturada, o produto a ser construído foi apropriado para servir como primeira experiência no mundo ágil: o dono de uma pequena loja de itens domésticos solicitou a criação de um site que expusesse sua marca e seus produtos na internet e que possibilitasse a seu visitante cadastrar-se para ter acesso a conteúdos exclusivos.

Depois de entendidas pela equipe, as necessidades do cliente foram transformadas pelo Product Owner em uma lista de tarefas, chamada pelo Scrum de Product Backlog. Na sequência, a primeira tarefa dessa lista foi esmiuçada em tarefas menores, que se transformaram no Sprint Backlog. Considerando os processos da metodologia Scrum, seu desafio consistirá em:

1. Criar o Product Backlog com base na descrição do produto, feita no enunciado, contendo de quatro a seis estórias (ou requisitos), cada uma delas classificada com a prioridade alta, média ou baixa.
2. Detalhar ao menos três tarefas da primeira estória do Product Backlog. Essas tarefas comporão o primeiro Sprint Backlog.
3. Criar um post-it em que a primeira tarefa do Sprint Backlog esteja descrita e que inclua seu nível de prioridade, a classificação de esforço para executá-la, a quantidade de horas estimada para sua conclusão, o nome do responsável, a estória à qual a tarefa pertence e sua descrição resumida. A escolha desses dados fica a seu critério, mas precisam ser coerentes com a tarefa.

Bom trabalho!

conceito-chave

Aquilo que não é bom não dura por muito tempo. Se a seleção natural é infalível na natureza, ela parece atuar com rigor semelhante no mundo do desenvolvimento de software ao permitir que apenas as metodologias mais aptas sobrevivam ao teste do tempo. Foi por isso que o Modelo em Cascata atravessou algumas décadas oferecendo aos engenheiros de software um modo razoavelmente seguro e efetivo de criar seus produtos, em substituição ao desenvolvimento especulativo e caótico praticado antes da estruturação de metodologias de desenvolvimento de software.

Mas, se o Modelo em Cascata é realmente bom, talvez o termo “razoavelmente” tenha sido mal colocado na sentença, não é mesmo? Bem, nesta seção teremos oportunidade de entender alguns elementos desse modelo que justificaram a mudança de paradigma iniciada no ano de 2001 e vivenciada até hoje. O Ciclo de Vida Tradicional – outra forma como o Modelo em Cascata é conhecido – apresenta falhas de concepção que o acabaram tornando obsoleto diante das demandas de tempo e agilidade atuais de produção de software.

Mas, afinal, quais são os problemas da metodologia tradicional? Qual o motivo da dificuldade dela em acompanhar as inevitáveis mudanças de requisitos de um produto durante seu ciclo de desenvolvimento? Por que o cliente tem dificuldade em reconhecer valor no que está sendo desenvolvido? Mais do que responder a essas questões, esta seção tem a intenção de apontar soluções. Antes de abordarmos diretamente as Metodologias Ágeis, convém tratarmos ainda de alguns aspectos do processo tradicional de desenvolvimento para que as comparações sejam feitas de forma adequada.

Conforme estudamos na primeira seção, o processo tradicional de desenvolvimento baseia-se na construção linear do sistema, seguindo uma sequência definida de fases, com a particularidade de uma etapa do processo utilizar o resultado obtido pela etapa anterior para criar seu artefato (WAZLAWICK, 2013). Há também a possibilidade de que o fluxo retorne para etapas anteriores em havendo necessidade de ajustes. Essa construção linear da metodologia baseia-se na ideia de que todas as coisas podem ser construídas como se estivessem em uma linha de montagem: a matéria-prima é inserida na linha de produção e, após algumas etapas determinadas, o produto final está pronto.

A Figura 1.2 ilustra a ideia de utilização dos princípios de uma linha de produção no processo de desenvolvimento de software. Observe que na primeira etapa os requisitos do produto de software representam as matérias-primas. Depois, como em uma linha de montagem tradicional, os especialistas em cada área do processo atuam na linha de montagem até que um produto de software acabado esteja disponível.

É essa fundamentação nas formas tradicionais de fabricação que nos permite atribuir ao Modelo em Cascata três características bem particulares segundo Teles (2006): o determinismo, a especialização e o foco na execução. Para explicar esses conceitos, usaremos a analogia com o processo de montagem de veículos. Vejamos:

• Determinismo: materiais alimentam um processo de fabricação e, ao final da linha de produção, temos um automóvel terminado. As alterações pelas quais os materiais passam são determinísticas e devem sempre gerar um resultado conhecido. Um processo assim estruturado tende a gerar segurança, redução de tempo e de custo.
• Especialização: o processo tradicional de manufatura divide a montagem desse carro em atividades especializadas, desenvolvidas por trabalhadores igualmente especializados. Assim, numa linha de montagem automotiva, haverá a etapa de soldagem do chassi, de colocação do motor, da montagem do interior e assim por diante, todas elas executadas por especialistas em cada função.
• Foco na execução: se as transformações na linha de montagem já estão determinadas e se cada etapa será executada por especialistas, então não há muito em que pensar. Basta executar.

Não é difícil inferir, então, que o Modelo em Cascata tenha sido concebido com base nessas ideias de desenvolvimento industrial em linha. De acordo com essas ideias, a mera obediência a eventos consecutivos (de requisitos até implantação), à especialização (funções de analista, projetista, programador, testador) e ao foco na execução já seria capaz de criar um produto de qualidade, no tempo estipulado pelo cliente e nos limites do orçamento. Havia – e ainda há – a presunção de que a sequência de etapas do projeto seja transformada corretamente em software (TELES, 2006).

Outra presunção que o modelo tradicional de desenvolvimento assume é a de que o profissional do software cumpre trabalhos repetitivos, previamente determinados e que pouco dependem das suas habilidades intelectuais. No entanto, os desenvolvedores podem ser classificados como trabalhadores do conhecimento, pois cumprem suas tarefas com base em seu raciocínio e raramente seguem um processo linear em suas investidas criativas. A eles, portanto, deve ser dada a oportunidade de aplicar tantas revisões quantas forem necessárias em suas criações.

Se as metodologias tradicionais de desenvolvimento se baseiam em modelos de construção que não se adequam especificamente ao produto que desejam entregar, as metodologias ágeis nasceram ajustadas para a criação de software. Os métodos ágeis enfatizam menos as definições de atividades e mais os fatores humanos inerentes ao desenvolvimento de programas de computador (WAZLAWICK, 2013). Eles são, portanto, claramente mais adequados à natureza do trabalho de profissionais de TI, já que preveem a necessidade de sucessivas revisões na obra. Atividades intelectuais não são executadas de forma linear e não são determinísticas.

Durante o processo de criação de um software, é mais do que natural que os requisitos sejam revistos, decisões sejam alteradas e detalhes sejam resgatados. Afinal, ao explicar pela primeira vez as funcionalidades que deseja para o produto, o cliente ainda não as conhece por completo e a visão global do que necessita ainda não está formada. Que tal um procedimento que dê a ele oportunidade de aprender e de mudar de ideia ao longo do desenvolvimento? Você certamente não notou essa atenção com o cliente ao longo do conteúdo do Modelo em Cascata.

Sobre o aprendizado do cliente em relação às suas próprias necessidades, Teles (2006) entende que ele está relacionado ao feedback que o software fornece ao cliente quando ele tem a oportunidade de utilizá-lo, mesmo na versão não completa. No desenvolvimento ágil, o conceito de feedback está presente ao longo de todo o desenvolvimento do software e exerce um papel fundamental.

As práticas relacionadas aos métodos ágeis serão apresentadas nas próximas páginas e você conhecerá elementos do Extreme Programming e do Scrum, duas das mais utilizadas metodologias ágeis.

Porém, antes de abordarmos diretamente as duas práticas, vale a menção ao ato que serviu como marco inicial do pensamento ágil de desenvolvimento. No ano de 2001, um documento contendo a declaração dos doze princípios que fundamentam o desenvolvimento ágil foi divulgado por um grupo de profissionais de TI. Através desse documento, chamado Manifesto Ágil, seus autores declaravam que indivíduos e interações importavam mais do que processos e ferramentas; que softwares em funcionamento importam mais do que documentação; que colaboração com o cliente importa mais do que negociação de contratos e que responder a mudanças é melhor do que seguir um plano (BECK et al., 2001). Você pode conferir a íntegra do manifesto e conhecer seus autores na página Agile Manifesto, na internet (BECK et al., 2001).

Visão geral do Extreme Programming (XP)

O XP é uma metodologia adequada para empreitadas em que os requisitos mudam com certa constância, além de ser ajustado para equipes pequenas e para o desenvolvimento de programas orientados a objetos (TELES, 2006). Ao contrário das metodologias tradicionais, ele é indicado também para ocasiões em que se desejam partes executáveis do programa logo no início do desenvolvimento e que ganhem novas funcionalidades conforme o projeto avança.

Embora a especialização não seja estimulada nas metodologias ágeis, ainda assim existe a necessidade de se estabelecer funções para os participantes do projeto. Uma típica equipe de trabalho no XP tem a seguinte configuração (TELLES, 2004):

• Gerente do projeto: trata-se do responsável pelos assuntos administrativos do projeto e do relacionamento com o cliente. Duas de suas funções mais importantes incluem o estabelecimento de contato entre a equipe e o cliente e o cuidado para que a equipe fique livre de pressões externas e se dedique integralmente ao desenvolvimento.
• Coach: este é o nome do responsável técnico pelo projeto, que deve ser tecnicamente bem preparado e experiente. Se, por exemplo, uma nova tecnologia fica disponível no mercado, é função dele sugerir seu uso no produto em desenvolvimento.
• Analista de teste: ajuda o cliente a escrever os testes de aceitação e fornece feedback para a equipe interna de modo que as correções no sistema possam ser feitas. Ao contrário do que é feito nas metodologias tradicionais, no desenvolvimento ágil em geral (e no XP em particular), o cliente participa ativamente dos testes no produto.
• Redator técnico: ajuda a equipe de desenvolvimento a documentar o sistema, permitindo que os desenvolvedores estejam plenamente focados na construção do programa propriamente dito. À propósito, a metodologia recomenda que o código deve ser claro o suficiente para permitir uma documentação mínima do sistema.
• Desenvolvedor: realiza análise, ajuda a criar o projeto e codifica o sistema. No XP, não há divisão entre as especialidades de engenheiro de requisitos, projetista e o desenvolvedor propriamente dito. No modelo tradicional, o desenvolvedor apenas programa, via de regra.

Para atingir seus objetivos, o Extreme Programming apoia-se em quatro pilares, comumente chamados de valores.

• O primeiro deles é o feedback, cuja aplicação pretende alcançar a troca de informações entre cliente e equipe. Assim, quando o cliente aprende com o sistema que utiliza e reavalia suas necessidades, ele gera feedback para sua equipe de desenvolvimento.
• O segundo valor é chamado de comunicação e pretende estabelecer contato proveitoso entre equipe e cliente, evitando que os desenvolvedores realizem o trabalho de forma especulativa.

• O terceiro valor é a simplicidade, cuja formulação serve para orientar a equipe a desenvolver apenas o que for suficiente para atender a necessidade do cliente, sem “sobrecarregar” o sistema com funções quase sempre inúteis.
• Por fim, o último valor estabelece a coragem como um dos pilares do XP, pois ela será necessária no impulsionamento da equipe para manter sempre o cliente presente, para propor melhorias no que já foi testado e colocado em funcionamento e, de modo geral, para sempre levar adiante as práticas da metodologia.

Como não poderia deixar de ser, esses princípios refletem-se nas práticas e no processo proposto pelo XP. De forma a destacar suas atividades-chave, Pressman e Maxim (2016) assim dividem o processo do XP:

• Planejamento: essa atividade, comumente identificada como jogo do planejamento, tem início com o esclarecimento de requisitos do produto e é executada de modo bem diferente daquele proposto pelo modelo tradicional: aqui, o cliente escreve – de próprio punho – as funcionalidades do produto em uma ficha. A essa ficha dá-se o nome de Estória e cada uma delas é avaliada pela equipe em termos de custo e tempo de execução. A qualquer momento, o cliente pode escrever novas histórias.

• Projeto: representações complexas da solução certamente não são características desta tarefa, muito menos a implementação de funcionalidades extras no produto não solicitadas pelo cliente. A intenção é que o projeto sirva como um guia de implementação de cada história e que seja compreendido também pelo cliente. Caso a equipe se depare com um problema cuja representação seja muito difícil, a metodologia recomenda que se construa um protótipo executável dessa parte do projeto, reduzindo, assim, o risco de se construir uma versão final equivocada daquela história.
• Codificação: mesmo depois de desenvolvidas as histórias e de ter sido feito o trabalho de projeto, a codificação ainda não é iniciada. Ao invés de procurarem codificar uma versão final do produto, os desenvolvedores criarão testes de unidade para cada uma das histórias e só então, após feita e validada essa atividade, o desenvolvimento será orientado a uma versão completa e final.
• Testes: os testes de unidade criados durante a codificação devem ser aptos à automatização, de modo a permitir que sejam feitos rapidamente e repetidos quando necessário. O conjunto de testes de unidade podem ser usados a qualquer momento para testes de integração e de validação do produto.

Em linhas gerais, é assim que o Extreme Programming funciona. No entanto, ele não detém o monopólio das metodologias ágeis.

Visão geral do Scrum

Outro método, também bastante adaptado às demandas atuais de tempo e qualidade, tem sido alternativa para as organizações desenvolvedoras. Trata-se do Scrum, um modelo ágil para a gestão de projetos de software, o qual tem, na reunião regular dos seus desenvolvedores para criação de funcionalidades específicas, sua prática mais destacada. Suas práticas guardam semelhança com as próprias do XP, mas possuem nomes e graus de importância diferentes nos dois contextos. Iniciaremos nossa abordagem com o ciclo tradicional do Scrum, ilustrado na Figura 1.3.

Cada um dos elementos do ciclo é abordado na sequência:

• Product Backlog: trata-se da lista que contém todas as funcionalidades desejadas para o produto. O Scrum defende que tal lista não precisa estar completa logo na primeira vez em que é feita. “Pode-se iniciar com as funcionalidades mais evidentes [...] para depois, à medida que o projeto avançar, tratar novas funcionalidades que forem sendo descobertas” (WAZLAVICK, 2013, p.56).

• Sprint Backlog: lista de tarefas que a equipe deverá executar naquele Sprint. Tais tarefas são selecionadas do Product Backlog, com base nas prioridades definidas pelo Product Owner.
• Sprint: o Scrum divide o processo de efetiva construção do software em ciclos regulares, que variam de duas a quatro semanas (ou em períodos maiores, a depender da complexidade das tarefas). Trata-se do momento em que a equipe se compromete a desenvolver as funcionalidades previamente definidas e colocadas no Sprint Backlog. Se alguma funcionalidade nova for descoberta, ela deverá ser tratada na Sprint seguinte. Cabe ao Product Owner manter o Sprint Backlog atualizado, apontando as tarefas já concluídas e aquelas a serem concluídas.

Embora o modelo Scrum defenda que as equipes sejam auto organizadas, ainda assim apresenta três perfis profissionais de relevância:

• Scrum Master: trata-se de um facilitador do projeto, um agente com amplo conhecimento do modelo e que preza pela sua manutenção durante todas as etapas do projeto. Deve atuar como moderador ao evitar que a equipe assuma tarefas além da sua capacidade de executá-las.
• Product Owner: é a pessoa responsável pelo projeto propriamente dito. Ele tem a missão de indicar os requisitos mais importantes a serem tratados nos sprints.
• Scrum Team: é a equipe de desenvolvimento, composta normalmente por um grupo de seis a dez pessoas. A exemplo do Extreme Programming, não há divisão entre programador, analista e projetista (WAZLAVICK, 2013).

Bem, esse foi o conteúdo de natureza mais teórica que queríamos abordar sobre as metodologias ágeis. No entanto, ainda precisamos tratar do aspecto prático desses modelos e aproveitaremos esta oportunidade para fazê-lo. Conforme já tivemos a oportunidade de discutir, uma das forças que movem as metodologias ágeis é a boa comunicação que deve haver entre os elementos envolvidos em um projeto. É através de boas práticas de comunicação que o cliente poderá se sentir parte integrante (e essencial) do trabalho e poderá expor com segurança o que espera do futuro sistema. Além disso, o bom entrosamento – e a aplicação de técnicas que o aprimoram – é a liga que manterá os membros da equipe mutuamente informados sobre o andamento do projeto.

Imaginemos, então, que você esteja começando seu trabalho em uma desenvolvedora de sistemas, a qual conduz seus projetos de acordo com o Scrum. Em dada ocasião, você acessa uma sala e se depara com um quadro branco afixado na parede, no qual observa um desenho em formato matricial e vários papéis coloridos colados. Um tanto encabulado, pergunta ao seu colega de trabalho do que se trata aquilo e ele diz ser o quadro por meio do qual a equipe mantém o controle das atividades desenvolvidas e a desenvolver do projeto em andamento. Para que você possa reconhecer esse quadro, no caso de essa situação se tornar real, vamos a algumas dicas sobre ele:

• De fato, o quadro Scrum é o meio pelo qual a equipe realiza a gestão visual das atividades do projeto. Uma análise mais detalhada do guia do framework Scrum revelará que o quadro não faz parte, oficialmente, da metodologia, porém sua adoção foi feita em larga escala pelas equipes e, aparentemente, esse fato não altera sua importância.
• As divisões do quadro (daí ele conter desenho com formato matricial) são bem simples: uma coluna identifica a estória e as três colunas seguintes representam as tarefas relacionadas a esta estória que estão: a fazer (to do), em execução (doing) e feita (done).
• Com essa disposição, cada linha do quadro representa uma estória e suas respectivas tarefas, que são, na verdade, extraídas do backlog do produto e que foram selecionadas para uma determinada Sprint.
• Os papéis coloridos colados no quadro são post-its. Eles representam uma determinada característica ou estado daquela tarefa e contêm sua identificação resumida. O exemplo clássico é a do post-it vermelho, que pode representar uma tarefa de correção de defeitos em um código. A critério da equipe, uma determinada cor pode identificar um determinado membro da equipe. Entretanto, uma forma mais completa e racional de se usar o post-it é a que segue:

• A dica final é que tanto o quadro quanto a própria metodologia são adaptáveis à cultura e às necessidades das equipes. Todavia, em sua essência, o quadro ajuda a comunicar a todos o que cada um está fazendo e em qual estágio da atividade ele está, de forma simples e intuitiva.

Observe, na Figura 1.5, um exemplo de um quadro Scrum:

Bem, mas será que podemos contar apenas com pedaços de papel autocolantes para registrar nossas tarefas no Scrum? Embora os post-its sejam úteis para a visualização, digamos, off-line do andamento do projeto, dispomos de ferramentas computacionais colaborativas que facilitam bastante o controle de um projeto, e a primeira que merece menção é o Trello, cujo acesso é gratuito. O início do cadastramento da sua conta acontece quando você fornece seu endereço de e-mail. Em seguida, você já pode dar um nome ao seu time, escolher o tipo do seu time e adicionar membros a ele, conforme exibido na Figura 1.6.

Depois de fornecer essas informações, você será levado a um conjunto de opções e, dentre elas, poderá escolher um modelo de quadro em que as tarefas (e demais informações) serão exibidas. Se você escolher o Template Kanban, obterá um quadro semelhante ao exibido na Figura 1.7 De acordo com texto da autora do template, disponível na mesma página do modelo, ele deve ser usado para manter a equipe com o mesmo nível de informação, para que todos possam seguir o trabalho com fluidez.

Basta agora criar um quadro real com base nesse modelo e pronto! A partir daí é só inserir as tarefas e as informações relacionadas a elas para ter um controle eficiente do seu projeto Scrum. A fim de que você possa utilizar corretamente a ferramenta, vale um resumo de cada uma das colunas apresentadas no template:

• Backlog: aqui devem ser inseridas e descritas as tarefas do projeto, cada uma em seu cartão. A equipe deve ter a liberdade de inserir aqui tarefas que deverão ser, eventualmente, executadas no futuro, mas que ainda não devem ser movidas para a coluna “A Fazer”.
• Elaboração e pesquisa: nessa coluna a equipe deve colocar tarefas que precisam ser mais bem detalhadas e sobre as quais recai necessidade de pesquisa antes que sejam movidas para a próxima etapa. A ferramenta trata essa coluna como apropriada para atividades de projeto ou design, conforme assinalado no título da coluna.
• A Fazer: após a tarefa ser devidamente detalhada e um eventual aprofundamento ter sido feito, ela deve ser levada a essa coluna, como sinalização de que está pronta para ser executada. Nesse caso, um ou mais responsáveis devem ser atribuídos a ela e a data de entrega deve ser estipulada.
• Em andamento: quando as tarefas estão efetivamente em execução elas devem ocupar esta coluna. Dessa forma, todos os envolvidos poderão conferir o andamento das atividades executadas pelos pares e a ferramenta permite, inclusive, que mensagens sejam deixadas diretamente nas tarefas como forma de promover a comunicação.
• Revisão de código: no momento em que a tarefa estiver em vias de ser concluída, ela deve ser movida para esta coluna, a fim de que seja revisada por membro designado da equipe. Embora o título dela seja Revisão de Código, vale aqui qualquer tipo de conferência ou validação.
• Feito: assim que a tarefa é concluída, ela é movida para esta coluna, que não está completamente visível na Figura 1.7.

Essa foi, portanto, a exposição de conteúdo relacionado a metodologias ágeis. Tivemos a oportunidade de conhecer conceitos, práticas e, principalmente, de realizar comparações entre o novo e o tradicional. Em sua jornada profissional, você certamente encontrará organizações desenvolvedoras que um dia ousaram transformar seus processos e tornarem-se ágeis, outras que já foram concebidas como tais e, finalmente, outras tantas que preferiram continuar desenvolvendo programas seguindo padrões tradicionais. Em breve você será desafiado a decidir como a sua organização irá atuar e o embasamento aqui adquirido será fundamental. Continue focado nas leituras e nas atividades propostas!

Faça valer a pena

Referências

A GUIDE to the Scrum Body of Knowledge (SBOK GUIDE). 3. ed. [S.l.]: SCRUMstudy, 2015. Disponível em https://apple.co/3nxZA3t. Acesso em: 18 out. 2020.

ALVERNAZ, A. Template Kanban. Trello, [S.l., s.d.]. Disponível em: https://bit.ly/3gYRRZD. Acesso em: 12 dez. 2020.

BECK, K. et al. Manifesto para Desenvolvimento Ágil de Software. Agile Manifesto, [S.l.], 2001. Disponível em: https://bit.ly/37tc1Ib. Acesso em: 29 out. 2020.

CRUZ, F. Scrum e Agile em Projetos. Guia Completo. 2. ed. Rio de Janeiro: Brasport, 2018.

PRESSMAN, R. S., MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.

SABBAGH, R. Gestão Ágil para Projetos de Sucesso. Edição Eletrônica: Casa do Código, 2013.

SILVA, E. C. Scrum e FTS: uma abordagem prática. Rio de Janeiro: Brasport Livros e Multimídia, 2017. Disponível em: https://bit.ly/38d2kwO. Acesso em: 29 out. 2020.

SUTHERLAND, J. A Arte de Fazer o Dobro do Trabalho na Metade do Tempo. São Paulo: LeYa, 2014.

TELES, V. M. Extreme Programming: aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade. São Paulo: Novatec Editora, 2006.

WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de Janeiro: Elsiever, 2013.