UNIVERSIDADE ANHEMBI MORUMBI JEFFERSON GELAZIO DE QUEIROZ MAURICIO PEREIRA LIMA RAFAEL DA COSTA ASSIS FERREIRA

SCRUM PARA GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAO EM PEQUENAS EMPRESAS DE TECNOLOGIA DA INFORMAO

So Paulo 2010

JEFFERSON GELAZIO DE QUEIROZ MAURICIO PEREIRA LIMA RAFAEL DA COSTA ASSIS FERREIRA

SCRUM PARA GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAO EM PEQUENAS EMPRESAS DE TECNOLOGIA DA INFORMAO

Trabalho apresentado como exigncia parcial para a obteno de titulo de Bacharel em Sistemas da Informao pela Universidade Anhembi Morumbi. Orientador: Prof. Jorge Makoto Shintani

So Paulo 2010

Q44

Queiroz, Jefferson Gelazio de

Scrum para gerenciamento de projetos de tecnologia da informao em pequenas empresas de tecnologia da informao / 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

SCRUM PARA GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAO EM PEQUENAS EMPRESAS DE TECNOLOGIA DA INFORMAO
Trabalho apresentado como exigncia parcial para a obteno de titulo de Bacharel em Sistemas da Informao pela Universidade Anhembi Morumbi. Aprovado em

Prof. Universidade Anhembi Morumbi

Prof. Universidade Anhembi Morumbi

Prof. Universidade Anhembi Morumbi So Paulo 2010

AGRADECIMENTOS Primeiramente, agradecemos a Deus, pela fora e nos dar sade para concluirmos essa etapa de nossas vidas. Aos nossos avos em especial Sra. Adelina, Sr. Vicente, avs do Rafael pelos esforos para o seu neto concluir os estudos. Aos nossos pais que jamais mediram esforos e sempre nos apoiaram e incentivaram para continuarmos nesta caminhada. Aos irmos que nos auxiliaram financeiramente e com apoio psicolgico. E tambm gostaramos de agradecer as namoradas quem compartilharam o seu tempo e seu apoio para a concluso deste trabalho. todos os citados e amigos e outras pessoas que contriburam para a concluso de trabalho Muito Obrigado e tambm desculpas pela ausncia e pela intolerncia. Obrigado Jessica, por compartilhar o tempo do seu namorado conosco.

RESUMO A qualidade dos projetos de pequenas empresas de Tecnologia da Informao (TI) foi estudada neste trabalho, visando criar uma melhor prtica para o gerenciamento de projetos de TI para pequenas empresas de TI, com o principal objetivo de permitir uma concorrncia leal entre pequenas empresas de TI e empresas de mdio e grande porte do mesmo segmento. As pequenas empresas sofrem uma grande desvantagem em relao s empresas de mdio 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 adaptao do framework Scrum para utilizao 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 prtica e gil. Pode-se concluir que a adaptao do framework Scrum traz benefcios ao gerenciamento de projetos de TI de pequena empresa de TI, organizando de maneira prtica e simples sem a exigncia de documentao e treinamento extensivo. Focado em pessoas a adaptao provou ser bastante flexvel e adaptvel. Palavras-chave: Scrum.framework.pequena.empresa.TI

ABSTRACT The quality of Information Technologys (IT) small business projects were studied within this work, looking forward to create a best practice to managing ITs projects for ITs small business, with the main objective of allow a fair competition among an ITs 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 largesized 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 ITs projects of ITs 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 ILUSTRAES Figura 1: Figura 2: Figura 3: Figura 4: Figura 5: Figura 6: Figura 7: Figura 8: Figura 9: Figura 10: Figura 11 Figura 12: Fases do ciclo de vida de um projeto Stakeholders de um projeto Scrum incremental e iterativo Scrum incremental e iterativo Papis e responsabilidades Scrum Componentes que do forma ao item de Backlog Cartas de Planning Poker Jogando Planning Poker Exemplo de grfico Burndown Ciclo do Scrum na prtica Ciclo do Scrum em pequenas empresas de TI Burndown do Projeto de Monitoramento 18 20 27 28 31 37 39 40 42 44 52 55

LISTA DE TABELAS Tabela 1: Tabela 2: Product Backlog Projeto Monitoramento Product Backlog Projeto mudana de sistema 54 59

LISTA DE SIGLAS ACS ASD COBIT DSDM FDD ID ITIL IT PAF-ECF PDV PMBOK PO PMI RAD ROI TI XP Automao Comercial e Servios Adaptative Software Development Control Objectives for Information and Related Technology Dynamic Systems Development Method Feature Driven Development Identificao Information Technology Infrastructure Library Information Technology Programa Aplicativo Fiscal Emissor de Cupom Fiscal Ponto de Venda Project Management Body of Knowledge Product Owner Project Management Institute Rapid Application Development Return of Investiment Tecnologia da Informao Extreme Programming

SUMRIO

11 1 INTRODUO

O mercado de Tecnologia da Informao (TI) cresce continuamente e grande parte do seu crescimento se deve ao fato das empresas terem se estruturado nas razes de seus processos para produzirem com qualidade e quantidade superior. Nada disso seria possvel sem gerenciamento. Existem diversas melhores prticas para gerenciamento de projetos, dentre elas, as mais conhecidas so: 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 mdio e grande porte possuem recursos, tempo, dinheiro e claro, uma estrutura favorvel ao custo/benefcio de um gerenciamento de projetos com vasta documentao como PMBOK e ITIL, ao contrrio das pequenas empresas que precisam de organizao, mas no podem dispor grande esforo na documentao, pois o seu time reduzido e normalmente no 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 no somente projetos de desenvolvimento de sistemas, mas tambm a aplicao 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 mxima qualidade, menor custo e dentro do prazo planejado, adequando os processos do Scrum, que foi desenvolvido para gerenciamento de projetos de software.

1.2 ABRANGNCIA

Ser usada como base de estudo somente o Scrum, este trabalho no far comparaes 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, sero analisados os projetos da pequena empresa de TI, a ACS Automao Comercial antes e depois de serem gerenciados pelo Scrum.

1.3 JUSTIFICATIVA

Com o aumento da competitividade e a globalizao, cada vez mais as empresas precisam organizar-se e melhorar a qualidade de seus servios ou aumentar sua produo. Estas empresas crescem de forma desorganizada e com servios no gerenciados, de modo que no possuem um cronograma em relao implantao dos servios prestados e/ou entrega de produtos. Assim os seus clientes ficam sem uma previso da finalizao de seus projetos, acompanhando o servio conforme o que foi combinado verbalmente no fechamento do negcio. Este trabalho tem como principio ajudar estas empresas no gerenciamento de seus projetos, melhorando assim o nvel de qualidade de maneira prtica 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 prticas desta rea. No capitulo trs sero introduzidos os conceitos de metodologia, framework e o gerenciamento gil. No captulo quatro ser apresentado o framework Scrum com abordagem sobre seu tipo de gerenciamento, aplicaes e vantagens. No capitulo cinco ser apresentado um estudo de empresa de TI sem nenhum gerenciamento em seus projetos. No captulo seis ser descrita e aplicada o framework Scrum com seus resultados obtidos. No capitulo sete sero apresentadas as concluses com a pesquisa realizada, suas vantagens, desvantagens e pontos crticos 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 terico na gesto de projetos com suas definies tcnicas, suas caractersticas e fases do projeto. Com o foco de orientar e melhorar os projetos de TI em pequenas empresas.

2.1 FUNDAMENTOS DE GESTO DE PROJETOS

Gerenciamento de projeto uma arte, porque envolve gerenciamento de pessoas e requer habilidades de intuio para ser aplicado em situaes totalmente nicas para cada projeto.

2.1.1 Definio de projeto

Definio de projeto segundo o autor:

Projeto um empreendimento no repetitivo, caracterizado por uma seqncia clara e lgica de eventos, com inicio, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzidos por pessoas dentro de parmetros de tempo, custo, recursos envolvidos e qualidade. (VARGAS, 2007, p.5)

Partindo desta definio de projeto, compreendido que em quase todas as reas do conhecimento humano, pode-se encontrar um projeto desde a seqncia mais rstica de trabalho ao mais sofisticado, desde que se enquadre dentro desta definio.

15 2.1.2 Caractersticas de projeto

