POSEAD - Turma 10-2009 - Monografia - Nicholas Paiva

UNIVERSIDADE GAMA FILHO POSEAD EDUCAO A DISTNCIA

IMPLANTAO E AVALIAO DOS RESULTADOS DO FRAMEWORK SCRUM PARA O GERENCIAMENTO DE TAREFAS NO AMBIENTE DO SETOR DE SUPORTE TCNICO DE TECNOLOGIA DA INFORMAO DO SETURN/NATALCARD, APS A IMPLANTAO DA BILHETAGEM ELETRNICA

NICHOLAS A. M. DA S. PAIVA

NATAL RN 2010




Monografia apresentada ao curso de ps-graduao distncia, Lato Sensu, da Universidade Gama Filho, como requisito parcial para a concluso do curso de Especializao em Engenharia de Software.

Natal - RN 2010




Projeto pela banca examinadora, constituda pelos signatrios abaixo relacionados, tendo obtido neste trabalho mdia _______.

Banca de Avaliao

_______________________________ xxxxx Examinador Professor Orientador

_______________________________ xxxx Examinador Professor Convidado

_______________________________ xxxx Examinador Coordenador do Curso

AGRADECIMENTOS Agradeo ao DEUS de Israel pela misericrdia e amor infinitos; a minha esposa e filha, a meus pais e irmos, a familiares e amigos.

DEDICATRIA Ao DEUS de Abrao, Jac e Davi.

RESUMO

O presente trabalho apresenta um estudo de caso sobre a implantao do framework SCRUM no setor de suporte tcnico de tecnologia da informao (STTI) do SETURN Sindicato das Empresas de Transportes Urbanos de Passageiros do Municpio do Natal/RN, aps a implantao da Bilhetagem Eletrnica. Com o advento da Bilhetagem Eletrnica, a complexidade dos servios do STTI cresceu severamente e novos processos, metodologias e frameworks precisavam ser adotados. Um dos escolhidos foi o SCRUM. Relatar e analisar como o SCRUM foi implantado em meio s mudanas promovidas pela Bilhetagem Eletrnica, qual seu impacto na formao do novo time de suporte tcnico de TI, quais customizaes teve que receber e, finalmente, qual a percepo dos clientes na entrega dos servios de TI aps o SCRUM, constituem os principais pontos apresentados nesse trabalho.

LISTA DE FIGURAS

Figura 1 - Ciclo de Funcionamento do SCRUM ................................................................... 18 Figura 2 - Grfico Sprint Burndown ...................................................................................... 20 Figura 4 - Quadro de Tarefas SCRUM/Exemplo 02 ............................................................. 23 Figura 3 - Quadro de Tarefas SCRUM/Exemplo 01 ............................................................ 23 Figura 5 - Quadro de Tarefas SCRUM/Exemplo 03 ............................................................. 23

SUMRIOSUMRIO ................................................................................................................................................................ 8 1. INTRODUO ..................................................................................................................................................... 9 1.1. APRESENTAO DO PROBLEMA ................................................................................................................. 9 1.2. REVISO DA LITERATURA ........................................................................................................................... 10 1.3. JUSTIFICATIVA .............................................................................................................................................. 11 1.4. OBJETIVOS .................................................................................................................................................... 12 1.4.1. GERAL ......................................................................................................................................................... 12 1.4.2. ESPECFICOS ............................................................................................................................................. 12 1.5. DESCRIO DOS CAPTULOS..................................................................................................................... 12 2. REFERENCIAL TERICO................................................................................................................................. 14 2.1. SCRUM E MTODOS GEIS ........................................................................................................................ 14 2.2. PRINCIPAIS ELEMENTOS DO SCRUM ........................................................................................................ 15 2.3. PRINCIPAIS PAPIS EM UM TIME SCRUM ................................................................................................. 15 2.4. FUNCIONAMENTO DO SCRUM .................................................................................................................... 16 2.4.1. VISO GERAL ............................................................................................................................................. 16 2.4.2. A REUNIO DAILY SCRUM (DAILY SCRUM MEETING) ........................................................................... 18 2.4.3. O PRODUCT BACKLOG ............................................................................................................................. 19 2.4.4. O PRODUCT OWNER ................................................................................................................................. 19 2.4.5. A ESCOLHA DE TAREFAS PARA O SPRINT BACKLOG .......................................................................... 20 2.4.6. A REUNIO DE PLANEJAMENTO DO SPRINT (SPRINT PLANNING MEETING) .................................... 21 2.4.7. A REUNIO DE REVISO DO SPRINT (SPRINT REVIEW MEETING) ..................................................... 21 2.4.8. QUADRO DE TAREFAS SCRUM ................................................................................................................ 22 3. DESCRIO DO CENRIO DO SUPORTE TCNICO DE TI DO SETURN: ANTES E APS A BILHETAGEM ELETRNICA ........................................................................................................................................................ 24 3.1. A BILHETAGEM ELETRNICA NO MUNICPIO DE NATAL ......................................................................... 24 3.2. DESCRIO GERAL DO PROCESSO DE BILHETAGEM ELETRNICA .................................................... 25 3.3. DESCRIO DAS FUNES DO SUPORTE TCNICO DA TI (STTI) DO SETURN: ANTES E DEPOIS DA BILHETAGEM ELETRNICA ................................................................................................................................ 27 3.3.1. FUNES DO STTI ANTES DA BILHETAGEM ELETRNICA.................................................................. 27 3.3.2. FUNES DA TI APS A IMPLANTAO DA BILHETAGEM ELETRNICA........................................... 30 3.4. REFORMULAO DA EQUIPE E IMPLANTAO DO SCRUM PARA GESTO DE TAREFAS DE TI ....... 32 3.4.1. CUSTOMIZAO DO SCRUM PARA O SETOR DE SUPORTE TCNICO DE TI DO SETURN .............. 33 4. ANLISE DOS RESULTADOS .......................................................................................................................... 36 5. CONSIDERAES FINAIS ............................................................................................................................... 37 5.1. APRESENTAO DOS PRINCIPAIS OBJETIVOS ATINGIDOS E SUAS SOLUES ................................ 37 5.2. PRINCIPAIS CONTRIBUIES ..................................................................................................................... 38 5.3. ASPECTOS POSITIVOS E NEGATIVOS ....................................................................................................... 38 5.4. TRABALHOS FUTUROS ................................................................................................................................ 39 REFERNCIAS ..................................................................................................................................................... 41

1. INTRODUO 1.1. APRESENTAO DO PROBLEMA Em Outubro de 2007, deu-se incio ao processo de implantao da Bilhetagem Eletrnica (BE) na cidade de Natal, capital do Rio Grande Norte. Envolvidos nesse processo, estavam uma frota de 800 nibus, 07 empresas de transporte pblico, 11 postos de venda de vales-transporte e passes-estudantis (tickets em papel), uma Central de Processamento e Controle localizada no SETURN (Sindicato das Empresas de Transportes Urbanos de Passageiros do Municpio do Natal) e outra, no rgo gestor (SEMOB Secretaria de Mobilidade Urbana, subordinada ao poder pblico municipal). Todos esses elementos, do incio do ano de 2006 at o ms e ano de implantao, receberam novos parques de hardware e software, pessoas e processos, concretizando, assim, a implantao do projeto. Dentre todas as equipes envolvidas com a nova realidade da BE, certamente a de suporte tcnico de tecnologia da informao (STTI) do SETURN foi a mais afetada. O que antes se resumia ao atendimento de suporte tcnico de informtica a 11 postos de venda de tickets em papel e Central de Processamento e Controle do SETURN, tornou-se um sistema complexo, totalmente depende da tecnologia para seu funcionamento (os tickets em papel foram substitudos por cartes com crditos eletrnicos). A complexidade dos servios de TI cresceu drasticamente, o que exigiu a busca, escolha e implantao de novas ferramentas, metodologias e mtodos para esse setor. Um dos frameworks implantados foi o SCRUM. Quase trs anos aps a implantao do SCRUM, uma pesquisa de satisfao foi realizada com os clientes internos do SETURN, com relao aos servios prestados pelo STTI. Os resultados foram positivos, demonstrando a eficcia do framework, apesar do aumento da complexidade advindo com a Bilhetagem Eletrnica.

9

1.2. REVISO DA LITERATURA O framework SCRUM baseia-se nas metodologias geis de

