Blog

Scrum Remoto: Praticando Planning Poker

Olá Pessoal,

O post de hoje é bem mais uma dica. Mas a pergunta é: como fazer estimativa se meu time está remoto? Ou melhor, como se beneficiar do planning poker?

Lets go..

Starting…

Aqui na ITS temos projetos presenciais e remotos, mas a maioria é remoto, ou seja, o time trabalha de casa. Depois farei um post sobre como é o nosso trabalho remoto. Voltando ao problema, como fazer as estimativas com planning poker se o time está remoto? Pesquisando sobre alguma ferramenta que pudesse nos auxiliar, encontrei http://www.planningpoker.com/ realmente sensacional. Além de ser free, é muito simples de usar. Aqui na ITS estamos usando a ferramenta e está sendo uma boa experiência.

Como funciona?

  1. Você faz o cadastro, que é simples e rápido;
  2. Você escreve a estória;
  3. E dá um start;

As cartas aparecem e você escolhe a sua estimativa. Quando todos estimarem, o resultado aparece e o time discute. Se for aceito, a estimativa é associada com User Story.

Simples, não?

Era isso que queria compartilhar com vocês, mais uma experiência com gerenciamento de projeto Scrum Remoto.

Abraços, See ya!!

Série Scrum Remoto: Adotando uma ferramenta online ideal para o time

 

Opa Pessoal, 

Vamos a mais um post da série Scrum Remoto. Nesse primeiro projeto aqui na ITSLabs com Scrum remoto realmente não sabíamos qual ferramenta adotar, e como há várias no mercado e algumas se demonstraram até como a solução ideal, preferimos analisar com cautela. 

Lets go…

Qual a ferramenta ideal para Scrum? 

Ouço e vejo muito essa pergunta. Eu digo sempre que não há ferramenta ideal. Uma que funciona bem para um determinado projeto e equipe, pode não funcionar bem para outra. Em um ambiente físico eu ainda gosto de ter as coisas na parede, quadro, etc. Mas e em um time remoto? Aí temos que usar uma ferramenta que pode ser uma planilha eletrônica, uma aplicação, um software desktop, etc. A escolha é da equipe. Mas qual adotar? Vou pelo custo ou por aquela que é famosa na comunidade?

O custo tem que ser analisado sim, e nem sempre o mais caro é o melhor. Pense nisso sempre. O mesmo vale para a segunda pergunta, o fato de ser famosa na comunidade também não quer dizer que é a melhor, e o fato de todo mundo usar não quer dizer que é a ideal ou a melhor do mundo. Há estratégias de marketing por detrás de qualquer produto e é preciso extrair e olhar apenas para o produto seco. É o que faço sempre antes de adquirir qualquer produto, busco identificar essa parte, ignorar e tomar uma decisão com base na razão e necessidade.

E como eu fiz aqui na ITSLabs?

Aqui tínhamos um problema como esse. Uma lição que aprendi é não tomar uma decisão corrida para a escolha da ferramenta apenas porque o Sprint 1 começa amanhã. É uma decisão importante e cara, mas também não posso deixar o team sem nada e as informações precisam estar compartilhadas de alguma forma para termos um tracking do Sprint corrente e saber como estamos indo. E pesquisando no velho Google achei um template feito no Microsoft Excel que parecia atender ao que precisávamos enquanto não tínhamos uma ferramenta ideal para o nosso time. Vejam o template dela:

scrumxls

Claro que não íamos ficar trocando emails com essa planilha, daí, o que usar? O dropbox. Então sempre que ela for atualizada todos são notificados.

O problema

Na planilha que encontrei acima descobri que é ideal para um projeto pequeno e rápido, mas não se encaixa no nosso. Por quê? Simples. Como fazer o tracking de todos os Sprints? A cada release os investidores querem saber como fomos nas últimas 3 Sprints. Quanto tempo gastamos, número de bugs, etc. Iai o que fazer? Mandar cada XLS do Sprint por email e dizer para ele olhar? Ou melhor, criar um novo XLS com essas informações compiladas e mandar pra ele. Mas terei que fazer isso a cada release, e quanto tempo vai custar para isso?

Outro problema que tivemos com a sincronização do DropBox: em alguns casos não funcionava bem. No IOS não atualizava às vezes e aconteceu de um membro da equipe ficar com  o XLS desatualizado.

