Agilidade

@ribeirord

1

Prof. Rafael Dias Prof. Rafael Dias Prof. Rafael Dias Prof. Rafael Dias RibeiroRibeiroRibeiroRibeiro, , , , M.ScM.ScM.ScM.Sc, CSM, CSPO,PMP., CSM, CSPO,PMP., CSM, CSPO,PMP., CSM, CSPO,PMP.http://www.rafaeldiasribeiro.com.brhttp://www.rafaeldiasribeiro.com.brhttp://www.rafaeldiasribeiro.com.brhttp://www.rafaeldiasribeiro.com.br

AgilidadeAgilidadeAgilidadeAgilidade

s.f. Ligeireza, presteza, leveza; desembarao.http://www.dicio.com.br/agilidade/

a capacidade de executar movimentos rpidos e ligeiros com mudanas nas direes

Adaptado de http://pt.wikipedia.org/wiki/Agilidade

@ribeirord

2

Rapidez AgilidadeRapidez AgilidadeRapidez AgilidadeRapidez Agilidade

Desenvolvimento gil diferente dedesenvolvimento rpido de aplicaes.

A agilidade est em garantir a qualidade domtodo de se adaptar e solucionarproblemas durante o desenvolvimento doproduto.

@ribeirord

3

Evoluo Histrica: Evoluo Histrica: Evoluo Histrica: Evoluo Histrica: WaterfallWaterfallWaterfallWaterfallProposta por Winston W. Royce em 1970

@ribeirord

Evoluo Histrica: Evoluo Histrica: Evoluo Histrica: Evoluo Histrica: WaterfallWaterfallWaterfallWaterfall ---- Winston W. Royce

In order to procure a 5 million dollar hardware device, I wouldexpect that a 30 pages specification would provide adequate detailto control the procurement. In order to procure 5 million dollars ofsoftware I would estimate 1500 pages specification is about right in

order to achieve comparable control

A fim de obter um hardware de 5 milhes de dlares, euesperaria que uma especificao de30 pginas proporcionasse detalhes suficiente para controlaresta aquisio. A fim de obter um software de 5 milhes de dlares,eu estimaria 1500 pginas de especificao, a fim de conseguir ocontrole comparvel

Royce defendia que a documentao deve ser extensa...

@ribeirord

4

Evoluo Histrica: Evoluo Histrica: Evoluo Histrica: Evoluo Histrica: WaterfallWaterfallWaterfallWaterfall ---- Winston W. Royce

I believe in this concept, but the implementation described aboveis risky and invites failure. (...) The testing phase which occurs at theend of development cycles is the first event for which timing,storage, input/output transfers, etc., are experienced asdistinguished from analyzed

Eu acredito neste conceito, mas a implementao descrita acima arriscada e convida falhas. (...) A fase de testes, que ocorre nofinal dos ciclos de desenvolvimento o primeiro evento para o quala temporizao, o armazenamento, transferncia de entrada/sada,etc., so experimentados como distinguido de analisados

Se o projeto precisa estar pronto para ser testado o produtodesenvolvido fatidicamente encontrar problemas (bugs, questesde performance, escalabilidade,...)

DINMICA

@ribeirord

5

Premissas / Suposies : Premissas / Suposies : Premissas / Suposies : Premissas / Suposies : WaterfallWaterfallWaterfallWaterfall

Um pessoa ou um grupo fala com o cliente e descobre o que ele deseja do software

O mesmo grupo de analistas transmite a informao obtida com o cliente para a equipe tcnica

Os analistas verificam a viabilidade do projeto e identificam os riscos

Os arquitetos de TI documentam (diagramas, etc) para orientar os desenvolvedores

Os desenvolvedores criam os cdigos de acordo com os documentos criados pelos arquitetos de TI

Os testers verificam os documentos e validam os cdigos gerados

O software implementado

A distncia do cliente durante o desenvolvimento do sistema muitas vezes faz perder o foco do que importante para ele.

As 4 primeiras fases consistem apenas em documentao, sem nenhuma produo de valor para o cliente.

Em um perodo de desenvolvimento muitas tecnologias surgem assim como a prpria necessidade do cliente , de acordo com a evoluo do negcio.

Ser que os programadores so incapazes de tomar deciso sobre o cdigo ?

@ribeirord

6

RUP RUP RUP RUP RationalRationalRationalRational UnifiedUnifiedUnifiedUnified ProcessesProcessesProcessesProcesses

Criado pela Rational, mais tarde englobado pela IBM

The Rational Unified Process activities create and maintain models. Rather than focusing on the production of large amount of paperdocuments, the Unified Process emphasize the development andmaintenance of models semanticly rich representations of thesoftware system under development

O Rational Unified Process tem a finalidade de criar e manter modelos. Ao invs de focar na produo de grande quantidade de documentos em papel, o Rational Unified Processenfatiza o desenvolvimento e manuteno de modelos -representaes semanticamente ricas do sistema de software em desenvolvimento


The Rational Unified Process is a configurable process. No single processis suitable for all software development. The Unified Process fits smalldevelopment teams as well as large development organizations. TheUnified Process is founded on a simple and clear process architecture thatprovides commonality across a family of processes. Yes, it can be toaccommodate different situations.

O Rational Unified Process um processo configurvel. Nenhum nicoprocesso adequado para todo o desenvolvimento de software. OProcesso Unificado se adequa a pequenas equipes de desenvolvimento,bem como organizaes de desenvolvimento de grande porte. O ProcessoUnificado fundamentada em uma arquitetura de processo simples eclaros que fornece uma famlia de processos comuns. Sim, ele pode ser ade acomodar para situaes diferentes.

@ribeirord

7


Melhores Prticas:

Desenvolva software iterativamente Gerencie requisitos Use arquiteturas baseadas em componentes Modele visualmente o software Verifique a qualidade do software Controle as mudanas no software


Given todays sophisticated softwares systems, it is not possible tosequentially first define the entire problem, design the entire solution,build the software and then test the product at the end. Na interactiveapproach is required that allows an increasing understanding of theproblem through successive refinements, and to incrementally growan effective solution over multiple iterations.

Devido a sofisticao dos softwares atuais, no possvel sequenciaro desenvolvimento de primeiro definir todo o problema, projetar todaa soluo, construir o software e, em seguida, testar o produto nofinal. Na abordagem interativa necessrio permitir acompreenso crescente do problema atravs de refinamentossucessivos, e gradativamente crescer na soluo eficaz durante vriasiteraes.

@ribeirord

8


Desenvolvimento iterativo, comeando sempre pelos pontos de maior risco ao projeto . Decises de risco decididas no inicio do projeto so corrigveis mais facilmente.

Iteraes curtas com releases internos durante a construo do projeto permitem um retorno mais rico do cliente e ajudam a controlar melhor o tempo estimado para a concluso do desenvolvimento.


@ribeirord

9


O framework raramente aplicado iterativamente... Apesar de esperar que mudanas aconteam , no muito dinmico para trat-las...

While the process must always accommodate changes, the elaboration phaseensure that the architecture, requirements and plans are stable enough, and therisks are sufficiently mitigated, so you can predictably determine the cost andschedule for the completion of the development. Conceptually, his level of fidelitywould correspond to the level necessary for na organization to commit to a fixed-price construction phase

Embora o processo deve sempre acomodar as mudanas, a fase de elaborao devegarantir que a arquitetura, os requisitos e os planos sejam estveis o suficiente eque os riscos foram suficientemente mitigados, para que vocpossa previsivelmente determinar o custo e o cronograma para a concluso dodesenvolvimento. Conceitualmente, o seu nvel de fidelidade que corresponderia aonvel necessrio para uma organizao se comprometer com uma fase deconstruo a preo fixo.

Lean Lean Lean Lean ITITITIT

