Metodologia Ágil

O que é XP – Extreme Programming?

Seguimos nossa série de artigos de metodologias, abordando hoje mais uma metodologia ágil: XP (Extreme Programming). Lembrando que já abordamos diversas metolodogias aqui, como Crystal, RAD, RUP, e AUP.

O XP (Extreme Programming ou Programação Extrema) é uma metodologia focada no desenvolvimento de software que possui valores e princípios, onde são fundamentados por um conjunto de práticas.

É uma metodologia leve que pode facilmente ser adotada por diferentes níveis de desenvolvedores (experientes ou não) e em qualquer tamanho de equipe. É uma excelente metodologia por se adaptar a requisitos que às vezes podem mudar rapidamente.

O XP pode ser utilizado de forma complementar ao Scrum, pois ele acaba focando mais em processos de engenharia e desenvolvimento de software.

Scrum - Planejamento e Desenvolvimento Ágeis
Curso de Scrum - Planejamento e Desenvolvimento Ágeis
CONHEÇA O CURSO

Princípios, valores e práticas

Como vimos acima, o XP possui um conjunto de princípios e valores, onde os princípios tendem a ser mais concretos que os valores. O conjunto de valores servem como um critério que norteiam as pessoas envolvidas no desenvolvimento do software, além de se complementarem. São eles: comunicação, simplicidade, feedback, coragem e respeito.

Além desses valores, existe um conjunto de princípios que deve ser seguido por equipes que forem usar XP em projetos, sendo o feedback rápido, presumir simplicidade, abraçar mudanças, trabalho de alta qualidade, pequenos passos, melhoria, diversidade, reflexão.

As práticas consistem no núcleo principal do processo. Elas evidenciam os valores que nos ajudarão a ter sucesso no projeto. São elas:

  • Cliente presente: O cliente deve participar ativamente do processo de desenvolvimento. Tudo precisa da comunicação com o cliente. Ele deve receber o melhor resultado possível a cada semana, ver o progresso no sistema, ser informado de mudanças de planos, etc. Escute, para que saiba qual é o problema a ser resolvido.

  • Planejamento: O desenvolvimento utilizando o XP é feito em iterações. Uma iteração é um período curto de tempo (1 ou 2 semanas) onde a equipe desenvolve um conjunto de funcionalidades. Sendo assim, no início da semana, desenvolvedores e clientes se reúnem para priorizar as funcionalidades. Essa reunião chama-se jogo de planejamento e nela já devem estar criadas as estórias. Se uma estória for muito grande, ela deve ser dividida em tarefas com duração máxima de alguns dias. Essas estórias devem ser escritas pelo cliente, pois assim ele consegue pensar melhor em cada funcionalidade. O planejamento é importante para que você sempre faça a coisa mais importante a ser feita.

  • Stand Up Meeting: São reuniões feitas em pé e de curta duração – mas muito produtiva, para que o time se mantenha alinhado, para saber o que cada um está fazendo exatamente, em que ponto está o projeto e se alguém está tendo problemas para executar suas tarefas. Ainda que apareça algum problema, essa reunião não tem o propósito de pensar em soluções.

  • Programação em par: É uma programação em par (dupla) em um único computador. Como é apenas um computador, o software sempre é revisto por duas pessoas diminuindo assim a possibilidade de falhas. Busca-se sempre a evolução da equipe melhorando a qualidade do código fonte. Ela é uma das práticas primordiais do XP, pois dois programadores fazendo o trabalho juntos acaba agregando muito para o trabalho em equipe.

  • Testes constantes: É utilizado o Desenvolvimento Orientado a Testes (Test Driven Development), o conhecido TDD. Primeiro crie os testes unitários e depois crie o código para que o teste funcione, essa abordagem é complexa no início, mas os testes unitários são essenciais para que a qualidade do projeto seja mantida.

  • Refatoração: É um processo que permite a melhoria contínua da programação, o mínimo de introdução de erros e mantendo compatibilidade com o código já existente. Refatorar melhora a clareza, leitura do código e facilita a manutenção. Além disso, o código fica mais coeso e você tem um melhor aproveitamento, evitando duplicação no código fonte.

