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
Erros em Planejamento de Software
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
Princípios de Desenvolvimento Ágil de Software
138 classificações
Explore Related Videos
At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you
Instituto Tecnológico de Aeronáutica
138 classificações
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] Olá a todos.
Meu nome é Eduardo Guerra.
Esse é o curso dos Princípios do Desenvolvimento Ágil de Software.
Nesse módulo vamos falar de planejamento, uma coisa extremamente importante.
Como planejar, como seguir o planejamento e como sempre vamos começar jogando pedra.
Vamos falar dos principais erros que as pessoas têm na hora de fazer o
planejamento de software.
Então, vamos lá.
Eu já vou começar aqui falando.
A engenharia de software ela digamos, das engenharias,
talvez seja uma das engenharias mais recentes.
Talvez perca para a Bioengenharia, algumas coisas assim,
mas é uma das engenharias mais recentes.
E o que aconteceu?
Quando ela apareceu ela meio que tentou pegar ideias de outras
engenharias já existentes.
Por exemplo, uma engenharia civil, onde você tem que ir lá fazer o
projeto da casa, validar, antes de começar a construir.
Então, os processos de desenvolviemento de software pegaram essa noção.
E realmente se a gente parar para pensar, se a gente chegar e falar assim,
olha chega essa parede aqui uns 20 centímetros para lá,
isso daí porque tem negócio que não está cabendo aqui.
Isso é difícil, é caro, vai ter que quebrar,
às vezes tem uma viga aí que inviabiliza.
Então, realmente para outros tipos de engenharia
pode ser mais complicado você fazer aí o desenvolvimento mais incremental.
Mas para software não.
Muita gente talvez conteste a afirmação de que o software,
ele é mais flexível mas talvez nem todos sejam.
Mas a questão é que software, ele pode ser mais flexível se a gente
utilizar as técnicas que a gente tem visto aí nesse nosso programa aí que é o TDD,
a Refatoração, utilizar as boas práticas de código,
uma boa modelagem orientada a objetos, modularização.
Usando tudo isso a gente consegue fazer o software ficar flexível.
Não é fácil, exige disciplina,
exige várias técnicas mas é possível deixar o software mais flexível
de forma a conseguir construir ele de forma incremental, de forma a dar
sempre alterando o que existe antes e fazer isso de uma forma sustentável.
Diferente de outras engenharias.
Então, tratar o software como outras engenharias, que primeiro
você tem que fazer o projeto e depois fazendo tudo de uma vez, isso aí é erro.
A construção não tem que ficar por último,
é possível criar o software de forma que a gente possa fazer as coisas de uma forma
mais dinâmica justamente devido a essa flexibilidade maior do software.
Outra coisa, tentar enxergar além do que você consegue.
O cara está fazendo planejamento, acha aí que é o Wild dos Thundercats,
que tem ali a visão além do alcance, que vai botar a espada justiceira
lá e vai conseguir ver o que é que a equipe está fazendo daqui a ano.
Não dá, né.
Fala uma coisa, se eu chegar para você e perguntar o quê que você vai fazer amanhã,
você vai conseguir me dizer com uma certa, talvez não com certeza,
mas você já vai ter talvez uma noção do que você vai fazer.
Se eu perguntar, daqui a uma semana o que você vai estar fazendo?
Daqui a mês, o que você vai estar fazendo?
Daqui a ano, o quê que você vai estar fazendo?
Não tenho menor ideia o quê eu vou estar fazendo daqui a ano.
Então não adianta você querer fazer uma planejamento para muito no futuro,
principalmente porque se alguma coisa mudar nesse meio do caminho,
você vai ter que refazer isso tudo, é trabalho perdido.
Então, a ideia é que o planejamento detalhado seja feito só a curto prazo.
Então o que acontece?
Lá para o longo prazo,
essa figura eu já mostrei aí quando a gente estava falando do manifesto ágil.
Mas eu volto com ela aqui porque isso é muito importante.
Ali no longo prazo você tem uma visão de onde você quer chegar mas você
sabe que o cliente ainda pode mudar muita coisa.
Você tem ali no médio prazo para talvez aqui nos próximos dois meses,
três meses, ali alto nível, mais ou menos quais são os objetivos da equipe
alcançar e talvez no curto prazo, para uma ou duas semanas na frente, no máximo,
você tenha aquele detalhamento de quais as user stories que você vai fazer.
Quais são as tarefas de cada user story,
para você ter esse controle mais fino, mas só nesse curto prazo.
Quando que eu vou fazer o próximo planejamento?
Esse próximo planejamento você vai fazer quando
terminar a interação com base no que você aprendeu.
Então, às vezes você tentar fazer uma planejamento muito para a frente,
você está deixando de utilizar o conhecimento que você vai ganhando no
começo do projeto sobre a tecnologia, sobre o que é fácil de fazer.
O conhecimento sobre os membros da sua equipe,
olha o fulano consegue fazer isso rápido, ciclano é mais devagar nessa parte.
Então, tudo isso são informações importantes que fazem com que com o tempo
a gente vá fazendo essas estimativas com mais precisão.
Outro erro, você impor deadlines.
O cara está fazendo o planejamento e falar, essa tarefa aqui é duas horas.
Ou chegar para o cara, quanto tempo você faz isso?
O cara falar, eu acho que eu preciso de cinco horas,
vai e fala assim, vou botar aqui quatro horas que dá.
Já vi muita gente fazer isso.
Lógico que você pode conversar, você tem certeza que é cinco horas, porquê,
me explica.
Se você acha que o tempo está muito grande, quer negociar, conversa,
tenta entender porquê das cinco horas.
Propõe para ele acordo, vê se ele aceita aquilo ali.
Mas não impôr.
Muitas vezes isso aí é erro muito sério.
Quem faz a estimativa não é quem vai fazer o software.
Como é que o cara vai saber?
Muitas vezes o cara não é nem técnico.
O cara chuta ali, pega de histórico, não é assim que funciona.
Você fazer isso, você está pedindo para o projeto atrasar.
Então, é aquela coisa, você é que sabe o tempo que você precisa.
Você chega ali recebe a tarefa, isso aqui vai ser uma tarefa para x horas.
E aí você olha e fala assim, é nunca que eu vou conseguir cumprir isso aqui.
E aí acontece o contrário também.
O cara fala assim, o cara pediu dez horas para essa tarefa aqui.
Olha, eu consigo fazer cinco, então posso fazer com tranquilidade.
Então o cara vai e estica para fazer nas dez horas,
ao invés de acabar rápido e pegar uma outra tarefa.
Então, é sempre ruim quando não é o próprio desenvolvedor que faz aquilo ali.
Então, você querer impor planejamento, querer impor tempo de forma que
você às vezes não tem as informações que o cara que é o desenvolvedor, que ele sabe
do conhecimento dele, ele às vezes conhece melhor a arquitetura e ele saberia estimar
aquilo de uma forma muito mais precisa do quem está fazendo o planejamento.
Você querer impor ali o tempo é você pedir para atrasar o projeto.
Isso aí é fato.
Outra coisa é a forma que se mede.
Uma vez eu lembro que chegou o gerente de projeto e falou, o projeto está atrasado.
Porquê?
O fulano ele está trabalhando na tarefa e ele falou que estava 50% da tarefa pronta.
Pelo tempo era já para ele estar 80%.
Que é 50%, quê que é 80%?
Ás vezes a gente acha que falta só pouquinho, na hora de integrar
tudo a gente gasta muito mais tempo do que a gente gastou na tarefa inteira.
Acontece isso.
Esse tipo de previsão, eu divido aqui a, b, c e d.
Se o cara fez a, b e c, então o cara fez 75%, pronto, é assim.
É esse tipo de medida de progresso aí também não é realista.
E muitas vezes, quando se faz isso se trabalha às vezes com tarefas de 20 horas.
Às vezes que, quê que é 80% de 20 horas,
ou então a gente mede pelo tempo que o cara trabalhou.
Essa tarefa estava prevista para 20 horas, o cara já trabalhou dez, então está 50%.
Eu já vi vários desses erros de você medir o progresso de uma forma completamente
imprecisa e que não condiz com a verdade.
É aquela coisa, às vezes os 10% finais demoram muito mais do que o resto.
Ou depois das 20 horas o cara vai descobrir que precisa de mais 20.
Então, a gente não pode pensar dessa forma.
Com software não é, por exemplo, igual uma parede que o pião está levantando e se
ela já está 80% na altura, você fala, está faltando mais 20.
Software não é assim que funciona.
O cara faz tantas linhas de código, está faltando 50 para ele terminar,
está faltando tanto tempo.
Não é assim que funciona.
Às vezes numa linha de código,
para você descobrir qual a linha que tem que ser ali, meu amigo, demora.
Então, você acompanhar o
projeto às vezes de uma forma não realista, às vezes ou coloca
na equipe uma pressão desnecessária ou cria uma falsa sensação de segurança
que mais para a frente vai ser destruída e vai pegar todo o mundo de surpresa.
Outra questão é você querer fazer o planejamento igual o
nosso amigo está fazendo aí, na pedra.
O cara fazer planejamento para ninguém alterar,
pensando que aquilo ali é, sei lá, o cara escreveu na pedra.
É negócio que se mudar está errado.
Não, na verdade eu costumo dizer que a única certeza que a gente tem quando
a gente faz planejamento é que não vai ser daquela forma.
Então, a gente tem que fazer o planejamento tendo consciência
de que aquilo ali pode mudar e a gente tem que fazer o planejamento de uma forma
que seja fácil a gente se adaptar, a gente consiga lidar.
Até mesmo as equipes ágeis mais maduras fazem as estimativas,
às vezes até cumprem ali o fizeram no tempo proposto,
mas às vezes porque acaba equilibrando de uma estimativa ser pouco maior,
outra pouco menor e aí as coisas acabam se equilibrando no final.
Mas exatamente daquela forma muito difícil de acontecer.
Então, a gente tem que pensar no planejamento como guia,
como uma referência e não como uma coisa escrita na pedra que a gente não pode.
Deixo para vocês essa frase, "Nada está escrito na pedra".
Então, a gente não pode considerar que o nosso planejamento não vai mudar.
Porque ele vai mudar e se a gente encarar ele como uma coisa
estática e que a mudança desse planejamento é uma coisa ruim,
é uma coisa que não deve ser feita, isso aí vai acarretar uma série de problemas,
desde desenvolvedores escondendo informações, fingindo que está tudo bem,
até mesmo você às vezes tem trabalho muito grande para acertar tudo depois.
Então, pense no planejamento como guia, como uma referência,
e não como script que tem de ser exatamente daquela forma.
Então, nessa aula que falei alguns dos erros do planejamento de projeto
de software e nas próximas aulas a gente vai ver aí como fazer as estimativas,
prioridades e tal, dentro aí de projeto de software.
Muito obrigado, espero você na 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.
© 2019 Coursera Inc. Todos os direitos reservados.
