[Painel TDC2011] O que vem depois do Agile?

No ano passado, tive o privilégio de participar do TDC 2011, um evento super massa concebido pela Globalcode,  que contou com o o apoio de grandes nomese empresas da Indústria de Software.
Participei de um painel bem bacana, mediado pelos meus amigos Felipe Rodrigues da Crafters, e Victor Hugo Germano.
O tema da discussão foi O que vem depois do Agile?
Segue a descrição oficial.

A adoção da agilidade tem crescido muito no mercado brasileiro e cada vez mais grandes empresas tem aderido ao seu uso. Isso aumenta sua visibilidade, mas também vai exigindo adaptações nem sempre fáceis ou bem recebidas pela comunidade.
A grande pergunta que surge é: Qual é o próximo passo? O que vem depois do Agile?

Abaixo segue o vídeo do painel

TDC2011 SP - Painel (O que vem depois do Agile) - Domingo, 10 de Julho from Globalcode on Vimeo.

Academia Agile - Do Coaching ao Kanban

 Muitos já sabem que a Globalcode em conjunto com a Fratech  está lançando a Academia do Agile, uma carreira com a carga horária de 108 horas, e composta por 8  cursos que abordam todos os aspectos necessários para formar um profissional ágil.

Código	Nome do curso	Carga Horária	Apostila Demo
AG1	Implantando e liderando equipes Ágeis	12 hs
AG2	Criação de produtos com Requisitos Ágeis	12 hs
AG3	Otimizando a Comunicação através de DDD	12 hs
AG4	Modelagem Ágil de Software	12 hs
AG5	Práticas Ágeis de Engenharia de Software com XP	24 hs
AG6	Gestão de projetos com Scrum	12 hs
AG7	Gestão de processos com Kanban e Lean	12 hs
AG8	Estratégia Ágil para Governança em TI	12 hs
	Resumo da carreira Academia do Agile	108 hs

Serei um dos revisores do material e para as próximas turmas um dos instrutores desta Academia, mas o que posso garantir é que o material foi feito pelos maiores especialistas na área, meus amigos Felipe Rodrigues da Fratech e Manoel Pimentel editor chefe da revista Visão Ágil.

A primeira turma está com 25% de desconto, pelo preço é uma ótima pedida para quem quer conhecer a fundo as disciplinas do Agile.

Segue alguns dos temas que irá rolar em cada módulo.

AG1- Implantando e liderando equipes Ágeis

• Facilitação
• O que é facilitação
• Abordagem cognitiva para facilitar mudanças
• Um breve passeio pela mente humana
• Estimulando a Neuroplasticidade
• Compreensão do Sistema Límbico
• Técnicas de Facilitação durante as atividades Agile
• Os Seis Chapéus do Pensamento
• Feedback efetivo através da janela de JOHARI
• O Que? Para que? E como causar a mudança com a TOC(Theory of Constraints)
• O desenvolvimento da confiança entre indivíduo
• Planejamento de eventos de facilitação
• Coaching
• Objetivo do Coaching
• Desfazendo mitos acerca do Coaching
• Papéis no processo de Coaching
• Condição Humana
• Missão e Ideal
• Valores e Crenças
• Consciência e Responsabilidade
• Perguntas Eficazes para gerar mudanças
• Motivação (verdades e mentiras)
• Vencendo o Inner Game
• FFA (Force Field Analysis)
• Ganhos e Perdas
• Modelo FARM
• Modelo GROW
• House of Change
• Estrutura das sessões de Coaching
• Liderança
• Gestão do tempo para gerar ROE
• Empatia
• Técnica Pomodoro
• GTD - Getting Things Done
• Covey Planning
• Liderança baseada em Coaching
• Coaching para Equipes
• O Coaching num ambiente Ágil
• O que fazer com impedimentos?
• Projeto de aplicação prática de Coaching

AG2 - Criação de produtos com Requisitos Ágeis

• Definição de escopo
• O produto do ponto de vista de negócio
• As dimensões do escopo (Tamanho, simplicidade e aderência.)
• Processo de aprendizado de escopo
• Estado Lean para o desenho de software
• Requisitos ágeis e os casos de usos?
• User Stories
• Modelando Papéis
• Representando desejos com User Story
• Formato para User Story
• O modelo INVEST
• Usando Temas e Épicos
• Features segundo o FDD
• Representando desejos com Features
• O modelo ARO (Ação Resultado Objeto)
• Aplicando a FBS (Feature Breakdown Structure) da FDD (Feature Driven Development)
• Usando Áreas e Atividades
• Priorização por Áreas, Atividades ou Temas
• Definindo o modelo de Entrega
• Estratégia de entrega em alto nível
• Critérios de Aceitação em diferentes níveis
• DoD (Definition of Done) em diferentes níveis
• Monitoramento de resultados
• Aplicando a TOC na engenharia de requisitos
• Documentação pós-projeto

AG3 - Otimizando a Comunicação através de DDD

• Introdução ao Domain Driven Design
• Sinergia entre Domain Driven Design e os princípios Ágeis
• Uma Linguagem Unificada e abrangente
• Visão Arquitetural do Domain Driven Design
• Arquitetura em Camadas
• Objetos de negócio com Domain Objects
• Ciclo de vida dos Domain Objects
• Mantendo um domínio flexível com Supple Design
• Práticas de suporte
• Refactoring em busca de aprofundamento
• Integrando vários domínios com Strategic Desing
• Delimitando os contextos
• Integração entre contextos diferentes
• Estratégias de integração

AG4 - Modelagem Ágil de Software

• Introdução à Modelagem de software
• Modelagem no contexto da agilidade
• Ciclos de modelagem ágil
• Modelagem em equipe
• Visualização do modelo
• Diagramas simples e práticos com Agile Draw
• Modelagem Ágil e UML
• Resultados da modelagem ágil
• Entregáveis

AG5 - Práticas Ágeis de Engenharia de Software com XP

• Introdução ao Extreme Programming
• Modelo cíclico de entrega
• Ciclo PDCA
• Test Driven Development
• O modelo Test First
• Modelando através dos testes
• Relação custo-benefício dos testes
• Behavior Driven Development
• Especificação executável com BDD
• Casos de negócio
• Ferramentas de BDD
• Relatórios de BDD
• Integração Contínua
• Processo de desenvolvimento com integração contínua
• Repositórios de código fonte
• Integração contínua e os testes
• Servidores de integração contínua
• Principios importantes
• Inspeção
• Pair-Programming
• Inspeção segundo o FDD
• A Inspeção e a Definição de Pronto