desenvolvimento de software, cujos princpios foram formalizados atravs do Manifesto gil, publicado na Internet em 2001 (www.agilemanifesto.org ).Presentes na elaborao desse Manifesto estavam trs dos principais autores desse framework: Mike Beedle, Ken Schwaber e Jeff Sutherland. Mike Beedle considerado um veterano na rea de desenvolvimento de software. fundador e CEO da Architects Inc.. Ele j contribui com a melhoria de milhares de produtos de software nos ltimos 20 anos, usando, recomendando e treinando outros no framework SCRUM. Ken Schwaber presidente da Advanced Development Methods (ADM), uma empresa dedicada melhoria na prtica de desenvolvimento de software. um experiente desenvolvedor de software, gerente de produto e consultor na rea industrial. Ele participou da revoluo no processo de gerenciamento de produtos, no incio dos anos 90s. Tm desenvolvido forte parceria com Jeff Sutherland no aperfeioamento do uso do SCRUM no processo de desenvolvimento de software. Jeff Sutherland iniciou seus trabalhos com SCRUM na Easel Corporation, em 1993. Ele, juntamente com Ken Schwaber, lanaram o SCRUM como um processo formal no OOPSLA, em 1995. Ele chairman do SCRUM Training Institute e CEO da SCRUM Inc. consultor snior da OpenView, prestando consultoria a empresas de grande porte, dentre as quais: Google, Yahoo, Microsoft, IBM, Oracle, MySpace, Adobe, GE, Siemens, BellSouth, GSI Commerce, Ulticom, Palm, St. Jude Medical, DigiChart, RosettaStone, Healthwise, Sony/Ericson, Accenture, Trifork, Systematic Software Engineering, Exigen Services, SirsiDynix, Softhouse, Philips, etc. Como fonte complementar, vrios sites e autores nacionais foram consultados, a saber:

I.

Fbio Cmara, autor de mais de 15 livros nos ltimos dez anos, tendo em seu vasto currculo de certificaes a de CERTIFIED SCRUM MASTER;10

II.

Guilherme Chapiewski, desenvolvedor de software, Engineering Manager do grupo Yahoo!, palestrante e evangelista do desenvolvimento gil de software;

III.

Heron Vieira Aguiar, Consultor Snior da SWQuality Consultoria e Sistemas, onde coordena diversos projetos de consultoria na implantao de SCRUM e CMMI/MPS.BR, combinados com SCRUM. Realizou diversos cases de sucesso em melhoria de processo de software em todo o Brasil. tambm Certified Scrum Master, graduado em Cincia da computao, ps-graduado em Melhoria de Processo de Software, mestre em Cincia da Computao pela UFPE e avaliador e implementador do modelo MPS.BR e consultor CMMI.

1.3. JUSTIFICATIVA Segundo a NTU (2010), a Bilhetagem Eletrnica no transporte pblico por nibus j uma realidade em muitas cidades brasileiras. O modelo de implantao certamente foi similar em todas as capitais, cabendo ao setor de suporte de TI do rgo responsvel pela implantao gerenciar toda a nova complexidade advinda com a bilhetagem. Descrever como o SCRUM foi implantado no setor de suporte de TI do SETURN, aps a implantao da Bilhetagem Eletrnica em Natal/RN, suas adaptaes, processos e papis, as conseqentes mudanas na equipe de TI e os impactos dessa implantao sobre clientes internos, certamente ajudar vrias outras equipes de suporte de TI que esto vivenciando uma realidade prxima, permitindo-lhes um estudo de caso rico em experincias prticas, fonte imprescindvel para as mudanas necessrias que precisam ocorrer para a consolidao do processo de bilhetagem eletrnica em suas cidades.

11

1.4. OBJETIVOS 1.4.1. GERAL Esse trabalho objetiva descrever como ocorreu a implantao do framework SCRUM no setor de suporte tcnico de TI (STTI) do SETURN, aps a implantao da Bilhetagem Eletrnica, e como, apesar do aumento da complexidade dos servios de TI, a qualidade na prestao de servios aos clientes internos foi mantida.

1.4.2. ESPECFICOS I. Descrever o funcionamento do STTI do SETURN antes da implantao da Bilhetagem Eletrnica; II. Identificar os novos processos de TI inseridos no SETURN aps a implantao da Bilhetagem Eletrnica; III. Descrever como os novos processos de TI aumentaram a complexidade do STTI, exigindo sua completa reformulao; IV. Relatar como implantao do framework SCRUM foi fundamental para a gesto dessa complexidade, permitindo manter a qualidade no atendimento desse setor, aos seus clientes internos. V. Descrever os processos, papis e adaptaes realizadas no SCRUM para a sua implantao no STTI do SETURN, alm da mudana provocada por essa nova realidade na equipe desse setor.

1.5. DESCRIO DOS CAPTULOS O Captulo 1 apresenta o problema proveniente do aumento da complexidade da TI aps a implantao da Bilhetagem Eletrnica na cidade de Natal/RN: o setor de suporte tcnico de TI (STTI) do SETURN passou a executar uma srie de novos servios, e sua equipe e ferramentas de gesto de tarefas certamente no seriam mais eficazes aos seus clientes internos. Algo precisava ser feito. A resposta veio com a implantao de novos mtodos, metodologias e frameworks. Um deles foi o SCRUM. Ainda nesse captulo, encontram-se os12

objetivos geral e especficos do trabalho, alm dos autores consultados sobre o tema SCRUM. O Captulo 2 traz o referencial terico utilizado para o entendimento do SCRUM. O trabalho descreve um CASE de implantao do SCRUM em um setor de suporte tcnico de TI e, portanto, traz mais aspectos prticos que tericos. Mas apesar disso, foi necessrio um forte embasamento terico at se decidir pelo SCRUM, customiz-lo e implant-lo no setor de TI do SETURN. Neste ponto, so apresentados os principais conceitos, papis, processos e princpios do SCRUM, com base nos principais autores da atualidade. O Captulo 3 descreve os cenrios anterior e posterior implantao da Bilhetagem Eletrnica no setor de suporte tcnico de TI do SETURN. O objetivo do captulo apresentar o severo aumento da complexidade dos servios de TI aps a implantao da BE. Aps isso, passa-se a descrever como o framework SCRUM foi customizado e implantado no SETURN, apresentando as mudanas que foram necessrias ocorrer nos processos e equipes de TI, bem como a percepo do cliente interno em relao qualidade dos servios de TI aps o SCRUM, atravs de uma pesquisa de satisfao do cliente. O Captulo 4 analisa as mudanas que precisaram ser feitas no time de TI para a implantao do SCRUM, principalmente com relao a processos e pessoas. Um novo esprito de equipe precisou ser entendido e absorvido pelo STTI, alm da nova metodologia de trabalho promovida pelo SCRUM. Os encontros matinais dirios, as revises ao final de cada Sprint, a deciso do que fazer tomada pela equipe e no exclusivamente pelo lder, a definio das prioridades de cada tarefa e a participao do cliente interno em todo o processo. Enfim, faz-se uma anlise detalhada dos impactos da implantao do SCRUM na equipe de TI e nos clientes internos de seus servios. O Captulo 5 expe as principais contribuies do trabalho, pontos positivos e negativos observados durante a implantao do SCRUM, enfim, as lies aprendidas durante o amadurecimento da Bilhetagem Eletrnica. Conclui-se o captulo com idias sobre os prximos passos do setor de suporte tcnico de TI do SETURN, na busca pela excelncia na prestao de servios aos seus clientes internos.13

2. REFERENCIAL TERICO 2.1. SCRUM E MTODOS GEIS Segundo Cmara (2010), SCRUM foi um nome utilizado pelos japoneses Hirotaka Takeuchi e Ikujiro Nonaka para descrever um tipo de processo de desenvolvimento de produto utilizado no Japo. O nome tambm foi escolhido pela similaridade entre o jogo Rugby e as caractersticas desse tipo de processo: ambos so adaptativos, rpidos e promovem auto-organizao. Em Schwaber e Beedle (2001), tem-se que o SCRUM no uma metodologia, mas sim um framework, o que significa que no conter os detalhes do que fazer exatamente. um framework para gesto de equipes envolvidas na execuo de tarefas, focada em entregar ao cliente, no menor tempo possvel, aquilo que mais agregue valor ao seu negcio. Em Mayer (2010), observa-se a introduo do termo SCRUM, por Jeff Sutherland, John Scumniotales e Jeff McKenna, enquanto trabalhavam para a Easel Corporation em 1993, uma empresa de software de Massachusetts, EUA. SCRUM baseia-se em princpios subjetivos como auto-organizao, comprometimento, colaborao, cooperao e equipes multifuncionais. Est notadamente inspirado nos princpios do AGILE MANIFESTO, registrados em Sutherland et al. (2010) onde:

