Scrum

Scrum Guia Prรกtico

Joรฃo Paulo Pinto Christiane Tscharf

www.fca.pt

Distribuição Edição

FCA – Editora de Informática, Lda. Av. Praia da Vitória, 14 A – 1000-247 Lisboa Tel: +351 213 511 448 fca@fca.pt Lidel – edições técnicas, lda www.fca.pt SEDE: R. D. Estefânia, 183, R/C Dto., 1049-057 LISBOA Distribuição Internet: 21 354 14 18 – livrarialx@lidel.pt / Revenda: 21 351 14 43 – revenda@lidel.pt 21 351 14 48 – formacao@lidel.pt / marketing@lidel.pt LidelFormação/Marketing: – Edições Técnicas, Lda. Línguas/Exportação: 21–351 14 42 – depinternacional@lidel.pt Rua Ens. D. Estefânia, 183, R/C Dto. 1049-057 Lisboa Fax: 21 357511 78 448 27 – 21 352 26 84 Tel: +351 213

lidel@lidel.pt

www.lidel.pt LIVRARIAS: LISBOA: Av. Praia da Vitória, 14 – 1000-247 LISBOA – Tel.: 21 354 14 18, e-mail: livrarialx@lidel.pt PORTO: R. Damião de Góis, 452 – 4050-224 PORTO – Tel.: 22 557 35 10, e-mail: delporto@lidel.pt Livraria Av. Praia da Vitória, 14 A – 1000-247 Lisboa Tel: +351 213 511 448 * Fax: +351 213 173 259 livraria@lidel.pt

Copyright ©© Fevereiro 2011– Editora de Informática, Lda. Copyright 2018, FCA

ISBN ediçãode impressa: 978-972-722-900-0 FCA – Editora Informática, Lda. 1.ª edição impressa: ISBN: 978-972-722-679-5

Capa: José M. Ferrão – Look-Ahead

Paginação: Carlos Mendes

Impressão e acabamento: Impressão e acabamento:Tipografia Rolo & Filhos, II – S.A.

Depósito Legal Depósito Legal N.ºn.º ………

Capa: José M. Ferrão – Look-Ahead

Marcas dede FCA – Editora de de Informática, Lda. Marcas Registadas Registadas FCA – Editora Informática, Lda. –

®

®

®

Este pictograma merece uma explicação. O seu propósito é alertar o leitor para a ameaça que

Todos os nossos livros passam um da rigoroso controlo de qualidade, no entanto aconselhamos a consulta o representa para opor futuro escrita, nomeadamente na área da edição técnica e universitária, desenvolvimento massivo dafazer fotocópia. periódica do nosso site (www.fca.pt) para o download de eventuais correções.

O Código do Direito de Autor estabelece que é crime punido por lei, a fotocópia sem autorização

dos proprietários do copyright. No entanto, esta prática generalizou-se sobretudo no ensino superior, Não nos responsabilizamos por desatualizações das hiperligações presentes nesta obra, que foram verificadas provocando uma queda substancial na compra de livros técnicos. Assim, num país em que a à data de publicação da técnica mesma.é tão escassa, os autores não sentem motivação para criar obras inéditas e fazêliteratura -las publicar, ficando os leitores impossibilitados de ter bibliografia em português.

Os nomes comerciais referenciados livro têm patente registada portanto,neste que é expressamente proibida a reprodução, no todo ou em parte, da Lembramos presente obra sem autorização da editora.

Reservados todos os direitos. Esta publicação não pode ser reproduzida, nem transmitida, no todo ou em parte, por qualquer processo eletrónico, mecânico, fotocópia, digitalização, gravação, sistema de armazenamento e disponibilização de informação, sítio Web, blogue ou outros, sem prévia autorização escrita da Editora, exceto o permitido pelo CDADC, em termos de cópia privada pela AGECOP – Associação para a Gestão da Cópia Privada, através do pagamento das respetivas taxas.

1Introdução à

Metodologia Ágil

1.1 Introdução à Metodologia Ágil Provavelmente, já terá ouvido falar em conceitos como “ser ágil no ambiente atual”, “utilizar uma abordagem ágil”, “metodologia ágil”, “equipas ágeis”, e assim por diante. Eventualmente, também pode já ter colaborado em projetos que foram geridos recorrendo a uma metodologia Ágil.