LeanLeanLeanLean ITITITIT definitiondefinitiondefinitiondefinition:::: Lean IT engages people, using a framework of Leanprinciples, systems, and tools, to integrate, align, and synchronize the ITorganization with the business to provide quality information andeffective information systems, enabling and sustaining the continuousimprovement and innovation of processes. Lean IT has two aspects:outward facing, supporting the continuous improvement of businessprocesses, and inward-facing, improving the performance of ITprocesses and services

Lean IT envolve as pessoas, utilizando um quadro de princpios do Lean,sistemas e ferramentas, para integrar, alinhar e sincronizar aorganizao de TI com o negcio para fornecer informao de qualidadee sistemas de informao eficazes, permitindo e manuteno da melhoriacontnua e inovao de processos. Lean IT tem dois aspectos:.Para oexterior, apoiando a melhoria contnua dos processos de negcio, e paradentro (interna), melhorando o desempenho dos processos de TI eservios

@ribeirord

10

Lean Lean Lean Lean ITITITIT

O sistema Lean de produo foi desenvolvido pela Toyota e tem umprincpio claro e simples: ReduzirReduzirReduzirReduzir oooo desperdciodesperdciodesperdciodesperdcio

Desperdcio tudo o que no ir gerar valor para o cliente. Este conceitofoi incorporado em alguns mtodos geis e considera como desperdciodocumentao excessiva, tempo de desenvolvimento parado por falta deinformaes (ou falta de clareza), ou cdigos e funcionalidades nosolicitadas...

Lean Lean Lean Lean ITITITIT Tipos de Desperdcios:

MuraMuraMuraMura: desperdcio por tentar prever possveis necessidades futuras. Evitar amura significa reduzir ao mximo o inventrio, isto , as partes paradas nomeio do processo, isto , comeando ou no terminando.

MuriMuriMuriMuri: desperdcios que podem ser evitados por planejamento. Nessa categoriaenquadra-se o excesso de burocracia ou de complexidade nem processo deproduo.

MudaMudaMudaMuda: desperdcios do dia a dia, criados por uma cultura anterior de trabalho.

Superproduo Transporte desnecessrio Inventrio Locomoo Defeitos Super processamento Espera

@ribeirord

11

Lean Lean Lean Lean IT IT IT IT Sistema PUSH vs. PULL Sistema PUSH upstream information

No sistema Ford de produo, cada estao da linha de produo trabalhaenquanto houver matria prima para tal. A quantidade do que ser produzido regulada com base em provises feitas sobre o mercado em um determinadoperodo, mas no h ligao entre os pedidos reais e a linha de produo.

Exemplo de Mura:

Muitas peas produzidas esperando para serem utilizadas em outras estaes, semsequer saber se existe demanda pelo produto (inventrio). Muito WIP ( Work in Progress )

Dimensionamento do trabalho...

ExpectedDemand

MassProduction

Economies ofscale

@ribeirord

12

Lean Lean Lean Lean IT IT IT IT Sistema PUSH vs. PULL Sistema PULL downstream information

Trabalha com o mnimo possvel de inventrio que ainda permite atender sdemandas de clientes rapidamente. Sua concepo e prtica so simples: hapenas o nmero suficiente de peas em inventrio para um produto (ou lote)ser completo.

A produo acontece de acordo com a demanda, reduzindo custos dearmazenamento, de peas intermedirias e produtos no vendidos, alm deflexibilizar a produo.

CustomerRequirements

On demandProduction

Adaptation

KanBanKanBanKanBanKanBan

Linha de Produo = sequncia de passos para produzir algo

A fazer Inventrio 1 Inventrio 2 Inventrio 3 Produto

Em sistemas push, cada estao de trabalho faz sua parte sem considerar fases anteriores e posteriores. O Kanban permite ver com mais clareza o acmulo de inventrio

@ribeirord

13

KanBanKanBanKanBanKanBanA fazer Inventrio 1 Inventrio 2 Inventrio 3 Produto

8

9

10

No Kanban representamos o sistema pull de produo, h um limite deinventrio claramente definido. Assim peas s so produzidas quando de fatoh demanda e gasta-se menos em peas que no sero utilizadas ou emestoque de inventrio.

12

3

4

5

6

7

@ribeirord

KanBanKanBanKanBanKanBan

dispositivos fsicos sinais de demanda downstream processes regula a demanda em um pull system limita de trabalho em progresso (wip) controle visual auto direo

OBS: uma excelente forma de visualizar o andamento da produo mas apenas uma ferramenta que deve ser empregada para auxiliar (reforar) a metodologia aplicada.

@ribeirord

14

Systems ThinkingSystems ThinkingSystems ThinkingSystems Thinking

Aps reduzir a mura, temos uma melhor viso de nossa linha de produo ( trabalhos redundantes,...)

Quantas vezes no vimos consagrados processos de produo de software atrapalhando uma equipe em vez de ajud-la ? Todas as fases do seu processo so realmente necessrias para o sucesso final ?

Systems Thinking pensar e repensar durante todo oandamento do projeto no que poderia ser melhorado noprprio processo de desenvolvimento e nas interaesentre as pessoas envolvidas

Work CellsWork CellsWork CellsWork Cells

No possvel pensar em encontrar melhorias no processo se cada individuo est focado exclusivamente em uma tarefa o qual especialista.

O Lean entende no podem ser superespecialistas, i. e., no podem se limitar apenas a conhecimento em sua etapa. Devem conhecer todas elas e saber executar algumas delas.

Cada membro da equipe uma Work Cell: pessoa capaz de trabalhar no projeto como um todo, em algumas ou todas as suas partes. O conhecimento mais amplo sobre o projeto incentivado, j que, ao conhecer o todo , melhores sero as crticas para melhoria.

@ribeirord

15

KaisenKaisenKaisenKaisen

Em Lean acredita-se que no existe uma bala de prata * capaz de resolver todos os problemas, preciso que cada membro da equipe adapte a metodologia e ferramentas sua necessidade a todo momento.

Kaisen a palavra japonesa para melhoria, significa maximizar a funo Ganho Desperdcio. Melhorias no processo, na forma de produo e no produto final so parte do dia a dia de quem trabalha com Lean

Artigo de Frederich Brooks com o ttulo No Silver Bullet, publicado na dcada de 70

Leitura sugerida:http://www.4shared.com/office/kBZlRWok/TheMythicalManMonthFBrooks.html

O Manifesto gilO Manifesto gilO Manifesto gilO Manifesto gil

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs deste trabalho, passamos a valorizar:

Indivduos Indivduos Indivduos Indivduos e interao entre elese interao entre elese interao entre elese interao entre eles mais que processos e ferramentasSoftware em funcionamentoSoftware em funcionamentoSoftware em funcionamentoSoftware em funcionamento mais que documentao abrangenteColaborao com o clienteColaborao com o clienteColaborao com o clienteColaborao com o cliente mais que negociao de contratos

Responder a mudanasResponder a mudanasResponder a mudanasResponder a mudanas mais que seguir um plano

Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda.

@ribeirord

16

Princpios geis Princpios geis Princpios geis Princpios geis

Nossa maior prioridade satisfazer o cliente, atravs da entrega adiantada e contnua de software de valor.

Aceitar mudanas de requisitos, mesmo no fim do desenvolvimento. Processos geis se adequam a mudanas, para que o cliente possa tirar vantagens competitivas.

Entregar software funcionando com frequncia, na escala de semanas at meses, com preferncia aos perodos mais curtos.

Pessoas relacionadas negcios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

Princpios geis Princpios geis Princpios geis Princpios geis

Construir projetos ao redor de indivduos motivados. Dando a eles o ambiente e suporte necessrio, e confiar que faro seu trabalho.

O Mtodo mais eficiente e eficaz de transmitir informaes para, e por dentro de um time de desenvolvimento, atravs de uma conversa cara a cara.

Software funcional a medida primria de progresso.

Processos geis promovem um ambiente sustentvel. Os patrocinadores, desenvolvedores e usurios, devem ser capazes de manter indefinidamente, passos constantes.

