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
Pareando com Qualidade
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
Princípios de Desenvolvimento Ágil de Software
131 classificação
Na lição
Semana 2
Olá, bem-vindo à Semana 2 do Curso 4 – Princípios de Desenvolvimento Ágil de Software. Neste módulo você aprenderá a criar user stories de forma informal; aprenderá também a fazer coleta ágil de requisitos para a Análise Ágil, que não tenta ser completo de forma antecipada, fazendo questão de definir a visão da aplicação de acordo com o conceito EDUF (Enough Design Upfront – Projeto antecipado suficiente); você aprenderá agora com mais detalhes, no contexto do Scrum&XP, tudo sobre programação em pares.
Conheça os instrutores
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[MÚSICA] Olá
a todos!
Esse é o curso de Princípios de Desenvolvimento Ágil de Software.
Meu nome é Eduardo Guerra e, hoje, no módulo de programação pares,
vamos estar falando aqui sobre pareamento com qualidade.
Então, como eu falei na outra aula, programação pares não é só sentar junto.
Então, vamos ver aí algumas técnicas, algumas coisas que você pode fazer,
algumas coisas para você prestar atenção para que você realmente consiga
extrair todos os benefícios dessa técnica da programação pares.
Então, como eu falei,
programação pares é muito mais do que sentar junto.
Eu vejo muita gente: " nós vamos começar aqui na empresa a fazer programação
pares".
Aí, pega, bota uma cadeirinha do lado, né?
Bota o cara sentado ali e deu.
Obviamente, isso, muitas vezes,
não vai dar certo porque programação pares não é só botar o cara ali do lado.
O cara vai ficar ali perdido, vai ficar mexendo no celular...
Então, da mesma forma que, aí você fala assim: " não.
Mas e o cara que tá programando?".
Ele também pode ter uma atitude que vai prejudicar.
Então, vamos ver aí.
Por exemplo, o copiloto, o cara que está ali do lado,
a ideia dele é que ele fique atento ao código, que ele preste atenção.
Se ele é cara menos experiente, ele procura entender o que está acontecendo,
procura dar a contribuição dele.
Ele não é cara para ficar passivo.
Não é cara pra ficar dormindo ali do lado.
Está o cara lá programando e está o outro lá.
[SOM] Ou, então, está o cara lá no celular.
Não!
O copiloto tem que estar atento ao que está acontecendo e buscando
oportunidades de contribuir.
Por outro lado,
o piloto também tem que dar oportunidade do copiloto contribuir.
Não é o cara pegar ali o teclado e [SOM] Quase rosna,
baba ali cima: [SOM "Meu programa!" [SOM].
E nem olha para o lado.
Que liberdade, que tipo de abertura ele está dando para o colega contribuir?
Então, da mesma forma, o piloto também não pode
abraçar o teclado e querer fazer sozinho enquanto o colega fica ali do lado.
Às vezes, mesmo prestando atenção, o cara fica perdido e não consegue ali uma
brecha para falar alguma coisa ou, quando fala, o cara ignora, dá patada.
Não é assim.
Lembra que ali vocês estão trabalhando conjunto.
Não é nem para o cara que está trabalhando como copiloto deixar o outro fazer e
ficar "passivão", nem para o cara que está programando querer dominar
tudo e ignorar o que o outro está falando.
Se tivermos dois com esse tipo de atitude, aí pronto.
Aí realmente você está jogando recursos fora com esse preprogramming bizarro.
Então, o primeiro passo quando uma dupla
vai se reunir para fazer alguma coisa é ela pegar e discutir como que vai fazer.
Vamos supor: " tem uma funcionalidade que,
por exemplo, vai ter que armazenar uma nova informação".
Aí, por exemplo, a dupla pode começar já falando: "Olha,
onde no banco de dados essa informação vai ficar?
Vamos dar uma olhada nas tabelas.
Olha, tem essa, tem aqui.
Pode criar uma nova tabela.
Pode criar uma coluna nessa tabela.
Para criar uma tabela nova tem que criar relacionamento.
Onde vai estar esse relacionamento?
Agora, temos que criar as classes.
Como que a gente vai criar?
Onde que vai ficar esse método?
Que pacote?
Que classe?".
Então, a ideia da dupla é você,
antes de sentar na máquina, ir discutir.
Às vezes, você pegar quadro branco e fazer pequeno desenho ou numa folha de
papel e tal, mais para orientar vocês, criar checklist para vocês terem
entendimento comum de qual é a solução que vocês vão adotar.
Uma experiência que eu tenho como professor é que muitas vezes,
quando a gente para para explicar uma coisa,
aquela ideia amadurece na nossa cabeça.
Não sei se já aconteceu com vocês.
Às vezes, você chega e começa a explicar uma coisa,
uma ideia que você teve, para alguém: "Ô, fulano!
Tive uma ideia!
Então, se a gente fizer assim, assim, assado." Aí você já fala: "Não,
não vai dar certo".
Ou seja, o fato de você pegar aquela ideia que na sua cabeça pode até fazer sentido,
mas ainda é uma coisa meio abstrata, o fato de você ter que, digamos,
serializar aquilo palavras, uma explicação que outra
pessoa pode entender, faz com que você amadureça aquela ideia.
Às vezes, na hora que você está elaborando isso,
você vê uma inconsistência ou, às vezes, na hora que está elaborando,
você se questiona ou até mesmo você tem outras ideias,
ou você às vezes, percebe que tem algum aspecto ali que, às vezes,
não invalida a sua ideia, mas que você não tinha considerado.
Então, você explicar uma ideia para alguém faz com que ela amadureça na sua cabeça.
" eu acho que aqui a gente podia fazer isso
com o loop assim, assado." E aí, você, às vezes,
tinha na sua cabeça mais ou menos como ia ser aquilo, mas não tinha elaborado ainda.
Na hora que você para para elaborar, para poder explicar para outra pessoa,
aquilo se torna muito mais claro para você mesmo.
Às vezes, a outra pessoa vai, te questiona,
você elabora pouco mais, você explica pouco mais.
Então, isso daí vai contribuindo, essa discussão dos dois lados,
você tendo que elaborar suas ideias, a pessoa questionando ou
dando outras ideias cima, essa troca de experiências faz com que vocês,
na hora de sentar no computador para começar a fazer o código,
já comecem com uma ideia bem legal do que vocês vão fazer e isso já tenha
sido mais ou menos validado pela outra pessoa que está trabalhando com você.
Então, explicar alguma coisa para alguém ajuda muito a amadurecer aquelas ideias.
Então, assim, se você estiver como piloto,
você tem que se preocupar tentar ir narrando pouco.
Você não está criando o código sozinho mais, você está criando com alguém.
Então, você fala assim: "Estou criando essa variável aqui para guardar
contador para o loop.
Olha, essa variável aqui vai guardar o nome do usuário".
Aí, o cara pode falar assim: "Acho que esse nome aí para mim não ficou claro".
Aí, vai lá e arruma.
Então, o piloto tem que tentar ir narrando,
tem que tentar ir explicando o que ele está fazendo: "Olha,
aqui eu estou chamando esse método aqui da lista que faz tal coisa".
" tem tal outro método que pode ser melhor por conta disso".
Então, a pessoa tem que ir narrando porque, no momento que ele está falando
com a outra pessoa, ele dá oportunidade da outra pessoa também estar contribuindo.
Por outro lado, o copiloto ele tem que procurar ali,
também ele tem que lembrar que o piloto está concentrado, então,
não tem que ficar: "Esqueceu uma letra!
Esqueceu ponto e vírgula!
Esqueceu não sei o quê!
Bota pontinho ali!
Apaga espaço que ficou ali!
Olha, ficou desalinhado!".
Não, ele, às vezes, deixa o cara ir pouco mais.
Tem que haver nas pausas ou simplesmente na conversa ali,
ele vai procurando momentos oportunos ali,
onde ele pode questionar, onde ele pode sugerir, onde ele pode dar uma dica.
Então, aquilo que o cara botar
vermelhinho já pode dar uma olhadinha no que ficou e tal e,
na hora que o cara for contar: "Olha, isso aí ou tal coisa ali está errado".
Isso seria uma contribuição.
Então, tem que ter, tanto da parte do piloto,
de tentar narrar o que está acontecendo para dar oportunidade para
essa pessoa contribuir, quanto do copiloto,
também evitar tirar a concentração do piloto de forma desnecessária e também
procurar oportunidades ali onde ele pode tentar contribuir, dando sua opinião e,
justamente, saber tudo o que o piloto está falando ajuda bastante nesse sentido.
E não é tentar ali e ficar o dia inteiro como piloto e o outro como copiloto.
A ideia é que haja uma rotação entre esses pares.
Momento, quem era o piloto vira o copiloto.
Exemplo clássico: num momento que, por exemplo,
o piloto tem pouca experiência numa parte e o copiloto está
praticamente narrando para que ele vá digitando o código,
está praticamente digitando ali o que ele está fazendo, talvez é uma boa hora
do copiloto assumir como piloto e o piloto assumir a posição de copiloto.
E é saudável, também, mesmo que isso não aconteça,
que eles tenham desempenho suas tarefas,
façam essa rotação para que todo mundo tenha a oportunidade de programar, todo
mundo tenha a oportunidade de aprender e contribuir de diferentes formas.
Essa parte da rotação dos pares é muito importante.
Então, espero que essa aula tenha mostrado pouco mais sobre como o
pareamento com qualidade não é fácil porque envolve pessoas.
Pessoas com diferentes personalidades, com diferentes facilidades e dificuldades,
tanto do ponto de vista técnico quanto do ponto de vista social,
mas essas atitudes, explicar isso para a equipe é
extremamente importante se você quer botar isso na prática e não simplesmente
botar essas pessoas sentadas uma do lado da outra e falar: "Te vira aí".
Certo?
Então, é isso.
Continuamos na próxima aula com mais detalhes sobre a programação pares.
Muito obrigado!
[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.
