UNIVERSIDADE ANHEMBI MORUMBI JEFFERSON GELAZIO DE QUEIROZ

MAURICIO PEREIRA LIMA RAFAEL DA COSTA ASSIS FERREIRA

São Paulo 2010

SCRUM PARA GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO EM PEQUENAS EMPRESAS DE TECNOLOGIA DA INFORMAÇÃO

JEFFERSON GELAZIO DE QUEIROZ MAURICIO PEREIRA LIMA

RAFAEL DA COSTA ASSIS FERREIRA

São Paulo 2010

SCRUM PARA GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO EM PEQUENAS EMPRESAS DE TECNOLOGIA DA INFORMAÇÃO

Trabalho apresentado como exigência parcial para a obtenção de titulo de Bacharel em Sistemas da Informação pela Universidade Anhembi Morumbi.

Orientador: Prof. Jorge Makoto Shintani

J

Q44 Queiroz, Jefferson Gelazio de

Scrum para gerenciamento de projetos de tecnologia

da informação em pequenas empresas de tecnologia da

informação / Jefferson Gelazio de Queiroz, Mauricio Pereira

Lima, Rafael da Costa Assis Ferreira. – 2010.

76f.: il.; 30cm.

Orientador: Jorge Makoto Shintani.

JEFFERSON GELAZIO DE QUEIROZ MAURICIO PEREIRA LIMA

RAFAEL DA COSTA ASSIS FERREIRA

São Paulo 2010

SCRUM PARA GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO EM PEQUENAS EMPRESAS DE TECNOLOGIA DA INFORMAÇÃO

Trabalho apresentado como exigência parcial para a obtenção de titulo de Bacharel em Sistemas da Informação pela Universidade Anhembi Morumbi.

Aprovado em

Prof. Universidade Anhembi Morumbi

Prof. Universidade Anhembi Morumbi

Prof. Universidade Anhembi Morumbi

AGRADECIMENTOS

Primeiramente, agradecemos a Deus, pela força e nos dar saúde para concluirmos essa etapa de nossas vidas. Aos nossos avos em especial Sra. Adelina, Sr. Vicente, avós do Rafael pelos esforços para o seu neto concluir os estudos. Aos nossos pais que jamais mediram esforços e sempre nos apoiaram e incentivaram para continuarmos nesta caminhada. Aos irmãos que nos auxiliaram financeiramente e com apoio psicológico. E também gostaríamos de agradecer as namoradas quem compartilharam o seu tempo e seu apoio para a conclusão deste trabalho. À todos os citados e amigos e outras pessoas que contribuíram para a conclusão de trabalho “Muito Obrigado” e também desculpas pela ausência e pela intolerância. Obrigado Jessica, por compartilhar o tempo do seu namorado conosco.

RESUMO

A qualidade dos projetos de pequenas empresas de Tecnologia da Informação (TI) foi estudada neste trabalho, visando criar uma melhor prática para o gerenciamento de projetos de TI para pequenas empresas de TI, com o principal objetivo de permitir uma concorrência leal entre pequenas empresas de TI e empresas de médio e grande porte do mesmo segmento. As pequenas empresas sofrem uma grande desvantagem em relação às empresas de médio e grande porte, pois realizam os seus projetos sem gerenciamento e sem o menor cumprimento de prazos, metas e sem registro dos documentos dos projetos. Com a adaptação do framework Scrum para utilização fora do contexto de desenvolvimento de software, será permitido um maior crescimento de forma organizada e documentada da empresa, com os processos de cada projeto bem definidos e de maneira prática e ágil. Pode-se concluir que a adaptação do framework Scrum traz benefícios ao gerenciamento de projetos de TI de pequena empresa de TI, organizando de maneira prática e simples sem a exigência de documentação e treinamento extensivo. Focado em pessoas a adaptação provou ser bastante flexível e adaptável.

Palavras-chave: Scrum.framework.pequena.empresa.TI

ABSTRACT

The quality of Information Technology’s (IT) small business projects were studied within this work, looking forward to create a best practice to managing IT’s projects for IT’s small business, with the main objective of allow a fair competition among an IT’s small business and midsize and large-sized business from the same segment. The small business suffer a great disadvantage in relation to the midsize and large-sized business, because they realize their projects without management and without the slightest compliance of schedules, goals and without record of the projects’ documents. With the adaptation of the Scrum framework to use it out of the context of software development, it will be allowed a higher growth in a organized and documented way of the business, with the processes of each project well defined in a practice and agile way. It can conclude that the Scrum framework adaptation brings benefits to the management of IT’s projects of IT’s small business, organizing in a practical and simple way without the requirement of extensive documentation and training. Focused on people, the adaptation proved to be pretty flexible and adaptable.

Key-words: Scrum.framework.small.business.IT

LISTA DE ILUSTRAÇÕES Figura 1: Fases do ciclo de vida de um projeto 18 Figura 2: Stakeholders de um projeto 20 Figura 3: Scrum incremental e iterativo 27 Figura 4: Scrum incremental e iterativo 28 Figura 5: Papéis e responsabilidades Scrum 31 Figura 6: Componentes que dão forma ao item de Backlog 37 Figura 7: Cartas de Planning Poker 39 Figura 8: Jogando Planning Poker 40 Figura 9: Exemplo de gráfico Burndown 42 Figura 10: Ciclo do Scrum na prática 44 Figura 11 Ciclo do Scrum em pequenas empresas de TI 52 Figura 12: Burndown do Projeto de Monitoramento 55

LISTA DE TABELAS

Tabela 1: Product Backlog – Projeto Monitoramento 54 Tabela 2: Product Backlog – Projeto mudança de sistema 59

LISTA DE SIGLAS

ACS Automação Comercial e Serviços ASD Adaptative Software Development

COBIT Control Objectives for Information and Related Technology

DSDM Dynamic Systems Development Method

FDD Feature Driven Development

ID Identificação ITIL Information Technology Infrastructure Library

IT Information Technology

PAF-ECF Programa Aplicativo Fiscal – Emissor de Cupom Fiscal PDV Ponto de Venda PMBOK Project Management Body of Knowledge

PO Product Owner

PMI Project Management Institute

RAD Rapid Application Development

ROI Return of Investiment

TI Tecnologia da Informação XP Extreme Programming

SUMÁRIO

11

1 INTRODUÇÃO

O mercado de Tecnologia da Informação (TI) cresce continuamente e grande parte

do seu crescimento se deve ao fato das empresas terem se estruturado nas raízes

de seus processos para produzirem com qualidade e quantidade superior. Nada

disso seria possível sem gerenciamento.

Existem diversas melhores práticas para gerenciamento de projetos, dentre elas, as

mais conhecidas são: PMBOK (Project Management Body of Knowledge),

ITIL(Information Technology Infrastructure Library), XP(Extreme Programming),

COBIT(Control Objectives for Information and Related Technology) e Scrum.

As empresas de médio e grande porte possuem recursos, tempo, dinheiro e é claro,

uma estrutura favorável ao custo/benefício de um gerenciamento de projetos com

vasta documentação como PMBOK e ITIL, ao contrário das pequenas empresas que

precisam de organização, mas não podem dispor grande esforço na documentação,

pois o seu time é reduzido e normalmente não tem disponibilidade para documentar

todos os processos.

É neste momento que entram os gerenciamentos de projetos ágeis e dentre eles

está o Scrum que será detalhado mais adiante. Será apresentada uma nova forma

de utilizar o Scrum para gerenciar projetos de TI em pequenas empresas e não

somente projetos de desenvolvimento de sistemas, mas também a aplicação de

Scrum para outros tipos de projetos no segmento de TI.

12

1.1 OBJETIVO

Este trabalho visa auxiliar as pequenas empresas de TI a gerenciarem seus os

projetos de TI, com máxima qualidade, menor custo e dentro do prazo planejado,

adequando os processos do Scrum, que foi desenvolvido para gerenciamento de

projetos de software.

1.2 ABRANGÊNCIA

Será usada como base de estudo somente o Scrum, este trabalho não fará

comparações com outros frameworks de mercado. Iremos apresentar um breve

resumo dos outros tipos de gerenciamento e dissertar nossa escolha pelo Scrum.

Para estudo de caso, serão analisados os projetos da pequena empresa de TI, a

ACS Automação Comercial antes e depois de serem gerenciados pelo Scrum.

1.3 JUSTIFICATIVA

Com o aumento da competitividade e a globalização, cada vez mais as empresas

precisam organizar-se e melhorar a qualidade de seus serviços ou aumentar sua

produção.

Estas empresas crescem de forma desorganizada e com serviços não gerenciados,

de modo que não possuem um cronograma em relação à implantação dos serviços

prestados e/ou entrega de produtos. Assim os seus clientes ficam sem uma previsão

da finalização de seus projetos, acompanhando o serviço conforme o que foi

combinado verbalmente no fechamento do negócio.

Este trabalho tem como principio ajudar estas empresas no gerenciamento de seus

projetos, melhorando assim o nível de qualidade de maneira prática e eficaz.

13

1.4 ESTRUTURA DO TRABALHO

No capitulo dois será apresentado os conceitos de Gerenciamento de Projetos que

descreverá o gerenciamento de projetos, seus fundamentos e o ciclo de

gerenciamento de projetos e as práticas desta área.

No capitulo três serão introduzidos os conceitos de metodologia, framework e o

gerenciamento ágil.

No capítulo quatro será apresentado o framework Scrum com abordagem sobre seu

tipo de gerenciamento, aplicações e vantagens.

No capitulo cinco será apresentado um estudo de empresa de TI sem nenhum

gerenciamento em seus projetos.

No capítulo seis será descrita e aplicada o framework Scrum com seus resultados

obtidos.

No capitulo sete serão apresentadas as conclusões com a pesquisa realizada, suas

vantagens, desvantagens e pontos críticos de utilizar o framework Scrum em

projetos de TI pequenas empresas de TI.

14

2 CONCEITOS DE GERENCIAMENTO DE PROJETOS

Neste capitulo será apresentado um embasamento teórico na gestão de projetos

com suas definições técnicas, suas características e fases do projeto. Com o foco de

orientar e melhorar os projetos de TI em pequenas empresas.

2.1 FUNDAMENTOS DE GESTÃO DE PROJETOS

Gerenciamento de projeto é uma arte, porque envolve gerenciamento de pessoas e

requer habilidades de intuição para ser aplicado em situações totalmente únicas

para cada projeto.

2.1.1 Definição de projeto

Definição de projeto segundo o autor:

Projeto é um empreendimento não repetitivo, caracterizado por uma seqüência clara e lógica de eventos, com inicio, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzidos por pessoas dentro de parâmetros de tempo, custo, recursos envolvidos e qualidade. (VARGAS, 2007, p.5)

Partindo desta definição de projeto, é compreendido que em quase todas as áreas

do conhecimento humano, pode-se encontrar um projeto desde a seqüência mais

rústica de trabalho ao mais sofisticado, desde que se enquadre dentro desta

definição.

15

2.1.2 Características de projeto

Embora todo projeto tenha suas particularidades e características próprias, os

projetos têm características em comum, como temporalidade, individualidade de

serviço ou do produto, resultados exclusivos, integração, escopo, tempo, custo,

qualidade, recursos humanos, comunicação e riscos.

Temporalidade não significa que o tempo para o projeto ser executado seja curto,

mas sim que o projeto deverá ter um início, meio e fim, e o fim está associado

diretamente ao objetivo do projeto, este somente chegará ao fim quando o projeto

alcançar o seu objetivo ou a equipe de stakeholders conclua que não mais existirá a

necessidade deste projeto ou seu objetivo não poderá ser alcançado.

Individualidade do serviço ou do produto produzido pelo projeto, característica na

qual define que cada projeto deverá ter entregas exclusivas e únicas, de forma que

cada entrega seja de forma crescente a fim de atingir o objetivo do projeto.

Resultados exclusivos: todo projeto sempre visa criar entregas exclusivas, estas

entregas podem ser: Produtos, serviços ou resultados. Estas entregas exclusivas

devem ser quantificáveis, um item final ou item componente.