Em projetos que já trabalhei com Scrum, já usei várias ferramentas, muitas já eram default nas empresas, outras estavam em testes, etc (como Jira, Scrumworks, IceScrum, Mingo etc), mas para o projeto que estou agora a ferramenta ideal foi a Rally pelo seguinte ponto:

– Atende ao nosso projeto;

– O team achou muito fácil de usar e ela se encaixa bem para o nível do projeto;

– Customização da tela;

– Custo x benefício;

É possível saber como as coisas estão muito facilmente.

O que precisa melhorar? 

– Sincronização. Se uma informação é atualizada, é preciso dar reload na página para ser atualizada; a ferramenta deveria atualizar automaticamente;

– Adicionar novo usuário. Se o usuário tem cadastro no rally, não conseguimos adicionar ele ao projeto. Acho que a ferramenta deveria permitir buscar usuários já cadastrados e adicionar ao projeto.

Depois de uma análise, decidimos usar a ferramenta no Sprint 2. Fizemos alguns testes antes com projetos fake para entender e ver se realmente nos ajudaria.

Conclusão 

Nessa busca de ferramenta online para projetos Scrum descobri que não importa a ferramenta que você usa, mas sim se o time está confortável com ela e se a mesma agrega valor para o seu projeto. Não adianta querer empurrar uma ferramenta para o time ou projeto só porque alguém do comercial fez um bom negócio com a criadora da ferramenta. O motivo? A ferramenta pode atrapalhar a equipe, principalmente na curva de aprendizado. Outro aprendizado que ficou é que para cada projeto o melhor é sempre analisar qual ferramenta se adéqua melhor, usar um X tudo pode ser mais fácil, e em alguns casos parece ser mais barato, porém hoje há varias opções onde que você contrata serviços apenas para o que precisa e acho que ter a ferramenta ideal por projeto é mais importante do que querer ter uma ferramenta “for all”.E lembrando que as pessoas são mais importantes que as ferramentas, não adianta investir milhões em aquisição de ferramentas “inovadoras” enquanto não se valoriza e não investe nas pessoas.

Vou ficando por aqui. E você, qual ferramenta Agile tem usado em seus projetos? O que tem considerado para a escolha?

Abracos, see ya!

Série Scrum Remoto: Fazendo retro usando realtimeboard

Olá Pessoal,  

No post de hoje da série Scrum Remoto vamos ver como fazemos as nossas retros na ITSLabs. Era um ponto que não fazia ideia como faria ao iniciar o projeto, mas sabia que deveria achar uma solução antes do final do primeiro Sprint.  

Lets go… 

Como fazer retrospectiva com time remoto? 

Essa é uma pergunta que muitos devem fazer e que eu também fazia, mas um dia reservei 1hr do tempo para buscar ferramentas que pudessem auxiliar para atingir esse objetivo, pois não bastava ter uma conferência sem saber como o time ia colocar os posts-its. Aí veio algumas ideias do time: 

– Podemos usar o google docs e criar uma planilha e as respectivas colunas: Good | Bad | Should be better.  Assim todos iam vendo;  

– Podemos usar o whiteboard e desenhar como fazemos fisicamente.  

E então, qual delas? 

 Para ser sincero não estava confortável com nenhuma das opções acima. Elas seriam minha última opção e eu queria algo melhor, com um custo x benefício aceitável dentro do orçamento do projeto.

RealTime Board 

Esse cara ai foi a melhor solução que achei e caiu como uma luva. Muito bom. Ele tem templates prontos e um deles era o KanBan. Algumas vantagens que identifiquei:

– Podemos ter 3 projetos private; 

– Sem refresh em browser ou algo do tipo; atualização realmente em tempo real; 

– Nada de share de tela; 

– Muito fácil de usar; 

– A versão paga possui um custo x beneficio aceitável;  

Vejam a seguir como foi a retro da Sprint 0 e o time todo colocando os posts-it remotamente durante a call. 

retrosprint

Fantástico, não? 

Conclusão 

Achei o RealTime uma ótima ferramenta quando queremos refletir um ambiente fisico KanBan em um ambiente remoto, e para quem já estava acostumado não vai sentir diferença.

E você, como tem feito suas retrospectivas com time Scrum remoto? 

Abracos, see ya!!!

Série Scrum Remoto: Team remoto com Scrum rola ou não?

