Fundamentos do Scrum

Fundamentos

do Scrum

Rodrigo Alves Costa

A RNP – Rede Nacional de Ensino e Pesquisa – é qualificada como uma Organização Social (OS), sendo ligada ao Ministério da Ciência, Tecnologia e Inovação (MCTI)

e

responsável

pelo

Programa Interministerial RNP, que conta com a participação dos ministérios da Educação (MEC), da Saúde (MS) e da Cultura (MinC). Pioneira no acesso à Internet no Brasil, a RNP planeja e mantém a rede Ipê, a rede óptica nacional acadêmica de alto desempenho. Com Pontos de Presença nas 27 unidades da federação, a rede tem mais de 800 instituições conectadas. São aproximadamente 3,5 milhões de usuários usufruindo de uma infraestrutura de redes avançadas para comunicação, computação e experimentação, que contribui para a integração entre o sistema de Ciência e Tecnologia, Educação Superior, Saúde e Cultura.

Fundamentos

do Scrum Rodrigo Alves Costa

Fundamentos

do Scrum

Rodrigo Alves Costa

Rio de Janeiro Escola Superior de Redes 2016

Copyright © 2016 – Rede Nacional de Ensino e Pesquisa – RNP Rua Lauro Müller, 116 sala 1103 22290-906 Rio de Janeiro, RJ Diretor Geral

Nelson Simões Diretor de Serviços e Soluções

José Luiz Ribeiro Filho

Escola Superior de Redes Coordenador Nacional

Leandro Marcos Oliveira Guimarães Edição

Lincoln da Mata Coordenador Acadêmico da Área de Governança de TI

Edson Kowask Bezerra

Equipe ESR (em ordem alfabética)

Adriana Pierro, Alynne Figueiredo, Celia Maciel, Derlinéa Miranda, Elimária Barbosa, Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato , Renato Duarte e Yve Marcial. Capa, projeto visual e diagramação

Tecnodesign Versão

1.0.0

Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de conteúdo da Escola Superior de Redes, no e-mail [email protected]. A Rede Nacional de Ensino e Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a pessoas ou bens, originados do uso deste material. As marcas registradas mencionadas neste material pertencem aos respectivos titulares.

Sumário 1. Introdução A importância da informação e a crise do software 1 Crise do software 2 Por que se tornar ágil vale a pena? 3 Exercício de fixação – Como você entende que o Scrum pode melhorar a produtividade na sua organização? 7 Processo Scrum 8 Papéis, fluxo e artefatos do Scrum 9 Papéis do Scrum 9 Exercício de fixação – Na sua organização, que papéis atuais poderiam ocupar os papéis do Scrum em uma eventual transição para Scrum? 9 Fluxo do Scrum 9 Visão Scrum 13 Transparência 14 Inspeção 14 Adaptação 14 Scrum e processos de desenvolvimento 14 Exercício de fixação – O que você acha que precisa mudar na mentalidade da sua organização para adotar um processo de gestão de projetos ágil como o Scrum? 15 Introduzindo um processo ágil em uma organização 16 Desenvolvedores 16 Realizando a transição de um processo peso-pesado 16 Scrum Escalável 17 Atividades práticas – Cenário para escolha sobre um processo a ser adotado 18

iii

2. O Scrum Fase de especificação 19 Fase de projeto 20 Fase de implementação 20 Fase de teste 20 Fase de manutenção 21 Metodologias de desenvolvimento tradicionais: vantagens e desvantagens 21 Vantagens e desvantagens 22 Exercício de fixação – Que metodologias de desenvolvimento são utilizadas na sua organização? Você enxerga vantagens e desvantagens no seu uso? Quais? 23 Metodologias de Ágeis de Projetos 23 Software Funcional em vez de Documentação Detalhada 24 Colaboração ao cliente em vez de negociação de contratos 24 Indivíduos e iterações em vez de somente processos e ferramentas 25 Responder à mudanças x planos detalhados 25 Velocidade e qualidade 26 Vantagens e desvantagens 26 Exercício de fixação – Você acredita que a sua organização e os seus clientes se beneficiariam da adoção de uma metodologia como o Scrum? 27 Histórico do Scrum 27 Toyota, uma grande influência para o Scrum 27 Exercício de fixação – Como eliminar a restrição tripla na sua organização? 28 Exercício de fixação – Você acredita ser possível ter uma equipe auto-organizável na sua organização? Qual o contexto para possibilitar tal auto-organização? 29 Origem do nome 29 O processo 31 Empírico 31 Iterativo e incremental 32 Fases do Scrum 32 Tamanho de projetos 33 Atividades práticas – Cenários para levantamento de requisitos 33

3. A metodologia Papéis 36 Product Owner 36 Scrum Master 36 Equipe de desenvolvimento 37 Cerimônias 38

iv

Reunião de planejamento da Sprint (Planning Meeting) 38 Reuniões diárias de Scrum (Daily) 40 Artefatos 43 Planning Poker 45 Product Backlog 51 Sprint Backlog 53 Release Burndown 54 Gráfico de Burndown 55 Task Board 57 Release 57 Atividades práticas 58

4. Scrum e a organização Scrum e o ciclo PDCA 59 Escalando projetos com Scrum 60 Infraestrutura 61 Staging 61 Equipes distribuídas 62 Reunião de planejamento da Sprint 63 Daily Scrum 64 Szcrum of Scrums 66 Sprint reviews e retrospectivas 66 Dicas gerenciais 66 Coexistindo com outras abordagens 67 Misturando Scrum e desenvolvimento sequencial 67 Governança 68 Conformidade a padrões 69 Recursos humanos, instalações e o PMO 70 Atividades 72

v

vi

1 Entender a crise do Software. Por que se tornar ágil vale a pena? Introdução ao processo scrum. Realizando a transição de um processo peso-pesado para um ágil.

conceitos

Crise do Software. Processos ágeis e Motivação. Processos peso-pesado e transição

A importância da informação e a crise do software Existe nas organizações uma constante sinergia de pressões e forças que criam ameaças

q

e oportunidades para a expansão e retração do seu negócio, e que alimenta o processo de tomada de decisão. É por essa razão que gestores necessitam ter cautela nesse processo, bem como contar com ferramentas que habilitem uma decisão que seja tomada estrategicamente, orientada de maneira a não prejudicar a organização, levando em consideração as oportunidades de negócio e garantindo a prosperidade das empresas, e o prejuízo que pode incorrer caso decisões sejam tomadas incorretamente. As organizações hoje consideram a informação como o seu principal ativo – é através dela que os gestores decidem os caminhos a serem traçados. A informação tem o poder de dar suporte e orientar decisões de negócios. Assim, a informação é o canal que dá acesso ao conhecimento e que contribui para a

q

mudança e o aperfeiçoamento, propiciando o conhecimento necessário para a tomada de decisão e execução das ações. Os administradores precisam analisar como um ambiente estrategicamente alimentado em termos de informação pode afetar a posição competitiva de uma empresa no mercado. Nesse contexto, independente da fonte, o valor ou a validade da informação, as organizações necessitam de meios de armazenamento das informações relevantes e o realizam em seus repositórios e bancos de dados. Na verdade, a era do acesso a repositórios online já chegou. Os usuários conectados à internet têm a possibilidade de acessar os mais variados tipos de informação.

q

Capítulo 1 - Introdução

objetivos

Introdução

1

A existência de um universo rico com uma quantidade imensa de informação tem deixado pessoas e empresas um pouco perdidas, e o tomador de decisão pode, por vezes, ficar confuso. Ter muita informação não significa que a empresa está bem informada. É nesse contexto que surge a ciência da gestão da informação que, para Siqueira

q

Marcelo Costa, autor do livro “Gestão Estratégica da Informação”, significa “a ação sistêmica de procurar entender as necessidades informacionais de uma organização e disponibilizá-las para a solução de problemas organizacionais, de forma estruturada e clara, com conhecimento pleno de todos os procedimentos e processos da solução encontrada, garantindo assim que ele seja eficaz e repetível”. Como se pode imaginar, ter a informação certa na hora certa e não é uma tarefa fácil. As informações devem ser exatas, relevantes e estar disponíveis em tempo hábil. A gestão da informação, portanto, busca resolver o problema de buscar uma forma eficiente de coletar e processar apenas as informações essenciais e indispensáveis, uma vez que é humanamente impossível digerir a imensa quantidade de informações colocadas à disposição. Como o compartilhamento e a distribuição do conhecimento organizacional é condição vital prévia para transformação de informações e experiências organizacionais isoladas em algo que a organização possa utilizar, e sendo a informação um ativo, ou seja, um bem que agrega valor à empresa, é necessário fazer uso de recursos de Tecnologia da Informação (TI) de maneira apropriada. É necessário utilizar, produzir e adquirir ferramentas de software para gerenciar bases

q

de dados que cresçam à medida que a informação se transforma e se torna disponível e relevante organizacionalmente.

Crise do software Paralelamente a essa necessidade pela produção de software relevante, que existe até os dias

q

de hoje, um termo acerca de sua produção foi firmado nos primeiros dias da ciência da computação e diz respeito à dificuldade de escrever programas de computador realmente úteis e eficientes dentro do tempo necessário para as partes interessadas: “crise do software”. A crise do software se deu por causa das melhorias rápidas nas capacidades dos computadores, e levando em consideração as complexidades dos problemas que conseguiriam resolver. Com o aumento da complexidade dos softwares, muitos problemas dessa natureza surgiram porque os métodos existentes não se mostraram suficientes. O termo “crise do software” foi cunhado pelos participantes na Conferência de Engenharia de Software da OTAN, em 1968, em Garmisch, na Alemanha. A palestra de Edsger Dijkstra, da ACM, de 1972, faz referência a esse mesmo problema: "A principal causa da crise de software é que as máquinas tornaram-se várias ordens de grandeza mais potentes! Para colocá-lo muito claramente: enquanto não havia máquinas, a programação foi nenhum problema em tudo; quando tivemos alguns computadores fracos, a programação tornou-se Fundamentos do Scrum

um problema leve, e agora temos computadores gigantescos, a programação tornou-se um

2

problema igualmente gigantesco.”

As causas da crise do software estão ligadas à complexidade geral do hardware e o pro-

q

cesso de desenvolvimento de software. A crise manifesta-se de várias maneiras: 11 Projetos em execução que estouram o orçamento; 11 Projetos que atrasam; 11 Software que, depois de entregue, se mostrou muito ineficiente; 11 Software de pouca qualidade; 11 Software que, muitas vezes, não atendeu aos requisitos; 11 Projetos se mostraram incontroláveis com um código difícil de manter; 11 Software nunca foi entregue. A ideia principal por trás da crise é que as melhorias no poder de computação sobrepujaram a capacidade dos programadores de utilizarem eficazmente esses recursos. Vários processos e metodologias foram desenvolvidos ao longo das últimas décadas para melhorar a gestão da qualidade de software, tais como programação processual e programação orientada a objetos. No entanto, projetos de software que são grandes, complicados, mal especificados e que principalmente envolvem aspectos desconhecidos ainda são vulneráveis a problemas grandes demais, imprevistos.

Por que se tornar ágil vale a pena? Em uma realidade de crise, equipes ágeis de sucesso têm produzido software de melhor

q

qualidade que atende às necessidades do usuário mais rapidamente e a um custo menor do que as equipes tradicionais. As organizações que se tornam ágeis adotando um processo como o Scrum têm experimentado benefícios significativos, incluindo ganhos dramáticos de produtividade com diminuições correspondentes em custo. Elas são capazes de levar produtos ao mercado muito mais rapidamente e com maior grau de satisfação do cliente, além de experimentar maior visibilidade do processo de desenvolvimento, o que leva a maior previsibilidade de resultados. Uma das primeiras organizações a entender esses benefícios a adotar o Scrum foi a Salesforce.com. Fundada em 1999 em um apartamento de San Francisco, a Salesforce. com é uma das histórias de sucesso duradouras da época das pontocom. Em 2006, com uma receita de mais de US$ 450 milhões e 2 mil funcionários, a Salesforce.com notou que a frequência das suas releases tinha diminuído de quatro por ano para apenas uma. Os clientes estavam recebendo menos entregas e esperando mais tempo para obtê-las, e algo precisava ser feito. A empresa decidiu a transição para Scrum. Durante o primeiro ano de mudança, a Salesforce.com: 11 Liberou 94% mais funcionalidades; 11 Entregou 38% mais funções por desenvolvedor;

Nos dois anos seguintes, a receita mais que dobrou, para mais de US$ 1 bilhão. Com resultados como esses, não é surpreendente que tantas organizações fizessem a transição para Scrum. Ou pelo menos tentassem. A transição para Scrum e outros métodos ágeis é difícil: muito mais difícil do que muitas empresas antecipam. As alterações necessárias para colher todos os frutos que se tornar ágil pode trazer são de longo prazo. Tais mudanças exigem grande quantidade de esforço


11 E mais de 500% mais valor aos seus clientes em relação ao ano anterior.

não só por parte dos desenvolvedores, mas de toda a organização. Não se trata apenas de 3

uma mudança das práticas, é necessário mudar a mentalidade e a forma de trabalho estabelecida. O objetivo deste curso, portanto, não é apenas mostrar como fazer essa transição adequadamente, mas também como obter sucesso no longo prazo. Toda mudança é difícil. Mudanças maiores podem ser ainda mais difíceis. No entanto,

q

existem ainda certas características de transição para Scrum que o tornam mais difícil do que a maioria das outras mudanças. Uma mudança, para ser considerada de sucesso, não depende exclusivamente de ser de cima para baixo ou de baixo para cima (ou seja, há múltiplos fatores que determinam o sucesso da mudança): em uma mudança top down (de cima para baixo), um líder influente compartilha uma visão do futuro e a organização segue o líder em direção a essa visão. Imagine um líder carismático, respeitado e poderoso como Steve Jobs dizendo a seus funcionários da Apple que eles são se movendo “para além de hardware e software de computador para dominar a música digital”. A sua reputação e estilo poderia ter apontado a empresa em uma nova direção, mas isso por si só não teria sido suficiente para realizar uma proeza tão improvável. Da mesma forma, sem compromisso operacional, as pessoas resistem à cadeia de comando. Assim, a participação bottom-up (de baixo para cima) será necessária, pois será o indivíduo, ou seja, os membros da equipe que trabalham com as questões que vão descobrir como Scrum vai funcionar melhor dentro de sua organização. Assim, a chave para qualquer sucesso na adoção de Scrum será a combinação elementos de bottom-up e mudança top-down. Criar esse plano exigiria saltar dois obstáculos impossíveis: em primeiro lugar, saber exatamente onde nós queremos acabar e, em segundo, saber exatamente os passos para chegar lá. Como não podemos superar essas impossibilidades, o melhor que se pode fazer é adotar uma abordagem de “provocar e observar” (Avery De, 2005), em que se pode tentar algo, ver se ele nos move mais perto de um objetivo intermediário, verificar se o estado melhorou e, em caso afirmativo, fazer mais do mesmo. Esses processos da organização não são aleatórios, são cuidadosamente selecionados com base na experiência, conhecimento e intuição, para dirigir uma transição para o Scrum. Apresentar a revisão de prontidão operacional quase certamente vai impactar as finanças, vendas ou outros departamentos. Portanto, cada um desses departamentos pode ser afetado pela Scrum. Dessa maneira, grupos financeiros terão de conciliar as políticas da empresa na capitalização com a maneira de como projetos Scrum se comportam quando estão em execução. As vendas e o marketing podem querer alterar como comunicam os seus prazos e o escopo, e podem mudar a forma como estruturam contratos. Com mais

l O estado final é imprevisível: uma transição para Scrum não pode ser tal que “articula e define o todo o processo de mudança necessária para preencher a lacuna entre ‘como’ e ‘ser’ e cria planos táticos”, como em um de gerenciamento de mudanças tradicional, segundo Carr, Duro, e Trahant.

l Scrum é generalizada: se tornar ágil terá implicações para a organização que vão muito além do departamento de desenvolvimento de software.

grupos afetados por uma mudança para o Scrum, há mais chance para aumentar a resistência e certamente mais chance de problemas, o que pode tornar a transição para Scrum ainda mais difícil.

Fundamentos do Scrum

Muitos testadores, por exemplo, aprendem ao longo dos anos que o seu trabalho é testar

4

para conformidade com uma especificação de requisitos. Por sua vez, os programadores foram treinados para analisar um problema em profundidade e para conceber uma solução perfeita antes que qualquer codificação comece. Em um projeto Scrum, testadores e programadores precisam desaprender esses comportamentos. Testadores passam a entender que o teste é também entender que o sistema precisa estar em conformidade com as necessidades do usuário. Já os programadores entendem que um design nem sempre é necessário (e às vezes nem mesmo desejável) antes que a codificação comece.

l Scrum é dramaticamente “diferente”: as mudanças criadas através da adoção do Scrum se permeiam ao longo do desenvolvimento, e muitas dessas mudanças vão de encontro à formação passada da maior parte dos funcionários.

Como a transição para Scrum inclui pedir às pessoas para trabalhar de uma forma diferente daquela que estão familiarizadas, ou seja, de uma forma que contradiz aquela da sua formação e experiência, os funcionários muitas vezes se apresentam muitas vezes resistentes à mudança.

As melhores práticas são arriscadas: como a maior parte de toda e qualquer mudança organizacional, depois que alguém descobre a melhor maneira de fazer alguma coisa, essa forma de fazer é capturada e registrada como uma “melhor prática”, e compartilhada com todos os outros.

Para alguns tipos de trabalho, a coleta e reutilização de melhores práticas é uma tremenda ajuda para o esforço de mudança. Por exemplo, uma organização que está vendendo um produto para um novo tipo de cliente pode capturar as melhores práticas para superar objeções por parte dos prospectos. Ao fazer a transição para Scrum, no entanto, a coleta de melhores práticas pode ser arriscada, pois elas tentam fazer a equipe “relaxar e parar o esforço de melhoria contínua”, que é essencial ao Scrum. Embora os membros da equipe devam sempre pesquisar para compartilhar uns com os outros as suas recém-descobertas acerca das melhores formas de trabalhar, eles devem resistir ao impulso de codificá-las em um conjunto de melhores práticas. Apesar de todas as razões pelas quais a transição para Scrum pode ser particularmente difícil, partes interessadas nas organizações que a realizaram têm o tempo para o mercado de seus produtos reduzido e se mostram satisfeitos depois de implementar um processo ágil como Scrum. Esse tempo de colocação no mercado mais rápido é possibilitado pela maior produtividade das equipes ágeis, o que por sua vez é o resultado da maior qualidade de projetos nessa disposição. Como os funcionários podem realizar trabalhos de alta qualidade e como eles passam a ver o seu trabalho entregue mais cedo nas mãos dos usuários, a satisfação com o trabalho sobe. Com maior satisfação dos funcionários, nota-se maior envolvimento, o que leva a ganhos de produtividade, iniciando um ciclo virtuoso de melhoria contínua. Podemos listar as seguintes razões porque uma transição para um processo ágil como

q

Scrum é importante: Aumento da produtividade e redução de custos Infelizmente, não há medidas universalmente padronizadas para medição de produtividade. Martin Fowler (2003) diz que medir a produtividade dos desenvolvedores de software é impossível. No entanto, algumas equipes usam medidas como o número de linhas de código como uma entrada para a produtividade. Outros usam como o número de pontos de função, ou seja, pontos entregues ao cliente. Algumas equipes medem sua produtividade por meio do número de características entregues, ignorando que nem

Obviamente, nenhuma dessas formas de medir produtividade é perfeita, mas a utilidade de se tentar medi-la encontra-se na aproximação do entendimento do que se quer gerenciar. Nesse sentido, a QSMA calcula sua produtividade por meio de um sistema que considera esforço, cronograma, dificuldade técnica das atividades e alguns outros fatores em uma tentativa de realizar comparações entre equipes mais significativas.

q


todas as características são do mesmo tamanho.

5

Em sua comparação entre projetos tradicionais e ágeis, Mah (2008) entende que projetos ágeis são 16% mais produtivos em qualquer situação. A figura 1.1 mostra a comparação de projetos ágeis (pontos) comparado com a produtividade média de o desvio padrão na base de dados da QSMA. Como se pode ver, a maioria dos pontos encontra-se acima da média da indústria, com

q

uma boa parte dos projetos mais de um desvio padrão acima de um nível de produtividade dessa média. +/- 1 Desvio padrão

Produtividade

Alto

Média

Figura 1.1 Equipes ágeis são significativamente mais produtivos que a média da indústria.

Projetos ágeis Baixo

Maior

Menor

Tamanho do projeto Os resultados da QSMA são corroborados por outras pesquisas, tais como as da DDJ e VersionOne. De acordo com a primeira, 82% dos participantes sentiram que a produtividade foi um pouco ou muito mais elevada do que antes, quando se utiliza métodos ágeis como o Scrum. De acordo com a VersionOne, 73% acreditava que ser ágil tinham significativamente melhorado (23%) ou melhorado (50%) a produtividade. Ora, é razoável entender que, se os funcionários em uma organização são mais produtivos, os custos serão menores. Embora encorajadores, esses números contam apenas parte da história. Uma das críticas dos processos tradicionais é que eles são tão onerosos. Que, muitas vezes, quando o software é entregue, algumas funcionalidades – ou o aplicativo inteiro – não são mais necessárias. Um benefício significativo de ser ágil é que equipes ágeis possuem a tendência de produzir apenas funcionalidades necessárias. Graças ao feedback constante e à habilidade de priorizar novamente a cada Sprint, uma equipe Scrum é capaz de trabalhar apenas naquelas funcionalidades que os usuários realmente precisam. Se isso for incluído no nosso requisito de produtividade, provavelmente veríamos resultados ainda mais dramáticos. De acordo com o levantamento de Rico, com base em estudos de caso de equipes ágeis

q

publicados até 2016, mostrada na tabela 1.1, há um aumento médio de produtividade de 88% e economias de 26% de custos quando se transiciona para ágil. Esses indicam uma evidência sólida de que equipes ágeis são mais produtivas, o que leva à redução de


custos para os seus projetos.

6

Categoria

Melhoria Mais Baixa

Melhoria Média

Melhoria Mais Alta

Produtividade

14%

88%

384%

Custo

10%

26%

70%

Tabela 1.1 Melhorias verificadas com ágil por categoria.

Exercício de fixação e Como você entende que o Scrum pode melhorar a produtividade na sua organização? O envolvimento dos funcionários melhora também a satisfação no trabalho Um fator que contribui para a maior produtividade e menores custos em projetos ágeis é: os trabalhadores passam a gostar mais do que fazem. Quinze meses após a adoção do

l

Uma razão pela qual os funcionários podem aproveitar mais os seus trabalhos é devido ao ritmo sustentável promovido por processos ágeis.

