UniEVANGLICA CENTRO UNIVERSITRIO CURSO DE SISTEMAS DE INFORMAO

AVALIAO DO NVEL DE MATURIDADE DOS PROCESSOS DE GESTO E DESENVOLVIMENTO DA FTT VIA MPS.BR.

CRISTINA SALETE ALEXANDRE DHIANCARLO MACEDO PINHEIRO

Anpolis

2011

CRISTINA SALETE ALEXANDRE DHIANCARLO MACEDO PINHEIRO

AVALIAO DO NVEL DE MATURIDADE DOS PROCESSOS DE GESTO E DESENVOLVIMENTO DA FTT VIA MPS.BR.

Trabalho de Concluso de Curso I apresentado ao curso de Sistema de Informao do Centro Universitrio Unievangelica para a obteno do titulo de graduao em Bacharelado em Sistemas de Informao, sob a orientao da Prof. Ms. Viviane Carla Batista.

Anpolis 2

2011

SUMRIO
1. INTRODUO...................................................................................................................................................4 2. PROBLEMA........................................................................................................................................................5 3. OBJETIVOS........................................................................................................................................................5 3.1. Objetivo Geral..................................................................................................................................................5 3.2. Objetivo Especifico...........................................................................................................................................5 4. JUSTIFICATIVA................................................................................................................................................6 5. REFERENCIAL TERICO..............................................................................................................................7 5.1. Modelo de Melhoria do Processo de Software Brasileiro - MPS.BR...........................................................7 5.1.1. Modelo de Referncia de Melhoria do Processo de Software Brasileiro MR-MPS.............................8 5.1.2. Modelo de Avaliao de Melhoria do Processo de Software Brasileiro MA-MPS................................10 5.2. Nvel G do MR-MPS......................................................................................................................................12 5.2.1. Gerencia de Projetos (GPR). .....................................................................................................................13 5.2.2. Gerncia de Requisitos (GRE)...................................................................................................................14 5.3. Metodologias geis..........................................................................................................................................15 5.4. SCRUM...........................................................................................................................................................18 5.4.1. Definio.......................................................................................................................................................18 5.4.1. Papis............................................................................................................................................................19 5.4.1.1. Burndown Chart......................................................................................................................................21 6. METODOLOGIA.............................................................................................................................................22 6.1. CRITRIOS DE INCLUSO.......................................................................................................................23 6.2. CRITRIOS DE EXCLUSO......................................................................................................................23 6.3. CRONOGRAMA...........................................................................................................................................24 7. REFERENCIAS................................................................................................................................................25

1. INTRODUO
As empresas que trabalham com desenvolvimento de produtos vm, cada vez mais, se preocupando com a agilidade e qualidade com que estes esto sendo produzidos. Assim, a gesto de seus processos de suma importncia para que os resultados sejam alcanados com mais rapidez. Alcanar o objetivo, ou seja, o produto pronto para utilizao ou consumo, depende de como a empresa tratar os processos de desenvolvimento para que o mesmo seja dado como terminado. No campo relacionado ao desenvolvimento de um software no diferente, pois o resultado tambm um produto que ser utilizado. (SOMMERVILLE, 2007). Segundo Sommerville um processo de software um conjunto de atividades que leva a produo de um produto de software(SOMMERVILLE, 2007, p.29 ). recomendado que esse conjunto de atividades siga um padro para serem desenvolvidas. Atualmente, existem vrios modelos de processo para essa finalidade. Sommerville (2007) descreve 4

diversos modelos genricos de processo, tais como: o modelo em cascata, desenvolvimento evolucionrio e engenharia de software baseada em componentes. Apesar de serem modelos muito utilizados, uma nova abordagem vem sendo inserida nos processos de gesto, que so as metodologias geis. Essas metodologias destinam-se a entregar um software de trabalho rapidamente aos clientes, que podem ento propor novos requisitos e alteraes a serem includos nas iteraes posteriores do sistema.(SOMEMRVILLE,2007, p. 262). As empresas desenvolvedoras de software procuram aprimorar a qualidade dos seus produtos melhorando seus processos de gesto e desenvolvimento de software. Em resposta a essa necessidade de aprimoramento da qualidade dos produtos e melhora dos processos, surgiram modelos que avaliam o nvel de maturidade do processo em que se encontram essas empresas e dessa forma propor melhorias. O Modelo de Melhoria do Processo de Software Brasileiro (MPS.BR) um modelo de qualidade que bastante utilizado para esse tipo de avaliao. (SOFTEX, 2009). A proposta para avaliao de maturidade da Fbrica de Tecnologias Turing (FTT), torna-se necessria devido ao rpido desenvolvimento dos processos de gesto. Alm disso, atualmente a busca pela qualidade no desenvolvimento de software um grande diferencial para as empresas. (SOMMERVILLE, 2007). Este trabalho tem por objetivo avaliar as caractersticas do modelo de gesto do Ncleo da Fbrica de Software, referente aos processos utilizados durante todas as etapas do projeto de criao de um software, avaliando novas tecnologias e metodologias atuais.

