CENTRO UNIVERSITRIO EUROAMERICANO UNIEURO PR-REITORIA E PS-GRADUAO, PESQUISA E EXTENSO COORDENAO DE PS-GRADUAO LATO SENSU CURSO PS-GRADUAO EM TESTE

E DE SOFTWARE

RENATA ELIZA PINTO FERREIRA SIBELE ESTEVES RAMOS VIVIAN CRISTINA LAGARES

SCRUM NO TESTE DE SOFTWARE

Belo Horizonte, Maro/2010

ii

RENATA ELIZA PINTO FERREIRA SIBELE ESTEVES RAMOS VIVIAN CRISTINA LAGARES

SCRUM NO TESTE DE SOFTWARE

Trabalho de Concluso de Curso Monografia, apresentada como requisito parcial para concluso do Curso de MBA em Teste de Software do Centro Universitrio Euroamericano Unieuro

Orientadora: Professora Cleziana de Freitas Costa

Belo Horizonte, Maro/2010

iii

RENATA ELIZA PINTO FERREIRA SIBELE ESTEVES RAMOS VIVIAN CRISTINA LAGARES

SCRUM NO TESTE DE SOFTWARE

Esta monografia foi julgada adequada obteno do grau de Especialista em Teste de Software e aprovada em sua forma final pelo curso de Ps-Graduao Lato Sensu em Teste de Software do Centro Universitrio Euroamericano - UNIEURO.

Data de aprovao: 12-03-2010 Banca Examinadora

__________________________________________ Professora Especialista Cleziana de Freitas Costa Centro Universitrio UNIEURO

__________________________________________ Professora Wilsa Sette Morais Figueiredo Centro Universitrio UNIEURO

__________________________________________ Professora Msc. Edna Dias Canedo Centro Universitrio UNIEURO

iv

"Testar igual a minha me testa fcil. Difcil se tornar um especialista e testar o software utilizando tcnicas e metodologias." Renata Eliza

minha famlia, em especial minha me Eliza e minha Tia Maria pelo intenso incentivo e apoio. Aos meus amigos, que de certa forma compreenderam a minha ausncia durante boa parte do curso. minha super amiga e companheira de curso Vivian Lagares, por todo o companheirismo, reflexes, network e apoio para que vencssemos juntas essa etapa. E ao Cara L de Cima, que mais uma vez me mostrou que quando a gente realmente quer alguma coisa, a gente consegue. Renata Eliza

A meus pais e familiares pelo apoio de sempre. E a todos aqueles que, direta ou indiretamente, acreditaram e me incentivaram a buscar meus ideais Sibele Esteves

Ao meu marido, me e irm por sempre me apoiarem e incentivarem em todos os meus projetos e por entenderem as freqentes ausncias. Eles so a minha vida, o meu alicerce! Ao meu padrinho Alysson, pela hospitalidade, dicas, apoio e conselhos profissionais e pessoais. A minha amigona do corao Renata Eliza, por sempre me ajudar, por ter pacincia com as nossas diferenas e por me incentivar em todos os momentos do curso. Vivian Lagares

vi

AGRADECIMENTOS Agradecemos a orientadora Cleziana Costa pela compreenso e ajuda. Ao Fabrcio Ferrari, ao Denis Ferrari, ao Thlio Prudente e ao Douglas Matoso pelo compartilhamento da experincia. A Deus e a todas as pessoas que contriburam com suas reflexes para o desenvolvimento deste trabalho.

vii

RESUMO O presente trabalho foi baseado em pesquisa qualitativa, exploratria e descritiva atravs de estudos de casos de empresas privadas com seguimento em desenvolvimento de Software que utilizam a metodologia Scrum; e provas de conceito apresentando os resultados, com o objetivo de estudar o Processo gil Scrum, e sua aplicabilidade no Teste de Software. Inicialmente apresentado o conceito de Processos geis, o Manifesto gil e os modelos existentes da Metodologia gil. Em seguida, apresentada a Metodologia Scrum, sua origem, ciclo de vida, seus papis e ferramentas. Alm disso, apresentada a aplicabilidade do Scrum no Teste de Software, os estudos de caso e as vantagens e as desvantagens da utilizao da metodologia.

Palavras-Chave: Processos geis, Scrum, Teste de Software, Teste, Metodologia gil.

viii

ABSTRACT This study was based on qualitative research, exploratory and descriptive using case studies of private companies focused in developing software using the Scrum methodology, and proof of concept showing the results aiming to study the Agile Process Scrum, and its applicability in Software Testing. First is presented the concept of Agile processes, the Agile Manifest and the existing models of Agile Methodology. Then you see the Scrum methodology, their origin, life cycle, their roles and tools. Additionally, you receive the applicability of the Scrum Software Testing, case studies and the advantages and disadvantages of using the methodology.

Key-words
Agile Processes, Scrum, Software Testing, Testing, Agile Methodology.

ix

LISTA DE ILUSTRAES
Figura 01 - O Scrum - (CLARIFICATION, 2009) ....................................................................................... 13 Figura 02 - Modelo de Gerenciamento Emprico - (CORDEIRO, 2006) ................................................. 15 Figura 03 - O ciclo de vida - (THAMIEL, 2009) ....................................................................................... 16 Figura 04 - Sprint Burndown - (GIRL WRITES CODE, 2009).................................................................... 21 Figura 05 - Quadro Kanban - (SPARTA CONSULTORIA, 2009) ............................................................... 22 Figura 06 - Planning Poker - (SPRINT PLANNING, 2009) ....................................................................... 22 Figura 07 - Tipos de Teste - (DUONG, 2009) ......................................................................................... 26

SUMRIO
1. INTRODUO ...................................................................................................................................1 1.1 1.2 1.3 1.4 1.5 2. Problema ..................................................................................................................................1 Justificativa ...............................................................................................................................1 Objetivos ..................................................................................................................................2 Metodologia .............................................................................................................................2 Estrutura ...................................................................................................................................3

PROCESSOS GEIS ............................................................................................................................4 2.1 2.2 2.3 2.4 Definio ..................................................................................................................................4 O Manifesto gil .......................................................................................................................5 Conceitos Chave .......................................................................................................................9 Modelos....................................................................................................................................9

3.

SCRUM........................................................................................................................................... 13 3.1 3.2 3.3 3.4 3.5 A origem ................................................................................................................................ 13 Metodologia .......................................................................................................................... 14 O Ciclo de Vida ...................................................................................................................... 16 Papis .................................................................................................................................... 19 Ferramentas .......................................................................................................................... 21

4.

APLICABILIDADE DO SCRUM NO TESTE DE SOFTWARE ................................................................ 23 4.1 4.2 Equipes Metodologia Tradicional x Equipes Metodologia gil ............................................. 23 Os papis do Analista de Teste no Time Scrum..................................................................... 23

5.

ESTUDOS DE CASO ........................................................................................................................ 28 5.1 5.2 5.3 5.4 Voice Technology .................................................................................................................. 28 Ci&T ....................................................................................................................................... 29 Empresa A ............................................................................................................................. 30 EMBRAS.net .......................................................................................................................... 31

6. 7. 8.

VANTAGENS E DESVANTAGENS DO SCRUM ................................................................................. 33 CONCLUSO .................................................................................................................................. 36 REFERNCIA BIBLIOGRFICA ......................................................................................................... 37

xi

9.

ANEXO ........................................................................................................................................... 40

1. INTRODUO 1.1 Problema Em funo do fracasso no desenvolvimento de grandes projetos de software no incio da dcada de 70, surgiu a necessidade da criao de uma nova metodologia, como uma alternativa s metodologias tradicionais. Uma nova abordagem para desenvolvimento de software tem despertado grande interesse entre as organizaes de todo o mundo. Estamos vivendo uma tendncia para o desenvolvimento gil de aplicaes devido ao ritmo acelerado de mudanas na tecnologia da informao, presses por constantes inovaes, concorrncia acirrada e grande dinamismo no ambiente de negcios (BOEHM, 2006). Apesar de existir h um bom tempo, apenas recentemente a expresso Mtodos geis vem se tornando mais popular no Brasil por usar uma abordagem simplificada. No entanto, ser simples geralmente confundido com falta de controle e completa anarquia. Na verdade, ser simples, ter agilidade, fazer a diferena e, ao contrrio do que parece, exige muita disciplina e organizao. A expresso Mtodos geis est se tornando mais popular no Brasil apenas recentemente, apesar de ser um termo antigo. A simplicidade pode ser confundida com falta de controle, porm, a agilidade quebra esse paradigma, pois necessita de muita organizao e disciplina. Mtodos, prticas e tcnicas para o desenvolvimento gil de projetos prometem aumentar a satisfao do cliente (BOEHM, 2003) para produzir alta qualidade de software e para acelerar os prazos de desenvolvimento de projetos (ANDERSON, 2003).