Mas, o que significa ser ágil?

Jim Highsmith, um dos mais populares gurus da metodologia Ágil, com diversos livros publicados sobre esta matéria e também sobre outros métodos de gestão de projetos, define o conceito de “Agilidade” da seguinte forma: “Agilidade é a capacidade de criar e responder à mudança, com vista a criar valor num ambiente de negócios turbulento. Agilidade é a capacidade de equilibrar flexibilidade e estabilidade.”

(Highsmith, 2002) De acordo com esta definição, ser Ágil é ser flexível, o que permite, por sua vez, ser adaptável à mudança. Este conceito está inicialmente associado ao desenvolvimento de software, no qual os requisitos e soluções evoluem através do esforço colaborativo de equipas auto-organizadas e multifuncionais e o cliente/utilizadores finais. O desenvolvimento ágil de software baseia-se no planeamento adaptativo, no desenvolvimento evolutivo, na entrega antecipada de valor e na melhoria contínua, e incentiva uma resposta rápida e flexível à mudança.

O termo ágil foi popularizado, neste contexto, pelo Manifesto Ágil (ver ponto 1.2). Os valores e princípios adotados neste manifesto foram amplamente —1—

Scrum

divulgados e sustentam uma ampla gama de estruturas de desenvolvimento de software, incluindo os métodos Scrum e Kanban.

A metodologia Ágil não é apenas aplicável na área do desenvolvimento de software, ainda que seja nesta área que se conhecem mais exemplos práticos de aplicação e na qual os métodos ágeis estão mais amplamente disseminados e profundamente enraizados. Os métodos ágeis podem ser utilizados em qualquer projeto, simples ou complexo, no desenvolvimento de produtos ou serviços. Highsmith recorre a analogias com o montanhismo para explicar estes conceitos-chave nos seus livros. Um alpinista inicia o seu percurso na base da montanha, mas, à medida que vai escalando e subindo, as condições, inicialmente previstas, mudam. A saliência que parecia escalável quando avistada a partir da base da montanha, é, na realidade, intransitável. A rota traçada inicialmente precisa de ser adaptada. Manter a rota inicial e tentar escalar a saliência, poderia ser mortal. Ser adaptável é fundamental no alpinismo, e, igualmente, em qualquer empresa ou organização.

1.1.1 A necessidade de métodos Ágeis Antes de aprofundar o conceito de Agilidade, é importante compreender o que originou a necessidade de métodos ágeis. O mercado de smartphones pode ser apresentado como um exemplo no qual os seguintes aspetos são relevantes, Figura 1.1.

Figura 1.1 – O porquê dos métodos Ágeis —2—

Introdução à Metodologia Ágil

Neste tipo de ambientes, em que a mudança é uma constante, os métodos tradicionais de gestão de projetos, mais preditivos, não funcionam, ou funcionando, não dão resposta efetiva às necessidades do projeto e da sua gestão.

Surge, assim, a necessidade de métodos que permitam responder rápida e eficazmente às mudanças constantes, com flexibilidade e adaptabilidade: os Métodos Ágeis. Os métodos Ágeis, ao invés de recusarem ou resistirem à mudança, aceitam-na e lidam com ela. Incorporam a gestão da mudança na gestão do projeto. Atualmente, esta abordagem capacita as organizações não apenas a trabalharem melhor no sentido de entregar Valor e Qualidade ao cliente – dando resposta efetiva aos seus pedidos e necessidades – mas também a trabalharem melhor com os seus clientes internos – departamentos, equipas e pessoas – possibilitando um ambiente de trabalho menos stressante e com maiores níveis de colaboração, cooperação e transparência.

1.1.2 Gestão adaptativa de Projetos A Metodologia Ágil não foi criada e desenvolvida num único dia. Pessoas de várias partes do mundo sentiram a necessidade de utilizar métodos adaptativos de gestão de projetos, à medida que iam constatando que os métodos tradicionais de Cascata (waterfall) não permitiam a flexibilidade necessária.