XP - Extreme Programming
Curso de XP - Extreme Programming
CONHEÇA O CURSO
  • Código coletivo: Diz que o código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo é fazer a equipe conhecer todas as partes do sistema.

  • Padronização do código: Como todo mundo trabalha no desenvolvimento do mesmo software, a equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir essas regras, assim parecerá que todo código fonte foi digitado pela mesma pessoa. A padronização de código também é muito importante, porque o XP preza isso, o trabalho em equipe, se uma pessoa faz de um jeito e a outra faz de outro, isso fica muito confuso e futuramente pode ter problemas na revisão deste código.

  • Design simples: Essa prática se encaixa no princípio da simplicidade e é basicamente seguir o que o usuário está pedindo, por conta disso o design do software acaba sendo mais simplista. Além disso, o software acaba ficando mais fácil de ser alterado. Com essa metodologia você consegue alterar o código quando precisar, sem comprometer a qualidade.

  • Metáfora: Procura facilitar a comunicação com o cliente, entendendo qual a realidade dele. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.

  • Ritmo sustentável: Manter um ritmo de trabalho com qualidade, onde eles estejam atentos e dispostos.

  • Semana de 40 horas: É trabalhar com qualidade buscando ter um ritmo de trabalho saudável, 40h por semana, 8h por dia, sem horas extras.

  • Integração contínua: Sempre que for produzido uma nova funcionalidade você nunca deve esperar uma semana para integrar com a versão atual do sistema. Isso só aumenta a possibilidade de conflitos e possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

  • Releases curtos: As liberações de pequenas versões funcionais do projeto auxiliam muito no processo de aceitação por parte do cliente que já pode testar uma parte do sistema. As versões chegam ainda ser menores que as produzidas em outras metodologias incrementais, como o RUP. Os releases são pequenos pedaços do produto que são entregues ao cliente antes do tempo, assim o cliente não precisa esperar o produto todo ficar pronto para ver.

Considerações finais

Como pudemos ver o XP é dinâmico e flexível, nos ajudando a ter rapidez, qualidade e flexibilidade no desenvolvimento de um software. Se você quer conhecer ainda mais a fundo e principalmente ver o XP funcionando na prática, confira nosso curso de Extreme Programming.

Metodologia Crystal: o que é e para que serve?

As metodologias ágeis são ferramentas que vem sendo cada vez mais utilizadas no desenvolvimento de software. Já temos aqui no blog posts falando de uma bem conhecida: a metodologia Scrum.

O Scrum é o mais famoso e mais usado. Mas também temos vários outros, talvez menos conhecidos, pois alguns acabam sendo mais técnicos, o que os tornam mais específicos para engenharia de software, ao contrário do Scrum que é mais gerencial e aplicável não somente a indústria de software, como também a outras áreas e setores.

Neste artigo abordaremos a metodologia Crystal.

Crystal - Metodologia ágil
Curso de Crystal - Metodologia ágil
CONHEÇA O CURSO

Família Crystal

Criada no final da década de 90 por Alistair Cockburn e Jim Highsmith, a família Crystal se baseia na gestão de pessoas, tendo o foco na interação, habilidades, talentos e comunicação.

Segundo o criador Cockburn, as pessoas de uma equipe possuem diferentes talentos e habilidades, sendo um diferencial durante o desenvolvimento de um projeto, já que as pessoas têm uma importância muito grande no desempenho do projeto. Além disso, foi criada para atender vários tipos de projetos e equipes que precisam de táticas para resolver diversos problemas.

Não há uma metodologia Crystal e sim diferentes tipos de metodologia Crystal para diferentes tipos de projeto, por isso chamamos de família Crystal. É uma família de metodologias que une diferentes modelos de processo, mas com elementos centrais que são comuns a todas, além dos papéis e práticas específicas de cada uma.

Segundo os autores da metodologia, acredita-se que a metodologia adequada é baseada no tamanho da equipe e nos riscos envolvidos no projeto. Por isso, a família Crystal é dividida em cores, onde deve-se escolher a cor que mais for apropriada para cada projeto, de acordo com o nível de criticidade e o tamanho da equipe. Quanto mais escura for a cor, mais crítico é o sistema e, consequentemente, será utilizada a metodologia mais “pesada”.

Por exemplo, um projeto com 50 pessoas envolvidas precisa de uma metodologia mais pesada do que um projeto com 10 pessoas. Você pode avaliar seu projeto por duas visões: número de pessoas e criticidade do sistema.

A criticidade é dividida em 4 níveis: (C) conforto, (D) baixo custo, (E) alto custo e (L) risco de vida. Assim você consegue escolher a melhor metodologia para aquele projeto, adotando um conjunto de políticas adequadas para cada situação.