AG6 - Gestão de projetos com Scrum

• Abordagens Ágeis
• Imergindo no Scrum
• Conhecendo as fases e ciclo de vida do Scrum
• A FDD (Feature Driven Development) e como combiná-la com o Scrum
• Entendendo a influência Lean
• Engenharia de Requisitos para compor um bom Product Backlog
• FBS (Feature Breakdown Structure) da FDD
• Compondo o Product BackLog com funcionalidades
• Planejamento
• Os papeis do Scrum
• O conceito de Sprint
• Entregas freqüentes de valor para o cliente
• Gerenciando Business Value
• Sprint Planning Meeting
• Desdobramento em tarefas
• Características do Sprint BackLog
• Estimativas
• Apostando no Planning Poker
• Descobrindo a complexidade
• Conhecendo o tamanho das coisas
• Trabalhando com estimativas em horas
• Qual a granularidade necessária para as estimativas
• Desenvolvimento
• Scrum Daily Meeting
• Gestão de Impedimentos
• Métricas e Acompanhamentos
• Foco no Escopo ? Entrega de software funcionado
• KanBan para facilitar a comunicação durante o processo
• Conhecendo o BurnDown Chart
• Entregas
• Sprint Review
• Testes de Aceitação
• Melhoria contínua
• Sprint Retrospective
• Uma breve introdução em TOC (Theory Of Constraints) para o Processo de Mudança 
• Imersão
• Durante todo o workshop será realizado um laboratório prático através da dinâmica de construção.

AG7 - Gestão de processos com Kanban e Lean

• Cultura e Filosofia Lean
• O que é Lean
• Pensamento Enxuto
• Impactos econômicos do pensamento enxuto
• Tipos de cenários para o pensamento Lean
• Perspectiva de Consumo
• Geração de Valor
• Eliminação das Perdas
• Respeito e Desenvolvimento de Pessoas
• Ferramentas Lean
• Hansei e Kaizen para melhoria contínua
• Poka-Yoke e Jidoka para ajudar a qualidade
• Andon e Kanban como meio de comunicação
• Gestão Lean
• Planejamento e Gestão com pensamento A3
• WIP (Work-In-Process)
• Pull System
• Visualizando o VSM - Value Stream Map
• O que é Lead Time?
• Identificando Restrições
• Resolução de Problemas com The Five Whys
• Aplicando o clico PDCA
• Definindo demanda
• Definindo tamanho
• Definindo capacidade
• Usando o sistema Kanban
• Adoção
• Aplicação em equipes de projetos
• Aplicações de equipes de sustentação
• Lean/Kanban com Scrum

AG8 - Estratégia Ágil para Governança em TI

• Visão Geral do Ecossistema
• Pessoas
• Processos
• Práticas
• Ferramentas
• Parceiros
• Filosofia e Cultura
• Missão, Valores e Propósito
• Introdução ao Enterprise Agile
• Agile Project Management
• Enterprise Scrum
• Engenharia de Software com FDD
• Lean/KanBan para gestão de processos
• Definindo escopo de atuação para Agile
• Planejamento de adoção/implementação de Agile
• Framework de TI
• Gestão de Demandas
• Gestão de Portfólio
• Gestão de Configuração
• Gestão de Mudanças
• Gestão de Serviço de TI
• Planejamento Estratégico
• Gestão Financeira
• Geração de Conhecimento
• Integrações
• Dialogando com ITIL e COBIT
• Gestão Ágil em ambientes PMBoK
• Agile com modelos de certificação
• Convivendo com processos auditáveis por órgãos reguladores

Pelo conteúdo apresentado acima, é fácil entender o porque este curso é a formação mais completa que existe sobre agilidade não só no Brasil, mas talvez no mundo, abordando temas como DDD, FDD, BDD, TDD, Lean, Kanban, XP, Scrum, passando por Coaching, e Governança em TI.

A primeira turma começa agora dia 26/03, as aulas serão intercaladas de 15 em 15 dias com aulas ás sextas e sábados. Nos vemos por lá!

Diversão Garantida!!! 

Perguntas Frequentes sobre Agilidade

Em Julho deste ano, após o mini-curso que dei na Globalcode sobre Scrum + XP, uma das pessoas presentes, meu amigo Orlando, anotou diversas perguntas sobre Agilidade no formato de entrevista e pediu que eu respondesse por email.
Segue abaixo algumas perguntas que achei interessante, e resolvi publicá-las aqui no blog.

O que é ser ágil nos dias de hoje?

Acho que ser ágil nos dias de hoje é saber aproveitar as oportunidades de inovação no seu ambiente de trabalho, percebo que a maioria das pessoas acabam ficando acostumadas com a rotina de seus afazeres e perdem chances de inovar.
Quando digo inovar, digo que existem várias maneiras de você introduzir no seu dia a dia práticas ágeis. Outro ponto importante em ambiente ágeis é a comunicação, para ser ágil a pessoa saber lidar com pessoas, com o cliente, e ter um relacionamento de parceria, não pode ter medo de se expor e ser comprometido.
Comprometido não é trabalhar 250 horas por mês no projeto, é saber assumir responsabilidades e saber responder por elas, não ter vergonha de pedir ajuda na hora de uma dificuldade. É velha a história do porco e da galinha =).

Quais os pontos fracos das metodologias ágeis?

O que vejo como um ponto fraco em metodologias ágeis, pela sua própria natureza lean, ou seja, enxuta. É que fica um pouco difícil a sua adoção em ambientes que haja modelos de governança de TI como o Cobit, por exemplo. É difícil em um ambiente de Governança "certificado", você justificar para o gerenciamento de projeto o uso apenas de quadros e post-its, entende? Isso eu digo principalmente com Scrum e XP.
Neste tipo de cenário, a empresa tende a escolher modelos híbridos baseados no PMBook e RUP. O que no final acabam se tornando processos altamente burocráticos em cascata.
Por isso, que acho que esse é um campo que tem muito a ser explorado, trabalhei cerca de 2 a 3 com RUP, e uma escolha mal feita nos artefatos de projeto acaba comprometendo e muito o rendimento da equipe
Outro ponto fraco é o próprio agilista, que tende a pensar que é o dono da razão, pois a verdade é que Barry Boehm já falava da importância dos métodos iterativos (  que vieram bem antes do movimento ágil ).