Os indivduos e as interaes so mais importantes que os processos e as ferramentas; A colaborao com o cliente mais eficiente que aquilo que est escrito no contrato; Mudanas so encorajadas nas tarefas previamente definidas. Prefere-se software funcionando, no menor tempo, a possuir uma extensa documentao. Para Forss (2010), o SCRUM um mtodo que pode ser usado para deixar mais claro o ritmo no qual as tarefas precisam ser realizadas. Ele ajuda a definir as regras para quem toma as decises, o que precisa ser feito e quando as mudanas podem ser aplicadas.14

2.2. PRINCIPAIS ELEMENTOS DO SCRUM Para Cohn (2010), o principal elemento de um projeto SCRUM , notadamente, o produto em si. objetivo primordial da equipe a entrega do produto, das funes ou do sistema, no menor tempo e agregando o maior valor possvel ao negcio do cliente. O Product Backlog uma lista completa das funcionalidades, tarefas e produtos, desejados pelo cliente (MAYER, 2010). priorizado pelo Product Owner, o que implica que a equipe sempre manter o foco naquilo que mais importante para o cliente. A maneira mais eficaz de se criar um Product Backlog preench-lo de estrias do cliente, as quais descrevem de forma sucinta o que ele anseia, sempre na sua perspectiva e viso. No primeiro dia de um Sprint e durante um Sprint Planning Meeting, os membros do time criam o Sprint Backlog. Ele pode ser visto como uma lista de coisas a fazer no Sprint. Desse modo, o Product Backlog um conjunto de tarefas (funes, produtos, etc.) a realizar, solicitadas pelo cliente, e o Sprint Backlog uma lista de aes que o time precisa fazer para entregar essas funcionalidades solicitadas, no tempo combinado do Sprint, agregando o maior valor possvel ao negcio do cliente. Outros dois elementos essenciais so os grficos Sprint Burndown e o Release Burndown. Esses grficos mostram a quantidade de trabalho restante para um Sprint ou para uma Release. So ferramentas eficazes para determinar se as tarefas definidas para um Sprint ou Release realmente sero entregues no prazo desejado.

2.3. PRINCIPAIS PAPIS EM UM TIME SCRUM Segundo Sutherland e Schwaber (2010), o ScrumMaster uma espcie de tcnico do time, contribuindo para que todos os envolvidos atinjam seus mais altos nveis de performance. Ele difere de um gerente de projeto em variados aspectos, como, por exemplo, no ter a misso de ajustar diariamente a direo do time ou atribuir tarefas individualmente a cada um dos integrantes. Um bom ScrumMaster protege o time de distraes externas, permitindo-lhes focar, s e somente s, nos objetivos definidos para o Sprint.15

Enquanto o ScrumMaster objetiva ajudar o time a atingir os melhores resultados possveis, o Product Owner conduz o time para a direo correta, agregando o maior valor possvel organizao. Segundo Forss (2010), o Product Owner responsvel por decidir o que deve estar no Product Backlog, as prioridades de cada um desses itens, sua complexidade e interdependncias. Em Sutherland e Schwaber (2010), tem-se que o Product Owner deve produzir uma viso objetiva do que necessrio atingir (o produto a ser entregue ao final do Sprint), conduzindo todo o time em direo a ela. Ele responsvel por garantir que o Product Backlog mantenha-se priorizado, medida que ele aprende sobre o sistema ou produto que precisa ser construdo. Ainda em Sutherland e Schwaber (2010), encontra-se o terceiro papel no time SCRUM, que aquele exercido pelo prprio time. Nele, os integrantes podem ter diferentes funes ou formaes, mas trabalham em conjunto, contribuindo no que podem para completar as tarefas de cada Sprint.

2.4. FUNCIONAMENTO DO SCRUM 2.4.1. VISO GERAL Com o SCRUM, um projeto (conjunto de tarefas, recursos e prazo) progride atravs de interaes denominadas Sprints. Cada Sprint dura entre duas e quatro semanas. O SCRUM adqua-se a projetos com caractersticas de mudanas, com a emergncia abrupta de novos requisitos. Um time SCRUM formado por um grupo de 05 a 09 pessoas, mas eventualmente pode chegar a centenas (SUTHERLAND; SCHWABER, 2010). No time no existe os papis clssicos da engenheira de software, tais como analistas, programadores, etc. Cada um no time trabalha em funo dos outros, buscando incessantemente completar a lista de tarefas que eles coletivamente se comprometeram a realizar dentro do Sprint. Todo time SCRUM deve desenvolver um profundo esprito de comprometimento e camaradagem: estamos nisso todos juntos.

16

O Product Owner representa os usurios, clientes, a organizao. um profissional representativo na organizao que solicitou a tarefa, o software, o sistema, o produto. Deve conhecer verdadeiramente as prioridades da organizao para o projeto, pois sua funo manter o time SCRUM focado, alinhado com os objetivos organizacionais. O ScrumMaster o responsvel por garantir a eficcia do time SCRUM. O time precisa ser to eficaz quanto possvel. O ScrumMaster protege o time,

removendo os obstculos do dia-a-dia, impedindo que eventos externos tiram o foco da equipe durante o Sprint. O Product Backlog contm uma lista de tarefas ou misses, devidamente priorizadas, que refletem os anseios da organizao com relao ao projeto. So as misses a realizar com a devida prioridade vinculada a cada uma delas. No incio de cada Sprint, ocorre uma reunio denominada de Sprint Planning Meeting, onde o Product Owner prioriza as tarefas e o time seleciona o trabalho que eles realizaro durante o prximo Sprint. Essas tarefas so transferidas, movidas do Product Backlog para o Sprint Backlog, mas no mais no formato do usurio. No Sprint Backlog, as tarefas esto no formato de execuo do time de SCRUM, ou seja, o que deve ser feito para que cada tarefa eleita para o Sprint seja concluda. Assim, uma misso escolhida do Product Backlog para o Sprint, pode gerar vrias tarefas neste, devendo ser executadas pelos componentes do time SCRUM. O foco do time agora so as tarefas do Sprint. Diariamente, durante o Sprint, ocorre um encontro rpido chamado de Daily Scrum Metting. Nele, discute-se o que foi realizado no dia anterior e o que deve ser executado no dia presente, expondo-se inclusive alguns impedimentos que esto acontecendo. Todos os envolvidos devem participar do Daily Scrum Metting. No final do Sprint, o time demonstra tudo o que foi atingido em uma reunio denominada Sprint Review Meeting. um encontro informal, de no mais que duas horas, onde se demonstra os resultados obtidos.

17

A figura abaixo resume o ciclo de funcionamento do SCRUM:

Figura 1 - Ciclo de Funcionamento do SCRUM

2.4.2. A REUNIO DAILY SCRUM (DAILY SCRUM MEETING) Para cada dia do Sprint, deve haver uma reunio Daily Scrum. So , encontros que acontecem sempre no mesmo local e horrio com o time SCRUM. Idealmente, deve acontecer pela manh, antes do incio dos trabalhos do Sprint. Segundo Sutherland e Schwaber (2010), todos os membros do time odos SCRUM devem participar dessa reunio. um excelente momento para o time atualizar o status daquilo que est sendo feito. importante ressaltar que o Daily Scrum Meeting no deve ser utilizado para discusso tcnica de algum problema do Sprint. Isso deve ser feito no tempo do Sprint. No Daily Scrum Meeting o foco deve . Meeting, permanecer em responder as seguintes perguntas: O que foi feito ontem? O que deve ser feito hoje? H alguma tarefa impedida de ser executada? Quais ss razes?

18

Atravs do acompanhamento do que cada pessoa fez no dia anterior e o que deve fazer para o dia presente, tem-se uma excelente viso do andamento do Sprint e do trabalho que ainda vir. Ressalta-se que o Daily Scrum Meeting no pode ser tratado como uma reunio onde o lder coleta as informaes do time e pressiona quem est atrasado. Pelo contrrio, deve ser, preferencialmente, uma reunio do time para se ratificar os compromissos outrora assumidos. Quaisquer impedimentos que surjam durante o Sprint devem ser relatados nesse encontro. responsabilidade do ScrumMaster resolv-los, o mais rpido possvel.

