Desenvolvimento gil de Software Utilizando Scrum | TI Especialistas

file:///D:/novo upgrade/Desenvolvimento gil de Software Utilizando ...

Home Contato Cursos Inscreva-se Livros Sobre Carreira Desenvolvimento Mercado Promoes Redes & Telecom Tecnologia TI Corporativa

Home Desenvolvimento Desenvolvimento gil de Software Utilizando Scrum

Desenvolvimento gil de Software Utilizando Scrum

Postado por Isabelle Desbois em Desenvolvimento, Gerncia de Projetos | 2 comentrios

ago 16, 2011

A gerncia de projetos uma rea chave no desenvolvimento de software, pois a ela atribuda a responsabilidade por grande parte das falhas ocorridas em projetos, bem como a responsabilidade por grande parte dos projetos bem sucedidos (Glass, 2003). Os processos de desenvolvimento de software que apoiam a gerncia de projetos tm um papel importante na questo de maximizar a qualidade do sistema que est sendo construdo e, por isso, devem ser cuidadosamente escolhidos de acordo com o projeto que se pretende desenvolver. A complexidade de um projeto definida por Schwaber e Beedle (Schwaber e Beedle, 2002) de acordo com o grau de instabilidade de seus requisitos ou da tecnologia adotada. Os projetos considerados simples tm requisitos bem definidos e tecnologia conhecida pelos desenvolvedores. J os projetos complexos apresentam certa dificuldade em elucidar seus requisitos, pois estes esto mudando a todo instante, ou ainda fazem uso de tecnologia emergente. A impossibilidade de se prever com certo grau de detalhe qualquer um destes dois elementos faz com que o desenvolvimento do sistema seja, no mnimo, confuso. De acordo com Schwaber e Beedle, o grau de complexidade de um projeto pode indicar que tipo de abordagem de gerncia e construo do sistema se deve adotar. Existem dois tipos de processos para controle e gerenciamento de projetos: os processos definidos e os processos empricos. Os processos definidos so baseados em processos industriais que definem como se d a transformao das entradas em sadas, podem ser repetidos que apresentaro sempre os mesmos resultados. So aplicados aos projetos simples que conseguem garantir a estabilidade das entradas possibilitando, assim, que o processo definido garanta a qualidade das sadas. Nos processos empricos essa transformao de entradas em sadas complexa e varivel, no podendo ser definida ou repetida, necessitando de frequente monitoramento e adaptao. Projetos complexos, cujas entradas esto em constante mudana, provavelmente necessitaro de constante monitoramento e adaptaes durante o desenvolvimento, eles tendem a adotar a abordagem de processos empricos.

1 de 12

17/09/2011 17:43

Desenvolvimento gil de Software Utilizando Scrum | TI Especialistas

file:///D:/novo upgrade/Desenvolvimento gil de Software Utilizando ...

O Scrum um processo emprico que oferece uma estrutura de gerncia de projeto cujo desenvolvimento est focado em ciclos de 30 dias. Nos Sprints como so chamados esses ciclos so listadas uma srie de funcionalidades desejveis ao final daquele perodo que devero ser incorporadas ao sistema pelo time de desenvolvimento. Para coordenar e integrar a equipe e mant-la focada nos objetivos do projeto, so feitas reunies dirias de curto perodo onde expe-se as realizaes, as pendncias e os problemas daquele dia. Dessa forma, os empecilhos que poderiam, no futuro, atravancar o bom andamento do projeto, sero detectados no mximo 24 horas aps sua ocorrncia e medidas adaptativas podero ser tomadas com antecedncia para corrigir as diretrizes do projeto. O termo Scrum foi usado pela primeira vez em 1987 no Japo para designar um processo de desenvolvimento hiperprodutivo. A origem da palavra vem do jogo Rugby e refere-se a uma estratgia utilizada pelos jogadores para recuperar uma bola fora do jogo. A semelhana entre a estratgia do jogo e o processo est no fato de que ambos precisam ser adaptveis ao ambiente, rpidos, auto-organizados e dispem de pouco tempo para realizar suas atividades (Schawber e Beedle, 2002).

