Responder a Mudança

Loading...

Do curso por Instituto Tecnológico de Aeronáutica

Princípios de Desenvolvimento Ágil de Software

128 ratings

Instituto Tecnológico de Aeronáutica

Princípios de Desenvolvimento Ágil de Software

128 ratings

Neste curso, assumimos que você já sabe projetar e desenvolver programas mais complexos em Java, graças às boas práticas e princípios orientados a objetos, TDD e conceitos avançados de Java aplicados à Web e banco de dados exercitados nos cursos anteriores; mas você talvez não se sinta ainda confortável em planejar e gerenciar o desenvolvimento das aplicações com base em modernas práticas de modelagem ágil. O objetivo deste curso é expor você às principais técnicas e princípios de desenvolvimento ágil, em especial aos que se popularizaram pela sua utilização no framework Scrum e na metodologia XP (Extreme Programming). Apresentamos o Scrum&XP, uma combinação apropriada do framework Scrum com a metodologia XP – Extreme Programming, sem no entanto afirmar que você estará aprendendo tudo sobre Scrum ou sobre XP. Os conceitos apresentados neste curso incluem o seguinte: * Manifesto ágil e princípios de desenvolvimento ágil * Requisitos de software na forma de user stories e backlog de produto * Eventos e reuniões do Scrum&XP: Sprint, Sprint Planning, Planning Poker, Daily Scrum, Sprint Review e Sprint Retrospective, TDD e Programação em Pares * Papéis do Scrum: Product Owner, Time de Desenvolvedores e Scrum Master * Tarefas, Sprint Backlog, Quadro de Tarefas e Diagrama Burndown Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que será capaz de implementar de modo ágil um sistema que incorpora um componente de gamificação constante do Trabalho de Conclusão do Programa de Cursos Integrados, com base nas boas práticas ágeis exercitadas neste curso com o Scrum&XP apresentado. Obs.: Embora o Programa de Cursos Integrados (descrito abaixo) seja sobre a linguagem Java no contexto de desenvolvimento ágil, neste curso em especial você poderá empregar a linguagem que desejar, embora incentivemos que os alunos dos cursos anteriores do programa faça uso do Java, pois será uma oportunidade muito enriquecedora de praticar TDD com Java da maneira que se faz na indústria de software. -- --- ---- coursera.org: ITA Programa de Cursos Integrados: Programação Java e Modelagem Ágil Curso 1: Orientação a Objetos com Java Curso 2: TDD – Desenvolvimento de Software Guiado por Testes Curso 3: Desenvolvimento Ágil com Java Avançado Curso 4: Princípios de Desenvolvimento Ágil de Software Curso 5: Desenvolvimento Ágil com Padrões de Projeto Curso 6: Técnicas Avançadas para Projeto de Software Curso 7: Arquitetura de Software em Projetos Ágeis Projeto Final: Aplicativo para Web com Componente Gamificado

Na lição

Semana 1

Olá, bem-vindo ao Curso 4 – Princípios de Desenvolvimento Ágil de Software! Estamos contentes que você esteja aqui para ter os primeiros contatos com modelagem ágil de software. Neste módulo introdutório, você será apresentado ao Scrum&XP, uma combinação apropriada do Scrum com o XP. Ao final deste módulo você também terá aprendido sobre Manifesto Ágil, user stories e visão da aplicação.

Conhecendo o Manifesto Ágil5:50

Indivíduos e Interações10:46

Software Funcionando10:36

Colaboração com o Cliente9:26

Responder a Mudança7:15

Conheça os instrutores

Clovis Fernandes
Professor Titular in Portuguese
Ciência da Computação
Eduardo Guerra
Professor Colaborador

[MÚSICA] Olá a todos,

meu nome é Eduardo Guerra.

Esse é o curso Princípios de Desenvolvimento Ágil de Software.

Nessa aula vamos falar sobre a resposta a mudanças e porque

que isso é tão importante para o desenvolvimento ágil.

A gente vai ver poque que esse capacidade de adaptação ela está diretamente

ligado à questão da agilidade do processo.

Então a gente vai pegar aqui né, como a gente fez nas outras aulas

vamos começar falando sobre o princípio alí né, do manifesto ágil

que é a gente dar prioridade a resposta a mudanças ao invés de seguir plano.

Como eu falei, a gente nunca é eliminar uma coisa completamente

relação a outra, mas dar preferência para a resposta a mudança,

não ficar agarrado demais no plano, e se esquecer que você se

adaptar as vezes pode ser mais importante do que seguir o plano.

Então o que que acontece?

Às vezes o cara começa projeto ele já pega alí,

como ele já faz aquele levantamento de requisito detalha e tal ele e ele já tem

processo preditivo que já diz quais todas as atividades que ele precisa fazer,

ele pega tudo aquilo e joga dentro de project, dentro de gráfico gigante

para fazer o planejamento e às vezes já planeja alí para meses para

