RESUMO: No desenvolvimento de software há uma forte tendência para o desenvolvimento ágil de aplicações devido a um ritmo acelerado de mudanças. Este contexto tem causado crescentes frustrações nas organizações devido aos planos, especificações e documentações pesados, muitas vezes impostos por critérios de conformidade dos modelos de maturidade. Organizações que vinham adotando métodos clássicos, como o modelo em cascata (waterfall) estão cada vez mais interessadas na possibilidade de adoção de métodos ágeis. Este trabalho apresenta uma abordagem ágil para o Ministério Público de Minas Gerais baseada nos métodos de Programação Extrema, Scrum e Kanban. 

Palavras-chave: Gerência de Projetos, Programação Extrema, Scrum e Kanban.

INTRODUÇÃO:

A tecnologia da informação evidencia-se pela contínua expansão e por uma forte concorrência entre empresas ligadas a esse setor. Em virtude disso, para que essas entidades possam permanecer nesse meio, elas precisam desenvolver produtos e serviços que, de algum modo, se destaquem e conquistem a credibilidade de seus clientes [1]. Um item fundamental para atingir esse objetivo, independentemente do tipo do produto a ser produzido, denomina-se qualidade. A qualidade de um software está diretamente relacionada com os níveis de qualidade dos processos envolvidos no desenvolvimento [2].

A engenharia de software é uma área da tecnologia da informação responsável por esses processos de construção de software, abrangendo as técnicas empregadas na especificação, projeto, desenvolvimento e testes, tendo como objetivo um produto de qualidade, ou seja, que atenda as expectativas para as quais está sendo desenvolvido de forma organizada, produtiva e mais econômica possível [3]. Desta forma, para que esses processos possam atingir a qualidade desejada, torna-se imprescindível o uso de técnicas e metodologias de gerência de projetos para o planejamento e posterior controle desses processos.

De acordo com Martins, em [4], na engenharia de software existe dois tipos de processos ou métodos para controlar o desenvolvimento de um projeto de software: os métodos clássicos (ou definidos) e os métodos ágeis (ou empíricos).

Os métodos clássicos determinam o que deve ser feito, quando e como. O contexto do projeto, as atividades necessárias para execução deste e o prazo de entrega são definidos no início do projeto. Como exemplo de método clássico, tem-se o modelo em cascata (waterfall) com fases distintas de especificação de requisitos, projeto e desenvolvimento, todas agrupadas em níveis. A maior dificuldade desse modelo é acomodar mudanças com o projeto já em andamento, pois um nível depende do outro, sendo assim, caso um nível qualquer precise ser alterado, o nível anterior deverá ser refeito. Já os métodos ágeis têm representado alternativas às modalidades tradicionais de desenvolvimento e gestão de projetos de softwares [5], suportando projetos com requisitos instáveis, e se fundamentam em 4 super-valores:

a)    Indivíduos e Interações mais importantes que processos e ferramentas.

b)    Software Funcional mais importante que documentação elucidativa.

c)     Presença do cliente mais importante que negociação de contrato.

d)    Respostas às mudanças mais importantes que seguimento de plano.

O presente artigo realiza um estudo da viabilidade de utilizar a combinação de alguns métodos ágeis - Programação Extrema, Scrum e Kanban -, no gerenciamento de projetos de software do Ministério Público de Minas Gerais. O Ministério Público é uma instituição permanente, essencial à função jurisdicional do estado, incumbindo-lhe a defesa da ordem jurídica, do regime democrático e dos interesses sociais e individuais indisponíveis.

MÉTODOS ÁGEIS PARA GERENCIAMENTO DE PROJETOS:

Um dos aspectos mais interessantes dos métodos ágeis é sua estruturação conceitual. Oficialmente são quatro declarações de valor que nos inspiram um pequeno conjunto de princípios que nos guiam e uma grande quantidade de métodos que nos ajudam a estabelecer “como” as coisas devem ser feitas. Cada método estabelece seu próprio conjunto de pressupostos e práticas. E são comuns equipes de projeto adotarem práticas de diferentes métodos enquanto os adaptam às suas realidades.

