Desenvolvimento

Ξ 7 comentários

Desenvolvimento Ágil de Software Utilizando Scrum

publicado por Isabelle Desbois

A gerência de projetos é uma área chave no desenvolvimento de software, pois a ela é atribuída 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 gerência de projetos têm um papel importante na questão de maximizar a qualidade do sistema que está sendo construído 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 têm requisitos bem definidos e tecnologia conhecida pelos desenvolvedores. Já os projetos complexos apresentam certa dificuldade em elucidar seus requisitos, pois estes estão 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 mínimo, confuso.

De acordo com Schwaber e Beedle, o grau de complexidade de um projeto pode indicar que tipo de abordagem de gerência e construção do sistema se deve adotar. Existem dois tipos de processos para controle e gerenciamento de projetos: os processos definidos e os processos empíricos. Os processos definidos são baseados em processos industriais que definem como se dá a transformação das entradas em saídas, podem ser repetidos que apresentarão sempre os mesmos resultados. São aplicados aos projetos simples que conseguem garantir a estabilidade das entradas possibilitando, assim, que o processo definido garanta a qualidade das saídas. Nos processos empíricos essa transformação de entradas em saídas é complexa e variável, não podendo ser definida ou repetida, necessitando de frequente monitoramento e adaptação. Projetos complexos, cujas entradas estão em constante mudança, provavelmente necessitarão de constante monitoramento e adaptações durante o desenvolvimento, eles tendem a adotar a abordagem de processos empíricos.

O Scrum é um processo empírico que oferece uma estrutura de gerência de projeto cujo desenvolvimento está focado em ciclos de 30 dias. Nos Sprints – como são chamados esses ciclos – são listadas uma série de funcionalidades desejáveis ao final daquele período que deverão ser incorporadas ao sistema pelo time de desenvolvimento. Para coordenar e integrar a equipe e mantê-la focada nos objetivos do projeto, são feitas reuniões diárias de curto período onde expõe-se as realizações, as pendências e os problemas daquele dia. Dessa forma, os empecilhos que poderiam, no futuro, atravancar o bom andamento do projeto, serão detectados no máximo 24 horas após sua ocorrência e medidas adaptativas poderão ser tomadas com antecedência para corrigir as diretrizes do projeto.

O termo Scrum foi usado pela primeira vez em 1987 no Japão para designar um processo de desenvolvimento hiperprodutivo. A origem da palavra vem do jogo Rugby e refere-se a uma estratégia utilizada pelos jogadores para recuperar uma bola fora do jogo. A semelhança entre a estratégia do jogo e o processo está no fato de que ambos precisam ser adaptáveis ao ambiente, rápidos, auto-organizados e dispõem de pouco tempo para realizar suas atividades (Schawber e Beedle, 2002).

1  Papéis

São apenas três papéis em Scrum: o Product Owner, o Team e o Scrum Master. Todas as responsabilidades relativas ao gerenciamento do projeto são divididas entre estes três papéis. O Product Owner representa os interesses dos patrocinadores do projeto, o Team é responsável pelo desenvolvimento do sistema e o Scrum Master trabalha para garantir que as práticas de Scrum sejam aplicadas ao projeto.

1.1  Product Owner

O Product Owner é oficialmente o responsável pelo projeto, ele representa os interesses dos patrocinadores e sua maior responsabilidade é definir quais serão 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 modificações só deverão ser incorporadas pela equipe de desenvolvimento no próximo ciclo de iteração. Também faz parte de sua alçada garantir que o Product Backlog esteja visível 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 ninguém além do próprio 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 iteração com o Scrum Master para revisar o Product Backlog e se comprometer a desenvolver uma parte desta lista de requisitos para o próximo ciclo. É de responsabilidade do Team a definição de quais requisitos serão desenvolvidos, quem os desenvolverá, como as funcionalidades serão desenvolvidas e quanto tempo levará para desenvolvê-las.