Olá Pessoal,

Estou começando mais uma série no blog e a ideia é compartilhar com vocês o que venho aprendendo no meu último projeto, que é ter um time Scrum 100% remoto. Será que rola?  Não é difícil achar essa discussão e ouvir opiniões bem diferentes. No final do post eu vou dar a minha. A ideia da série é compartilhar o aprendizado, e a cada post da série vou compartilhar com vocês como foi a última Sprint e a semana do time. As Sprints são curtas, não duram mais que 2 semanas. Não pretendo entrar nos detalhes durante os posts e também vou omitir informações confidenciais de negócio do projeto. Dúvidas? Deixem nos comentários.

Lets go…

Starting…

Eu venho trabalhando em projetos Scrum desde 2011, mas sempre foi presencial, ou seja, o time estava alocado fisicamente, e o melhor: todos bem próximos e se possível na mesma mesa.  Mas mesmo assim sofríamos de vários problemas que não está realizado ao framework. Até porque o Scrum não te diz como vamos implementar as soluções para cada problema que temos.  E já ouvi muito isso aqui:

“Scrum só funciona se o time estiver fisicamente junto”

“Scrum não funciona remoto, não tem como fazer daily meeting e nem um quadro de como estão as coisas”

“Não dá para fazer Scrum usando ferramentas on line, já o framework diz que não devemos usar ferramentas” (sério que diz isso? Nunca vi isso).

Enfim, há muitas outras que é comum ouvir por ai. Mas iai, rola ou não rola?

Minha Experiência – Projeto Case

Eu sempre tive essa dúvida, mas nunca afirmei alguma das frases acima ou algo parecido, até por que é complicado afirmar algo assim já que há N variáveis. Mas agora estou em um desafio onde recentemente (julho/2013) entrei em um projeto onde todo o desenvolvimento será remoto e usaremos Scrum framework como ferramenta.

É isso mesmo que você está pensando, a daily meeting, planning etc, será tudo remoto. Não tem como os membros do time estarem fisicamente no mesmo local, a única coisa em comum é o timezone, por ser um projeto nacional.

Quando caí no projeto, apesar de já ter trabalhado assim, mas não usando Scrum, eu parei e pensei: “e agora, como será tudo remoto?”

Começando…

Começamos o projeto agora no inicio de agosto, pois em julho foi mais preparação do ambiente, equipe, reuniões estratégicas, budget e coisas administrativas do projeto. Depois de algumas semanas em reuniões para resolver assuntos administrativos, e também o valor disponível para saber onde podemos usar com eficiência, definimos o inicio do Sprint 0, que seria uma Sprint de setup de ambiente, análises tecnológicas e pequenos testes.

O que fizemos no Sprint 0

Aqui definimos se íamos ter um ambiente de desenvolvimento local ou remoto com base no nosso budget e optamos em ter tudo usando cloud computing, pois foi o que saiu melhor em custo x benefício. Para isso temos:

  • Integrator VPN (show de bola o serviço oferecido, vou fazer um post comparando cada solução de cloud que testamos – jelastic, openshift etc)
    • É nele que teremos nosso ambiente de continuous integration, deploy para test e homologação.
    • GitHub  (repositório privado)
    • RealTime Board: usamos esse cara para evitar compartilhar a tela e ter um whiteboard em tempo real. É fanstástico. Dá para usar um kanban nele. Usamos para retrospectiva. Mas usamos ele na Sprint 0 para jogar todas as tasks que tínhamos que fazer para preparação de ambiente.
    • Planning poker: usamos para estimativas das estorias
    • Rally Dev: de ferramenta online, usamos e aprovamos. Vai ter um post exclusivo.

Por enquanto é isso que precisamos para iniciar o Sprint 1. Vamos adicionados mais soluções à medida que avançamos nas entregas, adicionando mais carne no  esqueleto do projeto.

Vou escrever um post sobre como montar um ambiente de desenvolvimento remoto visando custo x beneficio.

Os problemas

Nem tudo são flores. Como o team é novo com Scrum e algumas soluções técnicas como o Git, GitHub, CI etc, preciso respeitar o tempo de aprendizado e ensinar aos membros como o Scrum funciona, a importância de usarmos Git e termos um ambiente de CI,  etc. Então não tenho a velocidade de entrega do meu time, não sei se eles são capazes de entregar 5 ,10, 15 pontos por Sprint, e não quero pressioná-los para entregar de qualquer jeito, já espero que até o terceiro Sprint eles se adaptem e errem bastante. Duvido também que consigam fazer o Sprint passar, mas considero esse tempo como investimento e aprendizado: quanto mais cedo eles errarem e aprenderem melhor.