1 Papis
So apenas trs papis em Scrum: o Product Owner, o Team e o Scrum Master. Todas as responsabilidades relativas ao gerenciamento do projeto so divididas entre estes trs papis. O Product Owner representa os interesses dos patrocinadores do projeto, o Team responsvel pelo desenvolvimento do sistema e o Scrum Master trabalha para garantir que as prticas de Scrum sejam aplicadas ao projeto. 1.1 Product Owner O Product Owner oficialmente o responsvel pelo projeto, ele representa os interesses dos patrocinadores e sua maior responsabilidade definir quais sero os requisitos do projeto e estabelecer uma ordem de prioridade entre eles, garantindo que as funcionalidades mais importantes sejam desenvolvidas primeiro. A lista de requisitos criada pelo Product Owner chamada Product Backlog e ser utilizada como insumo para desenvolvimento do sistema. A prioridade dos requisitos pode ser modificada a qualquer momento pelo Product Owner, afinal sua responsabilidade o gerenciamento do Product Backlog de acordo com seus interesses. Entretanto, essas modificaes s devero ser incorporadas pela equipe de desenvolvimento no prximo ciclo de iterao. Tambm faz parte de sua alada garantir que o Product Backlog esteja visvel a todos os envolvidos no projeto. O Product Owner representado por apenas uma pessoa, nunca por um comit. Um comit pode at existir para aconselh-lo, entretanto ningum alm do prprio Product Owner pode modificar as prioridades dos requisitos ou incluir um novo requisito na listagem. Se esta for a vontade do comit, ele ter que convencer o Product Owner a faz-lo. 1.2 Team Este papel desempenhado pelo time de desenvolvimento que deve se reunir a cada novo ciclo de iterao com o Scrum Master para revisar o Product Backlog e se comprometer a desenvolver uma parte desta lista de requisitos para o prximo ciclo. de responsabilidade do Team a definio de quais requisitos sero desenvolvidos, quem os desenvolver, como as funcionalidades sero desenvolvidas e quanto tempo levar para desenvolv-las. Uma vez que o time de desenvolvedores tem autonomia suficiente para definir como fazer seu trabalho, tambm passa a ser de sua responsabilidade o uso de padres, convenes, arquiteturas, grficos e tecnologias adotadas pela organizao, garantindo que o produto resultante do projeto possa ser compreendido por todos os envolvidos. Entretanto estes padres, convenes, arquiteturas, grficos e tecnologias devem ser mencionados no incio do ciclo, para que se possa reservar o tempo necessrio para verificaes de conformidades. O Team responsvel por atingir os objetivos do Sprint, ou seja, entregar um produto pronto que contm as funcionalidades resultantes dos requisitos os quais se comprometeu a desenvolver no incio do ciclo. Qualquer impedimento detectado no decorrer deste perodo deve ser imediatamente relatado ao Scrum Master nas reunies dirias. Se o time sentir que no tm capacidade para atingir o objetivo do ciclo por incorrees ou incoerncias dos requisitos ou qualquer outro tipo de impedimento que independam deles, podem pedir uma interrupo no Sprint e um novo recomeo do ciclo. O tamanho do time de desenvolvimento deve ser algo em torno de 5 a 9 pessoas. Times muito grandes podem atrapalhar os mecanismos de controle do Scrum e fazer com que o ritmo de produtividade diminua. Se for realmente necessrio o envolvimento de mais de 9 pessoas no desenvolvimento de um projeto, Scrum sugere que sejam criados dois times diferentes, tomando o cuidado de minimizar as dependncias entre eles e maximizar a coeso de trabalho entre os membros de cada time. 1.3 Scrum Master O Scrum Master o papel responsvel por garantir que os valores, as regras e as prticas de Scrum estejam sendo utilizadas

2 de 12

17/09/2011 17:43

Desenvolvimento gil de Software Utilizando Scrum | TI Especialistas

file:///D:/novo upgrade/Desenvolvimento gil de Software Utilizando ...