Quando não usar?

Bem, independente do lugar que você esteja é muito importante praticar, aplicar os valores do Manifesto Ágil.
Eu não consigo enxergar o uso de métodos ágeis em projetos de implantação de ERP (pacote comprado), principalmente quando a implantação é feita em grandes empresas com diversas filiais. Geralmente, as empresas fornecedoras deste tipo de software já possuem métodos próprios.
Outra ponto, é se a sua empresa desenvolve software e seu cliente esta feliz, o desenvolvedor esta feliz, os projetos estão sendo entregues no prazo, o ROI esta dentro das expectativas, o Time-to-market do seu produto é baixo e a equipe é produtiva, se neste cenário você já não estiver usando ágil, fique onde está.
Se o seu processo de desenvolvimento esta atendendo plenamente você e seus clientes, então não mude. Você já esta no caminho certo.

O que mais dificulta a implantação de uma metodologia ágil numa empresa atualmente?

Com certeza o que dificulta a implantação de métodos ágeis nas empresas é a própria filosofia de desenvolvimento da empresa. Por requerer uma mudança radical na forma de lidar com o desenvolvimento de software, é difícil alcançar uma plenitude na implementação de métodos ágeis e isto pode afetar sua adoção, é difícil as pessoas envolvidas na definição de processos da empresa admitirem que estavam fazendo algo que é não muito produtivo, e que a maneira que elas desenvolvendo software não é a melhor.
Outros pontos que dificultam a implantação de métodos ágeis, ainda alinhado ao primeiro item é a falta de um sponsor, como um diretor, ou outro cargo executivo, se agile não está "vendido" para a alta cúpula da empresa, então pode haver muita resistência por conta da própria TI.
E por fim, a falta de comprometimento da equipe e a falta de conhecimento em métodos ágeis podem dificultar também a implantação.

Só serve para projetos? E a manutenção do sistema?

Agile proporciona um leque bem variado de métodos, entre eles FDD, Scrum, XP, Lean, Crystal, entre outros. Eu diria que os dois caminham juntos, a questão gira em torno de como você irá administrar e classificar os itens em seu backlog.
A partir do momento que um release do seu produto entra em produção, é natural que novas demandas e até bugs apareçam. Tem empresas que separam equipes para atuar somente em projetos de manutenção e outras equipes para trabalhar somente em projetos de evolução, depende tudo de como o trabalho é priorizado.
Para áreas de serviço, como Infraestrutura, onde a atuação das equipes geralmente é feita sob demanda, é recomendado o uso de quadros Kanban, inclusive atualmente estou fazendo um trabalho neste sentido (Quadros Kanban para áreas de Infraestrutura).

E a arquitetura do sistema, como fica?

Essa é uma questão polêmica e que gera muitas dúvidas para quem está iniciando no mundo ágil, principalmente para as pessoas que estão em transição de um método como o Waterfall para o Ágil.
Quando o time de desenvolvimento vem do Waterfall ou até mesmo do RUP, que é um método que descreve os artefatos necessários para se documentar a arquitetura do projeto e propõe um modelo "big design up front", ou seja, força o time tentar imaginar e fechar todos os modelos no inicio da execução do projeto.
Em processos ágeis isso acontece de forma natural e evolutiva, uma das práticas do XP, o "Simple Design" ou "Design Simples" nos diz para mantermos o nosso design o mais limpo e simples possível, e não tentar imaginar funcionalidades que o sistema possa vir a ter, e preparar o sistema para estes prováveis cenários. Isso foge completamente do modelo ágil de gerir projetos.
Independente do modelo que você segue, o seu sistema obviamente será construída baseada em uma arquitetura, e em toda metodologia é muito importante você fazer o planejamento da sua arquitetura, a diferença é que em métodos ágeis devemos sempre respeitar a maturidade atual do projeto de modo que quando houver mudanças ou adição de novos requisitos do negócio, fique fácil refatorar o sistema, levando sempre em consideração os requisitos de qualidade de serviço (QoS) conhecidos por todo arquiteto,

Como fica o contrato? Não há prejuízos para a produtora, uma vez que o cliente altere constantemente o que foi inicialmente solicitado?

Acredito que não, um dos valores do manifesto ágil diz que a colaboração com o cliente é mais importante do que a negociação de contratos, por que isso? Se olharmos para a maneira como as empresas negociam os contratos de software com as consultorias, veremos que esta é uma eterna luta. Porque as empresas adotam o modelo de "Preço Fixo" e para uma consultoria entrar em uma empresa, ao formular uma RFP ela acaba colocando valores que muitas vezes ela mesma sabe que pode tomar um prejuízo, mas o faz para ganhar o cliente.
Este tipo de contrato é ruim, pois passa a maior parte do risco para o desenvolvedor, se o projeto atrasa, o consultor arca com os custos, o que dificulta (e muito) mudanças de escopo.
Um modelo de contrato que achei muito interessante é o modelo "Money for Nothing, Changes for free" proposto por Peter Stevens em http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts#MFN-cff.

Qual o maior benefício (a longo ou curto prazo) que um funcionário (desenvolvedor, tester, analista, etc.) obtém quando se compromete a seguir uma proposta ágil?

Desenvolvedores geralmente gostam de agile, porque os métodos são voltados para times auto-gerenciáveis. Modelos ágeis dão uma liberdade maior aos membros do time, então acho que o maior benefício é o próprio bem-estar do time. Sem falar dos ganhos da empresa como a melhoria contínua da qualidade, redução do risco de entrega e do time to market, aumento da visibilidade do projeto, entre outros.

Como ser um Scrum Master?

Na minha visão, para ser um Scrum Master é preciso antes de tudo saber lidar com pessoas, isso é fundamental, além disso, precisa ser uma pessoa comprometida e responsável, que entenda os requisitos do negócio e as necessidades do time.
Tem que ser uma pessoa humilde, e que saiba influenciar a equipe de maneira positiva, com uma cultura de colaboração.

Como as empresas do Brasil estão aceitando a XP?