2.4.3. O PRODUCT BACKLOG De acordo com Schwaber e Beedle (2010), o Product Backlog o corao do SCRUM. onde tudo comea. Ele contm uma lista de requisitos, estrias e desejos dos clientes, descritas utilizando uma terminologia no-tcnica. Quando um projeto iniciado, no existe uma especificao detalhada de tudo que deve ser feito para se atingir os seus objetivos. H apenas uma lista de grandes funes, as mais prioritrias, as mais importantes, as mais claras de se visualizar. o que conter o Product Backlog inicial. Ele pode evoluir e mudar medida em que se conhece mais os requisitos necessrios para se concluir o projeto. O Product Owner, durante o Sprint Planning Meeting, apresenta ao time SCRUM os objetivos de maior prioridade do projeto. O time, por sua vez, determina quais itens sero assumidos para o prximo Sprint. Desse modo, um item do Product Backlog pode gerar vrios itens no Sprint Backlog. Sugere-se que os itens do Product Backlog sejam descritos como estrias de usurios.

2.4.4. O PRODUCT OWNER A principal funo do Product Owner definir as prioridades dos itens do Product Backlog (FORSS, 2010). O time SCRUM olha para a lista priorizada do Product Backlog e a divide em vrias tarefas, as quais devem ser realizadas dentro de um Sprint. Esses itens formam assim o Sprint Backlog.19

Em respeito ao compromisso do time em concluir as tarefas do Sprint Backlog, o Product Owner no lhe adiciona novos requisitos, mesmo que sejam necessrios. Isso somente ser feito aps o final do Sprint, de modo que aquilo que foi acertado no incio desse ciclo possa ser cumprido sem alteraes.

2.4.5. A ESCOLHA DE TAREFAS PARA O SPRINT BACKLOG O Sprint Backlog a lista de tarefas que o time SCRUM est comprometido a completar no Sprint. Os itens do Sprint Backlog so tarefas necessrias para se atingir os desejos dos usurios, explicitados no Product Backlog como estrias de usurios. Em Schwaber e Beedle (2010), tem-se que o Sprint um processo emprico, no-linear e flexvel, onde se pretende evitar o caos, mas com forte flexibilidade. Baseados nas prioridades definidas pelo Product Owner, bem como na percepo do time com relao complexidade da tarefa e de seu prazo de concluso, o time define as tarefas do prximo Sprint, assim como o seu prazo. Todo o time deve estar realmente comprometido em entregar no final do Sprint as funes, tarefas, processos ou produtos, prontos para uso. Durante a execuo do Sprint, o ScrumMaster mantm um grfico com o trabalho estimado que ainda falta, em funo dos prazos do Sprint. O Grfico Sprint Burndown utilizado para acompanhamento do Sprint:

Figura 2 - Grfico Sprint Burndown

20

2.4.6. A REUNIO DE PLANEJAMENTO DO SPRINT (SPRINT PLANNING MEETING) A reunio de planejamento do Sprint envolve o Product Owner, o ScrumMaster e todo o time SCRUM. Durante essa reunio, o Product Owner explica, preferencialmente em termos de estrias de usurios, as aes (tarefas, produtos, etc.) que precisam ser desenvolvidos. O time SCRUM ento passa a questionar o Product Owner, buscando profundo entendimento do que precisa ser entregue e, principalmente, daquilo que entregar maios valor organizao. Essas estrias de usurios transformar-se-o em itens do Sprint Backlog. O Product Owner, nesse encontro, no precisa, necessariamente, descrever todos os itens do Product Backlog. Ele pode fazer isso apenas para os itens de maior prioridade, poupando o tempo do time SCRUM. Coletivamente, o Product Owner e o time SCRUM definem um objetivo para o Sprint, o qual pode ser representando por uma descrio sucinta do que aquele Sprint deve entregar, produzir. O sucesso do Sprint, avaliado posteriormente em uma reunio de reviso do Sprint, ser uma comparao do que foi realizado com essa pequena descrio, preferencialmente a uma comparao rgida, item a item, das tarefas que foram definidas para o Sprint. Aps a reunio de planejamento do Sprint, o time SCRUM pode se encontrar separadamente e discutir o que ouviram e planejarem como realizaro as tarefas durante o Sprint. Em alguns casos, pode haver negociao entre o time e o Product Owner, em relao ao que realmente pode ser entregue no Sprint. A deciso do que ser feito no Sprint realmente cabe ao time, uma vez que definiro realmente aquilo que podero entregar, ao final do prazo desse esforo.

2.4.7. A REUNIO DE REVISO DO SPRINT (SPRINT REVIEW MEETING) Ao final de cada Sprint realizada uma reunio de reviso. Durante esse encontro, o time apresenta o que foi realizado no Sprint. Geralmente, a reunio tem forma de demo das novas caractersticas que foram desenvolvidas. Deve ser mantido um carter informal, sendo proibida a21

apresentao de slides ou qualquer outra mdia que torne o encontro mais formal do que prtico. A reunio de reviso no pode ser tornar um obstculo ou distrao para o time. Deve ser apenas um resultado natural do Sprint.

2.4.8. QUADRO DE TAREFAS SCRUM O quadro de tarefas Scrum uma ferramenta de projeto para ser utilizada durante os Sprints. Ela mostra, basicamente, o que est sendo feito nele. Deve ser atualizado continuamente, exibindo para todo o time SCRUM o status atual da iterao. Pode ter vrios formatos, contendo variaes das seguintes colunas: I. Estria: contm a descrio, do ponto-de-vista do usurio, da funcionalidade que precisa ser entregue. Os itens dessa coluna foram aqueles selecionados do Product Backlog para serem entregues ao final do prximo Sprint. II. A Fazer: contm as tarefas necessrias para se atingir cada um dos itens da coluna Estria. As tarefas na coluna A Fazer ainda no esto sendo realizadas por nenhum componente do time SCRUM. III. Em Progresso: todas as tarefas em execuo precisam estar aqui representadas. Isso freqentemente acontece durante a reunio Daily Scrum Meeting, quando algum componente do time informa que iniciou determinada tarefa. IV. A verificar: uma srie de itens do Sprint est associada a testes sobre tarefas do prprio Sprint. Essas tarefas devem aparecer nesta coluna. V. Impedimentos: itens nessa coluna representam tarefas que foram iniciadas e foram interrompidas, devido a algum motivo. Requerem ateno imediata do ScrumMaster, para que possam voltar coluna A Fazer, de modo que o Sprint no seja prejudicado. VI. Concludas: itens nessa coluna representam tarefas concludas e que sero retiradas do quadro aps o trmino do Sprint.

22

Fisicamente, um quadro de tarefas SCRUM pode assumir vrias formas. Abaixo, seguem exemplos:

Figura 4 - Quadro de Tarefas SCRUM/Exemplo 01



23

3. DESCRIO DO CENRIO DO SUPORTE TCNICO DE TI DO SETURN: ANTES E APS A BILHETAGEM ELETRNICA

3.1. A BILHETAGEM ELETRNICA NO MUNICPIO DE NATAL A Bilhetagem Eletrnica consiste, basicamente, no pagamento das passagens no transporte pblico de forma eletrnica, utilizando computadores de bordo (validadores) nos carros e cartes smartcard como repositrios dos crditos, utilizados pelos usurios. Farrel (1996) indica em sua pesquisa os principais benefcios do sistema de bilhetagem eletrnica: I. Facilidade para os passageiros, que no precisam manusear dinheiro ou os vales na parada ou dentro do nibus; II. Agilidade na hora de passar pela roleta, pois basta encostar o bilhete no leitor para liber-la, alm de eliminar a perda de tempo com o troco; III. Mais segurana para todos os passageiros com a reduo do volume de dinheiro dentro dos nibus, reduzindo a possibilidade de assaltos; IV. Possibilidade de recuperar os crditos que no foram usados em caso de perda ou roubo do bilhete aps comunicao oficial ao Ponto de Venda Central, mediante apresentao de Boletim de Ocorrncia; V. VI. Fiscalizao e controle de todas as categorias de clientes; Moralizao do sistema ao garantir os benefcios a quem tem direito, evitando fraudes; VII. VIII. Controle do equilbrio entre oferta e demanda dos servios; e Comodidade na compra e recarga dos cartes.

Essa soluo informatizada permite populao, usuria do transporte coletivo, a utilizao desses cartes em substituio aos vales-transporte e passesestudantis em papel, bem como o dinheiro em espcie, alm de permitir que todos aqueles que gozam do direito da gratuidade nesse servio (idosos, deficientes, oficiais de justia, etc.) tambm utilizem o carto. Sem o papel, as fraudes diminuem e a informao, por ser eletrnica, coletada de forma automtica, propiciando uma

24