no projeto. de sua responsabilidade instituir junto aos clientes e aos gerentes a figura do Product Owner, e junto aos gerentes, a do Team. Sua principal tarefa ajudar estes dois papis a realizarem suas atividades de acordo com as regras de Scrum, eliminando os empecilhos que atrapalham o andamento do projeto. O Scrum Master trabalha junto ao Product Owner para construir o Product Backlog e junto ao Team para gerar o Sprint Backlog. de sua responsabilidade a conduo das Daily Meetings, onde deve escutar atentamente as realizaes de cada um dos membros do time de desenvolvedores. Qualquer dificuldade relatada deve ser prontamente trabalhada pelo Scrum Master a fim de devolver a normalidade ao desenvolvimento. Com base nessas reunies, ele deve avaliar o progresso da implementao do ciclo e compar-lo ao esperado nos objetivo do Sprint. Se algo estiver andando fora do esperado, o Scrum Master procurar identificar o motivo do atraso e tomar as providncias para que a produtividade volte a ser como o esperado. O perfil de uma pessoa que desempenha o papel de Scrum Master deve conter traos de obstinao e iniciativa prpria. Esta pessoa dever estar sempre focada e determinada a fazer aquilo que for necessrio para garantir o bom desempenho do Team.

2 Artefatos
Durante sua implementao, Scrum gera e faz uso de trs artefatos: o Product Backlog, o Sprint Backlog e o Incremento do Produto. Estes artefatos so explicados nas subsees seguintes. 2.1 Product Backlog O Product Backlog nada mais do que uma lista de todos os requisitos necessrios ou desejveis ao sistema que ser construdo. Ela contm todas as caractersticas, funes, tecnologias, bugs e tudo mais que representar trabalho a ser feito no decorrer do projeto. No incio do projeto, o Product Backlog considerado incompleto. Nesta fase ele constitudo apenas por uma listagem inicial dos requisitos mais importantes e caractersticos do sistema obtidos pelo Product Owner de algum documento de viso ou sesso de brainstorming. O artefato cresce em torno dessa listagem inicial conforme o Product Owner e os clientes vo amadurecendo o entendimento de suas necessidades em relao ao projeto em andamento. Por este motivo o Product Backlog nunca est completo. Ele pode ser constantemente alterado pelo Product Owner sempre que novas necessidades surgem ou novos detalhes referentes um item da lista so identificados. Desse modo, a listagem de requisitos vai sendo polida a fim de identificar cada vez mais precisamente os requisitos que tornam o sistema cada vez mais apropriado ao uso, competitivo e til. Os itens do Product Backlog so organizados por ordem de prioridade, os requisitos considerados mais importantes so desenvolvidos antes daqueles considerados menos prioritrios. Isso faz com que os elementos do topo da lista (os mais prioritrios) sejam analisados mais detalhadamente que os demais, agregando maior clareza especificao daqueles que precisam ser desenvolvidos com maior urgncia e ajudando o time de desenvolvimento a estimar mais precisamente o tempo necessrio para completar aquela tarefa. medida que os itens mais prioritrios da lista vo sendo feitos, os demais vo subindo na ordem de prioridade e anlises mais detalhadas so realizadas em torno daqueles requisitos. 2.2 Sprint Backlog O Sprint Backlog a lista de tarefas que o Team ir executar durante o Sprint. Essas tarefas so obtidas diretamente do Product Backlog de acordo com a prioridade dos requisitos definida pelo Product Owner. O Team escolhe quais sero os itens a serem desenvolvidos na iterao e estimam quando tempo ser necessrio para desenvolv-las. A estimativa do tempo para desenvolvimento de um item do Sprint Backlog feita em horas e ela no dever ultrapassar o tempo de 16 horas. Se isso acontecer, a tarefa dever ser melhor analisada para ser dividida em duas ou mais tarefas, pois possvel que ela no esteja precisamente detalhada. O time de desenvolvimento tem permisso para alterar os itens do Sprint Backlog. Conforme o ciclo de iterao vai ocorrendo e as tarefas do Sprint Backlog vo sendo desenvolvidas, a estimativa de horas gastas para cada tarefa vai sendo atualizada com o tempo real gasto naquela atividade. 2.3 Incremento do Produto Este o produto resultante do trabalho do time de desenvolvimento ao final de cada ciclo. Ele corresponde a uma parte do sistema que ser entregue no final do projeto e dever apresentar todas as funcionalidades descritas no Sprint que o resultou. O Product Owner tem o direito de fazer uso imediato do incremento do produto, por isso necessrio que ele tenha sido