1.2

Justificativa Nosso trabalho tem o enfoque na apresentao da utilizao da metodologia Scrum no Teste de Software, ressaltando benefcios como colaborao, integrao e boas prticas, auxiliando na qualidade e sucesso dos projetos.

Alm disso, sero apresentados modelos de adoo do Scrum em empresas e em equipes, demonstrando assim possveis problemas de adaptabilidade, j que poder ser uma grande mudana na forma de se trabalhar. Sero realizados estudos de viabilidade de adoo do Scrum, incluindo a equipe de Teste de Software, j que a metodologia veio se opor ao processo cascata de desenvolvimento, que joga os testes sempre para o fim esmagando os prazos e comprometendo a qualidade. Os riscos e vantagens da utilizao da metodologia Scrum vo ser listados, bem como os resultados obtidos da analise das empresas que utilizam o Scrum.

1.3 1.3.1

Objetivos Objetivo Geral O objetivo desse trabalho descrever o Processo gil Scrum, e analisar como o mesmo pode ser aplicado no Teste de Software.

1.3.2

Objetivos Especficos Identificar conceitos de Processos geis e da metodologia Scrum; Analisar a aplicabilidade do Scrum no Teste de Software; Descrever os papis da equipe de Teste no Time Scrum; Investigar em empresas que utilizam o Scrum, informaes relativas implantao, vantagens, desvantagens e aplicao da metodologia no Teste de Software; Descrever as vantagens e riscos inerentes a utilizao da Metodologia Scrum.

1.4

Metodologia Como metodologia de pesquisa para reunir informaes foi utilizada pesquisa Bibliogrfica, pesquisa em empresas que utilizam a metodologia, provas de conceito com a apresentao de resultados, a Internet para obter conhecimento sobre o que havia de novo sendo desenvolvido e quais as exigncias do mercado, a fim de conhecer profundamente a metodologia Scrum.

1.5

Estrutura O trabalho dividido segundo a estrutura a seguir: O captulo 2, intitulado Processos geis, abrange a definio e caractersticas dos Processos geis. O captulo 3, intitulado Scrum, conceitua a metodologia. O captulo 4, intitulado Aplicabilidade do Scrum no Teste de Software, descreve como a metodologia pode ser aplicada no Teste de Software. O captulo 5, intitulado Estudos de Caso, relata entrevistas realizadas com profissionais de empresas de desenvolvimento de software que utilizam o Scrum. O captulo 6, intitulado Vantagens e Desvantagens, lista as vantagens e as desvantagens provenientes da utilizao da metodologia no Teste de Software. Finalmente, o captulo 7 conclui o trabalho mostrando a relevncia do mesmo.

2. PROCESSOS GEIS 2.1 Definio Agilidade envolve disciplina e trabalho coordenado e pode tratar de projetos de vrios segmentos e portes. Agilidade a habilidade de criar e responder a mudanas com respeito ao resultado financeiro do projeto em um turbulento ambiente de negcios. Agilidade a habilidade de balancear flexibilidade com estabilidade. (Highsmith, Jim. Agile Project Management, 2002) Parte do princpio que os projetos devem ser desenvolvidos com uma estrutura e organizao necessrios. Estruturas e organizaes reduzem a criatividade e a flexibilidade de suportar mudanas, poucas estruturas e organizaes trabalham a ineficincia e resulta em esforos maiores que os necessrios. Em funo do fracasso no desenvolvimento de grandes projetos de software no incio da dcada de 70, surgiu a necessidade da criao de uma nova metodologia, como uma alternativa s metodologias tradicionais. Os mtodos de desenvolvimento conhecidos como geis (em ingls Agile Modeling, ou AG) possuem o objetivo de reduzir o ciclo de vida do software (e por conseqncia acelerar o seu desenvolvimento) atravs do desenvolvimento de verses mnimas. As funcionalidades so integradas por processos iterativos baseados na interatividade com o cliente e testes em conjunto e paralelo ao ciclo de desenvolvimento. Segundo Scott W. Ambler, Metodologia gil uma metodologia baseada na prtica para modelagem eficaz de software. um conjunto de prticas, onde os princpios e valores aplicados por profissionais de software no dia a dia so seguidos como guia. No um processo que define detalhadamente como criar um modelo, mas prov conselhos. Em 1990 o desenvolvimento de software gil evoluiu bastante em resposta a inconformidade dos mtodos tradicionais, caracterizados por uma pesada regulamentao e gerenciamento atravs do modelo cascata de desenvolvimento.

O processo originou-se da viso de que o modelo cascata era burocrtico, contraditrio e lento. Duas motivaes podem ser citadas como principais para a criao da Metodologia gil: O objetivo primrio de um projeto de software o prprio software, e no um grande conjunto de documentao sobre ele; Um artefato criado primordialmente para permitir a comunicao e a troca de informaes entre a equipe (um modelo de classes criado para passar para a equipe a hierarquia imaginada pelo projetista, assim como um diagrama de casos de uso criado para a equipe ter uma viso do mecanismo da funcionalidade envolvida) e permitir a discusso e refinamento do modelo do sistema. Assim, se um artefato no est passando informao relevante ao projeto, ele no cumpre seu objetivo bsico.

A criao dos Processos geis no implica no abandono das metodologias tradicionais e das prticas de engenharia de software.

2.2

O Manifesto gil O Manifesto gil uma declarao de princpios que fundamentam o desenvolvimento gil de software (WIKIPEDIA, 2009). Em 2001 foram apresentadas prticas efetivas para que fosse possvel a utilizao dos Processos geis no gerenciamento de projetos. Essas prticas foram compiladas atravs do consenso de grandes pensadores da comunidade de desenvolvimento de softwares e foram denominadas Manifesto gil. Os autores do manifesto so: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Ockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas. O manifesto gil cita doze princpios geis, vistos a seguir.

2.2.1

A prioridade satisfazer ao cliente atravs de entregas contnuas e Como a principal prioridade por um produto final de qualidade, foram feitas

freqentes pesquisas para definir quais as caractersticas durante a fase de desenvolvimento, que foram comuns nos processos que obtiveram sucesso. O resultado desta pesquisa revelou que o quanto antes se entregasse uma verso, mesmo que com poucas funcionalidades, do sistema, melhor seria a qualidade final, pois o sistema comearia a evoluir mais cedo. Sendo que essas verses deveriam ser atualizadas e entregues num perodo curto de tempo. Um Processo gil aquele que entrega cedo e constantemente. Tenta-se entregar o primeiro sistema j com algumas funcionalidades desenvolvidas e funcionais em algumas semanas do incio do projeto, sendo que novos pacotes de funcionalidades continuam sendo desenvolvidos e integrados ao mdulo anterior, no decorrer de algumas semanas. Isso deve ocorrer constantemente. de opo do cliente, escolher se vai implantar o sistema ainda no todo completo ou vai apenas test-lo para definir novas funcionalidades ou encontrar no conformidades com aquilo que necessrio.

2.2.2

Receber bem as mudanas de requisitos, mesmo em uma fase avanada do Indica atitude. Os participantes dos Processos geis no temem mudanas,

projeto pois assumem que as mudanas so indicadores de que o time est aprendendo sobre o sistema, possibilitando saber se vai satisfazer o mercado.

2.2.3

Entregas com freqncia, sempre na menor escala de tempo A idia entregar softwares funcionais regularmente em um curto perodo de

tempo. Documentaes e papis no contam como entregas, pois no satisfazem necessidade atual do cliente.

2.2.4

As equipes de negcio e de desenvolvimento devem trabalhar juntas Um processo gil precisa ser guiado constantemente, portanto necessria a

diariamente interao freqente de Clientes, Desenvolvedores e Partes Interessadas, pois todos fazem parte do time.

2.2.5

Manter uma equipe motivada fornecendo ambiente, apoio e confiana Os indivduos so parte fundamental do processo, como citados nos quatro

