14

2 Mtodos geis

2.1. Manifesto gil Em fevereiro de 2001, dezessete representantes de diversas prticas e metodologias de desenvolvimento se reuniram em uma estao de esqui, em Utah nos EUA para discutir mtodos mais leves de desenvolvimento do que o tradicional desenvolvimento orientado a documentos. Autodenominados de The Agile Alliance criaram o Manifesto for Agile Software Development ou simplesmente Manifesto gil para definir a abordagem hoje conhecida como desenvolvimento gil.
PUC-Rio - Certificao Digital N 0912827/CA

Estamos descobrindo maneiras melhores de desenvolver software fazendoo ns mesmos e ajudando outros a faz-lo. Atravs desse trabalho, passamos a valorizar: Indivduos e interao entre eles mais que processos e ferramentas; Software em funcionamento mais que documentao abrangente; Colaborao com o cliente mais que negociao de contratos; Responder s mudanas mais que seguir um plano. Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda. [Highsmith, 2001] 2.2. Princpios Alm do manifesto gil, foram documentados doze princpios com a inteno de dar suporte a esse manifesto. Nossa maior prioridade satisfazer o cliente atravs da entrega contnua e adiantada de software com valor agregado.

15

Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento. Processos geis tiram vantagem das mudanas visando vantagem competitiva para o cliente. Entregar frequentemente software funcionando, em poucas semanas a poucos meses com preferncia menor escala de tempo. Pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte necessrio e confie neles para fazer o trabalho. O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de desenvolvimento atravs de conversa face a face. Software funcionando a medida primria de progresso. Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente. Contnua ateno excelncia tcnica e bom design aumenta a agilidade. Simplicidade -- a arte de maximizar a quantidade de trabalho no realizado -- essencial. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizveis. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina e ajusta seu comportamento de acordo.

PUC-Rio - Certificao Digital N 0912827/CA

16

[Highsmith. 2001] 2.3. Processos definidos versus processos empricos

tpico adotar a abordagem de modelagem definida (terica) quando os mecanismos subjacentes pelos quais um processo opera so razoavelmente bem entendidos. Quando o processo muito complexo para ser definido, a abordagem emprica a escolha apropriada. [Ogunnaike / Ray, 1992] O modelo de controle de processos definidos requer que cada parte do trabalho seja completamente entendida. Dado um conjunto de inputs bem definidos, os mesmos outputs so gerados todas s vezes. Um processo definido pode ser iniciado e executado at sua concluso, com os mesmos resultados a cada
PUC-Rio - Certificao Digital N 0912827/CA

execuo. As principais caractersticas de processos definidos que podemos destacar so: Processo definido com mecanismos subjacentes claramente entendidos Sucesso de atividades claramente definidas e lineares Capacidade de estimar tempos de execuo de cada atividade O modelo de controle de processos empricos prov e exercita o controle atravs de inspeo frequente, com visibilidade, e adaptao para processos que no so perfeitamente definidos e geram sadas imprevisveis e no-repetveis. Por muitos anos, metodologias de desenvolvimento de software foram baseadas no modelo de controle de processo definido. Mas desenvolvimento de software no um processo que gera a mesma sada dada uma certa entrada. O mtodo gil de desenvolvimento de software Scrum baseado no modelo de controle de processos emprico [Schwaber / Beedle, 2001].

17

2.4. Scrum 2.4.1. Histrico O Scrum foi criado oficialmente na dcada de 90, por Ken Schwaber e Jeff Shuterland, com a ajuda de Mike Beedle, John Scumniotales e Jeff McKenna. A sua criao foi na realidade feita de maneira completamente independente, em duas frentes: de um lado, Ken Schwaber, e do outro Jeff Shuterland. Em 19951996, Ken e Jeff se reuniram e documentaram o processo do Scrum como se conhece hoje em dia [Sutherland, 2004]. Em 2001, Ken Schwaber e Jeff Shuterland fizeram parte do grupo de profissionais que assinou o Agile Manifesto. Desde ento, Scrum vm sendo usado nos mais diferentes projetos, pelas mais diferentes organizaes. Grandes empresas multinacionais, pequenas empresas startups, desenvolvedores para agncias do governo, e at a indstria de games e animao vm se beneficiando do Scrum [Sutherland, 2004].
PUC-Rio - Certificao Digital N 0912827/CA

2.4.2. O que ? Scrum um processo iterativo incremental para desenvolver qualquer produto ou gerenciar qualquer trabalho. No fim de cada Sprint (iterao), produzido um incremento de funcionalidades potencialmente entregveis. As principais caractersticas do Scrum so [Schwaber, 2004]: um processo gil (agile) para gerenciar e controlar trabalho. um embrulho para as prticas existentes de engenharia. uma aproximao coletiva (equipes) para desenvolver produtos e sistemas iterativamente e incrementalmente, onde requisitos mudam rapidamente. um processo que controla o caos de interesses e necessidades conflitantes. uma maneira de melhorar a comunicao e maximizar cooperao. uma forma de detectar e remover barreiras que entrem no meio do desenvolvimento e entregas de produtos. uma forma de maximizar produtividade.

