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
Software Funcionando
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
Princípios de Desenvolvimento Ágil de Software
131 classificações
Instituto Tecnológico de Aeronáutica
131 classificações
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.
Conheça os instrutores
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[MÚSICA] Olá a todos!
Meu nome é Eduardo Guerra,
esse é o curso "Princípios de desenvolvimento ágil de software".
Hoje eu vou falar para vocês pouquinho sobre software funcionando.
A gente não vai literalmente fazer o software funcionar,
mas a gente vai falar pouquinho sobre a importância de você focar no software
mais do que você ter uma documentação abrangente,
que tenha várias coisas, mas que não funcione.
Então, a gente vai estar pegando o segundo
item do manifesto ágil, que diz que é mais importante você ter o software
funcionamento do que uma documentação abrangente.
Bom, para começar eu vou pegar gráfico bastante famoso na
comunidade de desenvolvimento de software, que a gente chama das "baleinhas do RUP",
que ele mostra para cada tipo de atividade qual que é o esforço
que você vai ter durante cada fase do projeto.
Então, você pega ali somente a última baleinha,
que ela é mais gordinha para o final, que é o desenvolvimento, e aí você tem,
principalmente no início do projeto, esforço maior nas outras frentes.
Bom, quê que eu tenho a dizer relação a isso aí?
Está vendo essa parte aí?
Papel!
Isso aí é papel, não é software.
Então, o que acontece?
No desenvolvimento tradicional, no começo,
você gerava monte de papel, monte de documentação.
Uma vez eu participei de processo de desenvolvimento de software que ele tinha,
o processo obrigava que você tivesse documento
para documentar as necessidades de treinamento da equipe.
E aí, tinha documento de cinco páginas, quatro,
cinco páginas para falar que a equipe não precisava de treinamento nenhum.
Então, é exemplo da burocracia, do seguir o processo por seguir.
Então, realmente, se você tem que fazer monte de documentação que não
serve para nada, e aí eu lembro que quando eu citava isso a pessoa falava "não, mas
pode ser importante escrever que a equipe não precisou de nenhum treinamento!" Não,
tudo bem, se acredita nisso então vai frente.
Vai gerando papel!
Então, assim, que acontece?
Você chega, você percorre ali uma larga porção do
seu projeto sem que aquilo ali gere nenhum software.
E mesmo o início ali do desenvolvimento fala assim: " não,
mas logo no comecinho você tem".
Você pode até ter alguma coisa, mas até você ter alguma coisa entregável,
alguma coisa que o cliente possa ver, vai demorar,
vai ser mais da metade do projeto.
Então, que acontece?
Se você pegar às vezes desenvolvimento tradicional,
você vai falar assim: " qual que é o andamento do projeto?
É 40%." Só que não tem nada pronto ainda.
Todas as atividades que o cara tinha planejado ali fazer, que é: "!
Eu preciso escrever os requisitos,
preciso montar o planejamento, preciso fazer aquilo, aquilo,
gerar aquele monte de documentação, fazer diagrama assim, fazer diagrama assado,
fazer uma reunião assim, documentar o treinamento, documentar não sei quê lá." O
cara vai estar 40% do projeto, se pegar lá o Project,
o planejamento que ele fez, vai estar ali que tá tudo foi cumprido,
só que ele falou assim: "Ó, aqui, eu estou com 40% de projeto de
software e quantos porcento do software si está implementado?" 0%!
Não tem nada pronto.
Então, é complicado você chegar e
falar que tem 40% do projeto e não ter nada pronto.
E aí vem, e se eu trocar aquela documentação pela criação do software?
Se ao invés eu falar assim: "OK, eu tenho o meu software,
eu tenho aqui as necessidades do cliente.
Por que é que ao invés de eu pegar, sair correndo para escrever monte de coisa ali,
porquê que eu não vou e tento criar software que é parecido,
que tem a ver com aquilo que o cliente falou?" Ao invés de ele
ter que ler o documento, ele vai lá e vai mexer no software, vai falar: "Olha,
era isso que eu queria!" ou "Não, não era isso que eu queria" ou "Ó,
isso aí que vocês fizeram não tem nada a ver com o que eu queria!" Ou, sei lá,
"Metade disso que vocês fizeram tem a ver, a outra metade vai ter que mudar",
que costuma ser o caso.
A equipe costuma não acertar tudo, mas começar já
tendo várias coisas próximas daquilo que o cliente quer e evoluir a partir dali.
Não estou falando que não tenha que ter documentação nenhuma.
Como falei, o Manifesto Ágil, ele não diz para você ignorar uma
coisa e fazer só a outra; ele diz que talvez ter o software funcionando
seja mais importante do que você ter aquele monte de documento escrito.
Mas de repente você escreve pouquinho ali para entender as necessidades
do cliente e depois você vai e faz alguma coisa que ele realmente possa mexer,
interagir, te dar feedback.
Bom, aí com certeza vai vir alguém muito brabo falando pra mim,
vai falar assim: "OK, mas aí com certeza se você não documentar, e não insistir,
e não conversar de forma extensiva ali com o cliente, você vai fazer alguma coisa
que ele não quer e aí você vai ter que mudar!" E aí esse é o medo,
esse é o grande medo do pessoal do desenvolvimento tradicional.
"Tem que mudar!", a mudança.
Só que aqui a gente abraça a mudança, a gente não é contra a mudança.
A gente sabe que o cliente às vezes,
tem que ver o software para poder amadurecer na cabeça dele aquela ideia e
para que chegue no final do projeto e tenha aquilo que o cliente realmente quis.
Então, a ideia é essa mesmo.
Você faz pouquinho e aí com o feedback do cliente você vai evoluindo o software.
Então, vez de você querer, logo de cara, escrever monte de documentação, fazer
monte de projeto, para depois começar a fazer e não ter que mudar mais, não!
A gente faz ali pedacinho, vê o que o cliente acha,
pega o feedback dele, muda se precisar e aí vai fazendo essas pequenas iterações,
às vezes de uma semana, às vezes de 15 dias, no máximo de mês,
que o cliente vai dando esse feedback e a equipe vai evoluindo cima disso daí.
E aí, as técnicas que a gente aprendeu nos cursos anteriores, de TDD,
de refatoração, isso aí vai deixando o código mais fácil de ser modificado.
No TDD você está focando ali na simplicidade,
na refatoração você está se preocupando deixar o código limpo; você tem os
testes para saber se alguma mudança vai tá impactando outras partes do software.
Então, tudo isso dá esse suporte para a gente poder alterar o
software com maior facilidade.
Então, não é simplesmente: "!
O cliente vai falando, eu vou alterando, a gente vai fazendo." Não!
O desenvolvimento ágil não tem nada a ver com isso.
Precisa de muita disciplina para criar os testes automatizados,
para estar sempre refatorando o software, mas a gente precisa.
E aí com isso a gente, sim, consegue fazer aquelas alterações,
consegue fazer aquelas iterações.
Então, todas as práticas, elas são voltadas para possibilitar
essas iterações, esse contato maior com o cliente.
E aí, não é que você não tem que ter nenhuma documentação, às vezes,
é interessante você documentar os requisitos, o que o cliente falou,
de repente algum projeto que você fez que é mais importante,
uma parte mais complicada, como que funciona,
uma regra de negócio de repente tem ali diagrama de estado que talvez é
complicado, e aí você senta com o cliente de repente e desenha aquilo ali.
Mas a ideia é você fazer a documentação quando ela for agregar valor.
Quando você falar assim: "OK, isso daqui", sei lá,
"Esse modelo aqui de banco de dados, poxa!
Vale a pena", "Essa regra aqui de negócio do cliente,
todo mundo tem que estar ciente.
Então vamos escrever, vamos pregar na parede, vamos tentar divulgar essa
informação da melhor forma possível." É a diferença, por exemplo,
daquele cara que leva três malas e aí não usa nem a metade das roupas,
daquela pessoa que viaja mais leve, consegue se movimentar,
consegue viajar com maior conforto, com maior tranquilidade.
Então, com o desenvolvimento ágil, não é que a gente não leva nada,
mas a gente procura viajar leve, a gente tenta levar com a gente a menor quantidade
de documentação possível e focar naquilo que realmente vai agregar valor.
Então, por exemplo, se você estar indo para lugar que vai fazer calor,
para quê que você vai encher uma mala de roupa de frio?
O que às vezes acontece muito; você acaba fazendo
monte de documentação que ninguém nunca usa.
Mesma coisa você estar carregando na sua mala coisas que você não vai usar.
Então é isso, né?
A gente viu a importância aí de focar no software funcionando
ao invés de estar focando ter monte de documentação.
Afinal, que documentação melhor de como o software funciona do que ele próprio?
Certo?
Então é isso, muito obrigado, até a próxima aula!
[MÚSICA] [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.
