Este documento procura introduzir práticas e abrangência da Metodologia Ágil, SCRUM. Modelo aplicado pela primeira vez por Jeff Sutherland em 1993, mais tarde, meados de 1995, Ken Scwaber refinou a metodologia baseando na sua experiência em desenvolvimento de sistemas e processos.
Scrum aplica-se tanto a pequenos quanto a grandes projetos. Aplicado inicialmente no desenvolvimento de software, área onde tradicionalmente os projetos sofrem constantes mudanças de escopo, devido a mudanças no ambiente de negócios, inovações, legislação, concorrência e outros fatores, Scrum vem sendo aplicado em outras áreas, atingindo bons resultados, na maioria dos casos.
Scrum trabalha com a entrega de incrementos, ou seja, o desenvolvimento e entrega de partes de um todo a ser completado após ciclos que contam também com planejamento destes incrementos, priorização, estimativas e revisões do que foi realizado em cada um. Ciclos estes que buscam uma melhoria continua do produto, uma sinergia entre contratante e contratado, seu objetivo principal é qualidade e entrega de produto com valor real e imediato ao cliente.
Ainda assim, implantar Scrum nem sempre é uma tarefa simples. Diversos fatores contribuem para simplificar ou, em alguns casos, complicar o processo. No mínimo, são pontos que precisam de atenção.
Palavras Chave: Scrum, Product Owner, Scrum Master, Gerência de Projetos Ágeis, Time, Iterativo, Empírico
Scrum é um framework, uma estrutura bem definida e fundamentada no processo empírico, atende uma gama de áreas além da TI para gerenciamento de projetos. Um framework não pode ser confundido com um guia passo-a-passo, com respostas definitivas para resolução de problemas mais específicos de projetos. Mas pode, sim, dar vida nova ao ciclo de desenvolvimento de software, otimizando a previsibilidade e controlando riscos. É sustentado pelos pilares da transparência, inspeção e adaptação. Buscando visibilidade nos resultados, detecção de variações inaceitáveis no processo e suplantando-os.
O Scrum não é a única metodologia ágil existente, nem precisa ser o único framework a ser utilizado por equipes de desenvolvimento. Há outras opções com nível maduro de implementação, como por exemplo: o eXtreme Programming (XP) e o FDD (Feature Driven Development). Também existem metodologias complementares, como o desenvolvimento orientado a testes (TDD). Demais metodologias ágeis podem e devem ser incorporadas e adaptadas ao Scrum (segundo alguns agilistas), elevando o nível de maturidade em pontos mais específicos, levando em conta o foco de cada um.
O ritmo de adoção de metodologias ágeis nas empresas é maior do que o mercado de trabalho pode oferecer. Embora o Brasil já seja um dos quatro países que mais têm pedidos de certificação na Scrum Alliance, a principal autoridade no assunto, as companhias penam para encontrar profissionais prontos. Está aí uma boa oportunidade de trabalho. (BARRETO, 2009).
Jim Coplien certa vez observou para Jeff, “Todos irão gostar de Scrum; ele é o que já fazemos quando estamos pressionados contra a parede” (SCHWABER; SUTHERLAND, 2008-2009, p. 3).
Cenário atual
O que uma empresa produz é resultado de como ela está estruturada. Quem tem autoridade para dizer como deve ser a estrutura de uma empresa é quem está no topo. Então, a estrutura de qualquer empresa é, no fim das contas, o resultado do modo de pensar, da mentalidade, de quem está no comando. A mentalidade da maioria dos empresários, diretores e gerentes no mundo inteiro é, com raríssimas exceções, arcaica e incompatível com o trabalho de desenvolver softwares (TELES,2008).
Apesar da grande evolução que ocorreu com o surgimento de novas metodologias, novos frameworks, no cenário atual ainda temos certo receio por novas propostas, mesmo que aqueles a que estamos acostumados estejam defasadas. Metodologias tradicionais, primam por escopos fixos, excessos de documentos e que não são adaptáveis a mudanças inerentes ao negócio. Pecam na qualidade, pois focam na urgência da entrega do produto, que por vezes já está com o prazo esgotado.
Projetos tradicionais de desenvolvimento de software nos forçam a prever tudo o que será desenvolvido com o máximo de precisão no início do projeto. Sabemos que mudanças são inerentes aos negócios e por isso o produto inicial solicitado pelo cliente, com certeza não será, no final, o que ele realmente queria.
Tal divergência entre escopo e produto entregue ocorre por inúmeros motivos, que vão do cliente até a equipe engajada no projeto e passa por demais níveis hierárquicos da empresa. Alteração de regras de negócio da empresa movida pela concorrência, pouca atenção dada ao projeto pelo contratante, prioridade equivocada pela equipe de desenvolvimento, são alguns exemplos.
Um projeto ágil pode se adaptar as mudanças de um mercado, uma empresa, ou um cliente, efetivamente melhor do que os projetos tradicionais.
A demanda por qualidade de software tem motivado a comunidade de software para o desenvolvimento de modelos. Um software de qualidade é fácil de usar, funciona corretamente, é de fácil manutenção e mantém a integridade dos dados para evitar possíveis falhas, fora ou não, do seu controle. Para o usuário final as falhas se apresentam sem aviso prévio, gerando um impacto econômico e social por vezes irremediáveis.
A qualidade é hoje o grande motivador de todas as áreas de atividade humana, todos querem oferecer e receber produtos e serviços de qualidade.
Um software de qualidade oferece segurança da informação, disponibiliza serviços essenciais, gera competitividade.
Dada preocupação tanto de clientes quanto de fornecedores com a baixa qualidade dos softwares e o aumento da demanda por modelos de qualidade de software, o mercado vem buscando cada vez mais adotar um modelo que atenda às suas necessidades e a de seus clientes.
Métodos ágeis sempre atribuem forte foco na qualidade do que está sendo desenvolvido. Não se limitando apenas nos testes de aceitação do cliente, mas também adotando práticas de desenvolvimento que garantam alta qualidade técnica.
Evolutiva na gerência de projetos
Por que projetos falham?
Mesmo em projetos executados com sucesso, eles podem ainda não trazer benefícios para o negócio. O problema é uma falta de alinhamento entre os objetivos do negócio e as atividades de TI. Os stakeholders medem o sucesso ou insucesso de um projeto por sua contribuirão aos principais objetivos de negócio e ao resultado final obtido pela empresa.
Ferramentas tradicionais de gerenciamento de projetos falham ao não serem orientados para uma comunicação clara e consistente entre cliente e fornecedor e não fornecerem informações em um formato útil para tomada de decisões executivas.
No livro The Artof Lean Software Development: A Practical and Incremental Approach de Curt Hibbs, Steve Jewett e Mike Sullivan, no capítulo 2 os autores fazem a pergunta: se está claro (através de diversas pesquisas e casos reais) que o desenvolvimento tradicional e cascata frequentemente falha e que o desenvolvimento ágil e lean (enxuto) aumenta as chances de sucesso, o que impede as pessoas e organizações de fazer a troca?
Os autores acreditam em dois principais motivos para isso: medo e confusão. Pessoas que se identificam com práticas ágeis, esquematizam na mente como vender a promessa de alta produtividade e qualidade. Estas correm o risco de interferir no “conforto” adquirido, simplesmente não tem a experiência para reconhecer o impacto que essas e outras ações terão em suas promessas. Somado a isso, o sentimento de confusão ao se deparar com centenas de artigos ou livros, que apresentam inúmeras opções (HIBBS; JAWETT e SULLIVAN,2009, p. 24); basicamente, as pessoas preferem não mexer em time que aparentemente está ganhando.
Mostrar benefícios comprovados com casos de usos, de empresas conhecidas no mercado, e conseguir comprometimento de toda uma organização é essencial para eliminação do medo.
Mas não se pode atribuir o problema apenas ao medo, pois a maioria dos projetos de software falha por falta de clareza, que podem ser: sobre funções pessoais, responsabilidades e requisitos. E também por inabilidade para acompanhar o que ocorre em cada um dos diferentes passos do ciclo de vida da aplicação.
Além disso, podemos citar também a mudança de cultura, a empresa e as pessoas devem estar dispostas a lidar com aprendizagem e inevitáveis fracassos para obter o conhecimento necessário. Um ambiente pré-disposto a isso está pronto para buscar pontos de melhorias e não culpados pelos insucessos.
...