necessrios valores das Metodologias geis, portanto fundamental para o sucesso do projeto que todos estejam motivados, seja com o apoio de outros membros da equipe ou material e equipamento. Indivduos motivados trabalham melhor.

2.2.6

A maneira mais eficiente da informao circular atravs de uma conversa Conversao e Comunicao so valores bsicos dos Processos geis.

face-a-face Documentos e papis so suprfluos, apenas escritos quando extremamente necessitados e significantes. A maneira padro de troca de informaes a conversao.

2.2.7

Ter o sistema funcionando a melhor medida de progresso 30% do projeto esto concludos, quando 30% das funcionalidades necessrias

estiverem funcionando. O volume de documentos e qual fase do processo se est no determinam o progresso atual do projeto.

2.2.8

Processos geis promovem o desenvolvimento sustentvel A velocidade do desenvolvimento nos Processos geis deve ser sempre

constante. De nada adianta comear um projeto desenvolvendo de maneira rpida e essa velocidade no ser mantida, pois isso ir iludir o cliente, causando a ele uma impresso de falsa velocidade. Desenvolver em velocidades diferentes cansa mais os

desenvolvedores, fazendo-os ficarem estressados isso diminui a qualidade final do produto, quebrando um dos principais valores dos Processos geis.

2.2.9

Ateno contnua a excelncia tcnica e a um bom projeto aumentam a Alta qualidade a chave para a agilidade. Para manter rpido o

agilidade desenvolvimento necessrio deixar o software o mais limpo e o mais robusto possvel. Isso porque os times de Processos geis esto compromissados em desenvolver cdigos da melhor qualidade.

2.2.10

Simplicidade essencial O caminho a ser escolhido para desenvolver e projetar sempre o caminho

mais simples e consistente que leve ao resultado final esperado. A escolha do caminho mais simples implica em dizer que caso alguma mudana ocorra e elas vo ocorrer ser mais fcil alterar o que j foi feito.

2.2.11

As melhores arquiteturas, requisitos e projetos provm de equipes Decises so tomadas por toda a equipe e no por apenas um indivduo. Isso

organizadas caracteriza uma equipe organizada, pois todos trabalham juntos para o sucesso do projeto. Responsabilidades so compartilhadas pro todos os membros da equipe, mostrando que todos esto envolvidos no processo de um projeto.

2.2.12 eficaz

Em intervalos regulares, a equipe deve refletir sobre como se tornar mais Para uma equipe gil melhorar uma constante mxima. Sempre so feitas

reunies com a equipe a fim de encontrar novos pontos onde o time pode ser melhorado para satisfazer as necessidades atuais do meio, que est em constante mudana. O meio est sempre mudando e para a equipe continuar gil necessrio que ela mude de acordo.

2.3

Conceitos Chave Alguns defendem que alm dos itens citados no manifesto, deve-se levar em considerao os seguintes conceitos chave: Indivduos e iteraes ao invs de processos e ferramentas; Software funcional ao invs de documentao detalhada; Colaborao do Cliente ao invs de negociao de contratos; Responder s mudanas ao invs de seguir um plano.

2.4

Modelos Devido ao grande interesse da comunidade de desenvolvimento de software, tem crescido a demanda e com isso surgido uma considervel quantidade de mtodos geis nos ltimos anos, como:

2.4.1

Scrum um modelo de desenvolvimento gil de software e no uma frmula mgica

que resolver todos os problemas obtidos na sua empresa no processo de desenvolvimento. No baixada da Internet e nem precisa ser instalado, pois na verdade uma framework. Hoje em dia no Brasil e na Europa o Scrum a metodologia gil mais utilizada pelas pequenas, mdias e grandes empresas. O seu funcionamento acontece da seguinte forma: atividades de monitoramento e feedback, com reunies rpidas e dirias com suas equipes de poucos integrantes, visando a identificao e correo de qualquer problema no processo de desenvolvimento. uma mudana cultural na equipe de trabalho e no quer dizer que ao utiliz-lo, o mtodo em si far com que o seu cronograma seja cumprindo a risca, isso vai depender de toda a equipe tcnica envolvida no processo. Um dos pontos fortes dessa metodologia a maneira de se relacionar em equipe, ou seja, a parceria em times de profissionais cada um com sua especialidade tm o mesmo grau de comprometimento para a concluso e o sucesso do projeto.

10

2.4.2

Extreme Programmimg (XP) um modelo de desenvolvimento gil de software, mais utilizado pelas

pequenas e mdias empresas, tornou-se popular na dcada de 90 nos Estados Unidos e atualmente vem crescendo e sendo adotado com bastante freqncia no Brasil. O processo composto por quatro atividades: Planejamento, Projeto, Codificao e Teste e por quatro diretrizes: Feedback, Comunicao, Simplicidade e Coragem. Um dos pontos propostos por essa metodologia execuo de reunies de p, para que cada membro da equipe possa descrever as atividades realizadas no dia anterior de forma clara, rpida e objetiva. Essa metodologia muito utilizada em projetos cujos requisitos do projeto so sempre alterados. O cliente deve sempre se fazer presente e cabe a ele apontar as prioridades do projeto e dessa forma definir a ordem que as atividades sero executadas.

2.4.3

Feature Driven Development (FDD) uma metodologia gil com grande eficincia e aderncia a requisitos, muito

utilizada em softwares de tamanho mdio e grande. Tornou-se conhecida em 1997, definida por duas fases que so: Concepo e Planejamento e a de Construo, uma metodologia que agrada tanto o cliente, como os gerentes e desenvolveres. A FDD chama a ateno por algumas caractersticas peculiares: Resultados teis a cada duas semanas ou menos; Blocos bem pequenos de funcionalidade valorizada pelo cliente, chamados "Features"; Planejamento detalhado e guia para medio; Rastreabilidade e relatrios com incrvel preciso; Monitoramento detalhado dentro do projeto, com resumos de alto nvel para clientes e gerentes, tudo em termos de negcio; Fornece uma forma de saber, dentro dos primeiros 10% de um projeto, se o plano e a estimativa so slidos;

O lema da FDD : "Resultados frequentes, tangveis e funcionais."

11

2.4.4

Dynamic Systems Development Method (DSDM) uma metodologia de desenvolvimento de software onde o grande referencial

construir softwares de forma que satisfazem s restries de prazos apertados atravs de prototipagem incremental. Utilizado por pequenas equipes e suporta alterao de requisito durante o processo de desenvolvimento, criada em 1994, onde os princpios bsicos so: Iterao (duas a seis semanas); Releases freqentes; Qualidade total; Adaptabilidade a mudana de requisitos.

2.4.5

Adaptive Software Development (ASD) uma metodologia utilizada em sistemas grandes e complexos, definida por

ciclos de trs fases que so: Colaborao, Especulao e Aprendizado, cada ciclo dura de quatro a oito semanas. Criado em 1997, se baseia na idia de que Sistema Complexo igual a Resultados Imprevisveis. Suporta mudanas frequentes e a abordagem : Do it wrong the first time: erre cedo, corrija cedo, no potencialize malentendidos.

2.4.6

Famlia Crystal/Clear um conjunto de metodologias, uma para cada projeto definido de acordo com

a necessidade de cada um, voltada para projetos pequenos de no mximo seis desenvolvedores. Seu autor Alistair Cockburn (IBM - anos 90). Essas metodologias possuem como foco o desenvolvimento dividido em perodos curtos que so chamados iteraes. Essas iteraes duram em mdia de duas a quatro semanas. Ao final de cada perodo de iterao possvel ter um software j com partes funcionais, possvel de ser usado. Seguem processos iterativos e sucessivas entregas ao cliente, dessa forma, desde cedo o cliente pode verificar se o que est sendo construdo atende as suas necessidades e expectativas.

12

O Scrum, particularmente tem tido um crescimento visvel na indstria de software, e concentra-se no planejamento e acompanhamento do projeto.

13

3. SCRUM 3.1 A origem Scrum o nome de uma jogada do rugby; um jogo britnico com oito jogadores em cada time. Acontece na disputa pela bola em casos de penalidades ou faltas. Os jogadores dos dois times, um de cada lado, formam um nico bloco de pessoas encaixadas pelos ombros e pelos braos. A bola jogada no meio desse bloco. Neste momento um time tenta empurrar o outro at que a bola saia entre as pernas dos jogadores e jogo continue.