18

Scrum escalvel de um nico projeto a toda uma organizao, com vrios projetos inter-relacionados. Scrum uma maneira de fazer com que todos se sintam bem em relao ao seu trabalho, suas contribuies, e que eles fizeram o melhor possvel, o melhor que eles poderiam fazer. Scrum requer trabalho duro. Scrum requer comprometimento 2.4.3. Fluxo

PUC-Rio - Certificao Digital N 0912827/CA

Figura 1 Fluxo do Scrum [Mountain Goat, 2005] O Scrum define papis, artefatos e cerimnias, que provm o Scrum Framework. O Scrum trabalha em um processo iterativo e incremental, onde as iteraes so chamadas de Sprint. Os Sprints tm durao pr-definida e fixa. Normalmente um Sprint dura entre 2 a 4 semanas. Durante o Sprint, o produto planejado, codificado e testado. No final de cada Sprint h uma entrega. 2.4.4. Durao dos Sprints

importante que todos os Sprints possuam a mesma durao, pois a utilizao de um perodo constante leva a um melhor ritmo da equipe. Procure

19

manter a durao o mais constante possvel, qualquer que seja o tamanho do Sprint que voc escolher. Essa constncia d estabilidade ao time. Ao planejar a durao do Sprint do seu projeto, procure responder seguinte pergunta: Por quanto tempo possvel manter uma mudana fora do Sprint? Dependendo da estabilidade dos seus requisitos e caractersticas do seu negcio, voc encontrar a durao ideal. Manter a estabilidade dentro de um Sprint a regra.

2.4.5. Papis e responsabilidades 2.4.5.1. Product Owner O Product Owner, ou simplesmente PO, representa o cliente, patrocinadores
PUC-Rio - Certificao Digital N 0912827/CA

e/ou financiadores do projeto. Muitas vezes, pode ser um representante do cliente dentro da empresa, ou um analista de negcio. quem vai definir, gerenciar e priorizar os requisitos, gerenciar o ROI (Return over investment). O Product Owner trabalha como parte do time que realiza a entrega. responsabilidade do PO: Definir e manter uma viso compartilhada do projeto Gerenciar o ROI Apresentar requisitos iniciais e incrementais ao time Priorizar cada requisito em relao ao valor de negcio (Business Value) Gerenciar e priorizar o Product Backlog Gerenciar novos requisitos e sua priorizao Fazer o planejamento de entregas (Release Planning) Agir como mediador quando houver mais de um cliente Garantir que especialistas no domnio do negcio estaro disponveis para o time quando necessrio Aceitar ou rejeitar o resultado dos trabalhos Uma das responsabilidades do Product Owner, Definir e manter uma viso compartilhada do projeto, merece ser mais bem explicada. A viso do produto ,

20

uma viso geral, ou big picture, do produto, que todos tm conhecimento e entendimento desta viso. Esta viso vai guiar as atividades de desenvolvimento de produto, e prov direo ao time em relao ao que estamos tentando alcanar. Esta viso permite nos abrir para o fato que podemos atingir o possvel. Exemplo: Implementar um repositrio eletrnico central de documentos para solicitaes de hipoteca, provendo ao banco (cliente) a habilidade para lidar com as quantidades crescentes de solicitaes de hipoteca sem contratar novos funcionrios, atravs de ganho de produtividade. A soluo vai nos permitir reduzir o tempo de espera dos clientes por respostas, mantendo nossa vantagem competitiva como um fornecedor/provedor orientado clientes de servios financeiros, enquanto ao mesmo tempo reduziremos atritos entre os funcionrios, provendo economia significante em treinamento e reposio de funcionrios existentes.
PUC-Rio - Certificao Digital N 0912827/CA

2.4.5.2. Scrum Master O Scrum Master, ou simplesmente SM, representa a gesto do projeto, mas no no sentido de gesto tradicional. Na realidade, o SM funciona mais como um mediador e lder coach (em sentindo de coaching, como um tcnico de time de futebol). O Scrum Master trabalha com e para o time. responsabilidade do SM: Permitir que o time se auto-organize para realizar o trabalho Garantir que as vias de comunicao estejam livres e acessveis Garantir e ajudar que o time siga o processo do Scrum Cuidar e proteger a equipe de interferncias externas, de modo a garantir que a produtividade do time no seja a afetada Remover impedimentos (obstculos) que o time encontrar Agir como facilitador nas cerimnias como o Daily Meeting Garantir a colaborao entre os papis

21

2.4.5.3. Equipe A equipe composta por indivduos que esto comprometidos em realizar o trabalho proposto. Os times so cross-functional. Mas o que isso quer dizer? Nos mtodos tradicionais, ns temos papis distintos, por exemplo, arquitetos, testadores, etc. Em um time Scrum, temos pessoas com habilidades de arquitetura que podem ter uma habilidade secundria para ajudar nos testes. Ou seja, colaborao a palavra de ordem. Cada membro do time responsvel por: Definir a meta do Sprint (Sprint Goal) Comprometer-se com o trabalho, e faz-lo com o mximo de qualidade Trabalhar tendo em mente a viso do produto e o objetivo do Sprint
PUC-Rio - Certificao Digital N 0912827/CA