Hoje em dia é moda falar de Agilidade no Brasil, principalmente no meio dos desenvolvedores. O que vejo é que é um assunto muito falado, mas pouco aplicado.
XP tem sido assunto em roda de conversa de desenvolvedores durante muitos anos, e o que acaba sendo feito neste sentido são movimentos individuais de desenvolvedores que aplicam algumas práticas do XP de maneira isolada, principalmente TDD.
Com o advento e a popularidade do SCRUM, pessoas de outras esferas nas empresas estão começando a olhar agile de maneira diferente, e tem havido uma grande aceitação neste sentido, então acho que isso tem sido bom para XP também.

Dê algumas dicas de boas práticas àqueles que estão iniciando (estagiários e estudantes).

A melhor dica que posso dar é a mesma que dou em minhas apresentações quando sou indagado. Que é estudar, e tentar se manter bem informado sobre o que está acontecendo no mercado. É impressionante o que você consegue fazer com os feeds dos websites, busque os melhores sites e agregue-os em ferramentas como o Google Reader ou outro leitor de feed qualquer, isso potencializa muito o conhecimento.
Participe de lista de discussões, veja cases de implantação tanto de sucesso quando de insucesso e buscar ler o máximo que puder sobre o assunto.

Finalize com uma mensagem para aqueles que estão interessados, mas ainda são céticos.

Faça uma prova de conceito, e se possível procure implementar ao menos uma prática ágil. Uma dica que dou é sempre que possível, traga o cliente para o lado do desenvolvimento, se você puder fazer com que seu cliente avalie o produto que você está desenvolvendo semanalmente ou até de 15 em 15 dias, você irá começar a ver os ganhos do desenvolvimento ágil.
Ou ainda, vou ir totalmente contra o que acabei de falar, sempre que olhar para o seu processo atual de desenvolvimento, antes de tentar adicionar qualquer prática ou passo novo (menos a que citei sobre o cliente), exclua uma etapa do seu processo. Monte um gráfico de cadeia de valor dos seus processos, e analise o que você pode excluir de passos do seu processo. Se você fizer isso, você já está no caminho de se tornar um grande agilista!

Scrum + XP = Agilidade eXtrema

Nos dias 07 e 28 de Julho foi realizado no auditório da Globalcode o minicurso Scrum + XP = Agilidade eXtrema, gostaria de agradecer a Globalcode pelo espaço concedido e pela força e também a todos que compareceram, pelo ótimo feedback que recebi.

Para maiores detalhes de como foi o mini-curso acesse o seguinte link no site da Globalcode.

Na apresentação, o intuito foi dar um enfoque teórico e prático de como funciona o Gerenciamento de Projetos Ágeis utilizando XP e Scrum, e no final uma explicação de como combinar as duas.

O que acabou agregando bastante a apresentação foi o próprio público, que iteragiu bastante, com perguntas sobre planejamento e estimativas em projetos ágeis. Foi apresentado alguns técnicas para "vender" Agile em um ambiente corporativo. Conversamos bastante sobre o papel de uma equipe de testes, como escrever os testes de aceite e unitário dentro do TDD, Refactoring, Integração Contínua, priorização dos itens de backlog, User Stories, Débito Técnico, enfim.. três horas pareceu pouco =)


Conforme solicitado pelos colegas, segue a apresentação.

Scrum + XP na prática

Ainda durante a apresentação, demonstrei um vídeo bem engraçado intitulado "O Alpinista", onde fiz uma analogia de um alpinista com gerentes de projeto.. momento bacana para quebrar um pouco o gelo. Segue abaixo o vídeo.



Bom, é isso aí pessoal, obrigado mais uma vez !!!

Scrum + XP = Diversão Garantida !!!

Estimativas Ágeis - Planning Poker

Em projetos de software tradicionais, (leia-se não ágeis), geralmente fazer estimativa é algo muito chato, e que provavelmente será feito por apenas uma pessoa, que na maioria das vezes essa pessoa é o gerente de projeto, ou o líder da equipe, que utiliza métodos tradicionais para medir uma atividade com análise de ponto de função, ou por linhas de código, etc... mas acontece que quase sempre essa pessoa não conhece a fundo o negócio e as dificuldades técnicas de se implementar uma certa funcionalidade.

O que acaba gerando problemas no decorrer do projeto, pelo fato do analista de negócio (quando tem) não ter previsto uma funcionalidade adicional, ou uma regra de negócio imprescindível para o negócio.

Nesta altura de campeonato, quanto este tipo de situação acontece, geralmente o projeto já esta em um estágio avançado no desenvolvimento, e ATRASADO.. o cliente está puto,,, e sempre quem acaba levando a culpa é o incompetente do desenvolvedor.

Se você já se sentiu familiarizado com este triste relato, pois bem, não fique triste, pois isto já aconteceu comigo e acontece com milhares de pessoas nos dias atuais...

Pois bem, existe solução para este problema?

Sim, existe, se olharmos para alguns dos príncipios ágeis, conforme segue:

"Business people and developers must work together daily throughout the project. "

Traduzindo, quer dizer algo como "Analistas de negócio e desenvolvedores devem trabalhar juntos DIARIAMENTE no decorrer do projeto".

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. "

Traduzindo este também,

“O método mais eficiente e efetivo de obter informação para o time de desenvolvimento é na conversa cara-a-cara."

"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. "

E por último..

“Mudanças de requisitos são bem vindas, mesmo em um estágio avançado no desenvolvimento. Processos ágeis alinham as mudanças para vantagem competitiva do cliente."

Uma estimativa bem feita durante a fase inicial do projeto, reduz muito as chances de você ter dores de cabeça no futuro.

Ok, você está se perguntando, "Mas isto não respondeu a pergunta !!!", como eu posso melhorar as estimativas no inicio de um projeto ou de uma nova iteração ???

Existe um método ágil para estimativas, chamada de Planning Poker, esse método foi descrito inicialmente por James Grenning em 2002 e depois popularizado por Mike Cohn no seu livro Agile Estimating and Planning,, essa técnica é muito conhecido em XP.

Para "jogar" o Planning Poker precisamos apenas de uma lista de backlog e um baralho. E o baralho, geralmente composto por cartas que possuem uma seqüência fibonaci ou similar (0, ½, 1, 2, 3, 5, 8, 13, 21, 34, 50, 80 ,100, ?) e uma carta opcional com um sinal de interrogação.