Segundo o PMI (2004, p.10) cada projeto tem nove áreas de conhecimento:

1. Gerenciamento de integração: Descreve os processos e as atividades que

integram os diversos elementos do gerenciamento de projeto;

2. Gerenciamento do escopo: Descreve os processos envolvidos na verificação de

que o projeto inclui todo o trabalho necessário, e apenas o trabalho necessário, para

que seja concluído com sucesso;

16

3. Gerenciamento de tempo: Descreve os processos relativos ao término do

projeto no prazo correto. Definição de atividades, seqüência de atividades,

estimativa de recursos da atividade, estimativa de duração da atividade,

desenvolvimento do cronograma e controle do cronograma;

4. Gerenciamento de custos: Descreve os processos envolvidos em planejamento,

estimativa, orçamento e controle de custos, de modo que o projeto termine dentro do

orçamento aprovado;

5. Gerenciamento da qualidade: Descreve os processos envolvidos na garantia de

que o projeto irá satisfazer os objetivos para os quais foi realizado;

6. Gerenciamento de recursos humano: Descreve os processos que organizam e

gerenciam a equipe do projeto. Planejamento de recursos humanos, contratar ou

mobilizar a equipe do projeto;

7. Gerenciamento das comunicações: Descreve os processos relativos à geração,

coleta, disseminação, armazenamento e destinação das informações do projeto de

forma oportuna e adequada;

8. Gerenciamento de riscos: Descreve os processos relativos à realização do

gerenciamento de riscos em um projeto. Planejamento do gerenciamento de riscos,

identificação de riscos, analise qualitativa de riscos, análise quantitativa de riscos,

planejamento de respostas a riscos e monitoramento e controle de risco;

9. Gerenciamento de aquisições: Descreve os processos que compram ou

adquirem produtos, serviços ou resultados, alem dos processos de gerenciamento

de contratos. Ele consiste nos processos de gerenciamento de projetos: Planejar

compras e aquisições, planejar contratações, solicitar respostas de fornecedores,

selecionar fornecedores, administração de contrato e encerramento de contrato.

17

2.1.3 Gerenciamento de projeto

“Gerenciamento de projetos é a aplicação de conhecimento, habilidades,

ferramentas e técnicas às atividades do projeto a fim de atender aos seus

requisitos.” (PMI, 2004, p.37) Esta técnica é aplicada em cada uma das cinco áreas

dos processos de gerenciamento de projetos; iniciação, planejamento, execução,

monitoramento/controle e finalização, estas áreas estão relacionadas entrei si e se

aplicam de forma crescente com o desenvolvimento e andamento do projeto.

2.1.4 Benefícios do gerenciamento de projeto

Segundo Vargas (2003), o gerenciamento de projetos agrega diversos benefícios

para o projeto, dentre estes se destacam: melhoria no controle do projeto, aumento

no desempenho do projeto, redução do tempo, redução de riscos e melhor qualidade

dos projetos. O gerente do projeto aplicará suas técnicas e habilidades para manter-

se dentro do escopo, com o tempo compatível com o cronograma inicial.

Com o acompanhamento do gerenciamento de projetos, podem-se evitar surpresas

durante diversas fases do ciclo de vida de projeto, que possibilita desenvolver

vantagens estratégicas com relação aos concorrentes, pois os projetos gerenciados

que acompanham uma metodologia e uma estrutura definida, possuem uma

previsão de gastos, baseado em históricos, maior otimização, alocação de recursos

humanos e não humanos, além da maior agilidade na tomada de decisão.

18

2.2 FASES DO CICLO DE VIDA DE UM PROJETO

Os projetos são compostos por fases que dependem da natureza do projeto, mas

genericamente pode-se dividir um projeto em cinco fases: iniciação, planejamento,

execução, controle e finalização. Estas fases são seqüenciais e dependentes uma

da outra. As fases não necessariamente contam com os esforços dos seus times ao

máximo, pois o esforço do projeto segue uma curva, que atingirá seu máximo

durante a fase de execução, fase na qual todos os esforços estão concentrados para

atingir o objetivo do projeto. Na figura 1 a ilustração apresenta onde está

concentrado o maior esforço do projeto.

Figura 1 Fases do ciclo de vida de um projeto (VARGAS, 2003, p.38)

Fase de Iniciação. Está é a primeira fase de projeto, nela identifica-se a

necessidade ou falha que o projeto deve suprir quando o objetivo for alcançado.

19

Fase de Planejamento. Nesta fase é feito o detalhamento de projeto, no qual será

definido o objetivo, escopo, cronograma e envolvidos no projeto.

Fase de Execução. Nesta fase é colocado em prática tudo o que foi definido na

Iniciação e Planejamento. Nesta etapa qualquer erro feito nas duas primeiras fases

fica muito mais claro.

Fase de Controle. Nesta fase analisa-se o andamento do projeto e a mesma

acontece em paralelo entre Iniciação e Finalização. Seu objetivo é acompanhar,

corrigir e controlar tudo que está sendo feito no projeto.

Fase de Finalização. Na última fase são finalizadas formalmente as atividades do

projeto ou de uma fase. Nesta fase deve-se entregar o produto ou serviço final.

Dividindo os projetos em fase se tem benefícios no gerenciamento de seu projeto,

independente do seu tipo. Com o ciclo de vida de um projeto se consegue ter uma

melhor análise do quanto o projeto avançou, o quanto se distanciou do escopo e

analisar o ponto real em que se encontra o projeto, dentre suas diversas etapas e

fases. O principal item a ser analisado na vida de um projeto é o esforço.

Entende-se como esforço, todos os recursos alocados ao projeto, como pessoas,

equipamentos, dinheiro, complicações e horas adicionais.

20

2.3 ENVOLVIDOS NO PROJETO

Todo e qualquer projeto tem um grupo de elementos denominados de Stakeholders

ou envolvidos no projeto, este grupo pode ser formado por pessoa e organizações.

Este grupo deve ter seus interesses afetados pelo projeto de forma positiva ou

negativa. Sendo assim em um projeto de automação comercial pode-se destacar

seus Stakeholders como: o contratante, a empresa contratada, os funcionários da

empresa contratada, os funcionários da empresa contratante, os clientes da

contratante, clientes da contratada. Mesmo quando estão em um mesmo grupo, seja

ele financiando o projeto ou executando, sempre existem envolvidos no projeto

divergindo entre si. A figura 2 mostra os diversos Stakeholders de um projeto.

Figura 2 Stakeholders de um projeto (PMI, 2004, p.25)

21

3 METODOLOGIA

Metodologia é um conjunto de regras definidas que determinam como os processos

serão empregados em determinadas práticas. Esses processos são específicos para

uma tarefa ou função. De acordo com Tomhave (2005, p.9, tradução nossa) a

definição de metodologia é:

“Uma metodologia é uma construção focada que define regras, práticas e

procedimentos específicos para implementação ou execução de uma função ou

tarefa específica.”

Pode-se exemplificar a metodologia na maneira como uma empresa estipula seu

horário de trabalho.

A maioria das pizzarias costumam abrir às 18:00h e fecham às 23:00h, mas o senso

comum estabelece como horário comercial o período entre às 08:00h até 18:00h,

mas no caso das pizzarias não haveria o por que de abrir seu estabelecimento às

09:00h da manhã. Não faz parte dos costumes brasileiros comer pizza no café da

manhã e por isso não há demanda para que as pizzarias abram no período

matutino, tampouco no vespertino.

Isso demonstra que cada empresa trabalha de seu jeito, fica a cargo dos tomadores

de decisão avaliar o que é melhor para a empresa e partindo de fatos e convicções

criam-se processos de uma determinada metodologia de trabalho.

Esta metodologia vai definir o horário de trabalho, definirá que o controle de horário

dos funcionários será por leitura biométrica ou por folha de ponto.

Dentro da metodologia, existem os métodos que são distintos em seus significados.

O método é criado através da intuição, do saber e da experimentação e faz parte do

processo de aprendizagem sem que o indivíduo possua alguma informação prévia

ao problema, cabe a metodologia reunir os métodos e estudá-los, transformando-os

em uma abordagem prática para solucionar problemas relacionados.

22

3.1 MANIFESTO ÁGIL

Com o aumento da concorrência e a busca de melhorias entre os serviços e

produtos, foram ficando cada vez mais comuns as metodologias e métodos de

gerenciamento de projetos. Todas elas com as mesmas características: muitos

processos, muita burocracia e pouca praticidade.

No ano de 2001 em um encontro com 17 desenvolvedores nos Estados Unidos da

América, nasceu o “Manifesto para o Desenvolvimento Ágil de Software”. Este

manifesto teve como premisse a seguinte frase “Estamos descobrindo maneiras

melhores de desenvolver software fazendo-o nós ou até mesmo ajudando outros a

fazê-lo”. (SCHWABER et al. 2001, tradução nossa)

Nasciam então os doze princípios do Manifesto Ágil.

1. Nossa maior prioridade é satisfazer o cliente, através da entrega

adiantada e contínua de software de valor;

2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento.

Processos ágeis se adéquam a mudanças, para que o cliente possa

tirar vantagens competitivas;

3. Entregar software funcionando com freqüência, na escala de semanas

até meses, com preferência aos períodos mais curtos;

4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar

em conjunto e diariamente, durante todo o curso do projeto;

5. Construir projetos ao redor de indivíduos motivados. Dando a eles o

ambiente e suporte necessário, e confiar que farão seu trabalho;

6. O Método mais eficiente e eficaz de transmitir informações para, e por

dentro de um time de desenvolvimento, é através de uma conversa cara

a cara;

7. Software funcional é a medida primária de progresso;

8. Processos ágeis promovem um ambiente sustentável. Os

5patrocinadores, desenvolvedores e usuários, devem ser capazes de

manter indefinidamente, passos constantes;

9. Contínua atenção à excelência técnica e bom design, aumenta a

agilidade;

10. Simplicidade: a arte de maximizar a quantidade de trabalho que não

precisou ser feito;

23

11. As melhores arquiteturas, requisitos e designs emergem de times auto-

organizáveis;

12. Em intervalos regulares, o time reflete em como ficar mais efetivo,

então, se ajustam e otimizam seu comportamento de acordo.

(SCHWABER et al. 2001, tradução nossa)

Com um estudo sobre estes princípios do Manifesto Ágil, definiu-se que ser ágil é

colocar em prática os princípios do manifesto, a fim de aproximar cada vez mais os

clientes e time das pessoas, pois assim evita-se tempo perdido e mau entendimento

que poderia haver com quaisquer meio de comunicação.

3.1.1 Metodologia Ágil

Metodologia Ágil é uma denominação para metodologias que são “leves” na

documentação de seus processos e que focam os princípios do Manifesto Ágil.

Existem diversas metodologias quem empregam a definição do “ser ágil”.

(SCHWABER, 2004; SILVA, p.21, 2009)

As metodologias mais conhecidas segundo Silva (2009) e UNB (2004) são:

Adaptive Software Development (ASD) ou Desenvolvimento de Programa

Adaptável

Principais características estão em ser iterativo e incremental, usado para sistemas

grandes e complexos, cliente sempre presente para acompanhar o andamento do

projeto. Dividido em três fases. Especular, Colaborar e Aprender. (HIGHSMITH,

1999)

Dynamic Systems Development Method (DSDM) ou Método Dinâmico de

Desenvolvimento de Sistemas

Utilizado para RAD (Rapid Application Development). Mantém fixo o tempo e

recurso, ajustando apenas as funcionalidades do sistema. Aplicado em pequenas

24

equipes e aceitam mudanças de requisitos durante o ciclo de vida do projeto.

Dividido em cinco fases: Estudo das Possibilidades, Estudo dos Negócios, Iteração

do Modelo Funcional, Iteração de Projeto e Construção e Implementação Final.

(CONSORTIUM, 2010)

Crystal/Clear

Esta metodologia faz parte de um conjunto, criada por Cockburn (2001) direcionada

para projetos pequenos onde cada membro da equipe tem suas especialidades

distintas, não oferece suporta à documentação e tem forte embasamento na

comunicação.

Feature Driven Development (FDD)