Uma vez que o time de desenvolvedores tem autonomia suficiente para definir como fazer seu trabalho, também passa a ser de sua responsabilidade o uso de padrões, convenções, arquiteturas, gráficos e tecnologias adotadas pela organização, garantindo que o produto resultante do projeto possa ser compreendido por todos os envolvidos. Entretanto estes padrões, convenções, arquiteturas, gráficos e tecnologias devem ser mencionados no início do ciclo, para que se possa reservar o tempo necessário para verificações de conformidades.

O Team é responsável por atingir os objetivos do Sprint, ou seja, entregar um produto pronto que contém as funcionalidades resultantes dos requisitos os quais se comprometeu a desenvolver no início do ciclo. Qualquer impedimento detectado no decorrer deste período deve ser imediatamente relatado ao Scrum Master nas reuniões diárias. Se o time sentir que não têm capacidade para atingir o objetivo do ciclo por incorreções ou incoerências dos requisitos ou qualquer outro tipo de impedimento que independam deles, podem pedir uma interrupção no Sprint e um novo recomeço 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 necessário 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 dependências entre eles e maximizar a coesão de trabalho entre os membros de cada time.

1.3  Scrum Master

O Scrum Master é o papel responsável por garantir que os valores, as regras e as práticas de Scrum estejam sendo utilizadas 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 papéis 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 condução das Daily Meetings, onde deve escutar atentamente as realizações 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 reuniões, ele deve avaliar o progresso da implementação 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 providências para que a produtividade volte a ser como o esperado.

O perfil de uma pessoa que desempenha o papel de Scrum Master deve conter traços de obstinação e iniciativa própria. Esta pessoa deverá estar sempre focada e determinada a fazer aquilo que for necessário para garantir o bom desempenho do Team.

2  Artefatos

Durante sua implementação, Scrum gera e faz uso de três artefatos: o Product Backlog, o Sprint Backlog e o Incremento do Produto. Estes artefatos são explicados nas subseções seguintes.

2.1  Product Backlog

O Product Backlog nada mais é do que uma lista de todos os requisitos necessários ou desejáveis ao sistema que será construído. Ela contém todas as características, funções, tecnologias, bugs e tudo mais que representar trabalho a ser feito no decorrer do projeto.

No início do projeto, o Product Backlog é considerado incompleto. Nesta fase ele é constituído apenas por uma listagem inicial dos requisitos mais importantes e característicos do sistema obtidos pelo Product Owner de algum documento de visão ou sessão de brainstorming. O artefato cresce em torno dessa listagem inicial conforme o Product Owner e os clientes vão amadurecendo o entendimento de suas necessidades em relação 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 são 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 são organizados por ordem de prioridade, os requisitos considerados mais importantes são desenvolvidos antes daqueles considerados menos prioritários. Isso faz com que os elementos do topo da lista (os mais prioritários) sejam analisados mais detalhadamente que os demais, agregando maior clareza à especificação daqueles que precisam ser desenvolvidos com maior urgência e ajudando o time de desenvolvimento a estimar mais precisamente o tempo necessário para completar aquela tarefa. Àmedida que os itens mais prioritários da lista vão sendo feitos, os demais vão subindo na ordem de prioridade e análises mais detalhadas são 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 são obtidas diretamente do Product Backlog de acordo com a prioridade dos requisitos definida pelo Product Owner. O Team escolhe quais serão os itens a serem desenvolvidos na iteração e estimam quando tempo será necessário para desenvolvê-las.

A estimativa do tempo para desenvolvimento de um item do Sprint Backlog é feita em horas e ela não 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 é possível que ela não esteja precisamente detalhada. O time de desenvolvimento tem permissão para alterar os itens do Sprint Backlog.

Conforme o ciclo de iteração vai ocorrendo e as tarefas do Sprint Backlog vão 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 é necessário que ele tenha sido testado durante o Sprint e esteja funcionando de acordo com o que foi solicitado pelo Product Owner, que as operações dos usuários estejam devidamente documentadas e o código bem escrito e bem estruturado. Se algum desses elementos estiver faltando ao artefato, ele não poderá ser considerado pronto.

3  Regras