Por que utilizar esta seqüência, e não um conjunto de números naturais (0,1,2,3,4,5,6,7,etc...) ?

Boa pergunta, mas vou responder com outra pergunta, você consegue distinguir o número 13 do número 14? Fica mais fácil você ter uma noção de separação de complexidade, quando você trabalha com números em uma seqüência fibonaci, imagine que para cada tarefa, quando você for dar o seu peso, pense que uma tarefa com peso 2, é 2 vezes mais difícil que uma tarefa com peso 1.

Voltando ao PP, para jogar, cada participante, geralmente os membros da equipe de desenvolvimento (programadores, testers, designers, etc..) devem possuir uma seqüência de cartas, e cada funcionalidade da lista de backlog irá corresponder a uma rodada do jogo entre a equipe. Os membros não podem conhecer as cartas uns dos outros até início da rodada.

Para facilitar o entendimento, vou demonstrar um exemplo real, imagine que temos uma lista de backlog conforme a tabela abaixo, apresentada pelo Product Owner, e o mesmo dá explicações relacionadas a cada um dos itens, onde todos os membros discutem para chegar a um entendimento do problema.
Na nossa ambiente, vamo imaginar que temos 5 membros, 3 desenvolvedores (Carlão, Maria, Zeca), um tester (Júlio) e uma designer (Rita) e o Project Manager / SM (Walter). O Product Owner neste momento, já deu uma visão dos itens de backlog e explicou a necessidade do negócio, tirou algumas dúvidas e foi embora..

É importante frizar que os membros do time devem estimar todo o trabalho relacionado ao item do backlog, e não apenas a sua parte especifica.

Antes de iniciar a primeira rodada, o SM inicia a discussão:

Walter (SM): Pessoal, o que vocês acharam dessa user story (100)?, o usuário quer um repositório para armazenas os documentos operacionais da empresa assim, assim, assado, então, vamos votar:

Então, neste momento cada membro da equipe, pega uma carta que acha que corresponde com os Story points e depois que todos escolheram suas cartas, tem inicio a rodada. No nosso exemplo, o resultado foi esse:

Rodada 1:
Perceba que na primeira rodada, tivemos pessoas que votaram 50 (Maria, Julio), duas que votaram 80 (Zeca, Rita), um 21 (Carlão) e um 34 (Walter), neste momento o mediador (geralmente o Scrum Master) questiona os resultados.

Walter (SM): Peraí gente, vamos discutir, esta tendo muita divergência, Rita e Zeca, porque vocês acham que essa atividade tem um peso 80?

Rita (Designer): É por que, fico imaginando o tamanho dessa aplicação, já é uma bagunça hoje a forma que é organizado os documentos, imagina só o trabalho de reclassificar tudo, montar um repositório, modelagem, etc... e chora.. ..

Walter (SM): Huum entendi, e você Zeca.

Zeca (Dev): Concordo com a Maria, imagina a quantidade de trabalho.. e chora mais.. etc..

Walter (SM): Carlão porque você acha que é 21, é tão fácil assim??

Carlão (Dev): Na verdade, olhando na ótica do Zeca e da Rita, o problema me parece ser mais complexo do que pensei,..

Walter (SM): Então, o que vocês acham da gente pesquisar alguma ferramenta open source que nos ajude neste trabalho, como um ECM ??? Estava pensando em algo neste tipo, senão realmente teremos muito trabalho,,,

Júlio (tester): Ok Walter, ótima idéia, mas acho que vamos ter muita customização, e com a estrutura que temos hoje não será nada fácil.. Imagine a quantidade de testes !!!

Walter (SM): Certo, se todos estão de acordo, vamos implantar um ECM, vamos fazer mais uma rodada então...

Nisso, é feito a segunda rodada (Tabela 1), podemos ver que houve um consenso..

Neste exemplo simples, podemos observar que alguns benefícios ficam bem claros:

• O Product Owner descreve cada história resumidamente, de forma que todos tem uma idéia do que esta rolando.
• A sinergia entre a equipe aumenta, cada for iniciar um Sprint, onde as tarefas estarão bem definidas, os membros do time, terão uma idéia bem definida do que esta sendo feito, do que o seu colega de trabalho esta fazendo.
• O risco de erros da estimativa diminui dramaticamente.
• As diferenças de opiniões ficam transparentes, de modo que todos passam a discutir estas diferenças.
• É possível re-estimar uma user story até que haja um consenso.

Ok, muito legal esta explicação, mas ainda falta algo, qual a relação entre os princípios ágeis citados no início deste artigo com este jogo de cartas?

Bem, respondendo a pergunta, eu diria que tem tudo a ver, quer ver só:

"O método mais eficiente e efetivo de obter informação para o time de desenvolvimento é na conversa cara-a-cara."

Em planning poker todos estão conversando, (quase sempre olho no olho), o que dá transparência ao negócio.

"Analistas de negócio e desenvolvedores devem trabalhar juntos DIARIAMENTE no decorrer do projeto".

Ao fazer o planning poker, estamos discutindo requisitos funcionais e não funcionais, que visam a realização de um desejo do cliente, e geralmente, durate o planning poker está o Product Owner, para tirar todas as dúvidas em relação ao negócio e verificar se está sendo feito o que foi acordado.

E por último..

"Mudanças de requisitos são bem vindas, mesmo em um estágio avançado no desenvolvimento. Processos ágeis alinha as mudanças para vantagem competitiva do cliente."

Isso irá sempre acontecer, sempre haverá novas features/sistemas a serem desenvolvidos, e durante a estimativa podemos discutir de maneira mais técnica, até modelos de arquitetura, pois querendo ou não, a arquitetura/modelo que será desenvolvido o produto tem um forte peso nas user stories. Portanto, a qualidade do código e do modelo é essencial para que as mudanças de requisitos sejam menos "traumáticas".

Estive no Sun Tech Days, e uma palestra que achei interessante foi a "Usando computação social para melhorar a produtividade no seu projeto" da "Java Champion" Fabiane Nardon, onde ela apresentou várias ferramentas para computação social, e uma das ferramentas citadas foi o site "http://www.planningpoker.com/", um site idealizado por Mike Cohn, e propõe uma ferramenta para que time distribuídos façam a estimativa em conjunto, tem algumas coisas a melhorar, mas a idéia é bem bacana..