Figura 01 - O Scrum - (CLARIFICATION, 2009)

O ponto crucial dessa jogada o trabalho em equipe, onde se um falhar na formao, o outro time ganha bola e domina a situao. Em 1986, Hirotaka Takeuchi e Ikujiro Nonaka publicaram um estudo intitulado de "The New Product Development Game" (Harvard Business Review, Janeiro-Fevereiro 1986). Nesse estudo, eles compararam equipes pequenas, de alto desempenho e multidisciplinares jogada "Scrum" do Rugby. Takeuchi e Nonaka descobriram que utilizando esse tipo de equipe, obteriam melhores resultados. Desenvolveram ento, o Scrum voltado para gerenciar o desenvolvimento de produtos em empresas de fabricao de automveis e produtos de consumo.
Cada elemento deste por si no traz velocidade e flexibilidade. Mas tomados como um todo, formam caractersticas que podem produzir um poderoso conjunto de dinmicas que fazem a diferena. (TAKEUCHI, NONAKA, 1986, p. 137).

14

Para eles, existem os seguintes fatores de sucesso para o Scrum: Instabilidade Intrnseca Times Auto-Organizados Fases de Desenvolvimento Sobrepostas Multi-Aprendizado (Multi-Nvel e Multi-Funcinal) Controle Sutil Transferncia de Conhecimento Organizacional

Em 1993, Jeff Sutherland, John Scumniotales, e Jeff McKenna, incorporando o estilo de gerenciamento observado por Takeuchi e Nonaka, criaram, documentaram e implantaram o Scrum na empresa Easel Corporation. Dessa vez, voltado para gerenciar o desenvolvimento de projetos de software. Mais tarde, em 1995, Ken Schwaber formalizou a definio de Scrum e ajudou a implant-lo em desenvolvimento de software em todo o mundo. Em 1996, Schwaber e Sutherland apresentaram o Scrum na Object-Oriented Programming, Systems, Languages and Applications (OOPSLA), uma conferncia anual sobre programao, sistemas, linguagens e aplicaes. O Scrum junta conceitos do pensamento Lean de desenvolvimento iterativo e incremental. O pensamento Lean um conjunto de conceitos e procedimentos, que tem como objetivo simplificar o modo como uma organizao acaba com os desperdcios. Atualmente, o Scrum vem se enquadrando junto s necessidades dos projetos de software, com a proposta de tornar os projetos mais flexveis e geis, se tornando uma das mais utilizadas metodologias da atualidade.

3.2

Metodologia O Scrum uma metodologia gil para gesto e planejamento de projetos de software. um processo de desenvolvimento iterativo e incremental que pode ser aplicado a qualquer produto ou at mesmo no gerenciamento de uma atividade complexa, ou seja, sempre que um grupo de pessoas necessite trabalhar em conjunto para atingir um objetivo comum.

15

Mike Cohn definiu o Scrum em 100 palavras:

Scrum um processo gil que permite manter o foco na entrega do maior valor de negcio, no menor tempo possvel. Isto permite a rpida e contnua inspeo do software em produo (em intervalos de duas a quatro semanas). As necessidades do negcio que determinam as prioridades do desenvolvimento de um sistema. As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de maior prioridade. Entre cada duas a quatro semanas todos podem ver o real software em produo, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais um Sprint. (SCRUM TRAINING & AGILE TRAINING FROM SCRUMMASTER MIKE COHN, 2009)

O Scrum aplica o modelo de gerenciamento emprico.

Figura 02 - Modelo de Gerenciamento Emprico - (CORDEIRO, 2006)

Trs pilares sustentam qualquer implementao de controle de processos empricos. O primeiro pilar a transparncia, que visa garantir que aspectos do processo que afetam o resultado devem ser visveis para aqueles que gerenciam os resultados. O segundo pilar a inspeo. Todos os aspectos do processo devem ser inspecionados com uma freqncia suficiente para que qualquer situao no programada no processo seja detectada. O terceiro pilar a adaptao. A partir da inspeo, que um ou mais aspectos do processo esto fora dos limites aceitveis e que o produto resultante ser inaceitvel, ele dever ajustar o processo ou o material sendo processado.

16

O Scrum inspeciona a condio das tarefas e empiricamente determina o que deve ser feito para produzir o resultado esperado. Parte do princpio de que nem todas as caractersticas do produto so conhecidas na anlise e que provavelmente os requisitos mudaro com o passar do tempo. O Scrum um processo que controla a desordem resultante de necessidades e interesses. uma forma de aumentar a comunicao e maximizar a cooperao e tambm detectar e remover qualquer impedimento que atrapalhe o desenvolvimento de um produto, no h prtica de engenharia prescrita e as equipes se auto-organizam.

3.3

O Ciclo de Vida

Figura 03 - O ciclo de vida - (THAMIEL, 2009)

3.3.1

Sprints Os Sprints so ciclos (ou iteraes) peridicos que podem variar de duas a

quatro semanas de durao. Durante o perodo estabelecido para o Sprint so realizadas as atividades pr-definidas no Product Backlog. uma parte importante do ciclo de vida do Scrum. Cada Sprint deve ser conduzido com muita ateno e cuidado.

3.3.2

Sprint Planning uma reunio realizada no comeo de cada Sprint, visa traar a meta de

trabalho para cada ciclo.

17

3.3.3

Sprint Backlog So todas as tarefas que devem ser desenvolvidas durante cada Sprint

extradas do Product Backlog. Tem como objetivo dar visibilidade ao Projeto. Deve ser visvel e de fcil acesso aos membros do Scrum Team. fundamental que no sofra nenhuma alterao durante a iterao. As atualizaes devem ser registradas em tempo real e podem ser apresentadas atravs de um quadro chamado Kanban.

3.3.4

Product Backlog o que o cliente deseja implementar. uma lista que contm todas as tarefas a

serem realizadas, incluindo a prioridade de cada uma. As tarefas devem ser descritos de forma clara e simples. Definidas as prioridades, cabe ao Scrum Team determinar quais os itens sero implementados no prximo Sprint. Cada item do Product Backlog dividido em uma ou mais tarefas do Sprint Backlog. Essa diviso auxilia na distribuio do trabalho entre os membros da equipe. No existe nenhuma obrigatoriedade do Product Backlog estar completo j no comeo do projeto. Ele deve comear com os itens que so mais importantes em um primeiro momento. O Product Backlog cresce e muda medida que se aprende mais sobre o produto e seus usurios. O Product Owner deve estar priorizando e atualizando o Product Backlog constantemente, sempre em funo da viso do produto.

3.3.5

Daily Scrum uma breve reunio realizada diariamente, com durao mxima de 15

minutos. O objetivo compartilhar disseminar conhecimento sobre as atividades realizadas no dia anterior, identificar os problemas, os riscos e priorizar as tarefas que sero realizadas naquele dia. Aconselha-se que ocorra pela manh.

18

Durante o Daily Scrum, cada membro do Scrum Team deve responder s seguintes trs perguntas: O que voc fez ontem? O que voc far hoje? H algum impedimento no seu caminho?

As respostas dessas perguntas auxiliaro o Scrum Team na compreenso do status atual do Sprint. A reunio importante tambm, pois faz com que cada membro da equipe assuma compromissos perante os demais. Os problemas impeditivos identificados durante o Daily Scrum devem ser tratados rapidamente pelo Scrum Master.

3.3.6

Sprint Review uma reunio realizada ao final de cada Sprint. O projeto avaliado e o Scrum

Team apresenta os resultados obtidos durante o Sprint. S devem ser apresentados os itens que estiverem 100% prontos, atravs de uma demonstrao funcional. Deve ter a durao mxima de duas horas. Os slides e vdeos de apresentao so dispensados em funo da informalidade da reunio. O Product Owner tem o direito de aceitar ou rejeitar o Sprint. Qualquer necessidade de mudana, como a incorporao de novas tarefas ao Product Backlog, devem ser tratadas em momento oportuno e priorizadas novamente.

3.3.7

Sprint Retrospective uma reunio realizada ao final de um Sprint. O objetivo garantir um

processo de melhoria continua. O Sprint Retrospective visa identificar o que funcionou, o que precisa ser melhorado e quais aes sero tomadas para melhorar. Ou seja, avaliar e aprender com a experincia visando aumentar a produtividade.

19

