Esse artigo faz parte da revista Engenharia de Software 23 edição especial. Clique aqui para ler todos os artigos desta edição



Metodologias Ágeis

Scrum na Melhoria do Gerenciamento de Projetos de Software

Um estudo sobre a implantação de Scrum para otimizar o processo de gerenciamento de projetos de software

De que trata o artigo:

Neste artigo veremos os principais problemas associados ao planejamento e à gestão de projetos de software. Em seguida, mostraremos como os planos são tratados por Metodologias Ágeis de desenvolvimento de software.

 

Para que serve:

O planejamento e o desenvolvimento de um software sob o paradigma ágil oferecem mais flexibilidade do que os modelos tradicionais para a condução de projetos de software que possuem incerteza ou instabilidade.

 

Em que situação o tema é útil:

Além de ser um modelo que permite a criação de planos flexíveis, as técnicas ágeis evitam desperdícios de tempo e esforço, pois focam em alcançar rapidamente meios de validar as características do produto em desenvolvimento e de avaliar a evolução do projeto.

                                                                                                         

Atualmente, devido à alta complexidade inerente ao desenvolvimento de software, os processos definidos fornecem um nível de flexibilidade menos adequado para que se obtenha alta produtividade e qualidade no produto final com as atuais práticas de engenharia. Muitos dos processos definidos existentes e voltados para esta finalidade, como o Rational Unified Process (RUP) da IBM (Rational), nem sempre garantem o sucesso do projeto. Tais processos de desenvolvimento de software estabelecem quais as atividades necessárias para que o produto seja construído de forma repetível (CRUZ, 2008).

Os processos empíricos devem ser utilizados sempre que os processos definidos não forem adequados devido à complexidade do projeto. Ou seja, sempre que não se conheçam todas as variáveis de entrada para que possa estabelecer um processo repetível com a mesma saída (CRUZ, 2008).

O mercado de Tecnologia da Informação (TI) está cada vez mais competitivo, onde a rapidez na entrega de sistemas com qualidade, planejamento adaptativo, flexibilidade e rápida resposta às mudanças torna-se cada vez mais desejada. Diante desse contexto, surgiu um novo conceito de metodologia ágil na gestão de projetos de sistemas, o Scrum.

Uma alternativa possível nesta situação é a adoção de um processo que seja flexível o bastante para acomodar as alterações necessárias exigidas durante o desenvolvimento do produto, e que seja baseado em inspeção e adaptação. Quanto mais próximo do limite do caos a equipe conseguir trabalhar, porém mantendo a ordem, mais competitivo e útil será o produto resultante [CRUZ (2008), MARTINS (2007), p. 252].

O Scrum é uma metodologia ágil para gerência de projetos, baseado em inspeção e adaptação, iterativo e incremental, e pode ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa. Cada iteração de trinta dias conhecida como Sprint produz um conjunto de funcionalidades (BISSI, 2007). 

Além de estudar uma metodologia que se encaixa em uma categoria já conhecida pelo mercado de TI, chamada agile development, iremos também inferir sobre as vantagens de se utilizar tal metodologia em relação a outros processos tradicionais e avaliar a aceitação do Scrum no mercado atual, identificando algumas empresas que já obtiveram sucesso com o seu uso.

O artigo está organizado da seguinte maneiro: primeiramente trataremos da pesquisa bibliográfica realizada sobre o tema, a discussão do histórico, ciclo de vida do processo do Scrum, seus principais artefatos, os papéis desempenhados pela equipe e a sua aceitação no mercado atual. Em seguida, apresentaremos uma avaliação da utilização do Scrum para a melhoria no gerenciamento de projetos de software, os resultados alcançados e as conclusões deste artigo.

Retrospecto do Scrum

Diversas metodologias foram criadas para sistematizar o desenvolvimento de software. Tais metodologias podem ser divididas em tradicionais, que enfatizam a documentação de cada processo do desenvolvimento de software, ou ágeis, que consideram um novo paradigma de desenvolvimento de software.

As metodologias tradicionais surgiram quando os mainframes ainda reinavam e não existiam ferramentas de apoio ao desenvolvimento, o custo de realizar algum tipo de alteração era altíssimo e a documentação tinha de ser muito mais forte. Elas estabelecem uma sequência de etapas, onde cada etapa tem um início e um fim definidos com documentação rígida a ser seguida entre uma etapa e outra, de forma que sem a documentação o processo não avança (FERSTE, 2009).

Percebeu-se que os modelos tradicionais ocultavam uma série de problemas sérios, como:

·         Problema para entrega dentro do prazo considerando o escopo de todas as funcionalidades solicitadas [Standish Group, 1995];

·         Grande número de erros dado que a metodologia tradicional dificulta a execução de alterações durante o processo de desenvolvimento;

·         Um artigo famoso da época: “No Silver Bullet”, de Brooks [1987], demonstrou que a ideia de especificar totalmente o software antes de seu início é totalmente impossível.

         

São considerados processos tradicionais, ou pesados, de desenvolvimento de software, aqueles que tentam prever todos os requisitos do sistema para assim ser feito um planejamento prévio de como o sistema irá atuar. Este planejamento rigoroso é representado como documentos que guiarão todo o processo de desenvolvimento (ROCHA; OLIVEIRA; VASCONSELOS, 2004).

Os processos tradicionais se caracterizam por focar a análise de sistemas, investindo esforços para a obtenção de artefatos de projeto tão completos e precisos quanto possível: relatórios, documentos e diagramas. Grande parte dos processos tradicionais em uso atualmente tem como base os modelos de diagramas da Unified Modeling Language (UML), como é o caso do RUP (GALDINO, 2006).

Os processos ágeis surgiram como uma alternativa aos processos tradicionais. Tais projetos partem da premissa de que se devem permitir mudanças nos requisitos a qualquer tempo. Desta forma, o planejamento é feito durante todo o processo, ao mesmo tempo em que é feita a codificação: não há um passo dedicado exclusivamente ao planejamento (ROCHA; OLIVEIRA; VASCONSELOS, 2004).

Em fevereiro de 2001 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas, reuniram-se ...

Quer ler esse conteúdo completo? Tenha acesso completo