Fundamentos do Scrum

(1)

Rodrigo Alves Cost

a

Fundamentos

(2)

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.

(3)

Rodrigo Alves Costa

Fundamentos

(4)

(5)

Fundamentos

do Scrum

Rodrigo Alves Costa

Rio de Janeiro

Escola Superior de Redes

2016

(6)

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 encon-trado 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.

(7)

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

(8)

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 beneficia-riam 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

(9)

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

(10)

(11)

Ca pí tu lo 1 - I nt ro du ção

obj

et

ivo

s

co

nc

ei

to

s

1 Introdução

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.

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

q

Existe nas organizações uma constante sinergia de pressões e forças que criam ameaças 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.

q

Assim, a informação é o canal que dá acesso ao conhecimento e que contribui para a 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.

q

Nesse contexto, independente da fonte, o valor ou a validade da informação, as orga-nizaçõ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.

(12)

Fu nd ame nt os d o S cr um

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.

q

É nesse contexto que surge a ciência da gestão da informação que, para Siqueira 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.

q

É necessário utilizar, produzir e adquirir ferramentas de software para gerenciar bases de dados que cresçam à medida que a informação se transforma e se torna disponível e relevante organizacionalmente.

Crise do software

q

Paralelamente a essa necessidade pela produção de software relevante, que existe até os dias de hoje, um termo acerca de sua produção foi firmado nos primeiros dias da ciência da com-putaçã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 compu-tadores, 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 um problema leve, e agora temos computadores gigantescos, a programação tornou-se um problema igualmente gigantesco.”

(13)

q

As causas da crise do software estão ligadas à complexidade geral do hardware e o pro-cesso de desenvolvimento de software. A crise manifesta-se de várias maneiras: 1 Projetos em execução que estouram o orçamento;

1 Projetos que atrasam;

1 Software que, depois de entregue, se mostrou muito ineficiente; 1 Software de pouca qualidade;

1 Software que, muitas vezes, não atendeu aos requisitos;

1 Projetos se mostraram incontroláveis com um código difícil de manter; 1 Software nunca foi entregue.

A ideia principal por trás da crise é que as melhorias no poder de computação sobre-pujaram 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?

q

Em uma realidade de crise, equipes ágeis de sucesso têm produzido software de melhor 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 expe-rimentado 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 experi-mentar maior visibilidade do processo de desenvolvimento, o que leva a maior previsibi-lidade 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:

1 Liberou 94% mais funcionalidades;

1 Entregou 38% mais funções por desenvolvedor;

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

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 tran-siçã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 não só por parte dos desenvolvedores, mas de toda a organização. Não se trata apenas de

(14)

uma mudança das práticas, é necessário mudar a mentalidade e a forma de trabalho esta-belecida. O objetivo deste curso, portanto, não é apenas mostrar como fazer essa transição adequadamente, mas também como obter sucesso no longo prazo.

q

Toda mudança é difícil. Mudanças maiores podem ser ainda mais difíceis. No entanto, 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 exata-mente onde nós queremos acabar e, em segundo, saber exataexata-mente 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 grupos afetados por uma mudança para o Scrum, há mais chance para aumentar a resis-tência e certamente mais chance de problemas, o que pode tornar a transição para Scrum ainda mais difícil.

Muitos testadores, por exemplo, aprendem ao longo dos anos que o seu trabalho é testar 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 progra-madores precisam desaprender esses comportamentos. Testadores passam a entender que o teste é também entender que o sistema precisa estar em conformidade com as necessi-dades 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.

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.

l

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

(15)

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 for-maçã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.

q

Podemos listar as seguintes razões porque uma transição para um processo ágil como Scrum é importante:

Aumento da produtividade e redução de custos

Infelizmente, não há medidas universalmente padronizadas para medição de produ-tividade. 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 todas as características são do mesmo tamanho.

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.

q

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.

(16)

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.

q

Como se pode ver, a maioria dos pontos encontra-se acima da média da indústria, com uma boa parte dos projetos mais de um desvio padrão acima de um nível de produtivi-dade dessa média.

Alto Produtividade Baixo Menor Tamanho do projeto Maior Projetos ágeis +/- 1 Desvio padrão Média

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.

q

De acordo com o levantamento de Rico, com base em estudos de caso de equipes ágeis 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.

Categoria Melhoria Mais

