universidade federal de mato grosso instituto de ... · metodologia de software com scrum e bpm...
TRANSCRIPT
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
COORDENAÇÃO DE ENSINO DE
ESPECIALIZAÇÃO EM ENGENHARIA WEB E GOVERNO
ELETRÔNICO
METODOLOGIA DE SOFTWARE COM SCRUM E BPM:
UMA PROPOSTA EM PROJETO DE ALTO TURN OVER
AUREO CARNEIRO RIOS NETO
CUIABÁ – MT
2017
U F M T
1
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
COORDENAÇÃO DE ENSINO DE
ESPECIALIZAÇÃO EM ENGENHARIA WEB E GOVERNO
ELETRÔNICO
METODOLOGIA DE SOFTWARE COM SCRUM E BPM
AUREO CARNEIRO RIOS NETO
Orientador: Prof. MSc. NILTON HIDEKI TAKAGI
Monografia apresentado ao Curso de
Especialização em Engenharia Web e Governo
Eletrônico, do Instituto de Computação da
Universidade Federal de Mato Grosso, como
requisito para elaboração da Monografia do
Curso de Especialização em Engenharia Web e
Governo Eletrônico.
CUIABÁ – MT
2017
U F M T
2
3
RESUMO
O objetivo desde estudo é a criação de uma metodologia de software com características
ágeis que mescle valores de frameworks já existentes como o Scrum e técnicas de
gerenciamento de processos de negócios que visam a atender uma equipe
multidisciplinar com turn-over estabelecido. A solução proposta neste trabalho é uma
forma de desenvolvimento customizada a essa realidade e que proporcionam um
ambiente adequado de desenvolvimento e sofra o menor impacto com a entrada e saída
de componentes da equipe durante a execução e tenha uma estrutura mais enxuta de
atividades e papeis que a atual do modelo de desenvolvimento de software proposto
pelo Governo do Estado do Mato Grosso, denominado Processo de Desenvolvimento de
Software nas Instituições Públicas do Estado de Mato Grosso (PDSMT).
4
SUMÁRIO RESUMO ......................................................................................................................... 2
LISTA DE FIGURAS ...................................................................................................... 6
LISTA DE TABELAS ..................................................................................................... 7
LISTA DE SIGLAS E ABREVIATURAS ...................................................................... 8
CAPÍTULO 1 INTRODUÇÃO ........................................................................................ 9
1.1 APRESENTAÇÃO ................................................................................................. 9
1.2 OBJETIVOS ......................................................................................................... 10
1.2.1. OBJETIVO GERAL ..................................................................................... 10
1.2.2. OBJETIVO ESPECIFICO ............................................................................ 10
1.3 JUSTIFICATIVA ................................................................................................. 10
1.4 METODOLOGIA ................................................................................................. 11
CAPÍTULO 2 FUNDAMENTAÇÃO TEÓRICA .......................................................... 12
2.1 INTRODUÇÃO .................................................................................................... 12
2.2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE .............................. 12
2.2.1. PLANEJAMENTO ....................................................................................... 13
2.2.2. ANÁLISE ...................................................................................................... 14
2.2.3. PROJETO ...................................................................................................... 14
2.2.4. IMPLEMENTAÇÃO .................................................................................... 15
2.3 MÉTODOS ÁGEIS .............................................................................................. 15
2.3.1. DEFINIÇÃO DO MANIFESTO ÁGIL ........................................................ 15
2.3.2. PRINCIPIOS E VALORES DO MANIFESTO ÁGIL ................................. 16
2.3.3. MOTIVAÇÃO PARA UTILIZAR O DESENVOLVIMENTO ÁGIL ........ 18
2.3.4. OS MAL-ENTENDIDOS NO MÉTODOS ÁGEIS ..................................... 19
2.4 SCRUM ................................................................................................................ 21
2.4.1. HISTORICO.................................................................................................. 21
2.4.2. PAPEIS.......................................................................................................... 22
2.4.3. ARTEFATO .................................................................................................. 25
2.4.4. EVENTOS ..................................................................................................... 26
2.5 GERENCIAMENTO DE PROCESSOS DE NEGÓCIO ..................................... 29
2.5.3. NOTAÇAO BPMN ....................................................................................... 32
CAPÍTULO 3 ESTUDO DE CASO ............................................................................... 38
3.1. DESCRIÇÃO DO CASO .................................................................................... 38
3.2. METODOLOGIA ATUAL ................................................................................. 38
3.3. METODOLOGIA PROPOSTA .......................................................................... 41
5
3.3.1. PLANEJAMENTO DO PRODUTO ............................................................. 42
3.3.2 EXECUÇÃO DO PROJETO ......................................................................... 44
3.3.3. DESENVOLVIMENTO DE SOFTWARE .................................................. 47
3.3.4. HOMOLOGAÇÃO DO SOFTWARE .......................................................... 50
3.3.5 ENCERRAMENTO DO PROJETO .............................................................. 53
CAPÍTULO 4 CONCLUSÕES ...................................................................................... 55
REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................... 57
6
LISTA DE FIGURAS
Figura 1: Etapas do PDS utilizando notação BPMN. Fonte: o próprio .......................... 13
Figura 2: Os diferentes tipos de projetos, e as abordagens de gestão. Fonte IGTI. ....... 19
Figura 3: Visão Geral do Fluxo de um Projeto Scrum. Fonte: SCRUMSTUDY ........... 21
Figura 4: Visão geral dos papéis do Scrum. Fonte: SCRUMSTUDY ........................... 23
Figura 5: Três exemplos de Product Backlog. Fonte: Rafael Sabbagh .......................... 26
Figura 6: Durações Time-Box para Reuniões do Scrum. Fonte: SCRUMSTUDY ....... 27
Figura 7: Ciclo BPM. Fonte: Lecom BPM ..................................................................... 30
Figura 8: Fluxo do Processo de Desenvolvimento de Software nas Instituições Públicas
do Estado de Mato Grosso. Fonte: Governo de Mato Grosso ........................................ 39
Figura 9: Visão Completa do Processo. Fonte: O próprio. ............................................. 42
Figura 10: Fase de Planejamento. Fonte: o próprio. ....................................................... 43
Figura 11: Fase de Execução. Fonte: o próprio. ............................................................. 45
Figura 12: Fase de Desenvolvimento de Software. Fonte: o próprio. ............................ 49
Figura 13: Fase de Homologação. Fonte: o próprio. ...................................................... 51
Figura 14: Subatividade de Executar os Casos de Teste e Corrigir bugs. Fonte: o
próprio. ........................................................................................................................... 52
Figura 15: Fase de Encerramento. Fonte: o próprio. ...................................................... 54
7
LISTA DE TABELAS
Tabela 1: Eventos de BPMN .......................................................................................... 32
Tabela 2: Atividades de BPMN ...................................................................................... 33
Tabela 3: Gateways de BPMN ....................................................................................... 35
Tabela 4: Objetos de conexão da BPMN ....................................................................... 35
Tabela 5: Swimlanes da BPMN...................................................................................... 36
Tabela 6: Artefatos da BPMN ........................................................................................ 36
Tabela 7: Dados da BPMN ............................................................................................. 37
Tabela 8: Comparativo entre PDSMT e Metodologia Proposta ..................................... 41
8
LISTA DE SIGLAS E ABREVIATURAS
ABPMP Association of Business Process Management International
BPM Business Process Management
BPMI Business Process Management Initiative
BPMN Business Process Modeling Notation
BPMS Business Process Management Suite
EPC Event-driven Process Chain
IC Instituto de Computação
OMG Object Management Group
OOPSLA Object-Oriented Programming, Systems, Languages & Applications
PDCA Plan, Do, Check and Act
PDS Processo de Desenvolvimento de Software
PDSMT Processo de Desenvolvimento de Software nas Instituições Públicas do
Estado de Mato Grosso.
PO Product Owner
SBOK Scrum Body of Knowledge
TCC Trabalho de Conclusão de Curso
TDD Test Driven Development
TI Tecnologia da Informação
UFMT Universidade Federal de Mato Grosso
UML Unified Modeling Language
9
CAPÍTULO 1
INTRODUÇÃO
1.1 APRESENTAÇÃO
Com o crescimento de pessoas utilizando os meios eletrônicos, surge a necessidade dos
Governos se modernizarem e oferecer websites que forneça informações e capacidade
de interagir com os cidadãos através da internet de uma forma simples e seguindo as
tendências digitais.
O Instituto de Computação (IC) é vinculado a uma instituição pública, a Universidade
Federal de Mato Grosso (UFMT), onde realiza atividades terceirizadas na área que
envolva a computação, como consultoria e desenvolvimento de software, respeitando os
princípios de boas práticas para o Governo Eletrônico e metodologias ágeis.
As equipes de desenvolvimento e suporte do IC-UFMT possuem uma grande
participação de estagiários e terceirizados em seu time, o que gera um turn-over (o
conceito de turn-over definido pela área de Gestão de Pessoas é dada pela rotatividade
de funcionários no negócio, que dificulta um vínculo longo entre o funcionário e a
empresa), uma vez que os contratos de trabalho são encerrados com frequência pelos
mais diversos motivos, ainda com o projeto em andamento. Essa realidade gera uma
grande demanda de tempo para ensinar aos novos integrantes que estão ingressando no
time sobre todos os procedimentos e regras de negócios adotados no projeto em
andamento.
Considerando que alguns projetos têm interseção com o Governo do Estado de Mato
Grosso e a partir desse cenário, constatou-se necessário desenvolver uma metodologia
de desenvolvimento ágil voltada para web, utilizando o framework Scrum e o Processo
de Desenvolvimento de Software do Governo do Estado de Mato Grosso (PDSMT) em
uma notação de Processos de Negócio.
O Scrum e Gerenciamento de Processos de Negócios serão utilizados para modelar uma
metodologia de desenvolvimento de Software que será utilizada pelo Instituto de
Computação da UFMT para atender a uma necessidade de desenvolvimento de sistema
para a qual foi contratada.
10
1.2 OBJETIVOS
1.2.1. OBJETIVO GERAL
Desenvolver uma metodologia que seja de fácil compreensão e otimize a incorporação
de novos integrantes da equipe de desenvolvimento, reduzido os impactos causados
pelo turn-over e gerando mais resultado ao projeto.
1.2.2. OBJETIVO ESPECIFICO
Pesquisar o Processo de Desenvolvimento Ágil com Scrum;
Demonstrar a aplicabilidade de técnicas Business Process Management (BPM)
que auxilie no desenvolvimento de software;
Desenvolver uma metodologia com os conceitos de Scrum em conjunto com
Business Process Management (BPM) que atenda a equipes com poucos
empregados e que sofra com rotatividade de empregados (turn-over);
1.3 JUSTIFICATIVA
O Projeto será construído por um grupo de desenvolvedores de software para Web do
Instituto de Computação da Universidade Federal de Mato Grosso. A equipe possui uma
quantidade reduzida de colaboradores, formada por estagiários, gerando uma frequência
de rotatividade de membros ocasionadas pelos términos dos contratos de estágio.
Neste contexto, as atividades são constantemente prejudicadas pela entrada de novos
integrantes na equipe que não possuem conhecimento sobre o projeto em andamento,
regras de negócios e formas de trabalho (cultura operacional).
A partir da integração do Scrum e Business Process Modeling Notation (BPMN), cria-
se um ambiente de fácil assimilação dos processos de desenvolvimento de software
utilizado pela equipe, pois utiliza uma notação gráfica que cria uma ferramenta de
11
gestão do conhecimento e um processo com passos-a-passos do que deve ser realizados,
além de permitir o aumento de produtividade ao processo sempre quando houver a
entrada de novo componente na equipe e redução de tempo com treinamento e
supervisão inicial sobre o recém-admitido.
1.4 METODOLOGIA
A natureza desta pesquisa é de trabalho original, com objetivos de pesquisa exploratória
e que tem como procedimento técnico a pesquisa bibliografia e experimental. Para
atingir os objetivos propostos na pesquisa, serão realizadas:
1) A primeira etapa constitui uma revisão bibliográfica sobre prática de
desenvolvimento de software, métodos ágeis, Scrum, PDSMT e
Gerenciamento de Processos de Negócio;
2) A segunda etapa constitui em realizar uma pesquisa com a equipe de
desenvolvimento dos problemas existentes e apresentar uma possível
proposta de solução com técnicas de Scrum, PDSMT e BPM;
3) A construção de Diagramas da metodologia proposta em Notação de
Processo de Negócios utilizando a ferramenta Bizagi Modeler.
4) Documentação escrita e visual, explicando os artefatos, fases, atividades e
subatividades da metodologia proposta.
5) Apresentação aos gerentes de projetos responsáveis do IC-UFMT sobre a
metodologia proposta, com feedback de sugestões para melhoria e correções.
12
CAPÍTULO 2
FUNDAMENTAÇÃO TEÓRICA
2.1 INTRODUÇÃO
A fundamentação teórica dará subsídios para entender a metodologia proposta que será
aplicada ao trabalho.
2.2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Os motivos que levam uma organização a solicitar o desenvolvimento de software é
automatizar uma atividade que lhe proporcione algum benefício, como por exemplo,
aumento da qualidade dos produtos ou serviços prestados, aumento de vantagens
competitivas com dados que possa lhe ajudar a tomar decisões, otimizar a gestão do
negócio e diversos outros motivos levam as empresas a se informatizar.
E o Processo de Desenvolvimento de Software (PDS) é o canal utilizado para empresas
que necessitam de uma solução customizada para seu negócio. O PDS é similar a
qualquer outro processo, como o utilizado na indústria, construção civil, comércios,
serviços técnicos etc. O mais habitual em literaturas é realizar a analogia do processo de
desenvolvimento de software com o processo de construção civil, onde existe as fases
de planejamento, análise, projeto (design) e implementação independentes da
metodologia de desenvolvimento usada. Vejamos um exemplo:
Sob vários aspectos, a criação de um sistema de informação é similar à
construção de uma casa. Em primeiro lugar, o proprietário descreve a visão
da casa para o projetista. Em segundo lugar, essa ideia é colocada na forma
de croquis e desenhos esquemáticos, que são mostrados ao proprietário e
detalhados (frequentemente por meio de vários outros desenhos, cada um
deles aprimorando o anterior) , até ele concordar que as figuras descrevem o
que ele quer. Em terceiro lugar, é desenvolvido um conjunto de plantas
detalhadas, apresentando muito mais informações especificas sobre a casa
(por exemplo, posição dos quartos, localização dos aparelhos hidráulicos e
tomadas elétricas e assim por diante). Por fim, a casa é construída de acordo
13
com essas plantas – e, com frequência, com algumas alterações e decisões
tomadas pelo cliente enquanto a casa está sendo erguida. (DENNIS, WIXOM
e ROTH, 2014, p. 11)
Figura 1Etapas do PDS utilizando notação BPMN1. Fonte: o próprio
Nas metodologias tradicionais como Cascata (Waterfall), essas fases ficam mais
evidentes onde se inicia e finaliza cada fase, mas nas metodologias ágeis que estão no
auge, é mais sutil a forma como cada fase se começa e termina, as vezes sendo cíclicas,
contudo todas elas possuem basicamente as mesmas fases.
Apesar de existirem divergências nas fases de desenvolvimento de Software, as fases
adotas a seguir serão baseados no livro Análise e Projeto de Sistemas, maiores
informações sobre o livro, consultar as referências bibliográficas.
2.2.1. PLANEJAMENTO
1 As fases do Processo de Desenvolvimento de Software representando em BPMN se trata dos
macroprocessos, sendo que em cada fase existe diversos outras etapas (ou subprocessos). Processo em Cascata conforme (DENNIS, WIXOM e ROTH, 2014).
14
A fase de Planejamento tem a finalidade de entender o “por que” um sistema deve ser
desenvolvido e “como” os desenvolvedores procederão a sua construção, sempre com a
premissa de que o sistema diminuirá os custos e aumentará os lucros. Segundo
DENNIS, WIXOM e ROTH (2014) as etapas pertinentes a esta fase são identificar
oportunidades, analisar a viabilidade, desenvolver o plano de trabalho, compor o quadro
de pessoal do projeto e controlar e dirigir o projeto. O Planejamento da viabilidade pode
ser estruturada respondendo a três perguntas simples: Podemos contruí-los? (viabilidade
técnica), Ele agregará valor? (viabilidade econômica) e Se o construirmos, ele será
usado? (viabilidade organizacional).
2.2.2. ANÁLISE
A fase da Análise conforme DENNIS, WIXOM e ROTH (2014) tem por objetivo
responder ás perguntas tais como quem usará o sistema, o que o sistema fará, onde e
quando será usado. Esta fase é dividia em três etapas:
1ª Etapa: A primeira etapa é a desenvolver a estratégia de análise, que verifica a o
sistema atual e seus problemas, caso já exista um em operação, e projeta um futuro
sistema com as correções e melhorias apuradas.
2ª Etapa: Nessa etapa, é realizada o levantamento de requisitos, através das diversas
técnicas disponíveis como entrevistas, seminarios de grupos, questionarios,
Gerenciamento de Processos de Negócios etc. Com o levantamento dos requisitos é
desenvolvido um conceito para o sistema, que será usado para o modelo do sistema a
ser criado.
3ª Etapa: A combinação do conceito do sistema com o modelo do sistema gera um novo
documento chamado proposta do sistema, que servirá de apresentação para o cliente
para tomar a decisão de seguir adiante.
O documento final desta fase é a proposta do sistema que descreve quais requisitos o
sistema terá de atender e dará subsídios para a fase de projetos.
2.2.3. PROJETO
Na fase do Projeto, somente uma pergunta genérica e uma resposta complexa deve-se
ter em mente: como este sistema funcionará? Embora a maior parte das decisões já
15
tenham sido tomadas na fase de Planejamento e Análise, as decisões tomadas nesta fase
serão de supra importância para o êxito do software. Nessa fase que é trabalhada a
arquitetura de software.
2.2.4. IMPLEMENTAÇÃO
A última fase é de Implementação, onde o sistema realmente começa a ser
desenvolvidos (nessa fase que estão as etapas: programação, testes de software e
desempenho, treinamento e suporte ao usuário e manutenções). É a fase mais cara
durante todo o processo de desenvolvimento de software, e onde os erros são fatais para
o sucesso da aplicação a ser desenvolvida. A implementação é dividia em três etapas: o
desenvolvimento do software, a instalação (nessa fase que fica o treinamento e
responsável pela utilização do aplicativo) e o plano de suporte (suporte ao usuário e
manutenções preventivas e corretivas).
2.3 MÉTODOS ÁGEIS
O Manifesto Ágil surgi em 2001 (Manifesto para o desenvolvimento ágil de software,
2001) com a ideia antagônica existente aos métodos tradicionais, o que ocasionou uma
revolução na ideia de concepção e desenvolvimento de software, com as principais
ideias de entregas constantes que agregue valor ao negócio, envolvimento do cliente no
projeto e grande flexibilidade na alteração do escopo do projeto.
2.3.1. DEFINIÇÃO DO MANIFESTO ÁGIL
De acordo com a definição dada por Gomes (2013, p. 4) ao Manifesto Ágil:
É o embasamento filosófico de todos os métodos ágeis e diversos métodos de
desenvolvimento de software estão alinhados a ele. A maioria deles se utiliza
de ciclos curtos, que são chamados de iterações e normalmente têm duração
de poucas semanas, dessa forma garantindo feedback frequente e respostas
rápidas às mudanças.
Ainda segundo Gomes (2013) a ideia de criação do Manifesto Ágil surgiu da
experiência dos autores, que após participarem de diversos projetos de desenvolvimento
16
de software, e perceberem problemas com a abordagem tradicional (conhecida como
cascata ou Waterfall) de desenvolvimento. Um grupo de profissionais de
desenvolvimento de software se reuni em um Resort de Ski nas Cordilheiras Wasatch
localizada nas fronteiras dos Estados de Utah e Idaho para discutir melhores maneiras
de produção de software. Os celebres profissionais que participaram desta reunião que
posteriormente daria origem ao Manifesto Ágil foram: “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”
(Manifesto para o desenvolvimento ágil de software, 2001).
2.3.2. PRINCIPIOS E VALORES DO MANIFESTO ÁGIL
Nesse encontro deu-se a origem ao Manifesto Ágil, com os 12 princípios que regem o
manifesto. Os princípios do manifesto são:
Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e
contínua de software de valor; aceitar mudanças de requisitos, mesmo no fim
do desenvolvimento. Processos ágeis se adequam a mudanças, para que o
cliente possa tirar vantagens competitivas; entregar software funcionando
com frequência, na escala de semanas até meses, com preferência aos
períodos mais curtos; Pessoas relacionadas à negócios e desenvolvedores
devem trabalhar em conjunto e diariamente, durante todo o curso do projeto;
construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente
e suporte necessário, e confiar que farão seu trabalho; O Método mais
eficiente e eficaz de transmitir informações para, e por dentro de um time de
desenvolvimento, é através de uma conversa cara a cara; Software funcional é
a medida primária de progresso; Processos ágeis promovem um ambiente
sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser
capazes de manter indefinidamente, passos constantes; contínua atenção à
excelência técnica e bom design, aumenta a agilidade; Simplicidade: a arte de
maximizar a quantidade de trabalho que não precisou ser feito; as melhores
arquiteturas, requisitos e designs emergem de times auto-organizáveis; em
intervalos regulares, o time reflete em como ficar mais efetivo, então, se
17
ajustam e otimizam seu comportamento de acordo. (Manifesto para o
desenvolvimento ágil de software, 2001)
Além desses princípios, o Manifesto Ágil é composto por quatro valores, como:
Indivíduos e interação entre eles mais que processos e ferramentas;
Software em funcionamento mais que documentação abrangente;
Colaboração com o cliente mais que negociação de contratos; Responder a
mudanças mais que seguir um plano” (Manifesto para o desenvolvimento
ágil de software, 2001).
Apesar dos valores nas frases à direita, o Manifesto Ágil, valoriza mais a parte da frase
a esquerda e destacado, entendendo que o texto a direta seja uma forma completar do
valor ou uma explanação que o justifica. A compreensão dos valores ágeis pode ser
entendida conforme (GOMES, 2013) da seguinte forma:
Indivíduo e a interação entre eles mais importantes que processos e ferramentas,
tratar de entender que a equipe é formada por indivíduos, que possuem
características diversas, que devem ser mantidas as diversidades entre os
membros da equipe e valorizado o Ser sem que haja detrimento as ferramentas e
processos de produção e incentivar a interação entre os membros da equipe, por
exemplo, com o senso de colaboração e comunicação constante. Também deve
existir a valorização dos processos e ferramentas, que são essências para o
desenvolvimento de software e que não deve ser desvalorizada, entretanto, é o
Ser que utilizam os processos e ferramentas, gerando o produto final a partir de
seus conhecimentos e habilidades, que são características individuais.
Software em funcionamento mais que documentação abrangente, permitir que ao
final da interação que for realizada, a documentação seja produzida e entregue
ao cliente. Esse é um contraste com o método Waterfall, onde nas fases iniciais,
são criadas uma grande quantidade de documentação de como será o software,
que ao final, o que foi solicitado não se torna mais útil, e com isso a
documentação que serviu de base para sua criação do aplicativo passa a não ter
mais significado e deixa de agregar valor.
18
Colaboração com o cliente é mais valorizada do que negociação contratual, pois
é necessário a aproximação do cliente no projeto, para agregar valor e participar
das mudanças que podem afetam o escopo inicial pelos mais diversos motivos.
E último valor ágil é responder a mudanças é mais importante do que seguir um
plano, visto que o planejamento pode ser alterado, excluído e refeito, dependo
unicamente da necessidade do cliente que pode ser alterada.
2.3.3. MOTIVAÇÃO PARA UTILIZAR O DESENVOLVIMENTO ÁGIL
Um dos maiores motivadores para a transição do método de desenvolvimento
tradicional para métodos ágeis são os benefícios percebidos. Para o desenvolvimento
em ambientes governamental, as vantagens mais relevantes da adoção de métodos ágeis
são:
Maior Satisfação do Cliente e Melhor Gestão de Mudanças de
Prioridades: O planejamento iterativo permite que o cliente facilmente mude
suas prioridades com impacto reduzido na produtividade da equipe porque
planejasse detalhamento apenas daquilo que está mais próximo de ser feito,
evitando também desperdícios e custos desnecessários. A comunicação
constante cite a proximidade com o cliente frequentemente resulta também
em um melhor alinhamento entre os objetivos de TI e com os objetivos de
negócio da organização.
Melhor Disciplina na Engenharia e Melhor Qualidade Interna: A
utilização de práticas ágeis como redução de dívida técnica (melhorar a
qualidade interna do produto), refactoring, desenvolvimento orientado a
testes e programação em par, unido ao mindset de qualidade estimulado de
pelos métodos ágeis, contribuem para a entrega de produtos com melhor
mantenabilidade, extensibilidade e com menos defeitos.
Redução de Custos: Equipes ágeis são menos propensas a desenvolver
funcionalidades de baixa prioridade ou que se tornaram desnecessárias ao
longo do tempo. Abordagens não ágeis geralmente tendem a cair nesse
problema devido ao grande espaço de tempo entre o levantamento dos
requisitos e entrega do produto. Gomes (2013, p. 10-11)
19
Além dessas vantagens, Gomes (2013), cita outras primazias trazidas pela agilidade:
melhor time-to-market e maior retorno sobre o investimento; melhor visibilidade dos
projetos; maior produtividade; equipes mais motivadas e redução de risco. Todas essas
vantagens são claramente percebidas tanto em ambientes governamentais como em
segmentos privados.
2.3.4. OS MAL-ENTENDIDOS NO MÉTODOS ÁGEIS
Os Métodos Ágeis mostram claramente possuir diversos benefícios em adota-los,
principalmente em times pequenos, onde ficam mais evidentes as vantagens da
agilidade. Entretanto, os Ágeis têm seus mal-entendidos, que devem ser esclarecidos.
Os dois mais comuns são: Projetos ágeis são poucos planejados e que não existe
documentação.
O mal-entendido de que os projetos ágeis são poucos planejados, quando se comparada
com o modelo de desenvolvimento em Cascata. Os métodos ágeis partem da premissa
de que haverá mudanças ao longo do projeto e elas serão bem-vindas, por isso, não é
interessante detalhar todo o planejamento no início, sendo que o esforço de
planejamento ocorre ao longo de todo projeto, mas como em qualquer projeto, os
projetos ágeis não deixam de existem metas de prazos, esforço, orçamento e qualidade e
escopo como em projetos tradicionais de desenvolvimento de software. A imagem a
seguir faz o comparativo entre as diferentes formas e de projeto e as suas gestões.
Figura 2Os diferentes tipos de projetos, e as abordagens de gestão. Fonte IGTI.
20
No projeto caótico, Gomes (2013) ilustra um ambiente de caos gerado pelo pouco
planejamento no desenvolvimento de software:
Agora pense em uma equipe de desenvolvimento de software que não possui
nenhuma regra comum entre os membros da equipe, cada um escreve código
da maneira que acha melhor, uns escrevem testes outros não, alguns utilizam
certas convenções, outros utilizam outras, cada um trabalha em sua
linguagem de programação preferida, alguns trabalham no escritório outros
de casa, cada um define sua frequência de integração do código. Gomes
(2013, p. 27)
Já nos projetos tradicional de software, o desenvolvimento de software é tratado como
se fosse um ambiente totalmente controlado e ordenado, onde toda as variáveis podem
ser isoladas e por isso prever futuros acontecimentos sem desvio de percursos. Mas o
que ocorre “quando tentamos trazer nossas organizações para o extremo da ordem, para
que possamos tornar as coisas mais previsíveis e manter tudo sob controle, criamos uma
série regras, e enrijecemos o sistema, tornando-o pouco adaptativo e burocrático”
Gomes (2013, p. 26).
Os métodos ágeis são o meio termo entre caótico e previsível, o que seria um ambiente
complexo, onde há a auto-gestão, adaptativo a mudanças e tem finalidade de gerar valor
ao negócio, sendo seu planejamento ocorre a cada interação ou fase do projeto, sendo o
planejamento por etapas.
O segundo mal-entendido mais comum para quem está ingressando no desenvolvimento
ágil é acreditar que nos métodos ágeis não exista documentação de software. Entretanto
essa documentação existe, apesar da grande diferença evidente em torno da forma de
documentação nos projetos tradicionais e ágeis.
Um exemplo no modelo tradicional, o documento mais importante, é a documentação
dos requisitos, que detalhara e comunicara aos desenvolvedores o que e como será feito,
além de servir como contrato entre o cliente e o desenvolvedor sobre o que será
construído. Sendo também muito utilizada para identificar defeitos quando o software
não possui conformidade com a documentação de requisitos.
21
Contudo nos métodos ágeis valorizam a comunicação, que é dada de forma direta com
seus membros, sendo formado por equipes pequenas, o que não ocasiona a necessidade
de documentar essas informações, reduzindo drasticamente a quantidade de documentos
formais. Além da prática do cliente diretamente envolvido no projeto e prática de
técnicas como o TDD (Test Driven Development) e desenhos simples sobre a solução a
ser criada, deixando o código mais explicativo e auto documentado.
2.4 SCRUM
Segundo GOMES (2013, p. 12) Scrum é o framework mais popular da atualidade, sendo
voltando para gestão de projeto de desenvolvimento de software iterativo e incremental,
com três papeis, um artefato obrigatório e seis eventos, que tenta extinguir problemas
como não comprimento dos prazos, problema de comunicação, mudança de escopo e
estimativa errada do prazo, que são os motivos mais frequentes para o insucesso do
projeto.
Figura 3Visão Geral do Fluxo de um Projeto Scrum. Fonte: SCRUMSTUDY
2.4.1. HISTORICO
A história do Scrum surge baseando em uma estratégia de gerenciamento de fabricação
de produtos industrializados, que foi publicada em artigo chamado “The New Product
Development Game" por Hirotaka Takeuchi e Nonaka Ikujiro que inspirou o
desenvolvimento do Scrum. No Guia SBOK, o guia de conhecimento do Scrum,
constata-se o seguinte breve histórico:
22
Em meados dos anos 80, Hirotaka Takeuchi e Nonaka Ikujiro definiram uma
estratégia flexível e completa para o desenvolvimento de produtos, onde o
time de desenvolvimento trabalha como uma unidade, para alcançar um
objetivo comum. Eles descreveram uma abordagem inovadora para o
desenvolvimento de produtos, que chamaram de abordagem holística ou
"rugby", "onde um time tenta percorrer a distância como uma unidade,
passando a bola para frente e para trás." Eles basearam esta abordagem nos
estudos de caso de diversas indústrias. Takeuchi e Nonaka propõem que o
desenvolvimento do produto não deve ser como uma sequência de corrida de
revezamento, mas sim semelhante ao jogo de rugby em que o time trabalha
em conjunto, passando a bola para frente e para tras movendo-se através do
campo como uma unidade. O conceito de rugby em "Scrum" (onde um grupo
de jogadores se reúnem para reiniciar o jogo) foi introduzido neste artigo para
descrever a proposta dos autores de que o desenvolvimento do produto deve
envolver "o movimento de Scrum campo abaixo ".
Os criadores do Scrum, Ken Schwaber e Jeff Sutherland, demostraram sua ideia de
framework para desenvolvimento de software na conferência Object-Oriented
Programming, Systems, Languages & Applications (OOPSLA) em 1995 nos Estados
Unidos da América, onde receberam diversos feedback com sugestões de melhoria e
como estava sendo a implantação e utilização nos projetos, consolidando essas
informações e chegando ao Scrum conhecido por nós.
2.4.2. PAPEIS
O framework Scrum possui uma quantidade de papeis reduzidos, representado somente
por três papeis, sendo um Scrum Master e Product Owner, e o Time de
desenvolvimento que, são a essência do Scrum para o cumprimento dos objetivos do
Projeto.
23
Figura 4Visão geral dos papéis do Scrum. Fonte: SCRUMSTUDY
O Scrum Master é considerado o facilitador do Time de desenvolvimento, que deve
fornecer um ambiente propício para que as Sprint funcionem sem impedimentos e
interferências, e caso venha a haver algo durante a Sprint que impeça de executar
corretamente, é dever do Scrum Master tenta remover os impedimentos o mais breve. O
Scrum Master também é o responsável por explicar e verificar se o Time de
Desenvolvimento compreende o funcionamento do framework, promovendo a
motivação do Scrum, palestras e acompanhamento com os novatos em ambiente Scrum.
O SBOK resume da seguinte forma o papel do Scrum Master:
O Scrum Master é um facilitador, que garante ao Time Scrum o fornecimento
de um ambiente propício para concluir com sucesso o projeto. O Scrum
Master guia, facilita e ensina as práticas do Scrum para todos os envolvidos
no projeto; remove os impedimentos encontrados pelo time; e, assegura que
os processos do Scrum estejam sendo seguidos. SCRUMSTUDY ( 2016, p.
40)
24
Uma dúvida pertinente a quem está iniciando-se no Scrum, é de acreditar que o Scrum
Master é o Gerente de Projeto. O veja o que o SBOK comenta a respeito:
Observe que o papel de Scrum Master é muito diferente do papel
desempenhado pelo Gerente de Projeto em um modelo tradicional de
gerenciamento de projetos (em cascata/waterfall), em que o gerente de
projeto trabalha como um gerente ou líder para o projeto. O Scrum Master,
no entanto, trabalha como um facilitador, ele ou ela está no mesmo nível
hierárquico que outros membros do Time Scrum - qualquer membro do Time
Scrum que tenha a habilidade de facilitar projetos Scrum, pode se tornar o
Scrum Master de um projeto ou Sprint. SCRUMSTUDY ( 2016, p. 40)
O time Scrum é auto gerenciável e todos estão no mesmo nível hierárquico. O Scrum
Master trabalha servindo o time. Segundo Cruz (2014), ainda são atribuições do Scrum
Master planejar e envolver a organização na adotação do Scrum, gerar mudanças que
aumente a produtividade e trabalhar com outros Scrum Master quando houver, para
aumentar a eficácia da utilização do Scrum.
O Product Owner (P.O) representa o cliente e as outras partes interessadas para o time
de desenvolvimento, cabendo a ele tomar as decisões de negócios relativos ao projeto de
software e esclarecer as dúvida a respeito dos requisitos e critérios de qualidades de
aceitação alinhados com os objetivos do cliente. O SBok define o P.O (também
conhecido como Dono do Produto) como “a pessoa responsável por maximizar o valor
do negócio para o projeto. Ele ou ela é responsável por articular as necessidades dos
clientes e manter a justificativa de negócio para o projeto. O Dono do Produto
representa a Voz do Cliente” (SCRUMSTUDY, 2016, p. 41) . O P.O. é o único
responsável pelo gerenciamente do backlog do produto, sendo o backlog é organizado
conforme a prioridade de itens que agregue maior valor ao negócio.
O Time de Desenvolvimento é um grupo generalista, onde ficaram as pessoas
responsaveis pelo o desenvolvimento da Sprint. O gerencialmente da equipe é auto
organizado, sendo que dentro desse grupo não exista nivel hierarquico e nem
especializações (como programador, arquiteteto de software, designer etc). Vejamos a
definição de Time de Desenvolvimento dada por Rafael Sabbagh:
O Time de Desenvolvimento gerencia o seu trabalho de desenvolvimento do
produto. É ele que determina tecnicamente como o produto será
25
desenvolvido, planeja esse trabalho e acompanha seu progresso. Para tal, tem
propriedade e autoridade sobre suas decisões e, ao mesmo tempo, é
responsável e responsabilizado por seus resultados. (SABBAGH, 2013, p.
61)
O time deve ser pequeno, entre 3 a 9 integrantes, para não prejudicar a auto-organização
e comunicação, deve ser motivado, orientado a excelência técnica do projeto e focado
nas metas estabelecida junto com o P.O.
2.4.3. ARTEFATO
O único artefato do Scrum é o Backlog, que é dividido em três partes: backlog do
produto, backlog da versão de entrega e backlog da Sprint, que são gerenciados pelo
P.O. Existem outros artefatos utilizados no Scrum e em diversas literaturas, entretanto
não são oficiais, não são descritas no Guia do Scrum. A definição de Backlog dada por
Fábio Cruz é:
O backlog é o principal artefato do Scrum. Ele reúne os requisitos do produto
a ser entregue, bem como todo o entendimento necessário para atender aos
requisitos, produzir funcionalidades e, por fim, entregar o produto. Em outras
palavras, é uma lista de todas as características, funções, tecnologias,
melhorias e correções que constituem o produto a ser entregue. (CRUZ,
2014)
A conceituação do backlog do produto é “uma lista de tudo o que se acredita que será
desenvolvido pelo Time de Desenvolvimento no decorrer do projeto” (SABBAGH,
2013). O backlog do produto sempre é atualizado, ordenada conforme as prioridades do
cliente e quando o item se aproxima ao topo da lista, tem seus detalhes expandidos pelo
P.O.
Uma característica do backlog de produto é de estar “em constante evolução e, assim,
nunca está terminado ou completo. Conforme o produto evolui, o Product Backlog é
frequentemente modificado com a adição, subtração, reordenamento e modificação de
seus itens” (SABBAGH, 2013).
26
Figura 5Três exemplos de Product Backlog. Fonte: Rafael Sabbagh
O backlog da versão (existem divergências nas denominações) é “o incremento é a
soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor
dos incrementos de todas as Sprints anteriores” (SABBAGH, 2013). O backlog da
versão é o release, que é a formação de vários Sprints, que isolada seria somente
pedaços do software que não teria contextualização para funcionamento e não
representaria um valor ao cliente.
O backlog da Sprint é “uma lista de itens selecionados do alto do Product Backlog para
o desenvolvimento do Incremento do Produto no Sprint (o quê), adicionada de um plano
de como esse trabalho será realizado (como) ” (SABBAGH, 2013). O que é a lista
escolhida pelo Time de Desenvolvimento e negociada com o P.O na reunião que se
antecede a Sprint, chamada de reunião de planejamento de Sprint. O como, é o plano de
ação correspondente do que será desenvolvido, normalmente se quebra a Sprint em
pedaços menores para facilitar o gerenciamento das atividades. Os itens de Backlog do
Produto selecionados para a Sprint, junto com o plano de entrega destes itens é o
Backlog da Sprint.
2.4.4. EVENTOS
O Scrum possui 5 eventos descritos em seu framework, sendo a Sprint, Reunião de
Planejamento da Sprint, Reuniões diárias, Revisão da Sprint e Retrospectiva da Sprint.
27
A Sprint é o coração do Scrum, um evento que dura em média de duas a seis semanas,
conforme negociado pela equipe e durante esse período todo o esforço é focado no
desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint
anterior. Em cada Sprint é definido o que deve ser construído, um plano de construção e
no final o resultado do trabalho construído. Durante a Sprint, não devem ser feitas
mudanças, as metas de qualidade não podem ser inferiores aos ajustados anteriormente,
e o escopo deve estar claro e renegociado com o P.O caso haja necessidade.
Figura 6Durações Time-Box para Reuniões do Scrum. Fonte: SCRUMSTUDY
Na Reunião de Planejamento é realizado o planejamento da Sprint com o trabalho
colaborativo de todo Time do Scrum, que deve responder os seguintes questionamentos:
- O que será entregue como resultado do incremento da próxima Sprint?
- Como o trabalho necessário para entregar o incremento será realizado?
O primeiro questionamento, a equipe de desenvolvimento trabalha para definir as
funcionalidades que serão desenvolvidas durante toda a Sprint. O P.O apresenta os itens
do backlog do produto ordenados em prioridade para a Equipe de Desenvolvimento e
todo o time colabora para a compreensão do trabalho a ser realizado.
28
Já no segundo questionamento, a Equipe de Desenvolvimento decide como irá construir
essas funcionalidades durante a Sprint e transformar-lhe em um incremento do produto
que agregue valor.
A Reunião Diária é um evento que deve ser realizada com frequência diária, com
duração máxima de 15 minutos, sempre no mesmo local e horário para fomentar o
habito no Time de Desenvolvimento e que tem o objetivo de sincronizar as atividades e
criar um planejamento para as próximas 24 horas. Essa reunião é gerenciada pelo Scrum
Master, que tem a meta de não deixar a reunião se desvirtuar do seu objetivo. Na
Reunião Diária, cada integrante do Time de Desenvolvimento deve responder a três
perguntas:
- O que foi completado desde a última reunião?
- O que será feito até a próxima reunião?
- Quais os impedimentos que estão a caminho?
Ao responder essas perguntas, é possível a equipe avaliar o progresso e maximizar o
sucesso da Sprint, além de dar feedback para o Scrum Master e o P.O.
A Revisão de Sprint conforme Cruz (2014, p. 152):
O objetivo maior dessa reunião é a inspeção do incremento, pelo PO ou pelo
cliente, e a adaptação do backlog do produto se necessário. A melhor maneira
de fazer isso é justamente realizar uma apresentação ao PO de todos os itens
completados na Sprint. A sugestão mais indicada é que o Time faça uma
demonstração do funcionamento do produto, apresentando o que está pronto
e como está realmente funcionando.
E ainda “deve ocorrer ao ͆final do ciclo da Sprint e tem o objetivo de avaliar o que está
sendo e o que deveria ser entregue. Todos participam dessa etapa” (CRUZ, 2014, p.
152).
Logo após finalizar a Reunião de Revisão de Sprint e antes da próxima Sprint, deve-se
ocorrer a Reunião de Retrospectiva da Sprint. O objetivo desta reunião é examinar a si
próprios e criar um plano de melhoria a serem aplicadas na próxima Sprint. A Reunião
de Retrospectiva da Sprint tem 3 propósitos:
- Avaliar como a Sprint foi em relação a pessoas, processos e produtos;
- Identificar itens que foram bem e documentar esse conhecimento para futuras
reaplicações;
29
- Desenvolver um plano de melhorias no modo do Time de Desenvolvimento possa
otimizar seu trabalho.
Ao final da Retrospectiva da Sprint, o Time deverá ter identificado melhorias que serão
implantadas na próxima Sprint.
2.5 GERENCIAMENTO DE PROCESSOS DE NEGÓCIO
2.5.1. CONCEITOS DE GERENCIMENTO DE PROCESSOS DE NEGÓCIOS
Existem diversos livros e artigos com conceitos sucintos para o Gerenciamento de
Processos de Negócios (BPM – Business Process Management), um dos conceitos mais
simples é dados por Baldam, Valle e Rozenfeld (2014, p.13) como:
É uma abordagem disciplinada para identificar, desenhar, executar,
documentar, implantar, medir, monitorar, controlar, e melhorar processos de
negócio com o objetivo de alcançar resultados consistentes e alinhados com
as estrategias de uma organização.
A definição de Gerenciamento de Processos de Negócios dada pelo Guia para o
Gerenciamento de Processos de Negócios (BPM CBOK) é mais extensa e completa
quando se comparada a definição anterior:
Gerencimento de Processos de Negócios representa uma nova forma de
visualizar as operações de negócios que vai além das estruturas funcionais
tradicionais. Essa visão compreende todo o trabalho executado para entregar
o produto ou serviço do processo, independente de quais áreas funcionais ou
localização estejam envolvidas. Começa em um nível mais alto do que o
nível que realmente executa o trabalho e, então, subdivide-se em
subprocessos que devem ser realizados por uma ou mais atividades (fluxos de
trabalho) dentro de funções de negócios (áreas funcionais). As atividades, por
sua vez, podem ser decompostas em tarefas e, adiante, em cenários de
realização da tarefa e respectivos passos. (ASSOCIATION OF BUSINESS
PROCESS MANAGEMENT PROFESSIONALS, 2013, p. 33)
30
Com esses conceitos, vimos que a BPM é uma nova forma de gerencia negócios de
qualquer instituição, por meio de práticas comerciais que torna qualquer processo mais
eficientes e alinhados com os negócios, beneficiando principalmente a TI e
departamentos que trabalhem com inovação. A BPM é uma forma de gestão muito rica
e dinâmica, tendo um ciclo de vida que proporciona melhorias no processo, possuindo
similaridades com o tradicional PDCA.
Figura 7Ciclo BPM. Fonte: Lecom BPM
No portal Lecom BPM existe uma descrição de cada etapa do ciclo BPM:
1. Planejamento e estratégia: Este é o momento de desenvolver uma
estratégia dirigida para processos. Pois tal desenvolvimento oferecerá
estrutura e direcionamento para a gestão contínua dos processos e seu
objetivo macro deve estar alinhado com os da empresa e para isso, é
necessário ter conhecimento sobre as metas da empresa. 2. Análise de
processos de negócio: A análise do processo é quando serão validadas as
informações antes da ação efetivamente. É quando o contexto no qual as
metas e objetivos estão inseridos são medidos e suas variáveis, como fatores
externos, são identificadas. 3. Desenho e modelagem: Na prática, as pessoas
tendem a achar que sabem como o processo funciona, mas ao desenhá-lo é
possível identificar as falhas, repetições e fases desnecessárias. Portanto o
desenho do processo é sua materialização. É neste momento que perguntas
como: O quê, quando, onde, quem e como serão respondidas. Conforme
comentado acima, essas três primeiras fases podem variar conforme a
maturidade da empresa na prática de BPM. Elas podem se tornar uma fase
31
com três etapas, ao invés de três fases. Consequentemente despende de
menos tempo. 4. Implementação de processos: Agora é à hora da ação:
quando o desenho é posto em prática. É o momento também de pequenos
ajustes. 5. Monitoramento e controle: Monitorar ajuda a prover informações
sobre o desempenho através de métricas. E ajuda a pensar em ações de
refinamento. 6. Refinamento: Mediante os resultados é preciso fazer uma
melhoria ou redesenho de determinado processo. O monitoramento deve ser
contínuo para que os resultados sejam alcançados. E assim, obtemos a
satisfação da empresa. (ALVARES, Lecom BPM)
Devido a riqueza de detalhes que o ciclo BPM pode gerar, este trabalho acadêmico se
limitará ao desenho do processo.
2.5.2. MODELAGEM DE PROCESSO DE NEGÓCIO
A modelagem de processos é a atividade de construir modelos. Segundo BALDAM,
VALLE e ROZENFELD (2014) “um modelo é uma representação (com maior ou
menor grau de formalidade) abstrata da realidade (num dado contexto)”. Já para
ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSIONALS
(2013. p.72) tem um significado amplo para modelagem de processos:
Modelagem de processos de negócio é o conjunto de atividades envolvidas
na criação de representações de processos de negócio existentes ou proposto.
Pode prover uma perspectiva ponta a ponta ou uma porção dos processos
primários, de suporte ou de gerenciamento.
O propósito da modelagem é criar uma representação do processo de maneira
completa e precisa sobre seu funcionamanto. Por esse motivo, o nível de
detalhamento e o tipo específico de modelo têm como base o que é esperado
da iniciativa de modelagem. Um diagrama simples pode ser suficiente em
alguns casos, enquanto um modelo completo e detalhado pode ser necessário
em outros.
Para representação da Modelagem de Processo, existe diversas linguagem gráfica de
diagramação para representação de processos como BPMN (Acronico de Business
Process Modeling and Notation, tradução: Notação de Modelagem de Processos de
Negócio), Fluxogramas, EPC (Event-driven Process Chain, tradução livre: Cadeia de
32
Processos orientada a eventos), UML (Unified Modeling Language, tradução:
Linguagem de Modelagem Unificiada), entre outras várias que atendem a algum
objetivo especifico.
A BPMN será a notação de modelagem adotada neste trabalho, por atender a nossa
necessidade de forma mais eficiente, além de ser a notação mais popular. A BPMN foi
criada pela Business Management Initiative (BPMI), posteriormente incorporada ao
Object Management Group (OMG), grupo que gerencia outras notações no mundo da
tecnologia da informação como a UML, por exemplo.
Segundo a ABPMP, as principais caracteristicas do BPMN são que os “ícones
organizados em conjuntos descritivos e analíticos para antender a diferentes
necessidades de utilização” além de a “notação permite indicação de eventos de inícios,
intermediário e fim; fluxo de atividades e mensagens; comunicação intranegócio e
colaboração internegócio”. Ainda conforme a ABPMP, ela tem a caracterista de ser
muito utilizada quando se necessita apresentar um modelo de processo para publico-
alvos distintos, como analistas de negócios, pessoal de tecnologia da informação e
marketing por exemplo. Essas caracteristicas da BPMN geram uma facilidade de uso e
entendimentos por diversos setores e organização pela padronização e estar presente em
diversos setores empresarial, não sendo uma exclusividade do setor de TI, além de ser
versatil para modelar diversas situações em que ocorrem na empresa e ser fácil de
utilizar em ferramentas BPMS( Business Process Management System, tradução:
Sistema de Gerenciamento de Processos de Negócio).
2.5.3. NOTAÇAO BPMN
A seguir serão descritos os principais elementos da notação BPMN, conforme BPMN 2.
De acordo com Baldam, Valle e Rozenfeld, (2014, p.331): “Um evento é algo que
“ocorre” durante o curso de um processo. Eventos indicam o fluxo do processo e
usualmente possuem uma causa (gatilho) ou impacto (resultado)”.
Tabela 1Eventos de BPMN
Eventos
33
Não especifica nenhum fato particular para o início do processo.
Indica que um fato não especificado ocorre no fluxo do processo.
Finaliza o processo garantindo que qualquer fluxo paralelo seja
cancelado (o processo é completamente encerrado).
Indica que o fluxo do processo chegou ao fim sem gerar nenhum
evento em particular.
A tarefa é uma atividade de trabalho no menor nível de granularidade. Ela representa
uma ação no processo que pode ser executada por uma pessoa ou um sistema.
Tabela 2Atividades de BPMN
Atividades
Tarefa Abstrata.
34
Tarefa de Envio.
Tarefa de Execução de Script.
Tarefa Manual.
Tarefa de Envio.
Tarefa de Recebimento que inicia um processo.
Tarefa de Regra de Negócio.
Tarefa de Serviço.
Tarefa de Usuário.
Os Gateways representam alternativas ao fluxo do processo a ser percorrido.
35
Tabela 3Gateways de BPMN
Gateways
Sinaliza que durante a execução da tarefa, múltiplos eventos são
esperados e que qualquer um deles poderá iniciar o fluxo
decorrente do evento.
Dá seguimento ao fluxo por uma condição exclusiva, em que
apenas um dos caminhos será seguido de acordo com uma
informação a ser testada.
Esse elemento indica que existem muitas maneiras para iniciar o
processo e após a conclusão de um deles, o processo começará.
São esperados múltiplos eventos para começar o processo, e
todos devem ocorrer para inicia-lo.
Os elementos de ligação (conectores) para controle dos fluxos de sequência do trabalho
e de comunicação no processo.
Tabela 4Objetos de conexão da BPMN
Objetos de
conexão
Conforme Baldam, Valle e Rozenfeld, (2014, p.333) fluxo de
sequencia “refere-se ao fluxo originario a partir de um evento e
continua através de atividades até o evento final, não depedendo
36
de condição”.
Conforme Baldam, Valle e Rozenfeld, (2014, p.333) fluxo de
sequencia condicional “seguirá depedendo de condições
estabelecida. Somente será usada esta representação quando não
for usada a representação condicional com o losango”.
Conforme Baldam, Valle e Rozenfeld, (2014, p.333) fluxo de
mensagem “é usado para mostrar fluxo de mensagem em duas
entidades que podem enviar e receber. No BPMN duas psicinas
representam duas entidades”.
Conforme Baldam, Valle e Rozenfeld, (2014, p.336) associação
“é usada para associar informações com objetos do fluxo. Textos
e objetos que não sejam do fluxo podem ser usado com objetos
do fluxo.
As Raias (Swimlanes) representam os elementos de organização do fluxo.
Tabela 5Swimlanes da BPMN
Swimlanes
A piscina (pool) é um contêiner de processo de negócio. É
permitido apenas um processo por pool. O nome do pool
representa o processo de negócio que está contido nela.
É uma subdivisão de um pool, que pode ser usada para
representar um papel ou uma área organizacional responsável
pelas tarefas dispostas naquela linha.
Os Artefatos são elementos de complementação com informações visuais no diagrama.
Tabela 6Artefatos da BPMN
Artefatos
37
É um elemento de marcação que permite destacar com fins
puramente visuais, um agrupamento de componentes.
É usado para proporcionar informação adicional sobre um
processo.
Provê informações sobre o que é requerido pela atividade para ser executada e o que ela
produz.
Tabela 7Dados da BPMN
Dados
Representa um conjunto de informações cuja representação é
importante para a compreensão do fluxo do processo.
Representa um repositório de informações de qualquer espécie
que pode ser consultado ou atualizada no decorrer da realização
de alguma tarefa.
38
CAPÍTULO 3
PROPOSTA DA METODOLOGIA
3.1. DESCRIÇÃO DO CASO
A Universidade Federal do Mato Grosso, ao prestar serviços para clientes externos, é
submetida a atender a requisitos contratuais de entregas de artefatos descrevendo como
o software foi projetado. O modelo sugerido pelo Governo do Estado de Mato Grosso, é
um modelo próprio, com diversas fases, atividades, papeis e artefatos. Mostrando-se
inviável para times de desenvolvimentos pequenos e que possui uma grande
rotatividade de funcionários como acontece no IC-UFMT. Para tentar minimizar esses
problemas ocasionados pelo turn-over e estrutura funcional enxuta, uma metodologia
baseada em Scrum e Gerenciamento de Processos de Negócios é sugerida.
3.2. METODOLOGIA ATUAL
O Processo de Desenvolvimento de Software nas Instituições Públicas do Estado de
Mato Grosso, denominado de PDSMT, é uma metodologia baseada no processo de
desenvolvimento em cascata, que possui todas as atividades definidas em seis fases
(concepção, projeto, implementação, teste, homologação e implementação/entrega),
doze papeis e a documentação que serão produzidas em cada fase.
39
Abaixo a imagem descritiva do Processo de Desenvolvimento de Software nas
Instituições Públicas do Estado de Mato Grosso (PDSMT) em fases.
Figura 8Fluxo do Processo de Desenvolvimento de Software nas Instituições Públicas do Estado de Mato Grosso. Fonte: Governo de Mato Grosso
A seguir uma breve descrição das fases do PDS, as informações detalhadas encontram-
se no anexo ao trabalho, onde descreve papeis, atividades, fases e etc.
Na fase do Diagnostico, segundo o Guia de Referência PDSMT, é dada as seguintes
informações sobre essa fase:
A atividade de diagnóstico antecede o início da execução do processo e tem
como finalidade analisar a viabilidade de execução do projeto e, por
conseguinte, o início do desenvolvimento do processo. Através desta
atividade o cliente deve definir o fluxo do negócio que será automatizado e
os requisitos que o sistema deve conter. Estas definições devem ser realizadas
com o auxílio do analista de sistemas. Sendo assim, dois documentos serão
utilizados para iniciar o processo: o fluxo de negócio, cuja elaboração é
altamente recomendável e deve seguir as recomendações do BPMN
(Business Process Modeling Notation – Notação para Modelagem de
Processo do Negócio) e o documento de requisitos elaborado através do
template de Requisitos, cuja elaboração é o referencial para a definição do
escopo do projeto. (PDSMT, 2015, p. 12)
40
Nessa fase somente dois papeis ainda existem, o cliente e o líder de projeto, onde eles
verificam a viabilidade de desenvolvimento do sistema. A descrição das atividades
dessa fase, consta no anexo do trabalho.
A fase de Concepção, segundo o PDSMT é descrita como:
A fase de concepção dá início ao desenvolvimento do software, por este
motivo as decisões sobre a viabilidade de desenvolvimento e a
disponibilidade da equipe já devem ter sido tomadas quando as atividades
desta fase começarem.
Essa fase do PDSMT, é onde possui mais atividade e onde emprega muito tempo
planejando e gerando artefatos como documento de visão, documento de requisitos,
cronograma, pontos por função, ata, diagrama de caso de uso, especificação de caso de
uso, protótipo e glossário.
No Projeto, conforme descrito no PDSMT, “é apresentar a estimativa de prazos e custos
para que seja aprovado pelo Cliente e, após a aprovação, definir os alicerces para
construção do sistema, tais como, arquitetura, modelo de dados e outros”. No projeto é
onde tem a mais intensa participação de diversos papeis.
Na Implementação, somente uma atividade ocorre, entretanto, é muito intensa e pode
ser a mais longa de todas, onde realmente o Software é construído. Segundo a PDS, o
objetivo dessa fase é “elaborar o código fonte da aplicação e realizar os testes iniciais
para certificar-se que o sistema ou módulo desenvolvido pode passar pela fase de testes
para os ajustes finais”.
Na fase de teste, conforme o PDSMT é “assegurar que o sistema será disponibilizado ao
usuário final com a menor chance possível de apresentar um comportamento
inesperado”. Essa fase tem um envolvimento muito próximo com a Implementação,
pois sempre que detectado um erro, ela retorna para a Implementação verificar e corrigir
o problema.
Na Homologação, de acordo com PDSMT, consiste em “certificar que o sistema está
pronto para ser utilizado pelo usuário final” e finalmente a fase de
Implementação/Encerramento, onde é feita a finalização do sistema, ou como descreve
o PDSMT, “objetivo marcar o encerramento de um projeto ou iteração de
desenvolvimento”.
41
3.3. METODOLOGIA PROPOSTA
A metodologia proposta para atender a demanda do Governo do Estado de Mato Grosso
pela Instituto de Computação da Universidade Federal de Mato Grosso, é uma
metodologia que mescla Scrum e Gerenciamento de Processos de Negócios. Ao analisar
o PDSMT verifica-se a existência de muitos processos e papeis que são inviáveis de se
manter em uma equipe com estrutura reduzida como a utilizada pelo IC-UFMT, um
processo com difícil compreensão para quem está iniciando na equipe de um projeto já
existente, onde as atividades só seguem no fluxo, não existindo alternativas e além de
não proporcionar a entrega frequente que agregue valor ao cliente ao final de cada
iteração.
Uma tabela comparativa entre as duas metodologias a seguir:
Tabela 8Comparativo entre PDSMT e Metodologia Proposta
PDSMT METODOLOGIA PROPOSTA Papeis 13 7 Fases 7 5 Atividades 23 28 Participação ativa do cliente
Não Sim
Modelo Cascata Iterativo e evolutivo Metodologia baseada em
RUP Scrum
Notação gráfica
Fluxograma simples BPMN
Se fizermos uma analogia da metodologia proposta com o Scrum, veremos muitas
semelhanças, apesar da metodologia proposta possuir suas atividades mais detalhada, o
que ocasiona maior quantidade de atividades, papeis e fases. No Scrum o papel de
Product Owner está associado ao cliente e coordenador de projeto, do Scrum Master é
realizado parte pelo coordenador de projeto e as atividades realizada pelo time de
desenvolvimento são dividas para os papeis de analista de requisitos e negócios,
projetista de banco de dados, arquiteto de softwares, desenvolvedores e equipe de
qualidade. Não existe a necessidade de cada papel ser realizado por um profissional
diferente, a divisão é para deixar mais didático. Se a visão geral do Scrum for divido em
fases, obteremos basicamente 3 fases, planejamento, desenvolvimento e entrega. Na
42
metodologia proposta existem 5 fases, a fase de planejamento é similar com a do Scrum,
onde é realizada a caso de negócio do projeto, declaração da visão do projeto, backlog
priorizado do produto e cronograma de planejamento da release, a metodologia
proposta atende essas atividades, de com uma outra abordagem, que se estende a duas
fases, planejamento do projeto e execução do projeto\planejamento do
desenvolvimento. No Scrum o que seria a fase de desenvolvimento, nessa metodologia
existe um desdobramento em duas fases, Execução do Projeto\Desenvolvimento de
Software e Execução do Projeto\Homologação do Software, onde o desenvolvimento
ocorre e as entregas periódicas acontecem. E a fase de entrega aqui é denominada de
Encerramento do Projeto, onde é feita as lições aprendidas, desmobilização da equipe e
encerramento do projeto.
Figura 9Visão Completa do Processo. Fonte: O próprio.
O processo proposto é mais detalhado por papeis, fases e atividades, para facilitar a
compreensão para novos integrantes no decorrer do projeto.
3.3.1. PLANEJAMENTO DO PROJETO
A fase de Planejamento do Projeto aborda os papeis do cliente, Coordenador de Projeto
(PMO) e Analista de Requisitos e Negócios. Nessa fase são entendidos os “por que”,
43
riscos e prazo que o sistema deve ser elaborado.
Figura 10Fase de Planejamento. Fonte: o próprio.
A seguir as descrições das atividades da fase de Planejamento do Projeto:
Descreve a necessidade: o cliente justifica a necessidade do sistema e descreve
brevemente como imagina que o sistema atenderá sua necessidade.
Modelagem do Processo do Negócio: Realiza a modelagem macro do processo de
negócio e faz o levantamento de todos os artefatos necessários para tal, que serão base
para o levantamento de requisitos e criação dos artefatos de gestão. Como artefato de
entrega possui a ata de reunião.
Validar a Modelagem do Processo de Negócio: A validação da modelagem do processo
de negócio junto ao cliente para verificar se a modelagem está coerente.
Essa atividade recebe como entrada a Modelagem do Processo de Negócio e como saída
entrega a Ata de Reunião com parecer favorável, ou retorna para atividade anterior para
ser corrigida e novamente submetida.
44
Elaborar Documento de Visão: O Documento de Visão é um artefato fundamental na
fase de concepção, através deste documento é possível firmar um acordo com o cliente
de quais os principais requisitos do sistema, quais funcionalidades serão abordadas e
quais as expectativas do cliente sobre a forma que o sistema auxiliará em suas
necessidades e quais leis e normas o sistema deve obedecer. Como artefato de entrega
possui o Documento de Visão.
Criar Repositório de Dados: o repositório de dados será composto de ferramentas Git
(Controlador de Versão), Redis, Docker, entre outros, que auxilie na organização dos
binários e documentação do sistema a ser desenvolvido.
Identificar os Riscos do Projeto: A identificação dos riscos pertinentes ao projeto, que
ameaça a sua obtenção de sucesso, como prazo de entrega, capacidade técnica etc.
Nessa atividade não existe entrega obrigatória conforme o PDSMT.
Elaborar Cronograma de Fase: Nesta tarefa é elaborada o Cronograma das fases
conforme a Modelagem de Processo de Negócios, repositórios de dados e identificação
dos riscos, para estimar os prazos. Nessa atividade não existe entrega obrigatória
conforme o PDSMT.
3.3.2 EXECUÇÃO DO PROJETO
A fase de Execução do Projeto\Planejamento, é uma fase subsequente da fase de
Planejamento, onde ainda são realizados os planejamentos do sistema, mas agora com
características mais técnicas e menos negocial. Esta fase é trabalhada pelos papeis do
Coordenador de Projetos, Analista de Requisitos e Negócios, Projetista de Banco de
Dados, Arquiteto de Software e Equipe de Qualidade.
45
Figura 11Fase de Execução. Fonte: o próprio.
A seguir as atividades da fase de Execução do Projeto/Planejamento de
Desenvolvimento:
Monitorar e controlar o projeto e as entregas: Essa atividade encontra-se em transição,
com o início nesta fase, entretanto a maior parte da sua atividade acontece na fase de
Execução do Projeto/Desenvolvimento do Software. Essa atividade envolve atualização
do cronograma, dos riscos, do escopo e demais áreas da gestão. Ficar atento as entregas,
no que tange aos prazos e a qualidade. Atividade exercida pelo Coordenador de Projeto
(PMO). Nessa atividade não existe entrega obrigatória conforme o PDSMT.
46
Elaborar Glossário: Essa atividade encontra-se em transição, com o inicio nesta fase,
entretanto a maior parte da sua atividade acontece na fase de Execução do
Projeto/Desenvolvimento do Software. Essa atividade descrever as informações técnicas
que seja de fácil entendimento a todos os participantes do projeto, inclusive para o
cliente. Atividade exercida pelo Coordenador de Projeto (PMO). Como artefato de
entrega possui o Glossário.
Elaborar Diagramas e especificar os Caso e Uso: o Diagrama de Caso de Uso é
importante por oferecer uma visão geral do sistema e dos usuários (atores) que irão
interagir com ele. Ao ver o diagrama o cliente deve ter uma idéia das principais
funcionalidades que o sistema deve possuir. Atividade exercida pelo Analista de
Requisitos e Negócios. Como artefato de entrega possui a Especificação de Caso de
Uso.
Obter o aceite do cliente: fase em que o cliente valida o que será desenvolvido e
concorda com o time o que foi proposto ou sugere alterações. Atividade exercida pelo
Analista de Requisitos e Negócios. Como artefato de entrega possui o termo de Aceite.
Como entrada essa atividade recebe o Diagrama de Caso de Uso e sua especificação, e
como saída o aceite do cliente, em caso de um aceite positivo, a atividade prossegue
para a próxima, caso contrário retorna à atividade anterior para correção.
Elaborar o protótipo com o cliente: elaborar e obter o aceite do cliente com o protótipo.
Atividade exercida pelo Analista de Requisitos e Negócios. Como artefato de entrega
possui a ata de Reunião.
Receber sugestão do cliente: a equipe válida com o cliente o protótipo proposto e sugeri
melhorias ou aprova para atividade seguinte. Como entrada essa atividade recebe o
protótipo e saída a resposta de uma validação junto ao cliente, caso tenha sido aprovado
sem sugestões de alteração a atividade segue o fluxo, caso contrário, ela retorna à
atividade para correções e posterior validação do cliente.
Modelar o banco de dados: criar um modelo que explique as características de
funcionamento e comportamento de um software a partir do qual ele será criado,
facilitando seu entendimento e seu projeto, através das características principais que
47
evitarão erros de programação, projeto e funcionamento. Atividade exercida pelo
Projetista de Banco de Dados. Como artefato de entrega possui Documentação de
Arquitetura de Software.
Propõem a arquitetura do sistema: nessa tarefa são definidos os componentes de
software, suas propriedades externas, e seus relacionamentos com outros softwares,
além de ser realizada a documentação de tudo o que foi realizado, para posteriores
consultas. Atividade exercida pelo Arquiteto de Softwares. Como artefato de entrega
possui Documentação de Arquitetura de Software.
Receber sugestão e aceite do cliente: o cliente verifica a arquitetura de software
proposta e verifica a necessidade de alguma alteração. Como entrada esse processo
recebe a proposta de arquitetura de software, valida com o cliente com sugestões e caso
não haja correções, segue o fluxo. Entretanto, se a arquitetura proposta não atender o
cliente, o fluxo retorna para ser proposta outra arquitetura com sugestão fornecida pelo
cliente.
Elaborar Plano de Teste: nessa fase é elaborado um documento com uma abordagem
sistemática para o teste de sistemas com hardware ou software. Atividade exercida pela
Equipe de Qualidade. Como artefato de entrega possui Plano de Teste.
3.3.3. DESENVOLVIMENTO DE SOFTWARE
A fase de Execução de Projeto/Desenvolvimento de Software é onde os conceitos do
Scrum está mais presente, com ciclos definidos e qual a equipe que trabalha com
metodologia de desenvolvimento ágil Scrum irá trabalhar intensamente. As fases
anteriores não são características de metodologias ágeis, entretanto é a forma de
trabalho utilizada pelo Governo de Mato Grosso ao realizar o planejamento de Software
as empresas contratadas ou internamente.
Essa fase possui somente 4 atividades, sendo duas que vieram de transição iniciada na
fase anterior como Monitorar e Controlar os projetos e as entregas e Elaborar Glossário,
e duas atividades exclusivas dessa fase e que possui os loops de execução, tais
atividades são: Desenvolver as aplicações sobre os Casos de Uso e Elaborar Casos de
Teste.
48
As seguintes atividades da fase de Execução de Projeto/Desenvolvimento de Software:
Monitorar e controlar o projeto e as entregas: Essa atividade encontra-se em transição,
com o início nesta fase, entretanto a maior parte da sua atividade acontece na fase de
Execução do Projeto/Desenvolvimento do Software. Essa atividade envolve atualização
do cronograma, dos riscos, do escopo e demais áreas da gestão. Ficar atento as entregas,
no que tange aos prazos e a qualidade. Atividade exercida pelo Coordenador de Projeto
(PMO). Nessa atividade não existe entrega obrigatória conforme o PDSMT.
Elaborar Glossário: Essa atividade encontra-se em transição, com o início nesta fase,
entretanto a maior parte da sua atividade acontece na fase de Execução do
Projeto/Desenvolvimento do Software. Essa atividade descrever as informações técnicas
que seja de fácil entendimento a todos os participantes do projeto, inclusive para o
cliente. Atividade exercida pelo Coordenador de Projeto (PMO). Como artefato de
entrega possui o Glossário.
49
Figura 12Fase de Desenvolvimento de Software. Fonte: o próprio.
Desenvolver a aplicação sobre os Casos de Uso: São codificados os sistemas a partir de
informações do caso de uso proposto pela equipe e validado com o cliente. Atividade
exercida pelo Desenvolvedores. Como artefato de entrega possui o código-fonte ou
executáveis.
Elaborar Casos de Teste: aqui são elaborado um conjunto de condições usadas para o
teste de software. Atividade exercida pela Equipe de Qualidade. Como artefato de
entrega possui o Caso de Teste.
50
3.3.4. HOMOLOGAÇÃO DO SOFTWARE
A fase de Homologação do Software também utiliza a metodologia ágil de
desenvolvimento de software, sendo similar ao um ciclo iterativo do Scrum, onde
executados os testes, corrigido os problemas encontrados e validado com o cliente. Essa
é uma fase muito importante para o êxito do software que está sendo desenvolvido.
Nesta etapa, ela está composta de 4 atividades, sendo que uma possui subatividades.
As atividades dessa fase são: Executar os casos de teste e corrigir bugs encontrados
(aqui existe subatividades), Elaborar Relatório de Teste, Elaborar Homologação com
cliente e Entregar Sistema/Release.
Na fase de Homologação, somente 3 papeis trabalham, sendo Analista de Requisitos e
Negócios, Desenvolvedores (somente quando é encontrado alguma falha durante a
execução dos testes) e Equipe de Qualidade.
51
Figura 13Fase de Homologação. Fonte: o próprio.
A seguir a descrição de cada atividade da fase de Homologação:
52
Executar os casos de testes e corrigir os bugs encontrados: aqui são testadas as
condições e obtido os resultados de onde será necessário executar alguma correção no
sistema. Atividade exercida pela Equipe de Qualidade em sincronia com os
Desenvolvedores, quando encontrada uma falha nos testes, os Desenvolvedores ficam
responsável pela correção e submeter novamente o caso de teste para equipe de
qualidade. Essa atividade é composta de subatividades conforme o fluxo a seguir:
Figura 14Subatividade de Executar os Casos de Teste e Corrigir bugs. Fonte: o próprio.
Sendo a atividade de executar os casos de testes e corrigir os bugs encontrados, inicia-se
aplicando o caso de teste, caso o teste seja satisfatório e não apresente erros, ele será
finalizado com sucesso, entretanto se o caso de teste apresente erro ou não seja
satisfatório, ela deve ser informada na ferramenta de bugs para a equipe de
desenvolvimento, e subsequente a Equipe de desenvolvimentos corrige os bugs
apresentado durante o teste. Como artefato de entrega possui o Caso de Testes.
Elaborar Relatório de Teste: aqui são produzidos os relatórios dos testes conforme o
que foi testado e seus resultados. Serve para nortear toda a equipe sobre os erros
cometidos e gerenciar para que futuramente não ocorra os mesmos erros, e caso ocorra,
já tem informações de subsidio para solução. Atividade exercida pela Equipe de
Qualidade. Como artefato de entrega possui o Relatório de Teste.
Elaborar Homologação: homologar o sistema com o cliente, verificando se a suas
necessidades foram atendidas e possíveis alterações no sistema ainda são permitidas,
desde que não altere o escopo inicial do projeto. Essa atividade é frequente, ao final de
53
cada iteração é verificado se o que foi produzido agregara valor ao cliente. Atividade
exercida pelo Analista de Requisitos e Negócios. Como artefato de entrega possui o
Documento de Homologação.
Receber sugestões e aceito do cliente: receber sugestões e aceite do cliente na atividade
de homologação. Como entrada essa atividade recebe o documento de homologação e
faz a validação com o cliente, caso a atividade não tenha sugestões de alteração, o
cliente dá o aceite a atividade segue o fluxo, caso contrário, retorna para atividade de
homologação do cliente onde será feita as alterações solicitadas. Como artefato de
entrega possui o Termo de Aceite e Documento de Homologação.
Entregar Sistema/Release: nessa fase é realizada a entrega do que foi desenvolvido para
o cliente, podendo ser o sistema completo ou uma parte funcional e seus complementos.
Atividade exercida pelo Analista de Requisitos e Negócios. Como artefato de entrega
possui o Termo de Aceite.
3.3.5 ENCERRAMENTO DO PROJETO
A última fase do processo de desenvolvimento de software proposto é o Encerramento
do Projeto, onde como o Scrum, tem a função de documentar as lições aprendidas
durante o projeto para futuramente servir de aprendizagem e subsidio para decisões em
outros projetos.
Ele é composto somente de duas atividades e somente o Coordenador de Projeto tem
atribuições estabelecida, sendo as atividades de atualizar documento de lições
aprendidas e desmobilizar a equipe.
54
Figura 15Fase de Encerramento. Fonte: o próprio.
Criar documentos de lições aprendidas: atualiza a documentação com as lições
aprendidas durante o projeto, podendo ser com realizar uma nova forma de testes como
uma adaptação da metodologia que apresentou resultados positivos etc. Essa atividade é
similar a retrospectiva do Sprint, uma grande oportunidade para rever tudo o que deu
certo e tudo o que pode ser melhorado para o próximo Sprint. Atividade exercida pelo
Coordenador de Projetos (PMO). Não possui artefatos de entrega obrigatório, mas é
sugerido a realização de uma ata com o conhecimento adquirido.
Desmobilizar as equipes: a equipe é desalojada desse projeto e fica disponível para
participar de outros projetos. Atividade exercida pelo Coordenador de Projetos (PMO).
Não possui artefatos de entrega obrigatório, entretanto recomenda-se a criação de uma
ata informado todos os participantes e o que foram realizados pelos mesmos.
55
CAPÍTULO 4
CONCLUSÕES
A ideia de desenvolvimento de uma metodologia mesclada surgiu de uma dificuldade
enfrentada pelo Instituto de Computação da Universidade Federal do Mato Grosso, ao
atender o Governo do Estado de Mato Grosso, que propõe um processo de
desenvolvimento de software, baseado no tradicional modelo em cascata, com diversas
atividades, papéis e artefatos, que se mostra inviável no cenário do IC-UFMT, pois o
time de desenvolvimento é enxuto e possui problemas com turn-over funcional.
Sendo a metodologia proposta para resolução do problema, é uma mescla de PDSMT,
Scrum e BPMN, respeitando todas as entregas de artefatos solicitada pelo Governo do
Estado de Mato Grosso.
O PDSMT foi utilizado para basear-se no Planejamento do Projeto e Planejamento do
Desenvolvimento, além de nortear as atividades necessárias e os artefatos essenciais das
entregas.
O Scrum por ser considerada uma metodologia ágil que preza mais pelo gerenciamento
do processo e sendo menos inciso em técnicas de desenvolvimento, quando comparada
com outras metodologias ágeis com o Extreme Programming (XP) por exemplo,
mostrou-se apta ao alinhamento com PDSMT e BPMN.
E a notação de Processo de Negócios foi essencial como facilitador do entendimento,
por sua notação ser de fácil compreensão e de conhecimento comum de diversas áreas
profissionais, não ficando restritos a área de Tecnologia da Informação.
Durante a concepção da ideia nova da metodologia a ser criada, diversas dificuldades
foram encontradas, desde a escolha de uma metodologia ágil existente que poderia
atender à necessidade do IC-UFMT, em conjunto com o PDSMT e utilização de alguma
técnica que facilitasse a gestão do conhecimento e agregasse valor a metodologia, sendo
a escolha de BPMN por atender esses requisitos.
Para o futuro, esperasse a validação da metodologia proposta e informações dos
resultados obtidos, para compilação dos dados que gera indicadores para otimizar a
metodologia e aplicar ao máximo os conceitos de Gerenciamento de Processos de
Negócios, expandindo do Business Process Modeling Notation (BPMN) e sua
56
aplicação projetos, não sendo restritos ao IC-UFMT e Governo do Estado de Mato
Grosso, podendo ser uma metodologia aderente a qualquer organização.
57
REFERÊNCIAS
BIBLIOGRÁFICAS
ALVARES, S. O ciclo de vida BPM - Lecom, Lecom BPM. Disponivel em:
<http://www.lecom.com.br/blog/2013/08/28/o-ciclo-de-vida-bpm/>. Acesso em: 15 Junho
2016.
ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSIONALS. BPM CBOK: Guia para o
Gerenciamento de Processos de Negócio. 1ª. ed. São Paulo: [s.n.], 2013.
BALDAM, R.; VALLE, R.; ROZENFELD, H. Gerenciamento de Processos de Negócio BPM: Uma
referência para implantação prática. 1ª. ed. Rio de Janeiro: Elsevier, 2014.
CRUZ, F. O guia completo do Scrum e da agilidade em projetos. 1ª. ed. São Paulo: BRASPORT ,
2014.
DENNIS, A.; WIXOM, B. H.; ROTH, R. M. Análise e Projeto de Sistemas. 5ª. ed. Rio de Janeiro:
LTC, 2014.
GOMES, A. F. Agile: Desenvolvimento de software com entregas frequentes e foco no valor de
negócio. 1ª. ed. São Paulo: Casa do Código, 2013.
MANIFESTO para o desenvolvimento ágil de software. Manifesto para o desenvolvimento ágil
de software, 20 Março 2001. Disponivel em:
<http://www.manifestoagil.com.br/principios.html>. Acesso em: 20 Março 2016.
SABBAGH, R. Scrum: Gestão Ágil para Projetos de Sucesso. São Paulo: Casa do Código, 2013.
SCRUMSTUDY. Um Guia para o Conhecimento em Scrum (Guia SBOK™). Phoenix: [s.n.], 2016.