A origem da gestão adaptativa de projetos remonta à gestão ou administração científica de Frederick Taylor [1856-1915], do início dos anos 1900. A gestão adaptativa é um processo de tomada de decisão iterativo e particularmente útil em ambientes caracterizados por mudanças constantes e incerteza. Como recorre ao processo de feedback, reduz a incerteza e consegue incorporar a mudança ao longo do processo.

Os métodos Ágeis são um grupo de técnicas de desenvolvimento de produtos ou serviços, que recorrem a uma abordagem iterativa e incremental, e em que a entrega de soluções é feita de forma faseada. Os Métodos Ágeis dão ênfase ao planeamento adaptativo, de forma a desenvolver o produto ou serviço, em ciclos repetidos/iterativos, promovendo, assim, uma maior flexibilidade e incorporação da mudança no decorrer do desenvolvimento do projeto, ao mesmo tempo que se reduz o planeamento a longo-prazo.

O trabalho é completado através de ciclos curtos e repetidos, pelas equipas Ágeis. Os métodos Ágeis têm como princípio fundamental a comunicação cara-a-cara entre os membros da equipa, no caso de estes se encontrarem no mesmo local físico. No caso de as equipas se encontrarem geograficamente —3—

Scrum

separadas, recomenda-se a comunicação diária através de videoconferência ou outro meio tecnológico.

A Figura 1.2 mostra a cronologia do surgimento de vários métodos Ágeis:

Figura 1.2 – Cronologia dos métodos Ágeis

1.2 Manifesto Ágil De 11 a 13 de fevereiro de 2001, no Resort de Sky The Lodge at Snowbird, nas montanhas do Utah (EUA), um grupo constituído por dezassete pessoas, reuniu-se para esquiar, relaxar e tentar encontrar princípios e valores comuns aos vários métodos usados no desenvolvimento de software. Eram representantes que, na prática, usavam os vários métodos ágeis, movidos pela necessidade de encontrar uma alternativa aos métodos tradicionais, que colocam mais ênfase na documentação e planeamento a longo-prazo. O documento resultante desta reunião designou-se de “Manifesto Ágil”.

A aplicação de qualquer método ágil requer a compreensão clara dos quatro valores apresentados no Manifesto Ágil: “Estamos a descobrir maneiras melhores de desenvolver software, ao fazê-lo e ajudar outros a fazê-lo. Através deste trabalho, temos vindo a valorizar: Pessoas e interações, mais do que processos e ferramentas; Software a funcionar, mais do que documentação completa; Colaboração com o cliente, mais do que negociação contratual; Dar resposta à mudança, mais do que cumprir com o planeamento.

Ou seja, apesar de haver valor nos itens à direita, valorizamos mais os itens à esquerda.”

—4—

Introdução à Metodologia Ágil

De seguida é feita a explicação de cada um dos quatro valores.

1. Valorizar pessoas e interações, mais do que processos e ferramentas Embora os processos e ferramentas ajudem a completar com sucesso um projeto, são as pessoas que se encarregam, participam e implementam um projeto. Os elementos-chave em qualquer projeto são as pessoas, e a ênfase deve ser nelas e nas suas interações.

2. Valorizar software a funcionar1, mais do que documentação completa Ainda que a documentação seja necessária e útil para qualquer projeto, a equipa deve focalizar-se na entrega de valor real ao cliente, principalmente na forma de software a funcionar. Portanto, o foco é na entrega de software a funcionar, em incrementos ao longo do ciclo de vida do projeto.

3. Valorizar a colaboração com o cliente, mais do que a negociação contratual Tradicionalmente, os clientes eram vistos como elementos de fora que estão envolvidos apenas e sobretudo no início e no final do ciclo de vida de desenvolvimento do produto ou serviço, e cujas relações eram baseadas em contratos e no seu cumprimento. A metodologia Ágil preconiza uma abordagem de valores partilhados, em que o cliente é visto como colaborador. A equipa e o cliente trabalham juntos para desenvolver e melhorar o produto ou serviço.

4. Valorizar dar resposta à mudança, mais do que cumprir com o planeamento No mercado atual, em que os requisitos dos clientes, a tecnologia disponível, e os modelos de negócio estão em constante mudança, é fundamental uma abordagem flexível e adaptativa, que possibilite a incorporação de alterações, mantendo tempos de ciclo baixos, em vez de colocar a ênfase no cumprimento do planeamento, assente, a dada altura do projeto, em dados potencialmente desatualizados.