2. PROBLEMA
possvel atravs da utilizao Framework Scrum atender todos os requisitos do nvel de maturidade G do modelo MPS.BR ?

3. OBJETIVOS 3.1.Objetivo Geral

Avaliar se o uso de metodologias geis em projetos de desenvolvimento de softwares, possibilita alcanar o nvel de maturidade G do modelo MPS.BR.

3.2.Objetivo Especifico
Apresentar conceitos sobre metodologias geis e o modelo de qualidade MPS.BR; Mapear os atuais processos de gesto de projetos de desenvolvimento de software da FTT; 5

4. JUSTIFICATIVA
Com a necessidade de adaptao que as organizaes de software enfrentam, decorrentes da constante evoluo tecnolgica, torna-se necessrio melhorar o desempenho dos processos (FERREIRA et. al. 2005). As empresas esto investindo em qualidade, isto envolve melhorias de processos e adoo de metodologias que atenda estas mudanas (SANTANA, 2009). A utilizao do modelo de qualidade MPS.BR juntamente com o modelo gil de desenvolvimento Scrum aponta esta evoluo contnua dos processos, onde o objetivo produzir mais e com qualidade em menos tempo (CHIAVENATO, 2002). O custo reduzido da certificao de qualidade MPS.BR aliado a eficincia das metodologias geis podem ser interessantes s empresas voltadas ao desenvolvimento de softwares. Diante desse contexto e na busca pela melhoria contnua, a partir do ano de 2010, a Fbrica de Tecnologias Turing (FTT) passou a utilizar de metodologias geis nos seus processos de gesto e de produo. atravs desta perspectiva que este projeto se prope a realizar uma

avaliao sobre a interao de metodologias geis com o modelo de qualidade MPS.BR, utilizando para tanto o ambiente da FTT para realizar o estudo de caso.

5. REFERENCIAL TERICO
Este captulo abordar o Modelo de Melhoria de Processo de Software Brasileiro MPS. BR abrangendo os Mtodos de Avaliao MA MPS e Modelo de Referncia MR MPS, com foco no nvel G de maturidade. Diante do contexto que se prope a pesquisa, Metodologias geis ser outro tema abordado com nfase em Scrum.

5.1.Modelo de Melhoria do Processo de Software Brasileiro - MPS.BR

A indstria brasileira de desenvolvimento de software est em crescente desenvolvimento. Dentro deste contexto, vislumbrou-se a necessidade de criar um modelo de qualidade de desenvolvimento de software que fosse brasileiro e que atendesse as necessidades dos desenvolvedores nacionais, pois as certificaes estrangeiras so, na sua grande maioria, difceis de serem alcanadas, principalmente para as pequenas e mdias empresas. Assim, um modelo que se adequou s necessidades brasileiras foi criado, o MPS.BR. Este um programa brasileiro, coordenado pela Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX), que tem como foco ser referncia na melhoria da qualidade

de processos de software. Uma das principais preocupaes dos coordenadores atender os padres de qualidade exigidos internacionalmente. (SOFTEX, 2009).
Uma das metas do MPS.BR definir e aprimorar um modelo de melhoria e avaliao de processo de software, visando preferencialmente as micro, pequenas e mdias empresas, de forma a atender as suas necessidades de negcio e ser reconhecido nacional e internacionalmente como um modelo aplicvel indstria de software. (SOFTEX, 2009, pg 12).

O MPS.BR se fundamenta em normas e modelos para qualidade de produtos e processos de software, mundialmente aceitos, tais como: CMMI, ISSO/IEC 12207, ISSO/IEC 15504 conforme apresentado na figura 1.

Figura 01- Componentes do MPS.BR

Fonte: SOFTEX, 2009, p. 13 Analisando a figura 1, percebemos que o MPS.BR est dividido em trs componentes: MR-MPS (Modelo de referncia), MA-MPS (Mtodo de Avaliao) e MN-MPS (Modelo de Negcio). Cada um desses componentes tem suas particularidades e todos os requisitos especficos, de cada componente, devem ser atendidos para que possam estar em conformidade com o modelo. Cada modelo do MPS.BR composto por guias definidas em conformidade com os objetivos do modelo ao qual ela componente.