@ribeirord

17

Vantagens da AgilidadeVantagens da AgilidadeVantagens da AgilidadeVantagens da Agilidade

Feedback rpido

Motivao da equipe

Sem Corpo Mole

Ver problemas mais cedo

SCRUMSCRUMSCRUMSCRUM

Waterfall and Spiral methodologies set the context and deliverable definition at thestart of a project. Scrum and iterative methodologies initially plan the context andbroad deliverable definition, and then envolve the deliverable during the project basedon the environment. Scrum acknowledges that the underlying development processesare incompletely defined and uses control mechanisms to improve flexibility.

Metodologias de Cascata (Waterfall) e Espiral (Spiral ) definem o contexto e aentrega no incio de um projeto. Metodologias iterativas e oScrum inicialmente planejam o contexto e a definio entrega ampla, e, emseguida, especifica a entrega durante o projeto com base noambiente. Scrum reconhece que os processos dedesenvolvimento subjacentes no so totalmente definidose utiliza mecanismos de controle para melhorar a flexibilidade.

@ribeirord

18


The primary difference between the defined (waterfall, spiral and iterative) andempirical (SCRUM) approach is that the Scrum approach assumes that the analysis,design, and development process in the sprint phase are unpredictable. A controlmechanism is used to manage the unpredictablity and control the risk. Flexibility,responsiveness, and reliability are the results.

A principal diferena entre processos definidos (waterfall, spiral and iterative) e aabordagem emprica (SCRUM) que a abordagem Scrum assume que a anlise,concepo, desenvolvimento e processo dentro da fase de sprint soimprevisveis. Um mecanismo de controle usado para gerenciar o falta deprevisibilidade e controlar o risco. Flexibilidade, agilidade e confiabilidade so osresultados.


Scrum: A framework within which people can address complex adaptative problems,while productively and creatively delivering products of the highest possible value(...)Scrum makes clear the relative efficacy of your product management and developmentpractices so that can improve .

Scrum: Um framework no qual as pessoas podem abordar de formaadaptativa os complexos problemas, de forma produtiva ecriativa oferecendo produtos de maior valor possvel (...) Scrum torna claraa eficcia relativa de seu gerenciamento de produtos e prticas dedesenvolvimento.

A funo do Scrum evidenciar os problemas do projeto mais cedo para quese possa resolver o problema mais cedo.

@ribeirord

19


Scrum fundamentado nas teorias empricas de controle deprocesso, ou empirismo. O empirismo afirma que oconhecimentoconhecimentoconhecimentoconhecimento vemvemvemvem dadadada experinciaexperinciaexperinciaexperincia eeee dededede tomadatomadatomadatomada dededede decisesdecisesdecisesdecisesbaseadasbaseadasbaseadasbaseadas nononono quequequeque conhecidoconhecidoconhecidoconhecido. O Scrum emprega umaabordagem iterativa e incremental para aperfeioar aprevisibilidade e o controle de riscos.

SCRUM SCRUM SCRUM SCRUM Pilares que apoiam a implementao de controle de processo empricoPilares que apoiam a implementao de controle de processo empricoPilares que apoiam a implementao de controle de processo empricoPilares que apoiam a implementao de controle de processo emprico

TransparnciaTransparnciaTransparnciaTransparncia::::

Aspectos significativos do processo devem estar visveis aos responsveis pelosresultados. Esta transparncia requer aspectos definidos por um padro comumpara que os observadores compartilharem um mesmo entendimento do que estsendo visto.

InspeoInspeoInspeoInspeo

Os usurios Scrum devem, frequentemente, inspecionar os artefatos Scrum e oprogresso em direo ao objetivo, para detectar indesejveis variaes. Estainspeo, no deve no entanto, ser to frequente que atrapalhe a prpriaexecuo das tarefas. As inspees so mais benficas quando realizadas deforma diligente por inspetores especializados no trabalho a se verificar.

AdaptaoAdaptaoAdaptaoAdaptao

Se um inspetor determina que um ou mais aspectos de um processo desvioupara fora dos limites aceitveis, e que o produto resultado ser inaceitvel, oprocesso ou o material sendo produzido deve ser ajustado. O ajuste deve serrealizado o mais breve possvel para minimizar mais desvios.

@ribeirord

20


ResumindoResumindoResumindoResumindo tudotudotudotudo issoissoissoisso............

Scrum um framework INCOMPLETO o qual aspessoas podem resolver problemas complexos eadaptveis, enquanto entregam produtos de formaprodutiva, criativa e com o maior valor possvel !

SCRUM SCRUM SCRUM SCRUM PersonagensPersonagensPersonagensPersonagens

@ribeirord

21


O O O O ProductProductProductProduct OwnerOwnerOwnerOwner

O Product Owner, ou dono do produto, o responsvel por maximizar o valor do produto e do trabalho da equipe de Desenvolvimento. Como isso feito pode variar amplamente atravs das organizaes, Times Scrum e indivduos.

O Product Owner pode fazer o trabalho acima, ou delegar para a Equipe de Desenvolvimento faz-lo. No entanto, o Product Ownercontinua sendo o responsvel pelos trabalhos.


O ProductProductProductProduct OwnerOwnerOwnerOwner a nica pessoa responsvel por gerenciar o Backlog do Produto. O gerenciamento do Backlog do Produto inclui: Expressar claramente os itens do Backlog do Produto;

Ordenar os itens do Backlog do Produto para alcanar melhor as metas e misses;

Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;

Garantir que o Backlog do Produto seja visvel, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e,

Garantir que a Equipe de Desenvolvimento entenda os itens do Backlog do Produto no nvel necessrio.

@ribeirord

22


O ProductProductProductProduct OwnerOwnerOwnerOwner uma pessoa e no um comit. O ProductOwner pode representar o desejo de um comit no Backlog doProduto, mas aqueles que quiserem uma alterao nasprioridades dos itens de Backlog devem convencer o ProductOwner.

Para que o Product Owner tenha sucesso, toda a organizaodeve respeitar as suas decises. As decises do Product Ownerso visveis no contedo e na priorizao do Backlog doProduto. Ningum tem permisso para falar com a Equipe deDesenvolvimento sobre diferentes configuraes de prioridade,e o Time de Desenvolvimento no tem permisso para agirsobre o que outras pessoas disserem.


ProductProductProductProduct OwnerOwnerOwnerOwner

FaseFaseFaseFase AtividadeAtividadeAtividadeAtividade

PRE-GAME Identificar as necessidades Estratgicas do Projeto (Patrocinador, Time, Infraestrutura, reas Envolvidas, etc)

Realizar Kick-Off Descobrir a viso do produto e elaborar artefatos necessrios Descobrir os requisitos para o Product Backlog Organizar e priorizar o Product Backlog

GAME Participar de todas as Sprint Planning Meeting e Reviews. Quando necessrio visitar a reunio diria e participar de Retrospective(geralmente, quando convidado pelo Time)

Estar disponvel para o Time (ou garantir que algum designado por ele esteja)

Elaborar Plano de Release Manter o Product Backlog Atualizar o Plano de Release

POST-GAME Project Retrospective Tornar resultados visveis para outros (e futuros) projetos Scrum

na empresa; e/ou para a Enterprise Scrum

@ribeirord

23


ProductProductProductProduct OwnerOwnerOwnerOwner ProblemasProblemasProblemasProblemas ComunsComunsComunsComuns............

P.O. sem poder de deciso

P.O. com baixa disponibilidade

O metade P.O.

P.O. distante

P.O. proxy

P.O. da sua parte


Equipe de Desenvolvimento Equipe de Desenvolvimento Equipe de Desenvolvimento Equipe de Desenvolvimento

A Equipe de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma verso usvel que potencialmente incrementa o produto Pronto ao final de cada Sprint. Somente integrantes da Equipe de Desenvolvimento criam incrementos.