Scrum, a Salesforce.com realizou uma pesquisa junto a seus funcionários e constatou que 86% estavam “gostando” ou o “gostando muito” de trabalhar na empresa. Antes de adotar Scrum, apenas 40% respondiam a mesma coisa. Além disso, 92% dos funcionários disseram que recomendariam uma abordagem ágil para os outros. Resultados como esses são comuns. Em seu levantamento na indústria, a VersionOne constatou que 74% dos entrevistados relataram que a “moral” foi melhorada (44%) ou significativamente melhorada (30%).

Time to Market mais rápido Equipes ágeis tendem a lançar seus produtos mais rapidamente do que as equipes tradi-

q

cionais. De acordo com o estudo da VersionOne, 64% dos participantes relataram que o tempo de comercialização foi melhorado (41%) ou significativamente melhorado (23%). O estudo da QSMA comparou 26 projetos ágeis em uma base de dados de 7.500 projetos, em sua maioria tradicionais, chegando à conclusão de que os projetos ágeis chegaram 37% mais rapidamente ao mercado, como mostrado na figura 1.2.

Alto +/- 1 Desvio padrão

Time to market

Média

Baixo

Menor

Maior

Tamanho do projeto

Melhoria na satisfação das partes interessadas Tendo em conta todos os benefícios de processos ágeis até agora, não é surpreendente

q

que eles conduzam a uma melhoria na satisfação das partes interessadas. A pesquisa da DDJ descobriu que 78% dos participantes da pesquisa acreditam que o uso de um processo ágil levou a uma melhoria “um pouco maior” (47%) ou “muito mais elevada” (31%) na satisfação das partes interessadas. Uma das razões pelas quais as partes interessadas ficam mais satisfeitas com processos ágeis é porque as suas práticas são mais amigáveis com relação às mudanças de prioridades, o que é uma necessidade na vida das organizações de ritmo acelerado e competitivo de hoje. No estudo da VersionOne, 92% dos participantes consideraram que as metodologias ágeis melhoraram a capacidade de gerenciar mudanças de prioridades.

q


Figura 1.2 Projetos ágeis possuem um time to Market 37% mais rápido comparado com a média da indústria.

Projetos ágeis

7

Além disso, juntamente com a capacidade de mudar mais facilmente as prioridades, as partes interessadas em projetos ágeis aprendem a gerenciar o impacto da mudança. Outras razões incluem a melhoria na visibilidade dos projetos, a melhoria do alinhamento da TI e objetivos de negócio, e a redução de riscos de projeto.

O que as organizações têm feito não funciona Uma razão final para considerar a mudança para o Scrum é se o seu processo de desenvolvimento atual não está mais funcionando. Quando um processo que até funcionou no passado encontra muitas barreiras, uma tendência comum é “fazer mais do mesmo”. Esse foi certamente o caso no Yahoo!, onde o diretor de produto Pete Deemer foi um dos primeiros a reconhecer a necessidade de mudança: “Inicialmente, o Yahoo! tentou Scrum puramente por desespero. A abordagem sequencial claramente não estava funcionando, e fizemos uma tentativa de um ano para fazer a sequencial ‘melhor’ através de um planejamento e uma análise mais aprofundada de documentos, mais sign-offs e, assim por diante, era tornar as coisas piores, não melhores. Para as equipes que viram benefícios, que eram a maioria das equipes que tentaram Scrum, os benefícios eram visíveis quase que imediatamente.” Assim, ao adotar o Scrum, é interessante identificar continuamente os benefícios

q

obtidos até determinado ponto, selecionar fatores de interesse da organização e fazer com que tais fatores sejam uma linha de base contra a qual se possa comparar mais tarde – uma boa dica é qualidade, moral da equipe e satisfação das partes interessadas.

Processo Scrum Todas as práticas do Scrum estão cravadas em um esqueleto de processo incremental.

lCrie cartões para compartilhar com outras equipes com os seus resultados, explicando por que vale a pena mudar para o Scrum, se mostrarem interesse na transição. Isso pode diminuir a resistência da organização como um todo.

q

Esse esqueleto é mostrado na figura 1.3. O círculo de baixo representa uma iteração de atividades de desenvolvimento que ocorrem uma após a outra, e a saída de cada uma delas é um incremento no produto. Já o círculo superior representa uma espécie de inspeção diária que ocorre durante a iteração citada anteriormente, durante a qual cada membro da equipe se reúne para acompanhar as atividades umas dos outros e realizar adaptações adequadas. O que guia as interações são uma lista de requisitos e o ciclo se repete enquanto houver orçamento disponível para o projeto.

Reunião de Scrum Diária

24 h

2 – 4 semanas


Product Backlog

Sprint Backlog

Incremento no Produto

O esqueleto de processo funciona da seguinte maneira: no início de uma iteração, a equipe analisa o que deve fazer. Em seguida, seleciona o que acredita que pode se transformar em um incremento potencialmente utilizável de funcionalidade até no final de um ciclo da iteração, que dura entre duas e quatro semanas. Cada ciclo desses é conhecido como Sprint. A equipe é então deixada sozinha para fazer o seu trabalho durante a Sprint. No final, ela apresenta o incremento de funcionalidade que construiu, de modo que as partes interessadas podem inspecionar a funcionalidade e as adaptações oportunas para que o projeto possa ser feito.

8

Figura 1.3 O processo Scrum.

q

O coração de Scrum reside na iteração. A equipe lança um olhar sobre os requisitos, con-

q

sidera a tecnologia disponível, e avalia as suas próprias habilidades e capacidades. Em seguida, coletivamente determina como construir a funcionalidade, modificando a sua abordagem diariamente, à medida que encontra novas complexidades, as dificuldades e surpresas. A equipe descobre o que precisa ser feito e seleciona a melhor maneira de fazêlo. Esse processo criativo é o coração da produtividade Scrum.

Papéis, fluxo e artefatos do Scrum Papéis do Scrum Scrum possui três papéis: product Owner, Scrum Master e a equipe. 11 Product Owner: o Product Owner deve ser a pessoa com visão, autoridade e dispo-

q

nibilidade. O Product Owner é responsável por se comunicar continuamente com o time de desenvolvimento sobre a visão do projeto e as prioridades. Muitas vezes, é difícil para os Product Owners atingir o ponto ideal de envolvimento. Como Scrum valoriza auto-organização entre equipes, um Product Owner deve lutar a necessidade de microgerenciar. Ao mesmo tempo, Product Owners devem estar disponíveis para responder questões da equipe; 11 Scrum Master: o Scrum Master age como um facilitador para o Product Owner e

q

para a equipe. O Scrum Master não gerencia a equipe. O Scrum Master trabalha para remover quaisquer impedimentos ou barreiras que porventura venham atrapalhar a equipe para atingir os objetivos da Sprint. Isso ajuda a equipe a se manter criativa e produtiva ao mesmo tempo em que garante que seus sucessos estão visíveis ao Product Owner. O Scrum Master também trabalha para auxiliar o Product Owner em como maximizar o ROI (retorno sobre investimento) para a equipe; 11 Equipe: de acordo com os criadores do Scrum, “a equipe é totalmente autogeren-

q

ciável”. A equipe de desenvolvimento é responsável por se auto-organizar para completar o trabalho. Uma equipe de desenvolvimento Scrum contém mais ou menos sete membros completamente dedicados (oficialmente de 3 a 9), idealmente em uma sala protegida de distrações externas. Para projetos de software, uma equipe típica inclui uma mistura de engenheiros de software, arquitetos, programadores, analistas, especialistas em qualidade, testadores e designers de interface gráfica. A cada Sprint, a equipe é responsável por determinar como vai conseguir finalizar o trabalho. A equipe possui a autonomia e responsabilidade para atingir

Exercício de fixação e Na sua organização, que papéis atuais poderiam ocupar os papéis do Scrum em uma eventual transição para Scrum? Fluxo do Scrum Um projeto Scrum começa com uma visão do sistema a ser desenvolvido. A visão pode ser vaga no início, talvez expressa em termos de mercado, em vez de requisitos de sistema, mas ela se tornará mais clara à medida que o projeto avança.

q


os objetivos da Sprint.

9

O Product Owner é responsável por garantir o financiamento do projeto e por entregar a visão de uma forma que maximiza o retorno do investimento. O Product Owner também formula um plano para fazê-lo, que inclui um Product Backlog. O Product Backlog é uma lista de requisitos funcionais e não funcionais que, quando transformado em funcionalidade, vai entregar essa visão. O Product Backlog é priorizado para que os itens com maior probabilidade de gerar valor sejam prioridade e estejam divididos em lançamentos propostos. O Product Backlog priorizado é um ponto de partida, e os seus conteúdos, as prioridades, e agrupamento em releases geralmente muda no momento do início do projeto, como esperado. Mudanças no Product Backlog refletem mudanças nos requisitos de negócios e quão rapidamente a equipe pode transformar esses requisitos em funcionalidade implementada. Todo o trabalho é feito em Sprints. Cada Sprint é uma iteração de 30 ou 15 dias consecutivos e é iniciada com uma reunião de planejamento, onde o proprietário do produto e equipe se juntam para colaborar sobre o que será feito para a próxima Sprint. A ideia é que o Product Owner selecione o item de mais alta prioridade no Product Backlog, e que a equipe explique ao mesmo o quanto do que é desejado ela acredita que pode ser transformado em funcionalidade ao longo da próxima Sprint. Reuniões de planejamento da Sprint não podem ser muito demoradas, não devendo durar mais do que oito horas, evitando muita angústia sobre o que é possível. O objetivo é começar a trabalhar, não pensar em planejar o trabalho. Todos os dias, a equipe se reúne para uma reunião de 15 minutos chamada Daily Scrum. O objetivo da reunião é sincronizar o trabalho de todos os membros da equipe diariamente e agendar quaisquer reuniões adicionais que a equipe necessite para transmitir o seu progresso. No final da Sprint, uma reunião de revisão da Sprint é realizada. Essa é uma reunião de quatro horas em que a equipe apresenta o que foi desenvolvido durante a Sprint para o Product Owner e quaisquer outros interessados que queiram participar. Trata-se de uma reunião informal em que a funcionalidade é apresentada e destina-se a reunir as pessoas e ajudá-los de forma colaborativa, determinando o que a equipe deve fazer a seguir. Após a revisão da Sprint, e antes da próxima reunião de planejamento da Sprint, o ScrumMaster realiza uma reunião retrospectiva da Sprint com a equipe. Nessa reunião, o ScrumMaster encoraja a equipe a rever seu processo de desenvolvimento, no âmbito e práticas do processo Scrum, para torná-lo mais eficaz e agradável para a próxima Sprint. Juntos, a reunião de planejamento da Sprint, o Daily Scrum, a revisão Sprint e a retrospectiva da Sprint constituem as práticas de inspeção e de adaptação empíricos de Scrum. Na figura 1.4, podemos encontrar o processo Scrum estendido, incluindo as reuniões


recém-citadas.

10

q

A cada 24 horas Scrum diário

Sprint Nova funcionalidade demonstrada ao ﬁnal da Sprint

Backlog da Sprint

Selected Product Backlog

Backlog do Produto: Emergente, requisitos priorizados Visão: ROI esperado, lançamentos, Millestore

Figura 1.4 Visão geral do processo do Scrum.

Artefatos Scrum introduz alguns novos artefatos. Estes são utilizados em todo o processo de

q

scrum e são descritos a seguir.

Product Backlog Os requisitos para o sistema ou produto que está sendo desenvolvido pelo projeto estão

q

listados no Product Backlog. O Product Owner é responsável pelo conteúdo, priorização e a disponibilidade do Product Backlog. O Product Backlog nunca está completo, finalizado, ou seja, o Product Backlog utilizado no plano de projeto é apenas uma estimativa inicial das necessidades e evolui à medida que o produto e o ambiente em que será usado evolui. Em outras palavras, o Product Backlog é dinâmico e a gestão muda constantemente tal documento para identificar o que o produto necessita para Tabela 1.2 Product Backlog.

que seja adequado, competitivo e útil. Enquanto o produto existir, o Product Backlog existe. Um exemplo pode ser encontrado na tabela 1.2:

Requisito

Num

Categoria

Status

Pri

Estimativa

Registrar requisitos na base de dados

17

funcionalidade

em curso

4

5

Processar cenário de saque simples

232

caso de uso

em curso

4

60

Aprovação de crédito muito lento

12

problema

não iniciado

3

10

Cálculo de comissão de venda

43

defeito

finalizado

2

2

Captura de venda em ponto de venda

321

melhoria

não iniciado

1

100

Processar cenário de crédito PMT

45

caso de uso

em curso

3

30


Product Backlog

11

Sprint Backlog O Sprint Backlog define o trabalho (ou as tarefas que uma equipe define para transformar os

q

itens do Product Backlog que ele escolheu para o Sprint), de maneira a transformá-lo em um incremento de funcionalidade do produto potencialmente utilizável. Somente o time pode mudar o Sprint Backlog. O Sprint Backlog deve ser altamente visível, e deve ser um quadro que demonstra em tempo real o trabalho que a equipe planeja efetuar durante a Sprint. Um exemplo de um Sprint Backlog é mostrado na tabela 1.3. As linhas representam tarefas do Sprint Backlog; as colunas representam os 30 dias no Sprint. Uma vez que uma tarefa é definida, a estimativa do número de horas restantes para completar a tarefa é colocada no cruzamento da tarefa, e o dia Sprint pela pessoa que trabalhe com a tarefa. Sprint Backlog

Origem

Responsável

Status

Descrição da Atividade

Horas de trabalho restantes por dia

1

Rosa

João

em curso

8

8

8

8

8

8

8

8

8

8

8

8

Gerar documentação do SDK

Pedro

não iniciado

16

16

16

16

16

16

16

16

16

16

16

16

Disponibilizar documentação na wiki

João

não iniciado

6

6

6

6

6

6

6

LDAP: grupos de suporte

Maria

finalizado

26

18

10

2

0

0

0

0

0

0

0

0

Documentação de branch: fontes e builds

Pedro

não

4

4

4

4

4

4

4

4

4

4

4

4

Impedir criação de relações "erradas"

Maria

finalizado

20

12

4

0

0

0

0

Descrever extensão de PDA

Pedro

em curso

26

18

10

2

2

2

2


Release do serviço

12

2

3

4

5

6

7

8

9

10

11

12

iniciado

64

58

50

42

34

Incremento potencialmente utilizável de funcionalidade de produto Scrum exige que os times desenvolvam um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente utilizável, porque o Product Owner pode optar por implementar a funcionalidade imediatamente.

q

Tabela 1.3 Sprint Backlog.

l

Isso requer que os incrementos precisem ser exaustivamente testados e bem estruturados, que o código seja construído em um arquivo executável e que a funcionalidade implementada para operação do usuário seja escrita em um código bem documentado e disponibilizada em arquivos de ajuda ou em outra documentação de usuário acordada.

Visão Scrum Scrum é uma ferramenta para desenvolver e manter produtos complexos. A ciência do

q

Scrum está por trás do desenvolvimento de software complexo. Obviamente tal fato não é muito surpreendente, porque o universo é cheio de complexidades. A maioria delas são desconhecidas para a maioria das pessoas. Algumas – como o processo através do qual a pressão transforma carvão em diamantes, por exemplo, é irrelevante para a maioria das pessoas por ser natural e cuidar de si mesma. Outras, como o deslocamento para o trabalho diariamente, podem tolerar alguma imprecisão. No entanto, é impossível ignorar a complexidade no desenvolvimento de software. Seus

q

resultados são efêmeros, consistindo apenas de sinais que controlam máquinas de estado. O processo de desenvolvimento de software é totalmente intelectual, e todos os seus produtos intermediários são representações marginais dos pensamentos envolvidos. Os materiais que usamos para criar o produto final são extremamente voláteis: os requisitos dos usuários para um programa que utilizarão no futuro, a interoperabilidade de sinais entre outros programas com o aplicativo a ser desenvolvido e a interação dos organismos mais complexos do planeta – pessoas. Dessa forma, Scrum se propõe a ser visto como um quadro no qual as pessoas podem

q

resolver os problemas adaptativos complexos, ao mesmo tempo em que o realizam de forma produtiva e fornecem, de maneira criativa, produtos de maior valor possível. Scrum é: 11 Leve (Lightweight); 11 Simples de entender; 11 Difícil de dominar. Scrum é uma estrutura de processo que tem sido utilizada para gerenciar o desenvolvimento de produtos complexos desde o início da década de 1990. Scrum não é um processo ou uma técnica para a construção de produtos; ao contrário, é um quadro no qual você pode empregar vários processos e técnicas. Scrum torna clara a eficácia relativa das suas práticas de gestão e desenvolvimento de produtos para que você possa melhorar. O framework Scrum consiste em equipes Scrum e seus papéis associados, eventos, artefatos e regras. Cada componente no quadro serve a um propósito específico e é essencial para o sucesso e uso do Scrum. As regras do Scrum unir os eventos, papéis e artefatos, que rege as relações e interações

q

entre eles. As regras de Scrum são descritas ao longo desse documento. Táticas específicas para o uso do framework Scrum variam. Scrum é fundada na teoria de controle de processos empíricos: o empirismo. Essa teoria afirma que o conhecimento vem de decisões de experiência, preparando com base no que é conhecido. Scrum emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. São três os pilares que sustentam qualquer implementação de controle de processos empíricos: a transparência, a inspeção e a adaptação.


Essa é a definição de um incremento “pronto”.

13

Transparência Aspectos significativos do processo devem ser visíveis para os responsáveis pelo resul-

q

tado. A transparência exige que esses aspectos sejam definidos por um padrão comum de modo que observadores compartilhem um entendimento comum sobre o que está sendo visto. Por exemplo: 11 Uma linguagem comum referindo-se ao processo deve ser partilhada por todos os participantes; 11 Aqueles que executam o trabalho e aqueles que aceitam o produto do trabalho devem compartilhar uma comum definição de “Pronto”.

Inspeção Usuários de um projeto do Scrum devem frequentemente inspecionar artefatos pro-

q

duzidos pelo projeto e progredir em direção a uma meta de uma Sprint para detectar variações indesejáveis. Obviamente, a inspeção não deve ser tão frequente de maneira a tornar a inspeção uma barreira ao trabalho. As inspeções são mais benéficas quando a diligência é realizada por inspetores qualificados no trabalho.

Adaptação Se um inspetor determina que um ou mais aspectos de um processo se desvia dos

q

limites aceitáveis e que o produto resultante será inaceitável, o processo ou o material a ser processado tem de ser ajustado. Um ajuste deve ser feito o mais rapidamente possível para impedir desvios futuros. Os eventos prescritos pelo Scrum para garantir inspeção e adaptação são: 11 Planejamento da Sprint; 11 Scrum diária; 11 Revisão da Sprint. 11 Retrospectiva da Sprint

Scrum e processos de desenvolvimento A abordagem Scrum para o desenvolvimento de software ágil marca uma saída radical

q

das abordagens tradicionais. Scrum e outros métodos ágeis foram inspirados pelas deficiências daquelas abordagens, e enfatizam em colaboração, software funcional, autogestão de equipe e na flexibilidade a adaptar-se a necessidades emergentes de negócios. Essas necessidades são as mais comumente verificadas em negócios de software, cujos clientes normalmente não conhecem todos os requisitos de negócio no começo do projeto, e têm necessidades emergentes durante a sua execução. Fundamentos do Scrum

Scrum é parte do movimento ágil. Esse é uma resposta à falha da maioria dos paradigmas de gestão de projetos de desenvolvimento, e toma emprestado muitos princípios de lean manufacting. Em 2011, 17 pioneiros de métodos similares se reuniram no Resort Snow Bird Ski, em Utah, e escreveram o Manifesto Ágil, uma declaração de quatro valores e doze princípios. Esses valores e princípios contradizem fundamentalmente as áreas de conhecimento tradicionais do PMBoK. No entanto, o Manifesto Ágil não provê passos concretos. As organizações normalmente procuram métodos mais específicos dentro do movimento Ágil. Estes incluem Crystal Clear, 14

Extreme Programming, Desenvolvimento Orientado a Funções, Scrum e outros. Tipicamente, uma solução que possui definições simples como o Scrum habilita a equipe com a autonomia necessária para realizar o melhor trabalho enquanto auxilia a alta gestão (cujos membros podem se tornar Product Owner) a obter os resultados de negócio que desejam. Scrum é capaz de abrir portas para outras abordagens ágeis úteis como desenvolvimento orientado a testes. Uma organização realmente ágil dificilmente possui um lado “técnico” e um lado “de negócios”, mas possui equipes trabalhando diretamente que desejam entregar valor de negócios. Ora, os melhores resultados de negócios são entregues quando o negócio inteiro está envolvido no processo. Os primeiros defensores do Scrum foram inspirados por ciclos de feedback de inspeção e adaptação para se adaptar a complexidade e risco. Scrum enfatiza que o processo de decisão deve ser baseado em resultados do mundo real, em vez de especulação. O tempo deve ser dividido em cadências pequenas de trabalho, conhecidas como Sprints, de uma ou duas semanas. O produto é mantido em um estado potencialmente entregável (ou seja, adequadamente integrado e testado) o tempo inteiro. No fim de cada Sprint, as partes interessadas e os membros de equipe se reúnem para uma demonstração de uma melhoria do produto e planejar seus próximos passos. Dessa forma, podemos ver Scrum como um conjunto simples de papéis, responsabilidades e reuniões que nunca mudam. Ao remover toda imprevisibilidade não necessária, é possível se adaptar à necessária imprevisibilidade da descoberta e aprendizagem típica dos projetos. Assim, as regras e práticas para Scrum – um processo simples para gerenciar projetos complexos – são poucas, diretas e fáceis de aprender. No entanto, a simplicidade do Scrum em si e sua falta de prescrição podem ser tão sensibilizantes que novos praticantes acabam em situações em que aos poucos revertem para velhos hábitos e ferramentas de gestão de projetos, produzindo resultados menos satisfatórios. Assim, para entender a base na teoria e prática do Scrum, é necessária uma mentalidade

q

que possibilite: 11 Controlar até mesmo os mais complexos projetos; 11 Gerir eficazmente os requisitos do produto desconhecidos ou mudança; 11 Simplificar a cadeia de comando com as equipes de desenvolvimento de autogestão; 11 Receber mais claras especificações e feedback de clientes; 11 Reduzir grandemente o tempo de planejamento de projeto e ferramentas necessárias; 11 Construir e lançar produtos em ciclos de 30 dias para que os clientes obtenham resultados mais cedo; 11 Evitar erros inspecionando regularmente relatórios sobre os projetos e realizar ajuste fino constantemente sobre estes; 11 Apoiar várias equipes trabalhando em um projeto em larga escala a partir de muitas 11 Maximizar o retorno sobre o investimento.

Exercício de fixação e O que você acha que precisa mudar na mentalidade da sua organização para adotar um processo de gestão de projetos ágil como o Scrum?


localizações geográficas;

15

Introduzindo um processo ágil em uma organização O Manifesto Agil estabelece uma base comum para esses processos: valorizar mais

q