Embora todo projeto tenha suas particularidades e caractersticas prprias, os projetos tm caractersticas em comum, como temporalidade, individualidade de servio ou do produto, resultados exclusivos, integrao, escopo, tempo, custo, qualidade, recursos humanos, comunicao e riscos. Temporalidade no significa que o tempo para o projeto ser executado seja curto, mas sim que o projeto dever ter um incio, meio e fim, e o fim est associado diretamente ao objetivo do projeto, este somente chegar ao fim quando o projeto alcanar o seu objetivo ou a equipe de stakeholders conclua que no mais existir a necessidade deste projeto ou seu objetivo no poder ser alcanado. Individualidade do servio ou do produto produzido pelo projeto, caracterstica 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, servios ou resultados. Estas entregas exclusivas devem ser quantificveis, um item final ou item componente. Segundo o PMI (2004, p.10) cada projeto tem nove reas de conhecimento: 1. Gerenciamento de integrao: Descreve os processos e as atividades que integram os diversos elementos do gerenciamento de projeto; 2. Gerenciamento do escopo: Descreve os processos envolvidos na verificao de que o projeto inclui todo o trabalho necessrio, e apenas o trabalho necessrio, para que seja concludo com sucesso;

16 3. Gerenciamento de tempo: Descreve os processos relativos ao trmino do projeto no prazo correto. Definio de atividades, seqncia de atividades, estimativa de recursos da atividade, estimativa de durao da atividade, desenvolvimento do cronograma e controle do cronograma; 4. Gerenciamento de custos: Descreve os processos envolvidos em planejamento, estimativa, oramento e controle de custos, de modo que o projeto termine dentro do oramento 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 comunicaes: Descreve os processos relativos gerao, coleta, disseminao, armazenamento e destinao das informaes do projeto de forma oportuna e adequada; 8. Gerenciamento de riscos: Descreve os processos relativos realizao do gerenciamento de riscos em um projeto. Planejamento do gerenciamento de riscos, identificao de riscos, analise qualitativa de riscos, anlise quantitativa de riscos, planejamento de respostas a riscos e monitoramento e controle de risco; 9. Gerenciamento de aquisies: Descreve os processos que compram ou adquirem produtos, servios ou resultados, alem dos processos de gerenciamento de contratos. Ele consiste nos processos de gerenciamento de projetos: Planejar compras e aquisies, planejar contrataes, solicitar respostas de fornecedores, selecionar fornecedores, administrao de contrato e encerramento de contrato.

17 2.1.3 Gerenciamento de projeto

Gerenciamento de projetos a aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim de atender aos seus requisitos. (PMI, 2004, p.37) Esta tcnica aplicada em cada uma das cinco reas dos processos de gerenciamento de projetos; iniciao, planejamento, execuo, monitoramento/controle e finalizao, estas reas esto relacionadas entrei si e se aplicam de forma crescente com o desenvolvimento e andamento do projeto.

2.1.4 Benefcios do gerenciamento de projeto

Segundo Vargas (2003), o gerenciamento de projetos agrega diversos benefcios para o projeto, dentre estes se destacam: melhoria no controle do projeto, aumento no desempenho do projeto, reduo do tempo, reduo de riscos e melhor qualidade dos projetos. O gerente do projeto aplicar suas tcnicas e habilidades para manterse dentro do escopo, com o tempo compatvel 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 estratgicas com relao aos concorrentes, pois os projetos gerenciados que acompanham uma metodologia e uma estrutura definida, possuem uma previso de gastos, baseado em histricos, maior otimizao, alocao de recursos humanos e no humanos, alm da maior agilidade na tomada de deciso.

18 2.2 FASES DO CICLO DE VIDA DE UM PROJETO

Os projetos so compostos por fases que dependem da natureza do projeto, mas genericamente pode-se dividir um projeto em cinco fases: iniciao, planejamento, execuo, controle e finalizao. Estas fases so seqenciais e dependentes uma da outra. As fases no necessariamente contam com os esforos dos seus times ao mximo, pois o esforo do projeto segue uma curva, que atingir seu mximo durante a fase de execuo, fase na qual todos os esforos esto concentrados para atingir o objetivo do projeto. Na figura 1 a ilustrao apresenta onde est concentrado o maior esforo do projeto.

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

Fase de Iniciao. Est a primeira fase de projeto, nela identifica-se a necessidade ou falha que o projeto deve suprir quando o objetivo for alcanado.

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 Execuo. Nesta fase colocado em prtica tudo o que foi definido na Iniciao 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 Iniciao e Finalizao. Seu objetivo acompanhar, corrigir e controlar tudo que est sendo feito no projeto. Fase de Finalizao. Na ltima fase so finalizadas formalmente as atividades do projeto ou de uma fase. Nesta fase deve-se entregar o produto ou servio final. Dividindo os projetos em fase se tem benefcios no gerenciamento de seu projeto, independente do seu tipo. Com o ciclo de vida de um projeto se consegue ter uma melhor anlise do quanto o projeto avanou, 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 esforo. Entende-se como esforo, todos os recursos alocados ao projeto, como pessoas, equipamentos, dinheiro, complicaes 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 organizaes. Este grupo deve ter seus interesses afetados pelo projeto de forma positiva ou negativa. Sendo assim em um projeto de automao comercial pode-se destacar seus Stakeholders como: o contratante, a empresa contratada, os funcionrios da empresa contratada, os funcionrios da empresa contratante, os clientes da contratante, clientes da contratada. Mesmo quando esto 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 sero empregados em determinadas prticas. Esses processos so especficos para uma tarefa ou funo. De acordo com Tomhave (2005, p.9, traduo nossa) a definio de metodologia : Uma metodologia uma construo focada que define regras, prticas e procedimentos especficos para implementao ou execuo de uma funo ou tarefa especfica. Pode-se exemplificar a metodologia na maneira como uma empresa estipula seu horrio de trabalho. A maioria das pizzarias costumam abrir s 18:00h e fecham s 23:00h, mas o senso comum estabelece como horrio comercial o perodo entre s 08:00h at 18:00h, mas no caso das pizzarias no haveria o por que de abrir seu estabelecimento s 09:00h da manh. No faz parte dos costumes brasileiros comer pizza no caf da manh e por isso no h demanda para que as pizzarias abram no perodo matutino, tampouco no vespertino. Isso demonstra que cada empresa trabalha de seu jeito, fica a cargo dos tomadores de deciso avaliar o que melhor para a empresa e partindo de fatos e convices criam-se processos de uma determinada metodologia de trabalho. Esta metodologia vai definir o horrio de trabalho, definir que o controle de horrio dos funcionrios ser por leitura biomtrica ou por folha de ponto. Dentro da metodologia, existem os mtodos que so distintos em seus significados. O mtodo criado atravs da intuio, do saber e da experimentao e faz parte do processo de aprendizagem sem que o indivduo possua alguma informao prvia ao problema, cabe a metodologia reunir os mtodos e estud-los, transformando-os em uma abordagem prtica para solucionar problemas relacionados.

22 3.1 MANIFESTO GIL

Com o aumento da concorrncia e a busca de melhorias entre os servios e produtos, foram ficando cada vez mais comuns as metodologias e mtodos de gerenciamento de projetos. Todas elas com as mesmas caractersticas: muitos processos, muita burocracia e pouca praticidade. No ano de 2001 em um encontro com 17 desenvolvedores nos Estados Unidos da Amrica, 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 ns ou at mesmo ajudando outros a faz-lo. (SCHWABER et al. 2001, traduo nossa) Nasciam ento os doze princpios do Manifesto gil.
1. Nossa maior prioridade satisfazer o cliente, atravs da entrega adiantada e contnua de software de valor; 2. Aceitar mudanas de requisitos, mesmo no fim do desenvolvimento. Processos geis se adquam a mudanas, para que o cliente possa tirar vantagens competitivas; 3. Entregar software funcionando com freqncia, na escala de semanas at meses, com preferncia aos perodos mais curtos; 4. Pessoas relacionadas negcios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto; 5. Construir projetos ao redor de indivduos motivados. Dando a eles o ambiente e suporte necessrio, e confiar que faro seu trabalho; 6. O Mtodo mais eficiente e eficaz de transmitir informaes para, e por dentro de um time de desenvolvimento, atravs de uma conversa cara a cara; 7. Software funcional a medida primria de progresso; 8. Processos geis promovem um ambiente sustentvel. Os 5patrocinadores, desenvolvedores e usurios, devem ser capazes de manter indefinidamente, passos constantes; 9. Contnua ateno excelncia tcnica e bom design, aumenta a agilidade; 10. Simplicidade: a arte de maximizar a quantidade de trabalho que no precisou ser feito;

23
11. As melhores arquiteturas, requisitos e designs emergem de times autoorganizveis; 12. Em intervalos regulares, o time reflete em como ficar mais efetivo, ento, se ajustam e otimizam seu comportamento de acordo. (SCHWABER et al. 2001, traduo nossa)

Com um estudo sobre estes princpios do Manifesto gil, definiu-se que ser gil colocar em prtica os princpios 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 comunicao.