5.1.1.

Modelo de Referncia de Melhoria do Processo de Software

Brasileiro MR-MPS.
Como descrito pela Softex, O Modelo de Referncia MR-MPS define nveis de maturidade que so uma combinao entre processos e sua capacidade. (SOFTEX, 2009, 8

p.15). De acordo com essa definio, o nvel de maturidade de desenvolvimento est diretamente ligado aos processos que esto sendo aplicados para desenvolver um projeto. Segundo a Softex, Os nveis de maturidade estabelecem patamares de evoluo de processos, caracterizando estgios de melhoria da implementao de processos na organizao. (SOFTEX, 2009, p.16). Ao todo so sete nveis classificados como A (Em Otimizao), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A escala de maturidade se inicia no nvel G e progride at o nvel A. (SOFTEX, 2009, p.16). Cada nvel de maturidade tem em especfico os processos que devem ser atendidos pela organizao durante a execuo de seus projetos. Quando essa organizao solicita uma anlise so verificados quais processos so atendidos e assim a classificao de seu patamar em relao ao nvel de maturidade MPS.BR ser feita. (SOFTEX, 2009). Quando uma empresa decide por uma certificao MPS.BR ela est priorizando a qualidade de seus processos e o mais importante, a qualidade do produto final que ser entregue ao cliente. Nesse mercado to concorrido, sair na frente com qualidade de desenvolvimento de software poder ser o diferencial para chegar a novos mbitos comerciais. (SOFTEX, 2009). Abaixo est descrito mais detalhadamente os nveis de maturidade de acordo com o modelo MR-MPS. (SOFTEX, 2009).

Figura 02- Representao dos 7 nveis de maturidade MPS.BR

Fonte: MPS.BR (2007)

Nvel G: Parcialmente Gerenciado Atende os processos de gerncia de projetos e gerncia de requisitos. Nvel F: Gerenciado Alm de abranger o Nvel G acrescenta-se o processo de Aquisio, Gerncia de Configurao, Garantia de Qualidade e Medio. Nvel E: Parcialmente definido Abrange os Nveis G e F acrescentando os processos Avaliao e Melhoria do Processo Organizacional, Definio do Processo Organizacional, Gerncia de Recursos Humanos e Gerncia de Reutilizao. Nvel D: Largamente Definido Abrangendo os Nveis G, F, e E, alm dos processos de Desenvolvimento de Requisitos, Integrao do Produto, Projeto e Construo do Produto, Validao, e Verificao. Nvel C: Definido Abrange todos os nveis acima e inclui os processos de Anlise de Deciso e Resoluo, Desenvolvimento para Reutilizao e Gerncia de Riscos. Nvel B: Gerenciado Quantitativamente Abrange do Nvel G at o Nvel C e acrescenta-se ao processo de Gerncia de Projetos novos resultados. Nvel A: Em Otimizao Neste nvel todos os processos esto includos, alm do processo de Anlise de Causas de Problemas e Resoluo. Assim, utilizando destes dados, a certificao poder ser adquirida por nveis, a depender de quais processos esto sendo atendidos durante todo o projeto de desenvolvimento do software. O escopo dessa pesquisa se limita na avaliao do ambiente de estudo de caso, conforme apresentado nas sees 3 e 4 desse trabalho, em conformidade com o nvel G do MPS.BR. Desta forma, este nvel de maturidade ser melhor detalhado na seo 5.2.

5.1.2.

Modelo de Avaliao de Melhoria do Processo de Software

Brasileiro MA-MPS
Este componente prope um modelo para avaliar quais processos so realizados durante a execuo do projeto de desenvolvimento de software de uma organizao. Demonstrando todo o caminho que deve ser traado para ser realizada essa anlise seguindo modelos da MPS.BR. Basicamente feito um levantamento de todos os processos que esto inseridos durante a realizao dos projetos, e de posse desses dados embasando-se no MA-MPS, a

10