OBS> Nas fotos acima, a 1º é uma sessão de planning poker no meu ambiente de trabalho, e na segunda foto o PO priorizando e discutindo os itens de Backlog.

Planning poker com certeza é uma ótima prática, e é também uma boa maneira de iniciar no mundo ágil..

Diversão garantida !!!

Engenharia de Software: 40 Anos de sofrimento e aprendizado

Um pouco de história:
Modelo Cascata ou Waterfall:
Nas empresas que passei, pelo menos a maioria, posso dizer que trabalharam (ou trabalham) com o método cascata para o desenvolvimento de software, que tem seus prós e contras, o problema é que este modelo foi concebido nos anos 70 por W. W. Royce, e consiste na evolução de cada fase do projeto de forma sequencial (Figura 1), vemos na imagem que o primeiro quadrado inicia-se pelo "Requerimento", ou seja, é aquela fase do projeto que demora até meses para ser feita, onde o analista tem que coletar todas as informações pertinentes do projeto e definir os seus requisitos.

Pois bem, uma vez definido os requisitos e fechado o contrato ou a SLA, é montado o cronograma e iniciando a segunda fase deste modelo, a fase do "Projeto", e aí é que geralmente os problemas começam, pois muitas vezes, o cliente ao especificar um projeto não tem nem certeza do que quer, apenas uma idéia, ficando para o analista decifrar tudo o que cliente quer, e quando os requisitos chegam para os desenvolvedores, muitas vezes estes não tem nem contato com o usuário, e tem que se virar com o entendimento baseado nos documentos de especificação, o máximo é uma conversa rápida com o analista, e quando possível.
Outro problema é que estes projetos, são estimados em torno de 3 - 6 meses, e conforme o tempo vai passando, acontece coisas com o cliente e ele começa a esquecer o que foi acordado, sobrando para o pobre desenvolvedor que acaba tendo que refatorar o código para atender a necessidade do usuário, e no modelo cascata não podemos voltar uma fase, conclusão, projetos mal sucedidos, ou atrasados, ou o produto acaba não atendendo o cliente.

Modelo Espiral:

Para tentar acabar com estes problemas conhecidos do Modelo Cascata, em 1988 Barry Boehm escreveu um artigo “A Spiral Model of Software Develpement and Enhancement” , que propõe um desenvolvimento iterativo e incremental que podem chegar de 6 meses a 2 anos,


Vantagens deste modelo:
• O Modelo em espiral permite que ao longo de cada iteração se obtenham versões do sistema cada vez mais completas, recorrendo à prototipagem para reduzir os riscos.
• Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reflete, de uma forma bastante realística, o processo de desenvolvimento.


Desvantagens:
• Pode ser difícil convencer grandes clientes (particularmente em situações de contrato) de que a abordagem evolutiva é controlável.
• A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e baseia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas.
• Este tipo de modelo é relativamente novo e não tem sido amplamente usado.
• É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectos do sistema a ser desenvolvido.
• O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

RUP:

Nestes 3 últimos anos especificamente, tenho trabalhado com um híbrido de RUP, e nas minhas experiências não tenho tido o sucesso desejado, vendo a causa pude chegar a conclusão que para uma metodologia desta dar certo não dependendo só dos templates do método e das fases estabelecidas mas da cultura da empresa e das pessoas envolvidas, pelo menos nos locais onde trabalhei com esta metodologia as pessoas trabalham com RUP em uma forma cascata, e RUP pode será ágil, que é o que mostra o artigo RUP Ágil de José Papo em seu blog. Mas mesmo assim, as pessoas tendem a trabalhar com um RUP mais “pesado”, com um excesso de documentação a ser preenchida, onde para cada passo que é dado, é preciso de assinaturas dos envolvidos.
Ou seja, essa situação faz com que as pessoas envolvidas no processo (leia-se cliente, fornecedor, terceiro) acabam entrando em conflito, pois imagine a seguinte situação, eu tenho um determinado cliente que pede uma determinada funcionalidade no sistema DELE, após eu(analista) colher o requisito, eu tenho o trabalho de documentar isso em um documento definindo as fronteiras do sistema, identificando principais envolvidos/interessados e priorizando suas necessidades, e os requisitos funcionais e não funcionais, pois bem, depois de todo este trabalho, antes de fazer qualquer coisa eu tenho que pegar um documento assinado ou email, provando que foi uma solicitação real e será implementada de acordo com a especificação.
É normal que o cliente terá receio de assinar qualquer documento, pois na cabeça dele, ele pensa que se acontecer alguma coisa errada no processo, a culpa irá recair sobre ele por causa deste documento assinado. Isso vai gerando um desconforto muito grande entre os envolvidos, e o atraso é evidente pois para cada passo é preciso da aprovação do cliente, cada fase do projeto é auditada. Então me diga, Cadê a agilidade?
Lembro que estas foram as minhas experiências com RUP.
Será que não tem algo errado nisto ? Por quê muitas empresas utilizam processos de desenvolvimento de 40 anos atrás, sendo que todo ano é publicado o relatório do Caos pela Standish Group International, onde até o ano passado, 1 entre 3 projetos estouram o orçamento,

Foram por causa dessas perguntas que comecei a me interessar por meios alternativos de gerenciamento de projeto, foi quando conheci as metodologias ágeis. E descobri algo que o que realmente faltava nestes processos / modelos / metodologias, e é algo que é o ponto chave em metodologias como SCRUM, é que esta metodologia é centrada em PESSOAS, GENTE, SER HUMANO, agora que as outras não priorizam. Desenvolvimento LEAN. Veja alguns dos principios:

“Indivíduos e interações são mais importantes que processos e ferramentas.”

“Software funcional é mais importantes que excesso de documentação.”

Para uma idéia melhor sobre o que que é manifesto ágil, veja meu outro post Agile Manifesto – Metodologias Ágeis.

E essa descoberta mudou radicalmente o meu processo de pensar, é a solução para todos o problemas? NÃO.

Mas com certeza é um passo muito importante para quebrar o paradigma de desenvolvimento de software tradicional.

Aos poucos vou falar sobre estes processos ágeis, recomendo que você leia as seguintes matéria.


Blog:

Agile Manifesto – Metodologias Ágeis
TDD – Test Driven Development
SCRUM – Uma abordagem prática

Livros:
Agile Software Development with SCRUM
Extreme-Programming-Explained
User Stories Applied
Lean-Software-Development

Certified Scrum Master (Scrum Alliance)

Recentemente tirei o certificado de Scrum Master fazendo um treinamento pela TeamWare, quem deu o treinamento foram os americanos Chris Doss e David B. Douglas, e o foco do treinamento é o de efetivamente treinar Scrum Masters.
O papel do Scrum Master é o mesmo de Gerente de Projeto, mais o Scrum Master não tem autoridade sobre o Product Owner ou a Equipe, ele é responsável apenas de seguir o processo Scrum conforme descrito, atuam como um coach , auxiliando o Product Owner e a Equipe a entender melhor como realizar o seu papel dentro do processo.
O treinamento foi totalmente ministrado em inglês e teve uma abordagem altamente prática sendo apresentado vários cases.
O treinamento focou os seguintes pontos:

• Estimativa de esforço / tempo, utilizamos o planning poker.
• Sprint Planning baseado em um case (com um PB já definido), onde fizemos a priorização dos Sprints.
• Execução do Sprint.
• Desenvolvemos nosso próprio modelo de Sprint Backlog.
• Formas de comunicação com o Product Owner.
• Sprint Demos (com direito a criação de protótipos e tudo mais).
• Retrospectivas
• Como buscar feedback.
• Melhores Práticas

Minhas observações:
O curso foi bom, entretanto, acho que deveria estar explícito que para participar deste treinamento, o camarada precisa ter pelo um conhecimento prévio do assunto ou estar trabalhando com a metodologia.
Na minha opinião deveria ter uma prova de conceito para avaliar os conhecimentos do aluno.
Outra coisa, o treinamento como eu disse, é para formar SCRUM MASTERS, o curso não ensina como você pode definir a quantidade de pontos de estória que você pode incluir no seu Sprint. Como posso estimar a velocidade da minha equipe ? Como faço a estimativa de disponibilidade da equipe por Sprint ? Como posso analisar os Sprints anteriores no momento de planejar um novo Sprint ? Não foi explicado qual é a melhor maneira de você montar um taskboard, ou como calcular um gráfico burndown ? Como posso estimar dias VS horas ?
Digo isso para que você saiba que não vai encontrar estes tópicos, se você estiver procurando um curso de como fazer Scrum, eu não recomento este curso, recomendo que você faça um treinamento no mercado.
Enfim, o treinamento foi focado em gestão, e em como o Scrum Master deve se comportar e qual é o seu papel. E acho que o curso cumpriu o seu objetivo.

SCRUM - Uma abordagem prática

Metodologias Ágeis vem ganhando um espaço mais do que merecido no meio da comunidade, e vem sendo adotado de forma acelerada por grandes empresas, como Microsoft, Xerox, IBM, etc..
As vezes seguir a risca metodologias como RUP nem sempre é a melhor opção para as empresas que possuem um tempo escasso para entregar o software com qualidade em prazos cada vez mais curtos, foi quando nos dias 11 a 13 de Fevereiro de 2001, caras como Martin Fowler, Kent Beck, Alistair Cockburn, Ward Cunningham e Ken Schwaber se reuniram em resort de ski em Snowbird (Utah) para mudar o rumo do desenvolvimento de software, foi nesta reunião que nasceu o XP, Scrum, DSDM, Crystal, FDD, e outras metodologias que visam "desburocratizar" o desenvolvimento de software, entre as metologias propostas esta o Scrum idealizado por Ken Schwaben, que vem ganhando cada vez mais adeptos.
Esse post é um tutorial prático de SCRUM, para que se interessarem no assunto recomendo o livro Agile Project Management with Scrum de Ken Schwaben
OBS> Esse tutorial é fortemente baseado no documento pdf Scrum And Xp From The Trenches e no livro Agile Project Management with Scrum de Ken Schwaben.

O que é Scrum ? SCRUM é uma metodologia (ou Framework de acordo com o criador Ken Schwaber) onde a espinha dorsal é que chamamos de Sprint. Que nada mais é do uma lista de objetivos ou requisitos bem definidos cujo time de desenvolvimento irá trabalhar focado em um período de 30 dias.

Papéis no Scrum ?

No Scrum existem 3 papéis que devem estar bem definidos, que são:

Product Owner	Scrum Master	Scrum Team
É o "cliente" focal, responsável por reunir todas as mudanças planejadas para o produto e priorizar as funcionalidades possíveis. Administra o Backlog do Produto e assegura que o Scrum Team esta trabalhando com as tarefas certas na perspectiva do negócio.	O Scrum Master lidera o time de desenvolvimento, resolve possíveis impedimentos e trabalha para assegurar que o time possui a ferramentas e condições necessárias para alcançar os objetivos estabelecidos pelo Sprint. Realiza reuniões diárias “Daily Scrum” com o Scrum Team para o acompanhamento das atividades.	São os membros que formam o time de desenvolvedores, designers, consiste de 5 a 9 pessoas. Interagem com o Product Owner para determinar o objetivo do Sprint e priorizar as funcionalidades, e quebrar o Sprint em tarefas detalhadas. O time é auto organizável e tem a responsabilidade conjunta pelos resultados.

	O Product Owner é responsável por compilar todas as requisições e especificações no documento chamado Product Backlog, essas mudanças são referentes ao produto, como novas funções e correções de bugs. As prioridades devem ser feitas durante a criação de cada tarefa.
	Em um período de 30 dias, é feito uma reunião que será definido o Sprint Backlog de acordo com os itens do product backlog levantado pelo Product Owner, ou seja, de acordo com os itens de maior prioridade é criado o Sprint Backlog que a equipe terá a responsabilidade de terminar até o próximo Sprint.
	Uma vez com o Sprint definido, o Scrum Master diariamente faz o “Daily Scrum”, que é uma reunião com o Scrum Team cujo propósito é eliminar qualquer impedimento. Cada integrante deve responder a 3 perguntas: 1º O que você fez desde a ultima reunião ? 2º O que você vai fazer entre esse e a próxima reunião ? 3º Tem algo impedindo você de efetuar a sua tarefa ?