3.1.1 Metodologia gil

Metodologia gil uma denominao para metodologias que so leves na documentao de seus processos e que focam os princpios do Manifesto gil. Existem diversas metodologias quem empregam a definio do ser gil. (SCHWABER, 2004; SILVA, p.21, 2009) As metodologias mais conhecidas segundo Silva (2009) e UNB (2004) so: Adaptive Software Development (ASD) ou Desenvolvimento de Programa Adaptvel Principais caractersticas esto em ser iterativo e incremental, usado para sistemas grandes e complexos, cliente sempre presente para acompanhar o andamento do projeto. Dividido em trs fases. Especular, Colaborar e Aprender. (HIGHSMITH, 1999) Dynamic Systems Development Method (DSDM) ou Mtodo Dinmico de Desenvolvimento de Sistemas Utilizado para RAD (Rapid Application Development). Mantm fixo o tempo e recurso, ajustando apenas as funcionalidades do sistema. Aplicado em pequenas

24 equipes e aceitam mudanas de requisitos durante o ciclo de vida do projeto. Dividido em cinco fases: Estudo das Possibilidades, Estudo dos Negcios, Iterao do Modelo Funcional, Iterao de Projeto e Construo e Implementao 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, no oferece suporta documentao e tem forte embasamento na comunicao. Feature Driven Development (FDD) Metodologia gil e adaptvel tem o seu foco nas fases de desenho do projeto, trabalhos com desenvolvimento iterativo. Possui cinco processos principais: Desenvolver modelo compreensvel, 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 desperdcio. Est metodologia de gerenciamento de software visa concluir o desenvolvimento na primeira verso, pois evitando refazer o trabalho ter economia de recursos humanos e financeiro. (POPPENDIECK, 2003) Extreme Programming (XP) A metodologia XP formado com base nos princpios geis que nasceram no Manifesto gil, esta metodologia tem como valor, comunicao, feedback, respeito e simplicidade. O XP organiza os ciclos de iterao em perodos curtos, com a presena dos usurios assim possibilitando assim os usurios a se familiarizar e testar o software. (BECK, 2004)

3.2 DEFINIO DE FRAMEWORK

25

O termo metodologia empregado comumente com uma definio que no 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 prticas. O termo framework tem diversas tradues, mas todas elas levam ao significado de modelo genrico de alto nvel, que nos permite a construo de uma metodologia, baseado em processos e conceitos definidos. Essa metodologia criada a partir do framework tem um maior embasamento terico, 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 responsveis pelo projeto ao contrrio da metodologia que diz como ser feito e proporciona ferramentas prontas para serem usadas, no apenas um modelo. O benefcio do framework a capacidade de adaptao, j que seu mecanismo de gerenciamento no focado para uma tarefa ou funo especfica. Por definio framework : uma construo fundamentada que define suposies, conceitos, valores, prticas e que inclu um guia para ser implementado sozinho. (TOMHAVE, 2005, p.9, traduo nossa)

26 4 SCRUM

O Scrum destaca-se tanto pela maneira como emprega seus processos, como pela praticidade em aplicao de seu framework em processos bastante complexos. Os processos complexos podem ser empricos 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 no existe margem para o desconhecido. Pode-se exemplificar em uma viagem de avio, aonde o piloto sabe aonde deve chegar e como deve chegar, a rota est traada e no existem alternativas. Tudo planejado e previsto: durao de vo, hora de chegada, latitude do avio e condio climtica. Tais processos permitem um grau de impreciso, mesmo que pequeno, mas esta possibilidade somente vivel pelo nvel de informao existente sobre aquele fato. Apesar desse processo ser complexo, ele repetitivo e mesmo havendo mudanas climticas ou atraso no vo, 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 variveis fossem desconhecidas e o menor erro tivesse grande conseqncia, como em um desenvolvimento de software. Esta situao definida como: Controle de Processo Emprico, que permite o controle de processos complexos e imprevisveis, sendo necessrio analisar e reavaliar os processos no decorrer do projeto. Pode-se exemplificar o Controle de Processo Emprico em uma viagem de carro:

27 O motorista precisa percorrer o percurso do ponto A ao ponto B, mas dependendo do conhecimento, do trnsito, do pedgio e de outras variveis impossveis de se descobrir antes de comear a viagem, o motorista pode percorrer um caminho ou outro. Ele vai tomar suas decises durante a viagem. No existe uma rota traada, como ocorre em um avio. Alm de ser um Controle de Processo Emprico, o Scrum um framework gil, iterativo e incremental que se refaz em ciclos de realimentao, buscando organizar e aprimorar o mecanismo de trabalho e de seus usurios como possvel 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 no uma metodologia. O Scrum no vai resolver seus problemas, vai ajudar a identificlos e tambm no gerencia processos e sim pessoas.

4.1 CARACTERSTICAS DO SCRUM

O Scrum possu diversas caractersticas, a principal delas sua maneira iterativa e incremental de desenvolvimento. A explicao de iterativo e incremental pode-se relacionar com a compra de uma casa: O cliente compra uma casa que est comeando a ser construda. Ao invs de esperar a casa ser construda inteira, o cliente pode mudar-se, assim que a sala

29 estiver pronta. Nela haveria tudo, luz, gua encanada e moblia, os outros cmodos continuariam sendo construdos e o cliente poderia escolher ou no se construiria aquele cmodo de visitas ou no caso acreditasse no ser mais necessrio. O projeto seria imaginado como um todo desde o comeo, mas a cada fim de ciclo, seria entregue algo de valor e esta entrega estaria totalmente pronta para uso. (SCHWABER, 2004) O Scrum tambm possu seus papis e responsabilidades bem definidos, seus ciclos curtos para entrega rpida de produto com valor agregado permitem ao cliente avaliar o retorno de investimento, reunies dirias de 15 minutos e reunies ao final de cada ciclo servem para revisar ou inspecionar o desenvolvimento do projeto. (WOODWARD, 2010) Assim como em todos os projetos, no Scrum tambm existe uma lista de requisitos, nomeado de Product Backlog. Cada nova funcionalidade possu um carto que descreve brevemente seu objetivo e contm elementos chave para sua fcil identificao. Este carto uma ferramenta que o Scrum utiliza para auxiliar no desenvolvimento do projeto. Resumo de algumas caractersticas: Vision: a idia que o cliente tem do projeto pronto, aquilo que vai corresponder sua necessidade ou trazer algum benefcio, o retorno de investimento; Product Backlog: a lista de requisitos do projeto. Os requisitos ou itens de Backlog so alinhados pelo cliente e atravs de uma reunio s com a equipe, definido como ser entregue algo de valor at o fim do ciclo; Sprint Planning: a primeira reunio do Scrum e nesta reunio realizado o planejamento inicial de como ser o primeiro ciclo de trabalho, define-se junto com o cliente o que precisa ser feito, quais so as prioridades, visando entregar aps um ciclo curto de perodo um produto de valor agregado;

30 Sprint: o ciclo de trabalho do Scrum, existem vrias Sprints dentro de um projeto Scrum e tudo que for planejado ou revisado nas reunies feito pela equipe. Cada Sprint possui seu objetivo e a equipe no deve fazer nada no relacionado Sprint, para alterar ou acrescentar novas tarefas, no Scrum conhecidos como itens de Backlog, obrigatrio esperar o fim da Sprint; Burndown: Grfico que demonstra o tempo estimado e decorrido de acordo com as os itens de Backlog planejados para aquela Sprint. Pode-se criar tambm um Burndown para medir a produtividade da equipe; Time-box: Time-box um conceito que estabelece o tempo fixo, a caixa de tempo em traduo livre. O Scrum como framework permite flexibilidade em seus mecanismos, a melhor prtica pode recomendar que uma reunio dure quatro horas e que um ciclo de trabalho dure trinta dias consecutivos, mas cabe ao responsvel pelo projeto escolher incio, trmino e regularidade de cada ciclo, reunio 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 perodo de tempo no deve ser alterado e com isso o Scrum ensina a importncia em cumprir prazos e entregas regulares.

4.1.1 Vantagens do Scrum

O Scrum como framework possu algumas vantagens em relao aos mtodos de gerenciamento tradicionais: Controle de Processo Emprico possvel descobrir variveis desconhecidas no decorrer do projeto, tais variveis eram impossveis de serem previstas ou conhecidas no incio devido fatores que regem os processos complexos.

31 Mecanismo O mecanismo, as ferramentas e os papis do Scrum so simples, no necessrio grficos e tabelas complexos para descrever os processos, os papis dos envolvidos so fceis de entender tecnicamente, basta apenas uma pessoa com conhecimento suficiente para agregar os valores do Scrum aos envolvidos. Suas prticas so flexveis e adaptveis. Comunicao O foco so as pessoas e seu objetivo e ajudar na comunicao entre e equipe e cliente, permitindo que a equipe trabalhe sem interferncia e ao mesmo tempo possibilitar a satisfao do cliente atravs de encontros em pessoa.