Colaborar com demais membros do time e ajudar o time a se autoorganizar Comparecer s reunies do Daily Meeting Levantar impedimentos Estimar requisitos Manter seu prprio progresso (com ajuda do Scrum Master) As equipes de Scrum tm o tamanho ideal de 7 +/ 2 pessoas. 7 o nmero timo. Times pequenos so mais produtivos que times grandes, por causa da quantidade de vias de comunicao existente entre os membros do grupo. Se o seu time for maior que o recomendado, ento ele deve se dividir em dois e o trabalho de ambos deve ser sincronizado. Outro ponto importante a lembrar manter a estabilidade do time durante o Sprint, ou seja, evitar mudanas na equipe no meio de um Sprint. 2.4.6. Cerimnias As cerimnias do Scrum so reunies, formais ou no, que acontecem em momentos especficos do Sprint. A seguir, falaremos sobre as seguintes cerimnias do Scrum:

22

Sprint Planning Daily Meeting Sprint Review Sprint Retrospective 2.4.6.1. Sprint Planning A reunio de Sprint Planning uma reunio de curta durao (geralmente 4 horas), e tem como objetivo planejar o trabalho da equipe durante o Sprint. O dia em que ocorre a reunio de Sprint Planning considerado o primeiro dia do Sprint. Esta reunio dividida normalmente em 2 partes: Sprint Planning I e II, de igual durao. Nesta reunio, participam somente as pessoas comprometidas com a entrega. Pessoas interessadas ou especialistas no negcio podem ser convocadas
PUC-Rio - Certificao Digital N 0912827/CA

reunio pontualmente, entretanto devem se retirar aps responder os questionamentos ou prestar os esclarecimentos devidos. 2.4.6.1.1. Sprint Planning I Participantes: Entradas: Sadas Selected Product Backlog Objetivo do prximo Sprint Equipe comprometida e com entendimento dos requisitos Product Backlog (Estimado e Priorizado) Dados histricos de capacidade da equipe (se houver) Condies do negcio Equipe (Team) Scrum Master Product Owner

O objetivo do Sprint decidido pelo Product Owner em conjunto com o time. Todos discutem os itens de Backlog priorizados e estimados e definem o objetivo, que deve ser uma frase simples e objetiva. Por exemplo:

23

Permitir que pessoas se cadastrem em nossa newsletter corporativa e se descadastrem caso eles no desejem mais receb-la. Esta reunio tambm tem como sada o comprometimento da equipe em realizar o trabalho proposto durante o Sprint. A equipe, e somente a equipe, pode decidir e se comprometer a respeito do trabalho que ser executado, seja a partir de dados histricos de capacidade da equipe, ou a partir da capacidade que a equipe espera atingir no Sprint. Em outras palavras, o Product Owner prioriza e seleciona, mas s a equipe pode dizer o que ser atingido durante o Sprint. Se o Product Owner ficar insatisfeito, tudo o que ele pode fazer repriorizar as tarefas e ajustar o objetivo do Sprint. 2.4.6.1.2. Sprint Planning II Na reunio de Planning II, participam somente as pessoas que
PUC-Rio - Certificao Digital N 0912827/CA

efetivamente iro realizar o trabalho. Aqui j no cabe mais a participao do Product Owner, somente da equipe e do Scrum Master. O Product Owner pode ser consultado durante o Sprint Planning II caso ocorram dvidas a respeito dos requisitos selecionados. Participantes Entradas Sadas Sprint Backlog Selected Product Backlog Objetivo do prximo Sprint Equipe (Team) Scrum Master

O Sprint Backlog uma expanso do Product Backlog selecionado durante a reunio de Planning I. A equipe vai ler, de um por um, os itens selecionados, e decompor em tarefas necessrias para considerar o item de Backlog implementado, pronto. Este trabalho feito colaborativamente, com a participao de toda a equipe. recomendvel manter as tarefas num nvel de granularidade suficiente para admitir tarefas de 4 ou 8 horas (ou seja, no mximo 1 dia de

24

trabalho). Estas tarefas podem ser estimadas individualmente, ou pode-se assumir o tamanho do requisito previamente estimado (isso fica cargo da equipe). importante firmar o conceito de pronto (done), para garantir o entendimento de todos. Pronto significa que o requisito foi implementado e testado, e est num estado entregvel, caso seja necessrio. Ter isto firmado em mente importante porque na eventualidade de um item de Backlog ter ficado parcialmente implementado, digamos, 80% num Sprint, isso significa que ele no est pronto e dever ser selecionado como item de Backlog para o prximo Sprint. No trmino desta cerimnia, temos a equipe comprometida, uma meta de velocidade pr-estabelecida e o trabalho decomposto em tarefas de granularidade suficiente para serem trabalhadas. 2.4.6.2. Executando o Sprint
PUC-Rio - Certificao Digital N 0912827/CA