Baixa Melhoria Média Melhoria Mais Alta

Produtividade 14% 88% 384%

Custo 10% 26% 70%

Figura 1.1

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

verificadas com ágil por categoria.

(17)

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 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 entrevis-tados relataram que a “moral” foi melhorada (44%) ou significativamente melhorada (30%).

Time to Market mais r

ápido

q

Equipes ágeis tendem a lançar seus produtos mais rapidamente do que as equipes tradi-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.

Time to market Média Projetos ágeis Alto Baixo Menor Maior Tamanho do projeto +/- 1 Desvio padrão

Melhoria na satisfação das partes interessadas

q

Tendo em conta todos os benefícios de processos ágeis até agora, não é surpreendente 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 pro-cesso á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.

q

No estudo da VersionOne, 92% dos participantes consideraram que as metodologias ágeis melhoraram a capacidade de gerenciar mudanças de prioridades.

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

l

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

(18)

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 desen-volvimento 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 ten-tativa 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.”

q

Assim, ao adotar o Scrum, é interessante identificar continuamente os benefícios 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

q

Todas as práticas do Scrum estão cravadas em um esqueleto de processo incremental. 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 Sprint Backlog Product Backlog 2 – 4 semanas Incremento no Produto

q

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 trans-formar 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 é conhe-cido 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 opor-tunas para que o projeto possa ser feito.

Crie 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.

l

Figura 1.3 O processo Scrum.

(19)

q

O coração de Scrum reside na iteração. A equipe lança um olhar sobre os requisitos, con-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.

q

1 Product Owner: o Product Owner deve ser a pessoa com visão, autoridade e dispo-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 necessi-dade de microgerenciar. Ao mesmo tempo, Product Owners devem estar disponíveis para responder questões da equipe;

q

1 Scrum Master: o Scrum Master age como um facilitador para o Product Owner e 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;

q

1 Equipe: de acordo com os criadores do Scrum, “a equipe é totalmente autogeren-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 sof-tware, arquitetos, programadores, analistas, especialistas em qualidade, testadores e desig-ners 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 os objetivos da Sprint.

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

q

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.

(20)

q

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 funciona-lidade, 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ça-mentos propostos.

O Product Backlog priorizado é um ponto de partida, e os seus conteúdos, as priori-dades, 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 funcionali-dade implementada.

Todo o trabalho é feito em Sprints. Cada Sprint é uma iteração de 30 ou 15 dias conse-cutivos 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 diaria-mente 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.

(21)

A cada

24 horas

Sprint

Backlog da Sprint

Selected Product Backlog

Backlog do Produto: Emergente, requisitos priorizados

Nova funcionalidade demonstrada ao ﬁnal da Sprint

Visão: ROI esperado, lançamentos, Millestore

Scrum diário

Artefatos

q

Scrum introduz alguns novos artefatos. Estes são utilizados em todo o processo de scrum e são descritos a seguir.

Product Backlog

q

Os requisitos para o sistema ou produto que está sendo desenvolvido pelo projeto estão 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 que seja adequado, competitivo e útil. Enquanto o produto existir, o Product Backlog existe. Um exemplo pode ser encontrado na tabela 1.2:

Product Backlog

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

Figura 1.4

Visão geral do processo do Scrum.

Tabela 1.2

(22)

Sprint Backlog

q

