Tipos de Tasks

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

Princípios de Desenvolvimento Ágil de Software

131 classificações

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

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.

Implementando uma User Story5:20

O Que é Task?3:30

Características de uma Task4:28

User Story vs Task4:56

Tipos de Tasks7:36

Benefícios em Quebrar User Stories em Tasks7:19

Conheça os instrutores

Clovis Fernandes
Professor Titular in Portuguese
Ciência da Computação
Eduardo Guerra
Professor Colaborador

[MÚSICA] Olá!

Bem vindo ao curso Princípios de Desenvolvimento Ágil de Software.

Eu sou o Clóvis Fernandes e na aula de hoje iremos apresentar tipos de tarefas,

ou seja, ao final da aula você terá aprendido alguma maneira de,

que vai facilitar você a desenvolver,

a quebrar as user stories tarefas.

Uma maneira muito usual, mas que não é a que nós

iremos usar, é que eu uso o fluxo do desenvolvimento de software.

Então eu faço a análise disso, eu faço o projeto daquilo,

codifico aquilo outro, testo isso e aquilo e assim por diante.

Isso é uma maneira de fazer,

inclusive nós vamos usar esporadicamente isso na maneira como a gente vai propor.

Mas a maneira que nós queremos mostrar para vocês é usando a arquitetura camadas,

ou seja, normalmente o software é desenvolvido camadas

tem essa arquitetura, no caso aqui eu estou usando a arquitetura três camadas.

Se o software fizer uso da arquitetura camadas,

nós vamos mostrar que fica muito conveniente usar essa

arquitetura para guiar a definição de tipos de tarefas.

Suponha então que eu esteja querendo fazer a definição

das tarefas da user story Fazer login,

normalmente o quê que acontece com a user story, se eu quero implementar

eu vou fazer para fazer com que essa user story seja implementada,

às vezes eu tenho que fazer algum código na camada

de interface com o usuário, a camada de apresentação, pode ser que eu tenha que

fazer alguma coisa com a camada de regras de negócio, que vem logo a seguir,

e pode ser que eu tenha que fazer alguma coisa com a persistência,

o banco de dados, que eu vou lidar com banco de dados ou códigos que são comuns,

usados pelas camadas superiores.

Nós encontramos user stories que vão fazer isso.

O quê que acontece?

A gente chama isso de, quando ela vai da primeira camada até a última,

a gente chama isso de fatia vertical, ou seja, eu vou ter user stories,

muitas user stories que vão fazer isso, desde a apresentação até a parte

de persistência, eu vou ter que desenvolver código para isso.

Então tem que ter tarefas para fazer isso todas essas camadas,

realizando coisas todas essas camadas.

Vão existir tarefas que vão ocorrer

apenas na camada de apresentação, outras vão na camada de apresentação e na de

regras de negócio e outras como essa Fazer login, que vai acontecer nas três camadas.

nós vamos então começar a mostrar que tarefas eu posso definir para essa

user story a partir da apresentação.

Então na apresentação eu posso por exemplo colocar uma tarefa que

corresponda a projetar a interface de login.

Ou seja, às vezes eu quero fazer uma coisa inovadora, alguma coisa diferente,

então eu vou projetar isso, como é que eu quero fazer esse login?

Pode ser da maneira mais usual,

mas de qualquer maneira pode ser que para esse problema específico,

essa aplicação específica, o login seja feita de uma determinada maneira.

No caso aqui eu estou pensando fazer login simples, pois vão existir logins

que eu posso fazer via o Twitter, via o Facebook, o Dropbox ou coisa que o valha.

A segunda tarefa seria implementar essa interface do jeito que eu projetei e

a terceira, testar a interface que eu tiver implementado.

Já pela regra de negócio eu posso estar querendo, por exemplo,

projetar como fazer para implementar esse Fazer login.

No caso do login, vai ser uma coisa não muito complicada mas pode ser que tenha

uma responsabilidade simples, não muito complicada, vamos assim dizer.

Mas pode ser que haja uma responsabilidade mais complicada que fazer login,

que talvez eu precise fazer projeto, ver as classes que são existentes,

ver como é que eu posso integrar isso dentro do que já estava existente.

O segundo é codificar o Fazer login.

Se eu precisei projetar alguma coisa, eu vou usar isso na minha codificação,

mas agora o codificar o Fazer login,

eu tenho a responsabilidade eu vou usar fazendo o TDD.

Outra coisa que eu posso fazer também, quando eu faço no caso de fazer login,

é que todo password, todo password que o usuário envia,

logo de cara ele é criptografado.

Hoje eu poderia, eu tenho linguagem que permite que eu faça essa criptografia

lá no nível de apresentação, mas não é muito seguro.

Então é melhor fazer nesse nível aqui.

Então eu vou criptografar o password também usando o TDD,

porque isso aqui, criptografar o password é uma

nova responsabilidade que eu também vou desenvolver.

Eu vou realizar o teste de integração e testar a funcionalidade dentro

dessa camada, é só como o código existia nessa camada de regras de negócio.

Agora vamos fazer a divisão olhando a infraestrutura e persistência,

uma delas eu vou implementar busca de dados do usuário e de password,

porque se eu fizer login, eu suponho que o usuário já esteja cadastrado,

aí então tem que fazer uma procura e é isso que eu vou fazer.

Eu vou implementar essa busca.

Eventualmente talvez precisasse até fazer também determinado projeto,

dependendo do que eu for fazer, nesse caso é muito simples.

Aí eu vou realizar o teste de integração e salvar os dados de login.

São coisas que eu posso estar querendo fazer aí nessa parte de persistência.

Como o dado já existe, já foi vamos dizer assim: a parte de banco de dados já foi

feita porque ele está lá cadastrado, é só uma busca do banco de dados,

eu não preciso implementar nada novo no banco de dados aqui para esse exemplo.

Uma coisa que tem que ficar claro é que olhando isso eu vejo que eu

tenho agora que fazer a integração de todas essas camadas,

e aí então eu vou ter teste de integração de todas as camadas.

Eu vou testar a funcionalidade agora olhando todas as camadas e finalmente,

uma coisa que toda user story tem, que são os testes de aceitação,

eu vou fazer os testes de aceitação, olhando assim a camada fica muito mais

tranquilo da gente definir os vários tipos de tarefas que

eu devo cumprir para cada user story.

Com isso você apreendeu que usando a arquitetura

camadas isso facilita muito eu criar tipos de tarefas

os mais apropriados para cada user story que eu precisar implementar.

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.

Baixar na App Store

Baixar no Google Play