Nessa reunio obrigatria a participao do Scrum Team. O Product Owner depende de um convite da equipe para acompanh-la. Cabe ao Scrum Master registrar todas as informaes e o time prioriza a ordem ideal de mudana. Aconselha-se que o tempo de durao seja de 15 a 30 minutos.

3.4 3.4.1

Papis Product Owner O Product Owner o procurador do cliente, sua funo consiste em representar e defender os seus interesses. Est sob sua responsabilidade tambm, criar, manter e priorizar a lista de tarefas do projeto. ele quem define as metas de trabalho do Scrum Team para cada Sprint. A equipe se compromete a executar o conjunto de atividades estabelecidas e o Product Owner se compromete a no trazer novos requisitos durante o Sprint. vlido ressaltar que o Product Owner no o chefe do Scrum Team, no tem poder de deciso sob aspectos tcnicos e no pode impor datas e quantidades de itens que a equipe deve trabalhar em cada Sprint. Para exercer o papel de Product Owner, as seguintes caractersticas so necessrias: Viso estratgica Criatividade Persuaso Comunicao Disponibilidade Conhecimento do Negcio

3.4.2

Scrum Team a equipe responsvel pela execuo direta das tarefas do projeto. Deve

possuir entre cinco e nove componentes, com caractersticas multidisciplinares. Na equipe no haver rtulos como analistas, arquitetos, coordenadores e gerentes. Todos so membros da equipe.

20

O Scrum Team responsvel pela definio das estimativas de tempo e esforos das tarefas, e devem manifestar os impedimentos ao Scrum Master. Os membros da equipe no devem aguardar ordens. Devem tomar iniciativas para a concluso das tarefas do projeto. As seguintes caractersticas so necessrias: Ser auto-gerenciado Multidisciplinar Comprometido Comunicativo Resolvedor de Conflitos

3.4.3

Scrum Master um removedor de obstculos. Sua funo proteger o Scrum Team de

influencias externas. Assim a equipe tende a ter um caminho mais fcil para obter sucesso no Sprint definido. Auxilia o Product Owner no processo de conduo dos requisitos. sua funo tambm combater a iluso do comando alm de priorizar impedimentos e remove-los. O Scrum Master no chefe de ningum, ele deve exercer um papel facilitador, moderador. ele quem conduz todas as reunies. importante que seja um profundo conhecedor do Scrum para que consiga contagiar a equipe com a utilizao das boas praticas. O Scrum Master deve ser: Responsvel Comunicativo Humilde Facilitador Organizado Influente

21

3.5 3.5.1

Ferramentas Sprint Burndown Tem com objetivo mostrar o esforo restante para a concluso do Sprint, bem como mostrar o quo prximo (ou distante) o Scrum Team se encontra de atingir a meta.

Figura 04 - Sprint Burndown - (GIRL WRITES CODE, 2009)

A coluna vertical representa a quantidade de esforo. A coluna horizontal representa os dias de um Sprint. A Linha Vermelha representa o Fluxo ideal de trabalho. Quando o grfico est acima da linha vermelha significa que o time est distante de atingir a meta. Quando est em cima da linha vermelha significa que est no fluxo de trabalho ideal. E quando est abaixo da linha vermelha significa que o time est superando as expectativas. O Sprint Burndown deve ser atualizado diariamente.

22

3.5.2

Quadro Kanban um quadro que visa auxiliar o acompanhamento da execuo das tarefas.

Viabiliza a visibilidade e a comunicao entre os integrantes da equipe.

Figura 05 - Quadro Kanban - (SPARTA CONSULTORIA, 2009)

3.5.3

Planning Poker
Cada membro da equipe recebe um baralho de 13 cartas como mostrado acima. Sempre que uma estria deve ser estimada, cada membro escolhe uma carta que representa a sua estimativa de tempo (em pontos por estria) e coloca-a virada para baixo sobre a mesa. Quando todos os membros da equipe tiverem feito sua estimativa, as cartas so reveladas simultaneamente. Dessa forma, cada membro da equipe forado a pensar por si prprio ao invs de basear-se na estimativa de outra pessoa. Se houver uma grande divergncia entre duas estimativas, a equipe discute as diferenas e tenta chegar a uma viso comum do trabalho envolvido na estria. Eles podem fazer algum tipo de decomposio de tarefas. Depois disso, a equipe faz novamente a estimativa. Esse processo repetido at que as estimativas de tempo cheguem a uma convergncia, isto , todas as estimativas sejam aproximadamente a mesma para cada estria (KNIBERG, 2008, p.45)

Figura 06 - Planning Poker - (SPRINT PLANNING, 2009)

23

4. APLICABILIDADE DO SCRUM NO TESTE DE SOFTWARE 4.1 Equipes Metodologia Tradicional x Equipes Metodologia gil Na metodologia tradicional, as equipes so divididas por rea. Cada rea representa uma funo distinta e no h uma integrao entre as mesmas. No Scrum todas as equipes (Configurao/Instalao, Negcios, Teste, Desenvolvimento, entre outros) fazem parte de um mesmo Time. Com a fuso das equipes no mesmo Time, o Scrum permite que todos trabalhem de forma integrada facilitando a comunicao, gerando um ambiente de parceria e um verdadeiro esprito de equipe na empresa. Desta forma, a equipe de Teste no vista pela equipe de desenvolvimento como adversria, mas sim parceira. Como as equipes so um nico Time no Scrum, o conceito do que precisa ser entregue est pronto, pode ser diferente, pois um determinado item pode estar pronto dependendo do conceito de concluso/trmino estabelecido pela equipe. O item pronto pode ser: Codificao concluda ou Codificao + Teste concludos ou Codificao + Teste + Integrao concludas, ou Teste concludos ou Codificao + Teste + Integrao + Regresso. Por isso, necessrio que a equipe defina quando um item vai estar realmente pronto. Para cada item, a definio de pronto pode ser diferente, vai depender do que cada um se prope. 4.2 Os papis do Analista de Teste no Time Scrum O Analista de Teste no Scrum assume vrios papis como Lder, Arquiteto e Automatizador. Em cada fase do projeto, ele coloca o chapu necessrio. Um dos papeis que o Analista de Teste pode exercer, o de Product Owner (PO). O PO o responsvel pela viso do produto, ou seja, a representao da sua necessidade, o que deve ser satisfeito ao fim do projeto. Para a definio dessa viso, o PO, colhe informaes com os clientes, usurios final, time, gerentes, stakeholders e executivos. O Analista de Teste participa da fase de definio da viso do produto contribuindo com as seguintes tarefas:

24

Colaborao nas reunies com o cliente para levantamento dos requisitos; Participao das reunies de Brainstorm; Foco na viso da qualidade do produto; Revisa a abordagem de teste; Identifica as habilidades de teste necessrias para o projeto.

O Product Owner (PO) cria uma lista inicial de necessidades para que a viso do produto seja bem sucedida. Esta lista chamada de Product Backlog. O Analista de Teste participa desta fase realizando as seguintes tarefas: Participa de discusses de arquitetura; Participa das definies de tecnologias utilizadas; Identifica as necessidades do ambiente de teste; Identifica restries tecnolgicas; Identifica ferramentas de teste necessrias para auxiliar na execuo do projeto; Utiliza mapa mental (Mind Map) para auxiliar no entendimento das funcionalidades/requisitos; Identifica os melhores analistas de teste para o projeto em questo; Identifica a necessidade de suporte do time de suporte/operaes.

Estimar uma atividade do Time no Scrum. Como o Analista de Teste faz parte do Time, ele participa tambm desse processo. Alm dele, o Scrum Master deve mediar o processo, o Product Owner deve estar disponvel para esclarecer eventuais dvidas. Na primeira parte do Planning Meeting o PO define a meta da Sprint e divulga para o Time os itens prioritrios do Product Backlog. O Time deve estimar os itens em tamanho e selecionar o que vai ser feito. O Analista de Teste participa dessa fase realizando as seguintes tarefas: Ajuda a garantir que os itens selecionados esto de acordo com a meta do projeto e teste; Analisa indicadores de desempenho;

25

Revisa a estimativa, caso necessrio; Gerencia os riscos encontrados; Tira dvidas com o Product Owner; Define quais sero os tipos de teste (Sistema, Aceitao, Regresso) necessrios.