As Equipes de Desenvolvimento so estruturadas e autorizadas pela organizao para organizar e gerenciar seu prprio trabalho. A sinergia resultante aperfeioa a eficincia e a eficcia da Equipe de Desenvolvimento como um todo.

@ribeirord

24

SCRUM SCRUM SCRUM SCRUM PersonagensPersonagensPersonagensPersonagens As Equipes de Desenvolvimento Equipes de Desenvolvimento Equipes de Desenvolvimento Equipes de Desenvolvimento tem as seguintes caractersticas:

Eles so auto-organizadas. Ningum (nem mesmo o Scrum Master) diz a Equipede Desenvolvimento como transformar o Backlog do Produto em incrementos defuncionalidades potencialmente utilizveis;

Equipes de Desenvolvimento so multifuncionais, possuindo todas as habilidadesnecessrias, enquanto equipe, para criar o incremento do Produto.

O Scrum no reconhece ttulos para os integrantes da Equipe deDesenvolvimento que no seja o Desenvolvedor, independentemente do trabalhoque est sendo realizado pela pessoa; No h excees para esta regra.

Individualmente os integrantes da Equipe de Desenvolvimento podem terhabilidades especializadas e rea de especializao, mas a responsabilidadepertence Equipe de Desenvolvimento como um todo; e,

Equipes de Desenvolvimento no contm sub-equipes dedicadas a domniosespecficos de conhecimento, tais como teste ou anlise de negcios.

SCRUM SCRUM SCRUM SCRUM PersonagensPersonagensPersonagensPersonagens Tamanho da Equipe de Desenvolvimento Tamanho da Equipe de Desenvolvimento Tamanho da Equipe de Desenvolvimento Tamanho da Equipe de Desenvolvimento

O tamanho ideal da Equipe de Desenvolvimento pequeno o suficiente para semanter gil e grande o suficiente para completar uma parcela significativa dotrabalho.

Menos de trs integrantes na Equipe de Desenvolvimento diminuem a interao eresultam em um menor ganho de produtividade. Equipes de desenvolvimentomenores podem encontrar restries de habilidades durante a Sprint, gerandouma Equipe de Desenvolvimento incapaz de entregar um incrementopotencialmente utilizvel.

Havendo mais de nove integrantes exigida muita coordenao. Equipes deDesenvolvimento grandes geram muita complexidade para um processo empricogerenciar.

Os papis de Product Owner e de Scrum Master no so includos nestacontagem, ao menos que eles tambm executem o trabalho do Backlog daSprint.

@ribeirord

25

SCRUM SCRUM SCRUM SCRUM PersonagensPersonagensPersonagensPersonagens O O O O ScrumScrumScrumScrum Master Master Master Master

O Scrum Master responsvel por garantir que o Scrum sejaentendido e aplicado. O Scrum Master faz isso para garantir que oTime Scrum adere teoria, prticas e regras do Scrum. O ScrumMaster um servo-lder para o Time Scrum.

O Scrum Master ajuda aqueles que esto fora do Time Scrum aentender quais as suas interaes com o Time Scrum so teis equais no so. O Scrum Master ajuda todos a mudarem estasinteraes para maximizar o valor criado pelo Time Scrum.

SCRUM SCRUM SCRUM SCRUM PersonagensPersonagensPersonagensPersonagens O O O O ScrumScrumScrumScrum Master trabalhando para o Master trabalhando para o Master trabalhando para o Master trabalhando para o ProductProductProductProduct OwnerOwnerOwnerOwner

O Scrum Master serve o Product Owner de vrias maneiras, incluindo:

Encontrando tcnicas para o gerenciamento efetivo do Backlog do Produto;

Claramente comunicar a viso, objetivo e itens do Backlog do Produto para a Equipe de Desenvolvimento;

Ensinar a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa;

Compreender a longo-prazo o planejamento do Produto no ambiente emprico;

Compreender e praticar a agilidade; e,

Facilitar os eventos Scrum conforme exigidos ou necessrios.

@ribeirord

26


O O O O ScrumScrumScrumScrum Master trabalhando para a Equipe de Desenvolvimento Master trabalhando para a Equipe de Desenvolvimento Master trabalhando para a Equipe de Desenvolvimento Master trabalhando para a Equipe de Desenvolvimento

O Scrum Master serve a Equipe de Desenvolvimento de vrias maneiras, incluindo: Treinar a Equipe de Desenvolvimento em auto-gerenciamento e interdisciplinaridade;

Ensinar e liderar a Equipe de Desenvolvimento na criao de produtos de alto valor;

Remover impedimentos para o progresso da Equipe de Desenvolvimento;

Facilitar os eventos Scrum conforme exigidos ou necessrios; e,

Treinar a Equipe de Desenvolvimento em ambientes organizacionais nos quais o Scrum no totalmente adotado e compreendido.


O O O O ScrumScrumScrumScrum Master trabalhando para a Organizao Master trabalhando para a Organizao Master trabalhando para a Organizao Master trabalhando para a Organizao

O Scrum Master serve a Organizao de vrias maneiras, incluindo:

Liderando e treinando a organizao na adoo do Scrum;

Planejando implementaes Scrum dentro da organizao;

Ajudando funcionrios e partes interessadas a compreender e tornar aplicvel o Scrum e o desenvolvimento de produto emprico;

Causando mudanas que aumentam a produtividade do Time Scrum; e,

Trabalhando com outro Scrum Master para aumentar a eficcia da aplicao do Scrum nas organizaes.

@ribeirord

27


OOOO TimeTimeTimeTime ScrumScrumScrumScrum

O Time Scrum composto pelo ProductProductProductProduct OwnerOwnerOwnerOwner, a EquipeEquipeEquipeEquipe dedededeDesenvolvimentoDesenvolvimentoDesenvolvimentoDesenvolvimento e o ScrumScrumScrumScrum MasterMasterMasterMaster.

Times Scrum so auto-organizveis e multifuncionais. Equipesauto-organizveis escolhem qual a melhor forma paracompletarem seu trabalho, em vez de serem dirigidos por outrosde fora da equipe.

Equipes multifuncionais possuem todas as competnciasnecessrias para completar o trabalho sem depender de outrosque no fazem parte da equipe.


OOOO TimeTimeTimeTime ScrumScrumScrumScrum

O modelo de equipe no Scrum projetado para aperfeioar aflexibilidade, criatividade e produtividade.

Times Scrum entregam produtos de forma iterativa e incremental,maximizando as oportunidades de realimentao.

Entregas incrementais de produto Pronto garantem que umaverso potencialmente funcional do produto do trabalho estejasempre disponvel.

@ribeirord

28


ResumindoResumindoResumindoResumindo tudotudotudotudo issoissoissoisso............


vis

visvis

visooo

o

@ribeirord

29

SCRUM SCRUM SCRUM SCRUM VisoVisoVisoViso

VisoVisoVisoViso umaumaumauma claraclaraclaraclara imagemimagemimagemimagem quequequeque geragerageragera umaumaumauma atraoatraoatraoatrao emocionalemocionalemocionalemocional entreentreentreentrepessoaspessoaspessoaspessoas eeee produtoprodutoprodutoproduto ( quando se fala a viso quem escuta deve ser capazde imaginar como ser o produto)

Deve responder as seguintes perguntas:

Quem ir comprar este produto ? Quem o cliente alvo ? Quem ir usar o produto ? Quem so os usurios alvo ?

Quais problemas do cliente (ou usurios) o produto pretende resolver ? Qual valor o produto adicionar ?

Quais atributos o produto deve possuir para resolver estes problemas e quais garantiro o sucesso do produto ?

Como o produto pode ser comparado a produtos ou alternativas existentes ? Quais so os pontos diferenciais deste produto ?

Qual o preo alvo do produto ? Como a empresa pretende ganhar dinheiro com este produto ? Quais sero as fontes de faturamento e qual o seu modelo de negcio ? (quando aplicvel )