gesto just in time da atividade, o que representa um avano sem precedentes no servio de transporte coletivo. Esse sistema vem sendo implantado em vrias capitais brasileiras com dois objetivos bsicos: de um lado, o rgo gestor do transporte pblico (poder concedente), pretende melhorar a qualidade da informao sobre a atividade, propiciando assim maior controle, melhor tomada de deciso e, em ltima instncia, um melhor servio para a populao; do outro lado, as empresas permissionrias (que receberam a concesso do rgo gestor para realizar o servio) almejam estratificar melhor os seus passageiros, aumentar o seu poder de gesto e potencializar a sua arrecadao, atravs do impedimento de fraudes que ocorrem com freqncia atravs da manipulao do papel (vale-transporte e passeestudantil). O sistema atual de Bilhetagem Eletrnica do municpio de Natal/RN foi implantado em outubro de 2007, possuindo atualmente os seguintes nmeros: 07 empresas de transportes urbanos; 11 postos de venda de comercializao de crditos eletrnicos. Aproximadamente 400 mil cartes, distribudos nas seguintes categorias: o 170 mil cartes de vale-transporte, representado por 07 mil empresasclientes; o 140 mil cartes de estudante; o 15 mil cartes de gratuidade; o 75 mil cartes passe-fcil.

3.2. DESCRIO GERAL DO PROCESSO DE BILHETAGEM ELETRNICA A Bilhetagem Eletrnica na cidade de Natal composta por um conjunto de hardware, software e processos, representados por uma sute de solues denominada SIBEweb. O SIBEweb possibilitou a implantao da arrecadao eletrnica e do controle de demanda para o sistema coletivo de transporte por nibus de passageiros. A partir de sua implantao, os usurios passaram a utilizar cartes inteligentes sem contato, do tipo MIFARE, que:25

I.

Substituram o uso do dinheiro em espcie (opcionalmente), vale-transporte e passe estudantil em papel por crditos eletrnicos;

II.

Possibilitaram o usufruto do benefcio da gratuidade.

Tambm foi disponibilizada uma rede de atendimento, mantida e operada pelo SETURN, que presta servios de: I. Cadastramento de empresas clientes do vale-transporte eletrnico e solicitao de cartes para seus funcionrios; II. Atendimento a empresas clientes e usurios do carto, envolvendo processos de distribuio, desbloqueios, revalidao e solicitaes de novas vias de cartes, alm de comunicao de perdas, entre outros; III. Comercializao de cartes e crditos eletrnicos para usurios do tipo pessoa-fsica; IV. Comercializao de crditos eletrnicos para usurios do tipo estudantes.

Alm dessa rede de atendimento, existe uma rede de cadastramento, operacionalizada pela SEMOB, que executa as funes de cadastro de usurios de gratuidades (idosos, deficientes e outras classes definidas por lei) e estudantes. Os usurios, de posse de seus cartes, carregam crditos eletrnicos nos postos de venda, localizados na rede de atendimento, ou atravs de recarga embarcada (no caso de compra via WEB servio disponibilizado para empresasclientes de vale-transporte eletrnico). Os crditos carregados nos cartes so utilizados para o pagamento das passagens nos veculos, de acordo com as regras e polticas tarifrias vigentes. Esses crditos so gerados na Central de Operaes localizada no SETURN, sob forte esquema de segurana digital. Toda a frota das empresas associadas ao SETURN possui equipamentos denominados validadores, que permitem o uso dos cartes inteligentes pelos usurios, para pagamento de sua passagem e/ou validao de seu uso. Cada vez que um usurio utiliza um carto inteligente no sistema, o validador grava em sua memria interna uma transao (conjunto de dados descritivos sobre o uso do carto), em formato binrio encriptado. Diariamente, ao trmino da operao dos26

carros, ocorre o processo de coleta dessas transaes, atravs de uma rede de comunicao interna, sem fio (wireless), entre os validadores e computadores de coleta do sistema. Esses dados possibilitam a realizao da apurao financeira e controle da operao do dia, atravs de computadores e de programas destinados a esse fim. As Centrais de Operao (uma localizada no SETURN e outra na SEMOB) recebem as transaes dirias de todo sistema, em formato binrio encriptado, atravs de uma rede externa de comunicao privada, possibilitando a validao, autenticao, armazenamento e manuteno de todas as transaes recebidas e apurao da operao global do dia, tambm atravs de softwares e computadores. Assim, as informaes, em formato digital, sobre o sistema pblico coletivo de transporte de passageiros podem ser utilizadas para controle e melhoria da qualidade pelo rgo Gestor - SEMOB, propiciando-lhe agilidade e alto desempenho em seus processos de tomada de deciso.

3.3. DESCRIO DAS FUNES DO SUPORTE TCNICO DA TI (STTI) DO SETURN: ANTES E DEPOIS DA BILHETAGEM ELETRNICA

3.3.1. FUNES DO STTI ANTES DA BILHETAGEM ELETRNICA Notadamente, o setor de Tecnologia da Informao foi o que mais sentiu o impacto frente implantao da Bilhetagem Eletrnica, uma vez que: I. II. O papel foi substitudo pelos cartes smartcard com crditos eletrnicos; Um computador de bordo, denominado validador, foi instalado em cada um dos 800 nibus da cidade e, sem ele, no h a possibilidade do carro operar; III. 400 mil cartes foram distribudos dentre os usurios, com datas de validade, restries de uso, saldos eletrnicos, etc., e precisam agora ser devidamente controlados e atualizados para funcionarem corretamente; IV. Ao entrar nas suas garagens de origem, os nibus da frota das empresas associadas passam a compor um n de uma rede TCP/IP sem fio, wireless, em cada garagem instalada, onde so coletados e atualizados os dados dos validadores;

27

V.

Uma coleta equivocada pode bloquear a passagem de milhares de usurios pelas catracas dos nibus, causando caos no transporte pblico da cidade, e a todos os servios que dele dependem. Em outras palavras, e de forma muito similar ao que ocorreu com o sistema bancrio no Brasil, o transporte pblico por nibus, aps a bilhetagem eletrnica, tornou-se uma atividade altamente dependente da tecnologia da informao e de seus processos. Antes da Bilhetagem, a equipe de suporte tcnico de TI do SETURN

possua as seguintes responsabilidades, notadamente vinculadas venda do papel nos postos de venda, uma vez que toda a operao na rua, realizada pelas empresas associadas, dependia apenas do bom funcionamento do nibus e da presena do motorista e cobrador: I. Manter o parque de hardware e software dos postos venda em pleno funcionamento, realizando intervenes sempre que necessrio. As funes principais do software utilizado nos postos de venda eram: a. A de caixa, provendo o controle do numerrio recebido durante o dia, devido comercializao dos vales-transporte e passes estudantis em papel; b. A de impresso controlada nos vales-transporte e passes-estudantis, cuja data de validade e identidade do estudante precisavam ser impressas no corpo dos elementos de papel, sendo um importante fator de controle para atividade. II. Manter funcionando os servidores e software Central de controle de lotes de elementos em papel (vales-transporte e passes-estudantis), que eram enviados para a venda nos postos de venda. III. IV. Manter os dados da Central ntegros e disponveis. Realizar atendimentos aos usurios de TI da Central SETURN, no que se refere aos softwares de escritrio (pacotes MS Office), Windows, Internet e aplicativos de folha de pagamento e de controle de ponto. V. Atender prontamente SEMOB, quando no envio de relatrios operacionais gerenciais relativos atividade de transporte pblico por nibus.

28

Para isso, o SETURN dispunha de uma equipe de STTI com a seguinte formao:

01 Gerente de Suporte Tcnico de TI 01 Analista de Suporte de TI 03 Tcnicos de Suporte de TI 01 Analista de Telecom

A metodologia de atendimento resumia-se a receber ligaes dos clientes internos, sem centralizao alguma, alocando os colaboradores mais livres para as demandas. O foco da equipe de STTI era o conserto de hardware, uma vez que as paradas de servio nos postos de venda representavam perda direta de receita. Os postos de venda (onze ao todo) funcionavam com seus servidores de dados prprios, localmente instalados, que posteriormente sincronizavam-se com o servidor de dados principal localizado no SETURN. Ou seja, cada posto de venda funcionava de forma independente, com relao Central de Dados e Controle, localizada no SETURN. O fechamento da receita diria dos 11 postos de venda era feita aps o fechamento de caixa das estaes de trabalho e envio da receita para a Central do SETURN, conferindo-se a quantidade de papel vendida, bem como os lotes aos quais pertenciam. Ainda na Central do SETURN, funcionava um servio especial para os clientes do tipo pessoa-jurdica, denominado TELE-VALE. Era composto por uma equipe de funcionrios de Call Center que recebiam ligaes telefnicas dos clientes, digitando os seus pedidos em um sistema de informao. Aps isso, o setor de separao procedia ao corte dos vales-transporte e envelopamento dos mesmos, enviando-os atravs de uma frota de motos e taxis, temporariamente locada pelo SETURN para o atendimento dessa demanda. Todas as informaes operacionais ficavam concentradas nos sistemas de informao de cada uma das empresas, sendo enviadas mensalmente para o SETURN, para que pudessem ser consolidadas e enviadas para o rgo gestor, a SEMOB.29