4.1.2 Papis e responsabilidades

O Scrum define que os papis sejam bem claros e distintos. Cada papel tem sua funo e dificilmente os poderes podem ser impostos aos outros envolvidos. A figura 5 ilustra os Stakeholders em um projeto Scrum.

Figura 5 Papis 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 responsvel pela viso do negcio e por gerenciar conflitos de interesse do cliente. Cabe a ele estabelecer quais sero os itens a serem entregues em cada ciclo, qual prioridade ter cada item e atribuir aos itens valores de negcio para cada funcionalidade, estabelece as datas de entrega e contedo 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 importncia. Possu tambm a responsabilidade de aprovar ou desaprovar o resultado das entregas e responsvel em garantir a qualidade do produto. importante evitar a sndrome do PO Virtual (Product Owner) que acontece quando no se sabe quem deve ser o Product Owner: se ele deve ser o cliente, se deve ser algum interno da empresa ou externo da empresa por ter uma melhor viso do negcio, uma viso macro do projeto; quando ele no levado srio pela equipe ou no consegue atribuir um valor de negcio a funcionalidade. Vale lembrar-se da importncia 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 algum com grande experincia em Scrum, para assim aplicar os valores e prticas Scrum, cabe ao Scrum Master resolver todos os assuntos externos ao projeto. ele quem contorna situaes adversas como: funcionrios doentes, atraso na entrega e/ou desentendimentos na equipe. No o Scrum Master quem decide como as tarefas sero entregues ou feitas, isso papel da equipe e o Scrum Master no pode interferir. obrigao dele garantir a produtividade da equipe e colaborao entre os diversos papis e funes. ele quem conduz as reunies dirias 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 no tomem muito de seu tempo

33 contanto que haja disponibilidade para resolver impedimentos da equipe. No necessrio ser o lder tcnico ou gerente. Apenas em casos atpicos que o Scrum Master pode interferir na tomada de decises. 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 mdia com 5 a 10 pessoas. Sendo esta quantidade ideal de trabalho, podendo haver mais ou menos pessoas na equipe. A equipe auto-gerencivel e auto-organizvel. responsabilidade da equipe levantar seus impedimentos externos. Por exemplo: No possumos mquina capaz de realizar testes de validao do sistema X. A equipe no 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-gerencivel e autoorganizvel. muito comum as pessoas que desconhecem o Scrum no entenderem como uma equipe pode trabalhar sem ter um gerente ou alguma pessoa dizendo o que a equipe tem que fazer, porm 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 confiana, ao mesmo tempo que supre a necessidade de foco dos envolvidos no projeto. Um Product Owner no pode ditar como a equipe trabalhar, mas pode ditar quais sero 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 execuo do projeto que geralmente dura entre uma a duas semanas de acordo com a data que o Scrum Master definir. Na reunio de planejamento da Sprint so 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 pargrafo, 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 funo na equipe, o desenvolvedor faz tarefas de desenvolvedores e designer realiza tarefas de design. O mtodo de alocar um membro da equipe a cada tarefa importante, pois toda a equipe passa a conhecer melhor todas as funcionalidades do sistema, porm 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 rpido e eficaz.

4.1.4 Definindo o tamanho do Sprint

Um dos tpicos do planejamento do Sprint o tamanho do Sprint. Sempre fica a questo de qual seria o melhor tamanho para o Sprint. No Scrum no 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 favorveis que possibilitam a equipe ser mais gil, realize entregas mais rpidas, tenha uma resposta mais rpida para o cliente e no 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 invs de se preparar para apresentar o Sprint e o tempo que leva cada reunio 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 discusses 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 reunio 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 so convidados a participar da reunio, porm s a equipe, o Scrum Master e o Product Owner podem falar. Sua durao, horrio e local so firmados no planejamento da Sprint. O ideal que o Daily Scrum seja realizado no primeiro horrio da manh, em comum acordo com todos para no haver ausncias. Pode-se realizar Daily Scrums pela tarde, mas no prtico ter que trabalhar e lembrar o que falou que ia fazer ontem. O mais importante o que far e no o que fez. O Daily Scrum no serve para resolver problemas. Ele evita reunies desnecessrias e se baseia em trs 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 reunio dificilmente se estender, evitando o desgaste mental. Sua durao mdia deve ser de 15 minutos. (SCHWABER, 2004)

4.2 PRODUCT BACKLOG

O Product Backlog a lista de requisitos do projeto, ele compe os requisitos necessrios para a concluso do projeto e so previstos pelo Product Owner. No Scrum os requisitos so descritos pelo termo itens de Backlog. O Product Backlog deve traduzir a viso do projeto de termos de mercado para termos tcnicos e possu a caracterstica de mudar constantemente e atravs de seu processo emprico do Scrum, sua lista de requisitos alimentada antes do incio de cada Sprint. obrigao 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 cartes descrevendo cada item de Backlog como na figura 6.

37

Figura 6: Componentes que do forma ao item de Backlog (AUTORES, 2010)

Cada item de Backlog pode possuir os seguintes campos: ID (identificao): um nmero. Sua identificao importante para o controle de cada item, pois a mesma pode sofrer alterao de descrio. 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. Importncia: a importncia do item para o Product Owner, atribuda atravs de pontuao. Exemplo: 15 ou 120 o valor mais alto o mais importante. utilizada a pontuao com grandes intervalos, pois se surgir um item com maior importncia ou que sua importncia tenha sido subestimada a principio, pode-se reorganizar os itens sem utilizar pontuaes com mais de uma casa decimal.

38 Estimativa Inicial: So as estimativas da equipe sobre o tempo necessrio 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 trs homens quanto tempo levar para desenvolver um item. Se a resposta for quatro dias. Temos um item de 12 pontos. O importante no 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 explicao de como ser demonstrado o item na apresentao do Sprint. Fazer esta operao e verificar se a mesma foi alterada. Exemplo: entrar na configurao de produtos, alterar o valor do produto, verificar no relatrio de produtos se o valor foi alterado. Nota: Qualquer outra informao, que faa referncia a outra fonte de informao. Que seja breve e gil. No necessariamente obrigatrio 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, porm 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 alteraes, como por exemplo, alteraes 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 necessria para um projeto. Perdia-se muito tempo estimando, j que os envolvidos possuem habilidades, conhecimento e antepassados diferentes. Apesar de no ser um artefato prprio 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 nmeros que representam estimativas, estes nmeros so seqncias 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 seqncia Fibonacci. Existe toda uma anlise profunda sobre o efeito da ordem de grandeza na qualidade das estimativas, mas este tema no ser abordado neste trabalho (COHN, 2005). Uma carta simbolizada pela interrogao expressa a falta de conhecimento por parte do indivduo que est tentando estimar um item. A carta simbolizando um caf no encontrado em todos os designs de Planning Poker, mas significa uma pausa no jogo de estimativas. Deve-se usar o Planning Poker com o propsito de motivao e como auxlio para que at mesmo os indivduos mais quietos possam participar das estimativas. Em outros mecanismos de planejamento, difcil conseguir a participao de todos e com jeito de jogo, a equipe torna-se mais produtiva. Observa-se na figura 8 o nvel de participao 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 nmero com a estimativa de tempo para entrega daquele item. Assim que todos estiverem prontos, as cartas so viradas

41 demonstrando o pensamento de cada um. Ento se analisa o pensamento dos indivduos com a maior e menor estimativa atravs de um debate. O objetivo do debate no confrontar opinies e sim esclarecer pontos de vista. A idia estimar, no se deve perder muito tempo estimando cada item. Caso a equipe no 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 Grfico Burndown

Grfico Burndown uma das mais importantes ferramentas de gerenciamento de desenvolvimento de software, com ele possvel apresentar o trabalho restante em funo do tempo. Com o grfico Burndown pode-se medir o progresso do projeto e saber se est demorando muito para alcanar as metas estipuladas ou se os ciclos esto sendo finalizados com um trabalho de m qualidade. Na figura 9 permite observar o processo de evoluo do trabalho em funo do tempo, este tempo complemento para o final do prazo. A imagem abaixo mostra que a equipe no incio demorou muito para entregar os itens e quando perceberam no dia 29 de junho, comearam 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 grfico 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 excluso ou a incluso de novos itens de Backlog, que no estavam previstos no Sprint Planning.

4.3 SCRUM NA PRTICA

