1 INTRODUÇÃO
Em outubro de 1968, aconteceu na cidade de Garmisch, Alemanha, a Working Conference on Software Engineering, reunindo mais de cinquenta profissionais de onze países, todos relacionados em atividades que envolviam processos de desenvolvimento de software. Nela, surgiu e definiu-se o conceito de Engenharia de Software, assim como também foram abordadas outras questões importantes, como metodologias de desenvolvimento e design de software [1]. Desde então, diversas metodologias foram criadas a fim de aumentar a satisfação do cliente em relação à qualidade do produto, assim como garantir a viabilidade do projeto e a lucratividade da empresa responsável pelo desenvolvimento do sistema.
De acordo com as informações contidas no relatório The Chaos Report: Decision Latency Theory: It’s All About the Interval, apenas 26% dos projetos de softwareexecutados com métodos tradicionais (ou não-ágeis) foram concluídos com sucesso, ou seja, dentro do orçamento, tempo e escopo determinados inicialmente. Em contrapartida, as equipes que utilizaram métodos ágeis obtiveram 48% como taxa de sucesso [2]. Pesquisas também indicam que ciclos curtos, com entregas de partes do software mais cedo e frequentes, aumentam as chances de sucesso do projeto. Ciclos mais curtos resultam em um processo iterativo de design, prototipação, desenvolvimento e lançamento de pequenas partes funcionais [3].
Diante disto, no final dos anos 90foram criados novos métodos e frameworks de desenvolvimento de software, se contrapondo ao tradicional modelo em cascata, cuja representação encontra-se na Figura 1.
Figura 1: Modelo em Cascata.
Fonte: [3].
Dentre os novos métodos, destaca-se o Scrum. Schwaber e Sutherland, os criadores deste método [4, p. 4], descrevem que:
O Scrum foi inicialmente desenvolvido para gerenciar e desenvolver produtos. Iniciando no começo dos anos 90, o Scrum tem sido usado extensivamente, mundialmente, para:
1. Pesquisar e Identificar mercados viáveis, tecnologias e funcionalidades de produtos;
2. Desenvolver produtos e melhorias;
3. Liberar produtos e melhorias frequentes, chegando a várias vezes por dia;
4. Desenvolver e sustentar a Nuvem (online, segura, sob demanda) e outros ambientes operacionais para uso de produtos; e,
5. Sustentar e renovar produtos.
Ainda de acordo com Schwaber e Sutherland [4, p. 3],
Scrum não é um processo, técnica ou um método definitivo. Em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas.
Sendo assim, ao longo deste artigo será detalhado o método Scrum e também as bases teóricas do Método de Análise e Solução de Problemas (MASP), mostrando a correlação e aplicabilidade do MASP na realidade Ágil no desenvolvimento de projetos de software, buscando, desta forma, suprir de forma sistemática os principais pontos que impedem os times de atingirem as metas propostas dos projetos nas quais estão envolvidos.
2 O SCRUM
Ken Schawberpublicou em 1997 o artigo “Scrumdevelopment process”, definindo as bases do framework. Hoje, mais de 20 anos após sua publicação, é um dos métodos mais utilizados para o gerenciamento e desenvolvimento de software. Junto à Jeff Sutherland, eles observaram que os métodos tradicionais de gestão não se adequavam a ambientes de incertezas e constantes mudanças aos quais os projetos de software estavam sujeitos[5].
O Scrum é um framework estrutural para desenvolver, entregar e manter produtos complexos, tendo como base o Sistema Toyota
de Produção e o Ciclo OODA (Observe, Oriente, Decida e Aja), representado na Figura 2.
Figura 2: Ciclo OODA.
Fonte: [6].
Os times são auto gerenciáveis e multifunção, onde os membros do time decidem como irão se organizar de forma a executar o trabalho a ser realizado.
O Scrum é fundamentado nas teorias empíricas de controle de processo, ou empirismo,onde acredita-se que o conhecimento vem da experiência e de tomada de decisões baseadas no que é conhecido. Para uma maior visibilidade do processo, assim como para aumentar a previsibilidade e o controle de riscos, o Scrum utiliza uma abordagem iterativa e incremental [4].
2.1 Papéis do Scrum
O Scrum descreve três papeis: Product Owner, Scrum Master e Development Team[4].
O Product Owner, ou dono do produto, é responsável por maximizar o valor do produto, resultado do trabalho do Development Team, ou Time de Desenvolvimento [4]. Define e detalha junto ao cliente o Backlog do produto, garantindo que a equipe de desenvolvimento sempre irá trabalhar no item que entregue mais valor.
O Scrum Master age como facilitador, responsável por promover e dar suporte às práticas do método para os envolvidos no projeto. Não possui autoridade sobre o time, trabalha para que o time possa se desenvolver de forma otimizada, aumentando gradativamente a produtividade e qualidade das entregas.
Development Team, ou time de desenvolvimento, é o grupo responsável por
realizar o trabalho de modo a entregar ao fim da Sprint um incremento funcional do produto para o cliente.
2.2 Eventos Scrum
O Scrum define alguns eventos que irão cadenciar o trabalho a ser desenvolvido, em ritmo sustentável, de forma que seja possível ser mensurado e inspecionado periodicamente, atingindo assim, a melhoria contínua. Estes eventos encontram-se representados na Figura 3.
Figura 3: Scrum Framework.
Fonte: [7].
2.3 Sprint
A Sprint é o coração do Scrum. Com período de duração que varia entre 1 a 4 semanas, o time executa o trabalho planejado de forma a entregar valor para o cliente. Uma Sprint é formada pelos seguintes eventos: a Sprint Planning, o Daily Scrum, trabalho de desenvolvimento, a Sprint Review e a Sprint Retrospective [4].
Para que a Sprint seja executada de forma eficiente, existem alguns eventos que devem ser seguidos e que serão abordados a seguir.
2.3.1 SPRINT PLANNING
Evento onde o time de desenvolvimento irá analisar, detalhar e estimar o Backlog priorizado pelo Product Owner. Essa cerimônia tem duração entre 2 e 4 horas, tendo como objetivo determinar as histórias que serão entregues ao final da Sprint. As histórias de usuário precisam ter o detalhamento necessário para o time de desenvolvimento executar o trabalho. Cada história deve possuir uma Definição de pronto (Definition of Done).
2.3.2 DAILY SCRUM
Diariamente, o time de desenvolvimento se reúne por 15 minutos, planejando o trabalho das próximas 24 horas, promovendo a inspeção do trabalho que está sendo desenvolvido e a colaboração entre os membros do time.
Essa prática visa atender a um dos doze princípios do Manifesto para Desenvolvimento Ágil de Software, onde Beck et al (2001) [8] diz que: “O método mais eficiente e eficaz de transmitir informações entre uma equipe de desenvolvimento é através de conversa face a face”.
Dentro desta dinâmica, cada membro aborda três pontos:
· O que fez ontem para contribuir com o objetivo da Sprint;
· O que está fazendo hoje para contribuir com o objetivo da Sprint;
· Quais os impedimentos?
2.3.3 Sprint Review
Ao final da Sprint, o Product Owner, Scrum Master, Team e Cliente reúnem-se para o Sprint Review, evento com duração máxima de 4 horas. Nela, o Product Owner relata quais histórias de usuário foram ou não concluídas e o Team apresenta para o Cliente as funcionalidades prontas (software funcionando). O cliente também revisa cada história de usuário entregue pelo time, aprovando ou não o incremento do produto.
Com base nessas informações, o grupo irá refletir sobre os próximos passos, assim como o Cliente poderá revisar o Backlog do produto, analisando as prioridades para a próxima iteração dentro do projeto.
2.3.4 Sprint Retrospective
Após o Sprint Review, o Time de Desenvolvimento executa a Sprint Retrospective, listando pontos positivos, negativos e de melhoria que ocorreram durante o período da Sprint, onde posteriormente serão priorizados e executados de forma que a equipe atinja a melhoria contínua. A equipe deve focar no aprimoramento do processo que pode ser aplicada de forma imediata, refletindo de forma madura e objetiva, buscando formas mais eficazes de se realizar o trabalho do projeto.
Segundo Sutherland [9, p.146],
A reunião de retrospectiva é a parte “Verificar” do ciclo Planejar-Fazer-Verificar-Agir (PDCA), de Deming. O segredo é alcançar o passo Agir, o kaizen, que é o que de fato mudará o processo e o tornará melhor da próxima vez.
3 KAIZEN
A origem da palavra kaizenvem do japonês, ondeKaisignifica Mudar e Zensignifica Melhor, sendo interpretada e adotadamundialmente como Melhoria Contínua. Atualmente há uma nova interpretação para kaizen, sendo a Melhoria Contínua feita por todas as Pessoas,todos os Dias em todos os lugares. Os princípios orientadores do kaizen são:
· Processos consistentes conduzem aos resultados desejados;
· Ver por si mesmo para compreender a situação atual;
· Falar com dados e gerir com base em fatos;
· Tomar medidas para conter e corrigir as causas raiz dos problemas;
· Trabalhar como equipe;
Segundo Imai 10], kaizen “
É um processo que, quando feito corretamente, humaniza o local de trabalho, elimina o trabalho desnecessariamente difícil (mental e físico), ensina as pessoas a fazer experimentos rápidos usando métodos científicos e como eliminar o desperdício nos processos de negócios.
Assim como acontece no Scrum, o kaizen dá autonomia aos indivíduos pertencentes ao grupo. Segundo Anderson [11, p. 56],
Indivíduos sentem-se livres para agir; livres para fazer a coisa certa. Eles espontaneamente se debruçam sobre os problemas, discutem as opções e implementam correções e melhorias.
A cultura kaizen dá ao time o foco na melhoria da qualidade, a produtividade e a satisfação do cliente.
4 MÉTODO DE ANÁLISE E SOLUÇÃO DE PROBLEMAS (MASP)
De acordo com Campos [12],
Qualquer DECISÃO GERENCIAL, em qualquer nível, deve ser conduzida para solucionar um problema (lembrando sempre que problema é o resultado indesejável de um processo).
Ou seja, a eficácia da solução depende do método utilizado na análise do processo.
O Método de Análise e Solução de Problemas ou MASP é um método baseado no QC-Story, criado pela Union of Japanese Scientists and Engineers (JUSE) e amplamente difundido no Brasil através de Vicente Falconi, onde o processo foi descrito e correlacionado no livro TQC Controle da Qualidade Total (no estilo japonês) [12]. Este método está esquematizado na Figura 4.
Figura 4: QC-Story.
Fonte: [11].
O PDCA é a estrutura que dá suporte ao MASP e, para a análise do processo, outras ferramentas da qualidade como Estratificação, Lista de Verificação, Gráfico de Pareto e Diagrama de Ishikawa são utilizadas.
Ainda segundo [12, p. 208],
a análise de processo é uma sequência de procedimentos lógicos, baseada em fatos e dados que objetiva localizar a causa fundamental dos problemas.
O MASP enumera oito fases a serem seguidas e, em cada uma dessas fases, tarefas que devem ser realizadas utilizando ferramentas, para que assim, se possa atingir um objetivo específico. A seguir, são detalhadas cada uma das fases do processo e o objetivo a ser alcançado em cada uma delas.
4.1 Fases do MASP
4.1.1 IDENTIFICAÇÃO DO PROBLEMA
O objetivo central é definir claramente o problema e reconhecer sua importância. Dentre os problemas existentes na organização, o de maior prioridade deve ser selecionado para análise, onde dados e informações serão levantados para determinar a frequência e como o problema ocorre.
Para um real entendimento da extensão do problema, é essencial mostrar quais perdas em decorrência do problema estão acontecendo, e quais os potenciais ganhos com a resolução dele.
A Análise de Pareto é utilizada nesta fase para realizar uma analise quantitativa dos resultados indesejáveis mais frequentes. Por fim, responsáveis são designados para liderar a frente de trabalho que deverá solucionar o problema.
4.1.2 OBSERVAÇÃO
Essa fase é considerada crucial para o sucesso do processo, pois quanto mais tempo for empregado na observação, mais fácil será para resolver o problema. Nesta fase, devem ser investigadas as características específicas do problema com uma visão ampla e sob vários pontos de vista.
Através da Análise de Pareto, do uso da Estratificação e da Lista de Verificação, é possível descobrir as características dos problemas. Nesta fase também são criados cronograma, orçamento e meta que serão utilizados como base.
4.1.3 ANÁLISE
O ponto central desta fase é a análise e determinação da causa fundamental do problema. A definição e das causas influentes e escolha das mais prováveis é realizada através de Tempestade de Ideias (Brainstorm) e Diagrama de Causa e Efeito.
Com base nessas informações, ocorre a análise das causas mais prováveis e,havendo a confirmação, deve ser verificada se é possível bloquear a causa fundamental do problema e se há algum tipo de efeito colateral indesejável.
4.1.4 PLANO DE AÇÃO
Junto ao grupo de trabalho, é necessário conceber um plano para bloquear as causas fundamentais. O uso do 5W1H é determinante para o sucesso desta fase. É fundamental que todos os envolvidos (responsáveis) esteja de acordo com os objetivos e metas propostos.
O 5W1H é um plano de ação, criado por um grupo de pessoas, com a finalidade de realizar tarefas de forma sistemática. No plano é descrito: O que será feito (What); Quando será feito (When); Onde será feito (Where); Por que será feito (Why); Quem o fará (Who); Como será feito (How).
4.1.5 AÇÃO
Nesta fase é colocado em prática o plano de ação, de modo a bloquear as causas fundamentais. É importante que o plano seja divulgado, assim como também que as principais partes interessadas sejam envolvidas ativamente, engajando o grande grupo ao redor das metas.
4.1.6 VERIFICAÇÃO
Para verificar se o bloqueio foi efetivo, deve-se comparar os resultados, analisando a efetividade da ação e o impacto ocasionado nos resultados indesejáveis. Também devem ser listados possíveis efeitos colaterais e se o problema persiste ou não em algum grau. Se o bloqueio não tiver sido efetivo, o processo volta a fase de observação. Caso positivo, segue para a etapa de padronização.
4.1.7 PADRONIZAÇÃO
Para prevenir o reaparecimento do problema, alterações são implementadas ou até mesmo um novo padrão é criado. Ele deve ser comunicado para as partes interessadas e treinamentos devem ser promovidos. O novo padrão deve ser acompanhado sistematicamente para verificar o cumprimento.
4.1.8 CONCLUSÃO DO MASP
Esta fase é executada para recapitular todo o processo de solução do problema para trabalho futuro. Além da realização da relação dos problemas remanescentes, um novo ciclo do MASP pode ser executado caso seja necessário. O time irá refletir sobre as atividades desempenhadas, buscando a melhoria do processo em si.
5 ADAPTANDOO MASP AO SCRUM
Conforme abordado anteriormente, o Scrum é um método que promove a inspeção e adaptação do trabalho através de eventos como o Daily Scrum, a Sprint Review e a Sprint Retrospective. Através da Sprint Retrospective, o time reflete sobre o seu próprio trabalho, a fim de criar um plano para melhorias que deverão ser implementadas a partir da próxima iteração.
A seguir, são distribuídas as fases e tarefas do MASP dentro do Scrum, de modo que o time consiga maximizar seus resultados, utilizando uma versão enxuta do método mundialmente reconhecido como eficaz para a solução de problemas.
Na proposta deste trabalho, as fases do MASP foram reordenadas e dividas em 5 (cinco) grupos, de modo a melhor atender à dinâmica do Scrum, são eles:
· Prospecção;
· Exploração;
· Experimentação;
· Evolução.
Na sequência, são detalhados cada um dos grupos, listando quais fases do MASP estão inclusas, as tarefas foram adotadas, e em qual momento dentro da estrutura Scrum elas devem ocorrer, conforme representado no Quadro 1.
Quadro 1: Adaptação e correlação do MASP ao Scrum.
Fonte: Autor.