vis

visvis

visooo

o


Uma boa viso de produto permanece relativamenteconstante ao passo que o caminho paraimplementao da viso frequentemente adaptado.

vis

visvis

visooo

o

@ribeirord

30


ElevatorElevatorElevatorElevator StatementStatementStatementStatement

Para que , o um que .Diferentemente do nosso produto .

vis

visvis

visooo

o

http://www.flyingsolo.com.au/marketing/business-marketing/preparing-your-elevator-statement


ElevatorElevatorElevatorElevator StatementStatementStatementStatement

vis

visvis

visooo

o

Praticando...Praticando...Praticando...Praticando...

@ribeirord

31


ProductProductProductProduct Vision BoxVision BoxVision BoxVision Box

Nome do Produto Grficos Trs ou quatro pontos chave (benefcios)

para vender o produto Principais features no verso Principais requisitos operacionais

vis

visvis

visooo

o

http://www.agile-ux.com/2011/03/04/a-day-in-life-of-an-agileux-practitioner-vision/


ProductProductProductProduct Vision BoxVision BoxVision BoxVision Box

vis

visvis

visooo

o


@ribeirord

32


ProductProductProductProduct Road Road Road Road MapMapMapMapTcnica: Remember the Future

Descobrir o entendimento do sucesso do cliente e iniciar a visualizao do Road Map do produto/projeto

Ao invs de olhar o passo a passo, se posicione no momento final desejado e relembre o que foi feito para chegarmos neste ponto.

OBS: NO plano, NO cronograma, NO determinstico !OBS: NO plano, NO cronograma, NO determinstico !OBS: NO plano, NO cronograma, NO determinstico !OBS: NO plano, NO cronograma, NO determinstico !

vis

visvis

visooo

o

http://innovationgames.com/remember-the-future/


ProductProductProductProduct Road Road Road Road MapMapMapMap

vis

visvis

visooo

o


@ribeirord

33


Project Data Project Data Project Data Project Data SheetSheetSheetSheet

Formalizao da Viso

vis

visvis

visooo

o


Project Data Project Data Project Data Project Data SheetSheetSheetSheet

vis

visvis

visooo

o


@ribeirord

34

SCRUM SCRUM SCRUM SCRUM Preparando o Preparando o Preparando o Preparando o ProductProductProductProduct BacklogBacklogBacklogBacklog

UserUserUserUser StoryStoryStoryStory

Levantamento de Requisitos Tradicional

Premissas

Cliente:Linguagem de Negcio

Analista: Transforma em linguagem tcnica

Dev:Linguagem tcnica vira cdigos



Levantamento de Requisitos Tradicional

Premissas

Cliente:Linguagem de Negcio

Analista: Transforma em linguagem tcnica

Dev:Linguagem tcnica vira cdigos

Levantamento de Requisitos geis

Considera as premissas falsas !

NO necessrio requisitos detalhados

@ribeirord

35



CARTO

CONVERSAS

CONFIRMAO



IIIIndependenteNNNNegocivelVVVValiosa para usurios e clientesEEEEstimvelSSSSmall(pequena)TTTTestvel

@ribeirord

36



QUEM ?QUEM ?QUEM ?QUEM ?

O QUE ?O QUE ?O QUE ?O QUE ?

POR QUE ?POR QUE ?POR QUE ?POR QUE ?

Como um eu posso /gostaria/devo para

Como um P.O. eu devo REVISAR OS CONCEITOS DE SCRUM para FACILITAR O APRENDIZADO DE TPICOS AVANADOS

HistoryHistoryHistoryHistory CaseCaseCaseCase

A ideia gerar Persona e responder:

Como um ...Como um ...Como um ...Como um ...

Quero ...Quero ...Quero ...Quero ...

Para ...Para ...Para ...Para ...

Ex: Panela para preparar Salmo...

Como um Como um Como um Como um Cozinheiro ( Usurio)( Usurio)( Usurio)( Usurio)

Quero Quero Quero Quero panela de inox, com fundo oval e ... (Funcionalidade)(Funcionalidade)(Funcionalidade)(Funcionalidade)

Para Para Para Para cozinhar um salmo (Valor de Negcio)(Valor de Negcio)(Valor de Negcio)(Valor de Negcio)


@ribeirord

37

HistoryHistoryHistoryHistory CaseCaseCaseCase

A ideia gerar Persona e responder:

Pagamento de Boleto: RUIMRUIMRUIMRUIM

Para que o comprador possa pagar sem carto de crditoComo compradorQuero que o sistema de suporte a emisso de boletos

Pagamento de Boleto:

Para que eu consiga comprar produtos nessa lojaComo comprador que no tem carto de crditoQuero que o sistema de suporte a pagamento em boleto



Teste de AceitaoTeste de AceitaoTeste de AceitaoTeste de Aceitao

O P.O., com a colaborao de quem acharnecessrio, quem deve escrever os Testesde Aceitao, e deve faz-lo antes dacodificao

@ribeirord

38


StoriesStoriesStoriesStories, Temas e , Temas e , Temas e , Temas e EpicsEpicsEpicsEpics

EPICEPIC STORYSTORY STORYSTORYSTORY

STORY

STORY

STORY

STORY

STORY

TEMA


Priorizao do Priorizao do Priorizao do Priorizao do ProductProductProductProduct BacklogBacklogBacklogBacklog

Valor: Valor: Valor: Valor: Um item valioso se necessrio para que o produto seja lanado.

Conhecimento, incerteza e riscos: Conhecimento, incerteza e riscos: Conhecimento, incerteza e riscos: Conhecimento, incerteza e riscos: Como esses itens influenciam o sucesso do produto, eles devem ser sempre considerados como de alta prioridade

Capacidade para lanamento: Capacidade para lanamento: Capacidade para lanamento: Capacidade para lanamento: Itens que nos permitam mais rapidamente lanar um release de produto devem possuir boa prioridade

Dependncia: Dependncia: Dependncia: Dependncia: dependncia de itens em um Product Backlog um fato, e deve ser considerado ...

A priorizao por TEMAS deve ser considerado

@ribeirord

39

SCRUMSCRUMSCRUMSCRUMO corao do Scrum a SprintSprintSprintSprint, um time-box deum ms ou menos, durante o qual um Pronto,verso incremental potencialmente utilizvel doproduto, criado.

Sprints tem duraes coerentes em todo oesforo de desenvolvimento. Uma nova Sprintinicia imediatamente aps a concluso da Sprintanterior.

As Sprints so compostas por:

uma reunio de planejamento da Sprint, reunies dirias, (Daily Scrum) o trabalho de desenvolvimento, uma reviso da Sprint, (Review) restrospectiva da Sprint. (Retrospective)

SCRUMSCRUMSCRUMSCRUMDurante a Sprint:

No so feitas mudanas que podem afetar o objetivo da Sprint;

A composio da Equipe de Desenvolvimento permanecem constantes;

As metas de qualidade no diminuem; e,

O escopo pode ser esclarecido e renegociado entre o Product Owner e a Equipe de Desenvolvimento.

Cada Sprint tem a definio do que para ser construdo, um planoprojetado e flexvel que ir guiar a construo, o trabalho e o resultadodo produto.

@ribeirord

40

SCRUM SCRUM SCRUM SCRUM ---- Planning Meeting

O Planning Meeting o time-boxed e deve ocupar no mais de 5% do tempo do Sprint, se o Sprint de 2 semanas, essa reunio no deve consumir mais de 4 horas.

O objetivo definir as histrias que sero feitas no Sprint que acaba de comear:

Apresentao da Histria O P.O. apresenta a viso de negcio dos itens mais prioritrios do Product Backlog aos

desenvolvedores. (Ex: History Cases or Use Cases)

Dvidas do Negcio Os desenvolvedores tiram suas dvidas sobre as histrias, em termos da lgica de negcio

no entram em questes tcnicas

Opcional O Product Owner deve sair da sala, caso permanea ele no deve emitir opinies para o

prximo passo

O qu...

SCRUM SCRUM SCRUM SCRUM ---- Planning Meeting

Pontuao Os desenvolvedores do pontos cada uma das histrias, neste momento se considera a

parte tcnica. (Ex: Pontuao por Planning Poker)

Sprint Backlog Os desenvolvedores apresentam a pontuao para o P.O. e baseado na pontuao e na

capacidade de atendimento por pontos por Sprint da equipe escolhe as histrias mais prioritrias (negociando com os desenvolvedores, se necessrio).

Definio de Metas Se no tiver sido definida durante o processo, o P.O. define a meta do Sprint.

O qu...

Como...

@ribeirord

41

SCRUM SCRUM SCRUM SCRUM Daily scrum

Reunies dirias de no mximo 15 minutos. Reunio breve e informal , deve acontecer sempre no mesmo horrio e local combinados e dela participam apenas o TIME.

Funcionamento:

No horrio combinado, cada membro vai ao local combinado

Todos de P, respondem as seguintes perguntas: O que fiz desde o ltimo Scrum O que farei at o prximo Scrum Quais problemas esto me atrapalhando

Se algum tiver uma sugesto breve, se identifica para que, aps o dailyscrum, os interessados se reunam para resolver o problema juntos.

SCRUM SCRUM SCRUM SCRUM Review

A Reviso da Sprint executada no final da Sprint para inspecionar oincremento e adaptar o Backlog do Produto se necessrio.

Durante a reunio de Reviso da Sprint o Time Scrum e as partesinteressadas colaboram sobre o que foi feito na Sprint. Com base nisso eem qualquer mudana no Backlog do Produto durante a Sprint, osparticipantes colaboram nas prximas coisas que precisam ser prontas.

Esta uma reunio informal, e a apresentao do incremento destina-se amotivar e obter comentrios e promover a colaborao.

Esta uma reunio tem um time-boxed de 2.5% do Sprint. Por exemplo, uma Sprint de duas semanas tem Reunies de Reviso de duas horas.

@ribeirord

42

SCRUM SCRUM SCRUM SCRUM ReviewA Reunio de Reviso inclui os seguintes elementos:

O Product Owner identifica o que foi Pronto e o que no foi Pronto;

A Equipe de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas ocorreram dentro da Sprint, e como estes problemas foram resolvidos;

A Equipe de Desenvolvimento demonstra o trabalho que est Pronto e responde as questes sobre o incremento;

O Product Owner discute o Backlog do Produto tal como est. Ele (ou ela) projeta as provveis datas de concluso baseado no progresso at a data; e,

O grupo todo colabora sobre o que fazer a seguir, e assim que a Reunio de Reviso da Sprint fornece valiosas entradas para a Reunio de Planejamento da prxima Sprint.

SCRUM SCRUM SCRUM SCRUM Review

O resultado da Reunio de Reviso da Sprint um Backlog do Produto revisado que define o provvel Backlog do Produto para a prxima Sprint.

O Backlog do Produto pode tambm ser ajustado completamente para atender novas oportunidades.

Dicas: O sucesso do Review baseado na meta do Sprint Garantir que cliente, mas principalmente usurio aprove o produto Apresentar o produto sem influenciar o usurio Usurio deve dar feedback do uso NO ! NO ! NO ! NO ! Se codifica no Review Caso encontre BUGs, eles e novas ideias voltam para o Backlog

@ribeirord

43

SCRUM SCRUM SCRUM SCRUM Retrospective

Esta uma reunio tem um time-boxed de 3.75% do Sprint.

o momento de reflexo e exposio de problemas de um time e, portanto , o momento no qual se melhora o processo, evidencia-se e resolve-se problemas que afligem a equipe.

O propsito da Retrospectiva da Sprint :

Inspecionar como a ltima Sprint foi em relao as pessoas, relaes, processos e ferramentas;

Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e,

Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho;


O Scrum Master encouraja o Time Scrum a melhorar, dentro do processodo framework do Scrum, o processo de desenvolvimento e as prticas parafaz-lo mais efetivo e agradvel para a prxima Sprint.

Durante cada Retrospectiva da Sprint, o Time Scrum planeja formas deaumentar a qualidade do produto, adaptando a definio de Prontoquando apropriado.

Ao final da Retrospectiva da Sprint, o Time Scrum dever ter identificadomelhorias que sero implementadas na prxima Sprint.

A implementao destas melhorias na prxima Sprint a forma deadaptao inspeo que o Time Scrum faz a si prprio.

A Retrospectiva da Sprint fornece um evento dedicado e focado nainspeo e adaptao, no entanto, as melhorias podem ser adotadas aqualquer momento.

@ribeirord

44


Existem diversas formas de trabalhar na retrospectiva, uma das maisadotadas no Brasil funciona da seguinte forma:

Cada membro da caneta ganha caneta e post-it;

Cada um, sem olhar opinies ou conversar com outros membros dotime , escreve os pontos positivos e negativos do Sprint;

Um membro da equipe agrupa os post-its com opinies parecidas enarra o que foi descrito. Normalmente os problemas mais sriosaparecero mais vezes;

A equipe discute como resolver os problemas apontados j para oprximo Sprint. Evitar problemas recorrentes

Anota-se as solues discutidas e as mantem visveis durante o Sprint,como lembrete


@ribeirord

45



@ribeirord

46


O que pode alterar o tamanho da Sprint ?O que pode alterar o tamanho da Sprint ?O que pode alterar o tamanho da Sprint ?O que pode alterar o tamanho da Sprint ?


O que pode alterar o tamanho da Sprint ?O que pode alterar o tamanho da Sprint ?O que pode alterar o tamanho da Sprint ?O que pode alterar o tamanho da Sprint ?

EscopoEscopoEscopoEscopo Tamanho do timeTamanho do timeTamanho do timeTamanho do time Disponibilidade do clienteDisponibilidade do clienteDisponibilidade do clienteDisponibilidade do cliente Conhecimento do time sobre agilidadeConhecimento do time sobre agilidadeConhecimento do time sobre agilidadeConhecimento do time sobre agilidade Conhecimento do time sobre a tecnologiaConhecimento do time sobre a tecnologiaConhecimento do time sobre a tecnologiaConhecimento do time sobre a tecnologia Times novosTimes novosTimes novosTimes novos ............

@ribeirord

47


Dica:Dica:Dica:Dica:

Quanto maior o tempo de feedback pior ser... O Quanto maior o tempo de feedback pior ser... O Quanto maior o tempo de feedback pior ser... O Quanto maior o tempo de feedback pior ser... O leanleanleanleanpossui um conceito de possui um conceito de possui um conceito de possui um conceito de FailFailFailFail FastFastFastFast que afirma que que afirma que que afirma que que afirma que quanto mais rpido falhar, melhor para a mudana de quanto mais rpido falhar, melhor para a mudana de quanto mais rpido falhar, melhor para a mudana de quanto mais rpido falhar, melhor para a mudana de estratgia.estratgia.estratgia.estratgia.

SCRUM SCRUM SCRUM SCRUM Cebola do PlanejamentoCebola do PlanejamentoCebola do PlanejamentoCebola do Planejamento

Dia

Iterao

Release

Produto

Portflio

Estratgia

@ribeirord

48

SCRUM SCRUM SCRUM SCRUM Planejamento de ReleasePlanejamento de ReleasePlanejamento de ReleasePlanejamento de Release

Determinar Condies de Satisfao

Estimar os Itens do Backlog

Selecionar o Tamanho da

Sprint

Estimar Velocidade

PriorizarEstrias

Selecionar Itens e data do

Release


Tamanho

(27 pontos)

Clculo

(9 pontos por sprint)

Durao

(3 sprints)

@ribeirord

49


Tamanho

(27 pontos)

