Plataforma SPOTIFY >
https://open.spotify.com/show/7rLe4pURFDPSpVHS7zDuA1
Plataforma RADIO PUBLIC >
https://radiopublic.com/h12s-podcast-8X2aYk
Plataforma ANCHOR >
https://anchor.fm/haroldo-m-c-simoes/
...........................................................
Justiça seja feita, esse termo Sprint Creep apareceu no artigo de Bart Gerardi, de setembro de 2020, chamado What About Sprint Creep? (que traduzindo seria E quanto ao Sprint Creep?), publicado no website projectmanagement.com.
Link para acessar esse artigo >>
https://www.projectmanagement.com/articles/654814/What-About-Sprint-Creep-
Lembrando que esse website é dedicado ao gerenciamento de projetos e
para acessar os conteúdos completos dos materiais ali publicados é necessário
se registrar e fazer o login. Para os seguidores do blog eu posso enviar um PDF
desse artigo, bastando apenas o envio de um email para o enderêço h12sblog@gmail.com .
O texto fará referências aos papéis, artefatos e cerimônias encontradas
no método Scrum de gerenciamento ágil de projetos. Para os iniciantes, vou
descrever esses papéis, artefatos e cerimônias de forma geral e resumida aqui,
em seguida. No final desse texto você poderá encontrar sugestões de links com mais
detalhes e informações adicionais sobre o método Scrum.
No Scrum são estabelecidos os Sprints. Um Sprint é um ciclo ou período
de tempo (também chamado de “Time Box”) em que um conjunto de atividades deve
ser executada. O Sprint é o engrenagem principal do mecanismo que movimento o
Scrum.
Em linhas gerais, se eu tenho um produto para ser desenvolvido, eu não
faço esse desenvolvimento todo de uma vez. Eu divido o produto em partes e
executo essas partes em ciclos ou sprints. Tipicamente, um sprint tem duração
de 1 a 4 semanas.
O Product Backlog é a lista de requisitos e funcionalidades desejadas
para desenvolvimento de um produto – que podemos considerar como inteiro e
completo. Quando eu divido o produto em partes, eu também divido o Product
Backlog em partes. Cada uma dessas partes é registrada em um Sprint Backlog.
O Sprint Backog é, portanto, uma lista de itens selecionados dentro do
Product Backlog (formando uma parte do produto) que a Equipe planeja concluir
dentro do Time Box de um Sprint. Então, ainda em linhas gerais, tudo se passa
como se o projeto iniciasse e fosse avançando, com a equipe executando
diferentes partes do produto dentro dos Sprints. A equipe executa um certo
número de Sprints até que o produto completo é concluído.
O Scrum considera 3 papéis fundamentais: o Product Owner, o Scrum Master
e a Equipe do projeto.
O Product Owner (ou Dono do Produto) é o responsável por gerenciar o
Product Backlog, com função de priorizar as entregas. Por sua vez, o Scrum
Master é o responsável por garantir que todos trabalhem e sigam as regras do
processo, participem das suas cerimônias e usem corretamente seus artefatos. E
finalmente a Equipe é a responsável pelo desenvolvimento e entrega do produto.
São artefatos obrigatórios do Scrum: o Sprint Backlog e o Product
Backlog.
São cerimônias do Scrum – a Sprint Planning (é a reunião de planejamento
do sprint), As Daily Meetings (são reuniões diárias de acompanhamento do
trabalho que está sendo executado), a Sprint Review (é uma revisão sobre o que
foi feito durante o sprint) e a Sprint Retrospective (é uma retrospectiva do
sprint sobre como trabalhamos e o que pode ser melhorado).
Bem, continuando, Gerardi menciona em seu artigo que nos projetos com gestão
tradicional um gerente de projeto precisa ficar atento
e tentar evitar mudanças de requisitos, novas solicitações e outras adições a
um projeto em andamento - todas ocorrências comuns conhecidas como “scope
creep”. Na verdade, o “scope creep” é frequentemente considerado um grande
risco para um projeto e aparece em relatórios amplamente divulgados como uma
das razões pelas quais os projetos não têm sucesso. Se um gerente de projeto
não for cauteloso, os requisitos podem se multiplicar, causando atrasos nas
entregas, atrasos no cronograma, estouro do orçamento ou até o cancelamento do
projeto.
Sim, o
“scope creep” é um problema para os projetos tradicionais, com planos
estabelecidos no início e, com orçamentos e recursos fixos. No entanto, de
acordo com Gerardi, isso não deve ser um problema para projetos que operam com
os princípios ágeis. Ainda, segundo o autor, em
círculos ágeis, o “scope creep” é às vezes chamado de “sprint creep” – com
novas tarefas sendo inseridas em um sprint já planejado ou com as tarefas
existentes recebendo requisitos expandidos.
Nos projetos
tradicionais, os líderes são, geralmente, resistentes a esses tipos de
mudanças. Eles trabalham com um processo de Controle Integrado de Mudanças que
estabelece que devemos fazer uma revisão, ou melhor, uma análise dos impactos da
mudança nos custos, no cronograma, na qualidade, no que deverá ser replanejado,
e assim por diante. Essa análise, portanto, é necessária para que se conheça os
impactos gerados pela mudança. Será necessário saber se a mudança solicitada
vale a pena e se a mesma traz benefícios para o projeto. O resultado dessa
análise nos leva a conhecer as mudanças aprovadas e, consequentemente, resulta
em uma atualização do plano de gerenciamento do projeto.
Gerardi
afirma que embora essa abordagem às vezes seja necessária em um projeto não
ágil, ela é inadequada para uma equipe que trabalha de maneira ágil. Em vez de
resistir à mudança, uma equipe ágil a acolhe e descobre como se adaptar a ela.
É
nesse ponto de seu texto que o autor apresenta como pensa que um gerente deve
tratar as solicitações de mudança em um projeto ágil. Então vejamos:
“No Agile, não
deve haver algo como “sprint creep”, apenas "novo trabalho" - o que
significa trabalho que ainda não foi concluído. Isso é igualmente verdadeiro se
for uma nova história de usuário, um novo requisito funcional ou não funcional
ou mesmo uma nova ideia que não surgiu na última vez que o backlog foi
preparado ou o sprint planejado. Uma equipe ágil está sempre dando
boas-vindas a novos trabalhos em seu backlog ou considerando novas ideias para
inclusão em um lançamento. Isso não significa que a equipe deva aceitar
toda e qualquer sugestão ou interrupção, ou simplesmente adicionar um novo
trabalho sem análise, no entanto”.
Essa parte
me fez acender um sinal de alerta. Como assim, sempre dando boas-vindas a novos
trabalhos no seu backlog? Dar boas-vindas significa dizer sim, pode entrar!
Afinal de contas, ninguém dá boas-vindas dizendo sinto muito, você não pode
entrar. Se, por outro lado, eu tiver que analisar antes de dizer sim, não estou
“sempre” aceitando novos trabalhos. Bem, vamos seguir o texto e ver onde ele
vai nos levar.
“Aqui estão
algumas idéias sobre como lidar com novas solicitações durante um sprint.
Solicitações
de mudança que não ajudam a atingir a
meta do sprint - Provavelmente é óbvio, mas para considerar assumir um
novo trabalho em um sprint, ele deve estar alinhado com o objetivo geral do
próprio sprint. Se algo novo chegar que não ajudará a atingir a meta, mas ainda
for considerado urgente ou de maior prioridade, a equipe e o Product Owner
devem considerar o replanejamento de todo o sprint. Raramente faz sentido
distrair a equipe com um trabalho que não esteja alinhado com o propósito geral
e quase sempre levará ao fracasso da meta. Certamente pode haver exceções, como
uma solicitação muito pequena ou talvez uma solicitação de operações ou
segurança da informação que possa ser tratada, mas novas tarefas relacionadas a histórias de usuário devem aguardar um
Sprint futuro”. Me parece que esse
ponto foi tratado com muita clareza e eu concordo plenamente com essa
abordagem. Continuando:
“Solicitações
que estão alinhadas com a meta
- Se a solicitação ajudar a atingir o objetivo geral, o Product Owner e a
equipe devem discutir o valor relativo do novo item. Se o valor for realmente
maior do que o que a equipe está trabalhando atualmente, então a equipe deve
pelo menos estar aberta à ideia de enfrentá-lo”.
Lembrando
aqui que, dependendo de cada caso, a nova tarefa poderá ser simplesmente
inserida junto com as que já estavam sendo executadas ou uma ou mais tarefas
que estavam em execução poderão ser removidas, para dar espaço a essa nova
tarefa. De qualquer modo o planejamento do sprint deverá ser refeito e isso
implica em interromper o trabalho que vinha sendo feito para redefinir o que
será executado durante o sprint. Continuando:
“Se essa
solicitação de mudança – que é uma nova história de usuário – for aceita e
inserida no sprint o gerente de projetos ainda deverá responder as seguintes
perguntas:
A
equipe ainda sente que o sprint é alcançável? O Product Owner concorda que o
novo sprint é de maior valor do que o antigo? Existe algum outro motivo pelo
qual o custo da interrupção é menor do que o valor criado?
Agora
é a hora de considerar todas essas coisas e determinar se o novo item pode ser
adicionado e o que deve ser removido”.
Gerardi
nesse ponto do texto discute a urgência da mudança. Continuando: -
“Mesmo que a
nova história seja considerada de alta prioridade e de alto valor, ainda existe
o custo de interromper um sprint em execução para adicionar essa nova história,
com a discussão na equipe para determinar opções e escolher um novo caminho.
Além
de falar sobre a prioridade e o valor da solicitação de mudança, a equipe e o
Product Owner também devem falar sobre sua urgência. Se a nova história for
inserida no próximo sprint, os clientes a usarão imediatamente? Existe uma
razão pela qual a história precisa ser acelerada? Qual será o impacto negativo
para o produto ou para o cliente se a história esperar até o próximo sprint?
O
autor conclui afirmando que:
“Em um projeto
não ágil, o escopo deve ser estritamente gerenciado e o trabalho inesperado ou
“scope creep” pode criar um risco para a entrega geral do projeto. Em um
projeto de execução ágil, o oposto é verdadeiro. Novas solicitações não devem
ser temidas, elas são apenas novos itens de sprint que podem ser considerados
para adição a um sprint. Contanto que um novo item tenha tempo para ser
adequadamente preparado e analisado, esteja alinhado com a meta geral do
sprint e forneça valor imediato ao produto ou cliente, vale a pena pensar em
adicionar, mesmo em um sprint em execução.
E certas coisas podem nem
mesmo ser consideradas adições, mesmo que sejam itens realmente novos”.
Agora,
aqui entre nós: Ter um critério significa seguir o seguinte raciocínio: - Eu
aceito se esse novo trabalho ou se essa nova história de usuário passar pelos
critérios definidos para que algo novo seja aceito.
Caso
contrário, esse novo trabalho não será aceito. Isso, sem enrolação, é seguir um critério de aceitação para que algo
novo seja incluso no sprint.
Então,
me parece que na ânsia de se mostrar
alinhado aos princípios ágeis, o autor escolheu, do ponto de vista prático,
as ideias contidas no bom e velho processo de Controle Integrado de Mudanças do
guia PMBOK. A propósito, são todas ótimas ideias do autor apresentadas no
artigo.
Os
gerentes de projeto sempre buscaram usar as melhores práticas, ferramentas e
técnicas para alcançar o melhor resultado, para tornar o projeto bem-sucedido,
dentro de certa realidade e circunstâncias, com restrições e recursos
disponíveis (dinheiro, tempo, pessoas, tecnologia). Eles (e elas) usaram essa abordagem
porque fazia mais sentido, era adaptada às necessidades específicas de cada
projeto e produzia os resultados desejados. Portanto, não há nenhum demérito em
usar os princípios do processo de Controle Integrado de Mudanças para tomar uma
decisão sobre uma solicitação de mudança em um projeto ágil.
Para
gerenciar um projeto é necessário utilizar o conhecimento de múltiplos domínios
e campos do conhecimento, além de manter a mente aberta para perceber e descobrir
o que funciona. Fazemos o que funciona e quando não funciona, tentamos
descobrir algo diferente. Se nos esquecemos desse princípio, estaremos
colocando nossos projetos em risco. Bem, então tá falado. Até a próxima.
..................................................
Uma rápida leitura em http://h12sse.blogspot.com/2014/05/mais-um-pouco-de-scrum.html
pode ajudar a entender os Sprints e o trabalho do Product Owner no Scrum.
Para mais informações acesse > https://blog.trello.com/br/scrum-metodologia-agil ou
https://www.scrum.org/
Nenhum comentário:
Postar um comentário
Inclua seu comentário: