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
Dinâmica de uma Iteração
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
Princípios de Desenvolvimento Ágil de Software
128 ratings
Na lição
Semana 3
Olá, bem-vindo à Semana 3 do Curso 4 – Princípios de Desenvolvimento Ágil de Software. Neste módulo você aprofundará seus conhecimentos sobre os papeis do Scrum; terá aprendido como quebrar user stories em tarefas; e terá seus primeiros contatos com o planejamento de um sprint/iteração, com um hands-on interessante sobre o uso do Planning Poker para estimar o esforço/tamanho de user stories.
Conheça os instrutores
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[MÚSICA] [MÚSICA] Olá a todos,
meu nome é Eduardo Guerra e estamos no curso de Princípios de
Desenvolvimento Ágil de Software.
Nessa aula vamos falar pouquinho sobre a dinâmica da interação.
A gente falou de planejamento, falou de priorização,
agora como que isso aí é executado, como que a gente acompanha isso?
Isso é extremamente importante, o coração do desenvolvimento ágil.
Nessa aula vamos falar sobre como isso acontece.
O planejamento ele é executado interações.
A gente diz que essa interação acontece num time box,
por isso que tem esse relógio e essa caixinha aí, horrível.
Mas tudo bem, o que é que é o time box?
Ele é intervalo de tempo fixo, significa que eu não vou aumentar ele, ele é fixo.
O que pode acontecer é eu não conseguir executar tudo mas logo que ele terminar
eu vou ver o que aconteceu, o que deu errado, etc e vou começar novo time box.
Então a interação não tem essa de esticar pouquinho mais, é intervalo fixo.
Essa interação é o que o Scrum chama de Sprint.
Que é que precisa ter para ser Sprint?
Tem que ser curto não pode ser negócio de,
estou fazendo Sprint de três meses, você tá chamando errado.
Idealmente é de uma semana, 15 dias, no máximo, no máximo mês, não recomendo
mas tem gente que faz Sprints de mês, mas recomendo aí no máximo 15 dias.
Ele tem de entregar valor,
não é passou 15 dias eu fiz aqui todas as classes que acessam banco de dados.
Isso aí para o cliente não interessa, ele quer ver funcionalidade completa, ele quer
ver coisa funcionado, se não entregar valor, se no final não tiver uma entrega
que o cliente possa ver e possa aprovar e possa olhar, isso aí não é Sprint.
E precisa ter o ciclo de desenvolvimento completo.
Não é virar e falar assim, não vou fazer o Sprint aqui para escrever User Story,
depois eu vou fazer o Sprint para criar diagrama.
Não, não é isso.
Ele tem o ciclo de desenvolvimento completo.
Você vai desde pegar os requisitos e implementar,
testar, fazer todos esse ciclo dentro dessa uma semana,
para poucas funcionalidades e, no final entregando esse valor para o cliente.
Então, não tem essa de vou pegar ali aquelas baleinhas lá do hoop e vou dividir
várias, por mês ou cada 15 dias chamar de Sprint e vou ter Sprint só para escrever.
Não, isso não existe, ele tem que ter o ciclo de desenvolvimento completo ali
desde o zero até a entrega de funcionalidade para o cliente com teste,
com tudo o que precisar ser feito.
E a quantidade de User Stories vai de acordo com a velocidade do time.
Como a gente viu na parte de planejamento,
com o tempo a gente vai saber quantas Story Points ou quantas horas ideais
nosso time consegue fazer e com isso, com o tempo a gente vai aprimorando isso aí,
vai melhorando as estimativas e aí, provavelmente lá para a quarta,
quinta interação você já consegue fazer planejamento com muito mais precisão.
Então, eu vou sair aqui para vocês poderem ver essa tabela aqui mas já volto.
Então, a execução das tarefas, elas tem que ser acompanhadas durante a interação.
Uma forma de você fazer isso, por exemplo, você tem ali a User Story,
você tem as tarefas dela, você tem as horas ideais que elas foram estimadas,
quantas horas foram efetivamente trabalhadas e a restante.
Repara que o primeiro ali, ele cumpriu o que estimou,
ele estimou dez e conseguiu fazer ali o dez.
O banco de dados, note que ele estimou oito e trabalhou 12 e conseguiu terminar.
No controller aconteceu uma coisa diferente,
ele estimou 12 mas seis ele conseguiu terminar.
Olha o caso do último ali, por exemplo, ele estimou sete, ele
trabalhou cinco só que ele estima que para terminar aquela tarefa ainda faltam cinco.
Então, a gente sempre trabalha com o quanto que está faltando.
Então, lembra que eu falei daquela questão lá das porcentagens e tudo mais?
Então, essa é uma forma melhor de fazer,
ao invés de falar quantos porcento você já fez.
Você pergunta quantas horas ainda faltam para terminar.
Pode ser que você tenha estimado cinco e agora faltem dez.
Você começou a trabalhar e viu que o problema era bem maior.
Não tem problema.
O importante é a equipe estar ciente disso e ter tempo suficiente para
agir cima desse imprevisto que aconteceu.
Então, todo o controle ele acontece
cima do quanto já foi trabalhado e o quanto que ainda falta.
O quadrinho do Kanban que a gente tem ali as tarefas, os to do,
ou os que estão sendo feitas e as que já foram concluídas é uma forma bacana.
O pessoal usa os quadrinhos com post-it, uma forma bacana de você acompanhar e
tornar aí esse acompanhamento da interação uma coisa visível para todo o mundo.
É uma prática comum ter as daily meetings, reuniões diárias onde as pessoas vão lá,
dizem o que fez, atualizam o quadrinho, atualizam as horas e para que
a equipe tenha uma noção de como que está o andamento da interação.
Esse quadrinho do Kanban,
ele pode ter outras não precisa ser só essas três,
ele pode ter outras colunas, pode ter uma,
por exemplo, relacionada a se foi feito o teste.
A gente pode ter a coluna aqui bloqueado, que é a coluna quando tem
alguma coisa externa impedindo a equipe de fazer aquilo.
Aí as pessoas já vão olhar e falar,
opa, eu tenho que correr atrás senão eles não vão conseguir fazer esse negócio aqui.
E aí eu posso ter várias, de acordo com o mecanismo de trabalho,
até mesmo com o feedback da equipe eu posso ir tendo várias fases,
várias colunas ali nas quais as minhas tarefas
vão andando até poderem ser consideradas concluídas.
E gráfico muito comum da gente trabalhar é o Burndown Chart.
Que é que ele faz?
Ele mostra a quantidade de horas faltantes por dia.
Note que ele pode até dar uma aumentadinha ali no caso, por exemplo,
de eu ver que uma tarefa, ela não foi bem estimada e atualizar a estimativa.
Por exemplo, eu posso fazer uma tarefa e com aquilo concluir que
outras parecidas vão ter agora uma estimativa maior.
Então, eu posso ir lá e atualizar.
A todo o momento, no mínimo,
uma vez por dia eu estou atualizando essa questão das estimativas e das horas.
Lembra que não é muita coisa, é tarefa para uma semana ou 15 dias só,
então, dá para fazer esse tipo de controle.
É o que eu falei.
Para o curto prazo o planejamento é detalhado.
então, no Burndown Chart a gente tem uma noção do que é que a gente trabalhou,
como que estão a estimativa de horas e se a gente, pelo andamento,
consegue ver se a gente vai conseguir concluir ou não.
Se a gente vê que o Burndown Chart, ele está indo para cima,
ele está se distanciando muito dessa linhazinha cinza,
que seria mais ou menos a minha referência
do que seria o ideal o normal é ficar ali permeando,
ás vezes pouco mais para cima, pouco mais para baixo daquela linha.
Se eu ver que está saindo muito fora, que acontece?
Eu vou terminar a interação que eu sei que a minha equipe não vai conseguir concluir,
que eles vão ficar estressados, vão ficar chateados no final.
Não! Às vezes foi erro de planejamento,
às vezes é nas primeiras interações, o pessoal não sabe fazer direito.
O que é que eu vou fazer?
Eu paro a minha interação, eu faço uma retrospetiva, converso com as pessoas,
vejo o que está errado e aí a gente replaneja e começa uma interação do zero.
É a melhor forma, que aí a equipe se sente zerada e se sente muito
mais motivada de fazer aquelas tarefas naquela nova interação e para
tentar cumprir ou chegar perto do objetivo no final.
No começo pode ser realmente necessário, às vezes surge imprevisto.
Pode ser necessário esse replanejamento e aí é melhor não mexer
aí com o seu bem mais precioso que é a sua equipe.
Não mexa com o bem estar psicológico dela.
Zere tudo, comece de novo e a equipe vai começar nova interação motivada,
agora que ela teve a oportunidade de repensar,
ela vai aprender com aquele erro de estimativa para conseguir efetivamente
cumprir o que foi proposto para ela dentro daquela interação.
E aí é importante no final de cada interação, ter uma retrospetiva,
levantar o que funcionou, o que não funcionou.
Na verdade, as metodologias ágeis, elas são uma referência.
Mas você tem que fazer o seu processo.
O processo é dinâmico, o processo é adaptativo, então,
você tem que ver o que funcionou, o que não funcionou, o tipo de estimativa,
se você precisa de mais uma fasezinha lá no seu Kanban.
Às vezes uma tecnologia que você está usando, tipo de refatoração, deu certo,
não deu.
Como que faz o teste disso?
Desse jeito não ficou legal.
Então, tudo isso você pode colocar na retrospetiva para que a cada interação
a sua equipe esteja evoluindo e trabalhando cada vez melhor.
Eu tenho amigo que diz que se você está fazendo ágil hoje da mesma
forma que você fazia ano atrás você não é mais ágil.
Porquê? Porque você parou de evoluir.
Isso é muito legal.
Então, espero que nessa aula tenha dado para entender melhor como que funciona
essa dinâmica de uma interação e como casar isso com o planejamento,
esse acompanhamento aí do quê que foi planejado.
Muito obrigado.
Até à próxima.
[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.