Clculo

(9 pontos por sprint)

Durao

(3 sprints)

ResultadoResultadoResultadoResultado

Sprint 1 Sprint 2 Sprint 3

SCRUM SCRUM SCRUM SCRUM Release Release Release Release BurndownBurndownBurndownBurndown

Fonte: http://www.mountaingoatsoftware.com/scrum/release-burndown

@ribeirord

50

SCRUM SCRUM SCRUM SCRUM Sprint Sprint Sprint Sprint BurndownBurndownBurndownBurndown

Fonte: http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1116

eXtremeeXtremeeXtremeeXtreme ProgrammingProgrammingProgrammingProgramming

Os Valores em XP so conceitos no tangveis queacredita-se fazer uma grande diferena na qualidadefinal do produto e na motivao dos times. Eles so:

Comunicao Feedback Coragem Simplicidade

@ribeirord

51


Valores:Valores:Valores:Valores:

ComunicaoComunicaoComunicaoComunicao O valor da comunicao visto dentro do time, entre seus

membros, e entre o time e o cliente. Ambos tem igual importncia.

A comunicao deve ser: DIRETA EFICAZ ESCLARECEDORA



FeedbackFeedbackFeedbackFeedback

um valor que engloba as relaes interpessoais, mas tambm se refere ao feedback que o prprio cdigo do projeto devolve aos membros do time

Para que o feedback do cdigo funcione bem, so necessrios testes automatizados de unidade e um servidor de integrao contnua para que os testes mais longos sejam rodados com frequncia e, se quebrarem, sinalizem uma inconsistncia.

Com o feedback o cliente pode: Identificar erros rapidamente Definir prioridades

@ribeirord

52



CoragemCoragemCoragemCoragem

O XP prega que os desenvolvedores precisam ter coragem para refatorar o cdigo em prol de melhorias em clareza e design e nada melhor para dar coragem do que testes automatizados.

Coragem tambm apagar o cdigo, mesmo funcionalidades inteiras, no importa o trabalho que tenha sido empregado para desenvolve-la.

Coragem para no tentar prever o futuro, mas sim focar no que realmente necessrio no momento. XP associa a essa idia a sigla YAGNI (you aint gonna need it)



SimplicidadeSimplicidadeSimplicidadeSimplicidade

Considere que , na mdia, o tempo de construo de um software cerca de 30% do tempo investido nele. Os outros 70% so dedicados a manuteno do sistema.

Num cenrio como esse, a simplicidade essencial para tornar esse perodo maior muito agradvel.

O desenvolvedor deve: Implementar apenas o bsico No antecipar funcionalidades

@ribeirord

53


ValoresValoresValoresValores::::

Propriedade Coletiva do CdigoPropriedade Coletiva do CdigoPropriedade Coletiva do CdigoPropriedade Coletiva do Cdigo Programao PareadaProgramao PareadaProgramao PareadaProgramao Pareada Testes Automatizados e Testes Automatizados e Testes Automatizados e Testes Automatizados e testtesttesttest firstfirstfirstfirst Test Test Test Test DrivenDrivenDrivenDriven Design (TDD)Design (TDD)Design (TDD)Design (TDD) Integrao contnua e Integrao contnua e Integrao contnua e Integrao contnua e DeployDeployDeployDeploy ContnuoContnuoContnuoContnuo RefatoraoRefatoraoRefatoraoRefatorao ConstanteConstanteConstanteConstante



Propriedade Coletiva do CdigoPropriedade Coletiva do CdigoPropriedade Coletiva do CdigoPropriedade Coletiva do Cdigo

comum que desenvolvedores trabalhem em partes independentes do cdigo. A consequncia desta abordagem que cada desenvolvedor se sente responsvel apenas por sua parte...

O ideal o sentimento de time onde todos so responsveis pelo cdigo. Assim, um desenvolvedor livre para interferir em qualquer parte do cdigo sem irritar o dono do cdigo.

@ribeirord

54



Programao Pareada (Programao Pareada (Programao Pareada (Programao Pareada (pairpairpairpair programmingprogrammingprogrammingprogramming))))

A programao em par uma forma eficaz de reduzir a incidncia de bugs em um sistema.

Quem trabalha continuamente com programao em par se habitua a corrigir e ter seu trabalho corrigido dezenas de vezes ao dia. A incidncia de erros identificados pelo colega costuma ser to elevada que surpreende quem no est acostumado ao uso da tcnica.

Equipes que trabalham em par conseguem reduzir drasticamente a insero de defeitos em seus cdigos.

A programao em par ajuda os desenvolvedores a criarem solues mais simples, mais rpidas de implementar e mais fceis de manter.



Programao Pareada (Programao Pareada (Programao Pareada (Programao Pareada (pairpairpairpair programmingprogrammingprogrammingprogramming))))

A programao em par tambm uma forma de fazer com que o desenvolvedor tenha mais confiana no cdigo que produz.

O conjunto de caractersticas apresentadas acima faz com que a programao em par acelere o desenvolvimento significativamente, embora primeira vista parea o contrrio.

Programar em par exige que as pessoas envolvidas sejamreceptivas, compreensivas umas com as outras, engajadas e,sobretudo, humildes. necessrio aceitar que somos falveispara que possamos programar em par. Weinberg criou o termoegoless programming, ou seja, programao sem ego.

@ribeirord

55



Testes Automatizados e Testes Automatizados e Testes Automatizados e Testes Automatizados e testtesttesttest firstfirstfirstfirst

Um dos grandes desafios trabalhar em cdigos antigos.... O XP prega arefatorao constante ! Mas quanto maior o projeto, maior a quantidade decdigo no escrita por ns ou antigo, o que aumenta a insegurana de refatoraro cdigo...impedindo a evoluo do projeto.



Testes Automatizados e Testes Automatizados e Testes Automatizados e Testes Automatizados e testtesttesttest firstfirstfirstfirst

O XP prega o uso extensivo de testes automatizados que descrevem ocomportamento de uma funcionalidade, preferencialmente escritos antesmesmo do cdigo que eles testam, prtica que recebe o nome dedesenvolvimentodesenvolvimentodesenvolvimentodesenvolvimento dirigidodirigidodirigidodirigido porporporpor testestestestestestestes (Test(Test(Test(Test DrivenDrivenDrivenDriven DevelopmentDevelopmentDevelopmentDevelopment ---- TDD)TDD)TDD)TDD)....

Os testes automatizados tem 2 funes importantes:

PermitirPermitirPermitirPermitir refatoraorefatoraorefatoraorefatorao :::: podemos refatorar o cdigo com mais segurana. Podemos alteraro cdigo e verificar automaticamente se o software continua funcionando.

DocumentarDocumentarDocumentarDocumentar:::: Os testes devem ter nomes que explicam quais funcionalidades eles testam,assim ao executar o cdigo, o desenvolvedor sabe quais funcionalidades foramimplementadas e qual o comportamento esperado pelo cdigo.

@ribeirord

56



Test Test Test Test DrivenDrivenDrivenDriven Design (TDD)Design (TDD)Design (TDD)Design (TDD)

Queremos que os nossos testes guiem o prprio design das classes do Queremos que os nossos testes guiem o prprio design das classes do Queremos que os nossos testes guiem o prprio design das classes do Queremos que os nossos testes guiem o prprio design das classes do sistema sistema sistema sistema

O processo TDD funciona da seguinte maneira:O processo TDD funciona da seguinte maneira:O processo TDD funciona da seguinte maneira:O processo TDD funciona da seguinte maneira:

Faz-se o teste automatizado para o caso mais simples

Roda-se o teste (que no dever passar pois a funcionalidade ainda no foi implementada)

Implementa-se atravs da mudana mais simples possvel que faa o teste passar

Se o cdigo no estiver o melhor possvel: Refatora

Certifique-se que os testes continuem passando

Se o cdigo estiver bom Volte para o primeiro item com o prximo teste mais simples