Na segunda parte da Planning Meeting o time colhe mais detalhes dos itens do Select Product Backlog e os divide em tarefas gerando o Sprint Backlog. Aps a decomposio, cada membro do Time escolhe as tarefas que deseja executar durante a Sprint e estim-las. O Analista de Teste participa desta fase com a seguinte contribuio: Define o nvel de regresso de teste de acordo com a priorizao dos itens/tarefas do Sprint Backlog; Atualiza a matriz de teste por funcionalidade; Atualiza o mapa mental.

Aps a definio da Sprint, o quadro de acompanhamento preparado. Ele pode ser alterado de acordo com a sua realidade e necessidade. Durante a execuo da Sprint o Scrum Master atravs da sua capacidade de liderana e colaborao, facilita o trabalho do Time removendo os impedimentos encontrados e garantindo a boa aplicao do Scum.

26

Figura 07 - Tipos de Teste - (DUONG, 2009)

Q1 So os testes que focam na arquitetura. A responsabilidade dos desenvolvedores e os analistas de teste auxiliam na elaborao dos testes unitrios automticos;

Q2 So os testes que focam no negcio. A responsabilidade dos analistas de teste em conjunto com outros envolvidos no projeto(clientes, usurios, etc.). Ajuda no entendimento das funcionalidades;

Q3 So os testes que focam no negcio e encontrar defeitos. A responsabilidade dos analistas de teste;

Q4 So os testes que focam na arquitetura, estrutura do software. A responsabilidade dos analistas de teste.

Durante a execuo da Sprint o Analista de Teste possui o seguinte papel: Monta e configura o ambiente e infra-estrutura de teste; Executa testes; Automatiza casos e tarefas de teste; Auxilia os desenvolvedores na elaborao dos testes unitrios automticos; Evidencia os resultados; Acompanha os defeitos encontrados;

27

Desenvolve novas habilidades; O Analista de Teste a pessoa que aprova. Nada considerado pronto em um Sprint at que ele diga que est;

responsvel em ficar focado na meta da Sprint.

Na reunio diria (daily Scrum) de 15 minutos, o time ganha visibilidade de como est o caminho para a meta e planeja o dia seguinte de trabalho. O Scrum Master o facilitador. O Analista de Teste tambm participa dessas reunies contribuindo com as seguintes confeces: Relatrio de teste atualizado; Evidncia de teste atualizada; Grfico S-Curve atualizado; Lista de defeitos atualizada; Lista de impedimentos atualizada; Quadro Kanban atualizado.

O Analista de Teste participa de outras duas reunies. Reunio de Reviso, que possui o propsito de apresentar o que foi feito para o Product Owner e convidados e Reunio de Retrospectiva que possui o objetivo de representar o esprito de Inspeo Adaptao dentro do Scrum. Na reunio de Reviso, realizada uma apresentao por todo o Time e o Product Owner avalia se a meta foi alcanada e faz anotaes que podem ser transformar em novos itens para o Product. A reunio de Retrospectiva facilitada pelo Scrum Master onde so apresentas as lies aprendidas. O Time avalia o que foi bom na ltima Sprint, o que deve ser melhorado e quem est no controle. O Analista de Teste deve participar de todas as fases do Scrum, pois ele faz parte de um Time. No existe Time de Teste ou Desenvolvimento no Scrum, mas sim, Time do Scrum.

28

5. ESTUDOS DE CASO Para o nosso estudo de caso, realizamos entrevistas com profissionais da rea de Teste de Software das empresas colaboradoras, com intuito de levantar como ocorreu o processo de implantao do Scrum e verificar a existncia ou ausncia das vantagens e desvantagens propostas em nosso trabalho. Para idealizao dos Estudos de Caso, enviamos para os respectivos colaboradores o questionrio base que se encontra no item 9, Anexo. O objetivo do questionrio era visualizar a utilizao do Scrum nas empresas. Aps as respostas, novas comunicaes foram realizadas atravs das ferramentas Gtalk, Skype e e-mails para refinar a pesquisa e concluir o entendimento.

5.1

Voice Technology A Voice Technology uma empresa de pequeno porte do ramo de desenvolvimento outros. O Scrum foi iniciado na empresa no final de 2008. O nvel de envolvimento da empresa na implantao da metodologia foi baixo, pois a iniciativa surgiu de um gerente de projeto, e apenas alguns Shareholders se interessam em conhecer mais sobre o framework, e o mesmo no foi amplamente adotado pelos outros departamentos da empresa por comodismo e medo de mudana. O primeiro projeto da empresa que ousou e adotou a metodologia, teve os seguintes benefcios: Melhor alinhamento com a equipe de desenvolvimento, graas as participaes nas reunies de planejamento e review; Maior entendimento sobre o sistema, o que ajudou na elaborao dos testes e melhorou o planejamento dos testes, como por exemplo, uma melhor seleo dos testes de regresso a serem realizados. de software. Desenvolve sistemas para o mercado de Telecomunicaes: URAs, Discadores, PABX Virtual, Sistemas de Conferncia, entre

29

Diminuio do retrabalho, principalmente devido aos testes realizados durante o desenvolvimento, pois os mesmos davam um feedback mais rpido ao desenvolvedor, que poderia corrigir os defeitos, e assim a verso final, entregue ao time de teste era entregue com uma maior qualidade. No segundo projeto da Voice Technology que adotou o framework, o principal benefcio foi a efetividade dos testes, pois o profissional responsvel pela maioria das tarefas de Teste Software, tambm participava ativamente das tarefas de desenvolvimento e se envolvia com os desenvolvedores e o Product Owner, e assim tinha uma viso completa tanto da parte tcnica quando da parte de negcio. Podendo assim criar cenrios de teste tanto de verificao quanto na validao do sistema. Um ponto interessante do time de Scrum, que as pessoas costumam exercer variados papis durante o projeto, isso muito bom para o time, mas difcil para encaixar a pessoa em uma grade salarial. A participao de todos os membros do time em algumas atividades de teste, como a execuo, e a comunicao "frente-a-frente" diminuiu bastante a quantidade de retestes, comparando com outros projetos. Em ambos projetos citados o Scrum no trouxe nenhuma influencia negativa. As experincias foram muito boas, e trouxeram timos resultados, tanto para as equipes como para os clientes. Um detalhe importante que mesmo com os projetos no utilizando todas as prticas do Scrum e dos princpios geis, pudemos considerar a implantao do Scrum, como um sucesso, pois se encaixou bem nos projetos e com ele as equipes puderam fazer o seu melhor trabalho e buscar a melhoria contnua.

5.2

Ci&T A Ci&T uma empresa de mdio porte do ramo de desenvolvimento de software. Desenvolve sistemas em .NET, Java e PHP. O Scrum foi iniciado na empresa em meados de 2008. Para adoo da metodologia nos projetos depende de uma anlise especfica de cada projeto e de cada cliente. E quando adotada, abrange toda a rea de desenvolvimento.

30

A empresa est buscando cada vez mais aplicar o conceito de Lean It, gerando mais valor para o cliente, com o menor custo (tempo e recursos). Com isso a empresa est fortemente envolvida em oferecer a metodologia para novos clientes, e aprimorar o processo a cada novo projeto. Para a rea de Teste da empresa, o Scrum significou uma grande melhoria na qualidade dos processos. As equipes ficaram mais integradas, os erros nos sistemas foram reduzidos.

5.3

Empresa A A Empresa A, uma empresa de grande porte e desenvolve sistemas customizados em C#. O Scrum iniciou na empresa no final de 2008, e atualmente abrange a rea de desenvolvimento da empresa. A empresa apoiou com os recursos necessrios, mas a implantao e execuo foi de total responsabilidade da equipe. As equipes so compostas por 6 profissionais. O Teste est envolvido na construo (TDD) e na documentao do software. Os artefatos de descrio dos casos de uso s so mantidos durante a construo, depois de implementados os testes passam a ser a documentao do sistema. O grande benefcio que o Scrum trouxe para a equipe de Teste de Software a possibilidade de melhorar as tcnicas e os procedimentos por Sprint. Como ponto negativo, como nem toda a equipe estava preparada pra trabalhar com Scrum, os primeiros Sprints foram mais demorados e tiveram mais re-trabalho. O nome da empresa fictcio. O colaborador optou pela no divulgao do nome da empresa.

31

5.4