Algumas práticas da metodologia são:

  • a entrega em intervalos regulares;
  • o monitoramento do progresso;
  • envolvimento direto com o cliente;
  • inspeções constantes a cada incremento;
  • os feedback que servem para ajuste do produto e da metodologia caso necessário.

Você pode utilizar as metodologias da família Crystal em projetos de alta ou baixa criticidade. A ideia de Crystal é permitir que cada organização implemente as atividades que lhe pareçam adequadas.

Se você se interessou nessa metodologia e quer conhecer um pouco mais dos conceitos e como colocar em prática, temos um curso específico de Crystal, onde é abordado todas as metodologias dessa família.

No próximo artigo, conheceremos uma outra metodologia. Até lá!

Gráficos Burndown e Burnup: qual a diferença?

Quando estamos desenvolvendo um projeto, uma parte fundamental é o controle e monitoramento, por isso o quanto mais ferramentas e opções tivermos para fazer essa verificação do progresso do projeto é bem útil. Se você já fez uso ou conhece as metodologias ágeis, como o Scrum por exemplo, já deve ouvido falar em pelo menos um desses gráficos: burndown e burnup. Caso você nunca tenha ouvido falar sobre Scrum, sugiro a leitura de nosso artigo “Scrum como ferramenta de apoio ao gerenciamento de projetos” antes de prosseguir com este.

Scrum - Planejamento e Desenvolvimento Ágeis
Curso de Scrum - Planejamento e Desenvolvimento Ágeis
CONHEÇA O CURSO

Os gráficos de burndown e burnup são ferramentas do Scrum que basicamente representam o progresso do projeto. Com esses gráficos, você consegue medir a velocidade média de entrega da equipe, além de identificar fatores que possam influenciar na produtividade, como tarefas mal planejadas, ausência de membros da equipe, etc. Existem diversas maneiras de medir a performance da equipe em um projeto, esses gráficos são um deles, fazendo a comunicação ser direta e clara, informando sobre o trabalho em curso.

Gráfico de Burndown

O gráfico de burndown mede o progresso da Sprint, comparando o que foi planejado ao que foi entregue. Assim, é possível verificar se a equipe está adiantada, no prazo ou atrasada no cronograma, e assim, ajudá-los a tomar as medidas para adaptação caso necessário e a encontrar maneiras de melhorar o trabalho de acordo com os inconvenientes que enfrentam.

Nesse gráfico é mostrado as datas no eixo horizontal e no eixo vertical é mostrado o esforço em horas. Esse gráfico deve ser atualizados todos os dias, para monitorar o progresso diário do time.

Gráfico de Burnup

O gráfico de Burnup apesar de ser apresentado de uma maneira próxima ao Burndown, tem o propósito de exibir o total que foi planejado e o quanto a equipe já progrediu para alcançar esse objetivo. É utilizado para medir a entrega do projeto como um todo, onde podemos ver claramente em que ponto o time está, permitindo prever se a entrega será feita na data estimada.

Esse gráfico representa o progresso em direção à finalização do projeto, tendo como eixo vertical a story points e no eixo horizontal as datas. A ideia é que as linhas se aproximem, até as duas projeções se encontrarem, assim o projeto estará completo. Você pode atualizar esse gráfico ao final de cada sprint, para que o time possa ver o desempenho em relação a todo o projeto.

Quais as diferenças?

Os dois gráficos representam o progresso na entrega do projeto. O gráfico de burndown mostra o quanto falta para atingir a meta, enquanto o burnup mostra o que já foi feito até o momento do projeto. O gráfico de Burnup mostra as informações sobre o status do projeto como um todo, não apenas da sprint (caso do burndown).

Esses gráficos nos auxiliam muito pois conseguimos ver de forma clara e visual, principalmente em reuniões de equipe, para ver se tudo está caminhando como deveria. Caso tenha algo afetando, pode ser discutido ações e medidas para solucionar esses problemas, a fim de não comprometer a entrega do projeto. Nas imagens deste artigo, vimos que até o Trello nos ajuda na elaboração destes gráficos.

Kanban x Scrum: diferenças e como implementá-los

No nosso último artigo sobre Kanban, vimos alguns dos princípios básicos para que ele funcione corretamente. Começamos a abordar também que o Kanban não é uma metodologia ágil. Por ele ser comumente utilizado junto a uma metodologia ágil, como o Scrum por exemplo, pode haver essa confusão.