3 de 12

17/09/2011 17:43

Desenvolvimento gil de Software Utilizando Scrum | TI Especialistas

file:///D:/novo upgrade/Desenvolvimento gil de Software Utilizando ...

testado durante o Sprint e esteja funcionando de acordo com o que foi solicitado pelo Product Owner, que as operaes dos usurios estejam devidamente documentadas e o cdigo bem escrito e bem estruturado. Se algum desses elementos estiver faltando ao artefato, ele no poder ser considerado pronto.

3 Regras
As regras abordadas nesta seo so a alma do processo Scrum. Elas devem ser seguidas por todos aqueles que esto envolvidos no projeto e o Scrum Master deve garantir que todos compreenderam a importncia do uso dessas regras e garantir que elas estejam sendo devidamente aplicadas. Se alguma inadequao na aplicao das regras ao projeto for identificada, sugestes para mudana podem ser feitas, entretanto elas devem partir do time de desenvolvimento. Mesmo assim o Scrum Master s autorizar uma modificao nas regras depois de ter certeza de que o time e todos os envolvidos entenderam o funcionamento de Scrum ao ponto de terem condies de sugerir tal modificao. A seguir so apresentadas as regras de Scrum, elas esto organizadas nas seguintes prticas do processo: Sprint Planning Meeting, Daily Scrum Meeting, Sprint, Sprint Review Meeting e Sprint Retrospective Meeting. 3.1 Sprint Planning Meeting O Sprint Planning Meeting uma reunio para o planejamento do trabalho a ser feito no prximo Sprint. Dela participam o Scrum Master, o Team e o Product Owner, e eles podem convidar outras pessoas que contribuam com algum conselho ou informao relevante referente ao negcio ou a tecnologia aplicada ao projeto. O Product Owner tem a tarefa de pr-preparar o Product Backlog para o encontro, pois a partir dele que as tarefas sero selecionadas para o Sprint. Na falta de um dos dois, Product Owner ou Product Backlog, o Scrum Master assume. A reunio tem durao total de oito horas, mas dividida em duas partes de quatro horas de durao cada uma. As primeiras quatro horas so reservadas para que o time de desenvolvimento selecione os itens do Product Backlog os quais eles acreditam conseguir trabalhar nos prximos 30 dias para gerar um incremento do produto. Nas quatro horas seguintes, o time dever construir, a partir dos itens selecionados anteriormente, o Sprint Backlog.
3.1.1 Sprint Planning Meeting Primeira Parte

No comeo da reunio, o Product Owner apresenta os itens que ele considera mais prioritrios do Product Backlog para serem desenvolvidos. Ele expe as funcionalidades que gostaria que fossem construdas pelo time de desenvolvimento no prximo Sprint. O Team, por sua vez, seleciona aquelas que eles acreditam conseguir entregar ao final do ciclo de desenvolvimento e, a partir da, so realizadas as devidas negociaes. A responsabilidade final de decidir quanto do Product Backlog que o Product Owner quer pronto no final do Sprint ser trabalhado nos prximos 30 dias do time de desenvolvimento. Tendo decidido estes itens, o Sprint Goal ser oficializado. O Sprint Goal o objetivo final do Sprint, ele traduz que parte do negcio ser construda naquele ciclo de iterao. Seu objetivo dar viso aos desenvolvedores daquilo que est sendo construdo pelo time, evitando que eles permaneam focados apenas em suas tarefas e esqueam-se do porque elas esto sendo construdas. Em tempo, manter o objetivo em mente ajuda o time a adaptar-se diante de condies que possam surgir mudando o curso do Sprint (Highsmith, 2002).
3.1.2 Sprint Planning Meeting Segunda Parte