Aps a reunio de Planning I e II, a equipe est pronta para iniciar o trabalho, auto-organizando-se para decidir quem executa o qu e quando. importante que os membros da equipe se comuniquem para efetivar esta autoorganizao. Durante esta fase, que dura entre 2-4 semanas, que o trabalho ser executado e impedimentos sero levantados. Aqui que o trabalho do Scrum Master ser mais evidenciado, agindo como um desobstruidor, protetor e mentor. De maneira a manter todos informados, feita uma cerimnia de acompanhamento dirio, o Daily Meeting, sobre a qual vamos conhecer mais adiante. tambm durante a fase de execuo que o Scrum Master deve agir como um escudo para a equipe, evitando que trabalho no planejado ou novos itens de Backlog sejam includos no Sprint. Vamos para um exemplo: Estamos trabalhando em um Sprint de 4 semanas. Uma nova solicitao de negcio chegou para o Product Owner, com um grau de importncia alto. O Product Owner ento, apressa-se em comunicar ao time que eles devem comear a trabalhar nesta nova funcionalidade/solicitao agora. Isso disruptivo para o time, e introduz instabilidade. O time j gastou tempo planejando o Sprint, e est mentalmente focado em atingir o objetivo do Sprint, e mais importante, entregar software funcionando. O Product Owner deve tentar conversar com o cliente, e explicar como isso ir interferir no trabalho do

25

time, e priorizar esta demanda no Product Backlog para ser trabalhado no prximo Sprint. Se um bug crtico foi encontrado, e a no correo deste bug trar maiores consequncias organizao ou a seus clientes (por exemplo, pagamentos de carto de crdito esto sendo duplicados), ento compreensvel que um item do Sprint Backlog seja retornado ao Product Backlog e substitudo pela nova demanda. Se por alguma razo, a situao for muito catica, ento melhor dissolver o Sprint e comear novamente com uma nova reunio de Sprint Planning. Garanta que uma reunio de retrospectiva desse Sprint prematuramente terminada ir acontecer, para que possam ser encontradas as causas reais desse acontecimento. A prtica de interromper um Sprint deve ser adotada como ltimo recurso. Ao ser aplicada alguns fatores que possivelmente causariam a aplicao desse recurso devem ser observados, como por exemplo:
PUC-Rio - Certificao Digital N 0912827/CA

Planejamento pobre Priorizao no est correta Falta de entendimento e de suporte das prticas geis Ambiente de negcio passou por mudana massiva Polticas corporativas No h um acompanhamento cclico do cliente quanto evoluo do Backlog 2.4.6.3. Daily Meeting A reunio de Daily Meeting (ou Daily Scrum) um encontro pblico da equipe, de curtssima durao (no mximo 15 minutos). Nesta reunio so admitidos membros do time e interessados no projeto, entretanto tudo que os interessados podem fazer observar, sem fazer comentrios nem perguntas. Seguem algumas regras: Reunio com frequncia diria Durao: no mximo 15 minutos Mesmo local e horrio, todos os dias Participantes:

26

Scrum Master, Team, Product Owner Interessados (somente como ouvintes, no podem interromper sob hiptese alguma)

Entradas so geradas a partir de trs perguntas: O que eu tenho atingido desde a nossa ltima reunio? O que me proponho a atingir at a prxima reunio? Quais problemas esto me impedindo ou atrapalhando na realizao do meu trabalho? Como sada, temos impedimentos e decises tomadas. Os principais benefcios que podemos enumerar desta reunio so:
PUC-Rio - Certificao Digital N 0912827/CA

Visibilidade para todo o grupo: todos sabem o que est acontecendo Ajudar o Scrum Master a identificar impedimentos, para que os mesmos possam ser resolvidos e proteger a produtividade do time. obrigao do Scrum Master trabalhar em cima dos itens de impedimento levantados durante a reunio, e escal-los alta direo caso ele no seja capaz de resolver. Impedimentos detm que o time realize seu trabalho em um ambiente timo, e podem comprometer o objetivo do Sprint. funo do mediador da reunio (normalmente o Scrum Master) manter discusses tcnicas ou a respeito de soluo de problemas de fora, para que sejam por exemplo feitas imediatamente aps a reunio. Muitas vezes pessoas podem se alongar demais na discusso de um problema tcnico, e isso pode atrapalhar o bom andamento e o propsito da reunio. O mediador da reunio deve declarar claramente para os envolvidos o trmino do Daily Meeting, deixando assim o time vontade para discutir problemas ou questes tcnicas, ou para agendar uma outra reunio para discusso do tema entre os envolvidos.

27

2.4.6.4. Sprint Review Esta cerimnia realizada no ltimo dia do Sprint. uma reunio informal (em geral 4 horas) onde todos so convidados a participar, principalmente os clientes do projeto. Normalmente realizada numa sala de reunio ou auditrio, de portas abertas, e o objetivo desta reunio dar a oportunidade equipe para apresentar o resultado do trabalho realizado durante o Sprint. Tipicamente acontece como uma demonstrao do incremento de funcionalidade, ou da sua arquitetura informal. A equipe tem no mximo 1 hora para se preparar para esta reunio, na qual deve ser apresentada a demo do sistema. Funcionalidade que no ficou pronta (aqui, mais uma vez, destaco para a importncia de alinhar o significado de pronto entre todos os envolvidos, pois este conceito pode variar de organizao para organizao) no pode ser apresentada. Artefatos que no so funcionalidade tambm no podem ser
PUC-Rio - Certificao Digital N 0912827/CA