avaliao ter um resultado que ser a classificao de qual nvel de maturidade se encaixa a unidade avaliada, sempre seguindo os propsitos do MPS.BR. Atravs dessas orientaes que se define o nvel de maturidade da organizao. Por meio de um conjunto de atividades definidas pelo Modelo de Avaliao (MA-MPS), feita a avaliao, o resultado final obtido a fonte utilizada para fazer a classificao do nvel de maturidade correlacionada com os requisitos exigidos pelo Modelo de Referncia MR-MPS. Alguns objetivos desse modelo so definidos por seus coordenadores servindo como orientao para as instituies que tm interesse em conseguir uma certificao. Os principais objetivos segundo a SOFTEX so:
Permitir a avaliao objetiva dos processos de software de uma organizao/unidade organizacional. Permitir a atribuio de um nvel de maturidade do MR-MPS com base no resultado da avaliao. Ser aplicvel a qualquer domnio na indstria de software. Ser aplicvel a organizaes /unidades organizacionais de qualquer tamanho. (SOFTEX, 2009, p. 7).

O principal intuito da participao desse processo avaliativo conseguir uma certificao que comprove que um padro MPS.BR vem sendo utilizado para garantir a qualidade do software que esta sendo produzido. Esse registro garante por trs anos que a organizao segue o padro MPS.BR de qualidade de software. Todo esse processo passa por uma srie de atividades que devem ser realizadas para definir uma classificao de maturidade. A SOFTEX define alguns subprocessos para seguir o modelo de avaliao e cada um deles tem suas atividades, so eles: contratar a avaliao; preparar a realizao da avaliao; realizar a avaliao final; documentar os resultados da avaliao. Atravs desses subprocessos so recolhidas todas as informaes necessrias para uma anlise, podendo assim verificar quais foram os resultados obtidos e at que ponto esses atendem as especificaes da MPS.BR. (SOFTEX, 2009). A Figura 03 a seguir ilustra como esto divididos cada subprocesso e quais so as atividades relacionadas a eles.

11

Figura 03 Diviso do processo de avaliao e suas atividades relacionadas. Fonte: MPS.BR (2007)

Todas as etapas desse processo so importantes, desde contratar a avaliao at documentar os resultados da avaliao. Todo o processo de avaliao envolve uma srie de tarefas que devem ser cumpridas, como mostra a tabela acima, para o sucesso do trabalho que ser realizado, principalmente para as empresas que querem conseguir formalmente uma certificao MPS.BR, neste trabalho o foco ser fazer uma avaliao no formalizada dos projetos que esto em desenvolvimento. Por isso o foco ser avaliar os requisitos do processo e no em todo o processo.

5.2.Nvel G do MR-MPS
J descrevemos na seo 5.1.1 todos os nveis de maturidade do MR-MPS, aqui o foco ser o nvel de maturidade G. Esse nvel o primeiro nvel de maturidade do MR-MPS. Sua implementao deve ser executada com cautela por estabelecer o incio dos trabalhos em implantao de melhoria dos processos de software na organizao. (SOFTEX, 2009, p. 6). Cada um dos nveis de maturidade exige que alguns processos sejam atendidos, sendo que no nvel de maturidade G esses processos so o de Gerncia de Projetos e Gerncia de Requisitos. 12

5.2.1.

Gerencia de Projetos (GPR).

Uma empresa esta gerenciada quando suas atividades esto bem definidas e a atribuio das responsabilidades de cada membro de sua equipe so bem claras, dentre esses itens diversos outros requisitos devem ser atendidos. Para a Softex gernciar projeto estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informaes sobre o andamento do projeto que permitam a realizao de correes quando houver desvios significativos no desempenho do projeto.(SOFTEX, 2009, p.7). Dentro da gerncia de projetos a Softex define algumas atividades como: desenvolver um plano geral de controle do projeto; obter o comprometimento e mant-lo ao longo de toda a execuo do projeto; e conhecer o progresso do projeto, de maneira que aes corretivas possam ser tomadas quando a execuo do projeto desviar do planejado. Para se afirmar que um projeto de software esta sendo gerenciado alguns requisitos devem ser atendidos. Segundo a Softex so eles: O escopo do trabalho para o projeto definido. As tarefas e os produtos de trabalho do projeto so dimensionados utilizando mtodos apropriados. O modelo e as fases do ciclo de vida do projeto so definidos. O esforo e o custo para a execuo das tarefas e dos produtos de trabalho so estimados com base em dados histricos ou referncias tcnicas. O oramento e o cronograma do projeto, incluindo a definio de marcos e pontos de controle, so estabelecidos e mantidos. Os riscos do projeto so identificados e o seu impacto, probabilidade de ocorrncia e prioridade de tratamento so determinados e documentados. Os recursos humanos para o projeto so planejados considerando o perfil e o conhecimento necessrios para execut-lo. Os dados relevantes do projeto so identificados e planejados quanto forma de coleta, armazenamento e distribuio. Um mecanismo estabelecido para acess-los, incluindo, se pertinente, questes de privacidade e segurana. Um plano geral para a execuo do projeto estabelecido com a integrao de planos especficos. 13