E o tamanho do Sprint? Ainda não sabemos também, é outro problema. Como definir se o team é novo, se estamos remotos e ainda preciso ensinar aos poucos sobre o Scrum, ambiente etc? Dificil, né? Usar o fator foco pode não funcionar, porque não trata só se está focado na task e sim outros fatores. Iai o que fazer? Nada. Pega a primeira estória que está no topo do product backlog e coloca para o time fazer, mas não crie expectativa que será entregue e não pressione sua equipe para vender a alma e entregar a estória. Isso pode frustrar os iniciantes e bloquear o aprendizado deles. E você não quer isso. Quer que eles aprendam no menor tempo possível.

Outro problema foi encontrar uma ferramenta scrum. Há varias no mercado, porém o mais importante é escolher aquela que se adapta bem ao seu time, e não adquirir uma que é famosa. Então minha primeira decisão foi não adotar uma ferramenta online antes do Sprint 1. Daí usei um XLS que gera o burndown e é compartilhado via dropbox. Só isso.

E no final rolou ou não?

Por incrível que pareça rolou. Tínhamos reuniões diárias, extra meeting, planning e retro, tudo remoto usando o Google hangout. Terminamos o Sprint 0 com o ambiente de desenvolvimento pronto, ou seja, todo o setup finalizado e apto para começar a desenvolver na Sprint 1. Nesse timebox do Sprint 0, o team pode discutir e testar várias soluções e frameworks que seriam utilizados no projeto e  decidir qual seria o ideal para o nosso projeto e o porquê. Cada um tinha que defender a sugestão e no final o time entrava em um consenso e a tecnologia era escolhida. Não temos uma pessoa que vai enfiar a tecnologia pela garganta do time, quem vai decidir somos nós. E foi muito divertido ver a discussão do que usar ou não e cada um defendendo. O melhor de tudo foi que sugiram tecnologias que os membros do time não têm conhecimento e nunca trabalharam, mas que é o ideal para o projeto e será adotada. O team agora é responsável por aprender a tecnologia e fazer o bom uso para atingir o objetivo final que temos até o final do ano.

Conclusão

Não importa se você faz scrum presencial ou remoto, o mais importante é o seu time. Esse sim é quem define se vai funcionar usando Scrum ou qualquer outra técnica Agile. Claro que a estrutura base para o time trabalhar é importante e ajuda, mas não define. Aqui trabalhamos com uma estrutura mínima e usamos muitos serviços de cloud computing que nos ajuda a não ficar preocupados em gerenciar ou cuidar de atividades administrativas. Aquilo que não é importante para o negocio, mas é importante para o projeto, buscamos automatizar. Por exemplo, ter um servidor local. Talvez financeiramente seja barato, caso já tenha o servidor na empresa, mas você tem vários problemas relacionados em cuidar desse servidor; se você tem na cloud evita vários micro trabalhos que não agregam valor ao negócio.

Vou ficando por aqui. Até o próximo post da série.

Abraços.

UFC e Desenvolvedor de Software

 
Olá pessoal, 
 
O post de hoje é mais uma reflexão para que você possa começar a analisar os conhecimentos e direções que tem tomado na sua carreira. Para isso, vou fazer uma analogia com o esporte criado por um brasileiro e que hoje é um dos mais famosos no mundo, o UFC. 
 
Lets go…
 
Mas qual a relação do UFC com o desenvolvedor de software? 
 
Na verdade, o UFC pode estar relacionado a muitas outras profissões, mas limitei nesse post ao desenvolvedor de software. Sim, mas qual a relação? 
Toda.
 
Vamos lá entender o que e como é o UFC. Não vou contar a história de como tudo nasceu, mas veja aqui: http://estatico.globoesporte.globo.com/2013/20anos-UFC1/ e entenderá todo o restante do post.
 
Resumindo…
 