Metodologia ágil e adaptável tem o seu foco nas fases de desenho do projeto,

trabalhos com desenvolvimento iterativo. Possui cinco processos principais:

Desenvolver modelo compreensível, Construir uma lista de funcionalidades,

Planejar por funcionalidades, Projetar por funcionalidades, Construir por

funcionalidades. (LUCA, 2010)

Lean

Metodologia baseado no Lean Manufacturing, quem tem como premissa evitar o

desperdício. Está metodologia de gerenciamento de software visa concluir o

desenvolvimento na primeira versão, pois evitando refazer o trabalho terá economia

de recursos humanos e financeiro. (POPPENDIECK, 2003)

Extreme Programming (XP)

A metodologia XP é formado com base nos princípios ágeis que nasceram no

Manifesto Ágil, esta metodologia tem como valor, comunicação, feedback, respeito e

simplicidade. O XP organiza os ciclos de iteração em períodos curtos, com a

presença dos usuários assim possibilitando assim os usuários a se familiarizar e

testar o software. (BECK, 2004)

25

3.2 DEFINIÇÃO DE FRAMEWORK

O termo metodologia é empregado comumente com uma definição que não traduz

exatamente como algumas chamadas “metodologias” controlam seus processos.

Um bom exemplo disso é o Scrum que é amplamente difundido como metodologia

ágil, mas segundo o livro Agile Project Management with Scrum (2004), o seu

modelo de gerenciamento é um framework ou melhores práticas.

O termo framework tem diversas traduções, mas todas elas levam ao significado de

modelo genérico de alto nível, que nos permite a construção de uma metodologia,

baseado em processos e conceitos definidos. Essa metodologia criada a partir do

framework tem um maior embasamento teórico, pois conta com modelo estruturado

e detalhes que devem serem seguidos.

O framework pode ilustrar e guiar um projeto ao seu sucesso, mas como será feito

isso depende dos responsáveis pelo projeto ao contrário da metodologia que diz

como será feito e proporciona ferramentas prontas para serem usadas, não apenas

um modelo.

O benefício do framework é a capacidade de adaptação, já que seu mecanismo de

gerenciamento não é focado para uma tarefa ou função específica.

Por definição framework é: “uma construção fundamentada que define suposições,

conceitos, valores, práticas e que incluí um guia para ser implementado sozinho.”

(TOMHAVE, 2005, p.9, tradução nossa)

26

4 SCRUM

O Scrum destaca-se tanto pela maneira como emprega seus processos, como pela

praticidade em aplicação de seu framework em processos bastante complexos.

Os processos complexos podem ser empíricos ou definidos (SCHWABER, 2004,

p.2) e para cada um deles existe uma abordagem de gerenciamento:

Controle de Processo Definido, ou seja, um projeto aonde possuí detalhado e

especificado todas as particularidades de seus processos e não existe margem para

o desconhecido. Pode-se exemplificar em uma viagem de avião, aonde o piloto sabe

aonde deve chegar e como deve chegar, a rota está traçada e não existem

alternativas. Tudo é planejado e previsto: duração de vôo, hora de chegada, latitude

do avião e condição climática. Tais processos permitem um grau de imprecisão,

mesmo que pequeno, mas esta possibilidade é somente viável pelo nível de

informação existente sobre aquele fato. Apesar desse processo ser complexo, ele é

repetitivo e mesmo havendo mudanças climáticas ou atraso no vôo, o roteiro da

viagem pouco muda e o planejamento inicial pode ser mantido.

Mas o que aconteceria se fosse preciso controlar um processo complexo, aonde a

maioria das variáveis fossem desconhecidas e o menor erro tivesse grande

conseqüência, como em um desenvolvimento de software. Esta situação é definida

como:

Controle de Processo Empírico, que permite o controle de processos complexos e

imprevisíveis, sendo necessário analisar e reavaliar os processos no decorrer do

projeto.

Pode-se exemplificar o Controle de Processo Empírico em uma viagem de carro:

27

O motorista precisa percorrer o percurso do ponto A ao ponto B, mas dependendo

do conhecimento, do trânsito, do pedágio e de outras variáveis impossíveis de se

descobrir antes de começar a viagem, o motorista pode percorrer um caminho ou

outro. Ele vai tomar suas decisões durante a viagem. Não existe uma rota traçada,

como ocorre em um avião.

Além de ser um Controle de Processo Empírico, o Scrum é um framework ágil,

iterativo e incremental que se refaz em ciclos de realimentação, buscando organizar

e aprimorar o mecanismo de trabalho e de seus usuários como é possível observar

na figura 3 e na figura 4.

Figura 3 Scrum incremental e iterativo (PATTON, 2008)

28

Figura 4 Scrum incremental e iterativo (PATTON, 2008)

Os idealizadores do Scrum preferem destacar que o Scrum é um framework e não

uma metodologia. O Scrum não vai resolver seus problemas, vai ajudar a identificá-

los e também não gerencia processos e sim pessoas.

4.1 CARACTERÍSTICAS DO SCRUM

O Scrum possuí diversas características, a principal delas é sua maneira iterativa e

incremental de desenvolvimento. A explicação de iterativo e incremental pode-se

relacionar com a compra de uma casa:

O cliente compra uma casa que está começando a ser construída. Ao invés de

esperar a casa ser construída inteira, o cliente pode mudar-se, assim que a sala

29

estiver pronta. Nela haveria tudo, luz, água encanada e mobília, os outros cômodos

continuariam sendo construídos e o cliente poderia escolher ou não se construiria

aquele cômodo de visitas ou não caso acreditasse não ser mais necessário. O

projeto seria imaginado como um todo desde o começo, mas a cada fim de ciclo,

seria entregue algo de valor e esta entrega estaria totalmente pronta para uso.

(SCHWABER, 2004)

O Scrum também possuí seus papéis e responsabilidades bem definidos, seus

ciclos curtos para entrega rápida de produto com valor agregado permitem ao cliente

avaliar o retorno de investimento, reuniões diárias de 15 minutos e reuniões ao final

de cada ciclo servem para revisar ou inspecionar o desenvolvimento do projeto.

(WOODWARD, 2010)

Assim como em todos os projetos, no Scrum também existe uma lista de requisitos,

nomeado de Product Backlog. Cada nova funcionalidade possuí um cartão que

descreve brevemente seu objetivo e contém elementos chave para sua fácil

identificação. Este cartão é uma ferramenta que o Scrum utiliza para auxiliar no

desenvolvimento do projeto.

Resumo de algumas características:

Vision: É a idéia que o cliente tem do projeto pronto, é aquilo que vai corresponder

sua necessidade ou trazer algum benefício, o retorno de investimento;

Product Backlog: É a lista de requisitos do projeto. Os requisitos ou itens de

Backlog são alinhados pelo cliente e através de uma reunião só com a equipe, é

definido como será entregue algo de valor até o fim do ciclo;

Sprint Planning: É a primeira reunião do Scrum e nesta reunião é realizado o

planejamento inicial de como será o primeiro ciclo de trabalho, define-se junto com o

cliente o que precisa ser feito, quais são as prioridades, visando entregar após um

ciclo curto de período um produto de valor agregado;

30

Sprint: É o ciclo de trabalho do Scrum, existem várias Sprints dentro de um projeto

Scrum e tudo que for planejado ou revisado nas reuniões é feito pela equipe. Cada

Sprint possui seu objetivo e a equipe não deve fazer nada não relacionado à Sprint,

para alterar ou acrescentar novas tarefas, no Scrum conhecidos como itens de

Backlog, é obrigatório esperar o fim da Sprint;

Burndown: Gráfico que demonstra o tempo estimado e decorrido de acordo com as

os itens de Backlog planejados para aquela Sprint. Pode-se criar também um

Burndown para medir a produtividade da equipe;

Time-box: Time-box é um conceito que estabelece o tempo fixo, a “caixa de tempo”

em tradução livre. O Scrum como framework permite flexibilidade em seus

mecanismos, a melhor prática pode recomendar que uma reunião dure quatro horas

e que um ciclo de trabalho dure trinta dias consecutivos, mas cabe ao responsável

pelo projeto escolher início, término e regularidade de cada ciclo, reunião ou prazo

de entrega. Uma vez escolhido e definido este tempo, ele deve ser mantido e

respeitado tal qual pode-se adicionar ou retirar tarefas, mas o período de tempo não

deve ser alterado e com isso o Scrum ensina a importância em cumprir prazos e

entregas regulares.

4.1.1 Vantagens do Scrum

O Scrum como framework possuí algumas vantagens em relação aos métodos de

gerenciamento tradicionais:

Controle de Processo Empírico

É possível descobrir variáveis desconhecidas no decorrer do projeto, tais variáveis

eram impossíveis de serem previstas ou conhecidas no início devido à fatores que

regem os processos complexos.

31

Mecanismo

O mecanismo, as ferramentas e os papéis do Scrum são simples, não é necessário

gráficos e tabelas complexos para descrever os processos, os papéis dos envolvidos

são fáceis de entender tecnicamente, basta apenas uma pessoa com conhecimento

suficiente para agregar os valores do Scrum aos envolvidos. Suas práticas são

flexíveis e adaptáveis.

Comunicação

O foco são as pessoas e seu objetivo e ajudar na comunicação entre e equipe e

cliente, permitindo que a equipe trabalhe sem interferência e ao mesmo tempo

possibilitar a satisfação do cliente através de encontros em pessoa.

4.1.2 Papéis e responsabilidades

O Scrum define que os papéis sejam bem claros e distintos. Cada papel tem sua

função e dificilmente os poderes podem ser impostos aos outros envolvidos.

A figura 5 ilustra os Stakeholders em um projeto Scrum.

Figura 5 Papéis e responsabilidades Scrum (SANTOS, 2009, p.14)

32

Product Owner

É geralmente representado pelo cliente. O Product Owner estará sempre alinhado

com o valor agregado do produto, retorno de investimento (ROI) e é responsável

pela visão do negócio e por gerenciar conflitos de interesse do cliente.

Cabe a ele estabelecer quais serão os itens a serem entregues em cada ciclo, qual

prioridade terá cada item e atribuirá aos itens valores de negócio para cada

funcionalidade, estabelece as datas de entrega e conteúdo de cada item. Os outros

envolvidos no projeto podem sugerir itens a serem entregues, mas só o Product

Owner pode atribuir sua prioridade e/ou grau de importância. Possuí também a

responsabilidade de aprovar ou desaprovar o resultado das entregas e é

responsável em garantir a qualidade do produto.

É importante evitar a síndrome do PO Virtual (Product Owner) que acontece quando

não se sabe quem deve ser o Product Owner: se ele deve ser o cliente, se deve ser

alguém interno da empresa ou externo da empresa por ter uma melhor visão do

negócio, uma visão macro do projeto; quando ele não é levado à sério pela equipe

ou não consegue atribuir um valor de negócio a funcionalidade.

Vale lembrar-se da importância de ter um Product Owner com treinamento Scrum

para assumir seu papel e entender como o framework funciona.

Scrum Master (mestre Scrum)

Outro papel muito importante no Scrum é o Scrum Master que geralmente é

representado por alguém com grande experiência em Scrum, para assim aplicar os

valores e práticas Scrum, cabe ao Scrum Master resolver todos os assuntos

externos ao projeto. É ele quem contorna situações adversas como: funcionários

doentes, atraso na entrega e/ou desentendimentos na equipe. Não é o Scrum

Master quem decide como as tarefas serão entregues ou feitas, isso é papel da

equipe e o Scrum Master não pode interferir. É obrigação dele garantir a

produtividade da equipe e colaboração entre os diversos papéis e funções.

É ele quem conduz as reuniões diárias como mediador. Existem casos em que o

Scrum Master trabalha junto a equipe, mas depende muito da necessidade do

projeto, ele pode sim executar tarefas simples que não tomem muito de seu tempo

33

contanto que haja disponibilidade para resolver impedimentos da equipe. Não é

necessário ser o líder técnico ou gerente.

Apenas em casos atípicos é que o Scrum Master pode interferir na tomada de

decisões.

Equipe Scrum