apresentados, com exceo de quando eles so usados como suporte para entendimento da funcionalidade demonstrada. Artefatos no podem ser demonstrados como produtos de trabalho, e seu uso deve ser minimizado para evitar confundir os clientes, ou requerer que eles entendam como funciona desenvolvimento de sistemas. O ambiente de demonstrao deve ser o mais prximo do ambiente de produo. Na maioria do tempo da reunio, membros do time iro apresentar funcionalidades e responder perguntas dos clientes a respeito dos produtos apresentados. No final desta reunio, os clientes so questionados, um por um, e devem declarar suas impresses, mudanas desejadas e a prioridade dessas mudanas. O Product Owner ento discute com os clientes e o time sobre a potencial reorganizao do Product Backlog baseado no feedback recebido. Adicionalmente, os clientes podem apontar e identificar funcionalidades que no foram entregues, ou no foram entregues conforme esperado, e solicitar que esta funcionalidade em questo seja retornada ao Product Backlog para repriorizao. Alm disso, os clientes tambm podem solicitar que novas funcionalidades sejam adicionadas ao Product Backlog. O objetivo desta reunio claro: apresentar o incremento de funcionalidade atingido durante o Sprint, e receber feedback dos clientes, de forma a repriorizar o Product Backlog e adicionar novos itens ao mesmo.

28

2.4.6.5. Sprint Retrospective Esta uma reunio formal, fechada (geralmente 3 horas). Participam dela somente Time, Scrum Master e Product Owner, sendo a presena deste ltimo opcional. Todos os membros do time devem responder trs perguntas: O que foi bem? O que pode melhorar? Quem tem controle do que pode melhorar? (Time/organizao) Neste ponto, preciso tomar cuidado. A funo da retrospectiva no apontar culpado. Deve ser definida somente a responsabilidade da implementao da melhoria: do time, ou da organizao. Aps isso, as oportunidades de melhoria detectadas devem ser priorizadas.
PUC-Rio - Certificao Digital N 0912827/CA

A partir dessas perguntas, e da priorizao, sero inferidas as seguintes sadas: Team Backlog, o que o Time pode mudar no processo de forma a melhorlo. Impedimentos abertos que no esto no controle do time, devem ser trabalhadas pelo Scrum Master. Ambos ordenados por prioridade. O Scrum Master no est nesta reunio para prover respostas, mas para facilitar a busca do time por melhores maneiras de fazer com que o processo do Scrum trabalhe para o Time. Itens viveis podem ser adicionados prximo Sprint, como Product Backlog no-funcional de alta prioridade. 2.4.7. Artefatos do Scrum No Scrum, existem somente 3 artefatos requeridos: Product Backlog Sprint Backog Burnup/Burndown Charts

29

2.4.7.1. Product Backlog O Product Backlog uma lista de todas as funcionalidades desejadas no produto, estimadas pelo time e priorizadas pelo Product Owner. Quando um projeto iniciado, no possvel escrever todos e quaisquer requisitos que porventura um dia sero incorporados ao sistema. Tipicamente, escrevem-se primeiro os requisitos que so mais bvios, o que normalmente mais do que suficiente para o primeiro Sprint. O Product Backlog ento deve crescer e mudar medida em que se aprende mais sobre o produto, seus clientes e o negcio, ou seja, emergente. Os itens de maior prioridade so geralmente mais detalhados, e o mesmo mantido de uma forma visvel para todo o time e o Scrum Master. Geralmente, qualquer pessoa pode contribuir com o Product Backlog, mas as solicitaes devem ser sempre priorizadas pelo Product Owner.
PUC-Rio - Certificao Digital N 0912827/CA

Exemplo de um Product Backlog, j estimado, priorizado e com valor de negcio definido: # Prioridade Descrio
1 Muito Alta Como gestor, quero controle de acesso por login e senha para acessar o sistema, para controlar o acesso Como usurio, quero poder cadastrar fornecedores no sistema, para poder encontrar facilmente seus contatos Como usurio quero poder cadastrar notas fiscais no sistema, associando-as ao fornecedor, para poder manter registro das notas Como operador, desejo tirar backup dos dados do sistema a qualquer momento, para poder garantir a segurana dos dados Como vendedor, desejo poder registrar as vendas que fao sobre meu login, para poder administrar minha comisso.

Estimativa Valor de negcio

13 100

Muito Alta

80

Alta

90

Baixa

30

Mdia

60

Tabela 1 Exemplo de Product Backlog.

30