1.3 Princípios de Agilidade Os doze princípios de Agilidade são apresentados na figura seguinte.

Qualquer referência ao termo “software a funcionar” pode ser entendida como produto ou serviço na condição de ser apresentado ao cliente. Ou seja, algo que o cliente entende como “valor”.

1

—5—

Scrum

Figura 1.3 – Os 12 princípios do Manifesto Ágil

1.4 O Que Mudou na Gestão de Projetos?

Uma das diferenças entre métodos ágeis e a abordagem tradicional (Cascata ou waterfall) de gestão de projetos é a enfase na qualidade e no teste (validação). No modelo em Cascata, há sempre uma fase de teste separada da fase de construção. No entanto, no desenvolvimento ágil de software, o teste é concluído na mesma iteração da programação.

Como os testes são feitos em todas as iterações – que desenvolvem uma pequena parte do software – os utilizadores podem usar esses novos incrementos e validar o valor. Quando o utilizador conhecer o valor real do software, ele poderá tomar melhores decisões sobre o futuro do software. A possibilidade de ter uma retrospetiva do valor gerado e uma sessão de replaneamento de software em cada iteração melhoram a qualidade do mesmo. A título de exemplo, o método Scrum geralmente tem iterações (ciclos ou sprints) de apenas duas semanas o que ajuda a equipe de desenvolvimento a adaptar-se continuamente assim maximizar o valor que apresenta ao cliente. Isto segue um padrão semelhante ao ciclo PDCA (plan, do, act e check), já que o trabalho é planeado, feito, verificado (na revisão e retrospetiva), e quaisquer mudanças acordadas são acionadas.

Essa abordagem iterativa focaliza-se no produto e não no projeto. Isto proporciona maior flexibilidade em todo o processo de desenvolvimento; enquanto que nos projetos tradicionais os requisitos são definidos e bloqueados desde o —6—

Introdução à Metodologia Ágil

início, dificultando sua alteração mais tarde. O desenvolvimento iterativo permite que produtos ou serviços evoluam em resposta a mudanças no ambiente de negócios ou nos requisitos do mercado.

A Figura 1.4. que se segue apresenta as diferenças entre os métodos tradicionais de gestão de projetos e os métodos ágeis.

Figura 1.4 – Diferenças entre o método tradicional e o método ágil de gestão de projetos

As metodologias Ágeis exigem uma mudança de mentalidade face aos métodos tradicionais. Enquanto que os métodos Cascata (ou waterfall) se focam no âmbito do projeto e, em função do mesmo, determinam os custos e desenham o cronograma, os métodos ágeis focalizam na noção de “valor” para o cliente e é a partir dessa noção que definem o conceito de qualidade e os possíveis constrangimentos ou limitações do projeto.

Enquanto que o modelo Cascata é bem-sucedido em ambientes ordenados e/ou previsíveis, os métodos ágeis são mais adequados quando as mudanças são frequentes, uma vez que são considerados métodos “caórdicos” [caos + ordem]. O método Cascata utiliza estruturas de comando e controlo, enquanto que os métodos ágeis usam estruturas mais planas, de colaboração, com ciclos de inspeção-adaptação/ajuste e uma abordagem de valor partilhado.

Uma comparação entre os métodos tradicionais e os métodos ágeis é apresentada na tabela que se segue:

—7—

Scrum Tabela 1.1 – Comparação entre as diferentes abordagens à gestão de projetos

A figura seguinte mostra a diferença entre os métodos tradicionais e os métodos ágeis, representando um projeto Scrum.

Figura 1.5 – Diferença na abordagem tradicional vs. abordagem Scrum

Como ilustrado no diagrama acima, os projetos Scrum são concluídos de forma iterativa, em que as funcionalidades são entregues no final de cada iteração, designada de Sprint. De preferência, aquelas com o maior valor de negócio devem ser concluídas em primeiro lugar. Várias equipas multifuncionais trabalham em paralelo ao longo dos Sprints para produzir soluções potencialmente —8—