Qual é o critério para decidir a história que será incluída no Sprint ?

* Base da conversa

* Cálculo de Velocidade
Base da conversa, é ideal quando a equipe não possui histórico de sprints, ou seja, para equipes que nunca trabalharam com Scrum e não possuem dados estátiscos para realizar o calculo de velocidade.
A conversa gira em torno dos desenvolvedores, onde o Scrum Master pergunta para cada membro do time quanto tempo uma atividade do Backlog demora para ser desenvolvida (em horas), e com base nisso as horas necessárias para o projeto.
Quando já passou por alguns ciclos com Sprints, é utilizado o Cálculo de Velocidade é uma medida em cima do “total do trabalho feito”, onde cada item recebe um peso de acordo com a sua estimativa inicial.

.

Como estimar a velocidade ?
Resp: A maneira mais simples de estimar a velocidade é verificar o histórico do time. Qual foi a velocidade do time nos últimos Sprints ? Então assumir que a velocidade será a mesma para o último Sprint, mas isso só funciona se o time já tive feito alguns Sprints antes.
Outra maneira de calcular é através de cálculo de recurso. Por exemplo, vamos assumir que estamos planejando um Sprint de 3 semanas (15 dias) com um time de 4 pessoas. O recurso João ficará dois dias de folga, Zezinho apenas 50%, colocando tudo isso no papel ficará:

Recursos	Disponibilidade em dias
Zezinho	7	Esta não é ainda nossa estimativa de velocidade, a nossa unidade de estimativa são os pontos de estória, que no nosso caso corresponde ao “dias de recurso ideal”.
Wagner	15
João	13
Trainee	15
Total	50 Dias de Recurso disponível para este Sprint

Estimamos que a velocidade estimada será menor que 50. Mas quanto menos ? Utilizamos o termo “Fator Foco” para isso:
Fórmula para velocidade estimada do Sprint:
(Dias de Recurso Disponível) * (Fator Foco) = (Velocidade Estimada)
Fator Foco é uma estimativa de como o time esta focado no Projeto. Um fator foco baixo significa que o time espera encontrar vários inconvenientes. A melhor maneira de determinar um Fator Foco concreto é analisando o ultimo Sprint, ou melhor, a média dos últimos Sprints.
Fator Foco do último Sprint:
(Fator Foco) = (Velocidade Atual) .
(Dias de Recurso Disponível)
Velocidade atual é a soma da estimativa inicial de todas as estórias que foram finalizadas no Sprint anterior. Por exemplo, no ultimo Sprint complemos 18 pontos em um time de 3 pessoas, trabalhando por 3 semanas para um total de 45 Dias de Recurso. Vamos calcular o novo Sprint baseado nestes dados, para complicar imagine que chegou mais um recurso (Trainee), que totalizando dá 50 Dias de Recurso com treinamentos, feriados, etc...

Fator Foco do último Sprint:	(40%) =(18 Pontos de estória) (45 Dias de Recurso)
Velocidade Estimada Sprint:	(50 Dias de Recurso) * (40%) = (20 Pontos estória)

Desta maneira a velocidade estimada para o próximo Sprint é de 20 pontos de estória. Isso significa que o time deve adicionar estórias para o Sprint até o mesmo chegar perto de 20 pontos.

Index Cards: O que são ?
As reuniões de planejamento são gastas lidando com estórias do Product Backlog. Fazendo estimativas, priorizando-os, discutindo-os.
Scrum propõe uma maneira muito mais ágil de expor os problemas que serão discutidos que são os Index Cards. Na verdade para cada item do backlog é criado um cartão e estes cartões são expostos em um mural.
EX:

** Estas informações serão as mesmas do Product Backlog que podem ser armazenadas em arquivo Excel

Os cartões deverão conter as seguintes informações **: ID: Identificador único Nome: Descrição curta da estória. Importância: Grau de importância da estória. Ex: 10–50. Alto: Mais importante. Estimativa inicial: Estimativa do time de quanto trabalho é preciso, a medida é feita por pontos de estória que corresponde a “Dias de Recurso” Demonstração:Uma descrição de alto nível de como será feito a demo do Sprint. Observação: Outras informações...

Quebrando estórias em tarefas:
A diferença entre estórias e tarefas, é que estórias são as funções que o Product Owner solicitou e que espera que elas sejam entregues.
Desmembramos as estórias em tarefas unitárias de modo a distribuir as atividades do desenvolvimento da estória para toda a equipe.
Ex:

No nosso exemplo o quadro branco (consulta de clientes) seria a estória (item de Sprint) e os post its amarelos as tarefas deste item de backlog.

Gráfico Burndown de acompanhamento diário.

Na linha vertical, colocamos a quantidade de pontos de estória, que é a quantidade de trabalho que deve ser feito para este Sprint através do cálculo de velocidade por atividade, é a velocidade estimada de todo o Sprint. Na linha horizontal, marcamos o primeiro dia do Sprint, nor exemplo 1º de Augusto, e esperamos terminar este Sprint no dia 19 de Junho, a linha tracejada indica a estimativa de trabalho. A linha azul indica o trabalho realizado, no exemplo o gráfico nos mostra que no dia 16 ainda temos aproximadamente 15 pontos de estória de trabalho para fazer. O gráfico é atualizado diariamente durante o Daily Scrum.

Indicadores:De acordo com o gráfico podemos tomar algumas decisões, e saber diariamente o que esta acontecendo no projeto, se está dentro do prazo, etc...

Dissecando o quadro indicador:

Retrospectiva
Ao final de cada Sprint é ideal a equipe e o Scrum Master e discutir o que cada um achou da Sprint e dar suas opiniões. A idéia central se resume na seguinte pergunta: O que podemos melhorar no próximo Sprint ?
No quadro no exemplo, temos 3 colunas:
1ºBom (Good): Se tivéssemos que fazer outra Sprint, faríamos da mesma maneira.
2ºPoderíamos fazer melhor (Could have been better): Se tivéssemos que fazer outra Sprint, faríamos de maneira diferente..
3º Melhorias (Improvements): Idéias concretas que poderíamos implementar no futuro

Exemplo de um quadro de sugestões / análise:


É possível ainda mesclar Scrum com XP, o que torna o trabalho ainda mais produtivo, em tempo oportuno mostrarei algumas das técnicas utilizadas..