A viabilidade de atingir as metas do projeto, considerando as restries e os recursos disponveis, avaliada. Se necessrio, ajustes so realizados. O Plano do Projeto revisado com todos os interessados e o compromisso com ele obtido. O projeto gerenciado utilizando-se o Plano do Projeto e outros planos que afetam o projeto e os resultados so documentados. O envolvimento das partes interessadas no projeto gerenciado. Revises so realizadas em marcos do projeto e conforme estabelecido no planejamento. Registros de problemas identificados e o resultado da anlise de questes pertinentes, incluindo dependncias crticas, so estabelecidos e tratados com as partes interessadas.

Aes para corrigir desvios em relao ao planejado e para prevenir a repetio dos problemas identificados so estabelecidas, implementadas e acompanhadas at a sua concluso.

Todos esses resultados esperados formam a base de informao do que necessrio para caracterizar um projeto como parcialmente gerenciado.

5.2.2.

Gerncia de Requisitos (GRE).

O levantamento de requisitos parte importante no desenvolvimento de um software, a fase onde o cliente expe suas necessidade e essas devem ser atendidas. A Softex afirma que Uma boa comunicao com os fornecedores de requisitos fundamental para assegurar um bom entendimento das necessidades do cliente e dos requisitos do projeto e, consequentemente, aumentar as chances de sucesso do projeto.(SOFTEX, 2009, p.18). Segundo Sommerville Os requisitos de um sistema so descries dos servios fornecidos pelo sistema e as suas restries operacionais (SOMMERVILLE, 2010, p.79). A gerncia desses requisitos faz parte de todo o sucesso do projeto, segundo a Softex O propsito do processo gerncia de requisitos gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsistncias entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.(SOFTEX, 2009, p.18). Existem segundo a Softex alguns pontos a serem atendidos durante a execuo do projeto em relao gerncia de requisitos, so eles: Os requisitos so entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critrios objetivos. 14

O comprometimento da equipe tcnica com os requisitos aprovados obtido. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho estabelecida e mantida. Revises em planos e produtos de trabalho do projeto so realizadas visando a identificar e corrigir inconsistncias em relao aos requisitos. Mudanas nos requisitos so gerenciadas ao longo do projeto.

Nesse processo de gerncia de requisitos, analisando o nvel G de maturidade, alguns atributos so definidos e cada atributo j tem descrito pela Softex o resultado esperado. Abaixo esto descritos cada atributo com seu resultado esperado: O processo executado. o O processo atinge seus resultados definidos. O processo gerenciado. o Existe uma poltica organizacional estabelecida e mantida para o processo. o A execuo do processo planejada. o A execuo do processo monitorada e ajustes so realizados. o As informaes e os recursos necessrios para a execuo do processo so identificados e disponibilizados. o As responsabilidades e a autoridade para executar o processo so definidas, atribudas e comunicadas. o As pessoas que executam o processo so competentes em termos de formao, treinamento e experincia. o A comunicao entre as partes interessadas no processo gerenciada de forma a garantir o seu envolvimento. o Os resultados do processo so revistos com a gerncia de alto nvel para fornecer visibilidade sobre a sua situao na organizao. o O processo planejado para o projeto executado.

5.3.Metodologias geis
Em fevereiro de 2001, em uma estao de equi de Utah, dezessete pessoas discutiam as prticas convencionais de projetos de softwares e a partir desta reunio publicaram o Manifesto gil, documentando uma nova metodologia de desenvolvimento. (AGILE, 2009) Com o objetivo de promover a metodologia gil fundaram a Agile Alliance, reunindo conhecimento sobre os processos geis e recrutrando pessoas para somarem ao movimento. 15

Segundo Soares (2004) as Metodologias geis focaram mais nas pessoas que nos processos, mais tempo na resoluo do problema que na documentao. Esta simplificao dos processos e conseqentemente a agilidade na produo de resultados se diferenciavam da abordagem clssica. A figura 04 demonstra as diferenas entre a abordagem clssica e a abordagem gil.

Figura 04 Comparao da abordagem clssica com a abordagem gil de desenvolvimento Fonte: LEAL, Luciana de Queiroz, Gerenciamento gil de Projetos, 2008