Introdução à Metodologia Ágil

utilizáveis no final de cada Sprint. O número de funcionalidades não concluídas – representado pela linha tracejada “em escada” descendente – diminui de forma constante ao longo do projeto Scrum. No método tradicional, o número de funcionalidades não concluídas continua a ser elevado até ao final (ou até muito perto do final) do projeto.

Uma vez que cada Sprint dá origem a uma funcionalidade concluída (que é uma parte do produto final total), existe um objetivo mensurável no qual a equipa se concentra e para o qual trabalha, e isso garante a progressão sistemática e também que o projeto será concluído dentro do prazo. Os métodos tradicionais não implicam estas verificações, no final de cada ciclo (o Sprint, no Scrum), portanto, podem acontecer situações em que o planeamento inicial não é cumprido e existe uma grande quantidade de trabalho/tarefas ainda por fazer ou concluir, já perto do final do prazo.

Como o cliente interage regularmente com a equipa Scrum, o trabalho realizado é acompanhado e revisto regularmente, garantindo vai ao encontro das especificações do cliente. Na gestão de projetos tradicional, não existe esta interação e as funcionalidades apenas são entregues no final do projeto.

Em projetos complexos, em que o cliente não tem uma certeza exata sobre como será o produto final e, portanto, em que a funcionalidade do produto final muda continuamente, os métodos ágeis são mais flexíveis, no sentido de garantir que estas mudanças podem ser incluídas durante o projeto. Os modelos tradicionais têm maior dificuldade em incorporar estas mudanças.

No entanto, no caso de projetos simples, com funcionalidades bem definidas, e quando a equipa tem experiência no tipo de projeto em questão e consegue, assim, fazer estimativas precisas, o método tradicional pode ser bem-sucedido.

1.4.1 Os métodos Ágeis Os métodos Ágeis desenvolveram-se ao longo do tempo, também devido à limitação dos métodos tradicionais de gestão de projetos em dar resposta às necessidades reais.

Os mais populares métodos Ágeis são os seguintes: Crystal – este é um dos métodos mais “leves” e adaptáveis usados no desenvolvimento de software. Na prática, Crystal é uma família de metodologias ágeis que envolve métodos como: Crystal Clear, Crystal Yellow, Crystal Orange entre outros. A família de metodologias Crystal foca na —9—

Scrum

eficiência, na comunicação osmótica entre os membros da equipa e na aprendizagem baseada no feedback contínuo, como base para a melhoria contínua.

Dynamic Systems Development – O DSD desenvolvido em 1994, apoia-se num quadro conceptual que dá ênfase ao envolvimento dinâmico do cliente no processo de desenvolvimento, dando suporte aos projetos com orçamentos e cronogramas mais rigorosos. DSDM é baseado em nove princípios chave que se orientam à resposta dos pedidos/necessidades do cliente, envolvimento dos elementos da equipa, equipas autónomas, entrega frequente de valor, testes frequentes e colaboração dos stakeholders do projeto. DSDM faz uso das regras MoSCoW: −− Must have requirements – requisitos que têm de estar presentes; −− Should have if at all possible – requisitos que devem estar presentes se todos forem possíveis; −− Could have but not critical – requisitos que podem estar presentes, mas não são críticos; −− Won ‘t have this time, but potentially later – requisitos que não têm de estar presentes agora, mas provavelmente mais tarde.

Extreme Programming (XP) – XP emergiu como uma das mais populares e controversas metodologias ágeis. É uma metodologia disciplinada, desenhada com foco na melhoria da qualidade do software e na capacidade de resposta à mudança de requisitos por parte do cliente. Promove uma estrutura de gestão horizontal. XP promove um elevado envolvimento do cliente, rápidos ciclos de feedback, teste contínuo, planeamento contínuo e um forte relacionamento da equipa de desenvolvimento para que seja possível entregas frequentes de software a funcionar (tipicamente entre uma a três semanas). A versão original da metodologia XP baseava-se em quatro valores: simplicidade, comunicação, feedback e coragem.