EMBRAS.net A EMBRAS.net uma empresa de mdio porte que desenvolve nas linguagens Delphi e PHP o SIAP, um ERP voltado para Prefeituras, Cmaras e Autarquias Municipais. O Scrum iniciou na empresa, h aproximadamente 09 meses, com a implantao de algumas prticas. Hoje, abrange os departamentos de Desenvolvimento (e Manuteno) de Software, Qualidade (Teste, Homologao e Documentao) e tambm com participao do departamento de Suporte Tcnico que prioriza as tarefas, fazendo assim o papel do Product Owner. Antes da implantao do Scrum, houve uma resistncia natural. Toda a equipe de desenvolvimento interna e empresas terceirizadas foram treinadas para que conhecessem as prticas da metodologia, com isso tambm foi passado o conhecimento para outros departamentos como o de Qualidade (Teste, Homologao e Documentao) e o de Suporte, para que pudessem participar do processo. Atualmente, existem 4 times de Scrum, sendo 2 times internos e 2 times terceirizados, compostos em mdia por 5 integrantes cada. O Teste se utiliza de Sprints sincronizados com o desenvolvimento, e tem a misso de homologar ou reprovar tudo que foi desenvolvido pelo desenvolvimento, antes de chegar ao cliente, dando um feedback para os desenvolvedores para que os mesmos possam corrigir o mais rpido possvel. Aps a homologao, entra o trabalho do documentador que inicia a atualizao dos documentos: descritivo do sistema (para fornecer ao departamento Comercial material sempre atualizado), novidades da verso (lista de melhorias e correes de bugs que foram realizados no Sprint de cada sistema homologado), help e manual do sistema (para auxlio ao usurio) e documento interno de treinamento (este documento contm todas as implementaes concludas no Sprint por sistema, e utilizado para a realizao do treinamento interno do departamento de Suporte, um dia antes da liberao dos sistemas para os clientes). Deste modo, quando o cliente recebe a nova verso do sistema, o Suporte j esta preparado para ajud-lo.

32

Antes do Scrum, o Teste funcionava de acordo com o modelo cascata. No existia entrosamento entre o departamento de Qualidade (Teste, Homologao e Documentao) e o departamento de Desenvolvimento (e Manuteno) de Software, alm disso a comunicao possua muitas falhas. Com o Scrum, os departamentos passaram a ter uma padronizao nos eventos, uma sincronizao entre as tarefas de cada equipe e uma interatividade muito maior. Assim, ganharam produtividade e qualidade, diminuram situaes emergenciais, alm de terem criado um processo simples, que conhecido e envolve toda a empresa. O Scrum no influenciou negativamente em nenhum aspecto. A metodologia no utilizada em sua totalidade, mas so usadas boas prticas que atendem a necessidade da empresa. Basicamente o Scrum organizou as entregas com a configurao dos Sprints, melhorou o foco de trabalho com o Sprint Backlog e tornou mais assertivas as entregas dos "pacotes" de softwares aos clientes.

33

6. VANTAGENS E DESVANTAGENS DO SCRUM Todas as metodologias possuem vantagens e desvantagens e com o Scrum no seria diferente. Uma das grandes vantagens da metodologia Scrum a comunicao que existe entre todos os envolvidos da equipe, pois todos participam das decises, fazendo com que a comunicao acontea de forma clara e objetiva. Outro ponto positivo a forma de se trabalhar com divises de tarefas, isso faz com que todas as pessoas envolvidas, participem de todas as tomadas de decises e resolues de problemas, e vale ressaltar, que alm da equipe de desenvolvimento, o cliente participa tambm de forma ativa desde o comeo do projeto, o que colabora ainda mais com a propagao da informao. A participao do cliente traz fortes benefcios e de certa forma se destaca tambm no Scrum, pois o contato com os desenvolvedores, alm de permitir a divulgao do que ser de fato produzido, colabora com o feedback do cliente junto a empresa, que acontece de forma rpida e eficaz, colaborando e muito com o seguimento do processo. Dessa forma, a organizao estabelece uma relao de confiana e credibilidade junto ao seu cliente, pois, se todos participam com empenho, o resultado desse esforo com certeza gera produtos funcionais e com excelente qualidade, e a sincronia da equipe gera uma acelerao no tempo de desenvolvimento, e com isso se ganha tempo; e tempo dinheiro, quando falamos de desenvolvimento de software. O Scrum tambm se destaca por ter uma forma de trabalhar bem flexvel e de fcil adaptao, podendo ser aplicada em diversos ambientes. Alm do fato de trabalhar de forma transparente e eficiente, trabalha com constantes alteraes de escopo. A forma como trabalhada, faz com que essas alteraes no interferem de forma ativa nos custos do projeto, uma vez, que todas as mudanas so definidas e discutidas constantemente com o cliente, evitando surpresas na concluso das tarefas. Isso porque o Scrum trabalha de forma totalmente diferenciado no quadro de atividades, ou seja, todo o processo dividido em pequenos ciclos, chamados de Sprint, e caso venha ocorrer mudana de escopo ou at mesmo, mudanas na equipe de trabalho, a alterao e a incluso de um novo membro na equipe acontece de forma dinmica, uma vez que os pequenos ciclos tem um tempo curto de durao, isso,

34

facilita qualquer tipo de mudana que venha acontecer. Essa vantagem do Scrum faz com que, seja uma metodologia indicada para processo de desenvolvimento de software que constantemente so alteradas, e essas alteraes no influencia de forma impeditiva na concluso do processo. Alm dessas vantagens, uma metodologia de fcil automatizao, isso influncia diretamente em custos e prazos, e colabora de forma efetiva no controle das atividades a serem desenvolvidas. Devido ao efetivo controle, a participao do gerente de projeto, torna-se de suma importncia, principalmente no gerenciamento de conflitos e resoluo de quaisquer problemas que venha de certa forma, atrapalhar ou at mesmo impedir a concluso do processo, ou at mesmo de alguma atividade. Devido ao fato do Scrum suportar diversas mudanas, essa vantagem, pode ser vista de certa forma, como uma desvantagem, isso porque, para suportar mudanas constantes, necessrio trabalhar de forma bem exigente, tendo a frente um gerente de postura firme, para tomar todas as providncias que venha ser necessria para suprir os obstculos que a equipe venha encontrar. Sabemos o quo isso difcil, pois gesto de pessoas acaba sendo classificado pelas organizaes, como ponto de grande dificuldade, ainda mais na metodologia Scrum, onde, cada membro da equipe tem liberdade de expresso, isso pode causar certos desentendimentos entre os gestores, dessa forma, deve-se, gerenciar com muita autoridade de deciso e flexibilidade, sendo capaz de adaptar e aceitar bem as mudanas, e manter o controle de todos os conflitos, respeitando as opinies de todos os envolvidos, alm de garantir o entrosamento da equipe, inclusive, permitir que os todos os membros sejam autnomos o suficiente em suas tarefas, a ponto de terem em alguns momentos liberdade para tomar suas prprias decises. Para que isso acontece de forma tranqila o gerente, no caso o Scrum Master deve confiar em sua equipe, pois, ser rigoroso demais, pode influenciar e muito no fracasso do projeto. Dessa forma, exige um acompanhamento quantitativamente. Para se trabalhar de forma adequada no Scrum, necessrio que se tenha mode-obra especializada e no simplesmente, micro gesto. E mo-de-obra especializada custa caro. bem rigoroso do gerente tanto qualitativamente como

35

Alm disso, no podemos deixar de dizer que se trata de uma metodologia inovadora e flexvel, causando nas pessoas certa resistncia ao novo. Outro ponto, considerado negativo, a informalidade que o Scrum trabalha a documentao, pois no tem a preocupao em documentar, o foco que prevalece, o que ser desenvolvido. Como no Scrum se permite mudanas de escopo, isso pode fazer com que, gere projetos duradouros, j que no inicio do clico de desenvolvimento no temos a visibilidade concreta da finalizao do projeto. Uma vez que, a definio das tarefas, quando no definidas adequadamente, gera dificuldade para estimar o custo e o andamento do projeto, j que o tempo no fator principal e sim a concluso da tarefa. A forma de trabalhar com equipes pequenas (7 a 9 pessoas), pode tambm ser vista como desvantagem, pois, pode trazer alguns problemas quando essa equipe vai crescendo e precisa ser novamente dividida, essa nova diviso, pode fazer com que haja uma perda do foco entre os membros da equipe, porm, trabalhar com equipe grande pode causar inmeras falhas, dessa forma, a diviso pode ser inevitvel. Alm de participao, necessrio que o cliente tenha uma viso bem clara do que se deseja, pois a instabilidade pode fazer com que, o projeto no tenha sucesso, portanto o perfil do cliente de suma importncia e nem sempre isso pode ser alcanado facilmente.