O terceiro papel do Scrum é a equipe, composta de maneira heterogenia, a fim de

suprir as mais diversas necessidades do projeto (programadores, designers,

testadores e todas as pessoas envolvidas no projeto) contando em média com 5 a

10 pessoas. Sendo esta quantidade ideal de trabalho, podendo haver mais ou

menos pessoas na equipe. A equipe é auto-gerenciável e auto-organizável. É

responsabilidade da equipe levantar seus impedimentos externos.

Por exemplo: Não possuímos máquina capaz de realizar testes de validação do

sistema X. A equipe não é dependente do Scrum Master para resolver assuntos

internos como uma entrega do designer para que o desenvolvedor comece a

trabalhar. Isso é papel da equipe e por isso é denominada auto-gerenciável e auto-

organizável.

É muito comum as pessoas que desconhecem o Scrum não entenderem como uma

equipe pode trabalhar sem ter um gerente ou alguma pessoa dizendo o que a

equipe tem que fazer, porém se seguem os processos do Scrum a equipe

naturalmente se auto-gerencia e se auto-organiza.

O retorno das pessoas que trabalham com Scrum é muito bom, pois o Scrum

permite autonomia de trabalho e confiança, ao mesmo tempo que supre a

necessidade de foco dos envolvidos no projeto.

Um Product Owner não pode ditar como a equipe trabalhará, mas pode ditar quais

serão os itens a serem entregues. Em 99% dos casos existem apenas um Product

Owner e um Scrum Master. (FRIED, 2010)

34

4.1.3 Sprint

O Sprint é a execução do projeto que geralmente dura entre uma a duas semanas

de acordo com a data que o Scrum Master definir.

Na reunião de planejamento da Sprint são selecionados os itens de maior prioridade

de acordo com o que a equipe conseguirá executar durante aquela Sprint.

O objetivo da Sprint pode ser definido em um parágrafo, abordando o que vai ser

entregue ao final desta Sprint para o Product Owner. O objetivo deste é definido

entre a equipe e o Product Owner.

A equipe seleciona cada funcionalidade e separa em tarefas que se tornam a lista de

requisitos, (Product Backlog) definindo como deve ser estimado o prazo de entrega

de cada tarefa, podendo ser em dias ou em horas. No Brasil é muito comum

dimensionar tarefas em dias. (CAVALCANTI, 2008)

É definida uma tarefa para cada membro da equipe ou cada envolvido. O curso do

Scrum oficial sugere que cada membro da equipe escolha a tarefa a ser realizada.

De acordo com sua função na equipe, o desenvolvedor faz tarefas de

desenvolvedores e designer realiza tarefas de design. O método de alocar um

membro da equipe a cada tarefa é importante, pois toda a equipe passa a conhecer

melhor todas as funcionalidades do sistema, porém quando um membro escolhe sua

tarefa, ele foca maior tempo nessa funcionalidade e desempenha melhor seu papel

de acordo com seu conhecimento, assim podem realizar um trabalho mais rápido e

eficaz.

4.1.4 Definindo o tamanho do Sprint

Um dos tópicos do planejamento do Sprint é o tamanho do Sprint. Sempre fica a

questão de qual seria o melhor tamanho para o Sprint.

No Scrum não tem nenhuma regra para definir o tamanho do Sprint, é de

responsabilidade de cada equipe de Scrum.

35

Existem os Sprints curtos e os longos e de acordo com relatos de equipes Scrum,

Product Owners gostam de Sprints curtos e os desenvolvedores longos. O tamanho

da Sprint representa em linhas gerais uma data de entrega do compromisso

assumido.

Sprint curtos tem seus aspectos favoráveis que possibilitam à a equipe ser mais ágil,

realize entregas mais rápidas, tenha uma resposta mais rápida para o cliente e não

perca tempo no caminho errado, assim aprendem com os erros mais rapidamente.

Sprint longos possibilitam que a equipe tenha tempo para ganhar ritmo de trabalho,

para se recuperar de problemas durante o Sprint e conseguir chegar ao objetivo da

Sprint na data combinada. Economiza-se tempo com o desenvolvimento ao invés de

se preparar para apresentar o Sprint e o tempo que leva cada reunião de Sprint.

Cabe a equipe fazer testes nos primeiros Sprints até fixar um tamanho para cada

Sprint, este tamanho deve ser mantido, pois assim evita discussões e perca de

tempo planejando o tamanho do Sprint e a equipe já tem em mente a data para

entrega. (SANTOS, 2009)

4.1.5 Daily Scrum

O Daily Scrum é uma reunião pré-definida no planejamento da Sprint que consiste basicamente em um encontro que demonstre o compromisso dos envolvidos no projeto e os eventuais problemas externos que os mesmos estejam enfrentando. Todos são convidados a participar da reunião, porém só a equipe, o Scrum Master e o Product Owner podem falar.

Sua duração, horário e local são firmados no planejamento da Sprint.

O ideal é que o Daily Scrum seja realizado no primeiro horário da manhã, em comum

acordo com todos para não haver ausências. Pode-se realizar Daily Scrums pela

tarde, mas não é prático ter que trabalhar e lembrar o que falou que ia fazer ontem.

O mais importante é o que fará e não o que fez.

O Daily Scrum não serve para resolver problemas. Ele evita reuniões

desnecessárias e se baseia em três perguntas feitas a cada um dos envolvidos no

projeto:

36

• O que você fez ontem?

• O que você fará hoje?

• Algo te impede de concluir sua tarefa?

O Daily Scrum é sempre realizado em pé, assim a reunião dificilmente se estenderá,

evitando o desgaste mental. Sua duração média deve ser de 15 minutos.

(SCHWABER, 2004)

4.2 PRODUCT BACKLOG

O Product Backlog é a lista de requisitos do projeto, ele compõe os requisitos

necessários para a conclusão do projeto e são previstos pelo Product Owner. No

Scrum os requisitos são descritos pelo termo “itens de Backlog”.

O Product Backlog deve traduzir a visão do projeto de termos de mercado para

termos técnicos e possuí a característica de mudar constantemente e através de seu

processo empírico do Scrum, sua lista de requisitos é alimentada antes do início de

cada Sprint. É obrigação do Product Owner priorizar os itens de maior valor à serem

entregues no final de cada Sprint. A equipe pode incluir itens e ajudar a estimar o

tempo de entrega dos mesmos.

Podem ser feitos cartões descrevendo cada item de Backlog como na figura 6.

37

Figura 6: Componentes que dão forma ao item de Backlog (AUTORES, 2010)

Cada item de Backlog pode possuir os seguintes campos:

ID (identificação): é um número. Sua identificação é importante para o controle de

cada item, pois a mesma pode sofrer alteração de descrição.

Nome: é um descritivo. Um nome curto de aproximadamente 2 a 10 palavras. Deve

ser simples e claro para que os desenvolvedores e o Product Owner entendam do

que se trata e o diferencie dos outros itens.

Importância: É a importância do item para o Product Owner, atribuída através de

pontuação. Exemplo: 15 ou 120 o valor mais alto é o mais importante.

É utilizada a pontuação com grandes intervalos, pois se surgir um item com maior

importância ou que sua importância tenha sido subestimada a principio, pode-se

reorganizar os itens sem utilizar pontuações com mais de uma casa decimal.

38

Estimativa Inicial: São as estimativas da equipe sobre o tempo necessário para

implementar aquele item comparados aos outros itens realizadas anteriormente. A

unidade de medida é em pontos por item de Backlog e corresponde a homens/dias.

Exemplo: perguntar a equipe com três homens quanto tempo levará para

desenvolver um item. Se a resposta for quatro dias. Temos um item de 12 pontos. O

importante não é ter estimativas 100% exatas e sim estimativas coerentes entre si

como, por exemplo, um item de quatro pontos vai levar metade do tempo de um item

de Backlog com oito pontos.

Como Demonstrar: uma explicação de como será demonstrado o item na

apresentação do Sprint. Fazer esta operação e verificar se a mesma foi alterada.

Exemplo: entrar na configuração de produtos, alterar o valor do produto, verificar no

relatório de produtos se o valor foi alterado.

Nota: Qualquer outra informação, que faça referência a outra fonte de informação.

Que seja breve e ágil.

Não necessariamente é obrigatório que seu Product Backlog tenha somente esses

itens, podem ser adicionados mais itens de acordo com a necessidade de sua

equipe.

O dono do produto é o Product Owner, porém o ideal é manter esses dados em

arquivo e que seja disponibilizado em uma área compartilhada para que todos da

equipe tenham acesso para consulta ou até mesmo para alterações, como por

exemplo, alterações de estimativas dos itens de Backlog.

4.2.1 Planning Poker

O Planning Poker foi criado por James Grenning em 2002 para ajudar os

desenvolvedores com as estimativas de cada atividade necessária para um projeto.

Perdia-se muito tempo estimando, já que os envolvidos possuem habilidades,

conhecimento e antepassados diferentes. Apesar de não ser um artefato próprio do

39

Scrum, ele pode ser aplicado em diversos gerenciamentos ágeis, como o Scrum e o

XP.

O autor de Scrum Experience: O Tutorial Scrum (SANTOS, 2009) é um dos gestores

brasileiros que escolheram o Scrum para gerenciar seus projetos de

desenvolvimento de software e utiliza o Planning Poker como facilitador para estimar

a entrega dos itens de Backlog.

O mecanismo deste artefato é simples, ele é baseado no jogo de cartas Poker e

utiliza estimativas pré-definidas, debates e em alguns casos até mesmo uma

ampulheta de areia para tornar o processo ainda mais ágil (COHN, 2005, p.58).

Figura 7 Cartas de Planning Poker (CRISP, 2002)

Como pode-se observar na figura 7, o Planning Poker possuí cartas com números

que representam estimativas, estes números são seqüências e pertencem uma

ordem de grandeza, segundo alguns estudos (Miranda 2001; Saaty 1996), possuir

uma ordem de grandeza definida ajuda muito as estimativas. Na maioria dos designs

40

de Planning Poker, a ordem de grandeza utilizada é a seqüência Fibonacci. Existe

toda uma análise profunda sobre o efeito da ordem de grandeza na qualidade das

estimativas, mas este tema não será abordado neste trabalho (COHN, 2005).

Uma carta simbolizada pela interrogação expressa a falta de conhecimento por parte

do indivíduo que está tentando estimar um item. A carta simbolizando um café não é

encontrado em todos os designs de Planning Poker, mas significa uma pausa no

“jogo” de estimativas.

Deve-se usar o Planning Poker com o propósito de motivação e como auxílio para

que até mesmo os indivíduos mais quietos possam participar das estimativas. Em

outros mecanismos de planejamento, é difícil conseguir a participação de todos e

com jeito de jogo, a equipe torna-se mais produtiva.

Observa-se na figura 8 o nível de participação de cada um:

Figura 8 Jogando Planning Poker (SANTOS, 2009, p.18)

O Product Owner como mediador descreve um item de Backlog para a equipe

Scrum e cada um deles imagina um número com a estimativa de tempo para

entrega daquele item. Assim que todos estiverem prontos, as cartas são viradas

41

demonstrando o pensamento de cada um. Então se analisa o pensamento dos

indivíduos com a maior e menor estimativa através de um debate. O objetivo do

debate não é confrontar opiniões e sim esclarecer pontos de vista. A idéia é estimar,

não se deve perder muito tempo estimando cada item. Caso a equipe não entre em

consenso, aquele item pode ser estimada em outra oportunidade, pode ser dividida

em dois itens de Backlog ou é aceita a menor estimativa.

4.2.2 Gráfico Burndown

Gráfico Burndown é uma das mais importantes ferramentas de gerenciamento de

desenvolvimento de software, com ele é possível apresentar o trabalho restante em

função do tempo. Com o gráfico Burndown pode-se medir o progresso do projeto e

saber se está demorando muito para alcançar as metas estipuladas ou se os ciclos

estão sendo finalizados com um trabalho de má qualidade.

Na figura 9 permite observar o processo de evolução do trabalho em função do

tempo, este tempo é complemento para o final do prazo. A imagem abaixo mostra