O fluxo do Scrum inicia-se com a viso do projeto, esta viso concebida pelo Product Owner, em mdia deve possuir um pargrafo ou dois que descreva a necessidade do projeto e os benefcios que este projeto trar aps sua concluso. Em colaborao a idia do projeto, o Product Owner formula um plano para alcanar seu objetivo que dividido em requisitos, esses requisitos so conhecidos como itens de Backlog e o conjunto deles constitui o Product Backlog.

43 Os itens de Backlog so priorizados pelo Product Owner, assim pode-se garantir a entrega dos itens que possuam maior valor de negcio para o fim da prxima Sprint. O Product Backlog evolu junto com o projeto e podem ser adicionados ou retirados itens de Backlog para que o projeto gerencie mudanas de acordo com o ambiente do projeto. Esse mecanismo de gerenciamento um Controle de Processo Emprico, o projeto sofre alteraes a cada inspeo no final de cada Sprint. No inicio do projeto realizada a Sprint Planning 1, reunio de planejamento que define os itens a serem realizados durante a prxima Sprint. Esta lista de itens conhecida como Sprint Backlog. A Sprint inicia-se assim que a equipe termina de definir o Sprint Backlog, aps isso todos os dias realizado o Daily Scrum. Ao final de cada Sprint so concebidas duas reunies: o Sprint Review que exibe aos Stakeholders e ao Product Owner o resultado daquela Sprint. O objetivo desta reunio ajudar a comunicao dos envolvidos e reavaliar as necessidades do cliente, os impedimentos em entregar as solicitaes dos Stakeholders, e para a equipe receber o retorno positivo e negativo do que foi realizado. A Sprint Review torna possvel 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 aps a Sprint Review, Scrum Master e a equipe interagem em uma reunio descrita por Retrospective Scrum que consiste em avaliar os processos e prticas Scrum para torn-los mais eficazes e agradveis para a prxima Sprint e ento o fluxo volta ao comeo e se tem incio uma nova Sprint. Abaixo na figura 10 ilustra-se o ciclo do Scrum.

44

Figura 10 Ciclo do Scrum na prtica. (CAVALCANTI, 2008)

45 5. ESTUDO DE PEQUENA EMPRESA DE TI SEM GERENCIAMENTO

A empresa ACS Automao 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 automao comercial em So Paulo. A ACS percebeu que havia uma grande defasagem nos servios prestados nesse ramo de atividade e assim est conquistando cada vez mais clientes com servios de qualidade e atendimento rpido, passando para seus clientes confiana nos servios executados, sempre trabalhando com muita clareza em relao aos seus servios. A automao comercial se faz necessria para agilizar os processos de venda e controle em geral, como em qualquer rea do conhecimento que atualmente utilizase 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 atravs de um sistema integrado, automatizado e seguro; garantindo a durabilidade, atomicidade e identidade da informao gerada ao longo do perodo de produo. Hoje a ACS Automao Comercial conta com uma equipe de 4 integrantes nas determinadas funes: Setor Administrativo: 1 funcionrio Setor Tcnico: 2 funcionrios Setor Comercial : 1 funcionrio

5.1 CARACTERISTICAS DA EMPRESA ACS

ACS presta servios direcionados a rea de automao comercial, atuando na implementao e manuteno de Pontos de Vendas (PDV) em empresas de varejo como: supermercados, lanchonetes, restaurantes, padarias, bares e lojas.

46 Disponibilizando sistemas especficos para cada estabelecimento e tambm executa todo o processo de venda, implementao e manuteno. A carteira de clientes da ACS proveniente em grande parte da indicao de outros clientes como da indicao de profissionais da rea que conhecem os servios da ACS. A ACS segue as seguintes etapas no processo de negcio: Pr-venda: A ACS verifica qual o ramo de atividade do cliente e quais os equipamentos necessrios para o estabelecimento, para assim, implementar o melhor sistema de acordo com as necessidades da empresa, fazendo com que o estabelecimento atenda com eficincia e agilidade seus clientes. Atravs de uma visita tcnica coletada informao sobre os processos rotineiros do estabelecimento como relatrios de fechamento e relatrios de produtividade. As vendas dos produtos da ACS so em sua maioria adquiridos por distribuidoras, j que no tem quantidade suficiente de vendas para adquirir os produtos diretamente com o fabricante, porm possui um valor de venda bem competitivo no mercado. Depois de concretizada a venda desenvolvido um oramento baseado na estrutura previamente analisada na pr-venda e em quais equipamentos o cliente ir precisar para a implementao. 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 servio de infra-estrutura (estrutura de cabeamento lgico e eltrico) da maneira mais adequada possvel. Assim que o cliente cumprir com as exigncias solicitadas para o ambiente de instalao, como preparar ou suprir condies fsicas de instalao de parte eltrica e lgica, dado inicio aos trabalhos de implementao. So realizadas as instalaes dos equipamentos, tanto os PDVs de Check-out quanto o equipamento gerenciador de retaguarda responsvel pela consolidao

47 dos PDVs e so feitas configuraes e testes. Depois de efetivada a instalao dos equipamentos se inicia a capacitao e treinamento dos futuros usurios, 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. Aps esse processo previsto de 2 a 3 dias para se concluir a instalao. At o momento a nica parte documentada de todo o processo o oramento, os demais processos de implementao so acordados verbalmente e no existe nenhum planejamento em relao ao processo como um todo. Por exemplo, ao iniciar a instalao, os funcionrios da ACS simplesmente trabalham em cima de seu conhecimento adquirido atravs de experincias anteriores e do mtodo tentar e errar at ser possvel a entrega de um produto que atende as necessidades do cliente. Tambm no h nenhum plano desenvolvido em relao ao treinamento do cliente. Aps a implementao dos servios, a ACS disponibiliza um telefone para dvidas e eventuais problemas e um celular de suporte para emergncias fora do horrio comercial.

48 5.1.1 Estudo da qualidade de projetos no gerenciados

No estudo de caso da empresa ACS Automao Comercial os projetos no so gerenciados, no feito um cronograma com data de inicio e fim de cada atividade realizada do projeto, o custo de cada atividade e tambm no entregue o resultado de cada atividade, somente ao final de cada projeto que so entregues os resultados e custos adicionais que no foram previstos e estimados no planejamento inicial. Com esta informalidade os projetos da ACS Automao Comercial, so normalmente negociados com carter emergencial (APNDICE A) que apresenta um modelo de projetos, com dialogo entre ACS e cliente.

49 6 ADAPTAO 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 alcanado seus objetivos, no importando porte, tipo, ambiente do projeto ou outros fatores dependentes de cada cenrio. Este trabalho em sua anlise com pessoas que trabalham diariamente com projetos de TI em pequenas empresas de TI apontou que vrios processos precisavam ser adaptados para que seja possvel manter o conceito do Scrum em um cenrio to distinto do normalmente apresentado. Existe uma grande diferena que separa a aplicao convencional do Scrum para desenvolvimento de software em relao 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 mdia meses e possu Sprints que acontecem a cada 30 dias consecutivos que possibilitam entre uma entrega e outra a inspeo de seus processos e das tarefas serem realizadas. Em um projeto que dure sete dias ao mximo, no se mostra vivel reunir-se para participar de uma reunio e perder um dia de trabalho. Os itens abaixo podem ser includos, alterados ou removidos dependendo do projeto e so definidos pelo Scrum Master. Sprint O primeiro processo adaptado o Sprint, pois a agilidade do Scrum no consegue acompanhar o ciclo de vida de um projeto de TI em uma pequena empresa de TI que possua em mdia cinco dias durao. No lgico dividir um projeto curto de 5 dias e transform-lo em cinco Sprints , perderia se mais tempo com as reunies nos

50 intervalos de cada Sprint, do que propriamente na execuo do trabalho. A inspeo ocorreria durante dois encontros dirios e ao final do projeto, aonde Product Owner, Stakeholders e equipe se reuniriam para validar o resultado do produto ou servio solicitado. Daily Scrum O Daily Scrum seria um mecanismo de inspeo mais presente, mantendo a durao de 15 minutos, realizada em p e ao invs de somente uma, haveria duas reunies dirias; Daily Review e Daily Retrospective. Grfico Burndown O grfico 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 no 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 recomear o projeto em questo. Product Backlog No existe necessidade de desenhar cartes para as funcionalidades dos itens de Backlog em um projeto de TI que no abrange desenvolvimento de software e cuja durao seja inferior a uma semana. Sprint Backlog Com uma s Sprint por projeto, talvez havendo duas caso na entrega o cliente no esteja de acordo, no h a necessidade de construir um Sprint Backlog, as tarefas j estariam estimadas e priorizadas para todo o projeto no prprio Product Backlog.

6.1 PAPES E RESPONSABILIDADES DO SCRUM ADAPTADOS