A segunda parte do Sprint Planning Meeting, reservada para que o time de desenvolvimento possa discutir como os itens do Product Backlog selecionados anteriormente sero implementados no ciclo, que atividades estes itens englobam, quem realizar essas atividades e quanto tempo ser gasto em cada uma delas. O Product Owner poder permanecer disposio do Team para elucidar quaisquer dvidas que venham a surgir relacionadas aos itens do Product Backlog selecionados para o Sprint. Outros participantes tambm podem ser convidados pelo time para dar suporte tecnolgico ou do domnio do negcio do projeto. A lista de tarefas construda pelo time de desenvolvimento o Sprint Backlog, ela expressa quais sero as tarefas a serem realizadas no ciclo para atingir o Sprint Goal. O detalhamento de cada tarefa dever ser feito de modo que o tempo para sua construo no dure mais que dezesseis horas e todos os membros do time de desenvolvimento devem se comprometer com, ao menos, uma tarefa. O trabalho de estimar o tempo para a realizao das tarefas e de defini-las responsabilidade do time de desenvolvimento. O Sprint Backlog poder no ficar totalmente pronto nesta reunio, pode acontecer de o time ter que definir primeiramente uma arquitetura inicial ou realizar alguma investigao antes de definir detalhadamente o restante das tarefas a serem executadas. Nestes casos o time dever detalhar ao mximo as tarefas que puderem identificar e deixar lembretes de que

4 de 12

17/09/2011 17:43

Desenvolvimento gil de Software Utilizando Scrum | TI Especialistas

file:///D:/novo upgrade/Desenvolvimento gil de Software Utilizando ...

ainda existem tarefas a serem identificadas. 3.2 Daily Scrum Meeting O Daily Scrum Meeting uma reunio rpida, de cunho informativo, que acontece diariamente durante o Sprint. Participam desta reunio o Scrum Master e o Team. No entanto, outros participantes interessados no andamento do projeto podem acompanh-la, mas no podem falar ou questionar. As reunies duram cerca de quinze minutos e servem para promover a comunicao entre os membros do time, identificar e remover obstculos que atrapalhem o andamento do projeto e garantir que todos tenham acesso s mesmas informaes sobre o status do projeto. As reunies devero acontecer sempre no mesmo local e no mesmo horrio. O Scrum Master o responsvel por conduzi-la e dever garantir que as pessoas respondam claramente e objetivamente ao que lhes foi argido. Ele tambm dever estar atento para que observadores que no fazem parte do time no interrompam a reunio, deixando sempre claro que eles esto ali somente para observar. Todos os membros do Team devero estar presentes na reunio. Se, por algum motivo, algum integrante do grupo precisar faltar, ele poder participar por telefone ou nomear um representante no time que responda por ele. O Scrum Master inicia a reunio questionando um por um os integrantes do grupo de desenvolvimento. So feitas trs perguntas a cada um deles: O que foi feito no projeto desde o Daily Scrum Meeting passado? O que ser feito no projeto at o prximo Daily Scrum Meeting? O que est atrapalhando o bom andamento do trabalho? O time de desenvolvimento deve responder objetivamente a estas trs perguntas. Eles no devem descrever como est sendo feito o trabalho a no ser que precisem da ajuda de algum outro integrante da equipe. Entretanto, a soluo do problema no dever ser encontrada nesta reunio, se algum puder ajudar um colega com problemas, ele dever procur-lo ao final da reunio. Os obstculos ao bom andamento do trabalho identificados pelo Team na reunio sero anotados e verificados pelo Scrum Master. A maior prioridade em seu trabalho remover este tipo de obstculo a fim de que o time possa voltar a trabalhar normalmente o mais rpido possvel. 3.3 Sprint Um ciclo de desenvolvimento em Scrum chama-se Sprint e dura 30 dias. Este o perodo que a equipe de desenvolvedores tm para trabalhar com o Sprint Backlog e construir um incremento de produto que atinja as metas do Sprint Goal. Durante esta etapa do projeto, o Team tem completa autoridade para trabalhar da forma que lhe for conveniente: marcar reunies quando desejar, entrevistar os consultores que precisar, trabalhar quantas horas achar necessrio, buscar informaes na Internet por quanto tempo for preciso. Durante o Sprint, o contedo do Sprint Backlog no poder sofrer modificaes que no sejam solicitadas pelo Team, ele permanecer congelado at o final do ciclo, pois tido como base de trabalho da equipe de desenvolvimento. Se modificaes pudessem ser realizadas, as metas do Sprint poderiam no ser atingidas e o trabalho poderia se tornar confuso com novas tarefas sendo solicitadas a todo instante. Solicitaes de modificaes devem ficar registradas no Product Backlog para anlise no prximo Sprint Planning Meeting. Apesar de poderem definir seu formato de trabalho, os desenvolvedores tm algumas regras a respeitar: eles devem participar do Daily Scrum Meeting, trabalhar com o Sprint Backlog, utilizando-o como guia para desenvolvimento, ajustando suas estimativas e mantendo-o sempre atualizado caso haja alguma modificao nas tarefas, e entregar um incremento do produto que possa ser usando e atenda ao Sprint Goal. Se a equipe de desenvolvimento sentir que no ser possvel concluir o ciclo com todas as tarefas contidas no Sprint Backlog, ela dever informar ao Scrum Master e ambos devero consultar o Product Owner sobre quais itens poderiam ser removidos do Sprint Backlog. Se tantos itens precisarem ser removidos ao ponto do ciclo perder seu significado, o Scrum Master poder cancelar o Sprint e convocar novo Sprint Planning Meeting. Se, ao contrrio, o Team perceber que pode trabalhar mais itens do Product Backlog do que foi selecionado no Sprint Backlog, o Scrum Master dever ser informado e ambos consultaro o Product Owner sobre quais itens do Product Backlog ele considera interessantes serem acrescentados ao Sprint. 3.4 Sprint Review Meeting