Sendo assim, vamos abordar nesse artigo quais são essas diferenças e como eles se complementam entre si.

(Vale lembrar que já temos um artigo explicando sobre o Scrum, caso você queira saber mais sobre essa metodologia antes de prosseguir nesse artigo.)

AUP - Agile Unified Process
Curso de AUP - Agile Unified Process
CONHEÇA O CURSO

Afinal, quais são essas diferenças?

Depois de saber um pouco mais sobre o Scrum e o Kanban, podemos ver que eles compartilham alguns dos mesmos conceitos, mas com abordagens diferentes, portanto não devem ser confundidos um com o outro.

Na tabela abaixo, podemos ver de maneira geral algumas das principais diferenças.

KanbanScrum
RitmoFluxo contínuoSprints regulares definidas (ex: 1 semana, 2 semanas)
FunçõesSem funções existentesFunções definidas, como Scrum Master, equipe de desenvolvimento, etc.
EntregasContínua ou a critério da equipeNo final de cada Sprint devem ser aprovadas. Caso não seja, a mesma tarefa volta para a próxima Sprint.
MudançasPodem ocorrer a qualquer momentoAs equipes devem se esforçar para não fazer alterações na previsão da sprint durante a mesma, pois a estimativa fica comprometida.

Em outras palavras, o Kanban foca mais no acompanhamento visual dos processos e o Scrum no gerenciamento do projeto, por isso a junção desses dois é muito utilizada. Vamos abordar agora como é feita essa implementação em uma empresa.

Colocando o Kanban e Scrum em prática

Primeiramente precisamos ressaltar a importância do engajamento da equipe. Sem isso você não conseguirá ter sucesso. Esse engajamento é importante pois, no Kanban, cada colaborador é responsável por manter o painel sempre atualizado.

Primeiro começamos indo mais para o lado do Scrum, onde precisamos realizar alguns passos essenciais. Você deve definir sua equipe, escolher o Product Owner (pessoa responsável pela visão do que será entregue no projeto) e o Scrum Master (quem irá orientar a equipe). Lembrando que você pode saber mais sobre esses termos neste artigo.

Após os cargos definidos aos responsáveis, deve ser elaborada a Product Backlog, que é uma lista geral detalhada de tudo que precisa ser feito para chegar ao objetivo final, como por exemplo, a finalização de um software.

Após definir todas as tarefas que devem ser executadas na Product Backlog, deve-se estimar o respectivo esforço para cada uma delas. Isso é necessário para determinar a produtividade e a velocidade do projeto.

Uma das formas utilizadas é utilizando a sequência de Fibonacci. Mas calma que não é tão complicado assim. É determinado uma estimativa de pontos para cada tarefa, como 1,2,3,5,6,13,21… É bem rápido de se acostumar. Por exemplo, uma tarefa com 1 ponto, é uma tarefa bem rápida de ser feita, provavelmente poucas horas do dia, enquanto uma tarefa com 13 pontos já demanda um tempo maior, como alguns dias.

Depois das tarefas e estimativas prontas, é a hora da primeira reunião. Ela servirá para planejar a Sprint, que pode ser de 1 ou 2 semanas geralmente. Também é definido a Sprint Backlog, onde algumas tarefas da Product Backlog irão para a Sprint a fim de serem concluídas durante o período estimado.

Normalmente são passadas as tarefas prioritárias ou tarefas que conseguirão ser concluídas naquele período. É importante todos os envolvidos concordarem com o objetivo da Sprint. Também é importante pensar na realidade: colocar três tarefas com 13 de pontuação para um colaborador realizar em uma semana, pode ser que essas tarefas não sejam concluídas. Por isso que temos a pontuação para nos indicar o quanto de esforço teremos em cada tarefa e assim ter a estimativa se ela vai conseguir ser concluída a tempo. Se não, você pode até quebrar essa tarefa em duas ou três tarefas menores.

Agora vamos entrar no ponto que entra a metodologia Kanban. Você irá utilizar o Kanban para organizar o desenvolvimento, podendo ser utilizado um quadro com post-its ou também por meios digitais, já que temos muitas plataformas que permitem isso. Se for um quadro físico ele deve ficar em um local de fácil acesso onde todos possam vê-lo e se informar. Esse quadro pode ser dividido em “A fazer – Em execução – Feito” ou você pode dividir as colunas de acordo com suas necessidades. O importante é a equipe saber bem o que significa cada coluna e sempre manter os post-its atualizados.