51

Product Owner O Product Owner continua representando o cliente ou sendo o prprio cliente. Scrum Master O Scrum Master alm de possuir suas responsabilidades originais do Scrum, tambm 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 alcanar suas metas, mas pela questo da motivao, 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 relao s seguintes especificaes: Tipo de projeto; Durao do projeto; Tamanho da equipe; Valor de negcio do projeto. De acordo com essas especificaes, 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 no utilizar nossa adaptao das melhores prticas para gerenciar projetos de TI em pequenas empresas de TI. O Scrum Master pode assumir o papel do Product Owner quando necessrio. Equipe Scrum A equipe Scrum continuaria sendo auto-gerencivel e auto-organizvel, tendo que apresentar suas funcionalidades prontas no prazo exigido. Ela por si prpria poderia alterar, adicionar ou remover os itens a serem realizados para que seja possvel alcanar o objetivo do projeto. As decises seriam avaliadas pelo Product Owner,

52 em casos que ele seja representado pelo cliente e o mesmo no 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 implantao no cenrio atual. Como ilustrado na figura 11.

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

Vision: uma reunio composta pelo Product Owner, Scrum Master e algum integrante do departamento comercial. Nesta reunio exposta a viso do projeto, o cliente apresenta uma viso que ir aprimorar seu negcio, 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 negcio e oferece uma soluo. Acceptance of Project: O cliente avalia a proposta e se estiver de acordo, fecha o contrato. Sprint Planning 1: Aps 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: reunio diria igual ao Daily Scrum, tendo como participantes a equipe e o Scrum Master. Daily Retrospective: reunio diria realizada no final do dia, contaria com a presena do Product Owner, Scrum Master e a equipe. Seu objetivo seria substituir as reunies de inspeo Scrum realizadas ao final de cada Sprint. O Daily Retrospective seria de 15 minutos e tambm possuiria trs perguntas bsicas que seriam respondidas individualmente pelos integrantes da equipe: O que foi feito ontem? O que ser feito amanh? O que foi mudado em relao ao planejamento inicial? Aps a equipe responder as perguntas, a reunio termina e o Product Owner pode alterar a prioridade dos itens caso considere necessrio, enquanto que o Scrum Master pode intervir se as alteraes do Product Backlog forem drsticas o suficiente para alterar o objetivo do projeto. Se isto acontecer, Scrum Master e Product Owner se renem para estruturar uma nova Vision para o projeto. Retrospective: a reunio no qual feito um balano 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 no seja alcanvel ou caso no haja mais necessidade do projeto, ele encerrado. Caso contrrio, o ciclo retorna para viso 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 fbrica de roupas na cidade de So Paulo. Vision O proprietrio desta fbrica de roupas necessita instalar cmeras em lugares estratgicos de sua empresa para monitoramento de seus funcionrios e seu foco monitorar o andar por completo retirando os pontos cegos. As imagens geradas pelas cmeras sero armazenadas em um servidor stand-alone. Ser necessrio estruturar uma redundncia para estes dados e treinamento para os usurios 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

Importncia Estimativa 1. Analisar infra-estrutura para implantar o sistema de monitoramento 2. Analisar quais so os tipos especficos de equipamentos necessrios para o monitoramento 3. Analisar parte eltrica para fornecimento de energia das cmeras e stand-alone 4. Analisar parte lgica para cabeamento das cmeras e stand-alone 5. Definir local para o stand-alone 6. Analisar tubulao existente no local 7. Identificar nmero de cmeras para monitoramento 8. Analisar nmero de pontos cegos no monitoramento e aplicar mtodo corretivo 9. Analisar condies de luz e alcance das cmeras 10. Analisar se rea da tubulao suficiente para a quantidade de fios lgicos e eltricos para as cmeras 11. Criar oramento para compra de materiais 2 5 2 3 4 1 1 4 3 3 3 1 2 1 1 1 1 1 1 1 1 1

55 Importncia Estimativa 12. Criar topologia do sistema monitoramento 4 1 13. Estruturar redundncia no armazenamento dos arquivos 5 1 14. Fazer a parte de cabeamento das cmeras, levando os 5 8 cabos at o local de cada cmera 15. Fixao de todas cmeras no local especifico de cada 5 4 cmera. 16. Configurao do posicionamento de cada cmera. 5 5 17. Configurao stand-alone 4 3 18. Treinamento dos usurios 3 2 Total 36h
Fonte: AUTORES (2010)

A partir da criao Product Backlog, foi criado o grfico 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 disfarando o Scrum. Utilizar seus conceitos de gerenciamento sem mencionar suas nomenclaturas. No deixando de seguir fielmente os processos do Scrum adaptado para projetos de TI em pequenas empresas de TI. A deciso foi motivada pela economia de tempo j que no foi necessrio treinar os envolvidos do projeto em Scrum. Bastou apenas definir claramente o horrio das reunies, 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 indivduos de que era necessrio cumprir os horrios e o Scrum Master trabalhou bastante, pois era sua obrigao ver o que estava sendo feito para garantir a qualidade das entregas e nos encontros dirios 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 reunies dirias tinham obrigao 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 no perdia tempo pensando em como deveria fazer ou o que deveria ser feito primeiro, alm de traduzir o contrato em requisitos e documentar as solicitaes 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 decises do Product Owner sempre que considerava as decises dele incoerentes, mas educadamente conversava com o cliente para encontrar o caminho certo e alcanar os objetivos do projeto de maneira gil e prtica.

57 Retrospective Ao final do projeto, todos se reuniram para analisar se o projeto havia atendido as expectativas. No foi necessrio 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 no 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 rpida. Concluiu-se que o Scrum adaptado trouxe mais benefcios do que dificuldades neste projeto.

6.3 ESTUDO DE CASO II: MUDANA DE SISTEMA SUPERMERCADO

Vision Necessidade de instalao 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 rgo pblico responsvel 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 homologao para suprir as necessidades exigidas pela PAF-ECF, entre estas a emisso da nota fiscal paulista segundo a Lei estadual 12.685/07. Com a alterao no sistema de frente de caixa, surge tambm a necessidade de alterao do software de gerenciamento de caixas, para obter maior velocidade, integridade e melhor gesto de negcio. Este sistema dever ser rpido para que ocorra a diminuio de filas, interface amigvel, possua controle de acesso e fornea relatrios gerenciais. A loja possui quatro caixas e ir permanecer com este nmero de caixas com o novo sistema.

