Tudo o que você precisa saber sobre o Scrum: benefícios, aplicabilidade e exemplos práticos
Uma pesquisa realizada pelo Standish Group em 2015 sugere
que projetos de desenvolvimento de software que utilizam Scrum ou métodos
similares têm 3,5 vezes mais chances de sucesso. Eu li sobre essa pesquisa no
livro "Scrum: Gestão Ágil para Produtos de Sucesso". Aliás, este
artigo tem como base esse livro. (Veja as fontes de referência no final deste
artigo).
Uma curiosidade: o Standish Group é uma empresa de
consultoria especializada em análise de projetos de tecnologia da informação.
Eles conduzem pesquisas para avaliar o sucesso de projetos de software e
identificar fatores que contribuem para o êxito ou fracasso.
A pesquisa indica que projetos que adotam o Scrum ou
métodos similares têm mais chances de sucesso. Outros métodos ágeis, como
Kanban e Extreme Programming (XP), também podem ser considerados "métodos
similares".
A pesquisa se concentra especificamente em projetos de
desenvolvimento de software. Não encontrei nenhuma pesquisa citando o uso de
Scrum em outras áreas além da criação de softwares.
Embora o Scrum seja amplamente utilizado no desenvolvimento
de software, sua aplicação não se limita apenas a essa área. O Scrum foi
originalmente desenvolvido para gerenciar projetos complexos de software, mas
suas práticas e princípios têm sido adaptados e adotados em outras áreas, como
gerenciamento de projetos, marketing, educação, pesquisa científica, entre
outras.
1 - Gerenciamento de Projetos: O Scrum tem sido aplicado
com sucesso em projetos de diversos setores, como construção civil, engenharia,
eventos, marketing, consultoria, entre outros. A abordagem ágil do Scrum, com
seus ciclos iterativos de trabalho e foco na colaboração e entrega de valor
incremental, pode beneficiar projetos em várias indústrias.
2 - Marketing: Equipes de marketing têm adotado o Scrum
para gerenciar campanhas, lançamentos de produtos e desenvolvimento de
conteúdo. A natureza adaptativa do Scrum permite que as equipes de marketing
respondam rapidamente às mudanças no mercado e obtenham feedback contínuo dos
clientes.
3 - Educação: O Scrum também tem sido adotado no campo da
educação. Algumas escolas e universidades têm aplicado princípios ágeis em
salas de aula, incentivando a colaboração, autogestão e entrega incremental de
resultados de aprendizagem.
4 - Pesquisa
científica: Pesquisadores têm explorado o uso do Scrum para gerenciar projetos
de pesquisa científica. A abordagem ágil pode facilitar a colaboração entre os
membros da equipe, a adaptação rápida às descobertas e a entrega de resultados
iterativos.
Inclusive, já vi (mas ainda não tive a oportunidade de ler)
um livro chamado "Scrum para Escritores".
Mas antes de falar mais sobre o Scrum, quero primeiro falar
sobre por que os projetos falham.
Vou abordar os problemas primeiro para, em seguida,
apresentar a solução.
Quando alguém ou alguma empresa te contrata ou contrata a
sua agência para criar um software, são estabelecidas três coisas:
Custo;
Prazo;
Qualidade.
A pessoa/empresa que te contrata passa a descrição do
software que ela precisa e te pergunta quanto custa para você fazer esse tipo
de software e quando estará pronto.
Se sua casa precisa de um portão, quando você procura um
serralheiro para construí-lo, a primeira coisa que você pergunta (depois de ter
passado as medidas do portão) é: quanto custa?
Depois que o serralheiro passa o preço, ele deve dizer o
prazo em que o portão ficará pronto.
O Celso Russomano sempre diz que quando você contrata um
serviço, o prestador do serviço deve dizer o preço e o tempo em que o serviço
estará pronto. Está na lei.
CDC, Art. 40 – O fornecedor de serviço será obrigado a
entregar ao consumidor orçamento prévio discriminando o valor da mão-de-obra,
dos materiais e equipamentos a serem empregados, as condições de pagamento, bem
como as datas de início e término dos serviços.
Quanto à qualidade, quando o portão estiver pronto, você
espera que o portão esteja em boas condições, sem ferrugem, com boas soldas,
que não caia sozinho na sua cabeça...
Estou mostrando o problema, agora vou te mostrar a solução
que pode te ajudar com seus problemas: Scrum.
É muito importante que você saiba que não existe uma
solução única que resolva todos os problemas.
Para começar, como seria possível criar uma solução única
que resolva todos os problemas? Quais são todos os problemas? Como saber se
foram catalogados todos os problemas que podem ocorrer? É possível ter
conhecimento de todos os problemas que podem ocorrer?
Segundo: supondo que todos os problemas tenham sido
catalogados. É possível criar uma única e exclusiva solução que resolva todos
esses problemas? Como saber se essa solução realmente resolve todos os
problemas? Mesmo que reuníssemos especialistas de diferentes áreas, como
engenheiros, educadores, pessoal de marketing, etc., e todos esses
especialistas dissessem: "Esta solução resolveu todos os meus problemas na
minha área de atuação", isso comprovaria que essa solução resolve todos os
problemas?
Scrum tem sido muito utilizado em outras áreas que não
sejam a criação de software. Mas isso não significa que ele consiga resolver
todos os problemas.
Scrum funciona muito bem em combinação com outras técnicas.
Normalmente, na criação de algum produto, é definida uma
documentação longa (já ouvi dizer que essa "longa" é "muito
longa") com todas as funcionalidades (ou seja, todas as funcionalidades)
que o produto terá quando estiver pronto.
Ou seja, se o cliente decidir que o produto terá mudanças
no meio do caminho, essas mudanças não serão muito bem vistas.
Já ouvi casos de equipes passando meses criando
documentação e, somente depois dessa documentação extensa, começarem a criar o
produto.
Depois de um longo tempo preparando a documentação, quando
a equipe começa a criar o produto, o cliente decide fazer algumas modificações.
A equipe leva meses criando a documentação com todas as
funcionalidades e, somente então, começa a criar o produto. Então, o cliente
pede para fazer modificações. Que absurdo!
A equipe tem que parar a criação do produto e voltar para a
documentação para fazer as modificações. E se o cliente pedir mais
modificações?
Por isso, é melhor que o cliente saiba antecipadamente
quais são todas as funcionalidades do produto, meses antes de estar pronto.
Essa prática nociva de definir e detalhar o escopo antes de
iniciar o desenvolvimento do produto é conhecida como BDUF (Big Design Up
Front).
Outra forma de criar o produto é em ciclos curtos, dessa
maneira, quando o cliente decide fazer modificações, essas modificações são
fáceis de serem implementadas no produto. Apesar do produto receber feedback ao
longo do desenvolvimento, ele só sofrerá algum tipo de uso real após um longo
período.
E por que isso acontece? Eu gostaria de saber.
Em ambos os casos, o usuário receberá o produto somente no
final do projeto ou após a conclusão de uma grande etapa.
Dessa forma, investimos muito tempo no trabalho sem obter
qualquer retorno, que é esperado apenas como resultado dessa entrega. Não há,
no entanto, qualquer garantia de que a entrega realmente atenderá às
necessidades dos usuários e, portanto, gerará sequer algo próximo do valor
esperado.
Somente quando o usuário tem partes do produto é que ele
pode nos dar um feedback melhor.
Por essa razão, buscamos realizar entregas para usuários
reais desde cedo e com frequência.
E quando, por exemplo, tomamos decisões equivocadas sobre o
produto, esse feedback obtido rapidamente a partir do uso gera transparência
sobre o problema e permite correções de rumo.
Imagine que uma equipe de desenvolvimento de software
esteja criando um aplicativo de delivery de comida. Eles passam meses
trabalhando no projeto, planejando todos os recursos e funcionalidades com base
em suas próprias suposições e entendimento do que os usuários desejam. Durante
todo esse tempo, não há interação com os usuários reais do aplicativo.
Finalmente, quando o aplicativo é lançado, descobre-se que
muitas das funcionalidades planejadas não são tão úteis ou intuitivas quanto o
esperado. Os usuários podem enfrentar dificuldades na navegação, no processo de
pedidos ou até mesmo na realização de pagamentos. Essas falhas só são
descobertas quando o produto é entregue na íntegra.
No entanto, se a equipe adotar uma abordagem ágil como o
Scrum, eles buscarão realizar entregas para usuários reais desde cedo e com
frequência. Isso significa que eles dividiriam o desenvolvimento do aplicativo
em incrementos menores e entregariam partes funcionais para os usuários
testarem e fornecerem feedback.
Com essa abordagem, se a equipe tomasse uma decisão
equivocada em relação a uma funcionalidade específica, o feedback obtido
rapidamente a partir do uso do produto permitiria que eles identificassem o
problema e fizessem correções de rumo antes que o aplicativo estivesse totalmente
concluído. Isso gera transparência sobre os problemas e possibilita melhorias
contínuas com base nas necessidades reais dos usuários.
Assim, o Scrum busca evitar o cenário em que se investe
muito tempo em um trabalho que pode não atender às expectativas dos usuários,
permitindo que haja interação precoce e frequente com os usuários, o que leva a
um produto final mais alinhado às suas necessidades reais.
Referências:
0 Comments
Postar um comentário