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
Colaboração com o Cliente
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
131 classificações
Na lição
Semana 1
Olá, bem-vindo ao Curso 4 – Princípios de Desenvolvimento Ágil de Software! Estamos contentes que você esteja aqui para ter os primeiros contatos com modelagem ágil de software. Neste módulo introdutório, você será apresentado ao Scrum&XP, uma combinação apropriada do Scrum com o XP. Ao final deste módulo você também terá aprendido sobre Manifesto Ágil, user stories e visão da aplicação.
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.
Estamos de volta no curso Princípios de Desenvolvimento Ágil de Software.
Hoje vamos falar sobre a colaboração com o cliente,
o terceiro item do manifesto ágil.
Então nessa aula a gente vai entender como é que essa colaboração com o cliente
é importante, e como é que a gente pode deixar o nosso projeto mais produtivo,
focado nas coisas certas e não
ficar brigando com o cliente a partir ali dos contratos.
Então, vou colocar aqui qual é que é o princípio
que está lá no manifesto ágil é que a gente deve dar mais ênfase na
colaboração com o cliente do que na negociação de contratos.
Obviamente, eu não estou falando para ninguém não ter contrato nenhum
com o seu cliente.
Mas, talvez você ficar usando o
contrato como escudo, ou como uma forma de às vezes,
tirar vantagem do cliente no caso de ele pedir algum tipo de mudança,
isso pode ser ruim, e às vezes você pode até ser que entregue o projeto,
talvez não da forma exatamente que o cliente quer, mas aí por exemplo, aquele
cliente nunca mais vai querer trabalhar com você, ele vai sair insatisfeito,
porque às vezes o projeto não vai ser exatamente do jeito que ele quer.
E não é esse o objetivo.
O objetivo é que a sua empresa ou a sua equipe possa fazer o software e que
consiga que o cliente saia satisfeito no final do projeto com aquilo que ele tem,
e que aquilo seja útil para ele utilizar.
Então, frases, que a gente escuta aí.
"Ai, esses clientes nunca sabem direito o que eles querem, às vezes,
eles pedem monte de coisas que não fazem o menor sentido,
que não está na hora, que não tem lógica, e tudo o mais.
E aí o que é que acontece?
A gente vai, faz do jeito que eles pediram,
e aí depois eles querem mudar tudo de novo, colocar novas coisas,
sem que isso dê tempo para a gente trabalhar cima do software.
Ou seja, ai, eu quero mais isso." Só que o tempo para você fazer não muda.
Então toda essa questão, essa rixa aí dos desenvolvedores,
das equipes com os clientes, muitas vezes fazem com
que a gente considere os clientes ali uns inimigos, ali.
"Pjew!
Pjew!
O cara está querendo mudar o requisito ali.
Pjew!
Pjew!
O cara ali pediu negócio que não tem nada a ver.
Pjew!
Então, como se fosse o cliente querer atrapalhar tudo.
E aí acaba sendo nossos inimigos, nossos adversários nessa história.
E aí, que é que a gente faz?
Qual é que é a nossa proteção?
São os contratos.
O pessoal acaba usando ali o contrato como escudo,
de que na hora que o cliente falou "Olha, eu quero então isso daqui".
O cara vai lá faz o contrato, de preferência com uma documentação enorme,
como a gente falou na aula anterior, e aí faz o cliente assinar aquilo ali,
que aquilo ali que o software tem que fazer e aí qualquer mudança,
qualquer coisa que o cliente quiser fazer diferente daquilo, você tem o contrato.
" não sei quê..." Pjew!
Pjew! Pjew!
vem ali o disco voador, aqui, né?
Pjew! Pjew!
Pjew! O cara acata o contrato.
Pjew! Pjew!
Pjew! Não, não pode mudar nada.
Pjew! Pjew!
Pjew! para se defender dessas alterações do
cliente.
Como se o cliente estivesse ali para atrapalhar o desenvolvimento.
Olha que absurdo!
Mas, espera aí.
Esse cliente não é o maior interessado que o projeto dele dê certo?
Que tenha sucesso?
Será que logo no começo do projeto quando você está levantando os requisitos e tal,
o cliente tem maturidade para definir aquele monte de coisas?
Será que não é quando ele vê o software funcionando que vai
cair a ficha de algumas questões, quando ele começa a usar o
software que ele tenta simular o uso do software, que ele vai perceber que certas
coisas não estão certas ou que certas coisas não vão funcionar na prática?
Quem aí que já trabalhou com desenvolvimento de software que já não
viu isso acontecer?
Convido vocês aí que tiveram esse tipo de experiências para colocar no fórum,
coloquem aí nas mensagens, compartilhem com os seus amigos as suas histórias.
Eu tenho certeza.
Comigo, eu já vi isso acontecer várias vezes.
Exemplo que eu posso citar, por exemplo, eu tinha lá formulário enorme,
o cara tinha que fazer uma configuração,
aí o cara lá cadastrando digitava tudo, ok.
E aí, o que acontecia?
Ele percebeu que a segunda coisa que ele teria que cadastrar seria muito parecida
com a primeira e aí seria pouco eficiente ele ir lá e digitar tudo de novo.
Então ele poderia abrir o anterior e editar,
mas ele estaria alterando aquele mas o que ele queria era o quê?
Ele queria criar novo a partir de modificações do anterior.
Ele só percebeu isso no momento que ele estava usando o software.
Então, ele falou assim: "Será que não tem aqui uma forma de eu selecionar alguém
e pedir para usar esse como modelo do próximo?" Opa, é uma nova funcionalidade.
O cara percebeu depois, na hora que ele estava especificando os requisitos,
aquilo não veio na cabeça dele, foi na hora de usar que ele percebeu.
Então, eu deixo aí a última pergunta.
Será que não é melhor trabalhar junto com o cliente ao invés de disputar com ele?
Precisa de contrato?
Precisa, principalmente se forem empresas diferentes.
Mas será que tem que amarrar todos os requisitos?
Será que não pode determinar uma forma de trabalho,
determinar modus operandi para quando o cliente mudar de ideia?
De repente, ao invés de ter uma entrega no final,
ter várias entregas e ter mecanismo no próprio contrato que diga como fazer isso.
Tem muito material aí sobre contrato para projetos ágeis aí na Internet.
Muitas vezes há equipes de desenvolvimento da mesma empresa e às vezes
não precisa dessa formalização toda, mas se faz, se cria documentos só
para amarrar o cliente, só para evitar esse conflito.
Então, a ideia do desenvolvimento ágil é você
colaborar com o cliente, falar assim "Olha, é o seguinte, a gente quer fazer o
software o melhor possível para você, só que a gente não sabe." Aqui,
uma ou duas semanas de projeto, três semanas no máximo.
"Está aqui, primeira versãozinha das primeiras coisinhas que você pediu.
Será que é isso mesmo que você quer?" Aí o cara olha.
"Não, isso é diferente, e tal".
Mudança do cliente aqui, é lucro,
principalmente quando é no começo do projeto quando é nas primeiras versões.
Porquê?
Porque essa mudança do cliente vai fazer com que aquele erro não tenha sido
guardado para o final do projeto,
quando o cara era para estar recebendo o projeto final.
Então a ideia aqui é trabalhar junto com ele.
Então, ao invés de tomar todas essas decisões, de obrigar o cliente a tomar
todas essas decisões de requisitos no começo do projeto, ele vai dando feedback,
vai acrescentando, vai priorizando aquilo que é mais importante,
a ideia é que depois por exemplo, passado ano de projeto, pode ser que o que você
entregue não é exatamente aquilo que ele chegou pedindo para você.
Mas com todo o feedback que ele deu, vai ser o melhor produto
possível que a sua capacidade produtiva permitiu você fazer aquele num ano.
E o cara vai estar feliz.
E aí junto com o cliente é possível você ir refinando
o produto e chegar num objetivo que seria impossível sem ele.
Como eu falei, ágil é você responder rápido às mudanças.
É você reagir rápido, é você ver o que o cliente está achando e conseguir
ter tempo para ir adaptando o software de acordo com as necessidades dele.
Lógico que se o cliente começar a alterar demais isso é problema.
A gente tem que sentar e acertar as coisas,
mas sempre colaborando com o cliente, não ignorando os contratos,
mas vamos dar preferência para sentar juntos e trabalhar juntos do que a manter
a distância com o contrato como escudo entre a equipe e o cliente.
Certo?
Então, com isso a gente viu a importância de ter a colaboração com o
cliente e vendo que às vezes focar muito contrato,
você pode até ir lá e receber o que estava combinado, mas você não vai estar
muitas vezes entregando aquilo que o cliente realmente precisa.
Então é isso.
Espero que tenha entendido e espero vocês na próxima aula
com o último item do manifesto ágil.
[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.
