UNIVERSIDADE DO SUL DE SANTA CATARINA
CAMPUS DA GRANDE FLORIANÓPOLIS
CURSO DE ESPECIALIZAÇÃO EM ENGENHARIA DE PROJETOS E SOFTWARE
GUILHERME MARTINS DA SILVA
INCORPORAÇÃO DE PRÁTICAS ÁGEIS EM UM PROCESSO
DE DESENVOLVIMENTO ALINHADO AO MPS.BR
Florianópolis
2013
GUILHERME MARTINS DA SILVA
INCORPORAÇÃO DE PRÁTICAS ÁGEIS EM UM PROCESSO
DE DESENVOLVIMENTO ALINHADO AO MPS.BR
Projeto de Pesquisa apresentado à disciplina
de Metodologia da Pesquisa Científica,
como requisito parcial para a obtenção do
título de Especialista em Engenharia de
Projetos e Software.
Prof. Dr. Jean Carlo Rossa Hauck
Florianópolis
2013
1
GUILHERME MARTINS DA SILVA
INCORPORAÇÃO DE PRÁTICAS ÁGEIS EM UM PROCESSO
DE DESENVOLVIMENTO ALINHADO AO MPS.BR
Este trabalho de Conclusão de Curso foi julgado
adequado à obtenção do título de Especialista em
Engenharia de Projetos de Software e aprovado em
sua forma final pelo Curso de Engenharia de
Projetos de Software, da Universidade do Sul de
Santa Catarina.
Florianópolis, 11 de Junho de 2013.
__________________________________
Prof. e orientador Jean Carlo Rossa Hauck, Dr.
Universidade do Sul de Santa Catarina
__________________________________
Prof. Aran Bey Tcholakian Morales, Dr.
Universidade do Sul de Santa Catarina
2
SUMARIO
1. INTRODUÇÃO ................................................................................................................ 4
1.1
PROBLEMA ................................................................................................................... 5
1.2
JUSTIFICATIVA ............................................................................................................ 5
1.3
OBJETIVOS .................................................................................................................... 6
1.3.1
Objetivo Geral .......................................................................................... 6
1.3.2
Objetivos específicos ................................................................................. 6
2. MARCO TEÓRICO ......................................................................................................... 7
2.1
MPS.BR ........................................................................................................................... 7
2.1.1
Níveis de Maturidade ............................................................................... 8
2.2
SCRUM ......................................................................................................................... 12
2.2.1
O Time Scrum ......................................................................................... 13
2.2.2
O Product Owner ................................................................................... 13
2.2.3
Equipe de Desenvolvimento ................................................................... 13
2.2.4
O Scrum Master ..................................................................................... 14
2.2.5
Sprint ....................................................................................................... 14
2.2.6
Reunião Diária ........................................................................................ 15
2.2.7
Backlog do Produto ................................................................................ 15
2.2.8
Backlog da Sprint ................................................................................... 15
3.
MÉTODOS ................................................................................................................... 16
3.1
CARACTERIZAÇÕES DA PESQUISA ...................................................................... 16
3.2
ETAPAS DA PESQUISA ............................................................................................. 16
3.3
DELIMITAÇÃO DO TRABALHO .............................................................................. 17
3.4
A EMPRESA ................................................................................................................. 17
3.5
SAC ............................................................................................................................... 18
3.6
PONTOS A SEREM ABORDADOS ........................................................................... 18
4
ESCOLHA E USO DAS FERRAMENTAS ................................................................. 20
4.1
REUNIÃO DE KICK-OFF ........................................................................................... 20
4.2
PLANNING POKER ..................................................................................................... 20
4.3
REUNIÃO DIÁRIA ...................................................................................................... 23
4.4
PRODUCT BACKLOG E SPRINT BACKLOG.......................................................... 23
4.5
USO DO SAC................................................................................................................ 23
4.6
KANBAN ...................................................................................................................... 27
4.6.1
Quadro Kanban ...................................................................................... 27
4.6.2
Avatar ...................................................................................................... 29
4.6.3
Post-It....................................................................................................... 29
4.6.4
Gráfico de Burndown ............................................................................. 31
5
CONCLUSÕES............................................................................................................... 33
6
SUGESTÕES PARA TRABALHOS FUTUROS ........................................................ 34
7
REFERÊNCIAS ............................................................................................................. 35
3
1. INTRODUÇÃO
Atualmente no nosso ramo da tecnologia, vemos várias empresas se destacando e
ganhando cada vez mais um lugar no só seu mercado, e para que este crescimento senha
contínuo, essas devem investir cada vez mais em diferenciais que as sobressaiam.
Um dos meios de se destacar perante a concorrência é a adoção de um modelo de
processos tecnológicos de desenvolvimento, ou até mesmo metodologias de desenvolvimento
ágil, os quais dentro de suas especialidades podem fazer com que a empresa cresça de forma
padronizada e também aumente o seu coeficiente de produção.
Como metodologia de processo, o MPS.BR (SOFTEX, 2013), foi escolhido pela
sua extrema aceitação de mercado e também pela disponibilidade dos avaliadores para
obtenção do selo de qualidade (por ser um modelo nacional). Já como metodologia de
desenvolvimento ágil, o SCRUM (CRUZ, 2011) torna-se quase uma opção padrão devido a
sua vasta quantidade de material disponível para pesquisa e também flexibilidade para
adaptações.
Neste compasso, o desenvolvimento de um modelo alinhando utilizando-se dessas
duas fronteiras precisa ser criado, tendo em vista suas diferentes abordagens sobre o processo
como um todo e visando um aproveitamento satisfatório de ambos.
4
1.1
PROBLEMA
Pela necessidade de um diferencial perante o mercado e para atender exigências por
parte de seus clientes, a empresa estudada adotou o modelo de referência para qualidade
conhecido como MPS.BR1 Nível G (SOFTEX, 2012), no qual, estão escritas melhores
práticas de desenvolvimento de software utilizadas atualmente. Entretanto, nem todas as
unidades organizacionais seguem completamente as práticas do MR-MPS-SW (SOFTEX,
2012), pois algumas equipes também na fase de desenvolvimento utilizam práticas vindas de
metodologias ágeis, principalmente o SCRUM (CRUZ, 2011), onde ao contrário do processo
burocrático de desenvolvimento, visa um aumento da produtividade, desempenho e um maior
foco na solução do problema, utilizando-se de ferramentas de fácil compreensão e eficazes
métodos de monitoramento de atividades.
Pela divergência das duas práticas utilizadas, não é utilizado hoje em algumas
unidades organizacionais o paralelismo entre as elas, deixando assim grande parte da empresa
fora dos projetos alinhados ao MPS.BR. Já as equipes responsáveis por seguir este padrão,
não desenvolvem no mesmo ritmo das demais, e também não aproveitando algumas técnicas
que já são conhecidas e que melhorariam seu rendimento.
Nesse sentido, esse trabalho busca identificar alternativas de como inserir técnicas
ágeis para o melhoramento de desempenho mesmo em projetos rígidos seguidores da
metodologia MPS.BR.
1.2
JUSTIFICATIVA
Visando uma harmonização das práticas ágeis e a inserção das mesmas em
projetos alinhados ao modelo de referência do MPS.BR, é necessário um estudo que viabilize
uma integração entre as metodologias visando sempre o ganho de desempenho sem a perda do
foco no modelo de desenvolvimento adotado pela empresa.
1
MPS.BR - Melhoria de Processo do Software Brasileiro
5
1.3
OBJETIVOS
1.3.1 Objetivo Geral
Incorporar práticas ágeis a um processo de desenvolvimento alinhado ao nível “G”
do modelo de referência MR-MPS-SW do MPS.BR.
1.3.2
Objetivos específicos
•
Levantar
as
práticas
ágeis
utilizadas
atualmente
pelas
equipes
de
desenvolvimento de software;
•
Efetuar mapeamento das praticas ágeis identificadas;
•
Estudar o modelo de processos de desenvolvimento de software descritos no
modelo MPS.BR adotado pela empresa escolhida e identificar pontos a serem explorados para
inserção de práticas ágeis a fim de melhorar o desempenho deste.
•
Padronizar o uso das práticas ágeis e viabilizar a implantação do processo nos
novos projetos a serem desenvolvidos.
6
2.
MARCO TEÓRICO
Neste capítulo são apresentados conceitualmente o modelo de melhoria MPS.BR e
a metodologia de desenvolvimento ágil Scrum e é dada também uma introdução a empresa
alvo e um software a ser envolvido no processo.
2.1
MPS.BR
O programa MPS.BR foi criado em 2003 coordenado pela Associação para
Promoção da Excelência do Software Brasileiro (SOFTEX). Hoje, já consolidado do mercado
é um modelo referência sendo que tem como base modelos e normas internacionais como o
ISO/IEC2 15504 (Segundo a INFORMABR (2002): "ISO: Trata-se de uma organização
internacional formada por um conselho e comitês com membros oriundos da maioria dos
países" e "IEC: É uma organização voltada para o aprimoramento da indústria da
informação") e CMMI-DEV®3, onde descritos no próprio guia como referencias originárias,
trata-se de padrões de normas internacionais, trazendo processos e atividades referentes neste
caso, a produção de software. (SOFTEX, 2012)
Tendo como objetivo fomentar uma melhoria dos processos de desenvolvimento
de software, o modelo apresenta duas metas a serem atingidas:
Meta técnica: visa à criação e aprimoramento do modelo MPS e;
Meta de mercado: visa à disseminação e adoção do modelo MPS em todas as
regiões do país de forma acessível tanto a pequenas empresas de desenvolvimento de software
quanto a grandes empresas do setor público e privado.
Este modelo veio como resposta a necessidade crítica para uma melhora na
qualidade de processos no desenvolvimento de software.
O modelo encontra-se descrito sob quatro guias:
• Guia Geral: descrição geral do modelo MPS.BR
• Guia de Aquisição: Processos para aquisição de software
2
3
ISO - International Standartization Organization / IEC - International Engineering Consortium
CMMI-DEV® 2 - Capability Maturity Model Integration for Development
7
• Guia de Avaliação: Métodos de avaliação, requisitos para avaliadores, etc..
• Guias de Implementação: Orientação para implementação do modelo.
Modelo MPS (SOFTEX, 2012)
2.1.1 Níveis de Maturidade
O modelo de referência do MPS.BR está dividido em Níveis de maturidade que
podem ser definidos como grau de proficiência obtidos pela empresa que os obteve. Para
alcançar cada um dos níveis é necessário avaliação de processos e sua devida documentação
executada pelos avaliadores credenciados pela própria SOFTEX. Os níveis estão descritos na
seguinte ordem decrescente de grau de maturidade:
8
Nível
Definição
Processos
A
Em Otimização
Análises de
Resolução
B
Gerenciado Quantitativamente
Gerência de Projetos - GPR (evolução)
Definido
Gerência de Riscos - GRI
Desenvolvimento para Reutilização - DRU
Gerência de Decisões - GDE
Largamente Definido
Verificação - VER
Validação - VAL
Projeto e Construção do Produto - PCP
Integração do Produto - ITP
Desenvolvimento de Requisitos - DRE
Parcialmente Definido
Gerência de Projetos - GPR (evolução)
Gerência de Reutilização - GRU
Gerência de Recursos Humanos - GRH
Definição do Processo Organizacional - DFP
Avaliação e Melhoria do Processo
Organizacional - AMP
F
Gerenciado
Medição - MED
Garantia da Qualidade - GQA
Gerência de Portfólio de Projetos - GPP
Gerência de Configuração - GCO
Aquisição - AQU
G
Parcialmente Gerenciado
Gerência de Requisitos - GRE
Gerência de Projetos - GPR
C
D
E
Causas
de
Problemas
e
Tabela de Maturidade MPS.BR (RENAPI 2012)
O atual Guia de implementação publicado em 2011 está dividido em 11 partes
sendo individualmente direcionadas as fases ou tipos de organização que queiram melhorar a
qualidade de seus processos.
A divisão ocorre da seguinte maneira:
• Parte 1: Fundamentação para Implementação do Nível G do MR-MPS;
• Parte 2: Fundamentação para Implementação do Nível F do MR-MPS;
• Parte 3: Fundamentação para Implementação do Nível E do MR-MPS;
• Parte 4: Fundamentação para Implementação do Nível D do MR-MPS;
9
• Parte 5: Fundamentação para Implementação do Nível C do MR-MPS;
• Parte 6: Fundamentação para Implementação do Nível B do MR-MPS;
• Parte 7: Fundamentação para Implementação do Nível A do MR-MPS;
• Parte 8: Implementação do MR-MPS (Níveis G a A) em organizações que
adquirem software;
• Parte 9: Implementação do MR-MPS (Níveis G a A) em organizações do tipo
Fábrica de Software;
• Parte 10: Implementação do MR-MPS (Níveis G a A) em organizações do tipo
Fábrica de Teste;e
• Parte 11: Implementação e Avaliação do MR-MPS (Níveis G a A) em conjunto
com o CMMI-DEV.
Divisão do Guia de Implementação (Guia de Implementação MPS.BR parte 1)
Esta divisão de maturidade exige em cada nível seus artefatos e atributos
específicos para que a empresa seja classificada.
A tabela abaixo fornece um resumo geral dos níveis de maturidade definidos pelo
modelo, seus processos e atributos de processos:
10
Tabela de atributos requeridos (Guia Geral MPS.BR 2011)
11
2.2
SCRUM
O Scrum nasceu como um guia de processos de desenvolvimento que tem como
sua principal meta a diminuição de retrabalho e o máximo aproveitamento de esforço
desempenhado por toda equipe responsável por um projeto.
Segundo o Guia do Scrum (2011, 11)
Scrum é fundamentado nas teorias empíricas de controle de processo, ou empirismo.
O empirismo. O empirismo afirma que o conhecimento vem da experiência e de
tomada de decisões baseadas no que é conhecido. O Scrum emprega uma abordagem
iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos.
Guia do Scrum (CRUZ, 2011)
12
2.2.1
O Time Scrum
O Time Scrum é composto pelo Product Owner, uma Equipe de
Desenvolvimento e um "Scrum Master", que seria como um "guia" da metodologia por ser
conhecedor das técnicas Scrum. A ideia da equipe é ser interdependente e flexível. Cada um
sabe bem o que faz, e o que o outro está fazendo a qualquer momento, sem depender de
fatores externos. (CRUZ, 2011)
2.2.2
O Product Owner
O Product Owner, ou dono do produto, é responsável direto pelo produto,
geralmente é o conhecedor do negócio, podendo ser até um cliente, mas geralmente é o
analista de negócio que fez o levantamento dos requisitos do produto.
Dentre suas responsabilidades o guia lista:
• Expressar claramente os itens do Backlog do Produto;
• Ordenar os itens do Backlog do Produto para alcançar melhor as metas e
missões;
• Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;
• Garantir que o Backlog do Produto seja visível, transparente, claro para todos,
e mostrar o que o Time Scrum vai trabalhar a seguir; e,
• Garantir que a Equipe de Desenvolvimento entenda os itens do Backlog do
Produto no nível necessário. (CRUZ, 2011)
2.2.3
Equipe de Desenvolvimento
A Equipe de Desenvolvimento são as pessoas que realizam o trabalho em si,
são responsáveis pelas liberações das versões e por produzir o produto final.
13
As Equipes de Desenvolvimento devem ser estruturadas e com autonomeia
suficiente organizar e gerenciar seu próprio trabalho. A sinergia tende a se aperfeiçoar,
aumentando a eficiência e a eficácia como um todo.
O Scrum não reconhece títulos para os integrantes de uma Equipe de
Desenvolvimento. Todos são vistos com igualdade, independente da habilidade para
desempenhar tarefas ou função exercida. (CRUZ, 2011)
2.2.4
O Scrum Master
O Scrum Master é responsável por garantir que o Scrum seja entendido e
aplicado. O Scrum Master faz isso para garantir que o Time Scrum adere à teoria, práticas e
regras do Scrum.
O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender todas as
suas interações, cumprimentos de cronograma e como são realizados os releases (entregas). O
Scrum Master ajuda todos e realoca seus recursos para viabilizar uma melhor produtividade.
(CRUZ, 2011)
2.2.5
Sprint
Segundo SHWABER (2011, p. 8) "O coração do Scrum é a Sprint, um time-
box de um mês ou menos, durante o qual um “Pronto”, versão incremental potencialmente
utilizável do produto, é criado. Sprints tem durações coerentes em todo o esforço de
desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior."
(CRUZ, 2011)
14
2.2.6
Reunião Diária
A reunião diária é executada em local de trabalho antes do expediente. Ela dura no
máximo quinze e tem como objetivos o mais simples possível, apenas para dar uma ideia a
todos da posição do grupo e do resultado a ser atingido no dia.
Geralmente, o que é citado por todos os membros da Equipe de Desenvolvimento
é:
• O que foi completado desde a última reunião?
• O que será feito até a próxima reunião?
• Quais os obstáculos que estão no caminho? (CRUZ, 2011)
2.2.7
Backlog do Produto
O Backlog do Produto é uma lista ordenada de tudo o que deve ser feito no
produto. É a origem de toda alteração e todo conteúdo a ser alterado. Ele é de
responsabilidade do O Product Owner que deve manter seu conteúdo, disponibilidade,
ordenação e caso necessário versionamento. (CRUZ, 2011)
2.2.8
Backlog da Sprint
O Backlog da Sprint é um similar ao Backlog do Produto, porem apenas das
alterações vigentes da Sprint atual. Ele contem as alterações que devem ser feitas com seus
responsáveis e cronograma já estabelecido. Até a próxima Sprint, nenhuma tarefa ou
cronograma da equipe podem ser alterados. Toda funcionalidade a ser desenvolvida após uma
Sprint é documentada aqui. (CRUZ, 2011)
15
3.
MÉTODOS
Neste capítulo é apresentada a abordagem metodológica utilizada, incluindo as
pesquisas utilizadas, técnicas escolhidas e os processos para aplicações.
3.1
CARACTERIZAÇÕES DA PESQUISA
As pesquisas utilizadas para elaboração deste trabalho serão direcionadas a
necessidade da empresa. As mesmas serão aplicadas e qualitativas (levando-se em
consideração o estado atual dos processos) e posteriormente como pesquisa de satisfação,
tentando medir o nível melhoramento nos mesmos e relatando problemas a serem levados em
consideração em uma futura aplicação das técnicas.
3.2
ETAPAS DA PESQUISA
Para desenvolvimento deste trabalho, são necessárias três etapas principais:
Etapa 1: Etapa teórica fundamental onde será analisado artefatos que possam ser
alinhados as características e técnicas oriundas de metodologias ágeis. Pontos condizentes de
melhoria e que tenham abertura de utilização de métodos de execução que não venham a
atrapalhar o processo esperado pelas normas do MPS.BR
Etapa 2: Etapa direcionada a realidade atual da empresa, onde são coletadas as
práticas ágeis utilizadas na empresa e incorporadas ao modelo de processo utilizado.
Etapa 3: Avaliação do novo modelo de processo pela equipe.
Será proposto um roteiro onde depois de identificados os atuais papéis dos
colaboradores em um cenário real de desenvolvimento. Nesta fase, seriam inseridos cenários
de processos novos decorrentes de metodologias ágeis e também atribuídos a algumas pessoas
seus respectivos papéis visando controle dos processos ágeis.
A primeira pesquisa será feita em materiais teóricos visando coletar informações e
processos relevantes das metodologias bem como suas integrações com o modelo MPS.BR,
16
ela será basicamente direcionada a materiais on-line, pois os recursos literários ainda não
atendem a necessidade exigida para tal.
As demais pesquisas serão feitas por meio de entrevistas não estruturadas, onde a
intenção é detalhar o máximo possível dos processos utilizados hoje, tanto na parte da
documentação por parte da gerencia de projetos perante aos modelos de processos entregues,
quando na parte de desenvolvimento, mapeando cada passo executado por técnicas ágeis.
Tendo todo material coletado, será criado um padrão e viabilizado para as
equipes. Um padrão de documentação também será estudado para que seja compatível com
artefatos requeridos pelo modelo MPS.BR, estes artefatos, talvez não atendam totalmente aos
requisitos do modelo, mas podem ser mais condizentes com o atual processo utilizado para o
desenvolvimento utilizado pelas equipes, tendo em paralelo, a atual documentação
apresentada hoje.
3.3
DELIMITAÇÃO DO TRABALHO
O presente trabalho limita-se à incorporação de práticas ágeis ao processo
modelado na organização. O resultado deste trabalho consiste em um novo modelo unificando
as práticas ágeis ao processo atual. O modelo é avaliado pelos membros da equipe por meio
de um questionário.
Dadas as restrições de tempo para elaboração do trabalho, a utilização prática do
novo processo proposto está fora do escopo deste trabalho.
3.4
A EMPRESA
A empresa alvo deste trabalho é a Softplan, que como mesmo fala em seu site é
uma das maiores empresas de desenvolvimento de software de gestão do pais.
No mercado desde 1990, desenvolve soluções corporativas para segmentos
específicos de negócios, com foco em cinco áreas de atuação: indústria da
construção, administração pública, projetos cofinanciados por organismos
internacionais, departamentos de infraestrutura, transportes e obras e judiciário,
ministério público e procuradorias. (SOFTPLAN/POLIGRAPH, 2011)
17
Sendo a empresa deste tamanho, se faz necessário um controle interno de
processos, solicitações por parte de clientes e atendimentos em geral, é nesta parte que temos
o SAC.
3.5
SAC
Em uma breve explicação, podemos dizer que o SAC é o sistema utilizado na
empresa para quase todas as tarefas do dia-dia, podendo ser apontamento de horas,
gerenciamento de chamados (SALTs), comunicação com cliente, geração de relatórios
gerenciais, etc.. É um programa desenvolvido dentro da empresa para atender as necessidades
da empresa.
Falando um pouco do controle de atendimento, ele serve tanto para atendimento a
clientes externos quando para atendimentos a clientes internos. A ordem de serviço
(atendimento) intitulada internamente de SALT, possui níveis de controle e tipo.
Por exemplo: uma SALT possui uma numeração de 5 dígitos, seguida do seu item
(normalmente 1 ou 2 dígitos), seguida de uma atividade, que é atribuída a um colaborador.
A SALT pode originar-se de uma demanda interna ou externa, ela pode ser um
novo item a ser desenvolvido, ou uma item que necessite de manutenção, (seja corretivo,
evolutivo, etc..).
3.6
PONTOS A SEREM ABORDADOS
O método de desenvolvimento para projetos que estão alinhados ao MPS.BR é
extremamente bem definido, contendo todos os principais processos bem mapeados e com
modelos para todos os seus artefatos esperados.
O fluxo que compreende o desenvolvimento do projeto, passa por duas execuções
que são suscetíveis a intervenção de novas metodologias, seriam estas as atividades de:
Realização de testes e Realização de Implementação. A partir daqui, serão estas duas fases
que estaremos contemplando como alvos das técnicas ágeis, não interferindo em seus
18
resultados esperados nem nos artefatos gerados, apenas abordando métodos de
acompanhamento de escopo e gerenciamento de atividades.
Fluxo de execução de desenvolvimento (Arquivo interno da Softplan)
19
4
ESCOLHA E USO DAS FERRAMENTAS
Nesta fase serão apresentadas as ferramentas e técnicas escolhidas para a
implantação do alinhamento das metodologias na empresa escolhida.
4.1
REUNIÃO DE KICK-OFF
A reunião de Kick-off é uma reunião já costumeira da empresa, dando inicio ao
projeto junto a equipe de desenvolvimento. Dependendo do tamanho do sistema,
complexidade ou nível de detalhes abordado na analise de requisitos a atender, a reunião pode
se desdobrar por alguns dias. A reunião com esta equipe é feita assim que todas as clausulas
do projeto já foram aprovadas e o projeto está pronto para ser construído efetivamente. Nesta
reunião são expostos dados do cliente, ramo de negócio, necessidades a ser atendidas e
também é feita uma divisão de responsabilidades.
Desta reunião, podemos identificar alguns pontos necessários para o fluxo do
processo em si, tais como, período da Sprint, definição do “pronto” (estado da solicitação
onde não está sujeita a alterações, situação de pronto para entrega), e também, uma prévia do
que seria o cronograma, seguindo fluxo necessário referente guia MPS.BR de, GPR.
4.2
PLANNING POKER
Seguindo os processos definidos alinhados ao MPS.BR é necessário antes do
inicio das implementações apresentar todo protótipo de telas e um cronograma para o cliente.
E neste ponto devemos ser o mais assertivo possível nas estimativas.
Para efetuar estas estimativas podemos utilizar o planning poker.
Segundo próprio site da técnica em questão, a ideia de utilização do Planning
Poker é simples, são apresentadas estórias individualmente para estimar, e depois de um
20
período de discussão, cada participante escolhe um de seu próprio deck4 a carta numérica que
representa a sua estimativa. Todas as estimativas são privadas até que todos os participantes
escolham suas cartas. Ao mesmo tempo, todos os participantes apresentam suas escolhas e a
discussão poderá ser retomada. (PLANNINGPOKER, 2013).
Existe um deck sugerido pela própria técnica que pode ser comprado em vários
lugares, como o site especializado em consultoria ágil Crisp. (CRISP, 2013).
Deck para Planning Poker Crisp. (CRISP, 2013)
As cartas utilizam uma numeração que não representa exatamente uma variável
temporal, o que dificultaria sua representação em um cronograma a ser apresentado. Neste
Deck temos o número "0" (zero) e "1/2", que podem ser utilizados para atividades com tempo
de execução irrelevantes, estórias já prontas ou pouco relevantes como alguns minutos e
também as cartas de "?" (interrogação) e um xícara onde representam respectivamente estórias
sem definição clara ou não possíveis de serem estimadas e um pedido de descanso. (CRISP,
2013)
4
deck - Baralho ou conjunto de cartas.
21
Para o nosso caso, o ideal seria utilizar números que representem horas reais de
trabalho, para que sua transcrição para um cronograma não fosse dificultada. Sugere-se
utilizar o mínimo de uma hora para as atividades de menor complexidade e até quarenta horas
(uma semana de trabalho completa) para as mais dificultosas. Para implementações com
complexidade superior a isto, recomenda-se uma divisão de atividades, para que se mantenha
um controle mais assertivo e evitar também interrupções durante a execução.
Com isto teremos um deck com as seguintes numerações "1, 2, 4, 8, 16, 24, 32,
40, ?" onde daremos um foco maior em dias trabalhados representados por cartas contendo
numerações incrementais de oito horas. Também se aconselha manter o símbolo de
interrogação para indicar atividades que necessitam de uma melhor explicação.
Sobre o calculo dessas horas existem equipes que recomendam fazer uma media
de todos os votos, outras, recomendam a retirada dos extremos. Aqui trabalharemos com um
meio que leve menos em consideração os extremos, mas ainda assim, utilizando eles como
referencia. O que se sugere, é que dos votos dados em extremos tenham uma validade
diferente dos votos medianos, isto, apenas para estimativas feitas com uma equipe que
contenham três ou mais participantes, para equipes com apenas dois ou até mesmo um
participante, o voto é mais direto, sendo uma media dos votos.
Esta ponderação será feita multiplicando o menor voto por dois e o dividindo o
maior também por dois, mesmo que isto inverta os papeis dos votos, tornando o maior um dos
menores, e o menor um dos maiores.
Para um exemplo diremos que temos quatro votos para uma estória, sendo eles (2,
8, 24, 24). Neste caso temos os extremos (2 e 32). Calculando ponderadamente como
sugerido, temos o seguinte calculo (2 * 2) + 8 + 24 + (32 / 2) / 4 = 12. Logo, a estimativa
desta dada estória seria doze horas de para produção.
Para cálculos que resultem em um número não inteiro, sugere-se considerar o seu
próximo número inteiro. Exemplificando uma estória que tenha os seguintes votos (2, 4, 16),
teríamos o calculo (2 * 2) + 8 + (16 / 2) = 6,66... . Neste caso, considera=se o número 7.
Logo, a estimativa desta estória seria de sete horas de para produção.
22
4.3
REUNIÃO DIÁRIA
A reunião diária terá características já mencionadas conforme guia do SCRUM,
servindo como uma maneira de acompanhamento das atividades executadas para que sejam
tomadas decisões o mais rápido possível caso algo ocorra durante a Sprint.
A reunião será efetuada ao inicio do expediente não devendo demorar mais de
quinze minutos.
4.4
PRODUCT BACKLOG E SPRINT BACKLOG
Serão utilizadas duas ferramentas para acompanhamento e visualização de
backlog: o Kanban e o SAC. O Kanban hoje é utilizado por algumas equipes de
desenvolvimento e testes, porém, seus padrões fogem um pouco da sua função principal de
simplicidade e facilidade de interpretação visual de informações. Já com o SAC, a utilização a
ser sugerida foge do atual uso da ferramenta.
4.5
USO DO SAC
Para geração de relatórios no SAC, existe uma tela de consulta de atendimentos
(imagem 02) onde são aceitos vários filtros, dentre eles: situação, cliente, versão, e
atendimentos (número) e datas de previsão.
23
Tela de consulta de atendimentos (SAC)
24
Apos consultar um atendimento, é aberta outra tela com todas as SALTs e seus
respectivos itens em aberto obedecendo aos filtros informados.
Tela detalhada com SALTs filtradas (SAC)
Neste ponto, podemos esperar que sejam exibidas todas as solicitações pelos
filtros mencionados, podendo ser eles por um período pequeno, (uma semana caracterizando
uma Sprint) ou até mesmo no decorrer de um projeto inteiro (caracterizando um backlog do
projeto).
Sugere-se que se use a data prevista no cadastro da SALT, pelo menos no
momento que ela estiver preparada para ser executada, assim, pode-se gerenciar em um
pequeno espaço de tempo o rumo da solicitação, acompanhar atrasos e tomar medidas a
tempo de reverter uma possível quebra no cronograma.
25
O relatório impresso pelo SAC obedece ao seguinte leiaute (simplificado):
Sigla da Unidade - nome da unidade
Emitido em: data
Relatório de atendimentos
Colaborador: nome do responsável
Cliente: nome do cliente
DADOS DO ATENDIMENTO
Número
: Identificação da SALT
Sistema
: Nome do sistema
Origem
: Interna/externa
Contato
: Colaborador que efetuou registro
Observação
: Dados da solicitação.
Nro. atend.(cliente)
Versão:
DADOS DO ITEM DE ATENDIMENTO
Item
: Identificação do item da SALT
Encerrado em: data
Previsto para
: data
Prioridade: nível
Situação
: Interna/externa
Tipo:
: Desenv./ suporte/ documentação/ analise/etc..
Encerrado por
: Colaborador que encerrou o item
Descrição
: Dados da tarefa do item
Solução
: Solução encontrada
INFORMAÇÕES ADICIONAIS
Horas gastas
: quantidade de horas utilizadas
26
O relatório servirá como artefato gerado ao final da semana e também como
informação a ser repassada para os gestores de projeto. O acompanhamento do mesmo será
semanal.
Constata-se que este relatório é uma ferramenta muito útil para que seja efetuado
resumo da semana, podendo assim, comparar o que estava previsto e o que foi realmente
executado no período esperado.
4.6
KANBAN
4.6.1 Quadro Kanban
O quadro Kanban não está explicitamente sendo referenciado no guia, mas
quando se fala em Scrum, uma das primeiras imagens que vem a mente é a de um quadro
cheio de post-its5 coloridos.
Isto se dá pela facilidade de visualização e acompanhamento do projeto
proporcionado por esta ferramenta. É nela que ficam todas as "estórias" e/ou demandas
gerenciadas no decorrer do projeto.
O quadro Kanban caiu como uma luva para o Scrum porque garante a transparência
e a inspeção, dois dos pilares que suportam o framework. A transparência é
garantida no momento em que todos os comprometidos com o projeto podem
acompanhar, a qualquer momento, como está o desenvolvimento de cada história, os
problemas encontrados nelas. A inspeção é possível na interpretação do mesmo:
muitos post-its representando impedimentos podem indicar problemas, assim como
uma tarefa que está há muito tempo sendo feita. A interpretação do quadro pode
levar a diagnosticar problemas complexos muito facilmente, de forma visual e
intuitiva. (MADUREIRA, 2012)
O Kanban possui raias que seriam caminhos que uma solicitação pode passar. Ela
vai resumidamente de "a fazer" para "fazendo" e posteriormente "feito".
No caso atual da empresa, quadro já é utilizado porem com uma raia para cada
projeto, necessitando assim da criação de mais uma raia para atender a atividade de testes,
conforme processo de execução presente no modelo atual da empresa (realização de
5
post-it - Adesivos de papel utilizados para anotações.
27
implementação e realização de testes). Como são equipes diferentes, cada um será
responsável por manter atualizadas as situações de cada uma das suas tarefas.
Exemplo de Kanban (Caelun, 2013)
28
4.6.2 Avatar
Avatares são personagens, figuras ou qualquer tipo de imagem que seja associada
a uma das pessoas que possam interagir com as atividades dispostas no quadro kanban.
O avatar pode ser simplesmente substituído pelo nome da pessoa caso a mesma
não queira ser associar a nenhuma imagem, e seu uso indica exatamente o que esta pessoa esta
fazendo em um determinado momento.
4.6.3 Post-It
Uma definição simplificada do post-it seria a representação física da atividade
cadastrada no SAC para ser manipulada no Kanban.
No caso do post-it, existe também um modelo de padrão proposto para sua
utilização dentro da empresa, onde o mesmo foi pensado para que grande parte das
informações sobre a atividade ficasse a mostra nele. Com isto, sua complexidade aumentou
consideravelmente, perdendo um pouco do seu propósito em se tratando de uma ferramenta
ágil.
Segue exemplo disponibilizado nos arquivos da Softplan.
29
Modelo padrão de post-it (Arquivo interno Softplan)
Sugere-se neste ponto que haja uma considerável simplificação deste objeto,
deixando a parte gerencial para o SAC. O objetivo do Kamban neste momento é manter a
situação do projeto sempre disponível e dinamizar as atualizações das mesmas no decorrer do
tempo.
30
SALT - 12341 / 12
SALT - 42457 / 6
Corrigir cálculo de
folha de
pagamento.
Criar tela de
cadastro de cliente.
Modelos propostos de utilização de Post-it
É fato que no decorrer do projeto, uma atividade possa ser dividida em duas ou
mais frações, fazendo com que um post-it não seria suficiente, neste caso, para que não se
perca a rastreabilidade com a SALT original, pede-se que seja posto abaixo da descrição da
atividade, seja inserido também um contador de fragmentos com o seu número sequencial
pelo total divisório da SALT. Ex.: 2/4. Seria a segunda atividade de um total de quatro.
SALT - 43579 / 2
SALT - 31245 / 9
Cadastro de autos
de infração.
Correção do
calculo de valor de
multa.
2/3
1/2
Modelos propostos de utilização de Post-it (derivados)
Para utilização do post-it, o desenvolvedor ou testador da atividade ficará
responsável pela sua migração de coluna para outra no Kanban.
4.6.4 Gráfico de Burndown
Segundo Lima (2012) "O Burndown chart ou gráfico de Burndown é o gráfico
utilizado pelas equipes Scrum para representar diariamente o progresso do trabalho em
desenvolvimento.".
Este gráfico tem como métricas a quantidade de horas totais para finalização das
atividades da sprint, e o tempo total para finalização da mesma.
31
A quantidade total de horas é obtida através da soma das horas disponíveis de
todos os membros da equipe durante uma semana. Para atualização do gráfico, diariamente
durante a reunião diária, cada desenvolvedor deve dizer se finalizou sua(s) atividade(s) do dia
anterior ou, se não, a porcentagem que falta para finalização da atividade. Com essas
informações, serão indicadas no gráfico as horas já gastas, que poderá ser comparadas a uma
linha guia "ideal" de tempo para execução da sprint. Esta linha delimita visivelmente a
informação de atraso ou adiantamento da finalização da sprint. No exemplo abaixo, a cada
vez que a linha azul fica acima da linha vermelha pontilhada a execução está em atraso, já
quando a linha passa para parte inferior a linha vermelha, a equipe está adiantada em suas
execuções.
Burndown chart (LIMA, 2012)
32
5
CONCLUSÕES
Conclui-se com este que mesmo que em se tratando de uma metodologia de
processos rígidos e de uma comunicação expressamente formal com todos os participantes do
processo como é o MPS.BR, é possível sim um alinhamento com praticas e técnicas ágeis
como o SCRUM, que é altamente flexível e focado em desempenho, tendo como suas
características a facilidade de comunicação, visualização de resultados e alto desempenho da
equipe de desenvolvimento.
Garante-se por meio deste, que nenhum dos artefatos exigidos pelos processos
mapeados e alinhados ao MPS.BR seja alterado ou desconsiderado, sendo que todos os
processos sugeridos direcionam-se totalmente a linha de execução do projeto tornando o
processo mais visível gerencialmente, melhorando o desempenho com um constante
acompanhamento das métricas de produção.
33
6
SUGESTÕES PARA TRABALHOS FUTUROS
• Implantação de técnicas ágeis em equipes fora da metodologia MPS.BR;
• Alinhamento de artefatos resultantes de processos ágeis como documentos conclusivos
ao alinhamento de metodologias de qualidade como o MPS.BR;
• Implantação do modelo sugerido em locais fora da empresa foco do trabalho;
• Pesquisa de satisfação pós-implantação do modelo sugerido.
34
7
REFERÊNCIAS
CRISP. Planning Poker®: Buy Planning Poker® decks. Disponível
<http://www.crisp.se/bocker-och-produkter/planning-poker> Acesos em: 12 jan. 2013.
em:
CRUZ, Fábio Rodrigues. SABBAGH, Rafael. Um guia definitivo para o Scrum: As regras
do jogo, 2011. Disponível em: <http://www.scrum.org>. Acesso em: 11 ago. 2012.
INFORMABR. NBR ISO. Disponível em <http://www.informabr.com.br/nbr.htm>.
Publicado em: set. 2002. Acesso em: 03 jan. 2013.
LIMA, Ester. Burndown chart: Mede o progresso da sprint e dá indicativos do processo de
trabalho da equipe. Publicado em: 9 jan. 2012. Acesso em 24 jan. 2013.
MADUREIRA, Felipe. O quadro de tarefas no Scrum. Blog Scrum Half, Publicado em jan.
2012. Disponível em: <http://blog.myscrumhalf.com/2012/01/o-quadro-de-tarefas-noscrum/>. Acesso em: 02 jan. 2013.
PLANNINGPOKER. Play. Estimate. Plan.: How does Planning Poker® work?. Disponível
em <http://www.planningpoker.com/>. Acesso em 05 jan. 2013.
RENAPI. Rede de Pesquisa e Inovação em Tecnologias Digitais. MPS.BR: Níveis de
Maturidade
do
MPS.Br.
Disponível
em:
<http://www.renapi.gov.br/qualidade/metodologia/copy_of_finalidade>
SHWABER, Ken, FILHO, Heitor Roriz. et al. Guia do Scrum. Disponível em:
<http://www.scrum.org>. Acesso em: 11 ago. 2012.
SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro: Guia de
Implementação - Parte 1: Fundamentação para Implementação do Nível G do MR-MPS.
Disponível em: <http://www.softex.br/mpsbr/>. Acesso em: 13 ago. 2012.
SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro: Guia Geral. Disponível
em: < http://www.softex.br/mpsbr/>. Acesso em: 23 jul. 2012.
SOFTPLAN/POLIGRAPH.
Institucional.
Disponível
em:
<http://www.softplan.com.br/empresa.jsf >. Publicado em 2011. Acesso em: 02 jan. 2013.
35