Kanban – (termo em Japonês que significa cartão) O (quadro) kanban coloca ênfase na entrega just-in-time no desenvolvimento de produtos e serviços. As tarefas são ordenadas de acordo com a prioridade desejada, por norma, com base na noção de “valor”, de forma a que as entregas sejam incrementais, isto é, que cada entrega agregue o máximo possível de valor, o mais cedo possível no projeto. Todo o processo é tornado transparente, sabendo-se exatamente quem está a fazer o quê e em que fase se encontra, permitindo ao cliente o acompanhamento do progresso.

Este método é usado para gerir a criação contínua de produtos, sem sobrecarregar a equipa de desenvolvimento. Como o Scrum, o Kanban é — 10 —

Introdução à Metodologia Ágil

um processo projetado para ajudar as equipas a trabalharem juntas de maneira mais eficaz. Este método é baseado em três princípios básicos: 1. Visualizar o que é feito hoje (fluxo de trabalho) – ver todos os itens no contexto global pode ser muito informativo; 2. Limitar a quantidade de trabalho em andamento (WIP, work in process) – garante o equilíbrio do fluxo de trabalho para que as equipas não comecem e se comprometam com muito trabalho de uma só vez; 3. Melhorar o fluxo – quando algo está terminado, a próxima maior (ou mais importante) coisa do backlog é iniciada.

O método Kanban promove a colaboração contínua e encoraja a melhoria e a aprendizagem definindo o melhor fluxo de trabalho para a equipa.

Feature Driven Development (FDD) – É um método com ciclos curtos que se repetem, com elevado foco na funcionalidade a desenvolver. Consiste em cinco passos básicos: desenvolver o modelo global, elaborar a lista de funcionalidades, planear por funcionalidade, desenhar por funcionalidade e desenvolver por funcionalidade; Adaptive Software Development – consiste numa série de repetições/ /ciclos de especulação, colaboração e aprendizagem. Promove a aprendizagem e a melhoria contínua e é facilmente adaptável em qualquer fase do projeto, podendo ser aplicado em qualquer momento, ao “estado atual”; Lean Product Development (LPD) – Tem por base os princípios Lean utilizados na indústria e no desenvolvimento das TI (tecnologias de informação), associados ao modelo do Toyota Production System (TPS), no domínio do desenvolvimento de software. Apresenta um quadro conceptual um pouco diferente dos restantes métodos Ágeis, uma vez que utiliza ferramentas da área industrial, como o Value Stream Mapping, Queuing Theory e outras técnicas do desenvolvimento de produtos.

Os princípios da LPD são os seguintes: −− Eliminar os desperdícios; −− Aprendizagem abrangente; −− Decidir o mais tarde possível; −− Entregar valor o mais rápido possível; −− Desenvolver e capacitar a equipa; −− Construir integridade; −− Ver o todo e não as partes (pensamento global).

— 11 —

Scrum

RESUMO

A metodologia LPD coloca enfase na velocidade e a eficiência do fluxo de desenvolvimento e conta com feedback rápido e fiável dos programadores e clientes. A abordagem lean usa a ideia de trabalho sendo “puxado” por solicitação do cliente. O método concentra a autoridade e a capacidade de decisão em indivíduos e equipas pequenas. LDP também se concentra na eficiência do uso dos recursos da equipa, tentando garantir que todos sejam produtivos o máximo de tempo possível. Concentra-se no trabalho simultâneo e no menor número possível de dependências de fluxo de trabalho dentro da equipa. Por último, LPD recomenda a realização de testes ao mesmo tempo que o código é escrito.

1.5 A Gestão Ágil A designação gestão Ágil é aplicada a um método iterativo e incremental de gestão de projetos e atividades de engenharia, tecnologia de informação e outras áreas de negócios que visam fornecer novos produtos ou serviços de forma flexível e interativa, com base nos princípios expressos no Manifesto Ágil.

Os métodos iterativos e ágeis foram desenvolvidos como uma resposta a vários obstáculos que se desenvolveram em formas mais sequenciais de organização de projetos. Por exemplo, à medida que os projetos de tecnologia crescem em complexidade, os utilizadores finais tendem a ter dificuldade em definir os requisitos de longo prazo sem antes visualizar protótipos progressivos. Projetos que se desenvolvem em iterações podem reunir constantemente feedback para ajudar a refinar esses requisitos.