36

7. CONCLUSO Um fator que contribui para o sucesso do Scrum a maneira como se trabalha em equipe, dividindo todos os recursos, em pequenos grupos, sendo sempre equipes pequenas, isso faz com que todos sejam mais participativos e se empenhem melhor em suas atividades. Com a participao ativa de todos, o andamento do processo acontece de forma clara, que de certa forma, gera tambm, aumento de produtividade. Devido flexibilidade, a organizao pode ter que realizar alteraes na sua estrutura organizacional, para melhor adequar ao funcionamento do Scrum j que, a metodologia exige certo nvel de formao de todos os envolvidos. Com a participao do Analista de Teste em um Time do Scrum, podemos identificar os seguintes benefcios: Integrao do time; Apoio de quem est desenvolvendo cdigo durante a execuo dos testes; Apoio de quem est testando cdigo durante a codificao; Participao mais direta e ativa do profissional que est testando o software; Profissionais que esto desenvolvendo cdigo interessados em aprender sobre teste; Profissionais que esto testando cdigo interessados em aprender sobre programao; Agilidade, interao com testes; Acompanhamento de defeitos pelo profissional que est testando o software; Analistas de Teste deixaram de ser reativos para serem pr-ativos.

Apesar da resistncia inicial, no geral as empresas que aderem utilizao de um Processo gil como o Scrum tem boas experincias com timos resultados. A equipe trabalha mais unida, a qualidade e o retrabalharam reduzem consideravelmente.

37

8. REFERNCIA BIBLIOGRFICA ALMEIDA, Felipe Rodrigues de. Criando um processo gil para desenvolvimento de software. Disponvel em: http://d.yimg.com/kq/groups/20097703/189506039/name/Como_criar_um_processo_a gil.pdf. Acesso em: 01 dez. 2009. BECK, Kent. Extreme programming explained: embrace change. Ed. Pearson, EUA, 2000. BECK, Kent. Test-Driven Development. The Addison-Wesley Signature Series, 2003. BECK, Kent. Test-Driven Development: by Example. The Addison-Wesley Signature Series, 2003. CLARIFICATION. Rugdy Scrum. Disponvel em: <http://clarification.files.wordpress.com/2007/09/Scrum.gif>. Acesso em: 01 dez. 2009. COHN, Mike. Succeeding with Agile: Software Development Using Scrum. The Addison-Wesley Signature Series, 2009. COHN, Mike. User Stories Applied: For Agile Software Development. The AddisonWesley Signature Series, 2004. CRISPIN, Lisa; GREGORY, Janet. Agile Testing: A Practical Guide for Testers and Agile Team. The Addison-Wesley Signature Series, 2009. DERBY, Esther; LARSEN, Diana; SCHWABER, Ken. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2006. DUONG, Luu. Functional Testing Tools. Disponvel em: http://luuduong.com/blog/. Acesso em: 01 out. 2009. FUSCO, Camila. Scrum, A Nova Gesto de Projetos, mar, 2008. Disponvel em: http://governanca.wordpress.com/2008/03/18/Scrum-a-nova-gestao-deprojetos. Acesso em 27/01/2009. GIRL WRITES CODE. Sprint Burndown. Disponvel em: <http://www.invisiblecity.com/sharon/uploaded_images/SampleBurndownChart.jpg>. Acesso em: 01 dez. 2009. GOMES, Handerson. Porque usar Scrum, Nov, 2008. Disponvel em: http://webinsider.uol.com.br/index.php/2008/11/06/porque-usar-Scrum/. Acesso em 27/01/2009. KNIBERG Henrik, Scrum and XP from the Trenches, Ed. C4Media, EUA, 2007. KNIBERG, Henrik. Scrum and XP from the Trenches: How we do Scrum. Enterprise Software Development Series, 2007.

38

KNIBERG, Hernik. Scrum e XP direto das trincheiras: Como ns fazemos Scrum. In: KNIBERG, Henrik. Scrum e XP direto das trincheiras. Eua: Infoq, 2008. p. 45. Metodologia de Desenvolvimento gil Scrum: O Caso XMPM. Manaus: Benq Mobile, 2006. p. 11 - 11. MORAES, Rodrigo da Silveira. Metodologia de Desenvolvimento gil de Software PRIOR David, Scrum Meets Waterfall, mar, 2008. http://www.Scrumalliance.org/articles/93-Scrum-meets-waterfall. 29/01/2009 Disponvel Acesso em: em

QUEZADA, Gustavo. Papel do Time de Teste em Projetos SCRUM. Disponvel em: http://gustavoquezada.blogspot.com/. Acesso em: 01 out. 2009. SATO, Danilo; GOLDMAN, Alfredo. Desenvolvimento de Software Lean: Curso de Vero 2007 - IME/USP. Disponvel em: <http://www.agilcoop.org.br/>. Acesso em: 01 out. 2009. SCHWABER, Ken; BEEDLE, Mike. Agile Software Development With Scrum, Ed. Adisson Wesley, EUA, 2001. SCRUM Abordagem Terica e Exemplos de Aplicao. 2008. Monografia de Ps Graduao em projeto e Desenvolvimento de Sistemas de Informao, UNIFIEO, Osasco, 2009. SCRUM TRAINING & AGILE TRAINING FROM SCRUMMASTER MIKE COHN. An Introduction to Scrum. Disponvel em: http://www.mountaingoatsoftware.com/system/asset/file/58/RedistributableIntroToScr um.ppt. Acesso em: 01 dez. 2009. SOMMERVILLE, Ian. Engenharia de Software, So Paulo: Ed. Pearson, 2007. SPARTA CONSULTORIA. Ciclo de Vida do Scrum. Disponvel em: <http://www.spartaconsultoria.com.br/home/index.php/video-aulas/5-ciclo-do-Scrum>. Acesso em: 01 dez. 2009. SPRINT PLANNING. Planning Poker Cards. Disponvel em: <http://www.sprintplanning.com/planningpoker_cards_1.gif>. Acesso em: 01 dez. 2009. SURAVARAPU, Srinivas, Implementing Scrum: 8 Questions to Answer Before You Begin, mar, 2008. Disponvel em: http://www.Scrumalliance.org/articles/99implementing-Scrum--questions-to-answer-before-you-begin. Acesso em 29/01/2009 TELES, Vincius Manhes. Extreme Programming: Aprenda como encantar seus usurios desenvolvendo software com agilidade e alta qualidade. So Paulo: Novatec, 2004. THAMIEL, Thiago. Ciclo de Vida do Scrum. Disponvel em: <http://thiagothamiel.files.wordpress.com/2009/07/Scrum.jpg>. Acesso em: 01 dez. 2009.

39

The Agile Alliance - Manifesto for Agile Software Development. Disponvel em: http://agilemanifesto.org/. Acesso em 21/11/2008 WATTS, Geoff, Production Support and Scrum, mar, 2008. Disponvel em: http://www.Scrumalliance.org/articles/91-production-support-and-Scrum. Acesso em 29/01/2009 Wells, Don. Extreme Programming: A Gentle Introdution, fev, 2006. Disponvel em: http://www.extremeprogramming.org/index.html. Acesso em: 17 out. 2009

40

9. ANEXO QUESTIONRIO BASE SOBRE A SUA EMPRESA: 1. Existe alguma restrio em revelar o nome da empresa? 2. Qual o porte da empresa? 3. Qual a linguagem de programao? 4. Qual o tipo de software desenvolvido? 5. Qual o seu cargo e formao?

SOBRE O SCRUM: 1. Quando o Scrum iniciou na sua empresa? 2. Qual a abrangncia do Scrum (quais departamentos)? 3. Qual o nvel de envolvimento da empresa na implantao do Scrum? 4. Qual o tamanho da equipe do Scrum? 5. Qual o papel do teste no Scrum implantado na sua empresa? 6. Quais os benefcios o Scrum trouxe para o teste? 7. O Scrum influenciou negativamente em algum aspecto? 8. J existe algum case de sucesso do Scrum na sua empresa?