5 de 12

17/09/2011 17:43

Desenvolvimento gil de Software Utilizando Scrum | TI Especialistas

file:///D:/novo upgrade/Desenvolvimento gil de Software Utilizando ...

O Sprint Review Meeting a reunio de apresentao do incremento do produto desenvolvido no Sprint. Nela apresentado como foi o andamento do ciclo, o que deu certo e o que deu errado, a estrutura do projeto com a adio do incremento e, por fim, o incremento do produto demonstrado em funcionamento. Tem durao de quatro horas. Dessa reunio participam os gerentes, que vm verificar o trabalho realizado com os recursos por ele disponibilizados, os clientes, que vm assegurar se gostam do que est sendo construdo, o Product Owner, que vem se certificar de que as funcionalidades por ele pedidas foram implementadas, e outros desenvolvedores, que vm descobrir o que o time foi capaz de fazer no perodo de trinta dias. O time no deve gastar mais que uma ou duas horas para preparar a apresentao, a reunio informal e seu propsito apenas apresentar as novas funcionalidades desenvolvidas no novo incremento. Isso significa que as funcionalidades que no estiverem totalmente prontas no podero ser apresentadas. A reunio normalmente comea com o Scrum Master fazendo uma breve reviso do Sprint, comparando o Sprint Goal e os itens do Product Backlog comprometidos no ciclo aos resultados do Sprint. Em seguida, feita a apresentao das funcionalidades desenvolvidas. A apresentao do incremento do produto dever ser realizada em ambiente de trabalho dos usurios, por isso, nesta fase da reunio, poder ser necessrio o deslocamento de pessoas. Ao final da reunio, os participantes so encorajados a opinar. Os clientes so solicitados a demonstrar suas impresses em relao ao produto apresentado e a dar sugestes de alteraes no produto e prioridade de implementao das mesmas. Durante todo o decorrer do encontro, questes, sugestes, observaes e discusses podem ser feitas e devem ser encorajadas pelo time e pelo Scrum Master. Deve-se ter em mente que este um momento importante para informar sobre o sistema que est sendo construdo e obter o feedback importante para saber se o desenvolvimento est seguindo o caminho certo. Se este no for o caso, a reunio importante para identificar que ajustes devero ser feitos para os prximos ciclos. 3.5 Sprint Retrospective Meeting Ao final do Sprint organizado um debate entre o Scrum Master e o time de desenvolvimento (o Product Owner opcional) sobre o andamento do ciclo que passou e como o processo Scrum atrapalhou ou ajudou no desenvolvimento do incremento neste perodo. Neste debate os participantes tentam exaltar os erros e acertos cometidos e buscam solues para que os erros no voltem a ocorrer nos Sprints seguintes. Dura 3 horas. Nesta reunio os membros do Team devem responder a duas perguntas realizadas pelo Scrum Master: O que, em sua opinio, correu bem no Sprint passado? O que poderia ser melhorado no prximo Sprint? As contribuies dadas pelo time so debatidas durante a reunio e aquelas consideradas como uma boa alternativa para melhorar o funcionamento de Scrum no Sprint seguinte so incorporadas s prticas.