58 No escritrio h dois computadores que tero que acessar o sistema gerenciador dos caixas. O sistema atual funciona com quatro impressoras, no fiscais, que no permite a impresso de cupom fiscal, somente recibo sem valor fiscal. Os caixas so compostos pelas seguintes caractersticas: a) Computador; b) Monitor; c) Gaveta de dinheiro; d) Impressora de recibo no fiscal; e) Leitor de cdigo de barra de mesa; f) Sistema operacional Windows Millennium Edition; g) No possuem servio de internet. Criao do oramento de venda O oramento segue com todos os itens e preo especificados (APNDICE 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 negcio para cada item. Abaixo segue a tabela 2 que apresenta o Product Backlog deste estudo de caso.

Tabela 2 Product Backlog Projeto mudana de sistema Item 1 2 3 4 5 6 7 8 Importncia Estimativa Descrio 10 Converso do banco de dados 1 9 Lacrar a impressora fiscal 3 8 Entrega dos equipamentos 10 7 Instalao do gerenciador dos caixas 2 6 Treinamento dos usurios do gerenciador 1 7 Treinamento dos usurios do caixa 1 6 Treinamento dos usurios do caixa 1 4 Acompanhamento de inaugurao do sistema 2 Total 21 dias Fonte: Autores (2010)

59

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, alm de garantir a qualidade da entrega realizada pela equipe. A durao 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 atribudo o papel de Product Owner. A execuo da Sprint no estabelecimento do cliente se iniciou no item 4 com a instalao do gerenciador de caixa. Foram realizadas as reunies dirias normalmente. Na reunio 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 execuo do item est de acordo com o estimado, foi realizada a instalao do sistema gerenciador dos caixas no servidor e habilitado o acesso nas duas mquinas exigidas que tenham acesso, tambm foi feita a importao 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 instalao com sucesso e tambm foi instalado um frente de caixa para testes de vendas com intuito de verificar os cdigos e

60 preos 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 usurios do sistema gerenciador dos caixas e tudo que foi alterado no cadastro de produto do sistema anterior j foi tambm 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 aps o fechamento da loja foram realizadas as instalaes 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, porm devido as boas entregas dos itens do Product Backlog, o Scrum Master junto com o Product Owner definiram ser desnecessrio 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 execuo da Sprint. Daily Retrospective Ao final de cada entrega de item durante os dias de execuo foi realizada a reunio na sede da empresa e no prprio 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 reunio final para verificar todos os itens do Backlog, nesta reunio todos os membros da equipe puderam avaliar o projeto inteiro, o Scrum Master foi o responsvel pela apresentao e integrao do Product Owner com a equipe. No final da Retrospective, o Product Owner efetuou a validao do projeto e assinou o aceite formal.

6.4 RESULTADO DO ESTUDO DOS CASOS

Dentro deste perodo foi analisada a melhor forma de adaptar o Scrum as pequenas empresas de TI em projetos de TI, com a mudana de estrutura que foi necessria implantar nos projetos estudados, para concluir est implantao. Obtive-se os seguintes resultados: Equipe Scrum teve grande facilidade nos treinamentos do Scrum, mas no conseguiram obter a mesma facilidade no uso dirio, pois a equipe trabalhava de forma tradicional com a necessidade do gerente para gui-los em suas funes. Product Owner teve resultados mais rpidos, pois com o mtodo de gerenciamento tradicional o cliente no tinha um feedback com tanta freqncia e nem conseguia acompanhar o andamento do projeto. Scrum Master dedicou o seu tempo integralmente na implantao do Scrum e maximizar os benefcios do projeto, sempre alinhado junto com o Product Owner. No projeto com a utilizao do Scrum no gerenciamento dos projetos da ACS, foi possvel uma melhora de qualidade de gesto de projetos, diminuio da carga de trabalho de cada integrante, com a juno destes itens foi possvel 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 no seja desviado da viso inicial.

62 6.4.1 Concluses sobre o estudo dos casos

Com a aplicao de Scrum neste contexto fora de desenvolvimento de software, foram encontradas diversas dificuldades em alcanar o resultado final, pois as equipes de cho de fbrica possuem grande de dificuldade em serem autogerenciveis e auto-organizveis, mas ambas as empresas puderam obter o mximo de seus servios, tanto a ACS quanta a empresa contratante podero maximizar os seus lucros e atingir os resultados com maior facilidade. No projeto de implantao do supermercado XY foi possvel alterar o Product Backlog, pois com o acompanhamento do Product Owner, e as reunies dirias no foram necessrias alm de acompanhar a inaugurao do sistema durante dois dias, um dia foi o bastante.

63 7 CONCLUSO

Concluiu-se que a adaptao do framework Scrum traz benefcios ao gerenciamento de projetos de TI de pequena empresa de TI, organizando de maneira prtica e simples sem a exigncia de documentao e treinamento extensivo. Focado em pessoas a adaptao provou ser bastante flexvel e adaptvel. Mesmo diminuindo o escopo tornou-se muito difcil desenvolver melhores prticas do Scrum adaptado, pois dependendo do cenrio, seu fluxo e/ou processos teriam que ser readaptados. Mesmo assim, esta adaptao 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 atravs do Product Backlog, o Product Owner mantinha contato dirio com o projeto e ouvia os pensamentos da equipe, de forma a permitir a incluso, alterao ou excluso de itens a serem entregues no decorrer do projeto. As reunies dirias dvidas por Daily Review e Daily Retrospective substitui os ciclos de inspeo que aconteciam ao final de cada Sprint em projetos de desenvolvimento de software. Nota-se vivel o uso do Scrum adaptado, pois no necessrio receber treinamento Scrum, para pratic-lo, basta um Scrum Master que ajude na compreenso de seus conceitos, alm de que o Scrum Master pode ou no utilizar as nomenclaturas do Scrum, ou seja, apenas ele saber da prtica do Scrum em determinado projeto. Com o uso do Scrum foi possvel 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 tambm que os estudos devero ter uma seqncia a fim de obter avanos com a comunidade cientifica, est continuidade poder ser alcanada nos trabalhos futuros sugeridos no capitulo seguinte.

64 7.1 TRABALHOS FUTUROS

Com a idia de continuidade deste trabalho sugere-se aprofundar a abrangncia da adaptao do framework Scrum para gerenciar todo tipo de projeto para todo tipo de pequena empresa, no somente projetos e empresas de TI, projetos de implantao, projetos para gerenciar a prpria empresa, seus funcionrios e projetos de expanso da empresa. Aprimorar os papis atribudos aos envolvidos no projeto, desenvolver outros ou adapt-los conforme a realidade em uma pequena empresa. Desenvolver um sistema que armazene um histrico 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 mdio de Sprints, modelos de Product Backlog e por fim manter um documento histrico da empresa.

65 REFERNCIA BIBLIOGRFICA BECK, Kent. Extreme Programming Explained: Embrace Change. 2. ed. Melbourne: Paperback, 2004. CAVALCANTI, Eric. SCRUM: Uma abordagem prtica. Recife: C.E.S.A.R., 2008. 1 v. Disponvel 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. Disponvel em: <http://www.dsdm.org/>. Acesso em: 28 out. 2010. CRISP. Planning Poker Cards. Disponvel em: <http://www.crisp.se/planningpoker>. Acesso em: 10 out. 2010. FAIAS JUNIOR, Luiz; GOMES, Andr Faria; SURJAN, Jakov Trofo. Pronto: Agile Project Management. Disponvel em: <http://pronto.bluesoft.com.br/>. Acesso em: 04 out. 2010. FERREIRA, Aurlio Buarque de Holanda. Novo Dicionrio do Aurlio. 2. ed. Rio de Janeiro: Nova Fronteira, 1986. FRIED, Jason. difcil trabalhar no local de trabalho. Revista poca: O Dom da Fria, So Paulo, n. 632, 25 jun. 2010. Disponvel em: <http://revistaepoca.globo.com/Revista/Epoca/0,,EMI150505-15259,00JASON+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. Disponvel 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. Disponvel <http://www.featuredrivendevelopment.com/>. Acesso em: 28 out. 2010. em:

66 MARTINS, Elaine; ROCHA, Camila R.; SOARES, Silvia C. M.. SCRUM: Processo de Desenvolvimento de Software. Disponvel em: <http://www.dcc.unicamp.br/~eliane/Cursos/MO409/Curso2003/Apresentacoes/Scru m.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. Produo de Software: Proposta para uma fbrica de software com qualidade e produtividade. Disponvel 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. Disponvel em: <http://falcon.secureconsulting.net/papers/Alphabet_Soup.pdf>. Acesso em: 27 set. 2010. PATTON, Jeff. Dont know what I want, but I know how to get it. Disponvel 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). Mtodo e Metodologia. Disponvel em: <http://www.pucrio.br/sobrepuc/depto/dad/lpd/download/metodologiaemetodos.rtf>. Acesso em: 04 out. 2010. SANTOS, Rildo F. Scrum Experience: O Tutorial SCRUM. 16. ed. So Paulo: Scribble, 2009. 1 v. Disponvel em: <http://www.scribd.com/doc/16983386/ScrumExperience-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. Disponvel em: <http://www.manifestoagil.com.br/>. Acesso em: 05 maio 2010. SILVA, Tiago de Farias. Compondo Mtodos geis de Desenvolvimento. 2009. 81 f. Tese (Bacharel) - Curso de Cincia da Computao, Departamento de Centro de

67 Informtica, Universidade Federal de Pernambuco, Recife, 2009. Disponvel em: <http://www.cin.ufpe.br/~tg/2009-1/tfs.pdf>. Acesso em: 10 nov. 2010. UNB, Universidade de Braslia. O que uma metodologia gil? Disponvel em: <http://www.redes.unb.br/material/ESOO/Metodologias%20%C1geis.pdf>. Acesso em: 10 nov. 2010. VARGAS, Ricardo. Gerenciamento de Projetos. 7. ed. So 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 APNDICE A - EXEMPLO DE PROJETO DA ACS Mudana de Sistema Retaguarda (Gerenciador dos caixas de Supermercado) e PDV para Supermercado. O dilogo abaixo expressa claramente o cenrio atual: Cliente: No estou satisfeito com o meu sistema, o que pode me oferecer? ACS: Vamos agendar uma visita para demonstrao de nosso sistema? Cliente: OK pode vim amanh s 08:00h? ACS: Est combinado. Na visita verificado como o cliente trabalha, quais controles so utilizados e ento realizada a demonstrao. Cliente: OK! isso que preciso! Mande um oramento com urgncia para darmos incio a virada do sistema. ACS: J temos o oramento feito, quando podemos fazer uma reunio para apresentar o oramento? Cliente: Pode ser amanh s 08h00minh? ACS: Est Combinado. ACS: Aqui est o oramento os custos de instalao, mensalidade do sistema e equipamentos necessrios 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 converso do banco e depois instalamos. Cliente: Ok, faa o mais rpido possvel. ACS: Certo, vamos conversando, ir agilizar. O prximo procedimento enviar o banco de dados para o programador do sistema converter para o banco do novo sistema. Aps isso um tcnico visita o local para

69 instalar o Sistema Retaguarda e conferir com o cliente a relao de produtos cadastrados, feito isso iniciado a instalao do sistema de frente de caixa. Atividades executadas no projeto: Converso do banco de dados; Instalao e configurao do sistema; Treinamento dos operadores de caixa; Treinamento dos Fiscais de caixa; Treinamento do gerente da loja; Treinamento dos usurios do gerenciador dos caixas; Acompanhamento de inaugurao. O projeto todo realizado atravs da experincia em implantao de sistema do tcnico responsvel com prazo de entrega dado em relao a outras instalaes do mesmo nvel de dificuldade.

70 APNDICE B PROPOSTA COMERCIAL PROJETO MONITORAMENTO

So Paulo, 10 de setembro de 2010.

Projeto de Monitoramento

Assunto: Oramento de Venda. EMPRESA: Automao Comercial e Servios LTDA ME. ENDEREO: Rua Luis Dumont Villares, 1030. CEP: 02085-100 MUNICPIO: So Paulo ESTADO: SP CNPJ: 10.603.263/0001-49 FONE: (11) 2976-3900

1 - ESCOPO DOS SERVIOS. 1.1. Informaes Obtidas no Local. Estivemos em visita ao local, tomando conhecimento do escopo dos servios cujo detalhamento segue abaixo.

1.1. Descrio dos Servios. 1.1.1. Cabeamento e instalao O cliente deseja instalar 16 cmeras. Conforme figura abaixo:

Layout da rea para monitoramento

71

72 2 - Responsabilidades.

2.1. Responsabilidades da Contratada

- Fornecimento de mo-de-obra qualificada e auxiliar; - Fornecimento de E.P.I.(s) para nossos funcionrios; - Fornecimento de refeies para nossos funcionrios; - Fornecimento de transporte para nossos funcionrios; - Superviso tcnica da obra; - Fornecimento de quantificao de materiais.

2.2. Responsabilidades da Contratante

- Fornecimento de sanitrio de campo e vestirio para o uso de nossos funcionrios; - Liberao dos locais, onde sero realizados os trabalhos, inclusive em horrios extraordinrios. - Fornecimento de todos os materiais de aplicao e consumo. - Fornecimento de equipamentos de elevao e transporte.

3 - Cronograma. O prazo para a execuo dos servios de cmera de 05 (cinco) dias.

73 4 - Condies Comerciais. 4.1- Valor da Proposta. Item Descrio 1 STAND ALONE 16 CANAIS VD16E240 C/HD INTELBRAS - ISEC INTELBRAS CFTV com HARD DISK 1,5 TB SATA SEAGATE INFORMTICA 2 MINI CAMERA DAY/NIGHT VM320 420 LINHAS CCD SONY 1/3 INTELBRAS - ISEC INTELBR FONTE 12V 600MA C/PLUG - FRELUX - N/D SECURITY CAIXA DE PROTECAO ANODIZADA JUNIOR+SUPORTE 8,5CM MITSUPAK MITSUPAK Cabo Coaxial Conector BNC Eletroduto 3x4 (3 metros) Suporte para eletroduto Caixa de passagem 3x4 Conector do eletroduto un 01 R$3.000,00 R$ 3.000,00 Unid. Qtde V. Unit. V. Total

un

16

R$ 165,00

R$660,00

un

16

R$ 23,00

R$ 92,00

un

16

R$ 36,00

R$ 144,00

5 6 7 8 9 10

mt un un un un un

1920 16 30 60 20 40

R$ 2,50 R$ 20,00 R$ 18,00 R$ 1,20 R$ 7,20 R$ 3,80

R$ 650,00 R$ 60,00 R$ 450,00 R$ 72,00 R$ 108,00 R$ 152,00

74 11 12 13 14 15 16 17 18 Curva do eletroduto Bucha e parafuso Tampa cega Silicone Tampa PVC 3/14 Mo de Obra Mo de Obra Gesso Tinta branca un un un un un un un un 10 01 20 02 60 16 01 01 TOTAL R$ 3,50 R$ 45,00 R$ 5,20 R$ 21,00 R$ 1,20 R$250,00 R$370,00 R$ 150,00 R$28,00 R$45,00 R$78,00 R$42,00 R$54,00 R$ 1.000,00 R$ 370,00 R$ 150,00 R$7.155,00

4.2. Condies de Pagamento. R$ >> A titulo de Sinal R$ >> 30 dias

5 - CONSIDERAES 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 eltrica e isso acarretar interferncia na imagem da cmera, favor confirmar se no haver problemas quanto a instalao deste eletroduto.

6 REAJUSTE DE PREOS. Dentro do prazo determinado para a execuo dos servios, consideramos nossa proposta como fixa.

75 7 SERVIOS ADICIONAIS. Para o caso de servios adicionais a esta proposta, ser elaborada proposta de aditivo, sendo os servios somente executados aps a aprovao da mesma.

8 VALIDADE DA PROPOSTA. Esta proposta vlida por 10 (dez) dias, a partir dos quais solicitamos a confirmao das condies da mesma, antes de consider-la como vlida. Sendo o que nos apresenta, ficamos a disposio para dirimir eventuais duvida

76 GLOSSRIO Fibonacci: Um nmero na seqncia Fibonacci gerado atravs da soma dos dois nmeros anteriores. (COHN, 2005, p.52, traduo nossa) Manifesto gil: No ano de 2001 em um encontro com 17 desenvolvedores nos Estados Unidos da Amrica, 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 ento os doze princpios do Manifesto gil. (SCHWABER, et al. 2001). Metodologia. [do gr. metodos, 'metodo', + -log (o) + ia.] S. f.. 1. A arte de dirigir o esprito na investigao da verdade. 2. Filos. Estudo dos mtodos e especialmente dos mtodos da cincia. Mtodo. [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 srie de operaes que se devem realizar, apontando erros evitveis em vista de um resultado determinado (esperado). 4. Modo de proceder; maneira de agir; meio. (Novo Dicionrio do Aurlio, 1986) Projeto: Projeto um empreendimento no repetitivo, caracterizado por uma seqncia clara e lgica de eventos, com inicio, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzidos por pessoas dentro de parmetros de tempo, custo, recursos envolvidos e qualidade. (XAVIER, 2002) Scrum: traduo: luta pela bola numa jogada de rgbi. (Michaelis Moderno Dicionrio Ingls, 2010)

ANEXO A DEFINIES DO SCRUM Item Daily Scrum Descrio

77

O Daily Scrum um mecanismo de inspeo mais presente, mantendo a durao de 15 minutos, realizada em p O grfico 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 no seria capaz de ajudar tanto quanto esperado. Lista de requisitos, nomeado de Product Backlog. Cada nova funcionalidade possu um carto que descreve brevemente seu objetivo e contm elementos chave para sua fcil identificao. Lista de requisitos do projeto. Os requisitos ou itens de Backlog so alinhados pelo cliente e atravs de uma reunio s com a equipe, definido como ser entregue algo de valor at o fim do ciclo Pessoa responsvel por gerenciar o Product Backlog e criar o maior retorno de investimento possvel com o projeto. Product Owner representa o cliente. Reunio no qual feito um balano dos itens entregues e dos itens solicitados, indicando se a necessidade foi atendida pelo projeto ou se precisa continu-lo.

Grfico Burndown

Itens do Product Backlog

Product Backlog

Product Owner

Retrospective Scrum

Sprint Planning

Reunio 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 so as prioridades, visando entregar aps um ciclo curto de perodo um produto de

78 valor agregado. Scrum Melhores prticas de gerenciamento de projetos comumente aplicado em projetos de desenvolvimento de software. Seu foco so as pessoas e no os processos. Se vale de ciclos curtos, possu um controle de processo emprico e iterativo e incremental. Pessoa com grande experincia em Scrum, para aplicar os valores e prticas Scrum, cabe ao Scrum Master resolver todos os assuntos externos ao projeto. o ciclo de trabalho do Scrum, existem vrias Sprints dentro de um projeto Scrum e tudo que for planejado ou revisado nas reunies feito pela equipe. Lista de tarefas a serem entregues durante cada Sprint.

Scrum Master

Sprint

Sprint Backlog

Stakeholder

Envolvidos no projeto, este grupo pode ser formado por pessoa e organizaes. Este grupo deve ter seus interesses afetados pelo projeto de forma positiva ou negativa. O terceiro papel do Scrum a equipe, composta de maneira heterognea, a fim de suprir as mais diversas necessidades do projeto

Equipe Scrum