O Sprint Backlog define o trabalho (ou as tarefas que uma equipe define para transformar os 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

Horas de trabalho restantes por dia

1 2 3 4 5 6 7 8 9 10 11 12

Release do

serviço Rosa João em curso 8 8 8 8 8 8 8 8 8 8 8 8

Gerar docu-mentação do SDK Pedro não iniciado 16 16 16 16 16 16 16 16 16 16 16 16 Disponibilizar documen-taçã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

Documen-tação de branch: fontes e builds Pedro não iniciado 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 64 58 50 42 34 26 18 10 2 2 2 2

Incremento potencialmente utilizável de funcionalidade de produto

q

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.

Tabela 1.3 Sprint Backlog. D es cr iç ão d a A ti vid ade O ri ge m Res po ns áv el St atu s

(23)

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 implemen-tada para operação do usuário seja escrita em um código bem documentado e disponibili-zada em arquivos de ajuda ou em outra documentação de usuário acordada.

Visão Scrum

q

Scrum é uma ferramenta para desenvolver e manter produtos complexos. A ciência do Scrum está por trás do desenvolvimento de software complexo.

Obviamente tal fato não é muito surpreendente, porque o universo é cheio de complexi-dades. 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.

q

No entanto, é impossível ignorar a complexidade no desenvolvimento de software. Seus 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.

q

Dessa forma, Scrum se propõe a ser visto como um quadro no qual as pessoas podem 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 é: 1 Leve (Lightweight);

1 Simples de entender; 1 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 pro-dutos 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.

q

As regras do Scrum unir os eventos, papéis e artefatos, que rege as relações e interações entre eles. As regras de Scrum são descritas ao longo desse documento. Táticas espe-cí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”.

(24)

Transparência

q

Aspectos significativos do processo devem ser visíveis para os responsáveis pelo resul-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:

1 Uma linguagem comum referindo-se ao processo deve ser partilhada por todos os participantes;

1 Aqueles que executam o trabalho e aqueles que aceitam o produto do trabalho devem compartilhar uma comum definição de “Pronto”.

Inspeção

q

Usuários de um projeto do Scrum devem frequentemente inspecionar artefatos pro-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 qualifi-cados no trabalho.

Adaptação

q

Se um inspetor determina que um ou mais aspectos de um processo se desvia dos 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 pos-sível para impedir desvios futuros.

Os eventos prescritos pelo Scrum para garantir inspeção e adaptação são: 1 Planejamento da Sprint;

1 Scrum diária; 1 Revisão da Sprint. 1 Retrospectiva da Sprint

Scrum e processos de desenvolvimento

q

A abordagem Scrum para o desenvolvimento de software ágil marca uma saída radical das abordagens tradicionais. Scrum e outros métodos ágeis foram inspirados pelas defi-ciências daquelas abordagens, e enfatizam em colaboração, software funcional, auto-gestã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.

Scrum é parte do movimento ágil. Esse é uma resposta à falha da maioria dos para-digmas 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,

(25)

Extreme Programming, Desenvolvimento Orientado a Funções, Scrum e outros. Tipica-mente, 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 inte-ressadas 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.

q

Assim, para entender a base na teoria e prática do Scrum, é necessária uma mentalidade que possibilite:

1 Controlar até mesmo os mais complexos projetos;

1 Gerir eficazmente os requisitos do produto desconhecidos ou mudança;

1 Simplificar a cadeia de comando com as equipes de desenvolvimento de autogestão; 1 Receber mais claras especificações e feedback de clientes;

1 Reduzir grandemente o tempo de planejamento de projeto e ferramentas necessárias; 1 Construir e lançar produtos em ciclos de 30 dias para que os clientes obtenham

resul-tados mais cedo;

1 Evitar erros inspecionando regularmente relatórios sobre os projetos e realizar ajuste fino constantemente sobre estes;

1 Apoiar várias equipes trabalhando em um projeto em larga escala a partir de muitas localizações geográficas;

1 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?

(26)

Introduzindo um processo ágil em uma organização

q

O Manifesto Agil estabelece uma base comum para esses processos: valorizar mais 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 ativi-dades que a equipe pode finalizar na próxima sprint. Durante a sprint, a equipe é acom-panhada 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 cons-tantemente 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

q

A maioria dos desenvolvedores respondem à introdução de um processo ágil com uma combinação de ceticismo, entusiasmo e otimismo cauteloso. Outros desenvolvedores, no entanto, tendem a resistir à mudança ou simplesmente iniciar o projeto sem preme-ditaçã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 efetivi-dade e o valor dessas ativiefetivi-dades, 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

q

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.

(27)

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 infor-mados de que uma tarefa vai demorar mais do que se pensava originalmente.

q

A transição gradual de um processo mais pesado para um processo ágil pode tornar a mudança mais fácil para a equipe de desenvolvimento. Algumas equipes, em seu pri-meiro 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:

1 Prototipação; 1 Captura de requisitos; 1 Análise e design; 1 Implementação; 1 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 informali-dade do processo ágil, eles gradualmente abandonam o conceito de tipos de Sprint.

Scrum Escalável

q

Quando muitas equipes trabalham no mesmo produto, eles normalmente usam um 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 impedi-mentos organizacionais.

q

A ideia do Scrum é eliminar papéis de coordenação como gestor de projetos e PMO, pois 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.

Enquanto um cenário de agilidade ótima requer mudanças fundamentais na estrutura 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 tradi-cional. Recomenda-se que organizações maiores que estão comprometidas com valores e princípios do Manifesto Ágil aprendam sobre LeSS (Large Scale Scrum).

(28)

Atividades práticas

e

Cenário para escolha sobre um processo a ser adotado

(29)

Ca pí tu lo 2 - O S cr um

obj

et

ivo

s

co

nc

ei

to

s

2 O Scrum

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

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

Processo de software

q

Em uma visão geral do processo/projeto de desenvolvimento de software, podemos subdividi-lo em cinco fases genéricas que independem da área de aplicação, tamanho ou complexidade do projeto: 1 Especificação; 1 Projeto; 1 Implementação; 1 Validação; 1 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 pro-duzir 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

q

É uma das etapas iniciais do projeto, pois é onde procuram-se identificar funcionali-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.

(30)

q

É composta por três atividades principais, que são executadas, independentemente dos métodos utilizados, porém podem variar de acordo com o paradigma usado. As suas tarefas são:

1 Engenharia de sistema: estabelecimento de uma solução geral para o problema, envolvendo questões de tecnologia e equipamento;

1 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; 1 Especificação de sistema: descrição funcional do sistema. Pode incluir um plano de

testes para verificar adequação.

Fase de projeto

q

O projeto é finalizado quando seus objetivos propostos são alcançados e quando se encontra estruturado, em termos de arquitetura, interface e técnicas. Suas atividades são: 1 Projeto arquitetural: aqui se desenvolve um modelo conceitual para o sistema,

com-posto por módulos mais ou menos independentes;

1 Projeto de interface: onde cada módulo tem sua interface de comunicação estudada e definida. Pode resultar em um protótipo;

1 Projeto detalhado: onde os módulos em si são definidos e, possivelmente, traduzidos para pseudocódigo.

Fase de implementação

q

Também chamada de fase de desenvolvimento ou codificação. É a fase que define como 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 metodolo-gias precisam ser realizadas, tais como:

1 Projeto de software: parte central do desenvolvimento, que mostra o que e como será desenvolvido;

1 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

q

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 ativi-dades são:

1 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 básicos do sistema;

1 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.

(31)

Fase de manutenção

q

Considerada a fase final, onde se analisa todo o produto. Tem como foco principal as 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.

q

São quatro os tipos de modificações que podem ocorrer:

1 Manutenção corretiva: visa corrigir os defeitos que ocorreram durante a fase de desenvolvimento;

1 Manutenção adaptativa: modifica o software para adaptá-lo a alterações no ambiente externo;

1 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;

1 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.

q

O que se pode dizer é que todo modelo de software deve levar em consideração as fases 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 anda-mento 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 repre-sentaçã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 sof-tware de alta qualidade a um custo relativamente baixo.

Metodologias de desenvolvimento tradicionais:

vantagens e desvantagens

q

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 acompa-nhada 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 melhor visualização, sempre com foco na melhor qualidade final do produto.

(32)

q

De acordo com Sommerville, metodologia de desenvolvimento é o “conjunto de práticas recomendadas para o desenvolvimento de softwares, sendo que essas práticas geral-mente 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 bas-tante 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 desen-volvimento 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

q

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 desenvol-vimento 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: 1 Gerenciamento de requisitos: para garantir que as mudanças nos requisitos, que

são comuns após o início do desenvolvimento, sejam administradas em um projeto desenvolvimento iterativamente;

1 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 pro-blema no fim do projeto;

(33)

q

1 Gerenciamento de riscos: a cada iteração, é possível analisar pontos críticos e pla-nejar estratégias para não perder tempo durante o desenvolvimento;

1 Testes: são realizados no fim de cada módulo, permitindo que erros e não conformi-dades 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

q

Na última década, um novo segmento da comunidade da Engenharia de Software vem defendendo processos simplificados, com foco nas pessoas que compõem o processo e, principalmente, no programador. Também chamada de metodologia de desenvol-vimento 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 veloci-dade de desenvolvimento. Arquitetura / Projeto Prototipação Validação do cliente Implantação Levantamento Requisitos Desenvolvimento Testes Figura 2.1 Fases de uma metodologia tradicional.