FREE ONLINE EDITION (non-printable free online version, Notas de estudo de Informática

Baixe FREE ONLINE EDITION (non-printable free online version e outras Notas de estudo em PDF para Informática, somente na Docsity!

FREE ONLINE EDITION

(non-printable free online version)

Trazido para você como

Cortesia de

Este livro é distribuído gratuitamente no portal

InfoQ.com. Se você recebeu este livro de

qualquer outra fonte, por favor, suporte o autor e

o editor cadastrando-se em InfoQ.com.

Visite a página deste livro em:

http://infoq.com/br/minibooks/scrum-xp-from-

the-trenches

© 2007 C4Media Inc All rights reserved.

C4Media, Publisher of InfoQ.com.

Este livro é parte da série InfoQ de livros sobre Desenvolvimento de Software Corporativo.

Para informações sobre compra desse ou outros livros InfoQ, entre em contato com books@c4media.com.

Nenhuma parte dessa publicação pode ser reproduzida, gravada em um sistema de busca e recuperação de dados ou transmitida sob qualquer forma ou por quaisquer meios, eletrônicos, mecânicos, fotocopiado, gravado, escaneado ou qualquer outro, sem prévia permissão do Publicador, exceto se autorizado pelas Seções 107 ou 108 da Lei de Copyright dos Estados Unidos de

Designações usadas por companhias para distinguir seus produtos são frequentemente conhecidas como marcas registradas. Em todos os locais onde a C4Media Inc. tem conhecimento desse fato, os nomes dos produtos aparecem com a letra inicial Maiúscula ou TODAS AS LETRAS MAIÚSCULAS. Os leitores, entretanto, devem contactar as respectivas empresas para informações mais completas sobre suas marcas registradas.

Editor: Diana Plesa / Felipe Rodrigues

Tradutores: Vários voluntários gerenciados pela SEA Tecnologia

Dados de Publicação-em-Catálogo da Biblioteca do Congresso Norte-Americano:

ISBN: 978-1-4303-2264-

Dedicatória

O primeiro rascunho desse livro demorou apenas um final de semana para ser digitado, mas com certeza foi um final de semana intenso! Fator de foco de 150% :o)

Obrigado à minha esposa Sophia e aos meus filhos Dave e Jenny por agüentar minha falta de sociabilidade naquele fim de semana. E obrigado também aos pais de Sophia, Eva e Jörgen por virem ajudar a tomar conta da família.

Obrigado também aos meus colegas da Crisp, em Estocolmo, e às pessoas do grupo de discussão do yahoo scrumdevelopment por revisarem e me ajudarem a melhorar este trabalho.

E, finalmente, obrigado a todos os leitores que forneceram um canal constante de feedback bastante útil. Eu estou particularmente satisfeito por ouvir que esse trabalho tem impactado tantos de vocês a ponto de darem uma chance ao desenvolvimento ágil de software.

Prefácio por Jeff Sutherland

As equipes precisam conhecer o básico do Scrum. Como você cria e estima um product backlog? Como você o transforma num sprint backlog? Como você gerencia um gráfico burndown e calcula a velocidade de sua equipe? O livro do Henrik é um kit para iniciantes com práticas básicas que ajudam equipes a irem além de apenas tentativas de praticar o Scrum para executá-lo bem.

Uma boa execução do Scrum está se tornando mais importante para as equipes que buscam investimento de fundos externos. Como um mentor Ágil para um grupo de capital de risco, eu os ajudo a investirem em empresas que executam as práticas Ágeis com eficiência. O Parceiro Sênior do grupo tem perguntado a todas as empresas do portfólio se elas conhecem a velocidade de suas equipes. Elas têm dificuldade em responder a essa questão de imediato. Oportunidades futuras de investimento irão exigir que as equipes de desenvolvimento saibam sua velocidade de produção.

Por que isso é tão importante? Se as equipes não conhecem sua própria velocidade, o product owner não pode criar um guia de produto com datas de releases com credibilidade. E sem datas de release interdependentes, a empresa poderá falhar e os investidores poderão perder seu dinheiro!

Esse problema é enfrentado por companhias grandes e pequenas, novas ou antigas, com investimento próprio ou externo. Numa discussão recente sobre a implantação do Scrum no Google, numa conferência em Londres, eu perguntei às 135 pessoas presentes quantos deles estavam praticando Scrum , e 30 responderam positivamente. Então eu perguntei se eles estavam fazendo o desenvolvimento iterativo usando os padrões da Nokia. Desenvolvimento iterativo é fundamental no Manifesto Ágil – entregue software funcionando cedo e com freqüência. Depois de anos de retrospectivas com centenas de equipes de Scrum , a Nokia desenvolveu alguns requisitos básicos para o desenvolvimento iterativo:

• As iterações devem ter um tempo fixo com menos de seis semanas de duração.
• Ao final da iteração, o código deve ser testado pelo CQ e funcionar corretamente.

Das 30 pessoas que responderam estar usando o Scrum , apenas metade disse que estava atendendo o primeiro princípio do Manifesto Ágil pelos padrões da Nokia. Então eu perguntei se eles atendiam aos padrões da Nokia para o Scrum :

Prefácio por Mike Cohn

Ambos Scrum e Extreme Programming (XP) pregam que a equipe complete alguma parte palpável de trabalho que seja entregável ao fim de cada iteração. Essas iterações são pensadas para serem curtas e com espaço de tempo definido. Este foco em entregas de código funcionando em um curto espaço de tempo significa que equipes Scrum e XP não têm tempo para teorias. Eles não perseguem o desenho do diagrama UML perfeito em ferramentas case, a escrita do documento de requsitos perfeito, ou a escrita do código que poderá acomodar todas as mudanças futuras imagináveis. Ao invés disso, equipes Scrum e XP focam em ter as coisas prontas. Essas equipes aceitam que cometem erros ao longo do caminho, mas também compreendem que o melhor modo de identificar esses erros é parar de pensar sobre o software em um nível teórico de análise e design e mergulhar fundo, sujar as mãos e começar a construir o produto.

É esse mesmo foco em fazer ao invés de teorizar que distingue esse livro. E aparentemente Henrik Kniberg entende isso direito, desde o princípio. Ele não oferece uma longa descrição sobre o que é Scrum ; ele nos remete a alguns sites simples para isso. Ao invés disso, Henrik dá um salto e começa imediatamente descrevendo como suas equipes gerenciam e trabalham com seu product backlog. Daí, ele parte para todos os outros elementos e práticas de um projeto ágil bem executado. Sem teorias, sem referências. Sem notas de rodapé. Nada disso é necessário. O livro de Henrik não é uma explanação filosófica sobre por que Scrum funciona ou por que você poderia querer experimentá-lo. É uma descrição de como uma boa equipe ágil funciona.

Eis o porquê do subtítulo do livro, “Como fazemos Scrum”, ser tão apropriado. Pode não ser o modo como você faz Scrum , mas é o modo como as equipes do Henrik fazem Scrum. Você pode perguntar por que deveria se importar com a forma como outra equipe faz Scrum. Você deveria se importar porque todos podemos aprender como fazer melhor Scrum ouvindo histórias de como foi feito por outros, especialmente aqueles que estão fazendo direito. Não existe, e nunca existirá uma lista de “melhores práticas em Scrum ”, porque o contexto dos projetos e equipes descarta todas as outras considerações. Ao invés de melhores práticas, o que precisamos conhecer são boas práticas e o contexto onde foram bem sucedidas. Leia histórias suficientes de equipes bem sucedidas e como elas fizeram as coisas e você estará preparado para os obstáculos que se apresentarem a você e ao seu uso de Scrum e XP.

iv | SCRUM E XP DIRETO DAS TRINCHEIRAS

Henrik provê as boas práticas e o contexto necessário para nos ajudar a aprender melhor como fazer Scrum e XP, nas trincheiras dos seus projetos.

Mike Cohn Autor de Agile Estimating and Planning e User Stories Applied for Agile Software Development.

Introdução

Você está para começar a utilizar Scrum em sua empresa. Ou talvez você esteja usando Scrum há alguns meses. Conhece os princípios, leu alguns livros, ou talvez até já tenha feito a certificação de scrum master. Parabéns!

Mas ainda se sente confuso.

Como disse Ken Schwaber, Scrum não é uma metodologia, é um framework. O que significa que Scrum não vai te dizer exatamente o que fazer.

A boa notícia é que vou te dizer exatamente como faço Scrum , em um nível de detalhes excruciantemente doloroso. A má noticia é, bem, esta é a maneira como EU faço Scrum. E isto não significa que Você deva fazê-lo exatamente da mesma maneira. De fato, eu também faria de maneira diferente, se encontrasse situações diferentes.

O melhor e o pior do Scrum é que você é forçado a adaptar o processo para sua situação especifica.

Minha abordagem atual para o Scrum é o resultado de um ano de experiências numa equipe de desenvolvimento de aproximadamente 40 pessoas. A empresa estava em uma situação difícil com tarefas levando mais tempo que o previsto, problemas de qualidade severos, constantes incêndios, deadlines estourados, etc. A empresa decidiu utilizar Scrum mas não completou a implantação, o que foi como minha tarefa. Para a maioria das pessoas na equipe de desenvolvimento naquela época, Scrum era uma buzzword que escutavam de vez em quando nos corredores, mas que não tinha nenhuma implicação para o trabalho diário.

Após um ano, implementamos Scrum em todas as camadas da empresa, tentamos diferentes tamanhos de equipes (3-12 pessoas), diferentes tamanhos de sprint (2-6 semanas), diferentes formas de definir “pronto”, diferentes formatos para os product backlog e de sprint backlogs (Excel, Jira, cartões), diferentes estratégias de testes, diferentes formas de realizar

apresentações de sprint , diferentes formas de sincronização de múltiplas equipes Scrum , etc. Também fizemos experimentos com práticas de XP – diferentes formas de realizar a build contínua, programação em pares, desenvolvimento orientado a testes, etc, e como combiná-los com Scrum.

Este é um processo de aprendizado contínuo, de modo que a estória não termina aqui. Estou convencido que esta empresa continuará aprendendo (se continuarem a realizar as retrospectivas dos sprints ) e terem novos insights sobre como melhor implementar Scrum em seus contextos particulares.

Termo de Responsabilidade

Este documento não assume representar a “forma correta” de usar Scrum! Ele apenas representa uma forma de usar Scrum , o resultado da melhoria contínua ao longo de um ano. Você pode até mesmo decidir que nós entendemos tudo errado.

Tudo o que há neste documento reflete minhas próprias opiniões pessoais e subjetivas e não é de forma alguma uma declaração oficial da Crisp ou do meu cliente atual. Por esta razão eu intencionalmente evitei mencionar quaisquer produtos ou pessoas específicas.

Porque eu escrevi isso

Quando estava aprendendo Scrum , li os livros relevantes sobre Scrum e agile, acessei muitos sites e fóruns sobre Scrum , fiz a certificação do Ken Schwaber, perturbei-o com perguntas e passei muito tempo conversando com meus colegas. Uma das mais valiosas fontes de informação, entretanto, foram as histórias de guerra. As histórias de guerra transformam princípios e práticas em... bem... Como você realmente faz isso. Elas também me ajudaram a identificar (e algumas vezes evitar) erros comuns de iniciantes em Scrum.

Logo, essa é minha chance de devolver algo. Aqui está minha história de guerra.

Eu espero que este documento provoque algum retorno útil daqueles que estejam na mesma situação. Por favor, me iluminem!

Mas o que é Scrum?

Oh, me desculpe. Você é completamente novo no Scrum ou XP? Neste caso talvez você queira dar uma olhada nos seguintes links:

Como fazemos product backlogs

O product backlog é o coração do Scrum. É aqui que tudo começa. O product backlog é basicamente uma lista de requisitos, estórias, Coisas que o cliente deseja, descritas utilizando a terminologia do cliente.

Nós as chamamos de estórias , ou algumas vezes apenas de itens do backlog.

Nossas estórias incluem os seguintes campos:
ID – Uma identificação única, apenas um número com auto- incremento. Isso é para evitar que percamos o controle sobre as estórias quando nós mudamos seus nomes.
Nome – Um nome curto e descritivo para a estória. Por exemplo, “Ver o histórico de transações”. Suficientemente claro para que os desenvolvedores e o product owner entendam mais ou menos sobre o que estamos falando, e claro o bastante para distingui-la das demais estórias. Normalmente de 2 a 10 palavras.
Importância – a pontuação de importância dessa estória para o product owner. Por exemplo 10. Ou 150. Mais pontos = mais importante. o Eu tento evitar o termo “prioridade” já que prioridade 1 é tipicamente interpretado como “prioridade mais alta”, o que fica feio se mais tarde você decidir que algo é ainda mais importante. Qual pontuação de prioridade esse item deveria receber? Prioridade 0? Prioridade -1?
Estimativa inicial – As estimativas iniciais da equipe sobre quanto tempo é necessário para implementar aquela estória, se comparada a outras estórias. A unidade é pontos por estória e geralmente corresponde mais ou menos a “relação homem/dias” ideal.

1. Pergunte à equipe “se vocês puderem ter o número ideal de pessoas para esta estória (nem muitas, nem poucas, normalmnte duas), e se trancarem em uma sala cheia de comida e trabalharem sem distúrbio

10 | SCRUM E XP DIRETO DAS TRINCHEIRAS

algum, após quantos dias vocês apresentarão uma implementação pronta, demonstrável e testada? Se a resposta for “com 3 pessoas trancados em uma sala levará aproximadamente 4 dias” então a estimativa inicial é de 12 pontos por estória.

2. O importante não é ter estimativas absolutamente precisas (por exemplo, dizer que uma estória com 2 pontos deverá gastar 2 dias), mas sim obter estimativas relativas corretas (por exemplo, dizer que uma estória com 2 pontos gastará cerca da metade de uma estória com 4 pontos). Como demonstrar – Uma descrição em alto nível de como a estória será demonstrada na apresentação do sprint. Isso é simplesmente uma simples especificação de teste. “Faça isso, então faça aquilo e então isso deverá acontecer.” o Se você pratica TDD (desenvolvimento orientado a testes) essa descrição pode ser usada como pseudo- código para o seu código de teste de aceitação.
   Notas – quaisquer outras informações, esclarecimentos, referências a outras fontes de informação, etc. Normalmente ágil bem breve.

PRODUCT BACKLOG (exemplo) ID Nome Imp Est Como demonstrar Notas 1 Depósito 30 5 Logar-se, abrir a página de depósito, depositar R$ 10,00, ir para a página do meu saldo e verificar que este aumentou em R$ 10,00.

Precisa de uma diagrama UML de sequência. Não é necessário se preocupar com criptografia por enquanto. 2 Verificar seu próprio histórico de transações

10 8 Logar-se, clicar em “transações”. Fazer um depósito. Voltar para transações, verificar se o novo depósito é listado.

Usar paginação para evitar consultas muito grandes ao banco de dados. Projetar de forma similar à página de visualização de usuários.