frente com dependência de atividades, e aí com esses gráficos de você for

lá e atrasar uma atividade aquilo alí vira uma cascata,

e atrasa tudo que estava dependente daquilo alí dentro do projeto.

Então o que que acontece?

Toda mudança que acaba mudando esse planejamento, aparece uma tarefa nova,

uma tarefa aumenta de tamanho isso daí causa impacto num planejamento,

e se acontece no começo no projeto, isso aí impacta três meses para frente,

e aí vai te dar muito trabalho de ter que ficar adaptando esse planejamento.

Eu já vi projeto de cara só pra fazer isso só pra ficar controlando e modificando,

e adaptando planejamento.

Será que vale a pena?

Será que faz sentido eu planejar para tanto tempo assim na frente?

Se eu não tenho tanta certeza de como vai ser?

Será que a mudança tem que ser uma coisa tão ruim pra dar tanto trabalho?

Será que não tem uma forma melhor de trabalhar com isso?

Né? Então normalmente quando você tem feedback

do cliente você acaba gerando mudanças isso é natural, a gente já aprendeu que

o cliente as vezes ele não tem maturidade no começo do projeto pra saber de tudo.

Às vezes é só utilizando que ele vai saber alguma coisa.

E aí essas mudanças que vão mudar o projeto consequentemente vão mudar o

planejamento.

Então, a gente tem que aprender a trabalhar com isso da

melhor maneira possível.

E aí você ter que manter aquele planejamento sem

alterações para poder seguir aquilo direitinho as

vezes acaba virando o foco do projeto de seguir o plano,

né ao invés de você fazer o software, que é o que interessa no final das contas.

Então você vai fazer várias atividades, vai se proteger para não ter que

mudar aquele planejamento e reuniões com clientes para assinar,

para acertar os requisitos para aquilo não mudar mais.

Então essa fixação por manter o planejamento,

e seguir aquilo certinho até final acaba virando o foco do projeto

ao invés de desenvolver o software que o cliente realmente precisa.

No desenvolvimento ágil a ideia é você usar várias práticas

para você poder tornar essa resposta à mudanças mais rápidas.

Então a própria forma de fazer planejamento é diferente.

Então o que você vai fazer?

Você a longo prazo você vai ter uma visão do que você quer.

Olha, o cliente quer software para isso, eu não preciso de tantos detalhes,

mas a longo prazo eu sei onde que eu quero chegar, num médio prazo eu vou

ter de repente alí requisito de alto nível a funcionalidade,

uma descrição mais breve do que aquilo faz.

E ai as vezes no curto prazo quando eu falo curto prazo é talvez de uma ou

duas semanas para frente no máximo eu vou ter detalhamento de baixo nível daquilo

que eu vou fazer, não necessariamente eu vou usar o gráfico de Ganger,

por exemplo ágil é muito mais comum alí o Kanban,

você ter o quadro alí do Kanban, onde você vai controlando as tarefas feitas e tal,

e a própria equipe vai gerenciando isso mas aí você tem esse planejamento mais

detalhado no curto prazo, então é difícil né, aquela coisa,

onde você vai estar daqui a mês ano, é difícil responder a essa pergunta,

porque muita coisa pode acontecer e mudar esse planejamento.

Então no desenvolvimento ágil a gente, é lá longe?

Então vamos ter uma visão.

Não vamos deixar de planejar não, é importante planejar, mas não vamos

planejar com nível de detalhamento que a gente vai ter que mudar depois.

Vamos planejar de uma forma que o nosso tempo fazendo isso, e a precisão do

nosso planejamento é de acordo com o nível de detalhamento que ele tem.

E aí mais uma vez TDD, refatoração são técnicas aí para deixar o código

mais fácil de ser alterado, e você poder responder a essas mudanças mais rápido.

Então não é só no nível de planejamento mas também na parte do código a gente

também se preocupa com essa alteração da mudança, mais do que fazer altos diagramas

e tal e aí quando você alterar alguma coisa no software causar aquele

impacto alí você vai dar muito trabalho para responder a uma mudança.

Aqui é o contrario, a gente foca naquilo que dá essa agilidade para a gente.

Certo?

Então é isso.

Vimos aqui nessa aula a última parte aí do manifesto ágil.

Pegamos cada daqueles princípios e destrinchamos eles mostrando

a importância se a gente for ver a questão de colaborar com o cliente

é importante para a resposta a mudança, que é importante para outras partes,

então de uma certa forma as coisas estão interligadas,

e espero que nessas aulas aí vocês tenham entendido qual que é a ideia do

desenvolvimento ágil de software a partir desses princípios do manifesto ágil.

Certo?

Muito obrigado, até o próximo módulo.

[MÚSICA]

Explore nosso catálogo

Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.

O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.

© 2018 Coursera Inc. Todos os direitos reservados.

Baixar na App Store

Baixar no Google Play