2.4.7.2. Sprint Backlog O Sprint Backlog a lista de histrias que o time se comprometeu com o Product Owner a implementar durante o Sprint, aps a reunio de Sprint Planning I e II. Dependendo do tamanho de uma histria em particular, ela pode ser quebrada em duas ou mais histrias menores para facilitar a entrega em etapas. O Sprint Backlog escolhido pelo time dado o objetivo e prioridades descritos pelo Product Owner. Cabe somente ao time decidir quais histrias implementar durante o Sprint. Como o time que se compromete com o objetivo do Sprint ele que decide quais histrias devero ser feitas para cumprir esse objetivo. O Sprint Backlog pode ser mantido da maneira como for mais conveniente para a organizao: pode ser numa planilha de Excel, ou num sistema de controle de tarefas, ou at somente no quadro do time. 2.4.7.3. Burndown/Burnup Charts Os grficos de Burndown ou Burnup so as melhores ferramentas do time para manter registro da velocidade atual do trabalho. Esses grficos geralmente ficam no quadro do time, ou perto dele, e podem ser mantidos manualmente ou via Excel. Existem vrias formas de se representar um grfico de burndown ou burnup, a nica diferena em ambos que, no grfico de burndown, a linha representa o quanto de trabalho ainda falta para concluir o Sprint, e no grfico de burnup a linha representa quanto de trabalho j foi feito no Sprint, considerando que o montante de trabalho contabilizado pelo fator de complexidade adicionado a cada histria durante as estimativas (mais detalhadas a diante). Os grficos so ferramentas fundamentais para o time se auto-gerenciar, pois permitem de uma certa forma prever o sucesso de um Sprint. O grfico do Sprint deve ser mantido pela prpria equipe, e atualizado diariamente. Exemplo de grfico de Sprint Burnup:

PUC-Rio - Certificao Digital N 0912827/CA

31

Figura 2 Exemplo de Sprint BurnUp

PUC-Rio - Certificao Digital N 0912827/CA

Figura 3 Exemplo de Sprint BurnDown

Alm dos grficos do Sprint, a equipe tambm pode decidir monitorar sua velocidade entre Sprints, utilizando-se de um grfico de Product Burndown ou Burnup. Neste caso, a diferena entre Burndown e Burnup a mesma, a nica diferena que neste caso, ser monitorado o tamanho do trabalho que a equipe consegue entregar a cada Sprint. Este grfico tambm d visibilidade ao Product Owner e os Stakeholders que esto patrocinando o projeto sobre a velocidade do time por Sprint.

32

Figura 4 Exemplo de Product Burndown

PUC-Rio - Certificao Digital N 0912827/CA

2.4.8. Estimativas Planning Poker Antes de comear a falar sobre estimativas, gostaria de chamar a ateno para o significado da palavra Estimativa. O que uma estimativa? 1. 2. 3. Um clculo aproximado Uma declarao por escrito do preo aproximado que ser cobrado Um julgamento ou avaliao

para um trabalho especfico. Fonte: Oxford Dictionary Mais importante, estimativas so inerentemente erradas. Estimativas no so exatas, e no refletem a realidade. A nica maneira de saber o tempo exato que uma atividade vai durar, ou quanto esforo ser necessrio despender para executar algum trabalho, aps a sua realizao. Dito isso, vamos prosseguir a respeito do Planning Poker. Uma das maneiras mais eficientes e recomendadas de estimar o tamanho de requisitos em times que adotam mtodos geis (XP/Scrum) o jogo de cartas

33

conhecido como Planning Poker [Cohn, 2005]. Este mtodo de estimar combina opinio de especialistas, analogias e desagregao em uma aproximao eficiente para estimar de maneira rpida, porm confivel. uma variao do mtodo de estimativa Wideband Delphi (1940). As estimativas acontecem normalmente em uma reunio (geralmente 4 ou 8 horas, dependendo da quantidade de requisitos a ser estimada). Os participantes do jogo de poker so todos os membros do time do Scrum. O Product Owner normalmente comparece a esta reunio para prestar esclarecimentos a respeito dos requisitos, porm no pode opinar e estimar junto com o time. O Scrum Master registra os resultados da reunio, e assim como o Product Owner, no interefe nas estimativas do time. No incio de uma reunio de Planning Poker, cada membro do time recebe um deck de cartas, que contm uma variao da sequencia de Fibonacci, e uma ltima carta que representa a no possibilidade de estimativa: 0, , 1, 2, 3, 5, 8,
PUC-Rio - Certificao Digital N 0912827/CA

13, 20, 40, 50, 75, 90, 100, ?. Ainda no incio, todos os itens a serem estimados so lidos pelo Product Owner ou Scrum Master, e a equipe conversa para decidir qual o menor item de Backlog disponvel. Aps essa estimativa inicial, esse item marcado como 2 pontos, e a equipe prossegue para estimar os demais itens de Backlog. Isso serve para definir uma referncia de tamanho e complexidade para ser utilizada nas demais estimativas. Isso s precisa ser definido na primeira reunio de Estimativa, e deve ficar registrado, para uso nas futuras reunies. Em casos excepcionais, o time pode decidir mudar a histria de referncia por uma outra histria. Aqui tambm importante usar o bom-senso. Seguindo adiante, para cada histria a ser estimada, o Scrum Master ou Product Owner l a descrio e os critrios de aceitao da mesma. O Product Owner responde a quaisquer questionamentos que o time possua a respeito da histria, entretanto procurando manter o nvel da discusso em alto nvel, e no entrar em detalhes. comum definir tambm um timebox para esse tempo de perguntas e respostas, de modo a no se estender demais e perder muito tempo em uma nica histria. Depois da apresentao e discusso inicial, cada pessoa seleciona sua estimativa (uma carta), baseada em sua opinio pessoal a respeito do tamanho e complexidade da histria, e a coloca em cima da mesa, com a face voltada para

34

baixo. Quando todos os participantes selecionarem uma carta, as mesmas sero viradas ao mesmo tempo. Se houver uma grande varincia entre a maior e menor carta, o time vai discutir o que cada membro estava pensando quando selecionou o tamanho. A ideia que todos entendam as razes, que mais uma ou outra pergunta sejam respondidas pelo Product Owner, e a equipe volta a pensar sobre a histria, e faz uma nova estimativa. O ciclo deve ser repetido at que todas as estimativas estejam prximas, ou que a equipe chegue a um consenso. comum definir um limite de rodadas de poker, para evitar que as coisas fiquem muito arrastadas. Repetir at que todas as histrias estejam 100% estimadas! 2.4.9. Escrevendo Histrias Uma histria de usurio, ou user story, um requisito de sistemas de
PUC-Rio - Certificao Digital N 0912827/CA

software formulado com uma ou duas sentenas em linguagem natural. Cada user story limitada e pequena, de forma a caber perfeitamente em um pequeno papel de post-it. Isso feito para de forma a garantir que histrias muito grandes sejam sempre quebradas e granularizadas. User stories so uma maneira rpida de lidar com requisitos do cliente, sem ter que elaborar documentos de requisito formais e vastos, e sem executar tarefas administrativas super-dimensionadas para mant-lo. A inteno com a histria ser capaz de responder mais rpido e com menos overhead as mudanas nos requisitos volteis do mundo real. Uma histria uma declarao informal do requisito, que em segue normalmente o seguinte formato: Como um <papel do usurio/ator> quero <funcionalidade> para <valor de negcio> Na parte de trs da histria, normalmente so escritos os critrios de aceitao. Critrios de aceitao funcionam como um balizador de entendimento do que pronto entre o desenvolvedor e o cliente, para aquele requisito especfico. importante frisar que histrias no so requisitos do IEEE nem Casos de Uso (use cases). Exemplo de uma histria:

35

Como Gestor, quero que as informaes pessoais dos clientes fiquem gravadas em formato criptografado no banco de dados, para garantir a privacidade e a segurana dos dados dos meus clientes Critrios de aceitao: - Ter os dados armazenados no banco de dados e arquivos de troca do sistema usando algoritmo de criptografia do tipo chave publica/chave privada. 2.4.10. Scrum of Scrums Scrum of Scrums uma importante tcnica para escalar Scrum em grande times e projetos. Essas reunies permitem agrupar os times para discutir seus trabalhos, focando especialmente em rea de sobreposio e integrao. [Cohn, 2005] Essa reunio tem por objetivo alinhar informaes tcnicas entre os times de um mesmo projeto, bem como discutir eventuais problemas ou decises tcnicas. Imagine um projeto contendo sete times, cada um com sete membros, cada time ir conduzir seu prprio Daily Meeting. Cada time elege uma pessoa para fazer parte da reunio do Scrum of Scrums, essa dever ser uma deciso do prprio time, por reconhecerem um membro capaz de dar posio tcnica das decises do time e opinar nas decises dos demais. No aconselhvel que o Scrum Master ou Product Owner sejam os eleitos a participarem dessa reunio, exatamente pelo fato das decises tcnicas deverem ser tomadas pelo Time. Uma vez que o representante foi escolhido, ele dever ter uma sequncia de participaes, mas no est preso a essa reunio, eventualmente outro membro do time poder acompanh-la. Caso o time j saiba que existe uma determinada necessidade especfica de conhecimento dos outros times, como arquitetura ou banco de dados, poder previamente solicitar a presena de membros dos outros times que tenham o conhecimento especfico do problema para facilitar a soluo e o alinhamento entre os Times. O Scrum of Scrums pode ser feito tambm de forma recursiva, principalmente quando existem muitos times envolvidos no projeto. Sendo

PUC-Rio - Certificao Digital N 0912827/CA

36

possvel dividir em diversos grupos por temas, componentes ou funcionalidades. A reunio inicial ocorre somente dentro dos temas e na sequncia cada representante do tema se rene em um novo Scrum of Scrums. Caso o nmero de participantes na reunio seja pequeno, tanto por poucos times envolvidos no projeto, ou por uma recurso do Scrum of Scrums, poder ser enviado mais de um representante por time, dessa forma possvel enriquecer mais a reunio. Essa uma medida que dever ser tomada caso a caso, porque muitas pessoas participando dessa reunio poder tambm fazer com que deixe de ser efetiva. Outra reunio similar ao Scrum of Scrums tambm muito importante o agrupamento frequente por especialidade, a fim de manter um nivelamento de conhecimento, melhores praticas e padres. Dessa forma podemos manter a
PUC-Rio - Certificao Digital N 0912827/CA