que a equipe no início demorou muito para entregar os itens e quando perceberam

no dia 29 de junho, começaram a retirar itens da entrega para se ajustarem ao

cronograma planejado. O problema é que foram retirados tantos itens que pelo

desenvolver das entregas, o projeto acabaria antes do planejado o que pode

caracterizar má qualidade nas entregas. O devido ajuste foi feito pelo Scrum Master

e o projeto acabou na data planejada 3 de julho.

42

Figura 9 Exemplo de gráfico Burndown (FAIAS, 2009; GOMES, 2009; SURJAN, 2009)

Pode-se errar no planejamento do Burndown, podendo as tarefas necessitarem de

maior tempo do que era esperado, ou ainda necessitar de menos tempo. Neste

caso deve-se definir com o time a exclusão ou a inclusão de novos itens de Backlog,

que não estavam previstos no Sprint Planning.

4.3 SCRUM NA PRÁTICA

O fluxo do Scrum inicia-se com a visão do projeto, esta visão é concebida pelo

Product Owner, em média deve possuir um parágrafo ou dois que descreva a

necessidade do projeto e os benefícios que este projeto trará após sua conclusão.

Em colaboração a idéia do projeto, o Product Owner formula um plano para alcançar

seu objetivo que é dividido em requisitos, esses requisitos são conhecidos como

itens de Backlog e o conjunto deles constitui o Product Backlog.

43

Os itens de Backlog são priorizados pelo Product Owner, assim pode-se garantir a

entrega dos itens que possuam maior valor de negócio para o fim da próxima Sprint.

O Product Backlog evoluí junto com o projeto e podem ser adicionados ou retirados

itens de Backlog para que o projeto gerencie mudanças de acordo com o ambiente

do projeto. Esse mecanismo de gerenciamento é um Controle de Processo

Empírico, o projeto sofre alterações a cada inspeção no final de cada Sprint.

No inicio do projeto é realizada a Sprint Planning 1, reunião de planejamento que

define os itens a serem realizados durante a próxima Sprint. Esta lista de itens é

conhecida como Sprint Backlog.

A Sprint inicia-se assim que a equipe termina de definir o Sprint Backlog, após isso

todos os dias é realizado o Daily Scrum. Ao final de cada Sprint são concebidas

duas reuniões: o Sprint Review que exibe aos Stakeholders e ao Product Owner o

resultado daquela Sprint. O objetivo desta reunião é ajudar a comunicação dos

envolvidos e reavaliar as necessidades do cliente, os impedimentos em entregar as

solicitações dos Stakeholders, e para a equipe receber o retorno positivo e negativo

do que foi realizado. A Sprint Review torna possível para os Stakeholders observar

necessidades analisando a entrega feita naquela Sprint. Os Stakeholders podem até

mesmo implantar os itens que foram entregues ao final daquela Sprint.

Logo após a Sprint Review, Scrum Master e a equipe interagem em uma reunião

descrita por Retrospective Scrum que consiste em avaliar os processos e práticas

Scrum para torná-los mais eficazes e agradáveis para a próxima Sprint e então o

fluxo volta ao começo e se tem início uma nova Sprint.

Abaixo na figura 10 ilustra-se o ciclo do Scrum.

44

Figura 10 Ciclo do Scrum na prática. (CAVALCANTI, 2008)

45

5. ESTUDO DE PEQUENA EMPRESA DE TI SEM GERENCIAMENTO

A empresa ACS Automação Comercial é um bom exemplo de empresa sem

metodologia. Ela iniciou seus trabalhos em 2008, com o intuito de ser uma empresa

diferente, quando comparada as outras empresas que atuam na área de automação

comercial em São Paulo. A ACS percebeu que havia uma grande defasagem nos

serviços prestados nesse ramo de atividade e assim está conquistando cada vez

mais clientes com serviços de qualidade e atendimento rápido, passando para seus

clientes confiança nos serviços executados, sempre trabalhando com muita clareza

em relação aos seus serviços.

A automação comercial se faz necessária para agilizar os processos de venda e

controle em geral, como em qualquer área do conhecimento que atualmente utiliza-

se da tecnologia para aprimorar qualidade e economizar tempo. Por exemplo, um

mini mercado que anteriormente registrava seu fluxo de caixa em um bloco de notas,

hoje pode fazê-lo através de um sistema integrado, automatizado e seguro;

garantindo a durabilidade, atomicidade e identidade da informação gerada ao longo

do período de produção.

Hoje a ACS Automação Comercial conta com uma equipe de 4 integrantes nas

determinadas funções:

Setor Administrativo: 1 funcionário

Setor Técnico: 2 funcionários

Setor Comercial : 1 funcionário

5.1 – CARACTERISTICAS DA EMPRESA ACS

ACS presta serviços direcionados a área de automação comercial, atuando na

implementação e manutenção de Pontos de Vendas (PDV) em empresas de varejo

como: supermercados, lanchonetes, restaurantes, padarias, bares e lojas.

46

Disponibilizando sistemas específicos para cada estabelecimento e também executa

todo o processo de venda, implementação e manutenção.

A carteira de clientes da ACS é proveniente em grande parte da indicação de outros

clientes como da indicação de profissionais da área que conhecem os serviços da

ACS.

A ACS segue as seguintes etapas no processo de negócio:

Pré-venda: A ACS verifica qual é o ramo de atividade do cliente e quais os

equipamentos necessários para o estabelecimento, para assim, implementar o

melhor sistema de acordo com as necessidades da empresa, fazendo com que o

estabelecimento atenda com eficiência e agilidade seus clientes. Através de uma

visita técnica é coletada informação sobre os processos rotineiros do

estabelecimento como relatórios de fechamento e relatórios de produtividade.

As vendas dos produtos da ACS são em sua maioria adquiridos por distribuidoras, já

que não tem quantidade suficiente de vendas para adquirir os produtos diretamente

com o fabricante, porém possui um valor de venda bem competitivo no mercado.

Depois de concretizada a venda é desenvolvido um orçamento baseado na estrutura

previamente analisada na pré-venda e em quais equipamentos o cliente irá precisar

para a implementação. Se a empresa for de grande porte, a parte de infra-estrutura

é terceirizada com uma empresa parceira. Se for de pequeno porte a ACS ensina o

cliente a realizar o serviço de infra-estrutura (estrutura de cabeamento lógico e

elétrico) da maneira mais adequada possível.

Assim que o cliente cumprir com as exigências solicitadas para o ambiente de

instalação, como preparar ou suprir condições físicas de instalação de parte elétrica

e lógica, é dado inicio aos trabalhos de implementação.

São realizadas as instalações dos equipamentos, tanto os PDVs de Check-out

quanto o equipamento gerenciador de retaguarda responsável pela consolidação

47

dos PDVs e são feitas configurações e testes. Depois de efetivada a instalação dos

equipamentos se inicia a capacitação e treinamento dos futuros usuários, sempre

respeitando o prazo acordado e com acompanhamento nos primeiros dias de

funcionamento.

A estimativa de entrega do projeto desde o primeiro contato com o cliente até a

entrega final do produto é previsto em um prazo de 5 a 10 dias para entrega da

impressora fiscal, sendo de 3 a 5 dias para ser realizado o lacre da impressora.

Após esse processo é previsto de 2 a 3 dias para se concluir a instalação.

Até o momento a única parte documentada de todo o processo é o orçamento, os

demais processos de implementação são acordados verbalmente e não existe

nenhum planejamento em relação ao processo como um todo. Por exemplo, ao

iniciar a instalação, os funcionários da ACS simplesmente trabalham em cima de seu

conhecimento adquirido através de experiências anteriores e do método tentar e

errar até ser possível a entrega de um produto que atende as necessidades do

cliente.

Também não há nenhum plano desenvolvido em relação ao treinamento do cliente.

Após a implementação dos serviços, a ACS disponibiliza um telefone para dúvidas e

eventuais problemas e um celular de suporte para emergências fora do horário

comercial.

48

5.1.1 Estudo da qualidade de projetos não gerenciados

No estudo de caso da empresa ACS Automação Comercial os projetos não são

gerenciados, não é feito um cronograma com data de inicio e fim de cada atividade

realizada do projeto, o custo de cada atividade e também não é entregue o resultado

de cada atividade, somente ao final de cada projeto é que são entregues os

resultados e custos adicionais que não foram previstos e estimados no planejamento

inicial.

Com esta informalidade os projetos da ACS Automação Comercial, são

normalmente negociados com caráter emergencial (APÊNDICE A) que apresenta

um modelo de projetos, com dialogo entre ACS e cliente.

49

6 ADAPTAÇÃO DO SCRUM

O Scrum como framework possibilita aos gerenciadores de projetos a liberdade para

adotar seus processos de gerenciamento e adaptá-los para que seja alcançado seus

objetivos, não importando porte, tipo, ambiente do projeto ou outros fatores

dependentes de cada cenário.

Este trabalho em sua análise com pessoas que trabalham diariamente com projetos

de TI em pequenas empresas de TI apontou que vários processos precisavam ser

adaptados para que seja possível manter o conceito do Scrum em um cenário tão

distinto do normalmente apresentado.

Existe uma grande diferença que separa a aplicação convencional do Scrum para

desenvolvimento de software em relação a um projeto de TI em pequenas empresas

de TI:

O ciclo de vida do projeto extremamente reduzido

Um projeto convencional do Scrum dura em média meses e possuí Sprints que

acontecem a cada 30 dias consecutivos que possibilitam entre uma entrega e outra

a inspeção de seus processos e das tarefas à serem realizadas. Em um projeto que

dure sete dias ao máximo, não se mostra viável reunir-se para participar de uma

reunião e perder um dia de trabalho.

Os itens abaixo podem ser incluídos, alterados ou removidos dependendo do projeto

e são definidos pelo Scrum Master.

Sprint

O primeiro processo adaptado é o Sprint, pois a agilidade do Scrum não consegue

acompanhar o ciclo de vida de um projeto de TI em uma pequena empresa de TI

que possua em média cinco dias duração. Não é lógico dividir um projeto curto de 5

dias e transformá-lo em cinco Sprints , perderia se mais tempo com as reuniões nos

50

intervalos de cada Sprint, do que propriamente na execução do trabalho. A inspeção

ocorreria durante dois encontros diários e ao final do projeto, aonde Product Owner,

Stakeholders e equipe se reuniriam para validar o resultado do produto ou serviço

solicitado.

Daily Scrum

O Daily Scrum seria um mecanismo de inspeção mais presente, mantendo a

duração de 15 minutos, realizada em pé e ao invés de somente uma, haveria duas

reuniões diárias; Daily Review e Daily Retrospective.

Gráfico Burndown

O gráfico Burndown apesar de ser uma ferramenta que mostra o desenvolvimento

da equipe durante um projeto e ajuda a analisar estimativas, seu uso em um projeto

curto não seria capaz de ajudar tanto quanto esperado.

Sprint Review

A Sprint Review seria realizada somente no final do projeto, guiando o projeto para

seu status de “feito” ou para realimentar e recomeçar o projeto em questão.

Product Backlog

Não existe necessidade de desenhar cartões para as funcionalidades dos itens de

Backlog em um projeto de TI que não abrange desenvolvimento de software e cuja

duração seja inferior a uma semana.

Sprint Backlog

Com uma só Sprint por projeto, talvez havendo duas caso na entrega o cliente não

esteja de acordo, não há a necessidade de construir um Sprint Backlog, as tarefas já

estariam estimadas e priorizadas para todo o projeto no próprio Product Backlog.

51

6.1 PAPEÍS E RESPONSABILIDADES DO SCRUM ADAPTADOS

Product Owner

O Product Owner continua representando o cliente ou sendo o próprio cliente.

Scrum Master

O Scrum Master além de possuir suas responsabilidades originais do Scrum,

também supervisionaria a qualidade das tarefas entregadas diariamente, a equipe

continuaria se auto-gerenciando e se auto-organizando, teria liberdade para definir

como trabalhar e como alcançar suas metas, mas pela questão da motivação, a

equipe teria o Scrum Master para garantir que o trabalho seja bem feito. Definiria