os indivíduos e as interações que os processos e as ferramentas, trabalhar mais no software do que no detalhamento da documentação, colaborar mais com o cliente na negociação do contrato e responder mais rapidamente às mudanças do que seguir um plano à risca. As metodologias ágeis mais conhecidas são Extreme Programming (XP), Lean Development, Crystal e Scrum. Com o Scrum, os projetos progridem em uma série de interações mensais, denominadas sprints. Antes de cada sprint, as equipes de desenvolvimento se reúnem com o cliente, ou com o product owner, para priorizar o trabalho a ser realizado e selecionar as atividades que a equipe pode finalizar na próxima sprint. Durante a sprint, a equipe é acompanhada através de reuniões diárias (daily scrum) e, no fim das sprints, a equipe entrega um incremento do produto que pode ser potencialmente utilizado pelo cliente. O Scrum é, portanto, ideal para projetos que possuem requisitos que ou mudam constantemente ou são desconhecidos no começo do projeto e que possuam a tendência de surgir rapidamente, como projetos para web e para desenvolvimento de produtos em novos mercados.

Desenvolvedores A maioria dos desenvolvedores respondem à introdução de um processo ágil com uma

q

combinação de ceticismo, entusiasmo e otimismo cauteloso. Outros desenvolvedores, no entanto, tendem a resistir à mudança ou simplesmente iniciar o projeto sem premeditação. É importante ressaltar que ambas as reações podem causar problemas. Em geral, processos ágeis valorizam mais a produção de código do que processos orientados a planejamento. Em um processo assim, os desenvolvedores tratam a UML e outros itens que não são código como artefatos de primeira classe. Em um processo ágil, no entanto, esses itens só existem para suportar a atividade de codificação. Ao introduzir o Scrum em várias equipes de projeto, é normal encontrar programadores que passam mais tempo produzindo artefatos que não são código do que necessário. Também encontramos desenvolvedores que medem seu nível de contribuição no projeto pelo número de reuniões de que participam. Esses analistas vão além da “paralisia da análise” e ativamente buscam oportunidades para adicionar novas atividades no processo ágil, deixando-o mais complicado do que precisa ser. Em tais situações, o melhor é não intervir. Outros membros da equipe avaliarão a efetividade e o valor dessas atividades, e não as adotarão se estas não ajudarem o esforço de desenvolvimento geral da equipe.


Realizando a transição de um processo peso-pesado

16

Um número surpreendente de desenvolvedores enxerga o uso de um método ágil como uma tentativa da gestão de microgerenciá-los. Abordagens como o Scrum e o XP aceleram ciclos de projeto, e assim desenvolvedores interagem com seus gerentes mais frequentemente, mas por períodos mais curtos. Em um processo orientado a planos, um gerente pode passar até a semana inteira sem conversar com um desenvolvedor em particular, enquanto o contato diário é a norma na maioria dos processos ágeis.

q

Programadores que têm essa visão percebem as interações com seus gerentes de projeto como sendo sobre datas de entrega e prazos perdidos. Para impedir esse problema, os líderes devem constantemente demonstrar seu desejo de remover obstáculos assim que possível e evitar reclamar se uma atividade demorar mais do que o previsto. Gestores podem se surpreender, mas não devem se mostrar excessivamente críticos ao serem informados de que uma tarefa vai demorar mais do que se pensava originalmente. A transição gradual de um processo mais pesado para um processo ágil pode tornar a

q

mudança mais fácil para a equipe de desenvolvimento. Algumas equipes, em seu primeiro contato com o Scrum, ficam estagnados com a falta de ação gerada pela liberdade de não possuir um cronograma diário direcionando seu trabalho. A ideia é ajudar esses times ao definir tipos de sprint: 11 Prototipação; 11 Captura de requisitos; 11 Análise e design; 11 Implementação; 11 Estabilização. A cada reunião de planejamento, trabalha-se com as equipes para definir os artefatos que vão resultar de cada tipo de Sprint. Ao usar tipos de Sprint, introduzimos um nível de formalidade suficiente para permitir que as equipes vejam mais claramente sua função ao longo do projeto. Na medida que os times se tornam mais familiarizados com a informalidade do processo ágil, eles gradualmente abandonam o conceito de tipos de Sprint.

Scrum Escalável Quando muitas equipes trabalham no mesmo produto, eles normalmente usam um

q

mesmo Product Owner (que realmente toma decisões de negócio) e um único Backlog de Produto com requisitos orientados ao cliente. Cada equipe do Scrum deve buscar se tornar uma equipe de funcionalidades, capaz de desenvolver uma fatia completa de produto que pode ser entregue ao cliente. Quando interdependências aparecem, equipes de funcionalidade devem aprender a usar princípios da auto-organização para coordenar com outras equipes. Infelizmente, a maioria dos times não estão inicialmente acostumados com esse nível de responsabilidade, e hábitos pré-existentes de gestão e hierarquias apresentam impedimentos organizacionais. A ideia do Scrum é eliminar papéis de coordenação como gestor de projetos e PMO, pois

q

entende que eles interferem na auto-organização da equipe. O Scrum também elimina papéis ditatoriais como “arquitetos”, pois entende que as decisões técnicas devem ser tomadas por times colaborativos.

organizacional, é tentador usar algumas abordagens híbridas que combinam uma versão enfraquecida do Scrum ao mesmo tempo em que se utiliza uma gestão hierárquica tradicional. Recomenda-se que organizações maiores que estão comprometidas com valores e princípios do Manifesto Ágil aprendam sobre LeSS (Large Scale Scrum).


Enquanto um cenário de agilidade ótima requer mudanças fundamentais na estrutura

17

Atividades práticas e Cenário para escolha sobre um processo a ser adotado


Tutorial para uso de uma ferramenta Scrum (sugestão: Tuleap)

18

2 Metodologias tradicionais: vantagens e desvantagens. Filosofia por trás das metodologias ágeis. Metodologias ágeis: características, vantagens e desvantagens.

conceitos

O Scrum. Metodologias de desenvolvimento de software. Filosofia do Scrum.

Processo de software Em uma visão geral do processo/projeto de desenvolvimento de software, podemos

q

subdividi-lo em cinco fases genéricas que independem da área de aplicação, tamanho ou complexidade do projeto: 11 Especificação; 11 Projeto; 11 Implementação; 11 Validação; 11 Manutenção. Para cada uma delas, existe uma série de atividades que são executadas. O processo de software pode ser visto como um gerador de produtos, sendo o software em si o produto final – no entanto, é importante perceber que existem subprodutos gerados em cada fase. Por exemplo, no final da fase de especificação, é comum se produzir e entregar um ou mais documentos em que se detalham os requisitos do sistema. A seguir, detalharemos um pouco essas fases e suas atividades associadas.

Fase de especificação É uma das etapas iniciais do projeto, pois é onde procuram-se identificar funcionali-

q

dades, restrições, validações, interfaces e principalmente os requisitos-chave que o projeto deve cobrir. Deve haver interação com o cliente para validar todas as informações por ele passadas e com ele coletadas, a fim de que todos os requisitos sejam atendidos de maneira correta no decorrer da implementação do produto.

Capítulo 2 - O Scrum

objetivos

O Scrum

19

É composta por três atividades principais, que são executadas, independentemente dos

q

métodos utilizados, porém podem variar de acordo com o paradigma usado. As suas tarefas são: 11 Engenharia de sistema: estabelecimento de uma solução geral para o problema, envolvendo questões de tecnologia e equipamento; 11 Análise de requisitos: levantamento das necessidades do software a ser implementado – tem como objetivo produzir uma especificação de requisitos em forma de documento; 11 Especificação de sistema: descrição funcional do sistema. Pode incluir um plano de testes para verificar adequação.

Fase de projeto O projeto é finalizado quando seus objetivos propostos são alcançados e quando se

q

encontra estruturado, em termos de arquitetura, interface e técnicas. Suas atividades são: 11 Projeto arquitetural: aqui se desenvolve um modelo conceitual para o sistema, composto por módulos mais ou menos independentes; 11 Projeto de interface: onde cada módulo tem sua interface de comunicação estudada e definida. Pode resultar em um protótipo; 11 Projeto detalhado: onde os módulos em si são definidos e, possivelmente, traduzidos para pseudocódigo.

Fase de implementação Também chamada de fase de desenvolvimento ou codificação. É a fase que define como

q

os dados serão estruturados e implementados tecnicamente. Em outras palavras, é quando o projeto, que antes estava documentado em papel, passa a ser transformado para entrar em operação de fato. Linguagens de programação, técnicas e métodos – que podem variar de projeto para projeto –, contudo, atividades comuns a todas metodologias precisam ser realizadas, tais como: 11 Projeto de software: parte central do desenvolvimento, que mostra o que e como será desenvolvido; 11 Geração de código: que consiste em traduzir em linguagem de programação o que foi especificado no projeto de software.

Fase de teste Nesta fase, encontram-se as não conformidades com o que foi especificado durante a fase de especificação, com o objetivo de aumentar a qualidade do produto. Suas atividades são: 11 Teste de unidade e módulo: consiste na realização de testes para verificar a presença de erros e comportamento inadequado relacionado às funções e módulos Fundamentos do Scrum

básicos do sistema;

20

11 Integração: reunião dos diferentes módulos em um produto de software homogêneo e verificação da interação entre esses quando operando em conjunto.

q

Fase de manutenção Considerada a fase final, onde se analisa todo o produto. Tem como foco principal as

q

modificações, como correções de erros, adaptações necessárias e melhorias (novas funcionalidades não planejadas inicialmente) para evolução do software. Nessa fase, o software em geral entra em um ciclo interativo que abrange as fases anteriores. Como ocorrem alterações, a fase de manutenção abrange características das fases anteriores, porém seu enfoque é um software já existente. São quatro os tipos de modificações que podem ocorrer:

q

11 Manutenção corretiva: visa corrigir os defeitos que ocorreram durante a fase de desenvolvimento; 11 Manutenção adaptativa: modifica o software para adaptá-lo a alterações no ambiente externo; 11 Manutenção perfectiva: adiciona novas funcionalidades ao software. Essas novas especificações estão fora do escopo do projeto original e são consideradas como melhorias de produto; 11 Manutenção preventiva: assume que mudanças tanto no ambiente externo quanto de especificações vão ocorrer – portanto, já é implantado para que o impacto causado por essas alterações não afete o sistema. Para tornar o desenvolvimento de software uma atividade menos caótica, e buscando aumentar a qualidade e produtividade em seus projetos, as organizações produzem seus próprios modelos de processo de software. Assim, é impossível conceber um modelo uniforme que possa descrever com precisão o que de fato acontece durante todas as fases de produção de um software – os procedimentos utilizados são variados e as necessidades organizacionais diferem substancialmente. O que se pode dizer é que todo modelo de software deve levar em consideração as fases

q

descritas anteriormente; no entanto, cada organização organiza as fases do seu Modelo de Processo de Software de acordo com sua filosofia. Assim, um modelo, ou uma metodologia de desenvolvimento, é uma filosofia do andamento das fases – ciclo de vida – e não uma descrição de como cada atividade deve ser executada ao pé da letra. Um modelo de desenvolvimento corresponde a uma representação abstrata do processo de desenvolvimento que vai, em geral, definir como as etapas relativas ao desenvolvimento do software serão conduzidas e inter-relacionadas para atingir o objetivo do desenvolvimento – que é a obtenção de um produto de software de alta qualidade a um custo relativamente baixo.

As Metodologias de Desenvolvimento de Software são uma resposta das organizações, em especial das Software Houses, que buscavam desenvolver projetos de maneira mais organizada e profissional, à Crise do Software. Linguagens foram criadas para modelar e facilitar o produto pelo cliente e pela própria empresa desenvolvedora. A documentação gerada a partir da análise e especificação dos projetos era acompanhada por um método de desenvolvimento para suportar o processo de fabricação do software. Os métodos surgiram para dividir todo o processo em etapas e prover sua

q Capítulo 2 - O Scrum

Metodologias de desenvolvimento tradicionais: vantagens e desvantagens

melhor visualização, sempre com foco na melhor qualidade final do produto. 21

De acordo com Sommerville, metodologia de desenvolvimento é o “conjunto de práticas

q

recomendadas para o desenvolvimento de softwares, sendo que essas práticas geralmente passam por passos ou fases, que são subdivisões do processo para ordená-lo e melhor gerenciá-lo”. As metodologias consideradas tradicionais, também chamadas de “pesadas”, têm como característica marcante a sua divisão em etapas e fases bem definidas, como Análise, Modelagem, Desenvolvimento e Testes. A conclusão de cada fase gera um marco, que tipicamente refere-se um documento, protótipo do software ou versão do sistema. O foco principal dessas metodologias é a previsibilidade dos requisitos do sistema, que traz a grande vantagem de tornar os projetos completamente planejados, facilitando sua gestão, mantendo uma linha de comando e caracterizando o processo com bastante rigor. Essa previsibilidade é alcançada porque mais tempo é dedicado na fase de análise e na elaboração da documentação de planejamento. Como se pode imaginar, o controle do projeto é dificultado já que, em situações reais de projeto, sempre que se deseja alterar um requisito, ou parte do escopo, é necessário voltar ao início do projeto e reiniciar todo o processo de planejamento. As metodologias pesadas defendem que uma documentação detalhada é necessária por oferecer um embasamento maior para manutenção do software e prevenir a troca de recursos. Caso um desenvolvedor resolva sair do projeto, por exemplo, todo o projeto estará documentado e quem assumir estará munido de informações para continuar o projeto sem necessidade de perder muito tempo. Apesar de os modelos de desenvolvimento terem atendido diversos problemas originados pela Crise do Software, eles possuem limitações que na prática acabam não atendendo as necessidades de uma equipe técnica, podendo até mesmo inviabilizar os projetos de desenvolvimento em função dessas deficiências. Levando em consideração que o processo de desenvolvimento é bastante mutável, ele acaba demandando muito tempo de trabalho, pois frequentemente há o surgimento de novos requisitos por parte do cliente, tanto funcionais como não funcionais, assim como a não conformidade de algumas solicitações resulta na necessidade de alteração constante na documentação e no produto em si.

Vantagens e desvantagens As vantagens principais das metodologias de desenvolvimento tradicionais são: redução de riscos envolvendo custos a um único incremento e aceleração do tempo de desenvolvimento do projeto como um todo, visto que os desenvolvedores trabalham de maneira mais eficiente quando buscam resultados objetivos. Quando se segue uma metodologia moderna como o Rational Unified Process (RUP), as metodologias tradicionais incorporam uma série de outros benefícios, tais como:


11 Gerenciamento de requisitos: para garantir que as mudanças nos requisitos, que

22

são comuns após o início do desenvolvimento, sejam administradas em um projeto desenvolvimento iterativamente; 11 Integração de elementos: quando cada módulo desenvolvimento é integrado ao sistema como um todo, evitando que a atividade de “juntar as partes” seja um problema no fim do projeto;

q

11 Gerenciamento de riscos: a cada iteração, é possível analisar pontos críticos e pla-

q

nejar estratégias para não perder tempo durante o desenvolvimento; 11 Testes: são realizados no fim de cada módulo, permitindo que erros e não conformidades possam ser tratados ainda dentro do mesmo ciclo. Embora as abordagens tradicionais tenham surgido como um recurso para empresas desenvolvedoras de software, são diversas as críticas e limitações que surgiram. Além das já citadas anteriormente, o enorme número de documentos exigidos em cada atividade dificulta a implantação por empresas que não possuem recursos para criar e gerenciar tal documentação. Com isso, são muito poucas as pequenas organizações que conseguiram implantar processos pesados e tradicionais com sucesso – eles são mais indicados para grandes equipes de desenvolvimento.

Exercício de fixação e Que metodologias de desenvolvimento são utilizadas na sua organização? Você enxerga vantagens e desvantagens no seu uso? Quais?

Metodologias de Ágeis de Projetos Na última década, um novo segmento da comunidade da Engenharia de Software vem

q

defendendo processos simplificados, com foco nas pessoas que compõem o processo e, principalmente, no programador. Também chamada de metodologia de desenvolvimento leve, as metodologias ágeis propõem a execução dos passos do projeto em paralelo, e sua principal característica é o menor esforço à documentação. A documentação do projeto tende a ser simplificada e orientada pelo código-fonte. A crítica mais frequente às metodologias tradicionais é que são burocráticas. Para seguir a metodologia, é produzida grande quantidade de material, que faz diminuir a velocidade de desenvolvimento.

Arquitetura / Projeto Levantamento Requisitos

Prototipação

Validação do cliente

Implantação

Testes

Desenvolvimento Capítulo 2 - O Scrum

Figura 2.1 Fases de uma metodologia tradicional.

23

O novo advento ágil iniciou com alguns especialistas da indústria do desenvolvimento de

q

software, que se uniram para encontrar valores e princípios relacionados ao desenvolvimento, que escreveram o Manifesto Ágil. Esse manifesto destacava quatro valores: 11 Software funcional em vez de documentação detalhada; 11 Colaboração ao cliente em vez de negociação de contratos; 11 Indivíduos e iterações em vez de somente processos e ferramentas; 11 Responder às mudanças em vez de seguir um plano minuciosamente detalhado inicialmente.

Software Funcional em vez de Documentação Detalhada A ideia dos projetos ágeis é medir o progresso do projeto em função da quantidade de

q

software funcional existente, em vez de considerar um grande volume de documentos e a fase do processo em que o projeto se encontra como fatores determinantes para o progresso atual. Considera-se que 30% do projeto estão prontos quando 30% das funcionalidades necessárias estiverem funcionando. A documentação de um projeto é extremamente necessária para o seu sucesso, e projetos ágeis reconhecem isso. O código não é o melhor meio de comunicação entre o racional e a

entanto, não é contra documentação. Ele diz claramente: “Nenhum documento é gerado a não ser que seja necessário e significante.”

estrutura do sistema. Documentação legível é necessária para manter o sistema e fazê-lo evoluir; porém, o excesso de documentação é pior do que a falta dela. O manifesto, no entanto, sugere que somente a documentação necessária seja gerada, e que esta seja sempre atualizada com o código gerado. Uma documentação enxuta promove integração na equipe em função da transferência de conhecimento sobre o projeto que será realizado paralelamente com o código, uma vez que este não permite duplas interpretações. De nada adianta ter uma extensa gama de documentos que demandam muito tempo para serem gerados, depois lidos e, principalmente, para mantê-los atualizados. A documentação tem o papel de orientar todos os membros envolvidos no projeto. Documentações e papéis não contam como entregas, pois não satisfazem a necessidade do cliente. O cliente escolhe se vai implantar o sistema incompleto, se vai apenas testá-lo para definir novas funcionalidades ou se vai apenas testá-lo para encontrar não conformidades com aquilo que deseja.

Colaboração ao cliente em vez de negociação de contratos As metodologias leves enfatizam o relacionamento próximo com o cliente, exigindo que

q

sua participação seja dedicada, inteligível, colaborativa e efetiva. Esse envolvimento favorece caso os requisitos sejam imprevisíveis e sujeitos a mudanças; porém, havendo Fundamentos do Scrum

pontos de vista diferentes entre os desenvolvedores e cliente, possivelmente ocorrerão

24

conflitos, riscos e negligências. Esses riscos podem ser reduzidos através de métodos guiados por documentação, planejamento e revisão na arquitetura. As metodologias ágeis abordam o desenvolvimento de uma lista de prioridades e funcionalidades, para que o cliente defina e classifique o que é prioritário para ele. Tal definição é atualizada constantemente no início de cada ciclo.

lO Manifesto Ágil, no

Indivíduos e iterações em vez de somente processos e ferramentas A experiência e capacitação dos profissionais no desenvolvimento do projeto afetam

q

diretamente na qualidade do produto e no bom desempenho da equipe do projeto. Ter excelentes profissionais, no entanto, não é uma garantia de sucesso, pois eles dependem diretamente do processo. Um processo de má qualidade pode fazer com que os melhores desenvolvedores não sejam capazes de usar todo o seu talento.

Além da combinação do processo adequado com bons profissionais, é preciso que toda

q

a equipe possa interagir perfeitamente entre si. Comunicação é mais importante que simples talento para programação. Um desenvolvedor que consegue se relacionar bem e trabalha bem em equipe tipicamente é mais produtivo que um excelente programador que só consegue trabalhar sozinho. Comunicação é o principal valor dos Processos Ágeis e é a maneira mais rápida de se obter informações. Além disso, as responsabilidades e decisões são compartilhadas por toda a equipe, mostrando que todos estão envolvidos no processo e trabalhando em grupo. Assim, para a seleção dos funcionários envolvidos, deve-se levar em consideração o perfil, a competência, o comportamento individual e em equipe, e o profissional deve ser comunicativo. Obviamente, uma organização em transição deve ser capaz de treinar os seus profissionais – no entanto, é fundamental que todos estejam motivados, seja com o apoio de outros membros da equipe ou com o material e equipamento. Outra característica é a iteração. Após cada iteração, deve ser possível apresentar um protótipo para o cliente e coletar o seu retorno. Como já dito anteriormente, nas metodologias ágeis, é criada uma lista de prioridades de funcionalidades de acordo com o que o cliente julga como prioritário para ele. Tal lista é atualizada constantemente a cada iteração, permitindo acrescentar novos requisitos e mudanças, ajustando as prioridades. Dessa maneira, o gerente de projeto pode garantir que a equipe de desenvolvimento esteja trabalhando de acordo com os aspectos que o cliente considera mais significativo. Um processo ágil consiste em entregas rápidas e constantes. Entrega-se no início do

q

projeto o primeiro sistema, ou parte do sistema, já com algumas funcionalidades desenvolvidas, sendo que novos pacotes de funcionalidades continuam sendo desenvolvidos e integrados ao módulo anterior no decorrer do tempo.

Responder à mudanças x planos detalhados Assumindo que mudanças de especificação sempre vão ocorrer em qualquer projeto,

q

é possível afirmar que tais projetos terão mais sucesso quando se adaptarem a essas mudanças. Flexibilidade é fator fundamental para o sucesso em projetos, pois determina elas apareçam durante o desenvolvimento e os testes. Os participantes não temem as mudanças, pois assumem que elas são indicadores de que a equipe está aprendendo sobre o sistema, tentando atingir a satisfação do cliente.


o quanto estes são adaptáveis. Processos ágeis são receptivos a mudanças, mesmo que

25

Acerca da existência de planos, o Manifesto Ágil não é contra. Ele defende que planos sejam esboçados, mas que, como não é possível prever o futuro, as visões desses não devem ir muito longe. O planejamento, portanto, deve ser de curto prazo, em virtude das alterações que

q

invariavelmente vão aparecer. Na verdade, é muito difícil seguir planos de longo prazo à risca, então faz pouco sentido concentrar muito esforço nisso. Uma dica importante quando se identifica que o projeto será muito extenso é dividi-lo em fases, tornando mais fácil gerenciá-lo e executá-lo.

Velocidade e qualidade Ora, para garantir um desenvolvimento rápido, é necessário um software limpo e mais

q