A Programação Extrema [6], ou simplesmente XP, é uma metodologia leve, eficiente, de baixo risco, flexível, preditiva, científica e “divertida” de se desenvolver software. XP é adequada para ser utilizada por equipes de desenvolvimento pequenas ou médias em projetos com requisitos mal definidos ou que sofrem mudanças continuamente.

As equipes que utilizam XP devem ter entre 2 e 10 desenvolvedores e seus membros devem ser capazes de executar testes no sistema diariamente. Um dos criadores do método XP, Kent Beck, argumenta que o XP é “extremo” (extreme) dando grande ênfase a atividades reconhecidamente boas pela comunidade. Dentre as principais atividades do XP pode-se destacar:

a)    Revisão de código: Código é revisado a todo momento, ainda enquanto está sendo escrito.

b)    Testes de unidade e aceitação: todos os envolvidos no produto deverão testar o produto o tempo todo. Desenvolvedores (testes de unidade), Clientes (testes funcionais)

c)     Simplicidade no projeto: o projeto do software é o mais simples possível para suportar as funcionalidades do software em um determinado momento.

d)    Testes de integração: São feitas várias integrações durante um mesmo dia. Para cada pequena parte de componente que é desenvolvida, há uma integração desse componente ao produto.

e)    Iterações curtas: Ciclos de desenvolvimento curtos são bons por que permitem descobrir com antecedência problemas no projeto e agregar valor ao negócio do cliente com maior rapidez. No XP, as iterações são muito curtas, podendo ser de apenas alguns dias.

O Scrum é um arcabouço para desenvolvimento de produtos complexos fundamentado na teoria empírica de controle de processos, que é suportada pelo tripé formado por transparência, inspeção e adaptação. A transparência garante que todos os elementos do processo devem ser visíveis e compreendidos pelos envolvidos no processo. Já a inspeção defende que os elementos do processo devem ser monitorados com frequência suficiente para que variações inesperadas sejam detectadas e as intervenções devidas sejam realizadas. Por fim, a adaptação consiste em ajustar o processo sempre que ocorram variações indevidas. A adaptação deve ser rápida para diminuir o impacto negativo das variações na qualidade e também para que novos desvios sejam evitados.

Scrum é um método ágil similar ao XP, porém com foco maior em gerência. XP tem foco em engenharia, embora possua algumas práticas relacionadas à gerência [7]. O processo de gestão descrito pelo Scrum é bastante simples, bem como suas práticas, artefatos e regras. O Scrum não é prescritivo e, portanto não descreve o que deve ser feito em todas as circunstâncias. Mesmo assim, é aplicável em projetos complexos e o seu conjunto simples de práticas ajudam à manter todo o projeto bastante visível, o que permite que os praticantes saibam exatamente o que está ocorrendo e façam ajustes pontuais para que o projeto continue caminhando em direção ao alcance dos objetivos traçados.

Por fim, o Kanban [8] é uma expressão japonesa com origem nos cartões utilizados nas empresas japonesas para solicitar componentes a outras equipes da mesma linha de produção. Kanban designa um método de fabricação em série, desenvolvido pela Toyota Motor Company, aplicado aos processos de aprovisionamentos, produção e distribuição, seguindo os princípios do just-in-time (JIT).

A tradução literal da palavra kanban é anotação visível ou sinal. De modo geral, vem-se empregando na literatura esta palavra com o significado de cartão, pois o Sistema Kanban é conhecido por empregar determinados cartões para informar a necessidade de entregar e/ou produzir certa quantidade de peças ou matérias-primas. Em muitos trabalhos, nota-se a utilização indiscriminada da palavra kanban - significando tanto “cartão”, como se referindo ao “sistema” propriamente dito. Nesta seção, e no decorrer do presente trabalho, utiliza-se a seguinte distinção de termos: os cartões ou sinais empregados são tratados por “sinalizadores”, reservando-se, consequentemente, a palavra kanban ao sistema como um todo.