quais processos do Scrum seriam aplicados em cada projeto de acordo com suas

particularidades em relação às seguintes especificações:

Tipo de projeto;

Duração do projeto;

Tamanho da equipe;

Valor de negócio do projeto.

De acordo com essas especificações, o Scrum Master verifica como implantar os

processos e valores do Scrum. Nas quais podem ser implantadas as etapas do ciclo

do Scrum podendo ou não utilizar nossa adaptação das melhores práticas para

gerenciar projetos de TI em pequenas empresas de TI.

O Scrum Master pode assumir o papel do Product Owner quando necessário.

Equipe Scrum

A equipe Scrum continuaria sendo auto-gerenciável e auto-organizável, tendo que

apresentar suas funcionalidades prontas no prazo exigido. Ela por si própria poderia

alterar, adicionar ou remover os itens a serem realizados para que seja possível

alcançar o objetivo do projeto. As decisões seriam avaliadas pelo Product Owner,

52

em casos que ele seja representado pelo cliente e o mesmo não possa participar

ativamente do projeto, a responsabilidade é transferida para o Scrum Master.

6.1.1 Fluxo do Scrum para pequenas empresas de TI

Com as diversas particularidades que apresentam os projetos de TI em pequenas

empresas de TI, surgiu a necessidade de criar um fluxo adaptado baseado no Scrum

para auxiliar sua implantação no cenário atual. Como ilustrado na figura 11.

Figura 11 Ciclo do Scrum em pequenas empresas de TI (AUTORES, 2010)

Vision: é uma reunião composta pelo Product Owner, Scrum Master e algum

integrante do departamento comercial. Nesta reunião é exposta a visão do projeto, o

cliente apresenta uma visão que irá aprimorar seu negócio, atender uma

necessidade ou oportunidade.

Suggestion of Project: um integrante do departamento comercial junto com o

Scrum Master entende as necessidades do cliente, ajuda a construir uma proposta

53

com o melhor Return of Investiment (ROI) para aquele tipo de negócio e oferece

uma solução.

Acceptance of Project: O cliente avalia a proposta e se estiver de acordo, fecha o

contrato.

Sprint Planning 1: Após a proposta do projeto ser aceita inicia-se o projeto.

Product Backlog: é criado, estimado e priorizado os itens de Backlog que devem

ser entregues no decorrer do projeto.

Sprint: Ciclo do projeto.

Daily Review: reunião diária igual ao Daily Scrum, tendo como participantes a

equipe e o Scrum Master.

Daily Retrospective: reunião diária realizada no final do dia, contaria com a

presença do Product Owner, Scrum Master e a equipe. Seu objetivo seria substituir

as reuniões de inspeção Scrum realizadas ao final de cada Sprint.

O Daily Retrospective seria de 15 minutos e também possuiria três perguntas

básicas que seriam respondidas individualmente pelos integrantes da equipe:

• O que foi feito ontem?

• O que será feito amanhã?

• O que foi mudado em relação ao planejamento inicial?

Após a equipe responder as perguntas, a reunião termina e o Product Owner pode

alterar a prioridade dos itens caso considere necessário, enquanto que o Scrum

Master pode intervir se as alterações do Product Backlog forem drásticas o

suficiente para alterar o objetivo do projeto. Se isto acontecer, Scrum Master e

Product Owner se reúnem para estruturar uma nova Vision para o projeto.

Retrospective: é a reunião no qual é feito um balanço dos itens entregues e dos

itens solicitados, indicando se a necessidade foi atendida pelo projeto ou se precisa

continuá-lo.

The End: caso o projeto esteja dentro do solicitado, caso seu objetivo não seja

alcançável ou caso não haja mais necessidade do projeto, ele é encerrado. Caso

contrário, o ciclo retorna para visão do projeto.

54

6.2 ESTUDO DE CASO I: PROJETO MONITORAMENTO

O estudo de caso do projeto para monitoramento consiste em um sistema de

monitoramento para uma fábrica de roupas na cidade de São Paulo.

Vision

O proprietário desta fábrica de roupas necessita instalar câmeras em lugares

estratégicos de sua empresa para monitoramento de seus funcionários e seu foco é

monitorar o andar por completo retirando os pontos cegos. As imagens geradas

pelas câmeras serão armazenadas em um servidor stand-alone. Será necessário

estruturar uma redundância para estes dados e treinamento para os usuários do

stand-alone.

Product Backlog

Na tabela 1 pode-se observar os itens de Backlog com suas estimativas e

priorizados pelo Product Owner.

Tabela 1 Product Backlog – Projeto Monitoramento

Importância Estimativa

1. Analisar infra-estrutura para implantar o sistema de monitoramento 2 1

2. Analisar quais são os tipos específicos de equipamentos necessários para o monitoramento 5 2

3. Analisar parte elétrica para fornecimento de energia das câmeras e stand-alone 2 1

4. Analisar parte lógica para cabeamento das câmeras e stand-alone 3 1

5. Definir local para o stand-alone 4 1

6. Analisar tubulação existente no local 1 1

7. Identificar número de câmeras para monitoramento 1 1

8. Analisar número de pontos cegos no monitoramento e aplicar método corretivo 4 1

9. Analisar condições de luz e alcance das câmeras 3 1

10. Analisar se área da tubulação é suficiente para a quantidade de fios lógicos e elétricos para as câmeras 3 1

11. Criar orçamento para compra de materiais 3 1

55

Importância Estimativa

12. Criar topologia do sistema monitoramento 4 1

13. Estruturar redundância no armazenamento dos arquivos 5 1

14. Fazer a parte de cabeamento das câmeras, levando os cabos até o local de cada câmera 5 8

15. Fixação de todas câmeras no local especifico de cada câmera. 5 4

16. Configuração do posicionamento de cada câmera. 5 5

17. Configuração stand-alone 4 3

18. Treinamento dos usuários 3 2

Total 36h

Fonte: AUTORES (2010)

A partir da criação Product Backlog, foi criado o gráfico Burndown deste projeto com

a quantidade de itens representada no eixo X e a quantidade de dias no eixo Y,

assim o Scrum Master, poderá efetuar um maior controle sobe o projeto.

Figura 12 Burndown do Projeto de Monitoramento (AUTORES, 2010)

56

Sprint

Antes de iniciar o projeto Monitoramento, o Scrum Master concluiu que a melhor

maneira de gerenciar este projeto era disfarçando o Scrum. Utilizar seus conceitos

de gerenciamento sem mencionar suas nomenclaturas. Não deixando de seguir

fielmente os processos do Scrum adaptado para projetos de TI em pequenas

empresas de TI.

A decisão foi motivada pela economia de tempo já que não foi necessário treinar os

envolvidos do projeto em Scrum. Bastou apenas definir claramente o horário das

reuniões, prazos de entrega e explicar que a equipe seria livre para trabalhar, mas

que responderia diretamente ao cliente todos os dias.

Houve dificuldade para comprometer os indivíduos de que era necessário cumprir os

horários e o Scrum Master trabalhou bastante, pois era sua obrigação ver o que

estava sendo feito para garantir a qualidade das entregas e nos encontros diários

ele tinha um feedback do que estava sendo feito e como poderia ajudar a equipe

com problemas externos ao projeto. Outra dificuldade foi deixar claro que os

participantes definidos para as reuniões diárias tinham obrigação de comparecer.

O Product Backlog foi uma ferramenta extremamente útil, pois demonstrava o que

precisava ser feito e priorizava o que era mais importante, assim a equipe focava

nos problemas mais complexos e não perdia tempo pensando em como deveria

fazer ou o que deveria ser feito primeiro, além de traduzir o contrato em requisitos e

documentar as solicitações do cliente. Ao final do dia o Product Owner representado

pelo cliente ouvia da equipe o que havia sido realizado durante o dia e alterava os

itens do Product Backlog de acordo com suas necessidades.

O Scrum Master interferia nas decisões do Product Owner sempre que considerava

as decisões dele incoerentes, mas educadamente conversava com o cliente para

encontrar o caminho certo e alcançar os objetivos do projeto de maneira ágil e

prática.

57

Retrospective

Ao final do projeto, todos se reuniram para analisar se o projeto havia atendido as

expectativas. Não foi necessário reiniciar o processo, mas com ajuda do Daily

Review e Daily Retrospective, o Product Owner sempre sabia o que estava sendo

realizado e caso precisasse alterar algo que não havia sido previsto ou alterar algo

que só foi visto no decorrer da Sprint, este item era alterado ao final do dia junto com

a equipe de forma transparente e rápida.

Concluiu-se que o Scrum adaptado trouxe mais benefícios do que dificuldades neste

projeto.

6.3 ESTUDO DE CASO II: MUDANÇA DE SISTEMA SUPERMERCADO

Vision

Necessidade de instalação de um novo sistema de frente de caixa que seja

homologado pela lei do Programa Aplicativo Fiscal – Emissor de Cupom Fiscal

(PAF-ECF) que rege pelo órgão público responsável pelas normas de

funcionamento de sistemas de frente de caixa de cada estado, que será utilizado

com a impressora Fiscal, para ser gerado o Cupom Fiscal (ECF).

Este sistema necessita homologação para suprir as necessidades exigidas pela

PAF-ECF, entre estas a emissão da nota fiscal paulista segundo a Lei estadual

12.685/07.

Com a alteração no sistema de frente de caixa, surge também a necessidade de

alteração do software de gerenciamento de caixas, para obter maior velocidade,

integridade e melhor gestão de negócio. Este sistema deverá ser rápido para que

ocorra a diminuição de filas, interface amigável, possua controle de acesso e forneça

relatórios gerenciais.

A loja possui quatro caixas e irá permanecer com este número de caixas com o novo

sistema.

58

No escritório há dois computadores que terão que acessar o sistema gerenciador

dos caixas.

O sistema atual funciona com quatro impressoras, não fiscais, que não permite a

impressão de cupom fiscal, somente recibo sem valor fiscal.

Os caixas são compostos pelas seguintes características:

a) Computador;

b) Monitor;

c) Gaveta de dinheiro;

d) Impressora de recibo não fiscal;

e) Leitor de código de barra de mesa;

f) Sistema operacional Windows Millennium Edition;

g) Não possuem serviço de internet.

Criação do orçamento de venda

O orçamento segue com todos os itens e preço especificados (APÊNDICE B).

Sprint Planning 1

Na Sprint Planning 1 o Product Owner aprova a proposta do sistema, o Scrum

Master apresenta os itens do Product Backlog para que o Product Owner defina a

prioridade e o valor de negócio para cada item. Abaixo segue a tabela 2 que

apresenta o Product Backlog deste estudo de caso.

59

Tabela 2 Product Backlog – Projeto mudança de sistema

Item Descrição Importância Estimativa 1 Conversão do banco de dados 10 1 2 Lacrar a impressora fiscal 9 3 3 Entrega dos equipamentos 8 10 4 Instalação do gerenciador dos caixas 7 2 5 Treinamento dos usuários do gerenciador 6 1 6 Treinamento dos usuários do caixa 7 1 7 Treinamento dos usuários do caixa 6 1 8 Acompanhamento de inauguração do sistema 4 2

Total 21 dias Fonte: Autores (2010)

Sprint

Neste projeto o Scrum Master definiu apenas uma Sprint para todo o projeto e

adquiriu a responsabilidade de criar e priorizar os itens do Product Backlog, além de

garantir a qualidade da entrega realizada pela equipe.

A duração desta Sprint foi de 20 dias, o Scrum Master definiu as prioridades e o

tempo estimado para cada item do Product Backlog junto com o cliente que foi

atribuído o papel de Product Owner.

A execução da Sprint no estabelecimento do cliente se iniciou no item 4 com a

instalação do gerenciador de caixa. Foram realizadas as reuniões diárias

normalmente.

Na reunião do Daily Review foi relatado e constatado o andamento da entrega do

item 4 do Product Backlog. De acordo com o integrante da equipe a execução do

item está de acordo com o estimado, foi realizada a instalação do sistema

gerenciador dos caixas no servidor e habilitado o acesso nas duas máquinas

exigidas que tenham acesso, também foi feita a importação do cadastro de produtos