robusto possível. Isso porque as equipes de projetos ágeis são orientadas a desenvolver códigos com qualidade. Assim, o que deve ser mantido nos Processos Ageis é a velocidade do desenvolvimento. De nada adianta iniciar um projeto desenvolvendo-o rapidamente se essa velocidade declinar com o tempo, pois isso pode iludir o cliente, causando a ele uma impressão de falsa velocidade, além de estressar os desenvolvedores e diminuir a qualidade final do produto, quebrando os principais valores dos Processos Ágeis.

Vantagens e desvantagens As vantagens da Metodologia de Desenvolvimento Ágil são:

q

11 Receptividade às mudanças; 11 Orientada às pessoas, não aos processos; 11 Complementada por checagens dinâmicas; 11 Equipes de desenvolvimento menores; 11 Com foco para o compartilhamento do conhecimento; 11 Feedback praticamente instantâneo; 11 Versões úteis; 11 Visão clara de riscos e incertezas na arquitetura do projeto; 11 Poderá ser considerada uma solução de valor agregado; 11 Uma versão poderá ser entregue ao cliente em um tempo menor do que uma versão desenvolvida com a metodologia pesada; 11 São adaptáveis, favorecendo o aprendizado dos envolvidos, aprimorando o projeto e formando assim um ciclo de projeto. O gerente do projeto não precisa desenvolver um projeto pesado de documentação – pelo


contrário, ele só precisa ter foco no absoluto necessário, como a programação das tarefas.

26

No entanto, a grande limitação das metodologias ágeis é a maneira como elas manipulam grandes equipes. Metodologias pesadas e seus métodos pré-guiados se adaptam melhor às dificuldades de comunicação, algo extremamente complexo, entre pessoas em projetos que contam com mais de vinte desenvolvedores.

Como a prioridade máxima das metodologias ágeis é satisfazer o cliente, fornecendo o mais

q

rapidamente possível e continuamente novas funcionalidades para o seu software, em grandes sistemas essa filosofia pode resultar em retrabalho por falta de escala em sua arquitetura. Tradicionalmente, os objetos da metodologia pesada como previsibilidade, repetição e otimização são características de um desenvolvimento seguro. Portanto, seria displicente a aplicação da modelagem ágil em sistemas críticos de manutenção vital, por exemplo.

Exercício de fixação e Você acredita que a sua organização e os seus clientes se beneficiariam da adoção de uma metodologia como o Scrum?

Histórico do Scrum O Scrum foi a princípio concebido como um estilo de gerenciamento de projetos em

q

empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka, no artigo “The New Product Development Game” (Harvard Business Review, janeiro-fevereiro 1986). Nesse artigo, eles comparavam equipes de alto desempenho e multifuncionais com um jogo de rugby e concluíram que equipes são formadas de menores e equipes trabalhando com sucesso em direção a um objetivo comum. Os autores notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram essas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). Em meados de 1983, seguindo a mesma linha de Nonaka e Takeuchi, a metodologia começou a ser aperfeiçoada por Jeff Sutherland, vice-presidente de engenharia da Easel, que enquanto trabalhavam em construir uma ferramenta de Object Oriented Analysis and Design (OOAD) no produto smalltalk, percebeu que seu time de software também precisava de uma versão melhorada de desenvolvimento rápido de aplicação. O seu objetivo era um processo similar ao Scrum, de curtas interações, onde o CEO da Easel conseguisse ver código funcionando do que diagramas Gantt. Seus procedimentos e ferramentas para medir produtividade e comparar diferentes estratégias foram fundamentais na criação do Scrum. Apesar de a metodologia ter sido iniciada pelos autores supracitados, no ano de 1995, a documentação da metodologia foi publicada por Ken Schwaber com a ajuda de Jeff, que se empenharam para sintetizar o que tinham aprendido através dos anos e criaram uma nova Scrum e ajudou a implantá-lo no desenvolvimento de softwares em todo o mundo. O objetivo de Ken Schwaber durante todo esse período era auxiliar sua empresa, a Advanced Development Methods, Inc. a aprimorar seu processo de desenvolvimento de software com o objetivo de melhorar a produtividade de sua equipe. Após uma extensa análise de como fornecedores de softwares bem-sucedidos e independentes produziram seus produtos, ele concluiu que os processos de desenvolvimento desses fornecedores eram bastante análogos, os quais requeriam constantes verificações e adequações.

Toyota, uma grande influência para o Scrum Como a maioria dos termos do Scrum estão presentes nos processos da Toyota, essa empresa, sem intenção, acabou contribuindo para o desenvolvimento da metodologia. A própria missão da organização reflete um dos valores principais do Scrum: “Contribuir com o crescimento da economia das comunidades dos Estados Unidos e para estabilidade e bem-estar dos membros da equipe.” O ponto principal parece ser trazer benefícios para as


d

O primeiro artigo sobre o tema foi “Scrum and the Perfect Storm”, publicado na revista OOPSLA pela Object Management Group (OMG).

metodologia, a qual chamaram de Scrum. Em 1995, Ken Schwaber formalizou a definição de

pessoas, uma proposta distinta da maioria das empresas americanas. 27

Conforme já explicamos anteriormente, o foco do Scrum está nas pessoas. A metodologia trabalha para melhorar a vida de todos os envolvidos no projeto – principalmente os desenvolvedores de software. Um segundo foco é adicionar valor aos clientes, já que o Scrum é um processo de adição de valor, com foco no cliente. É interessante que o Scrum por si só está construindo comunidades de práticas, através de um programa de treinamento para certificação ScrumMaster. Hoje há milhares de certificados ao redor do mundo – estima-se cerca de 20 mil certificados, e cerca de 40 mil ScrumMasters não certificados atuando em projetos de Scrum no mercado. Normalmente, tem-se uma tendência em abrir mão da variável custo para obter qua-

q

lidade, ou abrir mão da qualidade para se obter o objetivo do projeto em um tempo menor. É isso que se chama de restrição tripla de projetos, composto pelas pontas: “custo, qualidade e prazos”, conforme mostrado na figura 2.2. Essa decisão ainda é um paradigma forte nas principais e na mente dos desenvolvedores: a tendência de despriorizar um vértice para conseguir otimizar o outro. Qualidade

Custo

Figura 2.2 Restrição tripla em projetos.

Prazo

Porém, a filosofia da Toyota vai de encontro a isso. A empresa trabalhou para quebrar

q

a restrição tripla como um triângulo de ferro e uniu todas essas pontas, buscando qualidade, entrega rápida, variedade de produtos e preço baixo. É nesse sentido que a Toyota e o Scrum caminham juntos – o sistema da Toyota é baseado na quebra da restrição tripla, buscando maximizar todas as variáveis da restrição tripla ao mesmo tempo, reduzindo custos, tempo e barreiras funcionais através de um processo interativo que inspeciona, junto com o cliente, cada passo do processo, para alcançar um resultado final com qualidade.

Exercício de fixação e Como eliminar a restrição tripla na sua organização? Enfrentar e alinhar a gestão e o controle da estrutura do cliente são as partes mais difíceis do Scrum. A equipe deve ser auto-organizada, e isso é mais fácil de conseguir em organizações emergentes, pois estas têm uma facilidade maior de se auto-organizar


através da ação local. Caso se pare para reparar as pessoas na linha de frente, geral-

28

mente são as que estão no campo, e, portanto, detêm mais conhecimento do negócio. Na Toyota, isso ocorre entre vendedores de carros ou nas linhas de montagem. É lá que as coisas acontecem e surgem, e assim permitem a distribuição do conhecimento e das ações para desenvolver os projetos. Da mesma forma, no contexto do Scrum, a equipe deve ser formada de maneira a permitir que se auto-organize também. E esse é o segredo do Scrum. Um projeto que utiliza a metodologia tem de ser capaz de formar um time que se auto-organize.

q

Takeuchi e Nonaka argumentam que há alguns sinais que podem ser identificados para

q

dizer se uma equipe está se auto-organizando: 1. Verifique se a equipe está localizada, tem um objetivo e senso comum. É possível descobrir isso respondendo às perguntas: 22 Os membros da equipe se sentem totalmente responsáveis? 22 Há alguém no caminho atrapalhando o processo? 22 Os membros da equipe estão completamente envolvidos e com foco no projeto? 22 Os membros da equipe sabem o que têm de fazer? 22 Os membros da equipe sabem por que estão ali? 22 A equipe é independente? 2. Verifique se há senso comum, ou seja, se cada membro da equipe está com foco no sucesso da equipe, ao invés do seu próprio avanço pessoal na empresa. Caso isso não ocorra, a equipe não se auto-organizará. 3. A terceira, denominada polinização, é fazer com que membros mais experientes ajudem membros menos experientes. Pessoas que têm alguma especialidade estão compartilhando conhecimento com os outros?

Exercício de fixação e Você acredita ser possível ter uma equipe auto-organizável na sua organização? Qual o contexto para possibilitar tal auto-organização? Em alguns casos, o trabalho de remover a gestão é árduo – no entanto, tornar os partici-

q

pantes independentes e com liberdade colabora para que o projeto tenha um resultado de sucesso. A perspectiva diversificada na Toyota e no Scrum vem dos times de funcionalidade múltipla: quando a Toyota começou a desenvolver o projeto Prius, trouxeram um engenheiro chefe que não sabia nada sobre o projeto. Por desconhecer o projeto, ele precisava montar uma equipe com os melhores e mais capazes membros da organização, reuni-los em uma sala para que eles o dissessem o que fazer. Mesmo sendo o engenheiro o mais experiente do grupo, ele precisava deixar que o projeto se desenvolvesse a partir daquela equipe diversificada – uma característica típica do Scrum. No Scrum, todos são parte do processo, a equipe tem uma estrutura vertical e, portanto, todos estão no mesmo patamar, trabalhando juntos: gerentes, clientes, pessoal da instalação, suporte, entre outros.

O nome Scrum foi inspirado em uma jogada do Rugby – a figura 2.3 mostra como é um Scrum no Rugby. Essa analogia feita entre uma jogada de Rugby e o Scrum tem dois fundamentos: o senso de equipe e as constantes reuniões em círculo durante o jogo.

q Capítulo 2 - O Scrum

Origem do nome

29

Senso de equipe O Scrum no Rugby consiste em uma equipe de oito jogadores abraçados, que realizam

q

uma força, onde o objetivo é empurrar o outro time. Essa jogada só é eficaz quando todos os jogadores fazem força ao mesmo tempo e na mesma direção, fazendo com que a soma das forças individuais sejam maiores que as do time adversário, e consigam assim pegar a bola. Podemos concluir que o desenvolvimento de um software realmente se tornou um esporte em equipe. O estilo de “corrida de revezamento” aplicado ao desenvolvimento de produtos pode conflitar com o alcance do objetivo final.

Essa corrida em estilo holístico, onde a equipe busca, como em um jogo de Rugby, de forma integrada, chegar ao gol, com passes de bola, pode servir melhor às atuais necessidades competitivas.

Reuniões constantes No jogo de Rugby, os jogadores se organizam em círculo para planejar a próxima jogada. É uma forma de mostrar que o projeto deve ser conduzido em pequenos círculos, mas com uma visão de longo prazo, que é ganhar o jogo. O mesmo ocorre na metodologia


Scrum: cada interação é uma forma de recomeçar a partida reunindo todos os jogadores

30

após um incidente ou quando a bola sair de campo. A ideia básica é reunir os desenvolvedores e deixar o jogo continuar acontecendo. A Metodologia Scrum apenas estabelece conjuntos de regras e práticas de gestão que devem ser adotadas para garantir o sucesso de um projeto. No entanto, esse método não requer nem fornece qualquer técnica ou método específico para a fase de desenvolvimento de software.

q

Figura 2.3 Exemplo de Scrum.

O processo Ken Schawber defende que Scrum não é uma metodologia em si, mas um framework.

q

Scrum não vai dizer exatamente o que fazer, mas dar um conjunto de diretrizes que podem ser seguidas e adaptadas para uma realidade específica do projeto. Na concepção desse autor, Scrum é enquadrado como um processo para gerenciamento de projetos ágeis. De maneira semelhante, não vai resolver todos os problemas, mas, se bem adequado à realidade de projeto, certamente os problemas serão mais facilmente identificados. Para Martins, “Scrum é um processo bastante leve para gerenciar e controlar projetos de desenvolvimento de software e para criação de projetos de produtos. O Scrum segue a filosofia iterativa e incremental, se concentrando no que é realmente importante: gerenciar o projeto e criar um produto que acrescenta valor para o negócio. O valor decorre da funcionalidade propriamente dita, do prazo em que ela é necessária, do custo e da qualidade”. Ou seja, a abordagem do Scrum é oposta à do modelo em cascata, já que inicia a análise

q

assim que alguns requisitos estão disponíveis. Depois que alguma análise foi realizada, inicia-se rapidamente os trabalhos de projeto técnico (design), e assim por diante. Em outras palavras, o projeto trabalha em pequenos ciclos de cada vez, até a conclusão do projeto final. Essa abordagem pode ser chamada de iterativa, e cada iteração consiste na captura de requisitos, um pouco de análise, um pouco de design e mais alguma programação e testes, culminando em um ciclo iterativo com várias entregas.

Empírico Segundo Cruz, existem dois tipos de processos: definidos e empíricos. Processos defi-

q

nidos determinam o que deve ser feito, quando e como. Para um mesmo conjunto de variáveis de entrada, podemos esperar o mesmo resultado sempre. Um exemplo bem conhecido de processo definido é a metodologia RUP. De acordo com Highsmith (2004), um processo de desenvolvimento de software extremamente bem definido tem uma probabilidade de sucesso drasticamente reduzida quando utilizado no desenvolvimento de um produto. O Scrum utiliza uma implantação de um controle descentralizado que lida de forma eficiente com situações menos previsíveis, o que aparece como uma possível solução para atacar esse problema. Ora, de acordo com Schwaber (2004), o principal objetivo do Scrum é o desenvolvimento de sistemas de software envolvendo uma porção de várias técnicas e de ambiente, como requisitos, tecnologia e recursos, que podem mudar durante o processo. O foco desse método é encontrar uma maneira de os membros da equipe trabalharem para produzir o sistema de forma flexível e em ambiente passível de sofrer mudanças constantes – o resultado desse trabalho deve ser um sistema de software realmente útil para o contratante.

definidos não forem adequados devido à complexidade do projeto, ou seja, sempre que não se conheçam todas as variáveis de entrada para que se possa estabelecer um processo que pode ser repetido(com a mesma saída sempre), o Scrum é um exemplo deste. O Scrum é assim o mais perplexo e paradoxal processo para o gerenciamento de projetos complexos, mesmo sendo um método incrivelmente simples. Antes de mais nada, não é um método prescritivo, ou seja, não descreve o que se deve fazer em cada

q


Nesse sentido, os processos empíricos devem ser utilizados sempre que os processos

circunstância. É usado para trabalhos complexos nos quais é impossível predizer tudo o que vai acontecer durante o desenvolvimento do sistema de software.

31

De acordo com Beedle (2001), Scrum é um método de desenvolvimento ágil que procura uma forma de lidar com o caos, em detrimento a um processo bem definido, cuja função primária é ser utilizado em gerenciamento de projetos de desenvolvimento de sistemas de software. Ele tem sido utilizado com sucesso para esse fim e pode ser utilizado em qualquer situação em que um grupo de pessoas precise trabalhar juntas para atingir um objetivo comum.

Iterativo e incremental Em virtude da complexidade, tamanho, mudanças de requisitos, urgência e necessidade

q

de demonstrar valor mais rápido para o cliente, fica quase inconcebível desenvolver software utilizando o modelo cascata, ou seja, desenvolver software de uma única vez. A metodologia considera um modelo iterativo e incremental por uma questão de estratégia de planejamento. O modelo segue uma filosofia: dividir para conquistar, onde o projeto é divido em blocos, em ciclos, onde a cada iteração é feito um novo incremento (parte do software funcional) até completar o software. Para esclarecer os conceitos de incremental e iterativo, segue uma figura retirada de um trabalho da Agile Way, um portal sobre metodologias ágeis. Nela, podemos ter uma ideia melhor do que significam esses conceitos. Com respeito ao conceito de incremental, a cada ciclo vai aumentando e no final completa-se o objetivo. Com respeito ao conceito de iterativo, a cada ciclo melhora-se o trabalho, chegando a um objetivo com mais qualidade.

Entrega 1

Entrega 2

Entrega 3

Plano incremental

Plano de iteração

Figura 2.4 Incremental e iterativo – diferenças.

Fases do Scrum


Basicamente, a metodologia Scrum é dividida em três fases simples, que se repetem a cada ciclo: planejamento, desenvolvimento e encerramento. 11 Planejamento: consiste na análise e definição de requisitos de uma nova funcionalidade requerida pelo cliente para o sistema, baseado na necessidade do negócio do cliente e no projeto do sistema como um todo. Em seguida, é realizada a estimativa de tempo e custo do novo desenvolvimento. Após a aprovação do cliente, tal funcionalidade segue o fluxo para a fase seguinte; 11 Desenvolvimento: consiste no desenvolvimento de fato de uma nova funcionalidade, respeitando o tempo, requisitos exigidos e nível de qualidade pré-definida na fase 32

anterior;

q

11 Encerramento: preparação para a entrega da funcionalidade planejada e desenvol-

q

vida nas fases anteriores, consistindo nas atividades a seguir: 22 Teste unitário; 22 Teste integrado; 22 Elaboração de documentação de usuário; 22 Treinamento.

Tamanho de projetos Scrum é uma metodologia que se aplica a projetos de qualquer tamanho, realizando uma avaliação correta do ambiente em evolução. Adapta constantemente o “caos” de interesses e necessidades, e é indicado e utilizado para o desenvolvimento de software em ambientes complexos, onde os requisitos mudam com certa frequência, sendo o caminho utilizado para aumentar a produtividade nesses tipos de sistemas.

Atividades práticas e Cenários para levantamento de requisitos A partir de requisitos, escrever User stories. Cenários (Sprint previamente finalizada) para cálculo de Burndown a partir do Tuleap. Cenários (idem) para cálculo de Velocidade.


É importante o instrutor explicar a diferença e importância dessas métricas.

33

34


3 Entender a Metodologia do Scrum; Papéis, Cerimônias e Artefatos do Scrum

Scrum Master, Product Owner; Daily Scrums, Reuniões de Planejamento e Reuniões de Revisão; Product Backlog, Sprint Backlog e Gráfico de Burndown

Antes de descrever o passo a passo da metodologia, precisamos conhecer os insumos

conceitos

q

que a compõem. Dessa forma, torna-se possível familiarizar-se com os termos que serão utilizados. A metodologia é formada por Papéis, Cerimônias e Artefatos, e cada um deles se subdivide em insumos menores, conforme a lista a seguir: 11 Papéis: 22 Product Owner (Proprietário do produto); 22 Scrum Master; 22 Equipe de Desenvolvimento; 22 Cliente. 11 Cerimônias: 22 Reunião de planejamento do Sprint; 22 Reuniões diárias de Scrum (Daily); 22 Reunião de Revisão do Sprint. 11 Artefatos: 22 User Stories (História); 22 Planning Poker; 22 Sprint; 22 Product Backlog; 22 Sprint Backlog; 22 Burndown Chart.

Capítulo 3 - A metodologia

objetivos

A metodologia

35

Papéis Como já mencionado anteriormente, a metodologia define como a equipe deve trabalhar.

q

O primeiro passo para o desenvolvimento baseado no Scrum é definir quem vai fazer o quê. A metodologia define dois tipos de papéis básicos: 11 Principais; 11 Auxiliares. Papéis principais são os profissionais que fazem parte da equipe do fornecedor – ou seja, são aquelas pessoas comprometidas com o projeto no processo do Scrum. Produzem o produto em si, o objetivo final do projeto. Já os papéis auxiliares são aqueles sem papel formal e nenhum envolvimento frequente no processo Scrum, mas que ainda precisam ser levados em conta.

Product Owner Podemos dizer que o Product Owner é um analista de negócio e um profissional com

q

conhecimento nas duas pontas: no negócio do cliente e na tecnologia. Tem como principal objetivo representar os interesses do cliente com a equipe técnica. Funciona,

l

portanto, como uma interface entre o cliente e a equipe de desenvolvedores, e deve estar sempre em contato com o cliente para saber o que precisa ser feito no projeto para satisfazer o negócio.

Veremos esse termo em detalhes no tópico de Artefatos.

Juntamente com os outros envolvidos, ele é o responsável por listar as prioridades e os requisitos, além de revisar e aprovar as entregar no final de cada Sprint. Mais detalhadamente, ele tem as seguintes responsabilidades:

q

11 Definir os requisitos e funcionalidades de produto; 11 Decidir sobre data de lançamento e término; 11 Ser responsável pela rentabilidade do produto (ROI); 11 Priorizar as funções de acordo com a necessidade atual do cliente; 11 Ajustar recursos e priorizar tarefas a cada ciclo, geralmente de 30 em 30 dias, como necessário; 11 Aceitar ou rejeitar o resultado do trabalho.

Scrum Master É o líder da equipe de desenvolvimento, geralmente o programador ou analista de sistemas mais experiente da equipe. É responsável por garantir a aplicação das práticas do Scrum, assim como repassar os ensinamentos da metodologia para os outros membros do projeto. Gerencia e delega as atividades que foram definidas durante o planejamento


pelo Product Owner. Suas principais responsabilidades são: 11 Assegurar-se de que a equipe de desenvolvimento funciona plenamente e é produtiva, intermediando a comunicação entre a equipe e o Product Owner; 11 Assegurar-se de que a metodologia está sendo seguida; 11 Conduzir reuniões diárias e reuniões de planejamento de atividades; 11 Revisar atividades, tendo conhecimento das que foram concluídas e das que foram iniciadas; 36

q

11 Identificar novas tarefas, priorizá-las e alterar qualquer estimativa que possa ter

q

mudado. Isso permite a ele atualizar sempre o Burndown Chart (veremos esse termo em detalhes no tópico de Artefatos); 11 Tomar ações para tarefas em aberto e computar quantas tarefas estão em aberto com o objetivo de minimizá-las o máximo possível para garantir um trabalho eficiente; 11 Avaliar as pendências e obstáculos que causam prejuízos ao andamento do projeto. Essas pendências e obstáculos devem ser listados, para receber níveis de prioridade e ser acompanhados com o objetivo de minimizá-los o mais rapidamente possível, a fim de serem solucionados. Um plano de ação deve ser implementado de acordo com a ordem de prioridade desses impedimentos. Alguns podem ser resolvidos pelo time, outros através de vários times, e outros precisam do envolvimento da gerência ou até do cliente, pois podem ser problemas que não são da alçada da equipe e, portanto, podem correr o risco de causar um bloqueio no andamento do projeto; 11 Efetuar a gestão das pessoas, percebendo e resolvendo problemas pessoais ou conflitos entre os integrantes do time do desenvolvimento Scrum. Caso o Scrum Master não consiga resolver algum tipo de problema, deve solicitar ajuda à gerência ou do departamento de Recursos Humanos. Alguns estudos apontam que 50% dos problemas de desenvolvimento acontecem por razões pessoais, então o Scrum Master precisa estar sempre atento ao time para maximizar a produtividade e motivação da equipe.