As regras abordadas nesta seção são a alma do processo Scrum. Elas devem ser seguidas por todos aqueles que estão envolvidos no projeto e o Scrum Master deve garantir que todos compreenderam a importância do uso dessas regras e garantir que elas estejam sendo devidamente aplicadas.

Se alguma inadequação na aplicação das regras ao projeto for identificada, sugestões para mudança podem ser feitas, entretanto elas devem partir do time de desenvolvimento. Mesmo assim o Scrum Master só autorizará uma modificação nas regras depois de ter certeza de que o time e todos os envolvidos entenderam o funcionamento de Scrum ao ponto de terem condições de sugerir tal modificação.

A seguir são apresentadas as regras de Scrum, elas estão organizadas nas seguintes práticas 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 reunião para o planejamento do trabalho a ser feito no próximo Sprint. Dela participam o Scrum Master, o Team e o Product Owner, e eles podem convidar outras pessoas que contribuam com algum conselho ou informação relevante referente ao negócio 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 serão selecionadas para o Sprint. Na falta de um dos dois, Product Owner ou Product Backlog, o Scrum Master assume.

A reunião tem duração total de oito horas, mas é dividida em duas partes de quatro horas de duração cada uma. As primeiras quatro horas são reservadas para que o time de desenvolvimento selecione os itens do Product Backlog os quais eles acreditam conseguir trabalhar nos próximos 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 começo da reunião, o Product Owner apresenta os itens que ele considera mais prioritários do Product Backlog para serem desenvolvidos. Ele expõe as funcionalidades que gostaria que fossem construídas pelo time de desenvolvimento no próximo Sprint. O Team, por sua vez, seleciona aquelas que eles acreditam conseguir entregar ao final do ciclo de desenvolvimento e, a partir daí, são realizadas as devidas negociações.

A responsabilidade final de decidir quanto do Product Backlog – que o Product Owner quer pronto no final do Sprint – será trabalhado nos próximos 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 negócio será construída naquele ciclo de iteração. Seu objetivo é dar visão aos desenvolvedores daquilo que está sendo construído pelo time, evitando que eles permaneçam focados apenas em suas tarefas e esqueçam-se do porque elas estão sendo construídas. Em tempo, manter o objetivo em mente ajuda o time a adaptar-se diante de condições 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 serão 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 à disposição do Team para elucidar quaisquer dúvidas que venham a surgir relacionadas aos itens do Product Backlog selecionados para o Sprint. Outros participantes também podem ser convidados pelo time para dar suporte tecnológico ou do domínio do negócio do projeto.

A lista de tarefas construída pelo time de desenvolvimento é o Sprint Backlog, ela expressa quais serão 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 construção não 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 realização das tarefas e de defini-las é responsabilidade do time de desenvolvimento.

O Sprint Backlog poderá não ficar totalmente pronto nesta reunião, pode acontecer de o time ter que definir primeiramente uma arquitetura inicial ou realizar alguma investigação antes de definir detalhadamente o restante das tarefas a serem executadas. Nestes casos o time deverá detalhar ao máximo as tarefas que puderem identificar e deixar lembretes de que ainda existem tarefas a serem identificadas.

3.2  Daily Scrum Meeting

O Daily Scrum Meeting é uma reunião rápida, de cunho informativo, que acontece diariamente durante o Sprint. Participam desta reunião o Scrum Master e o Team. No entanto, outros participantes interessados no andamento do projeto podem acompanhá-la, mas não podem falar ou questionar. As reuniões duram cerca de quinze minutos e servem para promover a comunicação entre os membros do time, identificar e remover obstáculos que atrapalhem o andamento do projeto e garantir que todos tenham acesso às mesmas informações sobre o status do projeto.

As reuniões deverão acontecer sempre no mesmo local e no mesmo horário. O Scrum Master é o responsável por conduzi-la e deverá garantir que as pessoas respondam claramente e objetivamente ao que lhes foi argüido. Ele também deverá estar atento para que observadores que não fazem parte do time não interrompam a reunião, deixando sempre claro que eles estão ali somente para observar.