Você já viu algum lutador de UFC saber apenas uma arte marcial? Normalmente não. Lutadores de UFC sabem cada arte marcial e quando juntam tudo se tornam bons competidores, o que eles chamam de “completo”, ou seja, um bom lutador de UFC precisa ser completo e não ter preconceito com outras artes marciais, o que no passado existia muito tanto que se ouvia dizer que boxe era melhor que capoeira, ou que o Karatê era melhor que X, e por ai vai. Isso refletia que um lutador de boxe jamais iria treinar ou querer pelo menos praticar um esporte que não fosse boxe. Ele passava a vida tentando ser o melhor no boxe, mas no final ainda não se tornava o melhor, pois a única habilidade que ele tinha era com os braços, se tivesse que “resolver um problema” no chão ele se desesperava e não sabia o que fazer porque o negócio dele era lutar em cima.
 
Mas no UFC, com um lutador assim, acredito que a luta não dura muito tempo, pois um verdadeiro lutador de UFC deve estar preparado para qualquer tipo de luta, seja no chão, em pé, usando o braço, a perna, etc. E para isso eles precisam adquirir habilidades de várias artes marciais e saber como usar. Um lutador de UFC não treina para ser o melhor ou perfeito em uma arte marcial, mas ele aprende muito bem, pratica e domina ela. Não fazem o feijão com arroz, mas aprendem de verdade, e quando começam a juntar as artes marcais eles se tornam lutadores completos e preparados para enfrentar qualquer situação. E eles falam: “ser completo” “é preciso ser completo”. Observe sempre a entrevista de um lutador de UFC, todos tem isso no seu DNA. Se não for completo não sobrevive, mas para ser completo exige tempo, disciplina e persistencia. Você não aprende Muay Thai em algumas horas ou praticando alguns golpes (só porque fez um crud na linguagem de programação, não quer dizer que aprendeu). Para aprender, terá que treinar todos os dias, errar, aprender com o erro, melhorar o que já aprendeu, ter disciplina e não desistir quando não consegue aplicar um determinado golpe por falta de habilidade.
 
Mas qual a relação com o Desenvolvedor de Software ?
 
Muita. Quantos desenvolvedores você conhece que sabe apenas uma linguagem e fecham os olhos para qualquer outra? Quantos ainda acham que a linguagem que ele sabe é a melhor do mundo? Parece a visão do passado de que o karatê é melhor que o boxe ou o contrário. Eu já tive o prazer de conhecer e entrevistar alguns desenvolvedores assim, e certamente seria um desenvolvedor que não faria parte da minha empresa, projeto ou time, assim como uma academia de UFC não aceita lutadores que não estão dispostos a aprender outras artes marciais e querem apenas melhorar aquela que já sabe. 
 
Um desenvolvedor precisa ser completo, conhecer (e não ter a informação apenas) mais de uma linguagem, tecnologia e aprender usar para resolver problemas específicos (se você tiver no chão dificilmente vai poder usar as técnicas do boxe para sair de lá). Fechar os olhos para outras tecnologias é o mesmo que apenas saber lutar quando a luta está em cima ou quando está no chão, se mudou o cenário você fica desesperado e não sabe o que fazer, tentar usar uma técnica do boxe quando está no chão, além de dificil, o impacto será pouco e a saída daquela situação pode não ser rápida, mas há necessidade é pra ontem.
 
Cada linguagem de programação (Ruby, Python, Java, Php, .net etc) é uma arte marcial. Você precisa aprendê-las de forma que esteja pronto para ir a um UFC Combate. Se você sabe apenas Java ou Ruby, arriscaria ir para o UFC Combate? 
 
Mas tudo depende do que você quer. Deseja se tornar um UFC Developer Software, ou seja, um desenvolvedor completo? Se sim, vai precisar ter paciência, disciplina, treino e persistência. Mas se seu objetivo é se tornar um bom lutador de boxe, karatê, etc, a história é outra, mas lembre-se que qualquer lutador de UFC tem a capacidade de te ensinar qualquer arte marcial com propriedade, até porque ele precisa garantir que aprendeu bem cada arte. Você precisa aprender bem cada linguagem de programação. Apenas fazer um Hello World ou CRUD não vai te dar conhecimento e experiência suficiente para ir ao combate. 
 
Eu particularmente não conheco tantas linguagens de programação. Comecei a programar com vb 6, em 2003, fiquei por 2 anos, depois fui para php 4 e fiquei por mais 2 anos full time e estou no Java desde 2007. Em termos de números não são tantos comparados com a quantidade de linguagens de programação que temos, mas cada tempo que vivi, em cada linguagem busquei exercitar, praticar, estudar e aprender com os erros. 
 