Equipe de desenvolvimento Também conhecida como Scrum Team, correspondem aos membros encarregados por

q

realizar as atividades de projeto. Ou seja, são aqueles que vão efetivamente colocar a mão na massa para que o projeto se concretize. Suas principais atividades são organizar e gerenciar suas próprias atividades. e geralmente estão integralmente dedicados ao projeto. Dependendo da complexidade do software, um projeto pode ter mais do que uma equipe de desenvolvimento. No entanto, a troca de equipe só deve ocorrer na mudança de ciclo. Suas principais características são: 11 Multifuncional e auto-organizável; 11 Pequenas e multidisciplinares, com até 10 participantes; 11 Definem metas a cada Sprint, junto com o Scrum Master, e especificam seus resultados de trabalho; 11 Têm como responsabilidade principal entregar o bloco (Sprint) no tempo determinado e com o mínimo de erro possível; 11 Têm o dever de respeitar as regras da metodologia;

Como já falamos, por ser multifuncional, a equipe de desenvolvimento Scrum deve ser composta por profissionais dos mais variados perfis, incluindo, mas não se limitando a: 11 Programadores; 11 Testadores; 11 Analistas; 11 Desenvolvedores de interfaces; 11 Administradores de bancos de dados.


11 Devem sempre manter o senso de equipe.

37

Na prática, a diferença entre uma equipe não multifuncional é que na primeira, como

q

podemos visualizar na figura 3.1, o projeto anda mais rápido, pois profissionais de diferentes especialidades trabalham juntos para cumprir uma tarefa. O sentido de equipe é exatamente esse – os membros compensam entre si as competências e as carências, em um aprendizado mútuo e contínuo.

Time não Multifuncional Sprint 4

Sprint 1

Sprint 2

Sprint 3

Análise

Código

Testa

Análise

Código

Testa

Análise

Código

Testa

Sprint 4

Sprint 5

Sprint 5

Time Multifuncional Sprint 1

Sprint 2

Sprint 3

Análise

Análise

Análise

Código

Código

Código

Testa

Testa

Testa

Cerimônias A equipe também tem a responsabilidade de participar das cerimônias. Essas são

Figura 3.1 Diferença de velocidade entre equipes não multifuncionais e multifuncionais.

q

reuniões que ocorrem em diversos momentos durante o projeto. O método é dividido sucintamente em basicamente três cerimônias principais, a saber: 11 Reuniões de Planejamento da Sprint (Planning Meetings); 11 Reuniões Diárias de Scrum (Daily Meetings); 11 Reunião de Revisão da Sprint (Sprint Retrospective). Esses três tipos de evento caracterizam bem o ciclo de vida de cada Sprint, que possui início, meio e fim.

Reunião de planejamento da Sprint (Planning Meeting) Fundamentos do Scrum

Os participantes da reunião de planejamento são:

38

11 Product Owner; 11 Cliente (e outras quaisquer partes interessadas, como diretores ou representantes do cliente); 11 Scrum Master; 11 Equipe de desenvolvimento.

q

Também chamada de Scrum Planning Meeting, a reunião de planejamento é a primeira

q

reunião do projeto, e seu objetivo é realizar o planejamento da Sprint, definindo escopo, estimativa e importância. Segundo Cockburn (2001), essa reunião é crítica para o sucesso do projeto, pois se não for devidamente planejada e bem realizada, pode ocasionar problemas com atrasos, estimativas mal realizadas e outros problemas típicos. Em uma primeira etapa da reunião de planejamento da Sprint, o Product Owner trabalha

q

em conjunto com o cliente para levantar todas as funcionalidades que o cliente deseja e assim criar uma lista de funcionalidades requeridas. Em seguida, são selecionadas as funcionalidades que devem ser entregues na próxima Sprint e definidas as prioridades de cada funcionalidade de acordo com as necessidades do cliente. Essa lista final é o que chamamos de Product Backlog, e é a base da segunda parte da reunião. Na segunda etapa, o Scrum Master trabalha junto com o Product Owner e a Equipe de Desenvolvimento para determinar como as tarefas devem ser executadas e o tempo que cada funcionalidade do Product Backlog demandará para ser concluída. Isso ajuda o Product Owner a definir prazos reais para o projeto e permite acompanhar o andamento do projeto durante todo o período de desenvolvimento. Após a confecção do Product Backlog com as prioridades e prazos relacionados, a reunião continua apenas com Scrum Master e a Equipe de Desenvolvimento. O Scrum Master quebra cada tarefa em pequenas tarefas, delegando-as aos respectivos profissionais. Assim, a reunião de planejamento da Sprint tem duas partes. As primeiras quatro horas são gastas com o Product Owner apresentando a maior prioridade do Product Backlog para a equipe, incluindo questionamentos da equipe sobre o conteúdo, propósito, significado e as intenções do Product Backlog. Quando a equipe sabe o suficiente, mas dentro dessas primeiras quatro horas, a equipe seleciona tanto do Product Backlog quanto acredita que pode se transformar em um incremento completo de funcionalidade do produto potencialmente utilizável até o final do Sprint. Durante a segunda parte de quatro horas de reunião de planejamento do Sprint, a equipe planeja, de fato, a Sprint. Como a equipe é responsável pela gestão do seu próprio trabalho, ela precisa de um plano provisório para iniciar a Sprint. As tarefas que compõem esse plano são colocadas em um Sprint Backlog; as tarefas dessa Sprint Backlog vão emergir à medida que a Sprint evolui. No início do segundo período de quatro horas da reunião de planejamento do Sprint, na verdade já se considera que a Sprint começou, e o relógio está correndo em direção à Sprint de 30 dias. Como a equipe de desenvolvimento é auto-organizada, deve informar as horas gastas em cada tarefa e o Scrum Master a ajuda a definir o tempo baseado no grau de dificuldade da funcionalidade e do nível de produtividade de cada profissional. A equipe de de qualquer desvio que saia do objetivo previamente definido. Essa reunião dura até 8 horas, e é ela que define o Sprint Backlog. Para validar se todos os pontos que devem ser abordados em reunião foram concluídos, é interessante fazer um checklist da reunião respondendo às seguintes questões: 11 A visão do produto foi completamente entendida? 11 Todas as funcionalidades que o cliente deseja foram levantadas?


desenvolvimento não pode sofrer interferências externas. É blindada pelo Scrum Master

39

11 Os itens do Product Backlog que serão entregues na próxima Sprint foram selecionados?

q

11 Os níveis de prioridade dos itens do Product Backlog foram definidos? 11 Os prazos dos itens do Product Backlog foram definidos? 11 A meta da Sprint (ou seja, o que deve ser entregue) foi estabelecida? 11 As histórias (funcionalidades narradas pelo cliente) estão quebradas em várias tarefas? 11 Todas as tarefas têm um profissional responsável? 11 Preparar o “Task Board” – quadro de tarefas; 11 Preparar o gráfico de Burndown. Uma vez definido o Sprint Backlog, com a listagem de todas as tarefas, seus responsáveis e prazos, o processo de desenvolvimento começa.

Reuniões diárias de Scrum (Daily) Os participantes das reuniões diárias são:

q

11 Scrum Master; 11 Equipe de desenvolvimento. Uma das principais características da metodologia são as reuniões diárias de Scrum, onde o Scrum Master se reúne com a equipe de desenvolvimento para avaliar os progressos do projeto e possíveis impedimentos que estejam atrapalhando o progresso do trabalho de desenvolvimento. As regras para as Daily são: 11 Essas reuniões acontecem todos os dias durante o ciclo de desenvolvimento; 11 São tipicamente rápidas e objetivas; 11 A ideia é que os participantes estejam de pé durante a reunião; 11 Ocorrem preferencialmente no turno da manhã; 11 Têm uma duração de no máximo 15 minutos, para evitar perder o foco do que está sendo desenvolvido e divergências de assuntos. A reunião diária de Scrum é uma maneira eficiente de manter os membros cientes dos objetivos e forçar que os profissionais não percam o foco. Elas não representam uma forma de cobrança vinda de um gerente de projetos, mas uma maneira de sincronizar a equipe às tarefas e relatar os impedimentos que possam estar interferindo no anda-


mento da Sprint. Uma reunião diária de Scrum típica pode ser encontrada na figura 3.2.

40

Figura 3.2 Reunião diária de Scrum (Daily Scrum).

Na Daily Scrum, cada membro da equipe responde a três perguntas:

q

11 O que você fez nesse projeto desde a última reunião diária do Scrum? 11 O que você planeja fazer nesse projeto entre agora e a próxima reunião diária do Scrum? 11 Que obstáculos se interpõem no caminho da equipe para atender seus compromissos a esse Sprint e esse projeto? Como se pode imaginar, o Scrum Master tem um papel muito importante nessas reuniões, pois é o responsável por identificar todos os problemas ou novas tarefas que surgirem e replanejar o plano da Sprint atual, remanejando o Task Board e o gráfico de Burndown, artefatos que estudaremos na próxima sessão.

Reunião de revisão da Sprint (Sprint Review) Também denominada de Sprint Review, a reunião de revisão da Sprint ajuda a equipe,

q

de forma colaborativa, a obter feedback e determinar os objetivos da próxima iteração, assim como a qualidade e as capacidades das funcionalidades produzidas. Os participantes da reunião de revisão da Sprint são: 11 Product Owner; 11 Equipe de Desenvolvimento; 11 Scrum Master; 11 Clientes (e outras partes interessadas, tais como diretores e representantes do cliente); 11 Engenheiros de outros projetos semelhantes. Segundo Martins (2006), a reunião de revisão da Sprint é uma reunião informal de quatro horas de duração, na qual a equipe de desenvolvimento, juntamente do Scrum Master, se reúne com o Product Owner e convidados para apresentar o resultado da Sprint – ou seja, tudo o que foi desenvolvido durante o ciclo de desenvolvimento da Sprint atual. Na primeira parte da reunião, o Product Owner é responsável por validar os requisitos e, caso necessário, solicitar ajustes para que o projeto se torne adequado às necessidades do cliente. Depois de revisar todo esse resultado, o Product Owner define quais itens do Product Backlog foram completados na Sprint, discutindo então com membros da equipe e com o cliente quais serão as novas prioridades. Esse é o primeiro passo para criar uma nova Sprint e definir juntamente com a equipe um novo incremento no produto, ou seja, uma nova parte do produto utilizável que será entregue no final da nova Sprint. Ao final da apresentação das funcionalidades desenvolvidas, o cliente é questionado quanto às suas impressões, mudanças necessárias e alterações de prioridades. Possíveis rearranjos podem ser inseridos na próxima Sprint. Depois que essa reunião é finalizada, uma nova Sprint pode começar até que todo o produto seja implementado ou finalizado e o Product Backlog esteja sem pendências. Para validar se todos os pontos abordados na reunião foram concluídos, é interessante fazer um checklist da reunião, respondendo às seguintes questões: 11 Qual o valor acrescentado nesse incremento (bloco)? 11 O que foi completado no nosso Sprint backlog? 11 Qual o feedback por parte do cliente do projeto?

q


nos itens do Product Backlog ou funcionalidades que não foram entregues como esperado

41

11 Quais foram os pontos fracos e fortes da equipe durante o Sprint?

q

11 Alguém teve alguma dificuldade? 11 Alguém vê algum risco futuro para o projeto? 11 Quais os pontos de melhoria a seguir com o próximo processo na próxima Sprint?

Reunião de retrospectiva da Sprint (Sprint Retrospective) Durante a retrospectiva, o Scrum Master reúne-se com a equipe de desenvolvimento e

q

revisa os altos e baixos do ciclo. O time conversa para analisar os pontos positivos e como pode melhorar ainda mais o ambiente de trabalho, as ferramentas e o convívio entre as partes, bem como suas funções. Trata-se basicamente de uma parte de um aprimoramento interno. Parte de qualquer projeto ágil de gestão, a retrospectiva do Sprint é uma reunião em que o Scrum Master, o proprietário do produto e a equipe de desenvolvimento discutem como a Sprint acontecem e como podem melhorar na próxima. Se a equipe Scrum interage regularmente com os agentes externos, as percepções dessas partes interessadas podem ser bastante valiosas e elas podem merecer um convite para a retrospectiva. O objetivo da retrospectiva da Sprint é melhorar continuamente os processos. Melhorar e personalizar os processos de acordo com as necessidades de cada equipe Scrum individualmente aumenta a moral da equipe Scrum, melhora a eficiência e aumenta a velocidade – ou seja, a produção de trabalho. É importante entender que os resultados encontrados nas retrospectivas de Sprint podem ser únicos para equipes diferentes de Scrum. Por exemplo, uma equipe pode decidir entrar em trabalho cedo e sair mais cedo em determinado dia: ou fazer o oposto. A flexibilidade para trabalhar quando a equipe se sente mais produtiva pode aumentar a motivação e a velocidade de trabalho. É importante lembrar também que abordagens ágeis rapidamente revelam problemas dentro de projetos – dados do Sprint Backlog mostram exatamente onde a equipe de desenvolvimento mostrou pioras ou melhoras. A reunião de retrospectiva da Sprint é orientada à ação e deve cobrir três perguntas

q

principais: 11 O que deu certo durante a Sprint? 11 O que gostaríamos de mudar? 11 Como podemos implementar tal mudança? Dica: para a primeira retrospectiva da Sprint, todos na equipe scrum precisam considerar as três perguntas antes da reunião iniciar. Assim, é bom o Scrum Master enviar as perguntas antecipadamente, para que todos na equipe de Scrum façam algumas notas de antemão ou até mesmo tomem notas durante toda a Sprint. Uma boa estratégia é anotar os impedimentos encontrados durante as reuniões diárias e tentar encontrar possíveis pontos de Fundamentos do Scrum

melhoria a partir destes. A partir da segunda reunião de retrospectiva da Sprint, podemos

42

comparar a Sprint atual com anteriores. Tópicos adicionais que podem ser cobertos nessa reunião: 11 Resultados: compare a quantidade de trabalho planejado com o que a equipe de desenvolvimento acabou completando de fato. Revise o gráfico de Burndown para entender a performance da equipe de desenvolvimento.

q

11 Pessoas: discuta o alinhamento e a composição da equipe;

q

11 Relacionamentos: discuta sobre comunicação, colaboração e trabalho em pares; 11 Processos: discuta sobre suporte, desenvolvimento e processos de revisão de código; 11 Ferramentas: como estão as ferramentas atuais para a equipe de desenvolvimento Scrum? Pense sobre os artefatos, ferramentas automatizadas, de comunicação e técnicas; 11 Produtividade: como a equipe poderia melhorar a produtividade e realizar a maior quantidade de trabalho na próxima Sprint? Para algumas equipes Scrum, pode ser difícil se abrir no início. O Scrum Master pode precisar fazer perguntas específicas para iniciar discussões. Participar em retrospectivas requer prática. O que importa é para incentivar a equipe Scrum a assumir a responsabilidade: para realmente abraçar a característica de autogestão. A retrospectiva da Sprint é uma das melhores oportunidades que a equipe Scrum tem de colocar as ideias de inspeção e adaptação em ação. É importante que a equipe possua a capacidade de identificar desafios e soluções durante a retrospectiva e não deixe essas soluções para após a reunião. Assim, a reunião de retrospectiva é ser orientada a ações, tais como inspeção e adaptação da equipe, que podem ser gravados, inclusive, informalmente: o importante é garantir visibilidade de ações sobre os itens listados após a reunião.

Artefatos Os artefatos do Scrum são as ferramentas básicas para se trabalhar com esse modelo

q

de desenvolvimento. Esses artefatos servem como guias e indicadores para suportar o processo e são divididos em seis. Podemos citar: 11 Estórias (User stories); 11 Planning Poker;

Nesta sessão, estudaremos cada um deles em detalhes.

11 Product Backlog; 11 Sprint Backlog; 11 Burndown Chart.

Histórias (user stories) Uma história do usuário, também denominada de user story, é uma pequena descrição

q

que detalha um item do Product Backlog. Esse item posteriormente virará uma funcionalidade ou mais. É tipicamente narrada pelo cliente e o Product Owner, através de técnicas de levantamento de requisitos, o ajuda a detalhar e extrair pontos importantes para composição de funcionalidades do sistema para o tornar legível – em um formato que se torne útil o suficiente para suportar o negócio. As user stories ajudam no entendimento das atividades de negócio e também são utilizadas como suporte para atividades de planejamento. São usadas como base para cálculo de velocidade da equipe. Usualmente, a estimativa é feita em pontos, os denominados story points, embora também possam ser feitos em horas.


l

11 Sprint;

43

Uma dica para escrever uma boa história é conversar sobre ela, entre os desenvolvedores e os clientes, de forma a detalhar os itens e esclarecer todas as dúvidas sobre o que deve ser feito. Antes de se reunir com o cliente, o proprietário do produto e a equipe de desenvolvimento devem preparar um questionário com perguntas que auxiliam o cliente a lembrar de fatos que podem passar despercebidos, mas que podem ter sido importantes para o desenvolvimento do produto. Exemplo: “Eu gostaria de efetuar um orçamento automaticamente, a partir de um cliente

q

ou serviço. Gostaria de poder enviar o orçamento para o cliente sem precisar nem entrar em contato. Eu acho que passo muitas horas calculando o total do orçamento, pois por serem muitos, eu nunca tenho os preços atualizados.” Seria difícil dar início ao desenvolvimento baseado apenas nesse pequeno texto. Baseado nesse exemplo, seguem os tipos de questões que a equipe pode aplicar para extrair mais informações úteis para o projeto: 11 Você faz o orçamento sempre para os mesmos clientes? 11 No sistema atual você está acostumado a fazer pesquisa de serviços através de quais atributos? 11 Um produto é fornecido apenas por um fornecedor? 11 O cliente sempre compra os mesmos serviços? 11 É possível enviar o orçamento por e-mail ou através de interface para o cliente; porém, como você pretende receber a autorização? Via interface gráfica, e-mail, ou através de um contato fora do sistema? 11 Os preços dos serviços são muito dinâmicos? 11 Os preços dos serviços são personalizados para cada cliente? 11 Você já tem um cadastro de serviço no software atual? É comum que os detalhes sejam expressos em histórias futuras. É melhor ter muitas histórias menores do que ter poucas histórias grandes. É também importante lembrarmos que a comunicação “cara a cara” é um dos princípios da filosofia ágil e, por isso, em vez de escrever todos os detalhes na user story, o melhor a fazer é reunir a equipe de desenvolvimento e o cliente e garantir uma discussão sobre os detalhes, já definindo as funcionalidades. Partindo desse exemplo de user story, poderíamos definir as seguintes funcionalidades: 11 Manter cliente: 22 Consultar cliente. 11 Manter serviço: 22 Cadastrar serviço; 22 Atualizar preço do serviço; 22 Excluir serviço;


22 Consultar serviço. 11 Manter orçamento: 22 Criar orçamento; 22 Calcular orçamento; 22 Enviar orçamento; 22 Excluir orçamento; 22 Consultar orçamento; 22 Autorizar orçamento. 44

q

É interessante que o proprietário do produto faça uma espécie de estágio no cliente para vivenciar a atividade no negócio e assim consiga ser mais sensível às necessidades. Um princípio-chave no Scrum é o reconhecimento de que, durante um projeto, os clientes podem mudar de ideia sobre o que eles querem e precisam (muitas vezes, chamados de “requirements churn” – do inglês “requisitos agitados”), e que os desafios imprevisíveis não podem ser facilmente tratados de uma maneira preditiva ou planejada. Como tal, o Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe para entregar rapidamente e responder as necessidades emergentes. As user stories devem ser compreensíveis por todos os envolvidos: usuários, cliente

q

e equipe de desenvolvimento. Portanto, existem alguns critérios importantes com os quais se preocupar quando se descreve histórias de usuário. Elas precisam ser: 11 Negociáveis: uma user story não é um processo jurídico e, portanto, não necessita ter excesso de informações. A ausência dessas informações estimulará que a equipe esteja sempre negociando os detalhes em futuras conversas com o cliente; 11 Valiosas: as user stories precisam ter valor para o cliente ou usuários; 11 Entendimento comum: como o planejamento do Sprint no Scrum é baseado em estimativas, as user stories precisam ser estimáveis. Não é necessário que a equipe entenda todos os detalhes da user story, mas é necessário um nível de entendimento comum dela para que seja possível realizar a estimativa; 11 Pequena: uma user story deve ser pequena o suficiente para que possa ser implementada e implantada, mas grande o suficiente para traga valor para o negócio; 11 Testável: as user stories precisam ser testáveis; caso contrário, não será possível a equipe saber se o desenvolvimento foi validado ou não.

Planning Poker O Planning Poker é basicamente a atribuição de pontos às user stories. É uma prática

q

que ajuda na estimativa de uma história ou de uma tarefa. Tais pontos representam um grau de dificuldade de uma funcionalidade perante o projeto. Planning Poker no Scrum reúne várias opiniões de especialistas para a estimativa ágil de um projeto. Nesse tipo de planejamento, que deve incluir todos, desde programadores, testadores e engenheiros de banco de dados com analistas e designers de interação do usuário. Como esses membros da equipe representam todas as disciplinas de um projeto de software, eles são adequados para a tarefa de estimativa. A dinâmica do Planning Poker é como segue: inicialmente, a equipe do projeto deve definir uma escala para o Planning Poker. Normalmente, esse usa uma escala de pontos não linear, como, por exemplo:

Em segundo lugar, devem-se definir valores de referências. Como, por exemplo: identificar uma user story à qual pode ser atribuída o menor valor (10 pontos), outra que representa um valor mediano (50 pontas) e outra à qual representa o valor máximo (130 pontos). Dessa forma, essas histórias serão utilizadas como referências para pontuação de demais user stories que apareçam durante o processo de estimativa nas reuniões de planejamento.


10, 20, 30, 50, 70, 130...

45

No início do exercício de planejamento ágil, a cada estimador é dado um baralho de

q