Para Fowler e Highsmith (2001), ns estamos [...] descobrindo maneiras melhores de desenvolver software fazendo-o ns mesmos e ajudando outros a faz-lo. De acordo com o manifesto gil so quatro os valores centrais da metodologia gil: Indivduos e interaes mais que processos e ferramentas Software em funcionamento mais que documentao abrangente Colaborao com o cliente mais que negociao de contratos Responder a mudanas mais que seguir um plano Embora o valor dado aos itens da esquerda so mais importantes, esta metodologia no considera desnecessrios os valores da direita. De acordo com o manifesto gil, o foco desta metodologia satisfazer o cliente adiantando a entrega dos resultados, aceitando mudanas de requisitos em qualquer etapa da produo. A entrega de softwares funcionando realizada em perodos mais curtos e o envolvimento das pessoas relacionadas bem maior. O Manifesto refora a idia de um

16

ambiente sustentvel onde todos os envolvidos so mantidos indefinidamente a passos constantes (AGILE, 2001). A busca de agilidade no interfere na qualidade do trabalho devida contnua ateno a excelncia tcnica e bom design. Com um time sempre motivado prevalece a confiana de que o trabalho ser finalizado de forma otimizada. Assim, este modelo de gesto foi determinante para a satisfao do cliente (BOEHM, 2003) reduzindo o prazo de execuo dos projetos e aumentando a qualidade do produto final (ANDERSON, 2003).
"Agilidade a habilidade de criar e responder a mudanas com respeito ao resultado financeiro do projeto em um turbulento ambiente de negcios. Agilidade a habilidade de balancear flexibilidade com estabilidade" (HIGHSMITH, JIM. AGILE PROJECT MANAGEMENT, 2002).

As principais metodologias geis utlizadas atualmente so: eXtremme Programming, SCRUM, Feature Driven Development, Lean Software Development, Adaptive Software Development, Crystal, DSDM, MSF for gile. (MANIFESTO, 2008) Dentre as metodologias supracitadas, destaca-se o SCRUM com 58% de adeptos em relao aos demais modelos, conforme demonstrado na figura 05.

Figura 05-Comparao do framework SCRUM em relao as demais metodologias geis Fonte: www.versionone.com

Este trabalho prope o estudo voltado ao SCRUM devido a necessidade de usar um framework onde produtos complexos podem ser desenvolvidos [Guia Scrum,2009], sendo que o SCRUM um conjunto de ferramentas que atende este requisito. 17

5.4.SCRUM 5.4.1. Definio

Considerado uma metodologia gil de gesto, o Scrum usado em vrios modelos de projetos de diversas reas do conhecimento (SCHWUABER, 2004). A aplicao inicial no fora voltada para a gesto tecnolgica. Sua aplicao no desenvolvimento de softwares foi muito importante para esta nova forma de controle e desburocratizao de processos. (SHUTERLAND; SCHWUABER, 2004) O framework Srcum fundamentado na .[...] teoria de controle de processos empricos, emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. (SCHWABER, 2004). Este framework foi influenciado pelas boas prticas da indstria Japonesa e pela teoria de sistemas adaptveis.(M POPPENDIECK apud SHUTERLAND; SCHWUABER, 2004). Segundo o Guia do SCRUM (2004), a transparncia no planejamento e a interao entre os envolvidos no desenvolvimento so determinantes nesta entrega rpida de resultados. Os monitoramentos constantes aliado ao planejamento contnuo durante os processos de desenvolvimento evitam o retrabalho e mitigam os desenvolvedores. Os pilares que sustentam esta metodologia so: Transparncia: Os resultados bem como sua obteno so claros e visveis a todos envolvidos. Inspeo: A inspeo constante resulta em maior deteco e previso de erros, evitando-os e os corrigido minimizando o desperdcio de tempo. Adaptao: O Ajuste durante o progresso e a reviso insistente das atividades evitam os desvios de escopo do projeto e conseqentemente a insatisfao e recusa do cliente. Segundo Larman (2004), o ciclo de vida do SCRUM possui quatro etapas: Planejamento Preparao Desenvolvimento Entrega

O Planejamento estabelece a viso, requisitos e funcionalidades do produto e garante que o oramento no ser extrapolado. A preparao a etapa em que so definidas prioridades de execuo e dividido o Product Backlog em Sprints sempre considerando a produtividade do time. O desenvolvimento a fase de implementao do sistema em 18

Sprints e a entrega corresponde a implantao operacional do sistema. (LARMAN, 2004; MARAL, 2009)

Figura-06: Demonstrao da iterao entre os papis, artefatos e etapas do SCRUM Fonte: SUTHERLAND & SCHWABER, The Scrum Papers, 2010)