Algumas exigem mais tempo de aprendizado, prática e perserverança; outras menos tempo. O java e a plataforma, por exemplo, não se aprendem da noite para o dia. Para se tornar um especialista leva-se um certo tempo, não só de estudo, mas passando por projetos que buscam resolver problemas diferentes. Apesar de eu ter me dedicado bastante ao Java (e foi de onde o blog nasceu), não quer dizer que não olho para o Ruby, Python, node.js, etc, e que eu tenho a visão fechada para essas tecnologias, pelo contrário, tenho muita vontade de praticar essas artes marciais, estudar, me envolver, e nunca passou pela minha cabeça que Java é melhor que Ruby ou o contrário. Acredito que cada uma resolve um problema de uma forma melhor ou não, depende se estou lutando em cima ou no chão. Hoje vejo a importância de ter aprendido bem outras linguagens e as ter vivido por um bom tempo. É como um lutador de UFC fala: “quando você junta todas as artes marciais, você se torna completo e se torna imbatível”. Eles tem o hábito de dizer que são imbatíveis e isso é uma forma psicológica de treinar o cérebro de que eles são capazes de ganhar, porque se eles pensam “tenho chances de ganhar”, isso impacta na atuação deles durante a luta, é apenas uma forma de treinar o cérebro. Dificilmente você vai ver um lutador de UFC dizer que ele pode tentar ganhar ou algo do tipo. 
 
Outro ponto que gosto de dizer é que conhecer tecnologias e saber codificar são apenas 50% do que um desenvolvedor de sofware deveria saber fazer bem. Entender de negócio, lidar com comunicação etc. serão distribuidos nos outros 50%. Não há coisa pior que um desenvolvedor de software que não entenda como um mundo dos negócios funciona, pois nem tudo é codificar na vida. Se você é bom tecnicamente, mas você não entende de negócio, você atingiu apenas 50% e não é completo. Um lutador de UFC não faz negócio, normalmente tem empresários, mas ele entende a mecânica do negócio. Você como desenvolvedor não necessariamente precisa saber como fechar negócio, mas entender como funciona. 
 
Ainda quando era novo achava que só o lado técnico era importante dominar. Eu tive 2 empresas e as duas faliram. Perdi dinheiro, mas ganhei experiência e vi a importância que o mundo de negócio tem. Depois dessa experiência amarga que tive, aprendi a viver no mundo dos negócios, seja para fechar um projeto, um salário, discussões estratégias com clientes etc. Aprendi a usar diferentes chapéus de acordo com o contexto, alias aprendi a lutar e buscar resolver o problema dependendo de onde eu estiver, ou seja, se a luta está em cima ou embaixo tenho que buscar resolver com as habilidades que desenvolvi treinando, praticando etc. Tenho a ciência de que alguns negócios vou perder outros vou ganhar, assim como as lutas de UFC são. 
 
Concluindo 
 
Se você é desenvolvedor e ainda acha que sua linguagem de programação é a melhor do mundo e resolve tudo, reflita um pouco e pense se isso é verdade. Ou melhor, veja se você deseja ser um profissional completo ou aquele que sabe apenas uma arte marcial. Mas fique longe de dizer que sabe várias artes marciais porque frequentou apenas 2-3 aulas com programação. Não ache que você conhece a linguagem só porque fez algumas implementações sem se aprofundar. Isso não é conhecimento e não se caracteriza como experiência. Se especialize, aprenda uma e somente parta para outra arte marcial (tecnologia, linguagem) depois que se sentiu seguro em poder ir para um UFC combate. Lembre-se que para aprender qualquer arte vai precisar ter disciplina, perserverança, dedicação e foco. A quantidade de artes marciais que se aprende é importante, mas a qualidade da aprendizagem é mais importante. Não adianta saber 10 artes marciais se não domina nem 5. Certamente se não domina nem 5 dificilmente vai sair com agilidade e inteligência quando estiver preso no chão do combate. 
 
Vou ficando por aqui e espero que tenham gostado dessa analogia que eu fiz. Em muitas partes fiz questão de não referenciar como tratar do lado técnico, assim você consegue pegar o trecho e refletir.
 
Abracos, see ya!!