Na utilização do Kanban pressupõe-se que exista determinada quantidade de peças nos armazéns (estoques) entre as estações de trabalho. Em outras palavras, é assegurada a disponibilidade de peças suficientes para a formação dos produtos num dado período de trabalho. O processo subsequente, visto como um “cliente” deve ir ao processo precedente, o “fornecedor”, para adquirir as peças necessárias já prontas. O processo precedente, por sua vez, produz a exata quantidade retirada, reabastecendo o armazém, entendido como um “supermercado”. Segundo [9], existe um considerável número de possibilidades no uso deste esquema, visto que se podem combinar diferentes tipos e quantidades de sinalizadores, formas de retirada, pontos de programação, tipos de armazéns ou estoques, etc.

GERENCIAMENTO DE PROJETOS NO MINISTÉRIO PÚBLICO DE MINAS GERAIS

Antigamente, cada servidor era responsável, praticamente, por um sistema. Este desenvolvedor (servidor), junto ao cliente, realizava o levantamento de requisitos, fazia as anotações que achava necessária e programava todo o sistema. Isso trazia diversos problemas para o MPMG. O conhecimento do sistema fica restrito apenas a uma pessoa, e caso esse saísse de férias, por exemplo, não existia ninguém capaz de manter o sistema.

Atualmente, o desenvolvimento de software no MPMG vem sofrendo grandes modificações. Foram criadas equipes por projetos, sendo cada equipe composta por certa de cinco desenvolvedores. Logo, resolveu-se o problema de disseminação de conhecimento dos sistemas desenvolvidos. No entanto, como existem mais pessoas envolvidas, contribuindo no desenvolvimento do mesmo sistema, tornou-se necessário gerenciar e organizar as tarefas realizadas, objetivando uma maior produtividade.

Com o objetivo de melhorar o gerenciamento de projetos do MPMG, realizou-se um levantamento de alguns métodos ágeis, a saber Programação Extrema, Scrum e Kanban. Como no MPMG têm-se softwares complexos onde nem todos os requisitos estão claros a partir do seu início e não se tem um plano bem definido do que será implementado, optou-se pela utilização dos métodos ágeis.

Para testar as melhorias da aplicação de um método ágil, escolheu-se o Sistema de Registro Único, conhecido entre os servidores e membros pela sigla SRU. Este sistema encontra-se em desenvolvimento aproximadamente quatro anos. Desta forma, já existem diversas funcionalidades implementadas.

Mas como este sistema encontra-se em constantes evoluções, espera-se que, com a aplicação desses métodos ágeis, ter-se-á uma melhora do projeto como um todo, podendo-se estimar melhor os prazos para liberação de novas funcionalidades para o usuário, dentre outros benefícios.

Inicialmente este sistema foi concebido por apenas uma pessoa, mas, nos dias atuais, a equipe consta de seis desenvolvedores, sendo quatro servidores e dois estagiários. Além dos desenvolvedores existe uma pessoa responsável pelo levantamento dos requisitos e iterações com o usuário. Desta forma, a equipe deste projeto contém sete pessoas. Assim, a primeiro passo já havia sido tomado, o sistema possui uma equipe pequena, multifuncional e auto-organizada.

O segundo passo foi dividir todos os requisitos a serem implementados em uma lista de pequenas funcionalidades entregáveis e classificá-las por prioridade. Além disto, foi atribuído um grau de complexidade e esforço para cada tarefa. Cada tarefa, com suas respectivas informações de custo, foram, então, escritas em cartões e coladas na parede. Utilizaram-se colunas nomeadas para ilustrar onde cada item está no fluxo de trabalho.

Após a lista de funcionalidades, dividiu-se o tempo em curtas iterações de duração fixa (sprint de três semanas). O objetivo é ter entregas de funcionais do sistema de três em três semanas, para que o usuário possa visualizar o que está sendo feito. Além disto, definiu-se um limite do trabalho em andamento. O trabalho foi limitado a quatro funcionalidades. Assim, sempre existirá uma programação em par na equipe, com o objetivo de ajudar disseminar o conhecimento dos integrantes mais experientes.