A partir daí teremos o Daily Scrum, uma reunião diária entre a equipe e o Scrum Master. É uma reunião rápida apenas para que cada um responda a três perguntas: “O que você fez ontem?”, “O que vai fazer hoje?” e “Quais os problemas encontrados?”. Lembrando que são respostas curtas e rápidas, mas que serve para que toda a equipe saiba em que ponto estão na Sprint. Com isso, o Scrum Master conseguirá ver se todas as tarefas serão concluídas a tempo, e claro, é ele quem irá resolver qualquer obstáculo que possa ter na equipe.

Após o período da Sprint (1 ou 2 semanas) é realizada a Sprint Review. É a reunião onde a equipe apresenta o que conseguiu evoluir durante a Sprint, podendo apresentar somente o que conseguir colocar no quadro como “feito”, ou seja, a tarefa deve estar totalmente concluída.

Por fim, temos a retrospectiva da Sprint, onde os envolvidos podem fazer uma avaliação de tudo o que aconteceu, como lições aprendidas, o que não deu certo, dificuldades, o que pode ser melhorado. É uma reunião de feedback para aprimoração do processo, podendo assim melhorar as próximas Sprints.

Feito isso, volta tudo de novo… Uma nova Sprint, novas tarefas a serem realizadas, e assim sucessivamente.

Concluindo…

Agora sim ficou mais claro onde o Kanban ajuda o Scrum e como eles se complementam. E você, já fez uso deles na sua empresa?

PMP/CAPM - Gestão da Integração
Curso de PMP/CAPM - Gestão da Integração
CONHEÇA O CURSO

Scrum como ferramenta de apoio ao gerenciamento de projetos

No post anterior, vimos como os projetos de TI podem ser beneficiados utilizando as técnicas do PMI. Foi citado também sobre a utilização de metodologias ágeis como forma de complemento para o sucesso nos projetos de TI. Veremos neste artigo mais profundamente sobre o Scrum, principal metodologia ágil utilizada no mercado.

Kanban - Usando com Scrum
Curso de Kanban - Usando com Scrum
CONHEÇA O CURSO

O que é e como funciona o Scrum?

O Scrum é uma metodologia ágil que permite manter o foco na entrega de valor para o negócio no menor tempo possível. Seu conceito principal é decompor um projeto em pequenas tarefas mais simples, chamadas de Sprints. Uma Sprint pode ser semanal ou mensal, tendo datas de início e fim bem definidas, possuindo as atividades que devem ser cumpridas dentro deste prazo.

Essa metodologia é composta basicamente por três papéis:

Product Owner ou Dono do Produto

Representa o negócio em si, além de ser o ponto central de liderança do projeto. É função dele comunicar a todos quais objetivos quer atingir. Para isso, ele precisa colaborar ativamente com o Scrum Master e toda a equipe de desenvolvimento, como por exemplo, participar das reuniões e responder rapidamente às questões realizadas pelo time. Ele é responsável por aceitar ou rejeitar o resultado dos trabalhos.

Scrum Master

O Scrum Master orienta a equipe para que as metas sejam cumpridas devidamente. É responsável para que o Scrum seja entendido e aplicado por todos da equipe. Ele também ajuda a desenvolver sua própria abordagem do Scrum, porém sempre respeitando as particularidades de cada organização.

Time de desenvolvimento

O time de desenvolvimento deve ser constituído por poucas pessoas, é recomendado no máximo 10. Aí você deve estar se perguntando o que fazer caso você tenha uma equipe de 15 ou 20 pessoas. A resposta é simples! Você sempre deve dividir sua equipe nesses casos. Uma equipe de 20 pessoas pode ser dividida em 3 equipes menores, podendo ser duas equipes com 7 pessoas e uma equipe com 6 pessoas.

Estas devem se programar para que a meta do Product Owner seja atingida. O time deve conter as habilidades e conhecimentos necessários para produzir com qualidade.

Principais artefatos da metodologia

Agora vamos fazer um passo a passo de como deve funcionar a metodologia Scrum. Primeiramente deve ser determinado quais são as funcionalidades a serem implementadas, estas ficarão em uma lista chamada “Product Backlog”, podendo ser requisitos funcionais, não-funcionais e até mesmo configurações do ambiente. A “Sprint Planning Meeting” é uma reunião na qual é decidido os requisitos, estes devem agregar valor de negócio do produto.