Os clientes internos necessitavam da STTI basicamente para 02 categorias de atendimento: uma relativa interrupo do hardware, devido quebra dos equipamentos; a outra concernente aos servios de software, focados na comercializao dos vales-transporte e passes-estudantis. As interrupes eram poucas e a qualidade no atendimento aos clientes internos era satisfatria, de acordo com os dados de pesquisa de satisfao do cliente interno, realizada pelo setor de TI em junho de 2007.

3.3.2. FUNES DA TI APS A IMPLANTAO DA BILHETAGEM ELETRNICA A implantao da Bilhetagem Eletrnica exigiu mudanas profundas na gesto da Aequipe de TI, uma vez que os processos desempenhados pelo SETURN tornaram-se altamente dependente de tecnologia. A gerao e comercializao dos crditos eletrnicos, o uso nos nibus pelos passageiros do sistema, a coleta das informaes dos passageiros transportados e as polticas de benefcios concedidas, bem como o controle da operao e gesto das polticas pblicas criadas e aplicadas pela SEMOB, tudo passou a depender, essencialmente, do correto funcionamento do SIBEweb, sute de solues fornecida pela FUJITEC. Diante desse novo cenrio, a equipe de suporte tcnico de TI passou a executar tarefas e processos organizados nas seguintes categorias:

I.

Manuteno dos sistemas e polticas de segurana da informao implantados.

II. III. IV. V.

Desenvolvimento e atualizao de sites corporativos: Intranet e Internet. Desenvolvimento e manuteno de sistemas corporativos internos. Administrao de Banco de Dados. Suporte aos usurios em Windows, MS Office, Internet e aplicativos internos, bem como naqueles do SIBEweb utilizados na Central de Operaes e postos de venda.

VI.

Manuteno de toda a infra-estrutura de conectividade da Central SETURN, SEMOB, empresas-associadas e postos de venda.

VII.

Recebimento e processamentos dos arquivos binrios na Central SETURN, contendo os dados dos passageiros transportados das empresas-associadas.30

VIII.

Gerao, teste e envio das listas de recarga (contendo a ordem de crditos eletrnicos para cada um dos cartes com pedido realizados na WEB) e de acesso. A percepo de que uma mudana estrutural na equipe do STTI seria

necessria adveio com as mudanas inseridas pela Bilhetagem Eletrnica. A equipe deveria se especializar nas novas funcionalidades da sute de solues SIBEweb, novos perfis de colaboradores seriam necessrios, o que sugeria algumas contrataes e demisses na equipe. E o modo pelo qual os chamados eram recebidos e resolvidos pela STTI, baseado apenas na disponibilidade dos colaboradores e em planilhas de registro, no parecia robusto o suficiente para suportar o novo quadro que se instalava no SETURN. De outubro de 2007 a maio de 2008 foram feitas vrias tentativas de se desenvolver um modelo prprio de atendimento s novas demandas da STTI. Apesar das tentativas, foi observado que alguns problemas ainda persistiam, quais sejam: I. A deciso das tarefas prioritrias sempre era funo da Gerncia do STTI, o que s vezes no correspondia com as necessidades dos clientes internos; II. As reunies de sincronizao com a equipe eram semanais, o que por muitas vezes se mostrou ineficiente, uma vez que algumas tarefas exigiam um acompanhamento dirio e o envolvimento de toda equipe; III. Cada colaborador do STTI desenvolvida seu mtodo de controle das tarefas, privando a equipe de uma viso global do setor; IV. No havia uma viso clara do que j foi realizado, o que estava em andamento, o que estava travado e o que j foi concludo; V. No havia o comprometimento devido entre os membros da equipe, frente aos grandes desafios que se apresentavam para o time de suporte. Foi iniciada uma busca por metodologias, mtodos, frameworks, etc., que pudessem eliminar os problemas acima, devolvendo ao STTI um desempenho igual ou superior ao que possuam antes da implantao da Bilhetagem Eletrnica. A busca trouxe como um dos resultados a escolha do framework SCRUM que, aps algum tempo de uso, revelou-se, realmente, uma das ferramentas teis para aquela nova realidade vivida pelo STTI, contribuindo para que o setor recuperasse um31

desempenho satisfatrio, mesmo diante da nova complexidade advinda com a Bilhetagem Eletrnica.

3.4. REFORMULAO DA EQUIPE E IMPLANTAO DO SCRUM PARA GESTO DE TAREFAS DE TI Os princpios do SCRUM estimulam um trabalho em equipe autoorganizado, de intensa cooperao e de comprometimento, com a entrega do melhor resultado ao cliente. E esse perfil certamente no estava presente em nenhum dos colaboradores da STTI logo aps a implantao da Bilhetagem Eletrnica. Diante dessa realidade, a nova gerncia da Tecnologia da Informao, que naquele momento assumia os servios de TI, bem como os da Bilhetagem Eletrnica, partiu para a seleo de novos candidatos, que se identificassem com os princpios do SCRUM e que pudessem levar aquele esprito de equipe para o STTI. Assim, uma nova equipe foi selecionada e treinada, de acordo com esses princpios, dentre eles: intensa colaborao (forte interaes entre os indivduos), trabalho com a verdade, comprometimento e lealdade aos prazos e misses estabelecidos. Abaixo, tem-se o quadro antes e depois do time do STTI, aps a seleo formao da nova equipe:

EQUIPE STTI - ANTES 01 Gerente de Suporte Tcnico de TI

EQUIPE STTI - DEPOIS 01 Gerente de Suporte Tcnico de TI / ScrumMaster

01 Analista de Suporte Tcnico de TI 03 Tcnicos de Suporte Tcnico de TI 01 Analista de Telecomunicaes

01 Product Owner / Gerente Comercial 03 Tcnicos de Suporte Tcnico de TI

Alm da contratao e formao de um novo time de TI com novos princpios, modificou-se tambm o modelo de atendimento das ocorrncias, passando-se a registr-las atravs de um servio de Service Desk (de acordo com as melhores prticas do ITIL v2), via software, com o fornecimento do cdigo do32

atendimento para o cliente e uma funcionalidade na Intranet que permitia o acompanhamento desse chamado, por todo o seu ciclo de vida.

3.4.1. CUSTOMIZAO DO SCRUM PARA O SETOR DE SUPORTE TCNICO DE TI DO SETURN Com um novo time contratado e formado, a partir dos princpios do SCRUM, restava apenas a customizao desse framework para que a sua eficcia pudesse ser verificada. Como todo framework, o SCRUM no expe de forma rgida como as aes devem ser realizadas, mas sim o que precisa ser feito e quais princpios necessitam estar implcitos durante a execuo do trabalho. Assim, para a realidade do STTI do SETURN, as seguintes

customizaes foram realizadas:

I.

O papel de Product Owner foi atribudo ao Gerente Comercial do SETURN, uma vez que ele representa a atividade fim do Sindicato. O STTI funciona como um prestador de servios para a rea comercial, uma vez que o foco do SETURN a comercializao de crditos eletrnicos.

II. III.

O papel de ScrumMaster foi atribudo ao Gerente de Suporte Tcnico de TI. Foi projetado um quadro (com chapa de metal) de tarefas SCRUM e instalado na sala do STTI. Todas as tarefas SCRUM so escritas em papel de Post-It amarelo e fixadas ao quadro atravs de pequenos ms (Post-it um pequeno papel com adesivo de fcil remoo atrs de si, de forma que seja facilmente pregado, retirado e recolocado por algumas vezes, sem deixar marcas ou resduos). O quadro de tarefas SCRUM do STTI foi definido com as seguintes reas: a. Product Backlog: contm Post-Its amarelos com descries

resumidas e no tcnicas daquilo que o usurio solicitou (so as estrias dos usurios). Cada tarefa contm um cdigo identificador nico e um nmero que indica a sua prioridade, variando de 01 (prioridade baixa) a 03 (prioridade mxima). Essas prioridades so definidas pelo Product Owner.