CONCLUSÃO:

A Programação Extrema é bastante prescritiva comparada ao Scrum. Ela inclui quase tudo do Scrum mais algumas boas práticas de engenharia de software bem específicas como desenvolvimento orientado a testes e programação em par. Scrum é menos prescritivo que XP, uma vez que ele não prevê nenhuma prática específica de engenharia. Porém, Scrum é mais prescritivo que Kanban, uma vez que prescreve coisas como iterações e equipes multifuncionais.

Uma das principais diferenças entre Scrum e RUP (Rational Unified Process – Método Clássico) é que no RUP você recebe coisas demais, e você supostamente remove o material que não precisa. No Scrum você recebe muito pouco, e supostamente adiciona o material que lhe falta.

Já Kanban deixa quase tudo em aberto. As únicas restrições são: Visualize seu fluxo de trabalho e limite suas atividades em andamento. Apenas a alguns centímetros de faça qualquer coisa, mas ainda assim surpreendentemente poderoso.

Ainda é muito cedo para avaliar os resultados alcançados pela aplicação dos conceitos dos métodos ágeis no MPMG. No entanto, nos primeiros meses da implantação, percebeu-se a importância do acompanhamento do tempo de execução das tarefas (tempo médio para completar uma funcionalidade, algumas vezes denominado lean time). Aperfeiçoar o processo para tornar o tempo de execução o menor e mais previsível possível é ainda um desafio. Prever o tempo gasto em todo o fluxo nos permite uma maior fidelidade aos ANS - Acordos de Nível de Serviço (ou do inglês SLAs - Service-Level Agreements) e fazer planos de entrega mais realistas.

Tanto XP quanto Scrum e Kanban são empíricos no sentido que se espera que se experimente o processo e personalize ao seu ambiente. Na verdade, tem-se que experimentar. Nenhum método ágil fornece todas as respostas - eles apenas fornecem um conjunto básico de restrições para conduzir o seu próprio processo de melhoria.

Assim, a aplicação das práticas ágeis no MPMG está em uma fase embrionária, mas os primeiros resultados foram muito positivos. Como trabalhos futuros, pretendem-se organizar melhor as equipes, verificar se o período de três semanas é satisfatório para o tamanho do Sprint e testar outros limites para a quantidade de trabalho em andamento.

REFERÊNCIAS:

[1] - Torreão, P. G. B. C. Ambiente de Aprendizado para Educação em Gerenciamento de Projetos. Dissertação (Mestrado) — Universidade Federal de Pernambuco, 2005.

[2] - Cavalcanti, A. P. C.; Bandeira, L. R. P.; Donegan, P. M. Um modelo de gerência de projetos baseado no rup com aplicações de pmbok. Simpósio Internacional de Melhoria de Processos de Software, 2004.

[3] - Pressman, R. S. Software Engineering: A Practitioner’s Approach. 6. Ed. McGraw-Hill, 2005.

[4] - Martins, J. C. C. Técnicas para Gerenciamento de Projetos de Software. Brasport, 2007.

[5] - [Coram e Bohner 2005]Coram, M.; Bohner, S. The impact of agile methods on software project management. In: Proceedings of the 12th IEEE International Conference and Workshops on Engineering of Computer-Based Systems. Washington, DC, USA: IEEE Computer Society, 2005. p. 363–370. ISBN 0-7695-2308-0.

[6] - Beck, K. Extreme programming explained: embrace change. [S.l.]: Addison-Wesley, 2000. (The XP series). ISBN 9780201616415.

[7] - SCHWABER, K. Agile Project Management with Scrum. [S.l.]: Microsoft Press, 2004.

[8] - Anderson, D. J. Kanban: Successful Evolutionary Change for Your Technology Business. 1nd. ed. [S.l.]: Blue Hole Press, 2010.

[9] - JUNIOR, M. G. F. M. L. Adaptações ao sistema kanban: revisão, classificação, análise e avaliação. Revista Gestão e Produção - UNIPAC, v. 15, p. 173–188, 2008.