UNIVERSIDADE FEDERAL FLUMINENSE
KATIENE OLIVEIRA DE SANTANA
METODOLOGIAS ÁGEIS PARA DESENVOLVIMENTO DE
SOFTWARE: UM EXEMPLO REAL DE USO DA METODOLOGIA
SCRUM
Niterói
2017
KATIENE OLIVEIRA DE SANTANA
METODOLOGIAS ÁGEIS PARA DESENVOLVIMENTO DE
SOFTWARE: UM EXEMPLO REAL DE USO DA METODOLOGIA
SCRUM
Trabalho de Conclusão de Curso submetido ao Curso de Tecnologia em Sistemas de Computação da Universidade Federal Fluminense como requisito parcial para obtenção do título de Tecnólogo em Sistemas de Computação.
Orientador:
ALTOBELLI DE BRITO MANTUAN
NITERÓI
2017
Bibliotecária responsável: Fabiana Menezes Santos da Silva - CRB7/5274
S231m Santana, Katiene Oliveira de
Metodologias ágeis para desenvolvimento de software : um exemplo real de uso da metodologia SCRUM / Katiene Oliveira de Santana ; Altobelli de Brito Mantuan, orientador. Niterói, 2017.
82 f.
Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)-Universidade Federal Fluminense, Instituto de Computação, Niterói, 2017.
1. Metodologia. 2. Gestão de processos de negócio. 3. Produção intelectual. I. Mantuan, Altobelli de Brito,
orientador. II. Universidade Federal Fluminense. Instituto de Computação. III. Título.
-KATIENE OLIVEIRA DE SANTANA
METODOLOGIAS ÁGEIS PARA DESENVOLVIMENTO DE
SOFTWARE: UM EXEMPLO REAL DE USO DA METODOLOGIA
SCRUM
Trabalho de Conclusão de Curso submetido ao Curso de Tecnologia em Sistemas de Computação da Universidade Federal Fluminense como requisito parcial para obtenção do título de Tecnólogo em Sistemas de Computação.
Niterói, 10 de novembro de 2017. Banca Examinadora:
_________________________________________ Prof. Altobelli de Brito Mantuan, MSc. – Orientador
UFF – Universidade Federal Fluminense
_________________________________________ Prof. Jean de Oliveira Zahn, MSc. - Avaliador
Dedico este trabalho à minha mãe, que sempre batalhou pelo meu sucesso e soube respeitar as minhas escolhas.
AGRADECIMENTOS
A Deus, por me dar força nas inúmeras vezes em que pensei em desistir.
Ao meu orientador Altobelli pelo estímulo e atenção que me concedeu durante o curso.
Ao meu amigo José Ronaldo, pela paciência em explicar inúmeras vezes as matérias de programação e não me deixar desistir quando a compreensão dos trabalhos parecia impossível para mim.
À Ana Lamoglia, que mais do que minha gerente no trabalho, se tornou uma segunda mãe, sempre me lembrando da responsabilidade e importância da conclusão desse curso para minha carreira profissional.
À minha mãe e minha família, pelas orações, apoio e educação dedicados a mim todos esses anos.
E finalmente a todos aqueles que direta ou indiretamente contribuíram para a realização deste trabalho.
“Falta de tempo é desculpa daqueles que perdem tempo por falta de planejamento.”. Albert Einstein
RESUMO
O mundo empresarial passou por diversas transformações ao longo dos últimos anos em decorrência de crises econômico-financeiras, problemas sociopolíticos e a principal delas, o surgimento de novas oportunidades de negócio como resultado da tecnologia ao alcance de todos. Os “novos negócios” implicaram numa mudança de cultura das empresas, tornando evidente a necessidade de controle dos projetos de maneira mais rigorosa e organizada, a fim de garantir entregas eficazes e aderentes às necessidades do mercado. Surgiram assim, inúmeras metodologias voltadas para o gerenciamento de projetos, como por exemplo, o RUP (mais tradicional e completo) e a recentemente difundida, metodologia Ágil (mais flexível), ambas perfeitamente aplicáveis ao desenvolvimento de softwares e aplicações. Focada no desenvolvimento iterativo, ou seja, com pequenas entregas, a metodologia ágil tem diferentes processos, sendo o SCRUM, o mais utilizado atualmente. Este trabalho visa descrever a aplicabilidade desse framework no desenvolvimento de uma aplicação WEB, apresentando as fases necessárias e os papéis de cada recurso envolvido com o projeto. Combinada à metodologia SCRUM também serão utilizadas duas técnicas para controle das atividades dos sprints: o KANBAN (que nada mais é do que um quadro de trabalho simples, com a descrição das atividades) e o Trello (ferramenta online, mais atual e voltada para as necessidades “real time”). Também serão discutidos / apresentados os artefatos necessários em cada fase da metodologia SCRUM, e como esse processo de desenvolvimento pode agregar valor ao negócio do cliente quando da entrega do produto final.
ABSTRACT
The business world underwent several changes over the last few years as a result of economic and financial crises, sociopolitical problems and the main one, the emergence of new business opportunities as a result of technology available to all. The "New business" implied a change in corporate culture, making evident the need for more rigorous and organized control of projects in order to ensure effective and adherent deliveries to market needs. Thus, numerous methodologies for project management have emerged, such as the RUP (more traditional and complete) and the recently disseminated Agile methodology (more flexible), both of which are perfectly applicable to the development of software and applications. Focused on iterative development, in other words, with small deliveries, the agile methodology has different processes, with SCRUM being the most used today. This work aims at describing the applicability of this framework in the development of a WEB application, presenting the necessary phases and the roles of each resource involved with the project. Combined with the SCRUM methodology, two techniques will be used to control sprints activities: KANBAN (which is nothing more than a simple frame of work with a description of activities) and Trello (the most current online tool for “real time” needs). The necessary artefact will also be discussed / presented in each phase of the SCRUM methodology, and how this development process can add value to the client's business when the final product is delivered.
LISTA DE ILUSTRAÇÕES
Figura 1 - Fases do Modelo Cascata. Fonte Oliveira [5]. ... 21 Figura 2 - Fases do RUP. Fonte VASCO [6]. ... 22 Figura 3 - Fases do SCRUM. Fonte BRQ [11]. ... 28 Figura 4 - Aproveitamento do software pelos clientes após implantação. Fonte Silva
[13]. ... 30 Figura 5 - Desafios apontados pelas empresas para adoção da Metodologia Ágil.
Fonte VersionOne [12]. ... 31 Figura 6 - Utilização dos frameworks de Metodologia Ágil pelas empresas. Fonte
VersionOne [12]. ... 32 Figura 7 - Grandes empresas que utilizam a metodologia SCRUM. Fonte Menescal
[17]. ... 36 Figura 8 - Estrutura base para aplicação do framework SCRUM. Fonte Vieira [20]. . 38 Figura 9 - Funcionamento da Metodologia SCRUM. Fonte Garrido [21]. ... 39 Figura 10 - Eventos que fazem parte da metodologia SCRUM. Adaptado de
Menescal [17]. ... 44 Figura 11 - Artefatos gerados na metodologia SCRUM. Adaptado de Menescal [17]. ... 51 Figura 12 - Modelo para confecção de Story Card com base em exemplo encontrado
na literatura [17]. Os textos grifados de vermelho representam as respostas às perguntas que orientam a confecção do Card. Fonte Menescal [17] e MJV [23]. ... 53 Figura 13 - Exemplo de documento “Definition of Done” para a implantação da Sprint
1, definida na Product Backlog descrita neste trabalho. ... 57 Figura 14 - Exemplo de confecção de um Burndown Chart com análise interpretativa.
Fonte BRQ [11]. ... 58 Figura 15 - Exemplos de Gráficos de Burndown para acompanhamento do
Figura 16 - Exemplo de quadro SCRUM básico implementado através da ferramenta KANBAN. Fonte BRQ [11]. ... 61 Figura 17 - Exemplo de organização do KANBAN com controle de cores e raias.
Para as tarefas de desenvolvimento foram utilizados cartões amarelos e para as tarefas relacionadas à correção de erros, foram utilizados cartões vermelhos, a fim de enfatizar a urgência. ... 62 Figura 18 - Exemplo de estruturação do KANBAN organizando as raias por recursos
(time de desenvolvimento). Fonte MJV [23]. ... 62 Figura 19 - Exemplo de estruturação do KANBAN organizando as atividades dos
recursos (time de desenvolvimento) de acordo com cores específicas. Fonte MJV [23]. ... 63 Figura 20 - Exemplo de SCRUM Board confeccionada via Trello, para gerenciamento
da Sprint Backlog da empresa Mindmaster. Fonte Vieira [25]. ... 64 Figura 21 - Quadro SCRUM real do projeto de consulta de apólices a renovar. ... 70 Figura 22 - Organização das Sprints do Projeto. ... 71 Figura 23 - Figura que exemplifica as alterações de layout propostas pela aplicação:
do lado esquerdo tem-se a tela de consulta e lista de resultados, antes da reformulação de layout. Do lado direito, tem-se a mesma tela de consulta e resultados, entregues ao final da Sprint. Ressalta-se que as informações foram apagadas e os valores manipulados por questões de confidencialidade. ... 73 Figura 24 - Exemplo das funcionalidades implementadas com a finalização da Sprint:
1 - Quantificador de dias faltantes para renovação; 2 - Pré-Cotado; 3 - Ações de Edição do Cálculo e Impressão da Cotação. ... 76
LISTA DE TABELAS
Tabela 1 - Exemplo de Product Backlog para um sistema de reserva hoteleira, após
Grooming.Fonte Menescal [17] e MJV [23]. ... 54
Tabela 2 - Exemplo de Sprint Backlog considerando o desenvolvimento da Sprint 1, descrita na Product Backlog apresentada neste trabalho. ... 55
LISTA DE GRÁFICOS
Gráfico 1 - Razões pelas quais as empresas têm adotado a Metodologia Ágil no desenvolvimento de softwares. Fonte VersionOne [12]. ... 30 Gráfico 2 - Evolução da utilização da metodologia SCRUM ... 35
LISTA DE ABREVIATURAS E SIGLAS
RUP – Rational Unified Process (Processo Unificado da Rational)
UML – Unified Modeling Language (Linguagem de Modelagem Unificada) IBM – International Bussiness Machines (Máquinas de Negócio Internacionais)
PMBOK – Project Management Body of Knowledge (Corpo de Conhecimento em Gerenciamento de Projetos)
XP – Extreme Programming (Programação Extrema) DoD – Definition of Done (Definição de Pronto) PO – Product Owner
SM – SCRUM Master
ST – SCRUM Team (Time SCRUM) ID - Identificador
SUMÁRIO
1 INTRODUÇÃO ... 17 2 REVISÃO BIBLIOGRÁFICA ... 19 2.1 METODOLOGIAS TRADICIONAIS ... 20 2.1.1 CASCATA ... 21 2.1.2 RUP ... 22 2.2 METODOLOGIAS ÁGEIS ... 23 2.2.1 XP ... 25 2.2.2 SCRUM ... 27 2.3 DISCUSSÃO ... 29 3 METODOLOGIA SCRUM ... 333.1 CONCEITOS E PILARES DO SCRUM ... 33
3.2 EXEMPLOS DE USO DO SCRUM ... 35
3.3 A METODOLOGIA ... 37 3.3.1 TIME SCRUM ... 40 3.3.1.1 PRODUCT OWNER ... 40 3.3.1.2 SCRUM MASTER ... 41 3.3.1.3 TIME DE DESENVOLVIMENTO ... 42 3.3.2 EVENTOS ... 43
3.3.2.1 PRODUCT BACKLOG GROOMING ... 44
3.3.2.2 SPRINT PLANNING MEETING ... 45
3.3.2.3 SPRINT ... 46
3.3.2.4 DAILY SCRUM MEETING ... 47
3.3.2.5 TIME BOXED ... 48
3.3.2.6 SPRINT REVIEW ... 49
3.3.2.7 POTENTIALLY SHIPPABLE PRODUCT INCREMENT ... 49
3.3.2.8 SPRINT RETROSPECTIVE ... 50
3.3.3 ARTEFATOS ... 51
3.3.3.2 PRODUCT BACKLOG ... 53 3.3.3.3 SPRINT BACKLOG ... 54 3.3.3.4 DEFINITION OF DONE... 56 3.3.3.5 BURNDOWN CHART ... 57 3.4 TÉCNICAS DE APOIO ... 60 4 ESTUDO DE CASO ... 65
4.1 JUSTIFICATIVA PARA ESCOLHA DO SCRUM ... 65
4.2 ESCOPO DO PROJETO ... 66
4.3 DESENVOLVIMENTO DA APLICAÇÃO UTILIZANDO A METODOLOGIA . 67 4.3.1 DEFINIÇÃO DE PAPÉIS ... 67
4.3.2 DEFINIÇÃO DE ETAPAS / EVENTOS ... 68
4.3.3 TÉCNICAS DE APOIO IMPLEMENTADAS ... 69
4.3.4 SPRINTS ... 71
4.3.4.1 SPRINT 1 ... 72
4.3.4.2 SPRINT 2 ... 73
4.3.4.3 SPRINT 3 ... 75
4.3.4.4 SPRINT 4 ... 76
4.4 DISCUSSÃO DO CASO DE USO ... 77
5 CONCLUSÕES E TRABALHOS FUTUROS ... 79
1 INTRODUÇÃO
Da necessidade de organizar/padronizar o desenvolvimento de programas computacionais, criou-se a disciplina Engenharia de Software que contém métodos e práticas para o gerenciamento de diferentes projetos. De maneira mais ampla essa disciplina não se restringe somente a ditar “regras de desenvolvimento”, mas também a explicar todos os ciclos necessários para o desenvolvimento de aplicações de qualidade.
Com o avançar da tecnologia no decorrer dos anos e a mudança de consumo da sociedade para demandas “real time” ou online, houve uma reorganização dos conteúdos dessa matéria, resultando na divisão de metodologias tradicionais (com foco em processos) e metodologias ágeis (com foco em produtos). Cada uma destas metodologias contém frameworks específicos que agilizam ou atrapalham o desenvolvimento do software quando não aplicados corretamente. O presente trabalho esclarece sucintamente essas diferenças e foca na apresentação de um framework representante da metodologia ágil, denominado SCRUM, apresentando suas aplicabilidades e ferramentas que podem apoiar seu uso.
Mediante o exposto, a ideia central deste trabalho é demonstrar como o SCRUM é facilmente aplicável nos mais diversos projetos, tendo como foco o desenvolvimento de software. Apoiado pelo exemplo de um estudo de caso real de utilização do SCRUM na manutenção de uma aplicação WEB, serão descritos todos os eventos e artefatos pertinentes, bem como as vantagens e desvantagens a serem superadas.
Dessa forma, o trabalho foi organizado da seguinte maneira: no capítulo 2, serão descritas, através de uma revisão de trabalhos da literatura, as principais diferenças entre os tipos de metodologias existentes (tradicionais e ágeis), sendo embasadas por exemplos dos frameworks mais utilizados em cada categoria. No capítulo 3 o tema proposto será apresentado em detalhes, com a descrição do
funcionamento da metodologia SCRUM, apresentação dos papéis, eventos e artefatos que caracterizam esse tipo de framework, bem como a sugestão de técnicas de apoio, que hoje já fazem parte dessa metodologia. Na sequência, após a apresentação da teoria, o capítulo 4 se proporá a descrever a empregabilidade do SCRUM através da narrativa de um estudo de caso, que contemplará todos os eventos e artefatos obrigatórios, servindo como um exemplo real que permitirá ao leitor identificar vantagens e desvantagens na utilização dessa metodologia.
2 REVISÃO BIBLIOGRÁFICA
O surgimento da disciplina acadêmica “Engenharia de Software” nas faculdades de computação há alguns anos reforçou a ideia de que o desenvolvimento de software não poderia ser definido simplesmente pela escrita das linhas de código, mas sim como um processo a ser padronizado e gerenciado. Desta interpretação, surgiram as chamadas metodologias de desenvolvimento de software, que nada mais são do que “padrões” ou boas práticas para que se tenha a entrega de um produto com qualidade. A definição proposta por Sommerville [1] e apresentada no trabalho de Kleber Hiroki Utida [2] ratifica o exposto: “Metodologia de desenvolvimento é o conjunto de práticas recomendadas para o desenvolvimento de softwares. Essas práticas podem ser subdivididas em fases, para ordenar e gerenciar o processo.”
Aliadas às inúmeras maneiras de se desenvolver um software têm-se as características de negócio de cada empresa, que faz com que cada uma procure a metodologia que melhor atenda às suas necessidades. A grande maioria, no entanto, acaba optando por trabalhar com um misto destas, que é definido de acordo com as características do projeto a ser desenvolvido.
Comumente as metodologias são divididas em dois grandes grupos: (i) as tradicionais (direcionadas a projetos de longa duração, fortemente documentados) e (ii) as ágeis (direcionadas a projetos de curto a médio prazo, com documentação mais flexível). Uma análise crítica acerca dessas metodologias pode ser encontrada no meio acadêmico, no trabalho desenvolvido por Mainart e Santos [3]. Neste Capítulo, serão descritas de maneira resumida, suas principais características, vantagens e aplicabilidade.
2.1 METODOLOGIAS TRADICIONAIS
As metodologias tradicionais, também conhecidas como “pesadas” ou orientadas a documentação, são caracterizadas pela divisão em fases, que correspondem ao ciclo de vida do software: Planejamento, Análise, Projeto e Implementação [26]. Descrevendo-as sucintamente, temos inicialmente a fase de planejamento, onde são levantados os requisitos e finalidades do software. Essas necessidades, por sua vez, são revisadas e priorizadas na fase de análise. Posterior a isso, na fase de projeto, são definidas as soluções que atenderão às necessidades e restrições levantadas. E por fim chega-se finalmente à fase de implementação, que nada mais é do que o desenvolvimento do software propriamente dito, com a codificação e testes pertinentes. Cada uma dessas fases deve ser muito bem definida e documentada. Costuma-se utilizar, para tal, a documentação UML (Unified
Modeling Language) [27], que contém toda uma padronização para confecção de
especificação de requisitos, diagramas de classes, casos de uso, diagramas de atividades, planos de teste e etc.
Amplamente utilizadas no passado, onde os custos de manutenção das aplicações eram muito altos (conforme exposto por Costa [4], dada a inexistência de ferramentas de apoio ao desenvolvimento), as metodologias tradicionais promovem o planejamento e documentação antes da implementação, sendo caracterizadas como “preditivas” e focadas em processos. Com o tempo, essa forma de trabalho mostrou-se um tanto “burocrática” favorecendo o surgimento das metodologias ágeis. Entretanto, empresas de grande porte, ainda fazem uso delas no desenvolvimento de projetos novos, de longa duração, complexos, com requisitos estáveis e previstos (demandas futuras), onde há necessidade de documentação de todas as fases, seja para fins de conhecimento, como também para atender às regulamentações governamentais vigentes.
Os frameworks que melhor representam esse tipo de metodologia são o desenvolvimento em cascata e o RUP, que serão apresentados a seguir.
2.1.1 CASCATA
Primeiro processo de software a ser descrito e publicado em 1970, por Winston W Royce [3], caracteriza-se pelo desenvolvimento sequencial das etapas de desenvolvimento de software. Ele acrescenta novas fases às quatro principais etapas descritas anteriormente (vide Figura 1 a seguir), a fim de proporcionar um melhor controle do desenvolvimento do projeto. São elas: Requisitos (levantamento das necessidades), Análise (priorização/análise de viabilidade dos requisitos), Desenho (proposta de solução para o desenvolvimento dos requisitos), Implementação (codificação e desenvolvimento do software), Testes (controle de qualidade e validação do funcionamento do software) e Implantação (entrega do produto em ambiente final, para utilização por todos os usuários).
Figura 1 - Fases do Modelo Cascata. Fonte Oliveira [5].
Como o próprio nome já diz, nesse tipo de desenvolvimento, cada etapa deverá ser desenvolvida sequencialmente, gerando os artefatos e documentações pertinentes a cada fase. A fase posterior só é iniciada ao final da anterior, evitando assim o retrabalho e sucessivas correções de “bugs”. Esse tipo de metodologia prevê que projetos bem definidos implicam em menos correções e entregas mais assertivas, o que na prática não é verdade. É inegável que requisitos bem definidos resultarão em produtos coerentes com o que foi solicitado, sendo esta a principal
vantagem deste modelo, contudo, é difícil aplicar modificações ou melhorias que sejam observadas na fase de implementação, uma vez que a fase de requisitos (anterior a essa) já foi finalizada. A solução para este caso seria retornar à fase inicial, paralisando o desenvolvimento e gerando assim possíveis atrasos no prazo de entrega do produto, que é a principal desvantagem desse método.
2.1.2 RUP
Principal representante comercial das metodologias tradicionais, conforme exposto por Utida [2] o RUP (Rational Unified Process) é um framework caracterizado pelo desenvolvimento iterativo das quatro principais fases da metodologia tradicional, renomeando-as para: Iniciação, Elaboração, Construção e Transição. As atividades realizadas em cada uma delas são as mesmas descritas no início deste capítulo e podem ser repetidas a cada ciclo (fase), sempre atualizando os artefatos gerados, conforme demonstra a Figura 2, a seguir. O ciclo de desenvolvimento termina com uma versão completa do produto de software.
Figura 2 - Fases do RUP. Fonte VASCO [6].
Comercializado pela IBM, o RUP faz uso do padrão UML na geração das documentações necessárias em cada etapa. Ele possui quatro elementos principais
que o caracterizam além de suas fases, conforme descrito por Utida [2]: funções (definição dos papéis dos envolvidos no projeto), atividades (trabalho que cada envolvido executa), artefatos (documentações) e disciplinas (coleção de atividades relacionadas, como por exemplo: modelagem de negócios e gerenciamento de mudanças). Sua principal vantagem se deve à aplicabilidade em diferentes tipos de projetos (sejam eles de desenvolvimento de software ou não), sendo considerada a metodologia mais completa atualmente, quando associado ao PMBOK (Project
Management Body of Knowledge). Enquanto o RUP define as técnicas para
desenvolvimento de software, o PMBOK o complementa, inserindo técnicas de gerenciamento de projetos, tais como controle de tempo (confecção de cronogramas), controle de riscos (impactos ao projeto), controle de custos (gerenciamento financeiro) e etc.
Como representante da metodologia tradicional, também é indicado para projetos de médio a longo prazo, com poucas mudanças no decorrer do desenvolvimento, sendo mais flexível a alterações se comparado com o modelo cascata, dada a sua possibilidade de configuração. Essa “flexibilidade” aparente, no entanto, deve respeitar alguns princípios (o que inclusive o difere dos demais modelos iterativos de desenvolvimento). Conforme exposto por Luiz [28], são eles: foco no software executável, antecipação e acomodação de mudanças, construção de sistema de componentes bem documentados, garantia de entregas de qualidade e visão do todo (tempo e custo do desenvolvimento). Sua utilização também é representada por empresas de grande e médio porte, onde se preza (principalmente em projetos de alta complexidade) a documentação às entregas. Esta inclusive é sua principal desvantagem, uma vez que a qualidade da entrega dependerá de um bom levantamento de requisitos logo no início do ciclo de desenvolvimento.
2.2 METODOLOGIAS ÁGEIS
Tendo destaque no final da década de 1990 como resultado da discussão de um pequeno grupo de desenvolvedores insatisfeitos com os padrões de desenvolvimento de software vigentes, as metodologias ágeis surgem como uma
alternativa eficiente no gerenciamento de projetos de curto prazo e atualmente vem sendo aplicadas em projetos de médio a longo prazo, dada a satisfação dos clientes. Com o advento das chamadas “startups” (pequenas empresas focadas em inovação), esse tipo de metodologia vem ganhando força no mercado e começando a chamar a atenção de empresas maiores (ou melhor, tradicionais), que estão resolvendo se arriscar nessa mudança de paradigma: foco em pessoas ao invés de processos.
Como o próprio nome já diz, sua principal característica são as entregas rápidas, porém o que a diferencia em relação à anterior é a sua capacidade de adaptação. Parte-se da premissa de que o cliente tem uma ideia do que deseja, e a cada ciclo de desenvolvimento, esta ideia pode ser melhorada, evoluída, seguindo doze princípios descritos na documentação conhecida como “Manifesto Ágil”, proposta em 2001, por Beck e demais desenvolvedores [7]:
1) Entrega contínua e adiantada de software com valor para o cliente. 2) Aceitar mudanças de requisitos, mesmo ao final do desenvolvimento.
Adequar as mudanças a fim de obter vantagem competitiva para o cliente.
3) Entregas frequentes de software funcionando, com produção em ciclos curtos (semanas até meses).
4) Trabalho em conjunto, durante todo o projeto, das pessoas de negócio e equipes de desenvolvimento.
5) Construir projetos com equipes de indivíduos motivados, com suporte e confiança necessários.
6) Conversação face a face é o método mais eficaz e eficiente de comunicação.
7) Software funcionando é a medida primária de progresso do projeto. 8) Ritmo sustentável de trabalho, válido para todo o time de projeto:
patrocinadores, desenvolvedores e usuários.
9) Excelência técnica e bom design aumentam a agilidade.
10) Simplicidade: a arte de maximizar a quantidade de trabalho não realizado.
11) As melhores arquiteturas, requisitos e designs resultam de times auto organizáveis.
12) Inspeção e adaptação como forma de melhoria contínua. Em intervalos regulares a equipe reflete sobre como se tornar mais eficaz, então se ajusta e refina seu comportamento.
Os doze princípios descritos acima, são na verdade o detalhamento dos quatro valores que norteiam e caracterizam um desenvolvimento ágil, também publicados no manifesto de Beck et al [7], que ditam:
1) Indivíduos e a interação entre eles devem ser mais valorizados que os processos e ferramentas.
2) Software em funcionamento vale mais do que uma documentação abrangente.
3) Colaboração com o cliente é mais importante do que a negociação de contratos.
4) Responder a mudanças é mais importante que seguir um plano.
Como principais representantes deste tipo de metodologia têm-se os
frameworks XP e SCRUM, que podem inclusive ser combinados de acordo com as
necessidades de cada projeto. O trabalho desenvolvido por Aline Cristine Fadel e Henrique da Mota Silveira [8] descreve em detalhes o funcionamento de cada um desses métodos. Neste capítulo, suas características principais serão apresentadas.
2.2.1 XP
Criado por um dos desenvolvedores do manifesto ágil (Kent Beck), no final dos anos 90 [5], o Extreme Programming, popularmente conhecido como XP, tem como principal característica o desenvolvimento do projeto com foco no código escrito do sistema. O entendimento de novas funcionalidades, a análise de erros, identificação de melhorias e até mesmo a comunicação da equipe em determinadas etapas é totalmente voltado para o código.
Conforme definição de Beck [9], o XP “é uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança”. Por isso mesmo, é largamente utilizado por empresas de
pequeno porte, como por exemplo, as “startups”, cujo negócio criativo e inovador, exige mudanças constantes no produto final.
Norteiam a adoção dessa prática, quatro valores aderentes aos princípios do Manifesto Ágil: comunicação, simplicidade, realimentação e coragem. Estes devem ser seguidos fielmente pelos personagens do projeto, que estão divididos de acordo com os seguintes papéis: Programador, Cliente, Testador, Monitor (uma espécie de auditor), Treinador (responsável pela manutenção e execução dos processos do XP), Consultor (membro externo com conhecimento técnico) e Chefe (responsável pela tomada de decisões, similar a um líder de projeto nas metodologias tradicionais).
Essa metodologia exige grande dose de disciplina, de maneira que todas as etapas sejam seguidas à risca. Coincidentemente ou não, assim como no Manifesto Ágil, doze princípios devem ser seguidos a fim de garantir a entrega de um produto de valor. Conforme descrito por Fadel e Silveira [8] têm-se:
1) Planejamento - onde serão definidos escopo e duração das iterações de desenvolvimento.
2) Releases de desenvolvimento pequenas.
3) Metáfora – Uma ideia que facilita o entendimento de determinadas funcionalidades do sistema por todos os envolvidos no projeto.
4) Simplicidade – Remoção de complexidades desnecessárias sempre que possível.
5) Testes – Execução de casos de uso a cada release gerada.
6) Refactoring – Melhoria do sistema através da remoção de códigos duplicados, tornando-o cada vez mais simples.
7) Programação em pares – Desenvolvedores devem trabalhar em conjunto, disseminando assim o conhecimento de determinada parte do projeto.
8) Propriedade coletiva – qualquer programador pode alterar qualquer parte do código.
9) Integração contínua – Novas versões são integradas e testadas a cada release gerada.
11) Cliente on site – adição de usuário do produto ao time do projeto, de maneira a tirar dúvidas ou mesmo tomar pequenas decisões (que não alterem as prioridades de desenvolvimento já definidas).
12) Padrão de programação – adoção de um padrão de codificação para facilitar as manutenções dos códigos, bem como atender ao princípio 8, aqui descrito.
Como representante da metodologia ágil, a principal vantagem do uso desse framework deve-se às entregas com qualidade, garantidas pela execução de testes frequentes e pela presença de usuários no processo de desenvolvimento. Entretanto, essa rapidez pode implicar em ausência de definições de riscos, conforme apontado pela Estudio Site [29], uma vez que a cada erro reportado durante os testes é providenciada uma correção, sem levar em consideração o impacto nas demais fases ou funcionalidades ou até mesmo áreas organizacionais da empresa.
2.2.2 SCRUM
Assim como no método anterior, o SCRUM também foi criado por dois autores do manifesto Ágil (Ken Schwaber e Jeff Sutherland), em 2001, que o definem como [10] “um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível”.
A garantia de entrega de projetos de maneira iterativa e incremental é feita com base em três valores que caracterizam essa metodologia: Transparência, Inspeção e Adaptação. Diferente do anterior, não é um framework voltado para o código e sim para pessoas, que são divididas de acordo com os seguintes papéis:
Product Owner, SCRUM Master e Time de Desenvolvimento, a serem detalhados
em capítulo posterior deste trabalho.
Popularmente utilizado por pequenas empresas, o SCRUM tem se expandido a empresas tradicionais, por se mostrar eficaz no desenvolvimento de projetos de baixa ou alta complexidade, assim como pela sua simplicidade de
implementação. Trata-se de um método totalmente flexível, podendo ser combinado com outras metodologias (inclusive a anterior, conforme trabalho de Oliveira [5]), desde que mantidas as suas etapas principais: Product Backlog (Funcionalidades desejadas e priorizadas), Sprint Backlog (lista de tarefas a serem executadas num ciclo curto de desenvolvimento), Daily SCRUM Meeting (Reuniões diárias de acompanhamento das atividades da equipe), Sprint Review (Reunião de avaliação ao final de cada Sprint) e Pottentially Shippable Product Increment (Resultado da Sprint / Entrega do produto). A Figura 3 a seguir, ilustra a iteratividade dessas etapas.
Figura 3 - Fases do SCRUM. Fonte BRQ [11].
A simplicidade de implementação, como já dito anteriormente é a principal vantagem desse framework que ainda conta com uma série de outros benefícios, tais como: produtividade elevada do time; feedback constante do cliente, permitindo uma análise de retorno de investimento (ROI), essencial para grandes empresas; maior controle no gerenciamento dos projetos, em decorrência de prazos e prioridades de desenvolvimento bem definidas. Em contrapartida, a ausência de documentação ainda é um entrave a se considerar na utilização desse método em projetos maiores, que aliados a variações de custo (em decorrência de sucessivas alterações) e a necessidade de um time de desenvolvimento totalmente focado são consideradas desvantagens importantes. Vale destacar ainda que as sucessivas reuniões, que na teoria são o ponto forte dessa metodologia (focada em pessoas),
podem acabar se tornando desvantajosas ao considerar que consomem tempo de desenvolvimento do produto, quando não respeitados seus limites de tempo.
2.3 DISCUSSÃO
Fazendo uma análise comparativa das metodologias apresentadas anteriormente, não é possível definir a que seria ideal para o desenvolvimento de um software. O que se pode concluir é que cada uma delas contém características que melhor se adaptam a diferentes processos, ou de maneira mais abrangente, a diferentes estratégias de negócio. Por exemplo, para o desenvolvimento de projetos complexos, que englobem diferentes processos da empresa, sugere-se a utilização das metodologias tradicionais, por questões de segurança e qualidade. Estas são alcançadas através de requisitos bem definidos, previsão de riscos e análises de impacto, que frameworks como o RUP fornecem em qualquer fase de desenvolvimento. Em contrapartida, se esse mesmo projeto complexo puder ser dividido em pequenas entregas que agreguem valor imediato ao negócio, com redução de riscos e garantia de satisfação dos clientes através de um ciclo de melhoria contínua, sugere-se a utilização das metodologias ágeis, que contém
frameworks que garantem a qualidade do produto final, tais como o SCRUM.
Ainda que as aplicabilidades sejam distintas, pesquisas recentes, como as divulgadas pelo 11º Relatório Anual de Situação do Ágil [12], comprovam que a utilização desse tipo de metodologia vem crescendo a nível mundial. Cerca de 26% das empresas de grande porte (com mais de 20 mil empregados) já fazem uso do ágil no desenvolvimento de projetos de software, sejam eles complexos ou não, com uma taxa de 90% de sucesso ao final deles. E as razões de sua popularidade devem-se principalmente às entregas rápidas, gerenciamento de prioridades e o ganho de produtividade, que as pequenas empresas já usufruíam desde o final dos anos 90. O Gráfico 1 a seguir, ilustra o exposto:
Gráfico 1 - Razões pelas quais as empresas têm adotado a Metodologia Ágil no desenvolvimento de softwares. Fonte VersionOne [12].
Esse aumento de produtividade é resultado de uma soma de fatores que vão desde o nível comportamental (foco no trabalho em equipe, no bem-estar do time e nas melhorias de ambiente) ao nível profissional (redução do desperdício de trabalho, simplificação da codificação e realização de testes). Sobre este último, pode-se dizer que a previsibilidade das metodologias tradicionais acaba se tornando uma desvantagem em projetos de longa duração, pois na maior parte das vezes, conforme comprova relatório da Standish Group (vide Figura 4, a seguir), muitas das funcionalidades solicitadas pelo cliente acabam sendo pouco ou nunca utilizadas depois de implantadas em produção.
A metodologia ágil tira vantagem dessa previsibilidade ao lançar versões evoluídas do produto no mercado. Se alguma funcionalidade se provar desnecessária é possível melhorá-la ou até mesmo retirá-la do escopo a fim de garantir o êxito da entrega. Entretanto, mesmo com altos índices de sucesso nas implantações, alguns desafios ainda precisam ser superados e surpreendentemente não se restringem às desvantagens mencionadas anteriormente neste capítulo, tais como a fraca documentação e o baixo gerenciamento de risco. O relatório da VersionOne [12], do ano passado, mostra que o principal motivo para não utilização das metodologias ágeis ainda se deve a resistência às mudanças, em particular de companhias com filosofias tradicionais, que têm dificuldade em se adequar aos valores do ágil e que ainda consideram que o produto só tem valor se entregue em sua totalidade. Seguido a isso, conforme ilustra a Figura 5 a seguir, tem-se a falta de experiência e treinamentos insuficientes nos métodos disponibilizados no mercado, que podem ser resolvidos com a adoção de metodologias que não requerem muita especialização, como por exemplo, o SCRUM e o KANBAN.
Figura 5 - Desafios apontados pelas empresas para adoção da Metodologia Ágil. Fonte VersionOne [12].
Justamente por ser uma metodologia flexível, existem diversos
frameworks para adoção da cultura ágil, havendo inclusive a possibilidade de
combinações entre eles. No entanto, conforme será descrito neste trabalho, o SCRUM tem se mostrado muito eficaz no desenvolvimento dos projetos de software, não só pela facilidade de implementação e simplicidade, como por todo o controle de
qualidade e transparência que ele proporciona. A Figura 6, também retirada do relatório produzido pela VersionOne [12], demonstra que mais da metade das empresas preferem o SCRUM a outros métodos.
Figura 6 - Utilização dos frameworks de Metodologia Ágil pelas empresas. Fonte VersionOne [12]. Com desvantagens facilmente contornáveis, nos capítulos seguintes a metodologia SCRUM será detalhada, acrescida da sugestão de técnicas de apoio, que foram essenciais para o sucesso do projeto de reformulação da consulta de apólices a renovar, de uma grande seguradora do mercado brasileiro.
3 METODOLOGIA SCRUM
Nos últimos dez anos, a metodologia SCRUM tornou-se a principal forma de implementação das metodologias ágeis no mundo, não se restringindo apenas ao desenvolvimento de software, foco deste trabalho, mas também sendo utilizado em processos de engenharia, marketing e serviços (voltados para tecnologia ou não).
Conforme citação de David Matthew, SCRUM Master certificado pelo Incentive Technology Group [14], “o método SCRUM pode ser usado para qualquer tipo de projeto complexo. A ressalva é que ele funciona melhor quando há um produto concreto que está sendo produzido”. Ou seja, não há limitações para sua utilização, uma vez que de maneira geral, o SCRUM pode ser visto como um método de gerenciamento de projetos. Aliado (ou não) a algumas técnicas, ele permite um melhor gerenciamento das atividades da equipe e entregas rápidas de versões “utilizáveis” do produto final.
Nas seções seguintes, as características dessa metodologia serão apresentadas em detalhes.
3.1 CONCEITOS E PILARES DO SCRUM
A definição do SCRUM como uma metodologia de gerenciamento de projetos é antiga e foi proposta por Takeuchi e Nonaka, em 1986 no artigo “The new
product development game” [8]. Através de uma analogia com a formação “scrum”
do jogo de rugby, eles provaram que pequenas equipes de alto desempenho e multifuncionais, produziam melhores resultados no desenvolvimento de projetos do que equipes grandes com muita especialização.
Concebido inicialmente para aplicação nas indústrias automobilísticas e de produtos de consumo, o SCRUM surge como metodologia ágil em 1993, quando
Jeff Sutherland e Ken Schwaber definiram métodos para o desenvolvimento de
software, após uma implementação bem-sucedida na empresa Easel Corporation
[14]. Conforme guia produzido por eles [10], o objetivo dessa metodologia não é descrever técnicas para a construção do produto e sim descrever como as equipes devem trabalhar a fim de produzir um sistema flexível, num ambiente de mudanças constantes, apoiado por diferentes processos e técnicas. O SCRUM é leve, personalizável e garante o sucesso do desenvolvimento por estar embasado pela teoria de controle de processos empíricos [10].
O empirismo dita que o conhecimento é adquirido através de experiências práticas, ou seja, as decisões são tomadas com base no que é conhecido, sendo, portanto, mais assertivas. Valendo-se disso, o SCRUM trabalha de maneira iterativa (aprimorando o produto a cada versão) e incremental (evoluindo o produto a cada entrega) a fim de aperfeiçoar a previsibilidade e o controle de riscos [10], fundamentado por três pilares: transparência, inspeção e adaptação.
A transparência garante o atendimento do quarto princípio do manifesto ágil, que fala sobre trabalho em equipe, com envolvimento e comprometimento de todos, indo do time de desenvolvimento ao usuário final. Aspectos importantes do projeto sempre devem ser divulgados, a fim de que todos estejam alinhados e de acordo com as decisões. Essa comunicação pode ser apoiada por diferentes técnicas, tais como o KANBAN ou o Trello. Seu objetivo, na verdade, é dar visibilidade das atividades (que estejam em andamento ou no backlog) a fim de estimular a participação dos envolvidos, não restringindo o acompanhamento do projeto apenas à figura do gerente, como ocorre nas metodologias tradicionais.
A inspeção por sua vez, garante a qualidade das entregas, assim como norteia o desenvolvimento do projeto. Apesar dessa metodologia não ser focada em documentação, faz-se necessário um mínimo de controle do que está sendo realizado, a fim de que os prazos sejam cumpridos e que a entrega esteja de acordo com o escopo definido. Sugere-se que essa validação seja realizada com certa frequência, de preferência por uma equipe especializada [10], porém na ausência desta, cabe ao usuário inspecionar a fim de detectar variações no desenvolvimento do projeto.
E por fim atrelado ao pilar anterior tem-se a adaptação, que é a garantia da flexibilidade, principal característica do SCRUM. As falhas detectadas na fase de
inspeção, se inaceitáveis, devem ser corrigidas o quanto antes, a fim de minimizar riscos. E as melhorias, que também podem ser apontadas, devem ser discutidas nas reuniões, podendo em alguns casos resultar em replanejamento das atividades, se consideradas como uma entrega de valor. A adaptação permite um planejamento menos engessado, o que está aderente com a realidade mutável dos projetos empresariais atuais [16].
3.2 EXEMPLOS DE USO DO SCRUM
O SCRUM tem sido utilizado no mundo todo, indo “do FBI a agências de marketing e equipes de construção” [14], não se restringindo somente ao desenvolvimento de software, que é sua principal aplicabilidade. Sempre que se deseja entregar um produto de valor, no menor prazo possível, a utilização dessa metodologia tem se mostrado eficaz, pelas orientações acerca da organização da equipe e gerenciamento de mudanças. A análise dos resultados divulgados pela Version One [12] nos últimos 10 anos, exposta no gráfico 5, demonstra a evolução da empregabilidade desta metodologia:
A facilidade de implementação e a possibilidade de personalização, são os principais motivos que fazem com que empresas grandes tenham resolvido, nos últimos anos, se experienciar no SCRUM. Com um conjunto de valores, princípios e práticas bem definidas, esse framework fornece a base, que permite a adição de práticas particulares de engenharia e gestão já vivenciadas por cada organização. Como resultado, tem se uma versão de SCRUM exclusiva da empresa, que tem sido compartilhada através de “cases” de sucesso reportados em congressos de tecnologia mundo afora. A Figura 7 a seguir, destaca organizações importantes no mundo e no Brasil, que já se beneficiam da utilização dessa metodologia.
Figura 7 - Grandes empresas que utilizam a metodologia SCRUM. Fonte Menescal [17]. Das empresas listadas na figura anterior, pode-se dizer que as organizações de inovação, voltadas para o desenvolvimento de produtos e serviços digitais, constituem-se como principais representantes, por entenderem a importância de centrar esforços na experiência do cliente. A empresa Spotify, por exemplo, faz uso de um SCRUM personalizado, que combina práticas do XP (tais como a codificação em pares) e KANBAN (controle de atividades) na oferta de serviços de gerenciamento de streaming de música [18].
Mantendo-se fiel aos conceitos da metodologia, o Spotify divide seus funcionários em pequenas equipes de SCRUM, com autonomia para criar, projetar, implementar e manter as funcionalidades que estão sob a sua responsabilidade. Elas possuem liberdade para desenvolver, tendo suporte e infraestrutura
necessários para a realização de seus testes, devendo sempre estar alinhadas com a missão geral da empresa. Como consequência dessa liberdade de criação há certa falta de padronização na codificação das funcionalidades, que eles procuram resolver através de uma forte comunicação entre os líderes dos times de desenvolvimento (os “SCRUM Master”, ou técnicos como eles se denominam). Metas de curto prazo são estipuladas para cada equipe e renegociadas a cada trimestre. Funcionalidades muito grandes são particionadas e implantadas de maneira “escondida”, a fim de que se antecipem erros e o produto possa ser evoluído até que se chegue a uma versão utilizável. Erros nas entregas são corrigidos imediatamente e procura-se sempre aprender com as falhas. O ambiente é otimizado para colaboração, pois aderente aos princípios da metodologia ágil, eles entendem que pessoas motivadas constroem algo melhor. Nesse sentido, as reuniões são, inclusive, realizadas no formato de festas a fim de promover e testar novas funcionalidades, bem como favorecer a comunicação e integração das equipes.
As organizações tradicionais por sua vez, tem se valido do SCRUM para quebrar projetos grandes e complexos (de reformulação de aplicações antigas, principalmente) em pequenas entregas de valor, a fim de manterem-se atraentes para o cliente no mercado. A empresa Bradesco Seguros, por exemplo, faz uso de uma metodologia combinada (recentemente denominada como SCRUMBAN), que usa as regras do SCRUM para organização da equipe e desenvolvimento do software, e o KANBAN para controle das atividades, tal qual ocorre no Spotify. O exemplo detalhado de aplicabilidade dessa metodologia é o objetivo do capítulo 4 do presente trabalho.
3.3 A METODOLOGIA
Apesar de ser extremamente personalizável, o framework SCRUM possui algumas práticas que devem ser obedecidas a fim de que se possa considerar sua aplicação. Elas estabelecem a base da metodologia e podem ser dispostas de maneira a compor um ciclo de vida de desenvolvimento, dividido em três fases,
conforme proposto por Koscianski e Soares [19]: planejamento, desenvolvimento e pós-planejamento. A Figura 8 a seguir, apresenta essa estrutura principal:
Figura 8 - Estrutura base para aplicação do framework SCRUM. Fonte Vieira [20].
Na fase de planejamento, serão definidos os papéis e responsabilidades de cada envolvido no projeto (Product Owner, SCRUM Master e Time SCRUM), bem como os requisitos de desenvolvimento e a maneira de implementá-los. O principal artefato gerado nesta fase é uma lista de prioridades desses requisitos, denominada
Product Backlog, que pode ser refinada com estimativas de esforço e tamanho no
evento Product Backlog Grooming. Dessa lista de prioridades serão elencadas - no planejamento da Sprint - algumas atividades que irão compor um ciclo de desenvolvimento, gerando assim um novo artefato: a Sprint Backlog.
De posse da lista do que deve ser feito, inicia-se a fase de desenvolvimento, que corresponde a execução da Sprint, ou seja, o desenvolvimento da aplicação propriamente dito. Essa fase engloba toda a codificação e testes necessários para disponibilização de uma versão utilizável do produto, sendo o seu principal artefato o DoD ou “Definição de Pronto”, que é dado pelo Time SCRUM em conjunto com o Product Owner. Por se tratar de um desenvolvimento iterativo, são realizadas reuniões diárias (Daily SCRUM Meeting) para acompanhamento e controle das atividades e ao final de cada Sprint são realizadas reuniões de Retrospectiva (Sprint Retrospective) para avaliação e monitoramento do progresso do projeto.
Por fim, na fase de pós-planejamento, tem-se a documentação e integração da versão disponibilizada aos demais sistemas da corporação, quando necessário. Também é realizada uma reunião de Revisão da Sprint (Sprint Review), onde tudo o que foi desenvolvido na versão é apresentado para validação dos gestores / clientes. Trata-se de uma reunião estratégica, que dá margem para revisões da lista de prioridades, bem como identificação de melhorias nos processos de desenvolvimento.
Por se tratar de uma metodologia incremental, as duas últimas fases (desenvolvimento e pós-planejamento), se repetem continuamente, até que se chegue à versão final do produto, que atende a todos os requisitos descritos na lista de prioridades (Product Backlog). Pode-se dizer que cada versão intermediária é na verdade uma evolução da versão anterior, de maneira que sempre seja funcional. Do ponto de vista do cliente, essa é uma vantagem considerável em relação às metodologias tradicionais, onde se espera a finalização do projeto para utilização da aplicação (ou produto). A Figura 9 a seguir, ilustra o funcionamento da metodologia de maneira resumida.
Figura 9 - Funcionamento da Metodologia SCRUM. Fonte Garrido [21].
Nos próximos subcapítulos, cada um dos itens mencionados que compõem a base do funcionamento do framework SCRUM serão explicados em detalhes.
3.3.1 TIME SCRUM
Conforme citação de capítulos anteriores, a metodologia SCRUM é totalmente voltada para o trabalho em equipe, estando em conformidade com os princípios da metodologia ágil, onde o foco são as pessoas e não os processos. Isso faz com que ela estipule regras específicas para o gerenciamento da equipe, organizando o time SCRUM sob três papéis fundamentais, que se recomenda que não sejam cumulativos: Product Owner, SCRUM Master e Time SCRUM.
3.3.1.1 PRODUCT OWNER
O Product Owner é o responsável pelo projeto, ou de maneira mais ampla, o dono do produto ou patrocinador. Espera-se que seja alguém com conhecimento do negócio, capaz de explicar detalhadamente os requisitos do produto a ser entregue, sendo, portanto, o representante do cliente dentro do time SCRUM. Ele pode ser um analista de negócios ou o gestor do produto, porém nunca um comitê, conforme descrito no Guia SCRUM [10]. Na verdade, ele por vezes representa os desejos de um comitê ou diretoria, uma vez que é diretamente responsável pelo ROI (retorno de investimento), quando define as funcionalidades que irão agregar valor ao negócio da empresa. Suas principais funções são a confecção da Product Backlog e o aceite da Sprint.
Com relação à lista de prioridades, o PO é a única que pessoa que pode alterá-la, devendo ainda administrar os riscos, benefícios e demandas, sendo sempre norteado pelas necessidades do cliente, o que implica em ter suas decisões respeitadas por toda a organização. Na ocorrência de dúvidas das quais ele não tenha as respostas, somente ele interage com o cliente a fim de saná-las, mantendo sempre um relacionamento colaborativo com a equipe de desenvolvimento.
No que tange ao aceite do projeto, quando uma versão “entregável” é disponibilizada, ele é quem fica encarregado da liberação para implantação,
podendo inclusive cancelar uma Sprint (o que é raro), se esta não estiver de acordo com o que foi solicitado.
3.3.1.2 SCRUM MASTER
O SCRUM Master é o líder do projeto sendo responsável por garantir que as práticas, regras e valores da metodologia sejam seguidos. Não há obrigatoriedade de certificação, podendo ser um gerente técnico ou qualquer pessoa (de preferência com perfil de liderança) que tenha conhecimento de SCRUM. Diferente do gerente de projeto das metodologias tradicionais, que exerce autoridade sobre a equipe de desenvolvimento, o SCRUM Master está mais para um líder servidor, que atua como facilitador do time, ajudando-o a praticar o autogerenciamento e a interdisciplinaridade [19]. Conforme definição de Vieira [20], ele “age como um Coach, executando a liderança do projeto e ajudando a equipe SCRUM (e o resto da organização) a desenvolver sua própria abordagem de SCRUM, que tenha a melhor performance, respeitando as particularidades da organização”.
As principais funções deste papel são: a liderança e execução dos eventos previstos na metodologia (tais como reuniões diárias, de planejamento e retrospectiva da Sprint); Manutenção da comunicação com os envolvidos, uma vez que ele deve analisar possíveis riscos e impactos nas demais áreas da organização, alertando imediatamente o Product Owner, para a devida comunicação; Gerenciamento das atividades, sempre em conjunto com a equipe, não permitindo que haja um comprometimento excessivo de atividades a serem realizadas durante uma Sprint. E por fim, a remoção de impedimentos ao progresso do projeto, protegendo o time de desenvolvimento de interferências externas, que poderiam vir a comprometer o prazo e a qualidade dos produtos entregues.
O SCRUM Master exerce um papel fundamental dentro da equipe, sendo o agente de mudanças, responsável por difundir o conhecimento da metodologia na organização, como também o agregador e motivador da equipe.
3.3.1.3 TIME DE DESENVOLVIMENTO
Finalmente, têm-se o time de desenvolvimento, também denominado time SCRUM, representado por um grupo de pessoas com todo o conhecimento técnico necessário para o desenvolvimento do produto. Conforme definição de Schwaber e Sutherland [10], esse time deve ser “pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho dentro dos limites da Sprint”. Via de regra, ele é composto por 3 a 9 integrantes no máximo. Menos do que isso, pode-se vir a ter problemas de produtividade, com equipes que talvez não tenham todas as habilidades necessárias para a entrega de uma versão utilizável, dentro dos prazos estipulados pelo Product Owner. E mais do que isso, têm-se problemas de coordenação, aumentando a complexidade de gerenciamento das atividades, fazendo com que se perca a agilidade das entregas. Para esse cenário, inclusive, sugere-se a divisão da equipe em mais de um time SCRUM (respeitando seu número máximo de integrantes), gerando o que é conhecido na literatura como “Scrum of Scrums”. O alinhamento entre essas equipes fica a cargo do SCRUM Master de cada time, que faz a comunicação com o Product Owner do projeto.
O ST (abreviação inglesa de Time SCRUM) deve ser multidisciplinar e auto-organizável. Tomando como foco o objetivo deste trabalho, que é a aplicação da metodologia em processos de desenvolvimento de software, para que se tenha a entrega de um produto de qualidade, sem levar em consideração sua complexidade, comumente, têm-se, por exemplo, os seguintes personagens: pessoas especializadas em determinadas linguagens de programação (para codificação), um
designer (para tornar o produto atraente), um analista de negócios (conhecedor do
produto e que também atue como documentador) e um testador (que valide as entregas). Como representante da metodologia ágil, o SCRUM é voltado para colaboração, logo, ele trabalha a multidisciplinaridade da equipe incentivando esses personagens a compartilharem seus conhecimentos e aplicarem suas especialidades em todos os problemas, ajudando uns aos outros. Busca-se trabalhar com o que é chamado na literatura de profissional “T-Shaped”, que conforme exposto por Menescal [17], não deve ser tão generalista (com conhecimentos em
diversas disciplinas, porém sem aprofundamento) e nem tão especialista (com conhecimento sólido em apenas uma disciplina).
No que tange à auto-organização, a equipe deve possuir total liberdade de desenvolvimento, onde nem o SCRUM Master deve intervir. Ela é quem define a estratégia a ser implementada na transformação dos itens da Product Backlog em incrementos entregáveis, sendo, portanto a chave do sucesso. A performance da equipe influencia diretamente nos rumos do projeto, podendo inclusive ser reestruturada quando o rendimento estiver abaixo do esperado. Nesse caso, sugere-se que essas trocas de recursos da equipe não sugere-sejam realizadas durante a execução de uma Sprint e sim somente ao final, após a reunião de Retrospectiva, a fim de minimizar os impactos na produtividade, que decairá até que se alcance o estado de auto-organização novamente [5].
A principal função do ST, obviamente é o desenvolvimento do produto, no entanto, ele também está envolvido na confecção da Product Backlog (quando estima o esforço de desenvolvimento das funcionalidades, o que de certa forma influencia na priorização) e na confecção da Sprint Backlog (quando define quais atividades podem ser atendidas em cada Sprint). Não há hierarquias no time de desenvolvimento e a participação em todos os eventos dessa metodologia é essencial, pois eles também podem sugerir melhorias, que na maior parte das vezes decorrem de um aprendizado com as falhas. Há aqui certa mudança de postura, que tira o time da posição de simples executor de tarefas e o leva para a posição de dono do produto, onde o êxito da entrega, representa a vitória de todos.
3.3.2 EVENTOS
Definidos os papéis do time SCRUM, parte-se para a execução da metodologia, cujas práticas norteiam todo o desenvolvimento do projeto. Por ser um
framework personalizável, é possível que nem todos os eventos sejam aplicados,
gerando desvios na metodologia apelidados de “Scrumbut”. Um exemplo clássico e praticado regularmente entre as empresas é deixar de fazer as reuniões diárias por considerar que estas impactam no andamento do projeto. Não obstante, provar-se-á,
a importância desta para a metodologia ágil, nos subitens seguintes. A Figura 10 abaixo ilustra o funcionamento desses eventos.
Figura 10 - Eventos que fazem parte da metodologia SCRUM. Adaptado de Menescal [17].
3.3.2.1 PRODUCT BACKLOG GROOMING
O processo de SCRUM se inicia como qualquer projeto: a partir do levantamento dos requisitos, que na metodologia ágil gera um artefato opcional denominado User Story (a ser descrito posteriormente).
Uma vez que a organização decida em qual projeto irá aplicar o SCRUM, caberá ao Product Owner apresentar as demandas ao time a fim de que estas possam ser discutidas, priorizadas e estimadas. Trata-se da reunião inicial do projeto (o equivalente ao Kick-off das metodologias tradicionais), apelidada de Product
Backlog Grooming (ou somente Grooming, conforme Guia SCRUM [10]). O PO e o
SM devem decompor as necessidades do cliente (ou User Stories) em atividades menores, detalhadas, que irão compor o que é nomeado nesse framework como
Product Backlog.
Durante o Gromming todas as atividades são analisadas e o SM vale-se de técnicas de estimativas (como por exemplo, a Planning Poker [17]) para mensurar
o esforço da equipe em cada uma delas. Ressalta-se que neste momento não se trata de uma medida de horas de trabalho e sim de valor de complexidade (“Story
Points” ou “dias ideais” [20]), a fim de facilitar a priorização por parte do PO. Esse
refinamento dos itens pode ser revisto e atualizado em eventos posteriores, tais como a Sprint Planning, execução da Sprint ou Retrospective Sprint, e quando bem feito assegura um ritmo de trabalho saudável para a equipe.
3.3.2.2 SPRINT PLANNING MEETING
De posse da Product Backlog, que contém todos os desejos e demandas do cliente, já priorizados, todo o time SCRUM - Product Owner, SCRUM Master e time de desenvolvimento – se organiza para uma Reunião de Planejamento, que consiste em definir as atividades que serão implementadas em cada ciclo de desenvolvimento, que nessa metodologia é chamado de Sprint.
Geralmente essa reunião só ocorre uma vez, pois nela serão definidas todas as Sprints que atenderão o projeto, juntamente com o objetivo de cada uma delas. No entanto, cabe ressaltar que por ser uma metodologia orientada a mudanças, sempre será possível replanejar essa divisão de acordo com o andamento do desenvolvimento, porém nunca durante a execução da Sprint, como será mostrado em subitem posterior.
Para Sprints com duração de um mês, sugere-se que essa reunião seja realizada em no máximo oito horas, cabendo ao SCRUM Master fazer com que esse tempo seja obedecido. Sprints menores podem ser planejadas em reuniões de duas a quatro horas. A ideia é utilizar esse tempo para responder aos seguintes questionamentos, conforme descrito no Guia SCRUM [10]: “Qual é o objetivo da
Sprint; O que pode ser entregue como resultado do incremento da próxima Sprint e
Como o trabalho necessário para entregar o incremento será realizado”.
Em suma, trata-se de uma reunião colaborativa, de análise da Product
Backlog, onde o time de desenvolvimento, além de tirar dúvidas acerca de
funcionalidades, tem liberdade para discutir acerca de quais serão as atividades técnicas necessárias para atendimento do objetivo da Sprint e qual o tempo gasto
em cada uma delas. A partir dessa informação, é possível ao SCRUM Master negociar com o Product Owner o que pode ser desenvolvido em cada Sprint, sem exceder a capacidade do time. Isso, por sua vez, permite ao PO equilibrar o atendimento das necessidades do cliente, atendendo, por exemplo, funcionalidades de alta prioridade em conjunto com baixas, a fim de valorizar a versão do produto entregável. Como resultado dessa reunião tem-se a geração do artefato Sprint
Backlog, a ser descrito em subitem posterior.
3.3.2.3 SPRINT
A Sprint é o coração da metodologia SCRUM, afinal ela representa o desenvolvimento em si, ou conforme definição do Guia SCRUM [10] é a criação de uma “versão incremental potencialmente utilizável do produto”.
De maneira formal, as Sprints consistem em ciclos de desenvolvimento iterativos, com duração fixa de uma a quatro semanas, onde um conjunto de atividades previamente definido no artefato Sprint Backlog é executado pelo time de desenvolvimento. Durante esse evento a equipe deve estar focada em atender todos os requisitos acordados no Planejamento da Sprint e o SCRUM Master deve trabalhar no sentido de manter a motivação e blindar a equipe de fatores externos que possam vir a comprometer as entregas.
A teoria dita que todas as Sprints devem possuir a mesma duração, a fim de que se tenha um ritmo de trabalho e entregas constante, contudo, observa-se que na prática as empresas quase sempre optam por um Scrumbut, com Sprints de durações diferentes, conforme critérios de aceitação do produto negociados com o
Product Owner. Cabe ressaltar aqui, que Sprints muito longas ferem o conceito de
agilidade proposto pela metodologia, uma vez que a definição do que está sendo construído pode mudar, a complexidade aumentar e o risco crescer [10].
Os Sprints ocorrem um após o outro, de maneira sequencial, sem intervalos e principalmente sem modificações. Cabe ao SCRUM Master garantir que a produtividade seja mantida, intervindo quando necessário, com base na análise do artefato Burndown Chart. Por exemplo, via de regra, alterações na equipe durante
uma Sprint não são permitidas, mas se o SM observar que a produtividade está alta e que existem recursos ociosos, ele pode reestruturar a equipe, minimizando os custos do projeto. Outro exemplo frequente diz respeito a alterações de escopo que também não são permitidas durante o processo de execução, mas que podem ser geridas de duas formas pelo SM, desde que negociadas com o PO. Se a equipe estiver com o desenvolvimento da Sprint adiantado e o SM entender que mais atividades podem ser inseridas na Sprint sem comprometer a capacidade do time, o PO executa uma Product Increment, pegando os próximos itens da Product Backlog e antecipando o desenvolvimento. O inverso também pode ocorrer, se as atividades da Sprint estiverem com atraso e o SM optar por renegociar com o PO a retirada de algumas atividades a fim de cumprir o prazo de entrega, cabendo a este último devolvê-las para o Product Backlog. Outra forma de devolução de atividades para o
Backlog, que só pode ser realizada pelo PO, é o cancelamento da Sprint. Trata-se
de uma situação incomum e traumática para o time [10], mas que pode ocorrer caso o objetivo da Sprint se torne desnecessário, seja por questões estratégicas da empresa ou por condições de mercado.
Fazem parte de uma Sprint, três eventos detalhados na sequência: Daily
Scrum Meeting, Sprint Review e Sprint Retrospective.
3.3.2.4 DAILY SCRUM MEETING
A metodologia SCRUM dita que reuniões diárias devem ser realizadas durante a execução de uma Sprint, como forma de responder rapidamente às mudanças e manter a comunicação do time, sendo a representante do pilar de “inspeção”.
Tratam-se de reuniões rápidas, de quinze minutos no máximo, com horário e local regular, também batizadas de Stand-Up-Meeting [20], por serem realizadas em pé, a fim de manter agilidade. O SCRUM Master é o responsável por conduzir a reunião, garantindo o cumprimento do tempo e a brevidade das respostas. O Product Owner normalmente não participa, e todo o time de desenvolvimento deve responder (individualmente) a três perguntas, conforme