33

b. Sprint Backlog: contm as tarefas que precisam ser executadas para cumprir as solicitaes do Product Backlog. Nessa seo do quadro, as tarefas so escritas tambm em Post-Its amarelos, e carregam consigo o cdigo identificador da estria do usurio que a originou (presentes no Product Backlog). A prioridade da tarefa no Sprint Backlog a mesma da sua estria de usurio correspondente do Product Backlog. c. Doing: contm Post-Its verdes das tarefas que esto sendo executadas. Nessa seo, h subdivises com os nomes dos colaboradores, permitindo ao ScrumMaster visualizar quem est fazendo o qu ao visualizar o quadro de tarefas SCRUM. d. Impediments: contm os Post-Its de todas as tarefas que esto com impedimentos, ou seja, que deveriam estar sendo executadas, mas no esto. Neste caso, adiciona-se ao Post-It da tarefa um outro, de cor vermelha, com o motivo do impedimento. e. Done: contm os Post-Its das tarefas que foram concludas. f. Burning Down Chat: exibe o grfico Burning Down, passando para o ScrumMaster a viso grfica do andamento do Sprint atual.

IV.

Todos os chamados (ocorrncias) registrados no software de Service Desk de uma semana, que necessitam de um prazo para anlise e desenvolvimento da soluo (seja em software, seja em processos), so agrupados no Product Backlog, com as suas prioridades j definidas pela Product Owner. Os chamados que so prontamente atendidos no Service Desk no entram para o quadro de tarefas SCRUM.

V.

Semanalmente, a partir de uma reunio de planejamento do Sprint (com a presena de todo time SCRUM, do Product Owner e do ScrumMaster), criado um Sprint Backlog, identificando quais ocorrncias registradas pelo Service Desk sero inseridas naquele Sprint. A discusso de como as tarefas sero executadas, com riqueza de detalhes, realizada posteriormente apenas pelo time SCRUM. Tarefas mais complexas que exijam mais que uma semana de envolvimento so na realidade particionadas em subtarefas, de modo que possam ser executadas em um Sprint semanal, de modo que outros Sprints possam ser criados para a concluso de todas as subtarefas34

de uma tarefa original. Nesse caso, todas as subtarefas possuiro o cdigo da estria de usurio que as originou. VI. Diariamente, s 8hs, realizada uma reunio Daily Scrum Meeting na sala do STTI, com a presena do ScrumMaster e do time SCRUM. Cada reunio dura at 20 minutos e realizada com todos os integrantes de p, defronte ao quadro de tarefas SCRUM. O ScrumMaster avalia os seguintes pontos: a. O que foi realizado ontem, relativo ao Sprint atual; b. O que ser realizado hoje; c. Qual tarefa que deveria ter sido realizada no dia anterior e no foi, e quais os motivos. As respostas provocam reposicionamento dos Post-Its nas sees do Quadro de Tarefas SCRUM: Doing, Impediments e Done. VII. Nas manhs de sbado so realizadas as reunies de reviso do Sprint, mantendo-se um carter o mais informal possvel. Participam dessa reunio o time SCRUM, o Product Owner e o ScrumMaster. Nas reunies de reviso do Sprint busca-se: a. Avaliar continuamente se as tarefas associadas ao Sprint foram realmente executadas e, se no foram, quais os motivos. O objetivo aprimorar todo o time SCRUM na correta eleio de tarefas para o Sprint, sempre procurando entregar o maior valor ao cliente. b. Avaliar o comprometimento da equipe com o cumprimento das tarefas, principalmente aquelas que envolvem o desenvolvimento em conjunto. Esse o momento para as conversas sinceras entre os integrantes da equipe. O intuito identificar comportamentos que fujam aos princpios do SCRUM. A equipe precisa sentir-se envolvida em um ambiente de justia, onde todo o esforo despendido em funo do outro mutuamente recompensado, gerando real comprometimento entre todos. c. Avaliar se as prioridades definidas pelo Product Owner realmente entregaram o maior valor ao cliente. De fato, essa uma avaliao feita exclusivamente pelo Product Owner, com feedback imediato para a equipe.

35

4. ANLISE DOS RESULTADOS Notadamente, a maior contribuio do framework SCRUM para o STTI do SETURN foi obtida a partir do profundo entendimento e absoro de seus princpios. O SCRUM transcende o valor de ferramenta de gesto de tarefas, oferecendo seu maior valor como uma filosofia de trabalho. Evidentemente, a percepo do que est sendo realizado e por quem, a definio de prioridades por um representante do cliente final e a praticidade das ferramentas do quadro de tarefas e do grfico Burning Down, so pontos altos do SCRUM. Mas nada supera o valor dos princpios geis, do comprometimento mtuo, da auto-organizao e da proatividade. Outro ponto importante foi a utilizao da filosofia SCRUM no processo de seleo e recrutamento dos colaboradores de TI. preciso que perfis que se encaixem ao SCRUM sejam prontamente selecionados, a fim de que os resultados desse futuro colaborador realmente sejam positivos dentro da equipe. Perfis fora dos princpios do SCRUM levariam a uma desordem na equipe e a uma provvel desarmonia do time. Junto ao SCRUM, a adoo do Service Desk, modelo ITIL v2, pode ser considerado um ponto de alavancagem para a nova STTI do SETURN. Sem um sistema de informao que permitisse o registro e organizao das solicitaes dos usurios (as quais em grande parte tornam-se estrias de usurios do Product Backlog) no seria possvel a adoo do SCRUM, nas condies atuais vivenciadas no STTI do SETURN. Para os clientes, que contriburam com os resultados do SCRUM a partir de uma pesquisa de satisfao, o desempenho do STTI foi mantido, apesar do aumento da complexidade. Certamente, sem a adoo de novas metodologias, ferramentas e frameworks para o setor de suporte de TI, o aumento da complexidade seria acompanhado de uma severa degradao da qualidade do atendimento e da prestao dos servios internos de TI, principalmente junto ao setor Comercial. Pela sensibilidade existente nesse setor (que lida diretamente com os interesses dos clientes externos), uma perda na qualidade dos servios de TI levaria a indicadores negativos na pesquisa de qualidade, fato que no ocorreu.

36

5. CONSIDERAES FINAIS 5.1. APRESENTAO DOS PRINCIPAIS OBJETIVOS ATINGIDOS E SUAS SOLUES Certamente, a implantao da Bilhetagem Eletrnica exigiu a adoo de uma nova postura, metodologias e frameworks no setor de suporte tcnico de TI (STTI) do SETURN. Um novo STTI precisava surgir naquele momento, caso contrrio, haveria severas perdas na qualidade da prestao dos servios de TI, com graves conseqncias para os servios de transporte e comercializao de crditos eletrnicos na cidade de Natal/RN. Um dos frameworks adotados foi o SCRUM. Descrever como ele foi implantado no STTI do SETURN e como os resultados forma percebidos perante o cliente final constituram os principais objetivos desse trabalho. De fato, a maior contribuio advinda com o estudo e implantao do SCRUM veio de seus princpios e filosofia. Mais que suas tcnicas, artefatos e ferramentas, seus fundamentos alteraram a seleo e recrutamento dos novos colaboradores (o que exigiu tambm uma adequao dos processos de Recursos Humanos do SETURN) e o esprito de cooperao e colaborao dos envolvidos no suporte tcnico de TI. Ressalta-se a mudana (altamente positiva) na relao com o cliente interno que, a partir do SCRUM, passou a fazer parte diretamente do processo de entrega da soluo (presena do Product Owner no time SCRUM), o que no ocorria anteriormente. Geralmente o cliente final s participava do processo no incio, quando fazia a solicitao, e no final, quando recebia os resultados. Finalmente, ressalta-se a expressiva melhora na entrega de valor ao cliente final, um dos pontos que eram mais falhos para o time de suporte de TI, que muitas vezes realizava atividades extremamente complexas, mas que no agregavam valor direto e perceptvel ao cliente final. Essa melhoria foi constatada a partir da pesquisa de satisfao, realizada com o setor Comercial do SETURN, visando avaliar a prestao de servios do suporte tcnico de TI. Os indicadores mostraram que apesar do aumento da complexidade oriundo da Bilhetagem Eletrnica a qualidade dos servios de TI manteve-se satisfatria.

37

