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
Como não Fazer Diagramas
Loading...
En provenance du cours de Instituto Tecnológico de Aeronáutica
Princípios de Desenvolvimento Ágil de Software
129 notes
À partir de la leçon
Semana 4
Olá, bem-vindo à Semana 4 do Curso 4 – Princípios de Desenvolvimento Ágil de Software. Ao final deste módulo, você terá aprendido a usar de forma pensada diagramas apropriados na modelagem ágil; terá aprendido também princípios de modelagem ágil e como integrar o TDD no sprint do Scrum. Adicionalmente, você será exposto ao processo adotado, Scrum&XP, na preparação ágil do projeto por meio de um Sprint Zero e a uma forma mais detalhada sobre o Sprint Planning. Você também irá exercitar todo o conhecimento aprendido neste curso e no passado ao desenvolver uma pequena aplicação com gamificação!
Rencontrer les enseignants
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[MÚSICA] [MÚSICA] Olá a todos.
Meu nome é Eduardo Guerra, este é o curso Princípios de Desenvolvimento Ágil
de Software e hoje vamos falar sobre como não utilizar diagramas.
Muita gente acha que o desenvolvimento ágil,
ele é incompatível com a utilização de diagramas.
Na verdade, ninguém chegou e falou assim, isso tudo aí que vocês estavam
trabalhando engenharia de software durante muito tempo não presta mais para nada.
Então, os diagramas podem sim ser muito úteis,
só que muitas formas que eles são utilizados, às vezes, não são adequadas.
Então, nessa aula a gente vai falar que os principais erros, os principais problemas
que a gente encontra quando as pessoas estão utilizando diagrama.
O que é que as pessoas estão fazendo de errado?
A gente vai começar vendo isso hoje.
Bom, acho que o erro básico que
a gente vai acabar vendo que tudo acaba girando torno disso é o cara
que cria ali o diagrama só porque o processo disse que ele tem que criar.
Ou seja, você vai passar pela fase quando chegar na tarefa tal,
você vai fazer diagrama de classe referente a tal coisa.
E o cara vai lá e cria aquilo só porque o processo disse para ele criar.
Está vendo esse camarada aí?
Então, para mim ele é mais ou menos isso aí, é aquele cavalinho
ali que tem aquele negócio que não deixa ele olhar para o lado.
Ele fica limitado àquilo que o processo diz para ele muitas vezes
sem se preocupar com para que é que aquilo vai ser utilizado, qual que é
a utilidade daquilo para o projeto, o que é que aquilo vai agregar de valor.
Então a gente tem que tomar cuidado para não chegar num processo preditivo e falar
que as pessoas precisam fazer diagrama ou precisam fazer alguma coisa, e as pessoas
fazem sem nem questionar ou sem nem saber porque é que aquilo ali está sendo feito.
Esse é dos principais problemas.
Pode até ser que no momento que aquele processo foi feito,
pensou-se nesses objetivos dos diagramas mas se a pessoa
que está fazendo o diagrama não sabe disso como que ela
vai tentar atingir objetivo que ela não sabe com a tarefa que ela está fazendo?
Então, tenho certeza que quem colocou aquilo ali sabia o objetivo mas quem
está fazendo muitas vezes não sabe, e muitas vezes também para aquela equipe
aquilo ali não serve ou para aquele tipo de software aquilo não vai ser tão útil.
Então, vamos ver como essa
questão básica de criar diagramas sem nem saber porquê ou como,
simplesmente seguindo o processo, como isso daí pode ser prejudicial.
Então, muitas vezes a gente não se questiona,
para que é que vai servir esse diagrama, qual que é o escopo dele?
Às vezes simplesmente a gente vai colocando tudo que tem,
não sabe quem vai utilizar, para que é que a pessoa vai utilizar.
Às vezes, a gente sabendo que a pessoa vai utilizar a gente sabe que tipo de detalhe,
que tipo de coisa tem que ir ou não.
Então, vamos lá.
Às vezes a pessoa cria e está ali perdida, aquele nosso amigo aí, certo?
Está ali sem saber porque é que está criando aquilo,
chegou aqui, tenho que criar diagrama de estado.
Aí vai lá, sem saber porquê, cria lá o diagrama.
Opa, chegou aqui o diagrama de classe.
Deixa eu identificar aqui os substantivos, os verbos igual aprendi lá.
Cria aqui as classes, nem sabe quem vai usar aquilo nem sabe porquê,
nem sabe que tipo de detalhe aquela pessoa precisa.
Então se você está fazendo diagrama,
alguém está fazendo diagrama e você pergunta,
para que é que é isso daí e a pessoa não sabe responder já tem uma coisa errada.
E outra coisa, não saber as necessidades de quem vai utilizar aquele diagrama.
Muitas vezes se faz diagrama com informações a mais ou a menos da
pessoa que vai estar utilizando.
Às vezes ela precisaria de uma coisa muito mais simples.
Às vezes muitos dos detalhe que você vai colocar ali vão ser jogados fora,
a pessoa vai desprezar e vai fazer do jeito dela.
Então, talvez aquilo ali pudesse até ajudar mas,
às vezes tem coisas a mais ou tem coisas a menos também.
Às vezes tipo de relacionamento, preciso colocar aqui a multiplicidade
desse relacionamento, é para muitos, é para.
Isso vai ser útil para a pessoa?
Essa é a informação que ela está buscando nesse diagrama?
É só entender pouco melhor os relacionamentos,
precisa de botar o método?
Precisa de botar o parâmetro do método?
E às vezes também tem diagramas que eles têm uma certa utilidade durante
tempo e depois aquilo ali não faz mais sentido, seja porque modificou,
seja porque era para gerar entendimento e aquele entendimento já foi gerado.
Então, as pessoas, é assim é sacrilégio você fazer
diagrama e não guardar ele para sempre aí, para muita gente.
E as pessoas às vezes não se questionam por quanto tempo a gente tem que
manter esse diagrama.
Durante quanto tempo ele vai ser útil.
Pode ser que chegue o momento que aquele diagrama que foi muito importante numa
parte do projeto vai deixar de ser útil e aí, não faz sentido eu ter uma
equipe e dispender esforço para manter uma coisa que não está agregando mais valor.
Às vezes até, você pensar sobre alguma coisa é
útil você ir num quadro ou num papel e fazer diagrama.
Mas é diagrama que você não precisa ir lá e gastar tempo para fazer ele
numa ferramenta e tal e depois ficar guardando e mantendo aquilo,
porque aquilo ali já cumpriu o objetivo de melhorar o seu entendimento sobre
aquilo ali ou validar aquilo com outras pessoas ou comunicar aquela ideia que às
vezes era mais difícil ser comunicada sem o diagrama.
Muitas vezes a gente não pensa no tempo que no ciclo de vida,
quanto tempo esse diagrama é útil e quanto tempo ele tem que existir.
E aí, uma outra pergunta.
Como que você faz esse diagrama?
Muitas vezes a pessoa, não é usando ML,
vou usar tudo o que tiver e vou colocar tudo o que puder.
Mas às vezes não é uma resposta trivial.
Então, às vezes você ter detalhes demais ali
acaba tirando o foco daquilo que a pessoa precisa.
Eu me lembro, por exemplo, projeto que eu participei que a gente fez diagrama de
classes que só tinha o nome das classes, porque era domínio complexo e simplesmente
a gente saber o relacionamento entre as coisas era muito útil.
Quais métodos tinha, quais informações tinha, isso aí era detalhe,
não era o foco ali.
Eu lembro que a gente fez esse diagrama, a gente atualizava ele,
pregava ele na parede e utilizava ele sempre.
Se ele tivesse muitos detalhes, todos os métodos e tal ia ficar
negócio enorme e ia tirar o foco do que era o principal que era entender
melhor o relacionamento entre as entidades ali do sistema.
Então a gente antes, quando a gente sabe o objetivo do diagrama,
a gente tem que pensar qual que é o nível de detalhe que é importante que ele tenha
para que a gente possa cumprir esse objetivo.
Às vezes você, não, mas eu estou colocando coisas a mais,
às vezes a coisa que você bota a mais,
além de tirar esforço desnecessário vai tirar o foco daquilo que você precisa.
É a história que eu costumo falar,
se alguém te pergunta: me recomenda livro sobre o tal assunto.
Se você recomendar livro a pessoa vai comprar e ler,
se você recomendar dez, não, mas eu estou dando mais opções.
Pois é, mas a pessoa às vezes não sabe julgar e não vai ler nenhum.
Às vezes quando a pessoa bater o olho naquele diagrama que tem monte de coisas
vai falar, não, melhor eu perguntar para alguém ou olhar direto no código.
E às vezes por ter informações a mais o diagrama deixa de atender o objetivo dele.
Às vezes outro erro é usar ferramentas mais complicadas do que você precisava.
Ir lá e pegar ferramentas Case ou de desenho, altamente complicadas
e perder tempo ali, às vezes para diagrama que é só para gerar entendimento,
só para comunicar alguma coisa com outros membros da equipe.
Às vezes o quadro branco, ele é uma ferramenta importante,
ou simplesmente papel às vezes se você está querendo pensar melhor ou às
vezes discutir alguma coisa com a sua dupla, com seu par,
isso daí pode ser bem importante.
Você ter como fazer essa discussão,
ter esse diagrama que você pode discutir cima dele.
E às vezes não precisa de uma ferramenta muito sofisticada para isso.
Depois, se vocês acharem que aquilo ali vale a pena ser guardado e mantido para,
que aquele entendimento vá sendo evoluído, você pode até passar para a ferramenta.
Mas naquele momento, talvez a ferramenta vá te deixar mais lento,
talvez não é o momento para tomar essa decisão, se aquilo ali vai ser útil
ou não, mesmo porque aquilo ali na hora da implementação pode até mudar.
Quando a gente falou aí do pre-programing a gente falou daquela discussão inicial
das ideias, de como são as coisas e tal, isso aí pode ser muito útil.
Nessa hora o diagrama é muito importante, mas não numa ferramente super sofisticada,
às vezes num quadro branco, uma folha, ele vai fazer seu papel de
servir ali como uma ferramenta de comunicação entre os membros da equipe.
E por fim,
eu vejo muita gente pegar diagrama e tentar colocar todas as informações nele.
Então, por exemplo, pega diagrama de classes que mostra a estrutura
estática e começa a botar uns balõezinhos para a explicar a dinâmica.
Não, pô!
Existem outros diagramas para isso, como o diagrama de sequência, por exemplo.
Aí o cara começa a botar ali umas observações
dizendo as classes ali dos estados e aí explicar.
Não, pera aí.
Vamos criar então diagrama de estado aqui,
não precisa de querer num diagrama só fazer tudo.
Isso aí é erro que eu vejo também,
a pessoa quer botar todas as informações num diagrama só.
Às vezes para comunicar uma coisa, às vezes você pode usar diagramas diferentes.
Vamos usar aqui pedacinho do de classes, faz mais pequinininho aqui de sequência,
a gente mata isso aqui.
E aí a gente deixa claro como isso vai funcionar.
Então, pense também que não existe tipo de diagrama só,
por motivo e utilize todos que você puder, que vá funcionar
melhor baseado naquele objetivo que você tem fazendo aquele diagrama.
Então, não fique preso num diagrama só, pode ser que seja necessário mais de.
Então, resumindo, os diagramas eles são uma
ferramenta importante sim, apesar deles não serem
o foco e não serem obrigatórios quando a gente usa desenvolvimento ágil.
Eles podem sim, ser uma ferramenta que a equipe vai utilizar,
mas eles têm que ser utilizados de forma inteligente,
eles têm que estar alinhados com as necessidades do projeto, não pode sair
utilizando ele aí simplesmente porque o processo disse que você tem que utilizar.
Então, eu espero que essa aula tenha conseguido mostrar para
vocês algum dos erros ao se utilizar diagramas projetos
e nas próximas aulas aqui vamos falar pouquinho mais sobre a modelagem ágil,
como o diagrama se encaixaria aí num contexto ágil.
Muito obrigado.
Até à próxima aula.
[MÚSICA] [MÚSICA]
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2018 Coursera Inc. Tous droits réservés.