Todos os membros do Team deverão estar presentes na reunião. 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 reunião questionando um por um os integrantes do grupo de desenvolvimento. São feitas três 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 próximo Daily Scrum Meeting?
  • O que está atrapalhando o bom andamento do trabalho?

O time de desenvolvimento deve responder objetivamente a estas três perguntas. Eles não devem descrever como está sendo feito o trabalho a não ser que precisem da ajuda de algum outro integrante da equipe. Entretanto, a solução do problema não deverá ser encontrada nesta reunião, se alguém puder ajudar um colega com problemas, ele deverá procurá-lo ao final da reunião.

Os obstáculos ao bom andamento do trabalho identificados pelo Team na reunião serão anotados e verificados pelo Scrum Master. A maior prioridade em seu trabalho é remover este tipo de obstáculo a fim de que o time possa voltar a trabalhar normalmente o mais rápido possível.

3.3  Sprint

Um ciclo de desenvolvimento em Scrum chama-se Sprint e dura 30 dias. Este é o período que a equipe de desenvolvedores têm 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 reuniões quando desejar, entrevistar os consultores que precisar, trabalhar quantas horas achar necessário, buscar informações na Internet por quanto tempo for preciso.

Durante o Sprint, o conteúdo do Sprint Backlog não poderá sofrer modificações que não sejam solicitadas pelo Team, ele permanecerá “congelado” até o final do ciclo, pois é tido como base de trabalho da equipe de desenvolvimento. Se modificações pudessem ser realizadas, as metas do Sprint poderiam não ser atingidas e o trabalho poderia se tornar confuso com novas tarefas sendo solicitadas a todo instante. Solicitações de modificações devem ficar registradas no Product Backlog para análise no próximo Sprint Planning Meeting.

Apesar de poderem definir seu formato de trabalho, os desenvolvedores têm 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 modificação nas tarefas, e entregar um incremento do produto que possa ser usando e atenda ao Sprint Goal.

Se a equipe de desenvolvimento sentir que não será possível concluir o ciclo com todas as tarefas contidas no Sprint Backlog, ela deverá informar ao Scrum Master e ambos deverão 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 contrário, 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 consultarão o Product Owner sobre quais itens do Product Backlog ele considera interessantes serem acrescentados ao Sprint.

3.4  Sprint Review Meeting

O Sprint Review Meeting é a reunião de apresentação 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 adição do incremento e, por fim, o incremento do produto é demonstrado em funcionamento. Tem duração de quatro horas.

Dessa reunião participam os gerentes, que vêm verificar o trabalho realizado com os recursos por ele disponibilizados, os clientes, que vêm assegurar se gostam do que está sendo construído, o Product Owner, que vem se certificar de que as funcionalidades por ele pedidas foram implementadas, e outros desenvolvedores, que vêm descobrir o que o time foi capaz de fazer no período de trinta dias.

O time não deve gastar mais que uma ou duas horas para preparar a apresentação, a reunião é informal e seu propósito é apenas apresentar as novas funcionalidades desenvolvidas no novo incremento. Isso significa que as funcionalidades que não estiverem totalmente prontas não poderão ser apresentadas.

A reunião normalmente começa com o Scrum Master fazendo uma breve revisão do Sprint, comparando o Sprint Goal e os itens do Product Backlog comprometidos no ciclo aos resultados do Sprint. Em seguida, é feita a apresentação das funcionalidades desenvolvidas. A apresentação do incremento do produto deverá ser realizada em ambiente de trabalho dos usuários, por isso, nesta fase da reunião, poderá ser necessário o deslocamento de pessoas.

Ao final da reunião, os participantes são encorajados a opinar. Os clientes são solicitados a demonstrar suas impressões em relação ao produto apresentado e a dar sugestões de alterações no produto e prioridade de implementação das mesmas.

Durante todo o decorrer do encontro, questões, sugestões, observações e discussões 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 construído e obter o feedback é importante para saber se o desenvolvimento está seguindo o caminho certo. Se este não for o caso, a reunião é importante para identificar que ajustes deverão ser feitos para os próximos 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 período. Neste debate os participantes tentam exaltar os erros e acertos cometidos e buscam soluções para que os erros não voltem a ocorrer nos Sprints seguintes. Dura 3 horas.