A gestão ágil apresenta-nos uma estrutura simples que promove a comunicação e a reflexão sobre os projetos/trabalhos anteriores entre os membros da equipa. As equipas que antes usavam o método tradicional de planeamento em cascata e adotaram o método ágil de desenvolvimento normalmente passam por uma fase de adaptação e transformação, recebendo para o efeito apoio consultivo e coaching Ágil que ajudam a guiar as equipas por uma transição suave.

— 12 —

Introdução à Metodologia Ágil

De referir ainda que os métodos Ágeis são considerados no livro de conhecimento gestão de projetos (Guia PMBOK do PMI2) no âmbito da definição do ciclo de vida do projeto: “Ciclo de vida do projeto adaptável – Ciclo de vida do projeto, também conhecido como métodos orientados às mudanças ou métodos ágeis, que se destinam a facilitar a mudança e exige um alto grau de envolvimento das partes interessadas (stakeholders).

O ciclo de vida adaptativo é iterativo e incremental, mas difere do tradicional modelo porque as iterações são muito rápidas (geralmente de duas a quatro semanas de duração) e são fixadas no tempo (time boxing) e nos recursos.” [adaptado da sexta edição do PMBOK].

1.6 Conclusão Neste capítulo fizemos uma introdução à Agilidade e aos métodos Ágeis. Ficamos a conhecer a origem do conceito de Agilidade, as diferenças entre a abordagem tradicional (cascata) à gestão de projetos e a abordagem Ágil e ficamos a saber que na abordagem Ágil é a equipa de desenvolvimento que gravita à volta do cliente e não ao contrário, Figura 1.6. Ainda neste capítulo foi dado a conhecer os doze princípios do Manifesto Ágil. Identificamos os principais métodos Ágeis, entre eles o Scrum que nos vai ocupar nos capítulos que se seguem.

Embora estes métodos tenham nascido no sector do desenvolvimento de software, veremos mais à frente que o método Scrum pode ser aplicado a outros domínios tais como projetos de engenharia ou arquitetura. Todos os sectores expostos a grande volatilidade e incerteza podem beneficiar com os métodos Ágeis, em especial com o método Scrum que julgamos ser aquele que melhor pode ser aplicado a outros sectores que não o desenvolvimento de software.

PMI – Project Management Institute (www.pmi.org), 2017.

2

— 13 —

Figura 1.7 – Mudança de paradigma: do modelo centrado na equipa (cascata) ao modelo centrado no cliente (métodos Ágeis)

3Introdução ao Scrum

3.1 Introdução ao Scrum Os papéis no método Scrum dividem-se em duas grandes categorias: 1. Papeis centrais (Core roles) – são as funções principais, necessárias e obrigatórias para produzir o produto ou serviço do projeto. São responsáveis pelo sucesso de cada Sprint e do projeto como um todo; 2. Papeis não-centrais (Non-core roles) – não obrigatoriamente necessários para o projeto Scrum. Estas funções podem incluir membros da equipa que estão interessados no projeto, que não têm papel formal na equipa do projeto, que podem interagir com a equipa, mas que não podem ser responsáveis pelo sucesso do projeto. Os non-core roles também devem ser considerados em todos os projetos Scrum.

Existem core roles e non-core roles em cada equipa. Decidir quem desempenha um papel core e um papel non-core nem sempre é fácil. Há uma história que pode ajudar a clarificar e decidir quem é core e quem é non-core. Trata-se da história de uma galinha e de um porco que decidiram abrir um restaurante. A conversa entre os dois ajuda a esclarecer a diferença entre estar comprometido e envolvido, Figura 3.1.

— 15 —

Scrum

Figura 3.1 – A conversa entre a galinha e o porco

RESUMO

Os papeis centrais (core) têm de se comprometer com o projeto enquanto que os demais (non-core) estão apenas envolvidos.

De seguida serão apresentados os elementos que constituem ambos os papeis no Scrum.

3.2 Papeis Centrais – Core Roles Há três funções principais na estrutura Scrum que são, em última instância, responsáveis pelos objetivos do projeto: o Product Owner (o dono do produto ou serviço), o Scrum Master e a Scrum Team (também designada como equipa de desenvolvimento). Juntos, são estes papeis formam a Scrum Core Team. É importante salientar que, destes três papéis, nenhum tem autoridade sobre os outros.