5.2. PRINCIPAIS CONTRIBUIES A descrio do processo de implantao do SCRUM no setor de suporte tcnico de TI do SETURN e seus respectivos resultados certamente podem ser teis para as equipes de TI das cidades brasileiras que esto implantando (ou j implantaram) a Bilhetagem Eletrnica. A contratao de novos colaboradores sendo guiada pelos princpios do SCRUM, a atribuio do papel de Product Owner ao gerente comercial, as customizaes dos Post-Its do quadro de tarefas SCRUM, bem como a diviso de tarefas mais complexas em subtarefas, de modo que nunca excedam uma semana de Sprint; todos esses pontos podem ser considerados relevantes, uma vez que s podem ser obtidos com uma experincia prtica de implantao do SCRUM. Outro ponto importante a ressaltar a descrio do processo SCRUM, de forma detalhada, explicitando o modus operandi da equipe: os horrios das reunies com o time de TI, a durao e o formato dos encontros, os papis desempenhados por cada envolvido. Novamente, sem o carter prtico do trabalho, no seria possvel extrair aspectos reais do dia-a-dia da equipe. Todos esses pontos podem ser analisados, reutilizados e modificados por outros times de TI, quando na implantao do SCRUM em suas equipes.

5.3. ASPECTOS POSITIVOS E NEGATIVOS A experincia de adaptar o framework SCRUM realidade do SETURN foi muito rica e positiva. Sem a rigidez das metodologias, o framework permite a sua adequao a diferentes realidades, permitindo modificaes sem a perda dos princpios, flexibilizao com respeito aos fundamentos. Desse modo, pde-se aproveitar toda a essncia do SCRUM, aplicando, na prtica, suas ferramentas e mtodos de forma personalizada realidade SETURN, mas sempre conservando os princpios de adaptabilidade, entrega de maior valor ao cliente, cooperao com comprometimento e auto-organizao. Os resultados prticos mais diretos da experincia com o SCRUM esto, sem dvida, associados entrega dos servios ao cliente final. Uma pesquisa de satisfao demonstrou que, apesar de toda a complexidade inserida pela Bilhetagem

38

Eletrnica, a qualidade do atendimento de TI se manteve, o que significa que mais valor e no menor tempo tem sido entregue aos clientes internos de TI. Notadamente, alguns pontos de melhoria tambm podem ser ressaltados nesse trabalho. A forte mudana de paradigma exigida pelas metodologias geis para que seus princpios sejam realmente absorvidos e utilizados pelas equipes de TI so, sem dvida, uma barreira para uma implantao bem sucedida. necessrio um generoso intervalo de tempo para o amadurecimento da equipe. S a partir disso que os resultados com os clientes finais comeam a acontecer. Outro ponto negativo do processo de implantao est relacionado com a manuteno da rotina SCRUM do time de TI. Durante os meses iniciais sempre havia alguma desculpa para no se iniciar as reunies dirias (Daily Scrum Meeting) no mesmo horrio e muitas das tarefas no eram explicitadas no quadro de tarefas SCRUM, ficando apenas na cabea dos envolvidos. De fato, houve um intenso trabalho de convencimento da importncia da rotina para todo o processo SCRUM, com a aceitao plena da equipe ocorrendo apenas quando os primeiros resultados perante os clientes comearam a aparecer. Finalmente, a aceitao do processo de melhoria contnua para o SCRUM tambm pode ser considerado um ponto de difcil aceitao pela equipe. A idia de estar sempre rodando em modo beta, de que nunca estar concludo de fato causa estranheza e aflio para times de Tecnologia da Informao, com forte crena na exatido. Entender, aceitar e reconhecer que o ambiente de subjetividade e caos (no possvel predizer e controlar os desejos dos clientes) ser parte do dia-a-dia de uma equipe de suporte tcnico de TI, e que o aprendizado eficaz e evoluo somente podem ocorrer nesse cenrio so, sem sombra de dvida, o maior desafio a ser vivido pelas equipes de TI que estiverem adotando frameworks como o SCRUM em seus ambientes corporativos.

5.4. TRABALHOS FUTUROS Certamente, a experincia de implantar o SCRUM juntamente com a Bilhetagem Eletrnica trouxe as suas lies. Juntou-se a complexidade natural de se implantar novas tecnologias e processos, e a necessidade de reformulao de todo um setor de TI, com a insero de novos princpios de trabalho e modelos de39

relacionamento com o cliente interno. Os resultados poderiam, realmente, no ter sido positivos. Sugere-se, com base nessa experincia, que as equipes de TI se antecipem ao advento dessa complexidade, migrando parte de seus processos (ou todos eles) para o campo dos mtodos geis, preparando-se para as turbulncias antes que as mesmas comecem a ocorrer. Como resultado, elas podem experimentar at um aumento na qualidade da prestao de seus servios de TI, ocupando-se com apenas um problema por vez, oportunidade que no foi dada ao STTI do SETURN (a qualidade da prestao dos servios do STTI do SETURN foi apenas mantida, no incrementada). Outra ao que poderia atenuar os impactos oriundos da introduo do SCRUM no SETURN (o setor Comercial, o suporte tcnico de TI e o setor de Recursos Humanos sofreram profundas mudanas em seus processos dirios) seria introduzir seriamente o setor de Recursos Humanos (RH) no mundo das metodologias geis. O entendimento da fora dos resultados junto aos clientes finais, fruto da aplicao dos princpios do SCRUM, deve ser a mola propulsora do convite ao RH da organizao para que conhea e aplique tais fundamentos em todas as equipes, no apenas nas de Tecnologia da Informao. Houve um esforo enorme e grande dificuldade para que o RH do SETURN aceitasse o SCRUM como algo que fosse alm da TI. Pode-se afirmar que houve intenso debate e inmeras reunies at que o RH pudesse se tornar um parceiro no processo de utilizao do SCRUM. Economizar essa energia e tempo, permitindo acesso prvio do setor de RH ao mundo dos mtodos geis foi, sem dvida, uma das grandes lies aprendidas durante o processo. Enfim, a experincia bem sucedida com o SCRUM leva o STTI do SETURN a novos ciclos de inovao. A rea de aprofundamento apontada a dos mtodos geis, e toda a sua vasta proposta de princpios, metodologias, mtodos e frameworks. Eles oferecem um campo profcuo de anlise e experimentao para novas propostas de funcionamento de times, onde o cliente final SOMENTE responder positivamente ao trabalho dos prestadores de servio que trabalharem de forma proativa, auto-organizada e comprometida, realidade que certamente ser vivenciada pelo SETURN e pelo setor de suporte tcnico de TI nos prximos anos40

REFERNCIAS

Associao Nacional das Empresas de Transportes Urbanos NTU. Disponvel em:.

Acesso em: 22 de ou. 2010.

BEEDLE, Michael A.. Mike Beedle on the Early History of Scrum. Disponvel em: . Acesso em: 18 out. 2010.

CMARA,

Fbio. SCRUM:

Uma

Metodologia

gil. Disponvel

em:

. Acesso em: 22 set. 2010.

COHN, Mike. Introduction to Scrum - An Agile Process. Disponvel em: . Acesso em: 13 out. 2010.

FORSS, Anna. Confessions of a serial product owner: Based on a true story. Disponvel em: . Acesso em: 20 out. 2010.

KNIBERG, Henrik. SCRUM e XP Direto das Trincheiras: Como ns fazemos o SCRUM. Utah: C4media Inc., 2007. Disponvel em:

. Acesso em: 10 set. 2010.

MAYER,

Tobias

et

al. The

Essence

of

Scrum. Disponvel

em:

. Acesso em: 22 out. 2010.

OOPSLA - BUSINESS OBJECT DESIGN AND IMPLEMENTATION, 1995, Austin, Texas, Eua. SCRUM Development Process.Austin, Texas, Eua: Oopsla, 1995.

SCHWABER, Ken; BEEDLE, Mike. Agile Software Development with Scrum (Series in Agile Software Development). New Jersey: Prentice Hall, 2001. 158 p.41

SUTHERLAND, Jeff et al. Manifesto for Agile Software Development.Disponvel em: . Acesso em: 05 out. 2010.

SUTHERLAND, Jeff et al. Shock Therapy: Scrum. Disponvel em:

A Bootstrap for Hyper-Productive

. Acesso em: 30 out. 2010.

SUTHERLAND, Jeff; SCHWABER, Ken. The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework. Boston: Open View Labs, 2010. 219 p.

42

POSEAD - Turma 10-2009 - Monografia - Nicholas Paiva

Documents

Transcript of POSEAD - Turma 10-2009 - Monografia - Nicholas Paiva