Fonte: Scrum Alliance http://www.scrumalliance.org /learn_about_scrum

A figura acima exalta os principais eventos do fluxo de funcionamento de Scrum. Nela pode-se observar que o Product Backlog usado como insumo para a construo do Sprint Backlog, e este utilizado como guia base para desenvolvimento do sistema durante os Sprints.

6 de 12

17/09/2011 17:43

Desenvolvimento gil de Software Utilizando Scrum | TI Especialistas

file:///D:/novo upgrade/Desenvolvimento gil de Software Utilizando ...

Os Sprints tm durao mdia de 30 dias ou, como mostrado na figura, podem variar entre 2 a 4 semanas. No decorrer deste perodo, so realizadas diariamente as Daily Scrum Meeting, reunies para acompanhamento do desenvolvimento do projeto. Ao final do Sprint, um incremento do produto pronto para ser utilizado apresentado aos clientes.

O sucesso da aplicao de Scrum em um projeto advm da importncia que o mtodo d s atividades consideradas chaves do gerenciamento de projeto. imprescindvel que estas atividades sejam bem desempenhadas para que o projeto seja bem sucedido. Por exemplo: a tarefa de desvendar os pontos de impedimento tomando decises rapidamente a fim de sanar os problemas o quanto antes precisa ser executada com preciso pelo Scrum Master, caso contrrio, o projeto corre grande risco de atrasar ou mesmo sucumbir frente aos problemas que impediro seu progresso. Os aspectos humanos estimulados pelas suas regras so bastante interessantes, pois mantm a equipe unida e focada no projeto. As reunies dirias, por exemplo, promovem a colaborao entre os desenvolvedores, alm, claro, de identificar impedimentos que atrasem o cronograma. As reunies de final de Sprint permitem que funcionrios de diversos setores de uma mesma organizao trabalhem juntos em prol de um nico objetivo. Essas reunies tambm so interessantes, pois realimentam toda a cadeia de ciclos do Scrum ao identificarem novos requisitos ou ajustes no projeto que devero ser considerados nos prximos ciclos. Jim Highsmith (Highsmith, 2002) aconselha aqueles que pretendem usar Scrum a adot-lo em seu projeto mais crtico, mais instvel. Segundo ele, no seria de grande valia aplicar as regras de Scrum num projeto de pouco interesse para empresa, j que a dificuldade em se aplicar as atividades chaves de gerncia de projeto necessrias seria muito pequena, uma vez que o teor das decises a serem tomadas e os impedimentos a serem descobertos no se comparariam aos de um projeto extremamente crtico e importante. Aplicando as regras em um projeto deste porte (crtico, instvel) permite que Scrum mostre seu verdadeiro potencial aumentando as chances de sucesso do projeto ou, ao menos, antecipando informaes necessrias para o seu cancelamento. Number of View :835 Compartilhe:

facebook comments:

7 de 12

17/09/2011 17:43

Desenvolvimento gil de Software Utilizando Scrum | TI Especialistas

file:///D:/novo upgrade/Desenvolvimento gil de Software Utilizando ...

2 comentrios

1.

Gilberto Ribeiro / 16/08/2011 Parabns pelo artigo. Show de Bola! Reply

Isabelle Desbois / 17/08/2011 Obrigada Gilberto! Reply

Responder
Name (required) Mail (will not be published) (required) Website

Me notifique via e-mail sobre quem responder meus comentrios Free WordPress Themes

8 de 12

17/09/2011 17:43

Desenvolvimento gil de Software Utilizando Scrum | TI Especialistas

file:///D:/novo upgrade/Desenvolvimento gil de Software Utilizando ...

Anunciante

Sobre o Autor

Comecei cedo na rea de tecnologia, aos15 anos fiz meu primeiro programa usando BASIC. :) Sou formada em Cincia da Computao pela UERJ e, ainda na faculdade, trabalhei no desenvolvimento de plataformas que apoiavam o conceito web 2.0. H alguns anos me certifiquei CSM pela Scrum Alliance mas optei por no atuar como Scrum Master, pois me identifico mais com a construo de softwares. No entanto, meu interesse por processos geis persiste. Atualmente trabalho com arquitetura e desenvolvimento de sistemas numa emissora de televiso e estou concluindo ps-graduao em datawahouse, data mining e gesto do conhecimento na PUC-Rio. Vote & Compartilhe

Like Box

9 de 12

17/09/2011 17:43

Desenvolvimento gil de Software Utilizando Scrum | TI Especialistas

file:///D:/novo upgrade/Desenvolvimento gil de Software Utilizando ...

Recent Popular Random

Quando a hora certa de olhar para a prpria carreira? Posted on set 9, 2011

Os Pilares para Contedos em E-commerce Posted on set 9, 2011

O mercado e o desenvolvimento para dispositivos mveis Posted on set 8, 2011

Privacidade nas Redes Sociais Posted on set 8, 2011

At onde vai a sua vontade de vencer profissionalmente? Posted on set 8, 2011 Anunciante

Newsletter

10 de 12

17/09/2011 17:43

Desenvolvimento gil de Software Utilizando Scrum | TI Especialistas

file:///D:/novo upgrade/Desenvolvimento gil de Software Utilizando ...

Mais acessados

Tablet: se voc no tem, ter - 11531 hits BI no SharePoint 2010, uma evoluo para seu Portal - 6966 hits Salto Alto no Suporte de TI - 5352 hits Poder com praticidade utilizando o HP BladeSystem Matrix - 5135 hits Portais (SharePoint), Conhecimento, Pessoas. O que o mercado diz? - 5052 hits Categorias Carreira Desenvolvimento Mercado Promoes Redes & Telecom Tecnologia Cloud Computing Inteligncia Artificial Mobilidade TI Corporativa BI Direito & Tecnologia E-Commerce Gerncia de Projetos Gesto de Conhecimento Gesto de Processos Governana Segurana da Informao Tecnologia Social Artigos por data setembro 2011 agosto 2011 julho 2011 junho 2011 maio 2011 abril 2011 maro 2011 fevereiro 2011 janeiro 2011 dezembro 2010 novembro 2010 outubro 2010 setembro 2010 agosto 2010 julho 2010 ltimas publicaes Quando a hora certa de olhar para a prpria carreira? Os Pilares para Contedos em E-commerce O mercado e o desenvolvimento para dispositivos mveis Privacidade nas Redes Sociais

11 de 12

17/09/2011 17:43

Desenvolvimento gil de Software Utilizando Scrum | TI Especialistas

file:///D:/novo upgrade/Desenvolvimento gil de Software Utilizando ...

At onde vai a sua vontade de vencer profissionalmente? Home Contato Cursos Inscreva-se Livros Sobre Designed by Powered by Wordpress | Customizado por Augusto Vespermann WordPress

12 de 12

17/09/2011 17:43