5.4.1.

Papis Scrum Master

1.1.1.1.

O Scrum Master exerce o papel de gerente do software sendo responsvel pelos valores, prticas, diretrizes e a garantia de execuo. Este papel fundamental para garantir que o projeto ser entendido por todos. Em princpio esta funo pode ser exercida por qualquer membro da equipe.

1.1.1.2.

Product Owner

19

O Product Owner conhece as necessidades do cliente, por isso o primeiro contato com o cliente, prioriza o que deve ser feito e auxilia o Scrum Master. o nico responsvel por definir os Product Backlog e definir suas prioridades em cada Sprint.

1.1.1.3.

Team

So as pessoas, a equipe que transformam o Product Backlog em produtos entregveis. Em um Team todos envolvidos contribuem com todas as tarefas, portanto no existem divises funcionais como engenheiro, programador, design, entre outros profissionais. (Schwaber, 2009).

1.1.2.

Cerimnias Sprint

1.1.2.1.

Uma Sprint um ciclo de execuo no SCRUM, estas iteraes podem durar de de 2 a 4 semanas. A definio das aes a serem executadas na Sprint so definidas junto ao time, Scrum Master e Product Owner. A reunio que delimita estas definies a Sprint Planning Meeting. As tarefas que so definidas para uma Sprint saem da lista de Product Backlog e vo para a Backlog da Sprint. (SCHWABER, 2009).

1.1.2.2.

Sprint Planning Meeting

A atividade que precede uma Sprint o seu planejamento, uma reunio onde so definidas as metas e prioridades que o Team deve alcanar naquela Sprint. Esta etapa guiada pelo Scrum Master para que evite desperdcio de recursos em determinadas tarefas. Segundo o Guia do SCRUM (2002), para delinear as metas da Sprint, deve-se dividir a reunio em duas partes, a do o que? ( o que deve ser feito) e a do como?( como deve ser feito).

1.1.2.3.

Sprint Review

Esta cerimnia realizada ao final de cada Sprint com a finalidade de mostrar o que foi feito e o que no foi feito (Guia do Scrum, 2009). So discutidos os impedimentos que ocorreram naquela Sprint, bem como os problemas enfrentados e as solues tomadas naquela circunstncia. O Product Owner revisa o Product Backlog e realiza projees de datas com base nos resultados obtidos naquela Sprint. Desta forma, esta reunio bastante til para o melhor rendimento do Team no decorrer das outras Sprints.

1.1.2.4.

Sprint Retrospective Meeting

20

Entre a Sprint Review e a Sprint Planning Meeting, a Sprint Retrospective Meeting realizada com o Team e o ScrumMaster para discutir o que pode ser melhorado na prxima iterao e inspecionar os eventos ocorridos na ltima Sprint. (SCHWABER, 2009).

1.1.2.5.

Daily SCRUM

A Daily SCRUM uma reunio diria que dura em mdia 15 minutos e so levantadas as tarefas realizadas desde o encontro anterior e as tarefas a serem realizadas no prximo encontro. So expostos nesta reunio os impedimentos que atrapalharam o Team. (SCHWABER, 2009) . A comunicao entre os envolvidos mais clara proporcionando uma melhor e mais rpida tomada de decises. O Scrum Master o responsvel por realizar essa reunio. Essa uma reunio fundamental de inspeo e adaptao no processo emprico do Scrum.(Guia do Scrum, 2009, p.16)

1.1.3.

Artefatos Product Backlog

1.1.3.1.

Segundo Schwaber, (2004) o Product Backlog uma lista gerada pelo Product Owner contendo as funcionalidades e os requisitos de um determinado produto. Mostra, tambm, o valor e o peso de cada item. Para iniciar um projeto gerenciado com Scrum, o mnimo necessrio um documento de viso do produto e do Product Backlog. Estes documentos devem ser compartilhados com todos os envolvidos sincronizando as expectativas do cliente com as expectativas do Team.

1.1.3.2.

Sprint Backlog

Sprint Backlog a diviso do Product Backlog em partes menores, especificando o caminho a ser tomado para implementar uma funcionalidade dentro de um ciclo ou Sprint. Cada membro do Team escolhe a tarefa que ir executar dentro daquela Sprint, podendo ser alterado mesmo durante o processo. Segundo Martins (2007), um projeto SCRUM comea com uma viso formada por requisitos e funcionalidades que geram listas de tarefas.

5.4.1.1.

Burndown Chart