cartões de Planning Poker. Cada cartão tem uma das estimativas válidas sobre ela, como as recém-descritas. Para cada história de usuário ou tema a ser estimado, um moderador (geralmente o Product Owner ou o Scrum Master) lê a descrição. Haverá alguma discussão, onde o moderador responde a quaisquer perguntas dos avaliadores. Mas o objetivo de Planning Poker no Scrum não é para derivar uma estimativa de que vai resistir a qualquer controle futuro. Em vez disso, a ideia é obter uma estimativa valiosa que pode ser alcançada de forma barata. Após a discussão, cada um estimador seleciona de maneira privada um cartão representando sua estimativa. Uma vez que cada estimador fez uma seleção, os cartões são simultaneamente virados e mostrados, de forma que todos os participantes podem ver a estimativa uns dos outros. Nesse ponto, é provável que as estimativas provavelmente sejam significativamente diferentes, e isso é aceitável. O moderador deve encorajar que as estimativas marginais expliquem as suas perspectivas para que a equipe possa entender o porquê de números mais discrepantes. O moderador toma notas durante essa sessão de planejamento ágil, pois se imagina que isso será útil quando a história for programada e testada. Não haverá problemas se, após discussões, quaisquer participantes decidirem mudar suas estimativas em função de discordâncias ou convencimentos – é comum em equipes ágeis. Após a discussão, uma nova rodada de estimativa deve acontecer e uma nova seleção de cartão pode ocorrer. Muitas vezes, as estimativas vão convergir na segunda rodada. Senão, repita o processo até que a equipe concorde com uma única estimativa a ser usada para a user story. Raramente será necessário mais do que três rodadas de discussões na estimativa para se alcançar a meta Sprint. Sprint é uma iteração, ou seja, um bloco de desenvolvimento em Scrum, que deve ser completada em 15 dias ou em 1 mês. Como todos os processos ágeis, Scrum é uma abordagem iterativa e incremental ao desenvolvimento de software. Embora os termos iterativo e incremental sejam normalmente utilizados em conjunto, cada um deles possui um significado único. Vamos brevemente provocá-los separados para que possamos entender melhor seus significados. O desenvolvimento incremental envolve a construção de um sistema peça por peça. Inicialmente desenvolve-se uma parte e, em seguida, um o bloco adicional é adicionado à primeira, e assim por diante. Alistair Cockburn (2008) descreve desenvolvimento incremental principalmente como uma “estratégia de encenação e de agendamento”. Por exemplo, uma abordagem incremental para o desenvolvimento de um site de leilão on-line pode envolver inicialmente desenvolver a capacidade de criar contas no site. Depois, o desenvolvimento da capacidade de listar itens para venda e, em seguida, a capacidade de oferta em itens, e assim por diante. Por outro lado, o desenvolvimento iterativo é o que Cockburn refere-se como um “retra Fundamentos do Scrum

balho estratégia de programação”. Um processo de desenvolvimento iterativo reconhece a

46

impossibilidade – ou, pelo menos, improbabilidade – de se conseguir acertar o desenvolvimento de funcionalidade em sua inteireza da primeira vez. Dentro da construção de um site de leilão on-line de forma iterativa, podemos primeiro desenvolver uma versão preliminar do site completo, obter feedback sobre ele, desenvolver uma versão subsequente do site completo que incorpora o feedback do cliente na segunda vez e repetir o processo, conforme necessário.

Assim, em um processo incremental, desenvolvemos totalmente uma funcionalidade e, em seguida, segue-se para a próxima. Em um processo iterativo, se constrói todo o sistema, mas isso é feito de forma imperfeita em primeiro lugar, usando passos subsequentes através de todo o sistema para melhoria. As fraquezas inerentes de ser apenas iterativo ou apenas incrementais desaparecem quando eles são combinados, e essa é a forma como eles estão dispostos em Scrum. Ao final da Sprint, a equipe do projeto deverá produzir uma entrega de valor para o cliente – que se trata de um software funcional. A entrega de valor é, portanto, a meta da Sprint, que deverá estar bem definida e combinada com o cliente antes do começo de sua execução. Durante cada Sprint, a equipe cria um incremento de produto “entregável”, ou seja, as funcionalidades testadas e prontas para uso. O conjunto de funcionalidades que entram em uma Sprint vem do Product Backlog. Um software funcional é aquele que está potencialmente completo e pronto para uso. Aprender como entregar um software dessa natureza é um dos maiores desafios que uma equipe nova nos processos Scrum pode passar. No entanto, isso é fundamental para se tornar ágil. Na verdade, é tão importante que um dos quatro valores indicados no Manifesto Ágil afirma que se valoriza “software funcional mais que documentação abrangente” (Beck et al., 2001). Metodologias ágeis enfatizam software funcional por três razões:

q

11 Software funcional possibilita feedback: uma equipe pode coletar mais e melhor feedback se mostra (ou melhor, entrega) um produto parcial em funcionamento para os utilizadores do que se fornece a esses usuários documento sobre o que o produto vai fazer; 11 Software funcional auxilia a equipe avaliar seu processo: um dos maiores riscos em um projeto não é saber o quanto ainda resta a ser feito. Quando se permite muito de um sistema em estado inacabado, é extremamente difícil saber o quanto de esforço ainda resta para trazer o sistema para um estado potencialmente de entrega; 11 Software funcional permite que a equipe entregue o produto mais rapidamente se desejar: no mundo competitivo e em rápida mudança de hoje, a opção de entregar o produto precocemente, mesmo que isso signifique entrega de menos recursos, pode ser muito valioso. Colocar o software em uma posição próxima a essa, no final de cada Sprint, oferece essa opção. Conforme vimos anteriormente, durante a reunião de planejamento da Sprint, são definidos os itens do Product Backlog que entrarão para o Sprint. Nessa reunião, o Product Owner informa a equipe dos itens no Product Backlog que o cliente deseja que sejam priorizados. A equipe então determina quanto eles podem se comprometer a concluir durante a próxima Sprint e registram isso no Sprint Backlog.

1. Entregue algo de valor a cada Sprint. 2. Prepare essa Sprint para a próxima. 3. Mantenha os períodos de tempo regulares e estritos. 4. Não mude os objetivos. 5. Obtenha feedback, aprenda e adapte.


Regras da Sprint:

47

Entregue algo de valor a cada Sprint Mesmo que se certificar que no fim de cada Sprint haja um software funcional não seja

q

um desafio muito grande, as equipes Scrum também devem entregar algo valioso para os usuários ou clientes ao fim de cada Sprint em termos de sistema. A definição do que é valioso para usuários ou clientes pode ser estipulado muito facilmente e de forma quase maliciosa. Por exemplo, uma equipe pode argumentar que atualizar os desktops dos desenvolvedores para a versão mais recente de seu Sistema Operacional preferido lhes permite desenvolver mais rapidamente para que os novos recursos se tornem disponível aos clientes de maneira mais eficientemente. Embora isso possa muito bem ser verdade, a intenção é que, a cada Sprint, se deve entregar algo de valor imediato para os usuários ou clientes que eles possam enxergar. Prepare essa Sprint para a próxima Esteja preparado. Passe um pouco de esforço em cada Sprint preparando-se para a

q

Sprint Seguinte. Ken Schwaber (2009) recomenda a alocação de cerca de 10% do tempo disponível de uma equipe em qualquer esforço para se preparar para o próximo esforço. A equipe deve, é claro, ajustar esse valor para cima ou para baixo com base na sua experiência. Já sabemos que uma equipe não deve puxar uma user story ou outro item do Product Backlog em uma Sprint se é claramente muito grande para ser concluído. Uma história de usuário épica que levará meses para completar deve ser decomposta em pedaços menores, de modo que cada uma possa ser concluída dentro de uma Sprint. Este é verdadeiro para user stories que são demasiadamente vagas. Se uma história não pode ser concluída em uma Sprint, ela não deve ser trazida para a Sprint. Em vez disso, a equipe precisa para passar por algum esforço para aprender sobre a estória pela primeira vez. No entanto, perceba que uma user story não precisa estar completamente compreendida para entrar em uma Sprint. Uma história de usuário no Product Backlog não precisa ser totalmente pensada, com todos os detalhes trabalhados, antes de ser puxada para uma Sprint. O Product Owner e outros membros da equipe ainda vão colaborar com a história durante a Sprint. No entanto, cada história de usuário puxada para a Sprint deve ser entendida em detalhes o suficiente para que, quando discutida e argumentada durante a Sprint, possa ser detalhada e concluída. Há algumas coisas que a equipe Scrum deve fazer para garantir esse pensamento proativo nas Sprints: 11 Discutir o product backlog. identificar os cinco principais itens na necessidade de promover o pensamento proativo. Para cada um dos itens, discutir quem precisa pensar sobre isso (arquiteto? Designer de experiência com o usuário? Administrador de


banco de dados? Outro?) E decidir em quantas Sprints de antemão que deve começar;

48

11 Nas suas próximas Sprints Reviews, discuta se cada item no Product Backlog possui detalhes suficientes incluídos detalhes suficientes e se ele foi adicionado apenas no tempo; 11 Para cada Sprint, é necessário controlar a quantidade de tempo gasto pensando no futuro. Normalmente, cerca de 10% do tempo disponível de uma equipe deve ser gasto olhando para frente.

q

Mantenha os períodos de tempo regulares e estritos Manter os períodos de tempo estritos para as Sprints reforça a ideia que o projeto se move continuamente adiante. A equipe deve entregar um novo incremento de produto potencialmente utilizável constantemente. Caso contrário, ou seja, se os períodos variarem (“Vamos executar uma Sprint de seis semanas agora porque nós estamos trabalhando em elementos arquiteturais”) ou se estes são ocasionalmente estendidos (“Nós só precisamos de mais três dias”), essa disciplina valiosa será perdida ao longo do tempo. Podemos citar algumas vantagens de se manter períodos de tempo regulares:

q

11 Equipes se beneficiam de uma cadência regular: quando as durações Sprint variam, os membros da equipe são muitas vezes se sentem inseguros do cronograma. Perguntas como “Essa é a última semana da Sprint?” ou “Será que nós enviamos nessa quinta-feira ou na próxima quinta-feira?” tornam-se comuns. Uma cadência regular de uma a quatro semanas ajuda as equipes a se acostumarem a um ritmo de trabalho; 11 Planejar a Sprint se torna mais fácil: tanto o planejamento da Sprint, quanto o planejamento do release, são simplificados quando as equipes ficam com uma duração da Sprint constante. O planejamento da Sprint é mais fácil, porque depois de normalmente duas a cinco Sprints a equipe aprende facilmente quantas horas de trabalho podem ser planejadas em uma Sprint; 11 Planejar a release se torna mais fácil: equipes Scrum derivam seus planos de lançamento empiricamente (sempre que possível). Eles estimam o tamanho do trabalho a ser feito em um projeto e, em seguida, medem a quantidade concluída por Sprint. Se a quantidade de horas na Sprint varia, medir a velocidade de uma equipe se torna mais difícil, pois não há nenhuma garantia de que uma Sprint de quatro semanas vai entregar o dobro que uma Sprint de duas semanas. Normalizar a velocidade como “velocidade por semana” funciona um pouco, mas é um trabalho extra desnecessário quando as Sprints são mantidas sob o mesmo período de tempo. Para deixar claro que os prazos da Sprint precisam ser cumpridos rigorosamente, é óbvio que as equipes vão ocasionalmente precisar deixar de fazer algum trabalho que tinham inicialmente planejado durante alguma Sprint. Essa situação não é desejada, mas é realista, e espera-se que estes possam compensá-la acrescentando ocasionalmente mais trabalho em uma Sprint futura. Desde que o trabalho seja realizado em ordem de prioridade, isso não é o fim do mundo. Assim, invariavelmente, termine as Sprints no tempo correto. Não chegue na data planejada e decida que precisa de mais um ou dois dias para finalizar o trabalho. Não mude os objetivos Durante uma Sprint, nenhum integrante da equipe, nem mesmo o Product Owner, pode

q

alterar o Sprint Backlog. Ou seja, a cada Sprint, os requisitos são congelados. O desenvolvimento de cada Sprint deve terminar no tempo predefinido em reunião. Caso os para o Product Backlog. A postura de Scrum de ser contra as alterações meio do Sprint pode parecer prejudicial para o sucesso do projeto. Afinal, às vezes as mudanças são tão importantes que precisam ser feitas. E outras vezes novas informações podem tornar inútil o trabalho no qual a equipe está atualmente envolvida. No entanto, existem algumas exceções. Primeiro vamos considerar o caso de o Product Owner descobrir algum novo requisito importante que precisa ser feito prioritariamente em vez do trabalho que a equipe está


requisitos não sejam finalizados por qualquer motivo, eles são deixados de fora e voltam

49

trabalhando. Antes de mais nada, o Scrum Master deve garantir que os objetivos da Sprint atual sejam visíveis e conhecidos por toda a organização. Mas, quando isso acontecer, a direção do Scrum é anunciar uma finalização anormal na Sprint, seguida imediatamente pelo planejamento de uma nova Sprint para incluir a funcionalidade recém-descoberta de mais alta importância. Garantir a visibilidade dos objetivos da Sprint é importante porque torna menos provável de acontecer. Em muitas organizações, os únicos que veem o redirecionamento constante da equipe são os membros da equipe em si. A abordagem Scrum de não permitir a mudança em um Sprint Backlog, mas disponibilizar o encerramento anormal seguido de um novo começo aumenta a visibilidade de aumento de custos e frequência de mudança. Isso deve dificultar a quantidade de mudanças lançadas contra a equipe no meio de uma Sprint, pois apenas mudanças realmente mais importantes justificarão o encerramento anormal de uma Sprint. No caso, quando novas informações são aprendidas sobre o trabalho que está sendo realizado (que pode fazer o trabalho planejado menos desejável), pode ser que a equipe aprenda algo que significa que ele deve parar de trabalhar em alguma parte de uma Sprint. Por exemplo, um objetivo da Sprint atual pode ser a de adicionar uma funcionalidade especial especificamente para ajudar a fazer uma venda a um grande cliente. No meio da Sprint, o cliente lhe diz que sua empresa tem tido um congelamento do orçamento e não pode comprar o seu produto, mesmo que tenha a nova funcionalidade, ou que ele foi adquirido e será forçado a usar o produto do seu concorrente, ou qualquer das situações semelhantes. Nesses casos, pode fazer sentido parar de trabalhar nessa funcionalidade específica, dependendo da conveniência geral para outros clientes e de quanto tempo o trabalho pode requerer. No entanto, situações como essas acontecem com menos frequência do que a maioria das pessoas que são novas para Scrum pensam. Uma situação muito mais comum é a de ter um negócio orientado a interrupções, mudanças, em que mudanças simplesmente continuam a aparecer e que, por causa disso, os desenvolvedores e o resto da equipe também precisam ser. Através dos anos, as organizações se tornaram viciadas em redirecionar constantemente suas equipes. Muitas vezes as equipes não são nem interrompidas porque o Product Owner descobriu uma necessidade do cliente crítica ou outra interrupção válida, mas simplesmente porque as partes interessadas não conseguiram pensar no futuro. Eles se tornaram acostumados a trabalhar dessa forma e não estão cientes do impacto negativo que essa abordagem tem sobre as suas equipes de desenvolvimento. Em outras palavras, nada é permitido mudar dentro da Sprint. A equipe compromete-se a um conjunto de trabalhos no primeiro dia e, em seguida, espera que as suas prioridades permaneçam inalteradas durante a duração da Sprint. No entanto, embora não sejam permitidas alterações na Sprint, o mundo inteiro pode estar mudando fora dela. Por fim, depois Fundamentos do Scrum

que uma Sprint é completada, a equipe demonstra como usar o software.

50

Obtenha feedback, aprenda e adapte Cada Sprint pode ser vista como um experimento. O proprietário do produto e da equipe se encontram no início da Sprint para identificar a experiência mais valiosa que eles podem executar. O experimento envolve a criação de uma certa quantidade de novas funcionalidades na forma de software funcional.

q

Grande parte da aprendizagem será sobre o produto: o que os usuários gostam? O que eles não gostam? O que eles acham confuso? O que eles querem seguir? Quais são as características do novo incremento que pode ajudá-los pensar acerca de coisas sobre as quais eles não tinham pensado antes? Talvez parte do aprendizado será sobre o uso da equipe sobre o próprio Scrum: quanto trabalho que podemos fazer em um sprint? O que fica no nosso caminho? O que poderia nos ajudar a ir mais rápido? Estamos obtendo “feito” software a cada Sprint? A própria característica do Scrum: ser de desenvolvimento iterativo e incremental é sobre a geração de feedback, aprender com ele, e então adaptar o que está sendo construindo e como este está sendo construindo. Sprints fornecem às equipes os mecanismos para fazer isso.

Product Backlog Uma equipe Scrum renuncia a uma longa fase de requisitos em favor de uma abordagem

Na reunião de Planejamento, o Product Owner prepara uma lista de funcionalidades desenvolvida em conjunto o cliente, que é organizada por prioridade de entrega. Esse é o Product Backlog.

just-in-time. Assim, descrições de funcionalidades podem ser recolhidas em alto nível no início, mas elas devem ser progressivamente refinadas no decorrer do projeto. Elas são documentadas em um Product Backlog, que é uma lista de todas as funcionalidades desejadas que ainda não estão no produto. Ele é mantido pelo Product Owner e possui uma ordem de prioridade, o que o faz ser conhecido muitas vezes como lista de funcionalidades priorizadas. Ao contrário de um documento de requisitos tradicional, um Product Backlog é altamente dinâmico: itens são adicionados, removidos e priorizados novamente a cada Sprint, à medida que se aprende mais sobre o produto, os usuários, a equipe e assim por diante. O Product Backlog é uma lista em nível de negócio. Dessa forma, não está escrito em nível de negócio e estão em uma linguagem do cliente. Já vimos que o Product Backlog não é final, e que a equipe de desenvolvimento também contribui para a sua manutenção. Essa contribuição se dá por meio das estimativas de custos das funcionalidades. Há um grande mito sobre os requisitos: se você os escreve, os usuários receberão exata-

q

mente o que eles querem. Isso não é verdade! Na melhor das hipóteses, os usuários receberão exatamente o que foi escrito, que pode ou não ser o que eles realmente querem. As palavras escritas são enganosas – parecem ser mais precisas do que realmente são. 11 Documentos escritos podem fazer você suspender o julgamento: quando algo está escrito, parece oficial, formal e finalizado, especialmente quando uma formatação organizacional foi aplicada; 11 Com um documento escrito, não conversamos acerca do significado como faríamos em uma conversa, para garantir uma transferência de entendimento; 11 Documentos escritos diminuem a responsabilidade da equipe como um todo: um dos objetivos da mudança para o Scrum é fazer com que toda a equipe trabalhe em conjunto em direção ao objetivo de oferecer um grande produto. Queremos tirar do processo de desenvolvimento maus hábitos que prejudicam esse objetivo. Documentos escritos criam transferências sequenciais de atividade, que tiram a equipe de uma unidade de propósito. Uma pessoa (ou grupo) define o produto; outro grupo constrói. A comunicação bidirecional é desencorajada;


l

51

q

11 Não deixar o bebê sozinho sem documentação: tais deficiências na comunicação escrita não significam que devemos abandonar completamente os documentos de requisitos. Em vez disso, devemos usar documentos onde for apropriado. Como o Manifesto Ágil diz ser a favor de “software funcional em vez de documentação abrangente”, ágil tem sido mal interpretada como sendo totalmente contra documentação. O objetivo no desenvolvimento ágil é encontrar o equilíbrio certo entre a documentação e discussão; 11 Use User Stories para o Product Backlog: histórias de usuários são a melhor maneira de mudar o foco de escrever sobre funcionalidades para falar sobre eles mesmos. A user story é uma breve descrição, simples de uma funcionalidade, contada a partir da perspectiva da pessoa que deseja uma nova função, geralmente um usuário ou cliente do sistema. Elas são muitas vezes escritas em cartões de índice ou notas, armazenadas e dispostos em paredes ou mesas para facilitar o planejamento e discussão. Como tal, as histórias de usuário mudam fortemente o foco de escrever sobre os recursos para discuti-las. Uma user story frequentemente tem o formato: Como um , eu gostaria de , pois . Em resumo, o Product Backlog deve incluir todas as funcionalidades visíveis ao cliente e em torno de dez dias de desenvolvimento esses itens deverão estar prontamente definidos para o seu desenvolvimento começar. As tarefas que têm mais prioridade e complexidade deverão ser quebradas em sub-tarefas para poderem ser estimadas e testadas. Observe a tabela 3.1. Um exemplo de sub-tarefa são as funcionalidades Cancelar Vinculo e Vincular Caixa de Picking List.

Tabela 3.1 Product Backlog.

Product Backlog


Funcionalidade (Use case)

52

Prioridade

Estimativa inicial (h)

Pré requisito

Código

Título

UC_01MC003

Manter Perfil

1

12

-

UC_01MC004

Associar Operadores aos Perfils

2

16

UC_01MC003

UC_01MC002

Gerenciar Perfil de Acesso

2

16

UC_01CT013

UC_01MC001

Painel de Rotas

1

22

UC_01CT013

UC_01CT013

Efetuar Login no Sistema

3

8

-

UC_01CT014

Gerar Relatório de Picking List

1

10

-

UC_01CT015

Registrar Mercadoria danificada

2

12

-

UC_01CT016

Manter Caixa

2

18

UC_01CT023

UC_01CT024

Manter Vínculo

UC_01CT024a

Cancelar Vínculo

2

10

UC_01CT024b

UC_01CT024b

Vincular Caixa ao Picking List

3

32

-

UC_01CT019

Manter Cubagem

1

28

-

UC_01CT020

Escanear Unidade

1

20

-

UC_01CT021

Expedir Picking List

2

12

-

UC_01CT023

Manter Tipo de Caixa

1

10

-

Sprint Backlog Assim que a equipe Scrum escolher e definir a lista de requisitos e a prioridade de seus

q

itens no Product Backlog, dá-se início a um novo ciclo, chamado Sprint. Cada um desses itens agora será dividido em partes menores para o Sprint Backlog. Um documento especificando o detalhe de cada funcionalidade do sistema, com informações técnicas adicionais que auxiliarão no desenvolvimento. A seguir, segue um exemplo de um Sprint Backlog, na tabela 3.2, da funcionalidade Consultar Caixa. Não existe um padrão, pode ser feito de várias formas: Excel, Word, em um quadro, post-it na parede, entre outros. O importante é que as informações se tornem disponíveis para controle do projeto. Sprint Backlog Funcionalidade (Use case)

Descrição

Código

UC_01CT016

Título

Manter Caixa

Permitir a consulta, a edição, a exclusão de caixas e o cadastramento de novas caixas.

Prioridade

2

Estimativa inicial

18

Horas Trab.

-

Status

Pendente

Pré requisito

UC_01CT023

Menu

Menu: Cadastros g Caixas

Regras

Campos Status e Tipo com combobox

2. Operador preenche os parâmetros de consultas desejados (Caixa, Tipo) e clica na opção "Consultar"; 3. Sistema faz a consulta na base de dados filtrando as caixas pelos parâmetros informados; 4. Sistema carrega a tela com o resultado da consulta, preenchendo os campos da grid (Caixa, Status, Tipo, Selecionar).

A equipe compila uma lista inicial dessas tarefas na segunda parte da reunião de planejamento do Sprint. As tarefas devem ser divididas de modo que cada um leva cerca de 4 a 16 horas para terminar. Tarefas que durariam mais de 4 a 16 horas são considerados meros espaços reservados para as tarefas que ainda não foram adequadamente definidas. Logo após o Sprint Backlog estar concluído, é preenchido o campo “Horas Trab” com a