@ribeirord


@ribeirord

57



Integrao contnua e Integrao contnua e Integrao contnua e Integrao contnua e DeployDeployDeployDeploy ContnuoContnuoContnuoContnuo



RefatoraoRefatoraoRefatoraoRefatorao ConstanteConstanteConstanteConstante

Com o aumento do projeto comum que pequenas partes de cdigo mal Com o aumento do projeto comum que pequenas partes de cdigo mal Com o aumento do projeto comum que pequenas partes de cdigo mal Com o aumento do projeto comum que pequenas partes de cdigo mal escrito se acumulem e, quando menos se esperar, compromete todo o projeto. escrito se acumulem e, quando menos se esperar, compromete todo o projeto. escrito se acumulem e, quando menos se esperar, compromete todo o projeto. escrito se acumulem e, quando menos se esperar, compromete todo o projeto. ( ( ( ( Big Ball Big Ball Big Ball Big Ball ofofofof MudMudMudMud Joe Joe Joe Joe YoderYoderYoderYoder))))

A melhor forma de evitar este problema atravs de pequenas A melhor forma de evitar este problema atravs de pequenas A melhor forma de evitar este problema atravs de pequenas A melhor forma de evitar este problema atravs de pequenas refatoraesrefatoraesrefatoraesrefatoraesconstantes.constantes.constantes.constantes.

Refatorao uma tcnica controlada para reestruturar um trecho decdigo existente, alterando sua estrutura interna sem modificar seucomportamento externo. (Martin Fowler)

@ribeirord

58





@ribeirord

59

O blackjack jogado com um ou mais baralhos de 52525252 cartascartascartascartas, paracujos valores ser designado um total de pontos.

As cartas de 2 a 10 tero o valor dos nmeros. Reis, damas e valetesvalem 10 pontos cada e ases podero ser usados tanto como 1 ou 11.

O objetivo para o jogador ser comprar cartas at um total de 21pontos (sem exceder), vencendo o total das cartas do distribuidor.

Design a deck of cardsppppublicublicublicublic classclassclassclass Deck{privateprivateprivateprivate readonlyreadonlyreadonlyreadonly Ilist cards = new List( );

publicpublicpublicpublic Deck( ){cards.Add(Card.Dois_de_Copas);cards.Add(Card.Tres_de_Copas);//..restante de copas

cards.Add(Card.Dois_de_Ouros);cards.Add(Card.Tres_de_Ouros);//..restante de ouros

cards.Add(Card.Dois_de_Espadas);cards.Add(Card.Tres_de_Espadas);//..restante de Espadas

cards.Add(Card.Dois_de_Paus);cards.Add(Card.Tres_de_Paus);//..restante de paus

//Coringacards.Add(Card.Coringa);}

@ribeirord

60

BUG DESCOBERTO !BUG DESCOBERTO !BUG DESCOBERTO !BUG DESCOBERTO !

No existe CoringaCoringaCoringaCoringa no Black Jack

Como testar automaticamente em cada novo incremento para que problemas assim no ocorram ?

http://junit.sourceforge.net/doc/testinfected/testing.htm

public class DeckTest{

public void Verify_Deck_contains_52_cards( ){

var deck = new Deck( );Assert.AreEqual(52,deck.Count( ) );

}}

@ribeirord

61

Criar Baralho de Cartas ....

Critrios de Teste .52 cartas no Baralho.13 Cartas de Cada Naipe.No pode existir carta Coringa.Uma carta de Cada Tipo

Critrios de Teste .52 cartas no Baralho.13 Cartas de Cada Naipe.No pode existir carta Coringa.Uma carta de Cada Tipo

@ribeirord

62

Critrios de Teste .52 cartas no Baralho. OKOKOKOK13 Cartas de Cada Naipe.No pode existir carta Coringa.Uma carta de Cada Tipo

public class DeckTest2{



}}

Critrios de Teste .52 cartas no Baralho. OKOKOKOK13 Cartas de Cada Naipe. OKOKOKOKNo pode existir carta Coringa.Uma carta de Cada Tipo




}

public void Verify_Deck_contains_13_cards_for_each_suit( ){

var deck = new Deck( );Assert.AreEqual(13,deck.NumberofCopas( ) );Assert.AreEqual(13,deck.NumberofEspadas( ) );Assert.AreEqual(13,deck.NumberofOuros( ) );Assert.AreEqual(13,deck.NumberofPaus( ) );

}}

@ribeirord

63

Critrios de Teste .52 cartas no Baralho. OKOKOKOK13 Cartas de Cada Naipe. OKOKOKOKNo pode existir carta Coringa. OKOKOKOKUma carta de Cada Tipo


//..Continuao

public void Verify_Deck_contains_no_joker( ){

var deck = new Deck( );Assert.IsFalse(deck.Contains(Card.Coringa ) );

}

}

Critrios de Teste .52 cartas no Baralho. OKOKOKOK13 Cartas de Cada Naipe. OKOKOKOKNo pode existir carta Coringa. OKOKOKOKUma carta de Cada Tipo OKOKOKOK


//..Continuao

public void Verify_Every_Card_in_the_Deck ( ){

var deck = new Deck( );Assert.IsTrue(deck.Contains(Card. Dois_de_Copas ) );Assert.IsTrue(deck.Contains(Card. Tres_de_Copas ) );

//...Testar todas as cartas vlidas para cada naipe

}

}

@ribeirord

64

Planning Planning Planning Planning PokerPokerPokerPokerA ideia principal por traz do Planning Poker permitir que todos osmembros do time de desenvolvimento que esto comprometidos naimplementao do Sprint participem colocando a sua viso decomplexidade para que juntos possam chegar a um indicador decomplexidade comum para o time.

A escala de complexidade baseada na sequncia de Fibonacci ( 1, 2, 3,

5, 8, 13,21, ), ou em outra escala definida pela equipe...

0000 1/21/21/21/2 1111

2222 3333 5555

8888 13131313 20202020

40404040 100100100100

????

@ribeirord

65

Planning Planning Planning Planning PokerPokerPokerPoker

Cada participante do time que estiver comprometido recebe um conjunto de cartas sendo cada uma com o nmero de complexidade.

O grupe se rene geralmente na reunio Sprint Planning e esclarece as histrias com o PO (Product Owner) para depois estimar uma a uma.

Seguindo a ordem de sequencia das s histrias j priorizadas pelo PO.

Ento o time conta at trs e cada um apresenta uma das cartas ao mesmo tempo. Esse um momento importante, pois nenhum membro pode influenciar o outro na hora de mostrar as cartas.

Planning Planning Planning Planning PokerPokerPokerPoker

Aps apresentada as cartas confere-se os nmeros das mesmas para verse deu tudo igual ou ocorreu divergncias. Em caso de divergncia cadamembro pode argumentar o que o levou a pensar diferente dos demais enesse momento pode usar os argumentos que justifique aquele item sermais complexo ou mais simples.

Com o tempo voc vai observar opinies do tipo Eu j implementei umarotina parecida em um projeto anterior que trazem a tona o grande valordessa tcnica que justamente fazer as pessoas serem ouvidas.

Aps a apresentao dos argumentos cada pessoa que ficou na dvidapode propor uma nova votao e mudar o seu voto para mais ou paramenos conforme o novo entendimento da questo. Por isso um item queestava complexo pode ser finalizado com mais simples ou vice-versaprevalecendo o entendimento do time sobre a questo.

@ribeirord

66

Leitura ComplementarLeitura ComplementarLeitura ComplementarLeitura Complementar

Dvidas ou Sugestes de Melhorias, entre Dvidas ou Sugestes de Melhorias, entre Dvidas ou Sugestes de Melhorias, entre Dvidas ou Sugestes de Melhorias, entre em contato: [email protected] contato: [email protected] contato: [email protected] contato: [email protected]

Agilidade

Documents

Transcript of Agilidade