A Figura 3.2 abaixo representa os papéis centrais no Scrum.

— 16 —

Introdução ao Scrum

Figura 3.2 – Os papeis centrais no Scrum e a sua interligação

3.2.1 Core Role: Product Owner O Product Owner representa as partes interessadas e é responsável por garantir que a Scrum Team entrega valor. O Product Owner escreve os requisitos do projecto, sob a forma de User Stories, com a contribuição da Scrum Team e gere Prioritized Product Backlog. Em alguns casos, os membros da equipa podem escrever as User Stories sob a supervisão do Product Owner. O Product Owner é também responsável por assegurar uma comunicação clara com a Scrum Team, acerca das funcionalidades do produto e, portanto, é chamado de “Voz do Cliente” ou VOC (voice of customer).

A Tabela 3.1. abaixo lista as responsabilidades do Product Owner durante os diferentes processos de um projeto Scrum.

— 17 —

Scrum Tabela 3.1 – Responsabilidades do Product Owner

Este é talvez o papel mais incompreendido no Scrum. O Product Owner precisa de compreender o conceito do Sprint. Embora não faça diretamente parte das tarefas de desenvolvimento, deve sentir-se parte da Scrum Team e não separado da mesma, em virtude da sua relação próxima com o cliente.

Correspondendo ao papel de Product Owner num projeto, pode haver um Program Product Owner – para um Programa (conjunto de projectos) ou um Portfolio Product Owner para um Portfolio (conjunto de Programas).

3.2.2 Voice of Customer (VOC) O cliente é a parte interessada (stakeholder) mais importante para qualquer Empresa ou Organização. Desta forma, é extremamente importante conhecer e compreender seus os requisitos e necessidades. A VOC refere-se às necessidades do cliente, expressas e não expressas, que devem ser perfeitamente compreendidas antes de produzir qualquer produto ou serviço. Por norma, na metodologia Scrum, a VOC é representada pelo Product Owner.

Em qualquer projeto Scrum, o cliente pode ser: Interno (ie, de dentro da própria Organização); Externo (ie, externo à Organização).

— 18 —

Introdução ao Scrum

3.2.3 Core Role: Scrum Master A principal responsabilidade do Scrum Master é assegurar que os processos Scrum são corretamente seguidos por todos os membros da Scrum Core Team, incluindo o Product Owner. O Scrum Master é a pessoa responsável por garantir que a gestão do projeto decorre sem problemas, e que os membros da Scrum Team têm todos os meios e ferramentas necessárias para realizar o trabalho. O papel de Scrum Master é baseado no conceito de Liderança Servidora (Servant Leadership), na qual os líderes alcançam os resultados satisfazendo as necessidades das pessoas que lideram.

A Tabela 3.2. seguinte resume as responsabilidades do Scrum Master, no decorrer dos diferentes processos de um projeto Scrum.

Tabela 3.2 – As responsabilidades do Scrum Master

A Figura 3.3. identifica as principais características que devemos esperar de um bom Scrum Master.

— 19 —

Scrum

Figura 3.3 – As principais características de um Scrum Master

Correspondente ao papel de Scrum Master num projeto, pode existir o Program Scrum Master num Programa ou o Portfolio Scrum Master, num Portfolio.

3.2.4 Core Role: Scrum Team A Scrum Team (também referida como equipa de desenvolvimento) é o grupo ou equipa de pessoas que são responsáveis por compreender os requisitos do negócio, especificados pelo Product Owner, estimar as User Stories, e criar as entregas do projeto. Ou seja, a Scrum Team é composta pelas pessoas que irão realizar o output desejado do projeto, são os executantes.

3.2.4.1 Características da Scrum Team

São auto-organizadas: O método Scrum promove o conceito de equipa auto-organizada, uma vez que esta é “proprietária coletiva do projeto; Os membros da equipa são envolvidos em todas as decisões relacionadas com as entregas (outputs ou deliberables) do projeto e escolhem a melhor forma de concluir o trabalho sem interferências externas.

— 20 —