q

quantidade de horas que a funcionalidade demandou para ser concluída. Sendo assim, é possível comparar o total de horas trabalhadas com a estimativa pré-definida na reunião de planejamento, dando oportunidade de melhorar futuras estimativas. Caso haja uma diferença significativa, a equipe Scrum deve negociar novamente com o cliente uma nova data de entrega. É importante selecionar uma pessoa para adicionar, atualizar e excluir informações no Sprint Backlog em uma planilha Excel ou em um aplicativo. No entanto, uma interface comum, a que todos da equipe tenham acesso e possam editar os seus itens também é recomendado, para que os membros da equipe possam podendo incluir itens conforme concluam suas atividades, como um quadro de cartões ou post-its ou um software que simule essa interface, como mostrado na figura 3.3. Dessa forma, o responsável pelo Sprint Backlog pode, ao fim do dia, atualizar o arquivo.


Tabela 3.2 Sprint Backlog da Funcionalidade Consultar Caixa.

1. Operador acessa a tela de Caixas (TL_01CU006_01);

53

Mais Importante

Menos Importante

Manter Tipo de Caixa

Cancelar Vínculo

Vincular Caixa ao Pick List

Manter Caixa

Figura 3.3 Lista de prioridades simulando quadro de cartões post-its.

q

Usar uma superfície grande e visível de cartões é positivo porque: 11 As pessoas ficam de pé e caminham ficando despertas e acordadas por mais tempo; 11 Todos se sentem mais pessoalmente mais envolvidos, em vez de uma só pessoa responsável pela planilha; 11 Fica mais fácil priorizar novamente as atividades – basta trocar a posição dos cartões; 11 Após a reunião, os cartões podem ser levados para a sala da equipe e colocado no quadro de tarefas (Task Board) para que todos visualizem melhor.

Release Burndown É considerado o principal gráfico de controle do Scrum e representa o trabalho restante

q

dentro da Sprint de uma versão do sistema que será entregue. No exemplo mostrado a seguir, na figura 3.4, o eixo horizontal do gráfico exibe as iterações e o eixo vertical exibe a quantidade de trabalho restante. 250

245

Horas Restantes

200

202

150

159 140 113

100

68

50

28 0 Release 5\ Sprint 1

Release 5\ Sprint 2

Release 5\ Sprint 3

Release 5\ Sprint 4

Release 5\ Sprint 5

Release 5\ Sprint 6

Release 6\ Sprint 1


De acordo com Mountain (2011), esse tipo de gráfico funciona em muitas situações e com diversas equipes. Porém, em projetos com muitas mudanças de requisitos, talvez o gráfico não seja adequado, já que a quantidade de horas não vai refletir a ideia de um projeto que se consome. Segundo Highsmith (2004), uma das principais ferramentas de equipe para acompanhar o projeto no Scrum é o release burndown chart, que mostra o andamento diário da equipe por horas, de acordo com a soma das tarefas listadas no Sprint Backlog. A equipe também possui uma task board onde as funcionalidades são colocadas separadas por estados. 54

Figura 3.4 Gráfico de Burndown em Planejamento.

Gráfico de Burndown É uma das principais ferramentas para o gerenciamento do processo de desenvolvimento,

q

pois permite mostrar as partes do trabalho que faltam para uma Sprint acabar, dia por dia. É um gráfico que mostra a quantidade cumulativa restante de trabalho de uma Sprint, diariamente, e permite visualizar o trabalho ainda não cumprida sobre o tempo, assim, habilitando a avaliação sobre a quantidade restante de trabalho e o tempo restante para completar uma Sprint. É com base nesse gráfico que se pode orientar e tomar decisões quanto à modificação do escopo ou cancelamento da Sprint. Sua atualização deve ser diária para que assim a tomada de decisão seja realizada com base em dados atualizados, melhorando a produtividade da equipe e habilitando a previsibilidade de riscos. Durante as Scrums diárias, o Scrum Master acompanha os membros da equipe para perceber o que foi concluído até aquele momento. Assim, dia a dia, ele ajusta o gráfico de Burndown e, a qualquer momento, todo o time pode ter uma ideia do andamento do processo. O mesmo gráfico pode ser mostrado para o Product Owner visualizar a trajetória do projeto: atrasado, adiantado ou dentro do cronograma. Em outras palavras, esse gráfico informa se a equipe está aproximadamente dentro do prazo, servindo como um sinal de alarme para o projeto. Através da leitura do Burndown, decide-se adicionar novas tarefas na Sprint, se a velocidade da equipe estiver acima do planejado, o que vai melhorar sua produtividade ou retirar tarefas, caso a velocidade esteja a seguir do previsto, pois a meta da Sprint estará comprometida se a redução de tarefas não aconteça. Segue-se a análise de três gráficos de projeto que se encontram em situações diferentes. Na figura 3,5, podemos perceber a linha real do andamento do projeto com muitos pontos estimados, mas poucos pontos realizados ao longo dos dias, com relação àqueles estimados inicialmente para a Sprint. Recomenda-se nesse caso a remoção de funcionalidades do Sprint Backlog, diminuindo o escopo da Sprint. 250

200

Pontos

150

100

0 Figura 3.5 Gráfico de Burndown para Sprint Superestimada.

1

2

3

4

5

6

7

8

Dias Estimado Realizado

9

10

11

12

13

14


50

55

Se, em caso contrário, a linha real do andamento do projeto estiver muito acima da linha

q

estimada, deve-se aumentar o escopo da Sprint. A seguir, na figura 3.6, segue um exemplo de projeto para a gestão de uma imobiliária em que o projeto foi sendo realizado antes do estimado – ou seja, muitos pontos foram sendo desenvolvidos antes do tempo pré-determinado. Nesse caso, é possível aumentar o escopo. 160 140 120

Pontos

100 80 60 40 20 0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

Dias Estimado Realizado O ideal em situações assim é retirar tarefas de alta prioridade da próxima Sprint. Caso a

Figura 3.6 Gráfico de Burndown para Sprint Subestimada.

q

meta da próxima Sprint seja muito baixa, podemos até mesmo optar pelo cancelamento da Sprint, juntando as tarefas restantes a Sprint seguinte. Finalmente, na figura 3.7, podemos ver um projeto para gestão de construtora sendo realizado mais ou menos conforme estimado – ou seja, muitos pontos estão sendo desenvolvidos no tempo determinado. Esse é um exemplo de um projeto ideal. 160 140 120

Pontos

100 80 60


40

56

20 0

1

2

3

4

5

6

7

8

Dias Estimado Realizado

9

10

11

12

13

14 Figura 3.7 Gráfico de Burndown para Sprint Ideal.

Task Board Consiste em um grande painel, que possibilita colocar as diversas informações rele-

q

vantes para o acompanhamento da Sprint, tais como o Product Backlog, e as atividades da Sprint juntamente com o seu status (“Pendente”, “Em desenvolvimento”, “A verificar” e “Concluída”). A ideia do Task Board é tornar essas informações sempre visíveis para todos os interessados no desenvolvimento do projeto. Geralmente, o painel é desenhado e colocado em uma parede, e as atividades são descritas em cartões de post-its, como na figura 3.8:

Sprint Backlog

Em Execução

Concluído

BurnDown

Cadastro de categorias de apartamentos

Cadastro de apartamentos Problemas no servidor de teste Cadastro de clientes

SCRUM Master deverá resolver (remover) este impedimento

Release Como não é criado um Product Backlog para cada produto, Scrum recomenda a criação

q

de um plano de Release, que divide os itens do Product Backlog em Sprints. Cada Sprint gera um “entregável”, que são funcionalidades desenvolvidas naquela Sprint. Conforme pode ser visualizado na figura 3.9, a junção dos entregáveis de algumas Sprints gera um release – ou seja, uma Sprint é parte de um release. O release se trata de um produto pronto para ser testado e utilizado pelo usuário. Os entregáveis de cada Sprint não são liberados para os usuários conforme são concluídos, mas são liberados quando a junção de cada entrega forma um produto que faça sentido e adicione valor para o cliente. Conforme é possível visualizar na figura 3.9-, as funcionalidades “Manter Caixa” e “Manter Pick List” foram desenvolvidas na Sprint 1 e geraram a entrega 1. Essa entrega é enviada à equipe de teste que realizará testes de integração apenas entre essas duas funcionalidades. Durante a Sprint, estas também foram testadas unitariamente. Capítulo 3 - A metodologia

Figura 3.8 Task Board com Impedimento.

57

Sprint #1 Manter Pick List

Manter Caixa

Entrega 1

Sprint #2 Vincular Caixa ao Pick List

Painel de Rotas

Entrega 2

Releases

Sprint #3 Cancelar Vínculo

Entrega 3

Produto O mesmo ocorre na Sprint 2 e na Sprint 3 com as funcionalidades “Vincular Caixa ao Picklist”, “Painel de Rotas” e “Cancelar Vínculo”. no final de cada entrega, gera-se as entregas.3.4

Atividades práticas Cenários para realização de uma Planning, incluindo: análise de backlog, análise de user stories, quebra de stories em atividades, scrum poker e finalização da Sprint.


Dividir os estudantes em equipes de 2 a 3 pessoas para eles planejarem uma Sprint.

58

Figura 3.9 Funcionalidades, Sprints, Entregas e Releases formando o Produto.

4 objetivos

Scrum e a organização Entender como Ciclo PDCA e Scrum se complementam; Dicas gerenciais para Scrum; Scrum e Governança

Scrum e o ciclo PDCA Cada Sprint é um bloco de iteração que segue um ciclo PDCA e entrega um incremento de

conceitos

Ciclo PDCA; Equipes distribuídas; Recursos humanos, instalações e PMO

q

funcionalidades prontas para serem incorporadas ao software. Um ciclo PDCA, também conhecido como o círculo de Deming, é um método de gerenciamento iterativo de quatro passos usado em gestão para o controle e melhoria contínua de processos e produtos.

Act (Agir)

Do (Fazer)

Check (Checar)

Figura 4.1 Ciclo PDCA.

Em resumo, o ciclo tem quatro fases, que significam passos no processo de administração. Quando aplicadas ao Scrum, elas podem ser perfeitamente correlacionadas às ações de uma Sprint, conforme analogia a seguir: 11 Plan: essa é a primeira fase do processo. Durante essa etapa, a equipe discute os objetivos, o processo e as condições claras de finalização da Sprint (condições de aceitação). Essa etapa define os objetivos mensuráveis e realizáveis para a equipe; 11 Do: a equipe trabalha em conjunto para atingir o objetivo fixado na fase de planejamento. A equipe trabalha com o conjunto de processos acordados;

q

Capítulo 4 - Scrum e a organização

Plan (Planejar)

59

11 Check: uma vez que a entrega foi realizada, a equipe se reúne e verifica a saída,

q

comparando-a com as condições acordadas de aceitação, decididas durante a fase de planejamento. Os desvios, se existirem, são anotados. É importante notar que essa verificação se dá não somente com relação ao produto entregue, mas também com relação aos processos realizados; 11 Act: se qualquer desvio em tarefas planejadas foi observado durante a fase de verificação, a análise de causa raiz deve ser conduzida. Brainstorms juntamente com a equipe serão realizados para identificação das alterações necessárias para evitar tais desvios no futuro. A equipe também realiza brainstorms para entender mudanças de ideias no processo, incluindo as mudanças de escopo e métricas de medição que podem resultar em um melhor processo ou produto no próximo ciclo ou iteração. Assim, qualquer pessoa com um conhecimento básico de Scrum pode correlacionar as terminologias Scrum a essa abordagem científica. 11 Plan: planejamento da Sprint; 11 Do: Sprint engenharia real; 11 Check: Sprint Review; 11 Act: retrospectiva da Sprint. O processo começa com um conjunto claro de metas e critérios de aceitação. Não pode haver mal-entendidos, o que ajuda a minimizar o desperdício. O grupo sabe o que fazer e ter orientação adequada para alcançá-lo. A verificação das tarefas planejadas também acontece em relação aos critérios de aceitação conhecidos. O processo ajuda a equipe a fazer pequenas mudanças, obter feedback e seguir em frente. A inspeção e adaptação ajuda a equipe a crescer. O cliente final provavelmente encontra-se satisfeito, porque pode ver a saída rapidamente e pode fazer as mudanças com base nas condições de mercado.

Escalando projetos com Scrum Muitos projetos requerem mais esforço do que uma única equipe Scrum pode propor-

q

cionar. Nessas circunstâncias, vários grupos podem ser empregados. Trabalhando em paralelo, os esforços dessas equipes podem ser coordenados através de uma variedade de mecanismos diferentes, que podem ser formais em alguns e mais aleatórios em outros. Quando mais de uma equipe Scrum trabalha simultaneamente em um projeto, esse projeto passa a ser referido como “projeto em escala”, e os mecanismos utilizados para coordenar o trabalho dessas equipes são chamados “mecanismos de escala”. Cada projeto escalado tem suas próprias complexidades, cada um dos quais normalmente exige sua própria solução única e individual. Scrum escala do mesmo modo como qualquer outro processo de desenvolvimento, utilizando praticamente os mesmos mecanismos de escala, mantendo todas as práticas empíricas que formam o seu núcleo.


O núcleo em torno do qual a escala ocorre é a equipe Scrum. Um projeto com 800

60

pessoas será composto por 100 equipes de 8 pessoas, então a dificuldade encontra-se em examinar como coordenar o trabalho dessas equipes, mantendo a produtividade de cada equipe Scrum individual. Também é importante examinar como dimensionar projetos, independentemente do número de pessoas que envolvem, bem como o tipo de aplicação, o tipo de sistema, o número de lugares em que o desenvolvimento precisa ocorrer e outras dimensões de escala relevantes.

q

Infraestrutura Antes de escalar qualquer projeto, uma infraestrutura adequada deve ser colocada em

q

prática. Se um projeto vai empregar várias equipes co-instaladas, um mecanismo para sincronizar com frequência o seu trabalho deve ser concebido e implementado. Além disso, um produto mais detalhado e a arquitetura técnica devem ser construídos de modo que o trabalho possa ser dividido entre as equipes. Se essas equipes estão distribuídas geograficamente, tecnologia de compartilhamento de código-fonte, sincronizado constrói e comunicações alternativas, tais como mensagens instantâneas, devem ser empregados.

Demonstrar funcionalidade de negócios permite a produção do tipo de resultados que o Product Owner e as partes interessadas tanto prezam desde o início, e ajudam o seu engajamento e envolvimento no projeto.

Tudo o que suporta o esforço da escala deve ser concebido e implementado antes do escalonamento do projeto; todo esse trabalho é feito em Sprints. Scrum exige que cada Sprint produza um incremento de funcionalidade do produto potencialmente utilizável, e esse requisito pode ser cumprido se meses são necessários para conceber e implementar uma infraestrutura para escalar o projeto. Na verdade, embora menos funcionalidade de negócio seja criada durante as Sprints iniciais nas quais a infraestrutura será criada, ainda é necessário demonstrar algumas funcionalidades de negócios no final. Na verdade, é ainda mais importante fazê-lo, porque isso permite que a infraestrutura seja testada com o trabalho de desenvolvimento de funcionalidade à medida que a mesma evolui. Os requisitos não funcionais para construir a infraestrutura de escala são uma priori-

q

dade elevada no Product Backlog, porque devem ser concluídos antes de escala em si. Como a funcionalidade de negócios deve ser demonstrada no final de cada Sprint, esses requisitos não funcionais são misturados com a funcionalidade de negócios de mais alta prioridade. Se um pedaço de funcionalidade de negócios depende de um requisito não funcional, o requisito não funcional deve ser priorizado no Product Backlog para ser desenvolvido antes ou em paralelo com a funcionalidade de negócios.

Staging O processo de definição e priorização dos requisitos não funcionais para escala é chamado

q

de Staging. Staging ocorre antes do início do primeiro Sprint e leva apenas um dia, durante o qual os requisitos de escala para o projeto são determinados e colocados no Product Backlog. Por exemplo, se você está escalando o projeto para usar várias equipes, os seguintes requisitos não funcionais devem ser adicionados ao backlog do produto: 11 Decompor a arquitetura de negócios para suportar o desenvolvimento de interfaces de várias equipes; 11 Decompor a arquitetura de sistemas para suportar o desenvolvimento de interfaces de várias equipes; 11 Se necessário, definir e implementar um ambiente para suportar diversas equipes alocadas em ambientes distribuídos. Após esses requisitos não funcionais para dimensionamento serem colocados no Product Backlog, as Sprints podem começar. No entanto, apenas uma equipe pode iniciar seus trabalhos até a infraestrutura de escala estar no lugar, como não é claro haverá mecanismo para coordenar o trabalho de várias equipes no mesmo período. Veja a figura 4.2 para uma representação do Product Backlog inicial com todos os requisitos não funcionais adequados para o tipo de Staging imaginado.

q


l

61

Equipe única

Figura 4.2 Sprints de Escala.

Backlog do produto inicial Requisitos funcionais Requisitos não funcionais Staged scalability requirements The rest of the functional and non-functional requirements

Várias equipes

Backlog do produto Requisitos funcionais Requisitos não funcionais

O Product Owner e a equipe devem ficar juntos em uma reunião de planejamento da

q

Sprint e colaboram para selecionar uma combinação de requisitos funcionais e não funcionais. A equipe então inicia Sprints e iteram tantas vezes quanto necessário, até que a infraestrutura para a encenação esteja no lugar. Nesse ponto, as reuniões de planejamento das Sprints para cada uma das várias equipes de Sprint podem ser realizadas. Cada nova equipe é semeada com um membro da equipe original, que serve como especialista da nova equipe em infraestrutura e arquitetura do projeto.

Equipes distribuídas Há alguns anos, as equipes co-instaladas eram a norma: se tornou difícil encontrar uma equipe distribuída geograficamente. Agora, o inverso parece ser verdadeiro: é uma surpresa quando uma organização tem toda a equipe trabalhando no mesmo edifício. Com a prevalência de equipes espalhadas por todo o mundo, ou pelo menos através de fusos horários distintos, é importante considerar quão bem Scrum funciona quando uma equipe está geograficamente distribuída. Um equívoco comum é que Scrum não é uma boa metodologia para uma equipe geograficamente dispersa. O argumento do Scrum pela preferência por uma comunicação face


a face faz com que muitos pensem que escolher equipes distribuídas seja má escolha.

62

Felizmente, esse argumento é falso. Embora seja verdade que uma equipe local sempre vai superar a equipe distribuída equivalente (Ramasubbu e Balan 2007), Scrum pode realmente ajudar as equipes geograficamente distribuídas.

q

Existem algumas regras do Scrum para equipes distribuídas que veremos a seguir, e

q

dizem respeito basicamente à forma com que as cerimônias devem acontecer e como a equipe deve ser disposta. A razão para isso é que uma diferença de fuso horário tem muito impacto sobre a forma como uma equipe trabalha. Na verdade, possui um impacto muito maior do que a distância geográfica em si.

Reunião de planejamento da Sprint Existem basicamente duas abordagens que podem ser utilizadas para o planejamento

q

da Sprint. As estratégias podem ser referenciadas pelos seus nomes descritivos: a teleconferência longa e duas teleconferências. A seguir, analisamos as vantagens e desvantagens de cada uma dessas abordagens.

Teleconferência longa É a abordagem padrão seguida pela maioria das equipes, e consiste em ligar para um

q

número de teleconferência e conduzir a reunião de planejamento normalmente, Tabela 4.1 A teleconferência longa.

simulando o formato de reunião pessoal. Todo o trabalho de uma reunião de planejamento de Sprint regular é realizado nessa reunião. Quando ela se encerra, a Sprint deve estar completamente planejada como se a equipe fosse local.

Vantagens

Desvantagens

Pode levar a boas discussões se todos se mantiverem engajados

Participantes podem se distrair em uma ligação tão longa

O planejamento da Sprint pode se encerrar em um dia

Só funciona quando há muitas horas em comuns no dia de trabalho na equipe geograficamente dispersa

É consistente com a abordagem utiliza em equipes co-localizadas

Pode significar estender o dia de trabalho em uma ou mais localidades

Duas teleconferências Para algumas equipes, é simplesmente impraticável planejar a reunião de planejamento

q

da Sprint em uma teleconferência: a separação de fusos horários é muito grande para proporcionar sobreposição suficiente nos dias de trabalho. A próxima abordagem de planejamento do Sprint, duas chamadas, divide a reunião através de dois telefonemas realizados em dias consecutivos. Substituir a sessão inicial de oito horas por duas sessões de quatro horas separadas, realizadas em dias consecutivos, é mais prático. Normalmente, a primeira sessão se concentra em identificar as principais tarefas, resultados e dependências de alto nível. Ela tem como foco discutir as expectativas e prioridades mais altas do Product Owner. Durante a segunda sessão, cada membro da equipe define as atividades e fornece estimativas para cada tarefa que ele aceite. Seu foco é sincronizar os compromissos de cada equipe individual com os quais pode se comprometer.

Vantagens

Desvantagens

Pode ser uma forma mais eficiente de se usar o tempo

Esse senso de utilidade pode variar grandemente, dependendo de como a equipe está distribuída

Pode ser usada mesmo quando há poucas horas em comum nos dias de trabalho na equipe

Como muitas discussões acontecem entre as equipes, nem todo o conhecimento é compartilhado com a equipe global, o que pode levar a mal-entendidos Não se completa em um dia.


Tabela 4.2 Duas teleconferências.

63

Daily Scrum A Scrum diária introduz um conjunto de novos desafios em relação à reunião de pla-

q

nejamento da Sprint em equipes geograficamente dispersas. Como o Scrum diário é uma reunião diária de 15 minutos, a sua realização não representa um problema para equipes com dias de trabalho que se sobrepõem, mas são um problema, no entanto, para equipes amplamente distribuídas sem sobreposição em horas de trabalho. Realizar chamadas diárias em uma hora em que você normalmente não está trabalhando não é sustentável a longo prazo. Existem basicamente três métodos que podem ser usados para as Scrums diárias nessas situações: uma conferência única, reunião escrita e reunião regional. Veremos as vantagens e desvantagens de cada uma delas a seguir.

Teleconferência única Talvez a abordagem mais comum e aquela que é inicialmente tentada pela maioria das

q

equipes é fazer com que todos os participantes da equipe entrem juntos em um único telefonema. Para as equipes coincidindo em fusos horário uns dos outros, essa é uma excelente abordagem. Infelizmente, a abordagem se deteriora rapidamente quando o número de fusos horários aumenta. Eventualmente, as equipes mais amplamente

Tabela 4.3 Teleconferência única.

distribuídas rapidamente entendem ser necessária uma estratégia diferente para as suas Scrum diárias. Vantagens

Desvantagens

Similar à abordagem usada em equipes locais, então nada novo precisa ser mudado

Pode ser inconveniente para membros da equipe

Discussões envolvem toda a equipe

Não é sustentável se as pessoas precisam realizar ligações fora de seus horários de trabalho