arquitetura, design, componentes client-side, banco de dados mais alinhados entre times. Isso no somente interessante do ponto de vista de unicidade no projeto como tambm facilita a transio de membros entre times, por manter o mesmo contexto base. A frequncia dessa reunio dever ser determinada pelo time, mas importante lembrar que quanto maior a distncia entre reunies fatalmente aumentar seu tamanho, e eventualmente algumas informaes podem ser perdidas. Principalmente no incio do projeto, recomenda-se que o Scrum of Scrums seja executado diariamente, ao fim de todos os Daily Meetings. [Schwaber, 2007] importante que os times foquem na colaborao entre si durante o Scrum of Scrums, e no alinhamento das expectativas de integrao entre componentes correlacionados. Se fizermos um paralelo do Scrum of Scrums com o Daily Metting [Cohn, 2005], as perguntas dirias devero ter uma leve mudana, alm do acrscimo de uma muito importante para essa reunio:

37

O que o seu time fez desde a ltima reunio? O que o seu time ir fazer depois desta reunio? Algo est diminuindo a velocidade o interrompendo o trabalho do seu time? Seu time est a ponto de fazer (ou deixando de fazer) algo que de alguma forma ir impactar outros times? A ltima pergunta pode ser extremamente til no que diz respeito a coordenao de mltiplos times em um projeto, e da expectativa entre times. Eventualmente um time no tem plena viso da profundidade do impacto que poder causar em outro time por uma deciso tcnica, que em algumas situaes poderia tomar outra soluo.
PUC-Rio - Certificao Digital N 0912827/CA

A idia das perguntas, como no Daily Meeting apenas para dar um ritmo rpido e efetivo a reunio. Questes mais profundas devero ser endereadas aps todos passarem por esse pequeno processo. Dessa forma pode ser otimizado o tempo daqueles que eventualmente no sero impactados por um determinado problema. importante no segundo momento, aonde as discusses tomam profundidades, levantar aes prticas e seus responsveis para que esses problemas possam ser resolvidos ou que os levantamentos necessrios possam ser feitos at o prximo encontro.

2.5. Kanban Em 2004, David Anderson adaptou o modelo Toyota de controle enxuto de produo utilizando como base a "teoria das restries", que de maneira bem simplificada diz que se for possvel identificar um gargalo em seu processo, dever-se-ia focar toda a ateno para aliviar esse gargalo [Anderson, 2003]. Dessa forma, Kanban se utiliza de filas de estgios (ou etapas) de processo com limites determinados e o acompanhamento da evoluo de cada item em cada uma desses estgios, com o intuito de expor gargalos nesse fluxo para que imediatamente sejam trabalhados.

38

Existem 5 propriedades no Kanban [Anderson, 2010]. 2.5.1. Visualizao do Fluxo Visualizar o fluxo de trabalho e faz-lo visvel constantemente fundamental para o entendimento de como funciona o trabalho e seu fluxo. Tornase mais difcil fazer mudanas sem o entendimento correto desse fluxo. Uma maneira comum de visualizar o fluxo utilizando cartes e um quadro com colunas. As colunas no quadro representam os diferentes estgios deste fluxo e os cartes brancos as funcionalidades ou histrias. Ainda na representao abaixo possvel observar figuras que representam o desenvolvedor responsvel pela histria em questo. Os marcadores em amarelo representam tarefas detalhadas das histrias. Podem ser adicionadas outras representaes visuais nas histrias
PUC-Rio - Certificao Digital N 0912827/CA

dependendo do seu cenrio, como uma estrela para identificar uma histria urgente, ou uma marcao vermelha para indicar um impedimento.

Figura 5 Exemplo de um quadro Kanban [Kniberg, 2009]

2.5.2. Limite de trabalho em andamento O nmero em vermelho, abaixo da descrio de cada etapa no exemplo de quadro acima, mostra a quantidade de cartes mxima para cada etapa de desenvolvimento. Uma vez observado que uma etapa no pode receber novos

39

cartes, dever ser observado o que est evitando o andamento correto do fluxo, para que seja trabalhado pelos membros do time. 2.5.3. Administrao do Fluxo O Fluxo de trabalho por cada estgio deve ser monitorado, medido e exposto. Ao medir o tempo de um carto a cada estgio, poder ser notado de forma clara o impacto (negativo ou positivo) de eventuais mudanas no processo. Uma forma comum de monitorar esses tempos anotar no verso dos cartes a data que a histria foi criada, passou por cada estgio e finalmente foi concluda. 2.5.4. Processo e polticas explicitas Todo o sistema de trabalho explicito no quadro. Os estgios de desenvolvimento, a definio de pronto, quem est fazendo qual atividade e
PUC-Rio - Certificao Digital N 0912827/CA

principalmente os limites de trabalho em andamento de cada estgio. 2.5.5. Melhoria colaborativa Kanban encoraja pequenas mudanas de forma incremental e contnua. O time, tendo uma viso compartilhada de seu trabalho, riscos, fluxo e processo, deve sugerir mudanas assim que perceber uma oportunidade de melhoria. Essas mudanas devem ser feitas em consenso, aonde todo o time participa da deciso.