convertido do sistema anterior com sucesso.

No segundo dia da entrega do item 4, foi realizado o confronto dos dados do sistema

anterior com o novo para entrega da instalação com sucesso e também foi instalado

um frente de caixa para testes de vendas com intuito de verificar os códigos e

60

preços de alguns produtos da loja e funcionamento correto do gerenciador dos

caixas. Pode-se acrescentar que todos souberam o que ocorreu durante a Daily

Review e Daily Retrospective.

No item 5 foi realizado o treinamento dos usuários do sistema gerenciador dos

caixas e tudo que foi alterado no cadastro de produto do sistema anterior já foi

também alterado no novo sistema.

No item 6 foi realizado o treinamento de todos os operadores de caixa usando o

frente de caixa teste instalado na loja.

No item 7 após o fechamento da loja foram realizadas as instalações do frente de

caixa em todos os computadores para iniciar o dia seguinte com o sistema novo.

No item 8 foi realizada a abertura da loja com o novo sistema e realizado o

acompanhamento do sistema até o fechamento da loja , este item estava estimado

para dois dias pelo Product Owner, porém devido as boas entregas dos itens do

Product Backlog, o Scrum Master junto com o Product Owner definiram ser

desnecessário o acompanhamento do sistema por mais um dia.

Daily Review

O Daily Review foi realizado em todos os dias que a Sprint iniciou e com esse valor

agregado do Scrum, o projeto teve um maior aproveitamento durante os dias de

execução da Sprint.

Daily Retrospective

Ao final de cada entrega de item durante os dias de execução foi realizada a reunião

na sede da empresa e no próprio cliente com o Scrum Master e o Product Owner

para verificar a entrega dos itens de Backlog pelo integrante da equipe, somente no

último item do Product Backlog que o Scrum Master e Product Owner definiram

como entregue o item que tinha como estimativa mais um dia de Sprint.

61

Retrospective

Foi realizado uma reunião final para verificar todos os itens do Backlog, nesta

reunião todos os membros da equipe puderam avaliar o projeto inteiro, o Scrum

Master foi o responsável pela apresentação e integração do Product Owner com a

equipe. No final da Retrospective, o Product Owner efetuou a validação do projeto e

assinou o aceite formal.

6.4 RESULTADO DO ESTUDO DOS CASOS

Dentro deste período foi analisada a melhor forma de adaptar o Scrum as pequenas

empresas de TI em projetos de TI, com a mudança de estrutura que foi necessária

implantar nos projetos estudados, para concluir está implantação. Obtive-se os

seguintes resultados:

Equipe Scrum teve grande facilidade nos treinamentos do Scrum, mas não

conseguiram obter a mesma facilidade no uso diário, pois a equipe trabalhava de

forma tradicional com a necessidade do gerente para guiá-los em suas funções.

Product Owner teve resultados mais rápidos, pois com o método de gerenciamento

tradicional o cliente não tinha um feedback com tanta freqüência e nem conseguia

acompanhar o andamento do projeto.

Scrum Master dedicou o seu tempo integralmente na implantação do Scrum e

maximizar os benefícios do projeto, sempre alinhado junto com o Product Owner.

No projeto com a utilização do Scrum no gerenciamento dos projetos da ACS, foi

possível uma melhora de qualidade de gestão de projetos, diminuição da carga de

trabalho de cada integrante, com a junção destes itens foi possível uma melhora nos

resultados de cada projeto, pois cada integrante trabalha em sua especialidade e o

Product Owner acompanha de perto o projeto afim de que não seja desviado da

visão inicial.

62

6.4.1 Conclusões sobre o estudo dos casos

Com a aplicação de Scrum neste contexto fora de desenvolvimento de software,

foram encontradas diversas dificuldades em alcançar o resultado final, pois as

equipes de “chão de fábrica” possuem grande de dificuldade em serem auto-

gerenciáveis e auto-organizáveis, mas ambas as empresas puderam obter o máximo

de seus serviços, tanto a ACS quanta a empresa contratante poderão maximizar os

seus lucros e atingir os resultados com maior facilidade. No projeto de implantação

do supermercado XY foi possível alterar o Product Backlog, pois com o

acompanhamento do Product Owner, e as reuniões diárias não foram necessárias

além de acompanhar a inauguração do sistema durante dois dias, um dia foi o

bastante.

63

7 CONCLUSÃO

Concluiu-se que a adaptação do framework Scrum traz benefícios ao gerenciamento

de projetos de TI de pequena empresa de TI, organizando de maneira prática e

simples sem a exigência de documentação e treinamento extensivo. Focado em

pessoas a adaptação provou ser bastante flexível e adaptável.

Mesmo diminuindo o escopo tornou-se muito difícil desenvolver melhores práticas do

Scrum adaptado, pois dependendo do cenário, seu fluxo e/ou processos teriam que

ser readaptados. Mesmo assim, esta adaptação provou organizar a maneira como

os envolvidos no projeto trabalhavam. A equipe tinha certeza de quais eram os

requisitos a serem entregues e quais eram os mais importantes através do Product

Backlog, o Product Owner mantinha contato diário com o projeto e ouvia os

pensamentos da equipe, de forma a permitir a inclusão, alteração ou exclusão de

itens a serem entregues no decorrer do projeto. As reuniões diárias dívidas por Daily

Review e Daily Retrospective substitui os ciclos de inspeção que aconteciam ao final

de cada Sprint em projetos de desenvolvimento de software. Nota-se viável o uso do

Scrum adaptado, pois não é necessário receber treinamento Scrum, para praticá-lo,

basta um Scrum Master que ajude na compreensão de seus conceitos, além de que

o Scrum Master pode ou não utilizar as nomenclaturas do Scrum, ou seja, apenas

ele saberá da prática do Scrum em determinado projeto. Com o uso do Scrum foi

possível dar liberdade para a equipe trabalhar da maneira que desejasse e ao

Scrum Master coube o papel de garantir a qualidade do que era realizado pela

equipe.

Conclui-se também que os estudos deverão ter uma seqüência a fim de obter

avanços com a comunidade cientifica, está continuidade poderá ser alcançada nos

trabalhos futuros sugeridos no capitulo seguinte.

64

7.1 TRABALHOS FUTUROS

Com a idéia de continuidade deste trabalho sugere-se aprofundar a abrangência da

adaptação do framework Scrum para gerenciar todo tipo de projeto para todo tipo de

pequena empresa, não somente projetos e empresas de TI, projetos de implantação,

projetos para gerenciar a própria empresa, seus funcionários e projetos de expansão

da empresa.

Aprimorar os papéis atribuídos aos envolvidos no projeto, desenvolver outros ou

adaptá-los conforme a realidade em uma pequena empresa.

Desenvolver um sistema que armazene um histórico dos projetos anteriores e assim

ajudar futuros Scrum Masters na hora de escolher o melhor meio de adaptar o

framework Scrum tendo como base documento real de cada projeto, valores do

Scrum, estimativas utilizadas para cada item do Backlog, tamanho médio de Sprints,

modelos de Product Backlog e por fim manter um documento histórico da empresa.

65

REFERÊNCIA BIBLIOGRÁFICA BECK, Kent. Extreme Programming Explained: Embrace Change. 2. ed. Melbourne: Paperback, 2004. CAVALCANTI, Eric. SCRUM: Uma abordagem prática. Recife: C.E.S.A.R., 2008. 1 v. Disponível em: <http://www.treinatom.com.br/pt/cafe-com-o-tom>. Acesso em: 05 maio 2010. COHN, Mike. Agile Estimating and Planning. Addison-Wesley, 2005. COCKBURN, Alistair. Agile Software Development: The Cooperative Game. 2. ed. New Jersey: Addison-Wesley, 2001. CONSORTIUM, DSDM (Org.). DSDM Atern - The Agile Project Delivery Framework. Disponível em: <http://www.dsdm.org/>. Acesso em: 28 out. 2010.

CRISP. Planning Poker Cards. Disponível em: <http://www.crisp.se/planningpoker>. Acesso em: 10 out. 2010. FAIAS JUNIOR, Luiz; GOMES, André Faria; SURJAN, Jakov Trofo. Pronto: Agile Project Management. Disponível em: <http://pronto.bluesoft.com.br/>. Acesso em: 04 out. 2010. FERREIRA, Aurélio Buarque de Holanda. Novo Dicionário do Aurélio. 2. ed. Rio de Janeiro: Nova Fronteira, 1986. FRIED, Jason. É difícil trabalhar no local de trabalho. Revista Época: O Dom da Fúria, São Paulo, n. 632, 25 jun. 2010. Disponível em: <http://revistaepoca.globo.com/Revista/Epoca/0,,EMI150505-15259,00-JASON+FRIED+E+DIFICIL+TRABALHAR+NO+LOCAL+DE+TRABALHO.html>. Acesso em: 09 nov. 2010. GRENNING, James. Planning Poker or How to avoid analysis paralysis while release planning. Creative Commons, 2002. Disponível em: <http://renaissancesoftware.net/files/articles/PlanningPoker-v1.1.pdf>. Acesso em: 10 out. 2010. HIGHSMITH, James A.. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Paperback, 1999. KNIBERG, Henrik; SUTTERLAND, Jeff; COHN, Mike. Scrum and XP from the Trenches: How we do Scrum. Stockholm: Infoq, 2007. 1 v. LUCA, Jeff de. Feature Driven Development. Disponível em: <http://www.featuredrivendevelopment.com/>. Acesso em: 28 out. 2010.

66

MARTINS, Elaine; ROCHA, Camila R.; SOARES, Silvia C. M.. SCRUM: Processo de Desenvolvimento de Software. Disponível em: <http://www.dcc.unicamp.br/~eliane/Cursos/MO409/Curso2003/Apresentacoes/Scrum.ppt>. Acesso em: 28 out. 2010. MIRANDA, Eduardo. Estimation of inelastic deformation demands of. New York: J. Struct. Eng., 2001. PESSOA, Dr. Marcelo Schneck P.; SILVA, Marcos Antonio Rodrigues da. Produção de Software: Proposta para uma fábrica de software com qualidade e produtividade. Disponível em: <http://www.poli.usp.br/pro/procsoft/tproepusp04.pdf>. Acesso em: 28 out. 2010. POPPENDIECK, Mary; POPPENDIECK, Tom. Lean Software Development: An Agile Toolkit for Software Development Managers. New Jersey: Addison-wesley, 2003. TOMHAVE, Benjamin L. Alphabet Soup: Making Sense of Models. Washington: Creative Common, 2005. 57 p. Disponível em: <http://falcon.secureconsulting.net/papers/Alphabet_Soup.pdf>. Acesso em: 27 set. 2010. PATTON, Jeff. Don’t know what I want, but I know how to get it. Disponível em: <http://www.agileproductdesign.com/blog/dont_know_what_i_want.html>. Acesso em: 27 set. 2010. PMI. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos: Guia PMBOK. 3. ed. Newton Square: Pmi Global Standard, 2004. 403 p. PUC (Rio de Janeiro). Método e Metodologia. Disponível em: <http://www.puc-rio.br/sobrepuc/depto/dad/lpd/download/metodologiaemetodos.rtf>. Acesso em: 04 out. 2010. SANTOS, Rildo F. Scrum Experience: O Tutorial SCRUM. 16. ed. São Paulo: Scribble, 2009. 1 v. Disponível em: <http://www.scribd.com/doc/16983386/Scrum-Experience-O-Tutorial-SCRUM-v16>. Acesso em: 05 maio 2010. SAATY, Thomas L.. Analytic Hierarchy Process Series. III San Pittsburg: RWS, 1996. SCHWABER, Ken. Agile Project Management with SCRUM. Wash Redmond: Microsoft Press, 2004. 1 v. SCHWABER, Ken et al. Manifesto Ágil. Utah: Agile Alliance, 2001. 1 v. Disponível em: <http://www.manifestoagil.com.br/>. Acesso em: 05 maio 2010. SILVA, Tiago de Farias. Compondo Métodos Ágeis de Desenvolvimento. 2009. 81 f. Tese (Bacharel) - Curso de Ciência da Computação, Departamento de Centro de