Burndown Chart um grfico que demonstra o andamento de uma Sprint e traa uma estimava para o trmino de itens de backlog. possvel visualizar atravs da figura 07 o consumo de horas dirias, apontando os atrasos e variaes de tempo na execuo de itens do Product Backlog.

21

Figura 07 Demonstrao de um Burndown Chart Fonte:http://blog.mountaingoatsoftware.com/improving-on-traditional-release-burndown-charts 16/03/2011

em

6. METODOLOGIA
O desenvolvimento deste projeto ser dividido em trs etapas: 1. 2. 3. Reviso Bibliogrfica. Mapeamento Avaliao

Na primeira etapa ser realizada uma reviso bibliogrfica sobre os assuntos pertinentes a essa pesquisa, em seguida uma avaliao do contedo e verificao da aplicabilidade dos recursos encontrados. Na segunda etapa ser realizado um mapeamento do Scrum na forma como aplicado na Fbrica de Tecnologias Turing ( FTT). Ser avaliado o nvel de maturidade dos processos de desenvolvimento e a aderncia em cada fase dos processos do nvel G, voltado Gerencia de Projetos e Gerncia de Requisitos, segundo o modelo MPS.BR, realizando um mapeamento dos processos e modelos de ciclos de produo dentro da FTT. Na terceira etapa ser realizada uma avaliao geral do processo de desenvolvimento baseada em guias de implementao e planilhas de avaliao proposta pelo modelo MPS.BR. Em funo do resultado desta avaliao, poder ser realizado um diagnstico propondo uma 22

soluo para a adequao do uso do Scrum, podendo o mesmo atender aos requisitos do nvel de maturidade G do MPS.BR.

6.1.CRITRIOS DE INCLUSO
Sero utilizados textos e sites com referncias tericas, textos e sites com abordagens descritivas relativos aos temas do projeto, livros e artigos cientficos, textos publicados a partir de Janeiro 1990 e imagens referenciadas com ano e fonte.

6.2.CRITRIOS DE EXCLUSO
No sero utilizados textos e sites sem referencial terico e bibliografia pesquisada, textos publicados antes de Janeiro 1990, livros, artigos e sites que no abordem os temas especificados.

23

6.3.

CRONOGRAMA

24

7. REFERENCIAS
25

AGILE MANIFESTO, Manifesto for Agile Software Development, 2001. Disponvel em <http://agilemanifesto.org/:> Acesso em maio de 2011. ANDERSON, David J.OBYRNE, Brian. Lean Interaction Design and Implementation: Using StateCharts with Feature Driven Development. Proceedings of Use 2003. 2003. BOEHM, B. and Turner, R., Balancing Agility and Discipline A Guide for the Perplexed, Addison Wesley, 2003. FOWLER, M.; HIGHSMITH, J. The Agile Manifesto. Software Development; Maro, 2001. LARMAN, C. Agile & Iterative Development, A Managers Guide. Addison-Wesley, 2004. MARAL, A. S. et al. Integrao de Story Points e Use Case Points em Projetos Baseados em SCRUM e CMMI. SBQS 2009 - 01-05 Junho, Ouro Preto MG, 2009. MARTINS, J.C.C. Gesto de projetos de desenvolvimento de softwares (PMI - UML); 1. ed. Rio de Janeiro; Brasport, 2007. POPPENDIECK, M.; POPPENDIECK, T. Lean Software Development: An Agile Toolkit, Agile Software Development Series, 2004. SANTANA, Clio; GUSMO. Melhoria de Processo de Software no Desenvolvimento gil. Revistas Engenharia de Software. Ano 2, 2009. SOFTEX - ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO. MPS.BR Guia Geral:2009, maio 2009a. Disponvel em <www.softex.br>. Acesso em Maio de 2011.

26

SOFTEX - ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO. MPS.BR Guia de Avaliao: 2009, maio 2009b. Disponvel em <www.softex.br>. Acesso em Maio de 2011. SOFTEX - ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO. MPS.BR Guia de Referencia:2009, maio 2009c. Disponvel em <www.softex.br>. Acesso em Maio de 2011. SOFTEX - ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO. Implementao MPS.BR do Guia do de Implementao: maio Fundamentao 2009d. Disponvel para em Nvel G MR-MPS:2009,

<www.softex.br>. Acesso em Maio de 2011. SOMMERVILLE. Engenharia de Software. 8 Edio Addison Wesley, 2007. Fowler e Highsmith (2001). SCHWABER, K. Agile Project Management with Scrum, Microsoft, 2004. SUTHERLAND, J.; SCHWABER, K. The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process. 2010.

27