A Sprint deve começar com uma “Daily Scrum Meeting”, onde é priorizada as funcionalidades contidas na “Product Backlog”, selecionando as atividades que cada um da equipe irá realizar na Sprint que irá ser iniciada, priorizando as atividades mais importantes primeiro, porém devem ser tarefas que possam ser completadas durante a Sprint.

É importante ressaltar que não pode ter mudanças nas tarefas durante a realização da Sprint

Cada membro do time escolhe uma tarefa da “Product Backlog” e deve atualizar o status dessa tarefa a cada dia.

As tarefas escolhidas para a Sprint passarão do “Product Backlog” para um outro quadro, podendo ser chamado por exemplo de “Sprint 1”, “Primeira Sprint”, etc.

A comunicação é essencial no Scrum, por isso temos o “Daily Scrum”. Ele é um encontro diário rápido, normalmente de 15 minutos e geralmente realizado logo no início do dia. Basicamente todos do time respondem às seguintes perguntas:

  • O que você fez ontem?
  • O que vai fazer hoje?
  • Quais foram os problemas encontrados?

A reunião é de grande importância pois a partir daí o Scrum Master pode medir os avanços e caso tenha algum problema, pode ser resolvido de forma imediata.

Depois que a Sprint acaba ocorre a “Sprint Review”, onde a equipe apresenta seus resultados. Nesta etapa os resultados devem ser comparados com o início da Sprint. O Product Owner identifica o que foi finalizado e o que não foi, e discute com a equipe o atual “Product Backlog” onde todos colaboram sobre o que deve ser feito a seguir, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais uma Sprint. A “Sprint Review” fornece dados importantes para a reunião da próxima Sprint.

A “Sprint Retrospective Meeting”, a retrospectiva da Sprint, tem o objetivo de verificar o que funciona e o que não funciona, caso necessite será realizada adaptações no processo de trabalho. Essa reunião deve ser realizada depois de cada Sprint e todos devem participar, levantando as seguintes questões:

  • O que gostaria de começar a fazer?
  • O que gostaria de parar de fazer?
  • O que gostaria de continuar fazendo?

Após esses passos, tudo volta novamente, sendo iniciada uma nova Sprint.

Scrum Master X Gerente de Projetos

Então se eu tenho Scrum Master para gerenciar o time, eu não preciso de um gerente de projetos, certo?

Errado. O Scrum Master tem um papel de facilitador, de um líder, mas não substitui o gerente de projetos. A metodologia Scrum defende que o time deve ser auto-gerenciável, ou seja, não deve haver a necessidade de um gerente de projetos na equipe. Porém, a ideia é que isso mude e que a contribuição do gerente de projetos venha complementar o time Scrum.

O gerente de projetos e o Scrum Master tem papéis diferentes. O gerente de projetos é capacitado para liderar e trabalhar para garantir que todos os processos serão implementados corretamente. Além disso, também auxilia na prestação de contas, contribuindo para a resolução de conflitos em relação ao que é esperado pelos usuários e protege a equipe de influências externas.

Já o Scrum Master tem o seu papel de orientador, sendo que as tarefas de planejamento e execução do projeto ficam a cargo do Product Owner e da equipe do projeto. Apesar disso, ele enfrenta diversos desafios como por exemplo, a gestão do tempo para garantir a execução das atividades da melhor forma.

Quando se trata de Agile, por mais que o termo “time auto gerenciado” esteja na moda, a figura do gerente de projetos ainda é fundamental, pois um gerente de projetos pode auxiliar o Scrum Master, não o sobrecarregando com outros tipos de tarefas.

O fato é que a figura do gerente de projetos continua existindo no papel de apoiador e não de controlador. A responsabilidade total do projeto e de integração com todas as outras frentes continua sendo do gerente de projetos.

Concluindo

Apesar de tudo isso e todas as vantagens que a metodologia tem a nos oferecer, sabemos que sua aplicação é um pouco complexa, ademais, você estará lidando com pessoas. Porém, se a metodologia for aplicada corretamente e houver comunicação e planejamento entre absolutamente todos da equipe (incluindo o gerente se projetos, se houver) há grandes chances de o produto final sair conforme o planejado e em um curto prazo de tempo.

O que achou dessa metodologia? Já participou de um projeto onde o Scrum foi utilizado? Conta pra gente. =)

Gerenciamento de Projetos - Avançado
Curso de Gerenciamento de Projetos - Avançado
CONHEÇA O CURSO