67

Informática, Universidade Federal de Pernambuco, Recife, 2009. Disponível em: <http://www.cin.ufpe.br/~tg/2009-1/tfs.pdf>. Acesso em: 10 nov. 2010. UNB, Universidade de Brasília. O que é uma metodologia ágil? Disponível em: <http://www.redes.unb.br/material/ESOO/Metodologias%20%C1geis.pdf>. Acesso em: 10 nov. 2010. VARGAS, Ricardo. Gerenciamento de Projetos. 7. ed. São Paulo: Brasport, 2009. 276 p. WOODWARD, Elizabeth; SURDEK, Steffan; GANIS, Matthew. A Practical Guide to Distributed Scrum. [s.l.}: Prentice Hall, 2010. 240 p. XAVIER, Carlos Magno da Silva. Gerenciamento de Projetos: Como definir e controlar o escopo do projeto. 2. ed. Rio de Janeiro: Saraiva, 2008. 272 p.

68

APÊNDICE A - EXEMPLO DE PROJETO DA ACS

Mudança de Sistema Retaguarda (Gerenciador dos caixas de Supermercado) e PDV

para Supermercado.

O diálogo abaixo expressa claramente o cenário atual:

Cliente: Não estou satisfeito com o meu sistema, o que pode me oferecer?

ACS: Vamos agendar uma visita para demonstração de nosso sistema?

Cliente: OK pode vim amanhã às 08:00h?

ACS: Está combinado.

Na visita é verificado como o cliente trabalha, quais controles são utilizados e então

é realizada a demonstração.

Cliente: OK! É isso que preciso! Mande um orçamento com urgência para darmos

início a virada do sistema.

ACS: Já temos o orçamento feito, quando podemos fazer uma reunião para

apresentar o orçamento?

Cliente: Pode ser amanhã às 08h00minh?

ACS: Está Combinado.

ACS: Aqui está o orçamento os custos de instalação, mensalidade do sistema e

equipamentos necessários para a virada de sistema.

Cliente: Certo, está aprovado. Em quanto tempo consegue instalar?

ACS: Precisamos converter o banco de dados para o nosso sistema, assim que

realizarmos a conversão do banco e depois instalamos.

Cliente: Ok, faça o mais rápido possível.

ACS: Certo, vamos conversando, irá agilizar.

O próximo procedimento é enviar o banco de dados para o programador do sistema

converter para o banco do novo sistema. Após isso um técnico visita o local para

69

instalar o Sistema Retaguarda e conferir com o cliente a relação de produtos

cadastrados, feito isso é iniciado a instalação do sistema de frente de caixa.

Atividades executadas no projeto:

Conversão do banco de dados;

Instalação e configuração do sistema;

Treinamento dos operadores de caixa;

Treinamento dos Fiscais de caixa;

Treinamento do gerente da loja;

Treinamento dos usuários do gerenciador dos caixas;

Acompanhamento de inauguração.

O projeto todo é realizado através da experiência em implantação de sistema do

técnico responsável com prazo de entrega dado em relação a outras instalações do

mesmo nível de dificuldade.

70

APÊNDICE B – PROPOSTA COMERCIAL PROJETO MONITORAMENTO

São Paulo, 10 de setembro de 2010.

A

Projeto de Monitoramento

Assunto: Orçamento de Venda.

EMPRESA: Automação Comercial e Serviços LTDA – ME.

ENDEREÇO: Rua Luis Dumont Villares, 1030.

CEP: 02085-100 MUNICÍPIO: São Paulo ESTADO: SP

CNPJ: 10.603.263/0001-49 FONE: (11) 2976-3900

1 - ESCOPO DOS SERVIÇOS.

1.1. Informações Obtidas no Local.

Estivemos em visita ao local, tomando conhecimento do escopo dos serviços cujo detalhamento

segue abaixo.

1.1. Descrição dos Serviços.

1.1.1. Cabeamento e instalação

O cliente deseja instalar 16 câmeras. Conforme figura abaixo:

71

Layout da área para monitoramento

72

2 - Responsabilidades.

2.1. Responsabilidades da Contratada

- Fornecimento de mão-de-obra qualificada e auxiliar;

- Fornecimento de E.P.I.(s) para nossos funcionários;

- Fornecimento de refeições para nossos funcionários;

- Fornecimento de transporte para nossos funcionários;

- Supervisão técnica da obra;

- Fornecimento de “quantificação de materiais”.

2.2. Responsabilidades da Contratante

- Fornecimento de sanitário de campo e vestiário para o uso de nossos funcionários;

- Liberação dos locais, onde serão realizados os trabalhos, inclusive em horários extraordinários.

- Fornecimento de todos os materiais de aplicação e consumo.

- Fornecimento de equipamentos de elevação e transporte.

3 - Cronograma.

O prazo para a execução dos serviços de câmera é de 05 (cinco) dias.

73

4 - Condições Comerciais.

4.1- Valor da Proposta.

Item Descrição Unid. Qtde V. Unit. V. Total

1 STAND ALONE 16

CANAIS VD16E240 C/HD

INTELBRAS - ISEC -

INTELBRAS CFTV com

HARD DISK 1,5 TB SATA

SEAGATE -

INFORMÁTICA

un

01

R$3.000,00

R$ 3.000,00

2 MINI CAMERA DAY/NIGHT VM320 420 LINHAS CCD SONY 1/3 - INTELBRAS - ISEC – INTELBR

un

16

R$ 165,00

R$660,00

3 FONTE 12V 600MA C/PLUG - FRELUX - N/D - SECURITY

un

16

R$ 23,00

R$ 92,00

4 CAIXA DE PROTECAO ANODIZADA JUNIOR+SUPORTE 8,5CM MITSUPAK – MITSUPAK

un

16

R$ 36,00

R$ 144,00

5 Cabo Coaxial mt 1920 R$ 2,50 R$ 650,00

6 Conector BNC un 16 R$ 20,00 R$ 60,00

7 Eletroduto 3x4 (3 metros) un 30 R$ 18,00 R$ 450,00

8 Suporte para eletroduto un 60 R$ 1,20 R$ 72,00

9 Caixa de passagem 3x4 un 20 R$ 7,20 R$ 108,00

10 Conector do eletroduto un 40 R$ 3,80 R$ 152,00

74

11 Curva do eletroduto un 10 R$ 3,50 R$28,00

12 Bucha e parafuso un 01 R$ 45,00 R$45,00

13 Tampa cega ¾ un 20 R$ 5,20 R$78,00

14 Silicone un 02 R$ 21,00 R$42,00

15 Tampa PVC 3/14 un 60 R$ 1,20 R$54,00

16 Mão de Obra un 16 R$250,00 R$ 1.000,00

17 Mão de Obra Gesso un 01 R$370,00 R$ 370,00

18 Tinta branca un 01 R$ 150,00 R$ 150,00

TOTAL R$7.155,00

4.2. Condições de Pagamento.

R$ >> A titulo de Sinal

R$ >> 30 dias

5 - CONSIDERAÇÕES GERAIS.

O eletroduto que será instalado de ponta a ponta até a entrada da rua deverá ser instalada na parte

inferior da parede por haver cerca elétrica e isso acarretará interferência na imagem da câmera, favor

confirmar se não haverá problemas quanto a instalação deste eletroduto.

6 – REAJUSTE DE PREÇOS.

Dentro do prazo determinado para a execução dos serviços, consideramos nossa proposta como fixa.

75

7 – SERVIÇOS ADICIONAIS.

Para o caso de serviços adicionais a esta proposta, será elaborada proposta de aditivo, sendo os

serviços somente executados após a aprovação da mesma.

8 – VALIDADE DA PROPOSTA.

Esta proposta é válida por 10 (dez) dias, a partir dos quais solicitamos a confirmação das condições

da mesma, antes de considerá-la como válida.

Sendo o que nos apresenta, ficamos a disposição para dirimir eventuais duvida

76

GLOSSÁRIO

Fibonacci: Um número na seqüência Fibonacci é gerado através da soma dos dois

números anteriores. (COHN, 2005, p.52, tradução nossa)

Manifesto Ágil: No ano de 2001 em um encontro com 17 desenvolvedores nos

Estados Unidos da América, nasceu o “Manifesto para o Desenvolvimento Ágil de

Software”. Este manifesto teve como premisse a seguinte frase “Estamos

descobrindo maneiras melhores de desenvolver software fazendo-o mesmos ou

ajudando outros a fazê-lo”. Nasciam então os doze princípios do Manifesto Ágil.

(SCHWABER, et al. 2001).

Metodologia. [do gr. metodos, 'metodo', + -log (o) + ia.] S. f.. 1. A arte de dirigir o

espírito na investigação da verdade. 2. Filos. Estudo dos métodos e especialmente

dos métodos da ciência.

Método. [do gr. metodos, 'caminho para chegar a um fim'.] S. m. 1. Caminho pelo

qual se atinge um objetivo. 2. Programa que regula previamente uma série de

operações que se devem realizar, apontando erros evitáveis em vista de um

resultado determinado (esperado). 4. Modo de proceder; maneira de agir; meio.

(Novo Dicionário do Aurélio, 1986)

Projeto: “Projeto é um empreendimento não repetitivo, caracterizado por uma

seqüência clara e lógica de eventos, com inicio, meio e fim, que se destina a atingir

um objetivo claro e definido, sendo conduzidos por pessoas dentro de parâmetros de

tempo, custo, recursos envolvidos e qualidade”. (XAVIER, 2002)

Scrum: tradução: “luta pela bola numa jogada de rúgbi”. (Michaelis Moderno

Dicionário Inglês, 2010)

77

ANEXO A – DEFINIÇÕES DO SCRUM

Item Descrição

Daily Scrum

O Daily Scrum é um mecanismo de inspeção

mais presente, mantendo a duração de 15 minutos, realizada em pé

Gráfico Burndown

O gráfico Burndown apesar de ser um artefato que mostra o desenvolvimento da equipe durante um projeto e ajudando a equipe a analisar sua estimativa inicial, seu uso em um projeto curto não seria capaz de ajudar tanto quanto esperado.

Itens do Product Backlog

Lista de requisitos, nomeado de Product

Backlog. Cada nova funcionalidade possuí um cartão que descreve brevemente seu objetivo e contém elementos chave para sua fácil identificação.

Product Backlog

Lista de requisitos do projeto. Os requisitos ou itens de Backlog são alinhados pelo cliente e através de uma reunião só com a equipe, é definido como será entregue algo de valor até o fim do ciclo

Product Owner

Pessoa responsável por gerenciar o Product

Backlog e criar o maior retorno de investimento possível com o projeto. Product

Owner representa o cliente.

Retrospective Scrum

Reunião no qual é feito um balanço dos itens

entregues e dos itens solicitados, indicando

se a necessidade foi atendida pelo projeto

ou se precisa continuá-lo.

Sprint Planning

Reunião do Scrum com a finalidade de ser o planejamento inicial e define como será o primeiro ciclo de trabalho, define-se junto com o cliente o que precisa ser feito, quais são as prioridades, visando entregar após um ciclo curto de período um produto de

78

valor agregado.

Scrum

Melhores práticas de gerenciamento de projetos comumente aplicado em projetos de desenvolvimento de software. Seu foco são as pessoas e não os processos. Se vale de ciclos curtos, possuí um controle de processo empírico e é iterativo e incremental.

Scrum Master

Pessoa com grande experiência em Scrum, para aplicar os valores e práticas Scrum, cabe ao Scrum Master resolver todos os assuntos externos ao projeto.

Sprint

É o ciclo de trabalho do Scrum, existem várias Sprints dentro de um projeto Scrum e tudo que for planejado ou revisado nas reuniões é feito pela equipe.

Sprint Backlog

Lista de tarefas a serem entregues durante

cada Sprint.

Stakeholder

Envolvidos no projeto, este grupo pode ser formado por pessoa e organizações. Este grupo deve ter seus interesses afetados pelo projeto de forma positiva ou negativa.

Equipe Scrum

O terceiro papel do Scrum é a equipe, composta de maneira heterogênea, a fim de suprir as mais diversas necessidades do projeto