Nesta reunião os membros do Team devem responder a duas perguntas realizadas pelo Scrum Master:

  • O que, em sua opinião, correu bem no Sprint passado?
  • O que poderia ser melhorado no próximo Sprint?

As contribuições dadas pelo time são debatidas durante a reunião e aquelas consideradas como uma boa alternativa para melhorar o funcionamento de Scrum no Sprint seguinte são incorporadas às práticas.

 

 

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 construção do Sprint Backlog, e este é utilizado como guia base para desenvolvimento do sistema durante os Sprints.

Os Sprints têm duração média de 30 dias ou, como mostrado na figura, podem variar entre 2 a 4 semanas. No decorrer deste período, são realizadas diariamente as Daily Scrum Meeting, reuniões para acompanhamento do desenvolvimento do projeto. Ao final do Sprint, um incremento do produto pronto para ser utilizado é apresentado aos clientes.

 

O sucesso da aplicação de Scrum em um projeto advém da importância que o método dá às atividades consideradas chaves do gerenciamento de projeto. É imprescindível que estas atividades sejam bem desempenhadas para que o projeto seja bem sucedido. Por exemplo: a tarefa de desvendar os pontos de impedimento tomando decisões rapidamente a fim de sanar os problemas o quanto antes precisa ser executada com precisão pelo Scrum Master, caso contrário, o projeto corre grande risco de atrasar ou mesmo sucumbir frente aos problemas que impedirão seu progresso.

Os aspectos humanos estimulados pelas suas regras são bastante interessantes, pois mantém a equipe unida e focada no projeto. As reuniões diárias, por exemplo, promovem a colaboração entre os desenvolvedores, além, é claro, de identificar impedimentos que atrasem o cronograma. As reuniões de final de Sprint permitem que funcionários de diversos setores de uma mesma organização trabalhem juntos em prol de um único objetivo. Essas reuniões também são interessantes, pois realimentam toda a cadeia de ciclos do Scrum ao identificarem novos requisitos ou ajustes no projeto que deverão ser considerados nos próximos ciclos.

Jim Highsmith (Highsmith, 2002) aconselha aqueles que pretendem usar Scrum a adotá-lo em seu projeto mais crítico, mais instável. Segundo ele, não 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 gerência de projeto necessárias seria muito pequena, uma vez que o teor das decisões a serem tomadas e os impedimentos a serem descobertos não se comparariam aos de um projeto extremamente crítico e importante. Aplicando as regras em um projeto deste porte (crítico, instável) permite que Scrum mostre seu verdadeiro potencial aumentando as chances de sucesso do projeto ou, ao menos, antecipando informações necessárias para o seu cancelamento.

  •  
  •  
  •  
  •  
  •  
  •  
  •  

Compare preços de Uber, 99 e Taxi

Minimum Way

Autor

Comecei cedo na área de tecnologia, aos15 anos fiz meu primeiro programa usando BASIC. :) Sou formada em Ciência da Computação 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 não atuar como Scrum Master, pois me identifico mais com a construção de softwares. No entanto, meu interesse por processos ágeis persiste. Atualmente trabalho com arquitetura e desenvolvimento de sistemas numa emissora de televisão e estou concluindo pós-graduação em datawahouse, data mining e gestão do conhecimento na PUC-Rio.

Isabelle Desbois

Comentários

7 Comments

  • Parabéns pelo artigo. Show de Bola!

    • Obrigada Gilberto!

  • Boa noite , estou estudando isso em minha especialização , parabéns pelo artigo … =)

    • Muito obrigada, Eder!

  • Parabéns pelo artigo ! Muito bem descrito, fácil entendimento. Estou estudando Scrum para aplicar na equipe de desenvolvimento e seu artigo contribuiu e muito. Parabéns !

    • Oi Pablo, que bom que o artigo foi útil!
      Obrigada!

  • Excelente artigo!!! parabéns!!!

You must be logged in to post a comment.

botão emergência ransomware (1)

Busca

Patrocínio

Publicidade




Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.