Todo mundo aprende todas as pendências, o que leva a maior aprendizagem da equipe e um comprometimento de uma abordagem compartilhada

Reunião escrita Para minimizar o trabalho de horas de telefonemas para alguns locais, algumas equipes

q

abandonam reuniões diárias completamente. No entanto, sem querer desistir do valor da comunicação diária inteiramente, tais equipes normalmente substituem reuniões diárias por uma versão escrita da reunião. Os membros da equipe concordam em enviar um e-mail, atualizar uma página de wiki ou fazer uma entrada em outra ferramenta de colaboração assíncrona em que fornecem as mesmas informações que eles compartilhariam em um telefonema. Uma variação dessa abordagem é a realização de uma chamada de telefone em um momento que seja conve-


niente para o maior número de membros da equipe, com outros membros da equipe “par-

64

ticipando” através da apresentação de um relatório escrito. Isso é particularmente comum quando a maioria da equipe está localizada apenas com alguns membros remotos. Normalmente, essa abordagem não é indicada como técnica primária, mas pode ser usada para completar chamadas diárias, se a equipe decide que elas estão acontecendo demasiadamente, estão prejudicando a equipe que está trabalhando fora da sua hora de trabalho normal e, por isso, precisa reduzir a sua frequência.

Há características importantes de uma Scrum diária que são perdidas quando a

q

chamada é transformada em uma atualização diária escrita. Por exemplo, o compromisso assumido parece mais forte quando um membro da equipe diz: “Eu vou fazer isso hoje”, do que quando as mesmas palavras são escritas. Talvez isso seja porque a Tabela 4.4 Reunião escrita.

mensagem falada é um compromisso assumido na frente dos próprios colegas de trabalho, enquanto a mensagem escrita é um compromisso feito em privado.

Vantagens

Desvantagens

Sustentável a longo prazo

Problemas não são discutidos e podem ficar “adormecidos” por dias

Ajuda a resolver problemas de linguagem, incluindo sotaques

Não há realmente garantias de que as atualizações escritas vão ser lidas Os membros da equipe tendem a se importar menos com as responsabilidades que os outros assumiram no dia anterior

Reuniões regionais A terceira e última abordagem para a reunião de Scrum diária é ter um conjunto de reu-

q

niões regionais seguidas por algum esforço para compartilhar a questões-chave de cada uma dessas reuniões. Se uma equipe é dividida em duas cidades muito distantes, por exemplo, cada cidade pode ter sua própria reunião diária. Esse seria o caso, por exemplo, para uma equipe com membros em escritórios da empresa em São Francisco, nos EUA, e Londres, na Inglaterra, que possuem intervalos de horas de diferença. Às vezes, uma equipe distribuída tem alguns escritórios com sobreposição de horas de trabalho, além de um escritório mais remoto – nesses casos, os locais com horários sobrepostos podem ter um Scrum diário, já a localização mais remota teria sua própria reunião. As reuniões regionais, se todo mundo está presente em um escritório, ou de discagem em uma chamada entre as diversas cidades, são, então, geralmente seguidas por uma comunicação adicional, de modo que cada equipe está consciente do trabalho das outras equipes. Uma maneira de realizar essa comunicação é um telefonema com pelo menos um

q

representante de cada equipe.

Vantagens

Desvantagens

Reduz grandemente o estresse de trabalho em horas extras

Informação de uma reunião para outra pode estar incorreta ou incompleta, nem compartilhada na hora necessária

Permite o compartilhamento de informação chave em equipes locais

Pode levar para um sentimento de “nós” e “eles” entre equipes diferentes Nem todos se encontram presentes para todas as discussões


Tabela 4.5 Reuniões regionais.

65

Szcrum of Scrums O Scrum dos Scrums é usado por várias equipes para coordenar seu trabalho. Envolve

q

um representante de cada equipe, e acontece geralmente duas ou três vezes por semana. A frequência reduzida dessa reunião a torna menos problemática para uma equipe distribuída. Essa reunião dura quase sempre uma hora ou menos; portanto, uma equipe distribuída com qualquer sobreposição de horas em sua jornada de trabalho será capaz de facilmente programá-la. Os desafios surgem, naturalmente, quando a equipe é tão amplamente distribuída que se torna impossível compartilhar horários de trabalho comuns. Nesses casos, recomenda-se que as equipes usem uma das estratégias anteriores para o Scrum, como chamada única diária ou reuniões regionais. Quando um número reduzido de equipes está envolvido, uma única reunião geralmente é suficiente, já que os participantes da reunião podem encontrar algum tempo que será minimamente inconveniente para pessoas suficientes. Isso é mais fácil de fazer do que é para o Scrum diário por duas razões: primeiro, a

q

maioria dos Scrum dos Scrums não são diárias e, em segundo lugar, a maioria das equipes, ocasionalmente, mudam quem participa dessas reuniões.

Sprint reviews e retrospectivas Revisões de Sprint e retrospectivas compartilham características tanto das Scrums

q

diárias quanto das reuniões de planejamento da Sprint. Assim como reuniões de planejamento de Sprint, essas reuniões não são realizadas diariamente, então membros da equipe se sentem mais disponíveis para participar fora do horário normal de trabalho.

l

No entanto, assim como as daily Scrums, revisões de Sprint e retrospectivas são um pouco mais fáceis de planejar, porque elas são mais curtas do que uma reunião de planejamento do Sprint. Isso faz com que a tarefa de encontrar um momento certo adequado para a reunião seja relativamente fácil, já que equipes com sobreposição de horas de trabalho agendam essas reuniões durante a parte sobreposta de seus horários. Equipes cujas horas de trabalho quase se sobrepõem normalmente agendarão essas reuniões no final de um dia de trabalho para uns e no início para outros.

Dicas gerenciais Alguns pontos finais a considerar em equipes virtualmente discretas são os que seguem: 11 Decida como distribuir as equipes: uma equipe colaborativa em uma localidade ou equipes deliberadamente distribuídas; 11 Tente criar coerência; 11 Entenda as diferenças culturais significativas


11 Entenda as diferenças culturais pequenas;

66

11 Fortaleça as culturas funcionais e de equipe; 11 Comunique e estabeleça uma visão compartilhada; 11 Construa confiança ao enfatizar o progresso desde o começo do projeto; 11 Tente se reunir presencialmente; 11 Encoraje a comunicação lateral.

q

Se tanto a revisão e a retrospectiva foram curtas, alguns membros da equipe podem preferir agendá-las uma logo após a outra. Outras equipes podem preferir agendá-las um dia logo após o outro.

Coexistindo com outras abordagens Uma coisa é olhar para o desenvolvimento ágil de software em um tubo de ensaio; outra

q

é experimentá-lo no mundo real. No tubo de ensaio, metodologias ágeis como o Scrum são facilmente adotadas por todos os membros, e as realidades da política corporativa, economia, e não podem intrometer. No mundo real, contudo, todas essas questões desagradáveis não existem. Raramente é simples tomar a decisão de utilizar Scrum e, em seguida, ser capaz de fazê-lo sem outras restrições. Por exemplo, um projeto pode tentar Scrum desde que isso não interfira na certificação CMMI Nível 3 da organização. Outro projeto pode tentar experimentá-lo enquanto ele está na revisão preliminar de arquitetura e, em seguida, tem uma reunião para aprovar o design. Pode haver razões válidas para uma organização para colocar essas restrições sobre os projetos. Nesta sessão, estudaremos como um projeto Scrum é afetado quando se cruza com um processo sequencial. A seguir, consideramos o impacto da governança do projeto e como projetos Scrum podem coexistir com sucesso com abordagens de governança não ágeis. Finalmente, vamos explorar maneiras projetos Scrum podem cumprir com normas como a ISO 9001 ou CMMI.

Misturando Scrum e desenvolvimento sequencial Poucas organizações de grande porte desfrutarão do luxo de fazer todos os seus pro-

q

jetos com Scrum. A maioria será obrigada a suportar um período em que alguns projetos foram transferidos para Scrum, enquanto outros ainda não. Isso pode ser porque seria muito perturbador para a transição de toda a empresa de uma só vez, porque seria perturbador para fazer uma mudança processo no meio do curso para um projeto particular, ou qualquer número de outras razões. São basicamente três os cenários onde essa mistura pode acontecer: 11 Sequencial a princípio: a confluência de Scrum e desenvolvimento sequencial no início do projeto geralmente ocorrem quando uma organização tem obstáculos de aprovação do projeto. Livrar-se desses obstáculos requer geralmente que a equipe Scrum anule qualquer pendência em relação aos documentos e crie uma especificação, plano de projeto ou outro artefato que é necessário para aprovação. Depois que um projeto em cascata for aprovado, ele é executado como um projeto normal de Scrum; 11 Sequencial no final: quando as características de Scrum e sequenciais se encontram no fim do projeto, geralmente dizem respeito às fases de teste. Às vezes, essa conflutestadores ou a garantia de qualidade como um grupo separado que se engajou no final para verificar e validar o produto. Outras vezes, a característica sequencial no final ocorre quando há um link externo para um grupo de operações, por exemplo, se exige que alguns testes ocorram no final com um grupo externo ao time. Tipicamente, no final do projeto, a equipe tem se acostumado à sua nova forma ágil de trabalhar, por isso continua a usar o máximo de Scrum quanto possível, mesmo no final. Em outras palavras, a equipe continua a trabalhar em sprints, realizará reuniões de planejamento sprints, têm reuniões diárias, e assim por diante;


ência ocorre porque a organização só abraçou o Scrum “tentativamente”, e deixou os

67

11 Sequencial no meio: a maneira mais complicada em que Scrum tem de interagir com

q

o desenvolvimento sequencial é esta. Um exemplo comum disso é quando duas ou mais equipes devem trabalhar juntas para criar um único produto e pelo menos uma equipe delas está usando Scrum, e a outra está usando uma abordagem sequencial. A coordenação do trabalho e a comunicação frequente são geralmente as principais fontes de problemas quando essa disposição existe. A equipe sequencial prefere se comunicar por meio de reuniões e documentos que bloqueiam a interface, enquanto a equipe Scrum vai preferir deixar interfaces mais vagas e eleger uma comunicação informal, com interfaces e compromissos definidos de forma progressiva. A equipe Scrum que se encontra nessa situação geralmente acha útil atrair os gestores dos projetos sequenciais para participar de reuniões de planejamento do Sprint e para as reuniões diárias.

Governança Uma das razões pelas quais muitas organizações adotam uma abordagem sequencial

q

para o desenvolvimento de software é o encaixe natural entre uma sequência definida, as fases de desenvolvimento e a necessidade de supervisão do projeto. O objetivo da supervisão do projeto, comumente chamado de governança, é certificar-se de que um projeto não vai se extraviar. Governança eficaz do projeto pode, por exemplo, identificar um projeto que vai exceder seu orçamento, levando a conversas sobre se o projeto deve ser cancelado. Governança também pode identificar um produto que está à deriva muito longe de seus objetivos originais, um projeto que está a se desviar de um padrão arquitetural ou qualquer número de considerações de alto nível similares importantes para a organização. A equipe de software pode encontrar portas ou pontos de verificação de governança em uma variedade de situações: 11 Uma análise precoce de seus planos para o escopo, orçamento e cronograma; 11 A revisão de decisões de arquitetura e design; 11 Uma revisão quando o aplicativo está pronto para o sistema ou teste de aceitação do cliente; 11 Uma revisão quando o produto pode ser entregue a uma organização de apoio; e assim por diante. Esses postos de controle muitas vezes podem causar estragos no desejo de uma equipe de software de usar Scrum, pois eles não são adequados para o trabalho feito de forma iterativa. O primeiro passo para conciliar a necessidade de governança do projeto e o desejo de

q

usar Scrum é perceber que a governança do projeto e gerenciamento de projetos não Fundamentos do Scrum

são a mesma coisa. Não é um problema separar a governança do projeto e a sua gestão.

68

Ao separá-los, na verdade estamos permitindo à equipe alcançar a capacidade de ter pontos de controle de alto nível para fornecer a supervisão necessária, permitindo ainda a liberdade de gerir a si mesmo e ao projeto de forma ágil.

Passos para rodar o projeto Scrum com governança não ágil:

q

1. Negocie e deixe claro quais são as expectativas desde o princípio. 2. Ajuste os seus relatórios às expectativas atuais. 3. Convide os membros do comitê de governança para o processo Scrum. 4. Nada convence como sucesso – quando obtiver sucesso, referencie o sucesso.

Conformidade a padrões Nem todas as equipes ou mesmo departamentos de desenvolvimento de software têm

q

o luxo de ter o controle completo sobre seu processo de desenvolvimento. Por exemplo, clientes terceirizados durante o desenvolvimento do contrato muitas vezes requerem que fornecedores sejam certificados CMMI Nível 5, o que requer que os desenvolvedores de software sigam algumas das melhores práticas estabelecidas. Além disso, alguns produtos de software são entregues em setores regulados e cumprem com normas como a ISO 9001. Nenhum desses padrões prescreve um ciclo de vida que é contraditório como o Scrum. Como cumprir normas na organização raramente é opcional, equipes Scrum devem preocupar-se com a melhor forma de cumpri-las, começando em alguns casos com a questão de saber se isso vai ser possível com um processo Scrum. Nesta sessão, vamos estudar como equipes de Scrum podem ficar em conformidade com ISO 9001 e CMMI, dois dos padrões mais comuns com que Scrum precisa coexistir. A partir deles, podemos generalizar algumas estratégias de enfrentamento em outras situações de conformidade.

ISO 9001 A Organização Internacional de Normalização (ISO) mantém o padrão 9001, que normal-

q

mente é designado em sua inteireza como ISO 9001:2000 ou ISO 9001:2008, ambos os quais indicam o ano de uma versão específica do padrão. A certificação ISO 9001 não se destina a garantir que os produtos de uma organização atinjam um nível de qualidade específico. Em vez disso, a certificação indica que a organização segue um conjunto de práticas formais no desenvolvimento de seus produtos. Uma grande parte do esforço em conformidade com a ISO 9001 é a criação de um sistema de gestão da qualidade, que geralmente é um longo documento ou conjunto de páginas da web que descrevem as práticas de qualidade seguidas pela organização. Primavera Systems, desenvolvedora de sistemas de gerenciamento de projetos e portfólio, criou o seu sistema de gestão da qualidade ao longo de um período de dez meses. workshop incluiu uma representação multifuncional dos desenvolvedores. Primavera já tinha experiência substancial com práticas ágeis no momento em que iniciou o seu esforço ISO 9001. Em tal ambiente, seria natural para os funcionários se preocuparem com a perda de agilidade com a introdução de ISO 9001. Bill McMichael, da Primavera, e Marc Lombardi, um consultor com experiência em ISO 9001, trabalharam juntos por iniciativa e chegaram à conclusão de que a documentação não diminuiu a sua agilidade. O mantra foi prover apenas documentação suficiente e referências que fossem realmente úteis para ajudar com a garantia do processo que já existisse.


A empresa realizou 30 oficinas para documentar seus processos existentes, e cada

69

CMMI Desde que o primeiro projeto ágil surgiu do lodo primordial, as empresas têm se pergun-

q

tado se as metodologias ágeis são compatíveis com o Capability Maturity do Instituto de Engenharia de Software Model Integration (CMMI). Como medida de algumas maneiras de quanto processo de uma organização tem (ou pelo menos como muito do que tem sido definida), o CMMI e seu antecessor, o Capability Maturity Model Software (SWCMM), são muitas vezes vistos como formas de pesos pesados de desenvolvimento de software e a antítese do desenvolvimento ágil. A incorporação de Scrum em um 5 processo CMMI Nível mostra uma solução para um problema comum com implementações do CMMI. Ao prosseguir com um nível CMMI particular, muitas organizações se esquecem de que o objetivo final é melhorar a forma como eles constroem software (e, presumivelmente, portanto, quais os produtos vão entregar), em vez de tornar-se com focos em preencher deficiências supostas acordo com a documentação CMMI sem a preocupação de saber se as mudanças vão melhorar o processo ou os seus produtos. Esse problema pode ser eliminado quando as metas do CMMI são combinadas com o “valor concentrado” na mentalidade inerente Scrum, de entregas constantes. O Scrum garante que os processos estão implementados eficientemente e o CMMI garante que todos os processos relevantes estão considerados.

Conseguindo conformidade De maneira geral, conseguimos estabelecer que Scrum é compatível com ISO 9001 e

q

CMMI, tanto teoricamente quanto empiricamente. Para tornar Scrum conforme a sua organização, um passo a passo pode ser seguido: 1. Coloque esforço suficiente no Product Backlog. 2. Tente deixar o Product Backlog conforme padrões previamente existentes na organização. 3. Considere o uso de checklists. 4. Automatize testes e a geração de builds. 5. Use uma ferramenta de gerenciamento de projetos ágeis. 6. Mova-se devagar, mas de forma estável. 7. Trabalhe com seu auditor no processo ao qual você deseja ficar conforme. 8. Traga ajuda externa, se necessário, como um Scrum Master.

Recursos humanos, instalações e o PMO Para alcançar o sucesso a longo prazo com Scrum, as implicações de se tornar ágil devem ser transferidas para outras partes da organização. Quando isso não for feito, gravidade organizacional – ou seja, as influências organizacionais que formaram a orga Fundamentos do Scrum

nização no formato em que ela estava antes do início da transição – se inicia. Transições

70

Scrum já foram interrompidas ou completamente paradas porque ignoraram o impacto de se tornar ágeis em grupos de fora do desenvolvimento. Isso resulta em situações como essas:

q

11 Recursos humanos: equipes Scrum começam a fazer muito bem até que chega o

q

tempo de revisão anual. De repente, todo mundo percebe que eles serão novamente avaliados e a receber aumentos, com base exclusivamente no desempenho individual. A revisão anual pode ter um campo para avaliar se um indivíduo se dá bem com os outros, mas no final do dia contribuições e o heroísmo individual é o que é importante em termos de aumentos e promoções. É impossível pensar em adotar um processo fundado sobre uma preferência por “indivíduos e interações sobre processos e ferramentas” sem envolver o departamento de recursos humanos. Na organização típica, esse grupo pode ter ainda mais influência sobre como as pessoas percebem seus trabalhos e atuar neles do que os gerentes funcionais desses indivíduos; 11 Instalações: é muito mais fácil ser ágil quando toda a equipe está no mesmo local. Mas quando um grupo de instalações torna tão tudo mais difícil, ou quando se impede que as equipes Scrum usem o espaço da parede para os gráficos de manejo e outros dados importantes do projeto, as equipes se tornam desmoralizadas. Torna-se mais difícil manter o impulso de se tornar melhor em Scrum quando parece que todo mundo está contra. O ambiente físico em que trabalhamos tem uma influência direta sobre nós. Considere as mensagens conflitantes enviadas quando uma empresa proclama “as pessoas são nosso maior patrimônio”, enquanto o conjunto de instalações proíbe pendurar gráficos de burndown nas paredes. A verdadeira mensagem é alta e clara: “As paredes são um bem maior.”; 11 PMO: sem pensar em como seu projeto se refere a um PMO existente, uma equipe Scrum inicia com uma atitude de “dane-se a papelada e processo”. Isso cria um inimigo no PMO, um grupo que já estava inquieto sobre os experimentos iniciais da organização com Scrum. O PMO responde convencendo gerência do departamento que não tem problemas com Scrum, desde que ele seja complementado por um conjunto de documentos e práticas. O PMO muitas vezes tem um enorme peso político e experiência do projeto. Ao conseguir que essa parte da organização esteja de acordo com Scrum, não só se evita uma possível fonte de resistência, mas também se beneficia da sua experiência. Os membros do PMO podem se tornar guardiões de auto-organização, melhoria contínua, propriedade, comunicação, experimentação, colaboração e outros valores. Quando Scrum é erroneamente encarado apenas como uma mudança dentro do grupo de desenvolvimento, a gravidade organizacional criada pelos departamentos de fora da TI pode puxar o grupo de desenvolvimento de volta para onde tudo começou. É possível ignorar as implicações do Scrum sobre esses grupos e ser bem-sucedido, por algum tempo. Eventualmente; porém, será necessário envolver com eles para criar uma tran-

É fácil ver os recursos humanos, instalações e do escritório de gerenciamento de projeto como obstáculos a serem superados. Uma abordagem mais produtiva é ver cada um como um aliado para ser inscrito. Embora uma relação conflituosa possa funcionar por um tempo, o sucesso a longo prazo requer o apoio de toda a organização. O caminho para se tornar ágil pode ser longo; quando for possível, é melhor fazer amigos, em vez de inimigos.


sição bem-sucedida, a longo prazo.

71

Atividades Cada Sprint é um bloco de iteração que segue um ciclo PDCA e entrega um incremento de funcionalidades prontas para serem incorporadas no software. Um ciclo PDCA, também conhecido como o círculo de Deming, é um método de gerenciamento iterativo de quatro


passos usado em gestão para o controle e melhoria contínua de processos e produtos.

72

Rodrigo Alves Costa atualmente é professor efetivo do curso de Ciências da Computação da Universidade Estadual da Paraíba e doutorando em Ciências da Computação na Universidade Federal de Pernambuco (UFPE). Possui mestrado em Ciências da Computação pela UFPE (2010), MBA em Gerenciamento de Projetos pela Fundação Getúlio Vargas (2007) e graduação em Ciências da Computação pela UFPE (2005). É certificado Project Management Professional (PMP) pelo Project Management Institute (PMI) (2006). Tem vasta atuação profissional, destacando-se em funções como executivo de projetos, analista de sistemas, engenheiro de sistemas, de segurança e de software em empresas como IBM, Siemens, Motorola e C.E.S.A.R. Também é autor de livros na área de administração organizacional com foco em projetos, entre os quais Gerenciamento de Projetos de TI, e colaborador de cursos de gestão empresarial em tecnologias da informação e comunicação em diversas organizações e instituições de ensino, sendo um dos idealizadores do currículo de governança da Rede Nacional de Pesquisa, vinculado à ESR/RNP/CNPQ. Foi bolsista CNPQ durante o mestrado e a graduação (PIBIC), e atualmente está vinculado aos diretórios de pesquisa da entidade, no grupo de estudos em Segurança Computacional da UFPE. Pesquisador na área de Ciência da Computação, com ênfase em segurança computacional e teoria da computação, e na área de Gerenciamento de Projetos, com ênfase em gerenciamento de projetos virtuais e planejamento estratégico orientado por TIC. É membro entusiasta do PMI, membro da Association for Computing Machinery (ACM) e da Sociedade Brasileira de Computação (SBC).

LIVRO DE APOIO AO CURSO

O curso aborda os principais conceitos do Scrum, apresentando aos alunos os fundamentos do gerenciamento de projetos ágeis, as vantagens e desvantagens da utilização desta metodologia de trabalho e como o processo de transição para esta prática ocorre nas organizações. dologia Scrum, compreendendo seus processos, papéis, entregas acontecem.

Fundamentos do Scrum

Recommend Documents