Requisitos para uma equipe ágil

magazine
engenharia
de software
Edição 44 - Ano 04
Modelos de processo pessoal
http://www.devmedia.com.br/post-23264-Modelos-de-processo-pessoal.html
Desenvolvimento
Desenvolvimento de aplicações de
realidade aumentada
Processo
Uma visão geral
do CMMI
Requisitos
Gerenciando mudanças
a partir de requisitos
Agilidade
Requisitos para
alcançar agilidade
Processo
Conheça os modelos
de processo pessoal
Desenvolvimento
Conheça técnicas para manter
seu código“limpo”– Parte 6
Agilidade
Scrum e o gerenciamento
de projetos - Parte 3
Aprimore suas estimativas de tamanho de projeto

Corpo Editorial
Editor
Rodrigo Oliveira Spínola
Colaboradores
Marco Antônio Pereira Araújo
Eduardo Oliveira Spínola
Jornalista Responsável
Kaline Dolabella - JP24185
Na Web
www.devmedia.com.br/central
(21) 3382-5038
Ano 4 - 44ª Edição - 2012
N
a fase inicial de um projeto,a necessidade em obter o custo,prazo e o
esforço é observado em todas as empresas,pois as mesmas precisam
gerar um orçamento para os seus clientes e avaliar uma série de
projeções.
Inicialmente não se tem conhecimento de todas as características do produto
bem como da sua real dimensão,por esse motivo é necessário utilizar técnicas
de extração de requisitos para realizar um levantamento inicial dos mesmos e
compreender melhor o problema. Os requisitos são condições, características
ou capacidades necessárias para atingir uma finalidade, categorizados na
implementação de sistemas em funcionais e não funcionais como forma de
estabelecer critérios de qualidade.
Uma vez definidos os requisitos,pode-se então avaliar o tamanho do sistema
em termos de suas funcionalidades. Existem vários métodos de estimativa, a
APF (Análise de Ponto de Função) é uma delas. Esse método não tem como
objetivo realizar estimativas de prazo, custo e esforço para implementação
de sistema, mas sim avaliar o tamanho de um sistema em termos de suas
funcionalidades. Resulta desta avaliação o tamanho funcional do sistema
expresso em Pontos de Função (unidade de medida do método). A partir do
tamanho funcional, podem ser derivadas estimativas adicionais, como tempo
e custo.
Neste contexto, esta edição da Engenharia de Software Magazine destaca
como tema de capa Análise de Ponto de Função. Para isto, trazemos um artigo
cujo objetivo é apresentar de forma simples, por meio de exemplos, o uso de
um método poderoso para a solução destes problemas recorrentes, a APF
(Análise de Ponto de Função).
Além deste artigo, teremos mais sete nesta edição:
• Requisitos para agilidade no desenvolvimento de software
• Scrum e o gerenciamento de projetos – Parte 3
• Modelos de processo pessoal
• CMMI – Uma visão Geral
• Gerenciando mudanças a partir de requisitos
• Introdução ao desenvolvimento de aplicações de realidade aumentada
• Boas práticas para escrita de métodos, funções e procedimentos – Parte 6
Equipe Editorial Engenharia de Software Magazine
RodrigoOliveiraSpínola
rodrigo.devmedia@gmail.com
Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ).Mestre em Engenharia de
Software (COPPE/UFRJ,2004).Bacharel em Ciências da Computação (UNIFACS,2001).Colaborador
da Kali Software (www.kalisoftware.com),tendo ministrado cursos na área de Qualidade de Pro-
dutos e Processos de Software,Requisitos e Desenvolvimento Orientado a Objetos.Consultor para
implementaçãodoMPS.BR.AtuacomoGerentedeProjetoeAnalistadeRequisitosemprojetosde
consultorianaCOPPE/UFRJ.ÉColaboradordaEngenhariadeSoftwareMagazine.
MarcoAntônioPereiraAraújo
maraujo@devmedia.com.br
DoutoreMestreemEngenhariadeSistemaseComputaçãopelaCOPPE/UFRJ-LinhadePesquisa
emEngenhariadeSoftware,EspecialistaemMétodosEstatísticosComputacionaiseBacharelem
MatemáticacomHabilitaçãoemInformáticapelaUFJF,ProfessoreCoordenadordocursodeBa-
chareladoemSistemasdeInformaçãodoCentrodeEnsinoSuperiordeJuizdeFora,Professordo
cursodeBachareladoemSistemasdeInformaçãodaFaculdadeMetodistaGranbery,Professor e
DiretordoCursoSuperiordeTecnologiaemAnáliseeDesenvolvimentodeSistemasdaFundação
Educacional D.André Arcoverde,Analista de Sistemas da Prefeitura de Juiz de Fora,Colaborador
daEngenhariadeSoftwareMagazine.
EduardoOliveiraSpínola
eduspinola@gmail.com
ÉColaboradordasrevistasEngenhariadeSoftwareMagazine,JavaMagazineeSQLMagazine.Éba-
charelemCiênciasdaComputaçãopelaUniversidadeSalvador(UNIFACS)ondeatualmentecursao
mestradoemSistemaseComputaçãonalinhadeEngenhariadeSoftware,sendomembrodoGESA
(GrupodeEngenhariadeSoftwareeAplicações).
Atendimento ao Leitor
ADevMediacontacomumdepartamentoexclusivoparaoatendimentoaoleitor.Se
você tiver algum problema no recebimento do seu exemplar ou precisar de algum
esclarecimento sobre assinaturas, exemplares anteriores, endereço de bancas de
jornal,entre outros,entre em contato com:
www.devmedia.com.br/mancad
(21) 2220-5338
Publicidade
Para informações sobre veiculação de anúncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br
Fale com o Editor!
É muito importante para a equipe saber o que você está achando da revista:que tipo de artigo você
gostaria de ler,que artigo você mais gostou e qual artigo você menos gostou.Fique a vontade para
entrar em contato com os editores e dar a sua sugestão!
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores,informando o título e mini-resumo do tema que você gostaria
de publicar.
EDITORIAL
Apoio

ÍNDICE
Agilidade
06 - Requisitos para agilidade no desenvolvimento de software
FlavioS.Mariotti
13- Scrumeogerenciamentodeprojetos–Parte3
FábioCruz
Engenharia Aplicada
20 - Estimativasdetamanhoemprojetosdesoftwareutilizandopontosdefunção
JhoneydaSilvaLopeseJoséLuisBraga
Engenharia Fundamentos
32 - CMMI–UmavisãoGeral
LenildoMorais
36 - Gerenciandomudançasapartirderequisitos
JoséAlbertoZimermann,ThiagoCarvalhodeSousaeRodrigoOliveiraSpínola
Arquitetura e Desenvolvimento
42 - Introduçãoaodesenvolvimentodeaplicaçõesderealidadeaumentada
AndréLuisTosato,VictorAngeloMarcorin,ThiagoSalhabAlvesePauloBarretodaSilva
47 - Boaspráticasparaescritademétodos,funçõeseprocedimentos–Parte6
JacimarFernandesTavareseMarcoAntônioPereiraAraújo

Edição 05 - Engenharia de Software Magazine 5

6 Engenharia de Software Magazine- Requisitos para agilidade no desenvolvimento de software
Flavio S.Mariotti
flaviomariotti@gmail.com
Especialista em Engenharia e Arquitetura
de Software. Pós Graduado pelo Instituto
de Pesquisa Avançada de Tecnologia IBTA
em Engenharia de Software baseado em
SOA.Bacharel em Sistemas de Informação
pela UNIUBE e técnico em Processamento
deDadospelaFEB.Consultorindependente
no desenvolvimento de software em
arquitetura OO,SOA,GIS e Plataforma .NET.
Dequesetrataoartigo?
Este artigo apresenta uma proposta sobre níveis
de requisitos ágeis, práticas correspondentes aos
papéis sugeridos e um modelo organizacional que
proporciona um formato de empresa ágil. O objetivo
éescreverosrequisitosquesefazemnecessáriospara
acriaçãodeumaequipeágil,programasqueofereçam
suporte ao primeiro nível e a fase e maturidade da
empresaágil.
Emquesituaçãootemaéútil?
Naúltimadécada,acriaçãodemodelosdeengenharia
de software cada vez mais ágeis foi a mudança mais
significativa que afetou as empresas de software
desdeoadventodomodeloemcascatanadécadade
1970.Nosúltimoscincosanos,asmetodologiaságeis
começaramaseespalharnasempresasdesoftware.
As iniciativas geralmente começaram com equipes
individuais, com a adoção de alguns métodos como
XP, Scrum, Lean entre outros. No entanto, esses
métodos começaram a se espalhar para o nível das
empresaseumasériedefatorescomeçaramaexigir
umescopoorganizacionalmaisamploparasuportar
os desafios da governança desses novos processos.
Neste sentido, o objetivo do artigo é fornecer um
modelo que ajude a obter uma visão elevada do
conceito ágil e seus requisitos para maturidade de
umaempresaágil.
ResumoDevMan
Esteartigodiscuteotemarequisitosparaagilidade
no desenvolvimento de software. Para isso, será
apresentado, sob diferentes perspectivas, como
a questão da agilidade pode ser considerada em
equipes de projetos de software que trabalhem
considerando os princípios da agilidade.
Requisitos para agilidade no
desenvolvimento de software
Necessidades requeridas para equipe,programas e empresa
O
desenvolvimento de software
se tornou um dos fatores mais
importantes da tecnologia.
O software que é produzido hoje se tor-
na rapidamente um item fundamental
para organizações e usuários finais no
intuito de acelerar e auxiliar a execução
de diferentes tarefas.
Nos últimos 50 anos diferentes grupos,
especialistas e pesquisadores da área de
TI, vêm disponibilizando diversas meto-
dologias para apoiar essa difícil tarefa de
desenvolvimento de software, tais como:
modelo cascata, espiral, RAD, RUP,
Crystal, Scrum (ler Nota Devman 1),
XP (ler Nota Devman 2), FDD (ler Nota
Devman 3), Lean, DSDM entre outros.
Com a evolução rápida dos recursos
computacionais, o escopo do software se
altera com a mesma velocidade, exigindo
Agilidade
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

agilidade
Nota do DevMan 1
Scrum: Scrum é um framework para gerenciamento de projetos ágeis muito
utilizado na área de desenvolvimento de software.Uma das principais características
do Scrum é permitir o desenvolvimento de produtos complexos de uma forma
incremental e iterativa, contribuindo para decompor um grande produto complexo,
em pequenos subprodutos mais simples, mais rápidos e mais fáceis de serem
desenvolvidos e entregues.No Scrum estas iterações são chamadas de Sprints,e uma
característica marcante de sua estrutura e aplicação é o controle sobre os trabalhos
realizados,eapossibilidadede correção e adaptação rápida,permitindo queaequipe
altere sua forma de agir ou de pensar o mais breve possível,evitando que problemas
ou erros causem danos maiores ao projeto.
Nota do DevMan 2
XP: O eXtreme Programming ou XP é um modelo ágil de desenvolvimento de
software criado em 1996 por Kent Bech no Departamento de Computação da
montadora de carros Daimler Chrysler. Ele possui muitas diferenças em relação
a outros modelos, podendo ser aplicado a projetos de alto risco e com requisitos
dinâmicos (vagos ou em constante mudança), conduzidos por equipes de tamanho
médio e pequeno.
Como todo método ágil,o XP procura responder com velocidade às mudanças nas
especificações do projeto, com base em princípios, valores e práticas bem definidos.
Este método enfatiza o desenvolvimento rápido garantindo a satisfação do cliente
e cumprindo as estimativas do projeto. O XP baseia-se em cinco valores para guiar
o desenvolvimento: Comunicação, Coragem, Feedback, Respeito e Simplicidade.
Segundo Beck,o método oferece ainda 12 práticas,a saber:i) Jogo do planejamento;
ii) Versões pequenas; iii) Metáfora; iv) Projeto simples; v) Teste; vi) Refatoração; vii)
Programação em pares;viii) Propriedade coletiva do código;ix) Integração contínua;
x) 40 horas de trabalho semanal;xi) Cliente presente;e xii) Padrões de codificação.
Nota do DevMan 3
FDD:O FDD é uma metodologia que serve tanto para o gerenciamento de projetos
quantoparaaEngenhariadeSoftware.Istoatornamaiscomplexaquandocomparada
comoutrasmetodologiaságeis.Porexemplo,oRUP(RationalUnifiedProcess)daIBM,
uma metodologia considerada tradicional, trata o gerenciamento de projetos como
uma disciplina dentro do seu framework, já que o seu foco está na Engenharia de
Software em si.Já o SCRUM,tem no papel do Scrum Master,uma figura parecida com
adeumGerentedeProjetosformal,masquetemseufoconafacilitaçãodostrabalhos
por parte da equipe técnica.O foco dessa metodologia está na auto-organização da
equipe e,para isso,são necessários analistas seniores.
OpontofortedametodologiaFDDestánacapacidadederealizarfeatures.Paraesta
metodologia,uma pequena feature possui um alto valor para o cliente.O exemplo de
uma feature está em um caso de uso com a função de“calcular a média de salário dos
gestores”, ou de“realizar um relatório integrado de vendas”e assim por diante.Veja
que não é estranha a menção do termo“caso de uso”para exemplificar uma feature,
já que a ideia é similar.Essa descrição do requisito que o FDD chama de feature são
os casos de uso no RUP e as estórias utilizadas no XP. O site www.agilemodeling.
com/essays/fdd.htm destaca que uma lista de features é inicialmente indicada para
que seja elaborado o planejamento do projeto com estimativas de esforço para sua
execução.Basicamente,esta é a proposta do FDD.
como um dos principais itens do desenvolvimento de software
a agilidade na produção. Porém, como criar produtos com me-
nos tempo e com a mesma eficiência? São dúvidas como essas
que vem transformando nossas metodologias na tentativa de
alcançar o melhor e mais ágil modelo de desenvolvimento de
software.
Contudo, será que somente uma boa metodologia é o sufi-
ciente para apoiar essa difícil missão? A resposta certamente é
NÃO. Para se obter agilidade no processo de desenvolvimento
de software é preciso aplicar o conceito nos três pilares que
fazem parte deste trabalho, que são: equipe, programas e em-
presa. Esse é o principal objetivo deste artigo, proporcionar
ao leitor uma breve abordagem do que se faz necessário para
atingir a agilidade no desenvolvimento de software, quais os
requisitos para criar um time ágil, quais os pilares e processos
que envolvem esse trabalho, qual o papel da empresa para dar
suporte aos processos, como distribuir a responsabilidade
de cada envolvido no processo e qual a importância dessa
distribuição.
Requisitos ágeis para a equipe
É importante ressaltar que o modelo de equipe que será
apresentado neste artigo tem como principal propósito au-
xiliar o time de desenvolvimento a se organizar ao definir
papéis, distribuir responsabilidades e criar as atividades para
um projeto no modelo ágil. Sendo assim, é de total valia usar
esses conceitos para modelar e adequar a sua equipe na sua
realidade.
Sabemos que um dos grandes desafios é fazer com que a
equipe incorpore o modelo ágil para contribuir ao máximo
com o time. Recomendo aos interessados pela teoria da lide-
rança de pessoas dar uma no lida modelo Tuckman’s stages of
group development proposto pelo psicólogo americano Bruce
Wayne Tuckman.
Funções e responsabilidades da equipe
Ao estudar e analisar diversos modelos organizacionais de
uma equipe ágil proposta em diferentes metodologias como
XP, Scrum, Lean, entre outros, chega-se à conclusão de que a
estrutura organizacional de uma equipe ágil é basicamente a
mesma em todas metodologias.
O Scrum, por exemplo, propõe um modelo que se divide em
três principais funções, são eles: Scrum Master (Responsável
Ágil), Product Owner (Proprietário do Produto) e o resto da

equipe que consiste principalmente de desenvolvedores e
testadores de software.
Composição da equipe ágil
A Figura 1 representa de forma gráfica o modelo organiza-
cional de uma equipe ágil. Na sequência conheremos cada
um desses papéis.
Figura 1.Ilustração do nível de equipes
Proprietário do produto
Como já definido no Scrum, o proprietário do produto tem
como característica atuar como a única função arbitrária, ou
seja, esse papel é responsável por determinar e priorizar as
necessidades dos utilizadores e gerenciar os itens acumulados
(product backlog). É importante lembrar que esse artigo não
descreve Scrum como metodologia a ser seguida. Indepen-
dente da metodologia que sua equipe adotou como ágil, é
recomendada a aplicação da função proprietário do produto,
já que esse papel vem mostrando verdadeiros avanços na
simplificação do trabalho exercido pela equipe.
Contudo, as responsabilidades do proprietário do produ-
to são ainda maiores. Segundo o princípio Agile Manisfesto
#4 - “Homens de negócio e desenvolvedores devem trabalharem
juntos diariamente durante o andamento do projeto”. Com base
nesse princípio, o proprietário do produto é a função ideal
para orientar a equipe e participar diariamente com a mesma
em suas atividades no intuito de direcionar e definir suas
prioridades.
Podemos dizer então que o proprietário do produto é o prin-
cipal responsável pela definição e priorização de requisitos.
Portanto, a função proprietário do produto é responsável pelas
seguintes atribuições:
• Trabalhar com todos stakeholders (gerentes, analistas, clientes
e interessados) do projeto para determinar os requisitos;
• Priorizar as atividades com base no valor relativo do
cliente;
• Definir motivos para iteração, atuar e elaborar relatórios,
participar e revisar processos buscando melhoria contínua.
Responsável Ágil
O responsável ágil é geralmente o papel do líder do projeto.
Essa função tem como responsabilidade dirigir o time para
alcançar suas metas e, em alguns projetos, é importante so-
mente na fase de transição. Quando o modelo ágil é imposto
na equipe e se torna a metodologia do time, as regras são
auto-impostas, fazendo com que a participação do Responsável
Ágil se torne menos frequente e necessária. Resumidamente,
as responsabilidades desta função se dividem em:
• Facilitar o progresso da equipe em direção à meta;
• Liderar os esforços da equipe e buscar a melhoria
contínua;
• Fazer cumprir as regras do processo ágil;
• Eliminar obstáculos.
Desenvolvedores eTestadores
A equipe se completa com os desenvolvedores e testadores.
Geralmente o tamanho de uma equipe ágil é limitada entre
4 até 6 desenvolvedores e de 1 até 3 testadores, idealmente
trabalhando juntos.
Desenvolvedores
O modelo de trabalho aplicável aos desenvolvedores pode ser
o modelo de programação em par com outro desenvolvedor,
ou também emparelhado com um testador ou outro modelo
ágil, de forma a operar mais independente e ter interfaces com
múltiplos testadores e desenvolvedores. Contudo, a responsa-
bilidade desta função é basicamente a mesma, são elas:
• Codificar os requisitos;
• Colaborar com os testadores e proprietários do produto
garantindo a codificação do produto de forma padronizada
conforme definição da equipe;
• Codificar e executar as unit test;
• Garantir o check-in e check-out do código feito diariamente;
• Participar ativamente na melhoria do ambiente de
desenvolvimento.
Testadores
Os testadores são parte fundamental e integrante da equipe
ágil. Os testadores estarão presentes logo no primeiro código a
ser liberado, e se faz necessário passar pela aplicação de testes
e aprovação do time de testadores. A principal responsabilida-
de atribuída a essa função é a liberação do código fonte para
produção ou continuidade do fluxo de trabalho. É de extrema
importância o cumprimento desse requisito para se obter
qualidade e agilidade no desenvolvimento de software. Outras
responsabilidades atribuídas a essa função são:
• Criar casos de testes e aprovação;
• Interface com os desenvolvedores e proprietário do produto
para garantir e certificar o entendimento das funcionalidades
requeridas;
• Executar os testes de aprovação;
• Desenvolver teste de aprovação para a atualização de com-
ponentes no ambiente de produção.
Especialistas
Não podemos deixar de ressaltar a importância de recursos
compartilhados e interfaces para outras funções. Segundo o
princípio Agile Manifesto #11 - “As melhores arquiteturas, requisitos e
projetosemergentesdeequipeauto-organizadas.”. Assimsendo,sefaz

agilidade
necessárioestabelecerumtrabalhocolaborativocomespecialista
que, não necessariamente fazem parte da equipe, porém contri-
buem com seus conhecimentos. Alguns desses papéis são:
• Arquitetos de software;
• Especialistas de qualidades QA;
• Especialistas de infraestrutura;
• Administradores de bancos de dados;
• Especialistas em gerenciamento de configuração;
• Especialistas de implantação.
Conceito ágil
Sabendo que o intuito de desenvolver software com agilidade
não exclui a principal necessidade de criar aplicativos eficien-
tes que agregue valor ao cliente, precisamos assegurar que
as equipes ágeis estejam aplicando modelos simples, porém
abrangendo todos os requisitos possíveis. Uma vez escutei uma
frase que dizia: “O difícil é fazer o simples, o complexo todo mundo
faz”. Resumindo, o significado dessa frase é: neste momento
precisamos garantir que a equipe não esteja sendo sobrecar-
regada com requisitos desnecessários que não agregam valor
ao cliente e não geram resultado para a equipe.
Histórias de usuários
Essa função é originada do modelo XP. Histórias de usuá-
rios (User Stories) vem com a proposta de substituir o famoso
requisitos de software. Este item ágil atualmente faz parte
dos modelos Scrum, XP e na maioria das outras metodologias
ágeis. A responsabilidade e definição desse usuário se resume
em: “Uma breve descrição dos principais objetivos que levam as
necessidades dos clientes através de fluxo de valor”.
Ao contrário de requisitos que definem o que o sistema “deve”
fazer na maioria das vezes como obrigação contratual, histórias
de usuários são breves declarações de usuários expressando
suas intenções que descrevem um recurso que o sistema “pre-
cisa” fazer para alguns usuários ou departamento.
A principal proposta dessa função é transmitir à equipe de
desenvolvimento o que realmente traz benefícios ao usuário
agregando valor ao produto, ensinando a equipe a se concen-
trar no que realmente agrega valor ao negócio do usuário.
Backlog
A última função que integra uma equipe ágil é o backlog.
O produto backlog consiste em acumular todos os recursos
necessários a serem implementados, identificados pela equipe
ágil com base em todas as histórias de usuários.
A responsabilidade dessa função é acumular os itens a serem
desenvolvidos com base nas histórias dos usuários. Embora
existam diversas tarefas a serem executas como: itens de confi-
guração, requisitos de infraestrutura, entre outras atividades,
o principal objetivo do backlog é concentrar a atenção da equipe
nas histórias de usuário.
Requisitos ágeis para o programa
No nível de equipe, foi introduzido um conceito que aborda
a criação de equipes de software preparadas para definir,
desenvolver e testar o software. Neste nível as equipes são
capacitadas e trabalham a partir de um backlog local que está
sob o gerenciamento do proprietário do produto. O proprie-
tário do produto tem o controle para definir, construir e testar
seus componentes fase a fase. Com base nos princípios do Agile
Manifesto, esse é o mecanismo ideal para incentivar e motivar
a equipe para produzir os resultados positivos.
No nível de programa, será apresentado um processo orga-
nizacional e modelo de requisitos que fornece mecanismos
para aproveitar os recursos que integram as equipes ágeis
para um propósito maior, ou seja, a entrega de um sistema ou
um conjunto de aplicativos para os clientes. Neste momento
os problemas são outros e a empresa irá enfrentar diferentes
desafios para executar com sucesso o conceito de agilidade.
Resumidamente, as metas neste nível são:
• Roadmap: definir e comunicar a visão do programa e manter
um roteiro;
• Gerenciamento de liberação: Coordenar as atividades das equi-
pes para definir critérios de liberação;
• Gestão da qualidade: Assegurar a qualidade do sistema, desem-
penho, segurança, e quaisquer normas impostas anteriormente
devem ser atendidas;
• Implantação: A definição de critérios para implantação deve
ser gerida no nível de programa;
• Gestão de recursos: Ajustamento dos recursos conforme
necessário para enfrentar as limitações e dificuldades na
capacidade do programa para entregar o valor necessário em
tempo hábil;
• Eliminação de obstáculos: Os líderes e gestores de progra-
mas são responsáveis por eliminar bloqueios que atrasem a
equipe.
Equipes recursos e equipes componentes
Nesta parte do artigo será apresentado como funcionam as
equipes de recursos e componentes. Vamos fazer uma com-
binação e comparação para demonstrar os resultados organi-
zacionais à equipe de organização. Em minha opinião, essa é
uma das decisões mais difíceis para serem tomadas. Perceber
a necessidade e decidir a inclusão de uma dessas duas equipes
para agilidade do projeto requer muito cuidado.
Equipes recursos
Uma equipe de recursos ou em inglês Feature Team, é basi-
camente um time com diferentes habilidades, ou seja, uma
equipe composta com profissionais de diversas competências
para desenvolver um recurso de ponta a ponta.
Para ilustrar a diferença entre equipes de recursos e equipes
de componentes, vamos imaginar um cenário típico nos proje-
tos corporativos. Em uma arquitetura como a apresentada na
Figura 2 em que as equipes se organizam em torno de camadas,
teríamos neste momento seis equipes, sendo uma para cada
camada. O modelo organizacional por equipes de componentes
dirige o time para uma variedade de problemas como:
• Nível de comunicação reduzida em todas as camadas;
• Trabalha com o sentimento de que o projeto apresentado no

• contrato é o suficiente;
• Finaliza o desenvolvimento da camada sem um produto
potencialmente utilizável.
Figura 2.Ilustração de arquitetura de projeto
A proposta da equipe de recursos seria, em vez de ter equipes
separadas por camadas da arquitetura, termos as equipes de
recursos trabalhando em todas as camadas.
Algumas vantagens podem ser obtidas neste modelo orga-
nizacional, são elas:
• As equipes de recursos têm mais habilidades para avaliar
o impacto das decisões de projetos. Essa habilidade é adquira
pelo fato do time construir a funcionalidade de ponta a ponta,
isso maximiza o aprendizado dos membros auxiliando nas
decisões que se fazem necessárias para o projeto;
• Reduz o desperdício de esforços da equipe, ou seja, o risco de
criar funcionalidade demasiada é consideravelmente menor;
• Garante que as pessoas certas estão falando, ou seja, uma
equipe de recursos inclui todas as habilidades necessárias para
ir da idéia a execução do recurso;
• Diminui o risco de integração do componente com os re-
cursos, ou seja, um componente desenvolvido pela equipe
de componente só tem valor depois de integrado ao produto
da equipe de recursos, sendo assim, o esforço para integrar
o trabalho da equipe de componente ao produto precisa ser
calculado.
O especialista em projetos ágeis, Mike Cohn, publicou um
artigo em seu blog apresentando alguns benefícios obtidos
com a equipe de recursos que pode ser encontrado no ende-
reço http://blog.mountaingoatsoftware.com/the-benefits-of-
feature-teams.
Equipes componentes
Embora seja fortemente recomendado o uso de equipes de
recursos, existem situações em que a equipe de componentes
é apropriada. Como seu próprio nome, uma equipe de compo-
nente é aquela que desenvolve um software para ser entregue
a uma outra equipe do projeto, em vez de diretamente ao
cliente. Um exemplo seria uma equipe de componente desen-
volvendo uma camada de mapeamento entre a aplicação e o
banco de dados.
O gerenciamento de equipe de componentes nem sempre
é uma tarefa fácil. Geralmente as equipes de componentes
trabalham paralelas às equipes de recursos. É importante
garantir que a equipe de componentes tenha conhecimento
das necessidades da equipe de recursos. No caso do Scrum, o
proprietário do produto irá auxiliar a equipe de componente
priorizando as necessidades de seu produto, porém quando
a equipe de componentes está a frente da equipe de recursos,
é preciso, na maioria das vezes, adivinhar quais serão as
necessidades seguintes. Muitas vezes isso resulta em com-
ponentes ou estruturas que não são utilizáveis pelas equipes
de recursos. Esse é um claro exemplo do que chamamos de
esforços desperdiçados.
Qual é o melhor cenário?
Embora não exista uma regra para auxiliar a tomada de
decisão, é necessário compreender a fundo as vantagens e
desvantagens das equipes descritas acima para uma escolha
apropriada.
Nas grandes empresas, onde há diversas equipes, recursos
e sistemas que em algumas vezes são compostos por siste-
mas ou componentes, o modelo de equipes provavelmente
será uma mistura entre equipes de recursos e equipes de
componentes.
É recomendado uma certa inclinação para as equipes de re-
cursos. Alguns especialistas acreditam que uma boa estratégia
para empresa ágil é permanecer no 70%-30% ou 80%-20% de
equipes de recursos para equipes de componentes. O espe-
cialista em projetos ágeis, Chad Holdor, ou como ele gosta de
ser chamado, o Agile Ninja, publicou um vídeo em seu blog
detalhando claramente as diferenças entre equipes de recursos
e equipes de componentes e no final recomenda um modelo
ágil combinando membros da equipe de componentes para
fazer a equipe ágil como ilustrado na Figura 3. Esse vídeo pode
ser encontrado no endereço: http://www.scaledagiledelivery.
com/2011/04/28/component-vs-feature-team/.
Figura 3.Combinando membros da equipe de componentes para fazer a
equipe de recursos
A equipe de sistemas
Como visto, as equipes ágeis são os motores de produção
de um software. Aprendemos que cada equipe precisa ter
habilidades necessárias para especificar, projetar, codificar e
testar os componentes e recursos de seu domínio.

agilidade
No entanto, no nível de programa, essas equipes formadas
por pessoas podem não ter todas as características necessárias
para concluir uma solução completa. Com isso, às vezes se faz
necessário adicionar uma equipe que complemente as equipes
de recurso ou componentes. Essas equipes são formadas de
sistemas que podem auxiliar nos testes de sistemas, sistema
de garantia da qualidade, sistema de integração, suporte na
infraestrutura de desenvolvimento e etc.
Equipe de gerenciamento e liberação
Nas melhores práticas que procedem uma empresa ágil, para
cada produto existe um time de planejamento e lançamento
que a empresa utiliza para alinhar as equipes técnicas com as
equipes de negócios para o lançamento.
Esta equipe é necessária porque, embora as equipes ágeis
sejam habilitadas, não tem necessariamente a visibilidade
do negócio, ou até mesmo a autoridade para decidir quando
será a entrega do produto para o usuário final. Geralmente
essa equipe é formada pelos principais membros do nível de
programa da empresa, tais como:
• Linha de negócio;
• Proprietário e gerente do produto;
• Representantes de marketing;
• Gerentes associados aos produtos;
• Equipe de implantação do produto.
É recomendado que essa equipe faça reuniões semanalmen-
te ou em um período adequado à importância do produto.
A reunião tem como principal foco debater a situação do
produto, tais como: status; onde estamos; se vamos cumprir
a tempo nossos objetivos; mudanças necessárias; impactos,
entre outros.
O principal intuito desse encontro é promover a visibilidade
ampla e o gerenciamento sênior semanal para o estado de
liberação do produto.
Roteiro ou Roadmap
A equipe de gerenciamento e liberação no final de cada fórum
resulta nos dados do planejamento da versão que são usados
para atualizar a planilha de roadmap.
O roteiro deve ser composto com as datas planejadas para
os lançamentos de cada solução, cada qual com o consultor de
recursos priorizando conforme a necessidade do negócio. A
Figura 4 representa o modelo de um roadmap.
O roteiro está sujeito a alterações em qualquer fase do pro-
duto, essas alterações podem ser causadas por questões como:
prioridade de negócio, fatores técnicos entre outros fatores
imprevisíveis, portanto, não se deve fazer compromissos ex-
ternos com planos além do próximo lançamento.
Requisitos não-funcionais
A visão também precisa conter os requisitos não-funcionais,
tais como: confiabilidade, desempenho, qualidade, compatibili-
dade e etc. Os requisitos não-funcionais devem ser descritos no
backlog do programa como recursos normais, ou seja, usando
o mesmo conceito de histórias de usuários. Alguns exemplos
de como esses requisitos podem ser solicitados são:
• O cliente solicita que o aplicativo funcione nos principais
navegadores do mercado;
• O cliente exige que uma determinada funcionalidade seja
executada em no máximo 30 segundos;
• O cliente solicita disponibilidade de 99,99% do sistema.
Figura 4.Ilustração básica de uma planilha de roteiros
Teste de requisitos não-funcionais
Requisitos não-funcionais, como desempenho, disponibilida-
de e outros do gênero, são frequentemente descritos pelo cliente
como qualidade do produto, porém devem ser aplicados no
backlog como um histórico de usuário e tratado como recurso,
assim aplicando os testes para sua qualidade. A Figura 5 ilustra
um modelo simples para aplicação de testes de qualidade nos
requisitos não-funcionais.
Figura 5.Modelo básico de teste de requisitos não-funcionais
Geralmente a maior parte dos requisitos não-funcionais (0..*)
requerem um ou mais testes. Neste cenário, pode ser aplicado
outro tipo de testes de aceitação. Aplica-se então os testes
de qualidade de sistemas. Este termo indica que estes testes
devem ser executados em intervalos periódicos no intuito de
validar o sistema.
Requisitos ágeis para a empresa
O terceiro e último requisito ágil que será apresentado neste
artigo é o nível empresa ou portfólio. Nesta etapa, encontramos
a função de gestão de portfólio que inclui equipes e organiza-
ções dedicadas à gestão dos investimentos e conformidades
com a estratégia de negócio da organização.
Para muitas fábricas de software atualmente, independente
do tamanho de seus projetos ou equipes, o modelo de equi-
pes junto ao modelo de programas podem ser o suficiente
para gerenciar seus projetos de forma ágil. No entanto, para
empresas que contém muitos produtos em que a governança
e o modelo de gestão para o desenvolvimento de novos ativos

de software exige novos artefatos e níveis ainda mais altos de
abstração, a inclusão do modelo de portfólio pode ajudar no
gerenciamento desses novos desafios.
Requisitos de investimento
Um conjunto de temas de investimento estabelece os objetivos
de investimento em relação à empresa ou unidade de negócio.
Este tema é o item que representa uma série de iniciativas que
impulsionam os investimentos da empresa para determinada
solução, produto ou serviço.
Equipe de gestão de portfólio
A equipe de portfólio pode ser formada pelos gerentes ou
responsáveis pelo negócio. Os membros desta equipe são os
indivíduos que tem a responsabilidade final com as linhas de
negócio. Em algumas empresas, esse processo pode ser com-
parado aos processos de elaboração orçamentária anual.
A equipe de gestão de carteira/portfólio toma suas decisões
com base em uma combinação das seguintes opções:
• Investimento em ofertas de produtos, melhorias, suporte e
manutenção;
• Investimento em novos produtos, novos serviços ou trabalho
comercial para ganhar novas fatias de mercado;
• Reduzir investimento para as ofertas existentes que estão
chegando ao fim de sua vida útil ou lucrativa.
Para fornecer governança e visibilidade nesta fase de investi-
mentos, a equipe de gerenciamento de portfólio pode ser diri-
gida pelas melhores práticas de um modelo de gerenciamento
de projetos como PMO.
Arquitetura:empresa,programa e equipe
Ao obter maturidade ágil a organização tende a continuar a
construção e conservação de uma arquitetura de responsabili-
dade eficaz. Ao administrar e gerenciar esses níveis de requi-
sitos que resultam em agilidade, a empresa pode evitar alguns
acontecimentos ruins, porém comuns, como por exemplo:
• Atrasos consideráveis para o lançamento do produto;
• Redução do risco de criar uma arquitetura sem capacidade
de se estender, deixando o sistema frágil e instável a mudanças,
correndo o risco de ser totalmente reescrito;
• Evita o desperdício de esforços no desenvolvimento e maus
investimentos.
É importante que essa administração ocorra de forma contí-
nua em cada um dos níveis apresentados.
Conclusão
É importante ressaltar que o modelo com níveis de equipes,
programas e empresas apresentados neste artigo é uma de-
finição arbitrária. Portanto, o objetivo é fornecer um modelo
mental que ajude a elevar o alcance de abstração e escala para
se obter agilidade no desenvolvimento de software.
Emresumo,vimosumconjuntoderequisitosquesãootimizados
para apoiar a entrega rápida das necessidades valiosas do cliente.
Tambémvimoscomoasequipeságeispodemalcançaraqualidade
mais alta através de testes funcionais e automação de teste.
Noníveldeprograma,foramapresentadosrequisitos,artefatos
eprocessosquesãonecessáriosparaalcançarodesenvolvimento
ágil.Foiapresentadoummodeloorganizacionalparaauxiliarna
montagem de equipes otimizadas para a entrega ágil de valor.
E, para concluir, introduzimos o nível de empresa. Nesta
fase foi apresentada de forma resumida uma abordagem sobre
os temas de investimento estratégico, gestão de portfólio e
arquitetura de melhoria contínua.
Mike Cohn’s blog Succeeding with agile
http://www.mountaingoatsoftware.com/
Chad Holdorf’s blog
http://www.scaledagiledelivery.com/
Dean Leffingwell, Agile Software Requirements: Lean Requirements Practices for Teams,
Programs,and the Enterprise,Addison-Wesley Professional,2010.
CraigLarman;BasVodde,ScanlingLean&AgileDevelopment,Addison-WeslyProfessional,2008
ChrisSterling;BrentBarton,ManagingSoftwareDebt:BuildingforInevitableChange,Addison-
Professional,2010.
Mike Cohn, Succeeding with Agile: Software Development Using Scrum, Addison-Wesley
Professional,2009
Links
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazinetem que ser feita ao seu gosto.
Para isso, precisamos saber o que você,leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Dês
eu Feedback
sobrees
taedição

Fábio Cruz
fabiorcruz@gmail.com
Graduado na área de TI e PMP certifica-
do com mais de 17 anos de experiência
profissional, atuando sempre na área de
desenvolvimento desistemas,sendoosúl-
timos 10 dedicados à liderança de equipes
e à coordenação de projetos. Atualmente
gerente de projetos na empresa americana
Ascendant Technology, voluntário no PMI
Chapter de Santa Catarina e autor do blog
www.fabiocruz.com especializado em ge-
renciamento de projetos.
Demonstrar como utilizar os artefatos de um geren-
ciamento ágil como o Scrum, suportando e dando
apoio aos artefatos também complementares do
gerenciamento tradicional, apresentando como esta
união pode ser benéfica para um mesmo projeto,
principalmente na área de gerenciamento das co-
municações, proporcionando um acompanhamento
transparenteebempróximodaexecuçãodoprojeto.
Esteartigovisademonstrarcomoresolverproblemas
geradosporfalhasdecomunicaçãoentreaequipedo
projeto,suagerênciasênioreocliente,apresentando
formasdeeliminarosburacoscausadospelafaltade
informação através da união de artefatos de origem
ágil com outros de origem tradicional, fornecendo
reflexõeseprovocandoaçõesparaunirasduasabor-
dagensemummesmoprojeto.
Resumo
Para se gerenciar projetos de desenvolvimento de
softwares é preciso estar constantemente atuali-
zado com as informações do projeto, e ao mesmo
tempo comunicar a todos os interessados com a
frequência necessária. Este artigo mostra como
aliar os artefatos de uma abordagem ágil como o
Scrum ao gerenciamento de projetos tradicional,
gerando benefícios e melhorando a comunicação
do projeto em várias direções.
Scrumeogerenciamentodeprojetos–Parte3
OScrumeasuarelaçãodealiançacomogerenciamentodeprojetostradicional
Engenharia
Nesta seção você encontra artigos voltados para testes,processo,
modelos,documentação,entre outros
I
ndependente do método utilizado
para executar e gerenciar projetos, a
comunicação continua sendo a área
mais importante quando se fala do su-
cesso em projetos. Simplesmente porque
a comunicação precisa acontecer para
que o projeto seja entendido, executado
e entregue.
Outro objetivo fundamental da comu-
nicação é manter a gerência sênior das
empresas envolvidas com o projeto in-
formadas sobre o andamento do mesmo.
Entende-se gerência sênior, neste caso,
como o patrocinador do projeto (Sponsor)
e as demais gerências compostas pelo
corpo diretivo responsável pelo projeto,
tanto na empresa executora quanto na
empresa contratante.
Esta comunicação tem o objetivo
principal de posicionar e informar.
Normalmente estes posicionamentos
são requisitados periodicamente e
geralmente incluem análises de valor
agregado, marcos principais (milestones),

14 Engenharia de Software Magazine- Scrum e o gerenciamento de projetos – Parte 3
últimas realizações do período, principais riscos, situação fi-
nanceira atual do projeto, entre outras informações relevantes
que podem variar um pouco de acordo com o projeto e com a
necessidade de informação das gerências.
Quando o projeto está no início, ou quando está tudo bem
controlado e o cliente satisfeito, a comunicação visando po-
sicionar e informar costuma ser desvalorizada, feita de uma
forma resumida demais e deixando de ser um valor real para
quem as recebe, ou seja, deixando de informar aos interessa-
dos dados importantes sobre o projeto. Este comportamento
faz parecer que a comunicação não é necessária quando tudo
está indo bem.
Por outro lado, quando o projeto está com problemas, ou
em fases críticas, um simples relatório de situação do projeto
(Status Report) pode ser um drama para um gerente ou para
uma equipe despreparada, e que principalmente não estava
informando e posicionando desde o início do projeto. Sendo
assim, o primeiro recado é que a comunicação deve ser reali-
zada sempre, durante todo o ciclo de vida do projeto.
A tarefa de comunicar e informar sobre o andamento do
projeto deve ser simples, e é obrigatória para qualquer gerente.
Porém, esta atividade que deveria ser simples, pode se tornar
um pesadelo pelo simples fato da equipe de gerenciamento
não manter informações atualizadas e bem documentadas
sobre o projeto. Esta falta de informação centralizada faz com
a equipe tenha que sair correndo atrás dos dados no dia da
apresentação do Status Report, ou após a ligação da gerência
sênior pedindo informações atualizadas.
Buscando evitar este tipo de problema e facilitar a comuni-
cação geral de um projeto, este artigo se propõe a apresentar
um modelo de união de alguns artefatos de comunicação do
gerenciamento tradicional, com outros existentes no geren-
ciamento ágil, mais especificamente no framework do Scrum,
com o objetivo de interligar todas as partes interessadas de um
projeto através de informações corretas e bem distribuídas.
Conceitos de gerenciamento ágil e tradicional
Alguns conceitos importantes para o entendimento do Scrum
foram descritos nas primeiras duas partes desta série de arti-
gos, que foram publicadas nas edições 41 e 43 da Engenharia
de Software Magazine.
O framework do Scrum é uma das práticas ágeis mais utiliza-
das atualmente, principalmente por trazer benefícios ao geren-
ciamento de projetos de software. Um destes benefícios mais
evidentes é a forma com que o Scrum propicia a visualização
dos trabalhos do projeto de forma direta, objetiva e simples.
Apoiado na qualidade do Scrum de contribuir para uma co-
municação mais eficaz e eficiente, será demonstrado aqui como
comunicarasinformaçõesmaisrelevantesparaumacompanha-
mento de um projeto que está sendo executado. O acompanha-
mento poderá ser realizado pelo time de execução, pela equipe
de gerenciamento operacional e pela gerência sênior.
Mais uma vez, como nos artigos anteriores desta série,
mostraremos como o Scrum complementa o gerenciamento
tradicional, assim como o gerenciamento tradicional apóia o
Scrum. Porém, não iremos comparar o Scrum a nenhuma abor-
dagem tradicional específica, mas sim tratar o gerenciamento
de projetos como uma área de conhecimento geral, com seus
aspectos comuns em várias abordagens de mercado.
A primeira parte tratou de papéis e responsabilidades, a
segunda falou das práticas, ferramentas e técnicas. Por fim,
nesta terceira parte, falaremos dos artefatos existentes nas duas
abordagens, agindo de forma complementar e influenciando
diretamente no resultado da comunicação do projeto.
Gerenciamento ativo e não reativo
Antes de sair comunicando, a equipe de gestão precisa ter o
que comunicar e saber como fará a distribuição das informações
coletadas. Este pode ser o ponto mais importante, que definirá
uma boa ou uma má comunicação dentro de um projeto.
Um erro básico que parece simples de ser evitado, mas na
prática a sua ocorrência ainda é alarmante, é que os gerentes
de projetos, ou as equipes de gerenciamento, não acompanham
o projeto de perto, e não possuem informações constantemente
atualizadas. Isso gera um problema enorme, pois quando a
informação é solicitada, a gerência precisa reagir ao pedido e
sair correndo atrás dos dados.
Estegerenciamentoreativoéruimparatodooprojeto,podendo
gerar insegurança e a geração de dados falsos, além de demons-
trar falta de metodologia implantada e organização definida.
O objetivo deve ser sempre um gerenciamento ativo, ou seja,
não basta ter um modelo (template) de Status Report pronto
para ser usado, é preciso ter sempre as informações que serão
utilizadas para montar este relatório, e estas preferencialmente
devem ser as mais recentes possíveis. Neste ponto é que o
Scrum pode nos ajudar com seus artefatos e regras.
Artefatos do gerenciamento tradicional
O primeiro passo na direção de uma boa comunicação é
ter as definições do que, como e quando serão realizadas as
comunicações do projeto.
Neste ponto, o gerenciamento tradicional é um forte aliado,
pois quase todas as boas práticas e metodologias tradicionais
trazem em seu conteúdo a orientação de se criar um plano de
gerenciamento da comunicação.
Este plano é fundamental e deve ser construído e divulgado
no início do projeto; o quanto antes melhor. Este documento
não precisa ser extenso ou completo, pelo contrário, a orien-
tação é que seja curto e direto.
O objetivo de um plano de gerenciamento da comunicação é
determinar que tipo de informação deve ser veiculada durante
o projeto, como estas devem ser divulgadas, qual deve ser a
frequência de circulação de cada relatório informativo, e por
fim, quem deve receber cada um deles.
Outro artefato bem relevante e que se encaixa perfeita-
mente no tema comunicação, é o plano de gerenciamento do
projeto. Este plano poderá conter o de comunicação, além de
geralmente ser composto pelos planos de gerenciamento de
requisitos, escopo, mudanças, riscos e qualidade. Todos estes
sub-planos fornecem informações importantes para várias

Gerenciamento de Projetos
partes interessadas (stakeholders) pelo projeto, e geralmente
fazem parte do que será comunicado durante o projeto.
O plano de projeto pode conter, inclusive, informações
pertinentes de como as metodologias de gerenciamento de
projetos serão aplicadas e como funcionarão conjuntamente
ao longo do ciclo de vida do projeto. Já o plano de comu-
nicação deverá informar quais artefatos serão utilizados,
quais suas finalidades e origens conceituais (Scrum ou
tradicional).
A partir destes documentos elaborados e divulgados corre-
tamente, todos os responsáveis ou interessados ligados dire-
tamente ou indiretamente ao projeto, poderão saber o que a
equipe gerencial usará como artefatos de comunicação, além
de como e quando cada documento será distribuído.
Note que esta preparação para se comunicar no decorrer
do projeto, já é uma comunicação efetiva, e demonstra que
há clareza e transparência na forma com que o projeto será
conduzido e acompanhado.
Artefatos do Scrum
O primeiro dos artefatos importantes do Scrum é o Backlog
do Produto, que é o conjunto de todos os requisitos e trabalhos
necessários para entregar o projeto. Este artefato pode incluir
regras de negócios, protótipos de tela, casos de uso, entre
outros documentos relevantes.
Partindo de um Backlog do Produto completo para o projeto,
ouparaumaversãodeentrega(release),seconsegueobterospró-
ximos e mais detalhados documentos que fornecerão os dados
importantes para que as comunicações do projeto aconteçam.
O Backlog do Produto se transforma no Backlog da Sprint,
que deverá conter apenas os trabalhos selecionados para se
entregar na próxima Sprint. A partir desta seleção de itens do
Backlog, a equipe poderá ser apresentada a outro artefato do
Scrum, as estórias dos usuários.
Falamos mais sobre Backlog do Produto na edição 43 da
Engenharia de Software Magazine.
Estórias do usuário
Uma estória do usuário (user story) é uma descrição resumida
que representa um item do Backlog, devendo ser sempre do
ponto de vista do usuário final do produto. Em alguns casos um
item de Backlog poderá dar origem a mais de uma estória, por
questões de entendimento, ou para uma melhor visualização ou
até por uma estratégia de abordagem gerencial e de execução.
Um item de Backlog pode possuir diversos documentos as-
sociados a ele, além de especificações detalhadas. Entretanto,
uma estória resume em poucas palavras o que a funcionalida-
de deve fazer, servindo como um ótimo item para controle e
acompanhamento. É aqui que começamos a ter artefatos para
melhorar a comunicação, principalmente no nível gerencial.
Um exemplo para um fácil entendimento é um “cadastro
de livros”, que é um item de Backlog possuindo protótipo de
tela, modelo de dados, especificação de regra de negócio e
caso de uso. Estes são todos os documentos que compõem o
item de Backlog “cadastro de livros”, porém, para controle e
monitoramento, usaremos apenas a estória que definiremos
a partir do seguinte padrão:
“Como um <tipo de usuário>, eu quero <um objetivo> para
que <atenda uma necessidade>”.
PegandoonossoitemdeBacklog“cadastrodelivros”ecriando
uma estória com o padrão apresentado, teremos o seguinte:
“Comoumusuárioadministrador,euquerocadastrarumlivro
para que ele possa ser consultado por visitantes na internet”.
Como pode ser observado, é possível resumir todas as necessi-
dades em poucas palavras, permitindo que seja possível colocar
este texto em um post-it conforme ilustrado na Figura 1.
Figura 1.Estórias em post-its
A partir das estórias definidas, o time poderá trabalhar
na reunião de planejamento da Sprint. Lembrando que esta
cerimônia é parte integrante do Scrum e foi descrita em mais
detalhes na Engenharia de Software Magazine 43.
Tarefas
Na primeira parte desta reunião de planejamento, o time
entende as estórias e determina o tamanho de cada uma. Esta
estimativa servirá como artefato para medir o desempenho
dos trabalhos no futuro. Já na segunda parte, o time detalha
melhor as estórias, decompondo-as em tarefas menores.
Estas tarefas devem ter um tamanho apropriado para que
possam ser determinadas em horas para conclusão, e devem
ser independentes de outras atividades para que sejam consi-
deradas finalizadas.
O resultado desta decomposição das estórias em tarefas
menores será um dos mais importantes artefatos de controle
que usaremos ao longo do projeto, pois estas tarefas menores
serão utilizadas para que toda a equipe do projeto saiba o que
precisa ser realizado, o que está sendo trabalhado e o que já
foi concluído.
Uma estória é uma macro atividade, que resume um conjunto
de trabalhos. Este conjunto de trabalhos poderá ser ilustrado
através de várias tarefas associadas, que por sua vez vão com-
por a estória, como ilustrado na Figura 2.
Figura 2.Decomposição da estória em tarefas

Estamos falando destes dois artefatos porque precisamos
de dados para acompanhamento e monitoramento do projeto
conforme ele é executado, além de contribuir para o forne-
cimento de informações consolidadas e atualizadas o mais
breve possível. Com isso, começamos a colocar em prática a
comunicação do projeto durante a execução.
Quadro deTarefas (Taskboard)
Este é um dos artefatos fundamentais e característicos do
Scrum, e possivelmente o que mais contribui para a comuni-
cação do projeto e colaboração do time.
O quadro de tarefas nada mais é do que um espaço reserva-
do para se colar ou fixar os post-its com as estórias e tarefas,
separados por colunas e cores diferentes que proporcionam
uma rápida identificação da atividade e sua situação, conforme
ilustrada na Figura 3.
Figura 3.Quadro de tarefas do Scrum
O formato mais utilizado para montar o quadro de tarefa é:
• Coluna 1: As estórias são colocadas uma embaixo da outra,
na sequência da mais importante para a menos importante
de cima para baixo;
• Coluna 2: As tarefas “a fazer” ao lado direito da sua respec-
tiva estória;
• Coluna 3: As tarefas que o time “está fazendo”, também ao
lado da sua respectiva estória;
• Coluna 4: As tarefas já concluídas (“feito”), na última coluna
à direita, também seguindo a mesma linha da sua respectiva
estória;
• Colunas complementares: Após a quarta coluna pode haver
a coluna “não planejados”, para o agrupamento de tarefas não
previstas e que surjam ao longo do desenvolvimento, e/ou
colunas antes da “feito”, para separação de itens na etapa de
“testes”, por exemplo.
Além das colunas distintas para cada etapa do desenvolvi-
mento, também é sugerido que as tarefas sejam colocadas em
post-its menores que as estórias e que seja adotada uma cor
diferente para cada tipo de tarefa, por exemplo:
• Laranja: Tarefas planejadas;
• Verde: Tarefas não planejadas;
• Vermelho: Impedimento, ou seja, obstáculo que está impe-
dindo a realização de uma tarefa. Geralmente colocado sobre
a tarefa impedida;
• Amarelo: Tarefas de teste.
Com este quadro montado, a comunicação do projeto começa
a tomar uma forma naturalmente clara, objetiva e transparente.
Note que o quadro de tarefas ilustrado na Figura 3 pode ser
físico, e com isso fixado em uma parede bem visível para todos
os interessados nas informações ali contidas.
Qualquer um que direcionar os olhares para o taskboard verá
rapidamente um conjunto de informações condensadas em um
único local, tais como:
1. Quantas tarefas estão sendo realizadas simultaneamente
(“fazendo”), o que fornece o número de pessoas trabalhando
no desenvolvimento. O tamanho do time é representado pelo
número de estórias, pois uma pessoa só pode realizar uma
tarefa de cada vez;
2. Quantas tarefas já foram concluídas (“feito”);
3. Quantas tarefas ainda estão aguardando para serem traba-
lhadas (“fazer”);
4. Qual o número de tarefas não previstas, ou seja, quantas são
da cor verde. Este item evidencia rapidamente qual o esforço
aplicado em atividades não planejadas;
5. Se alguém está parado devido a algum impedimento, ou
seja, quantas tarefas estão sobrepostas com outras de cor ver-
melha. Este item mostra claramente os momentos de falta de
produção devido a fatores externos que não foram previstos
inicialmente;
6. Se a priorização dos trabalhos está sendo seguida conforme
o planejado, pois de acordo com a regra do Scrum, somente
depois de todas as tarefas da primeira linha estarem na coluna
“feito”, é que podem ser iniciadas as tarefas da segunda linha.
Neste caso, pode se tomar providências ao perceber um item
sendo realizado fora de prioridade.
Este quadro de tarefas também pode ser virtual, a partir da
utilização de softwares de gerenciamento ágil de projetos que
permitem o cadastramento, acompanhamento e divulgação
completa do taskboard. Um exemplo de uma ferramenta com
estas funções é o Rational Team Concert (RTC), que permite
o cadastro de projetos, de times, de Backlogs, de estórias e de
tarefas, além do acompanhamento da taskboard e do gráfico
de Burndown.
Outro detalhe importante sobre o taskboard é que os próprios
integrantes do time mantêm as tarefas atualizadas no quadro
pelo menos uma vez por dia, com influência principalmente da
cerimôniaconhecidacomoreuniãodiária,quepodeservistaem
maiores detalhes na segunda parte desta série de artigos.
Gráfico de Burndown
A Sprint é a principal iteração no Scrum, e ela nos ajuda a di-
mensionar os trabalhos e controlar o projeto em ciclos menores

de até um mês. Maiores detalhes sobre as Sprints podem ser en-
contrados na Edição 42 da Engenharia de Software Magazine.
A Sprint contém um conjunto de trabalhos a ser realizado em
um determinado espaço de tempo, por isso ela é muito útil para
acompanharaevoluçãodoprojeto.Porém,comofazeresteacom-
panhamento e saber se o projeto está atrasado ou adiantado?
A resposta não é tão difícil quanto parece, principalmente
depois de termos falado sobre o Backlog da Sprint, estórias
e tarefas.
Todas as tarefas que precisam ser realizadas dentro da Sprint
estãonotaskboard,noentantoapenasolharparaoquadrodetare-
fasnãodizaequipedegerenciamentoseoprojetoestáemdiaou
não. Para resolver este problema entra em ação o último artefato
do Scrum que nos interessa aqui, o gráfico de Burndown.
O Scrum como abordagem ágil se preocupa com o esforço
restante para se terminar o trabalho, e não com o que já foi
concluído. Em outras palavras, o que importa no controle
do Scrum é a quantidade de tarefas que ainda precisam ser
completadas até o final da Sprint.
O gráfico de Burndown representa visualmente a soma
das estimativas dos esforços restantes para se terminar os
trabalhos contidos no Backlog da Sprint. Por isso, olhando o
gráfico ilustrado na Figura 4, temos à esquerda uma coluna
com a quantidade de trabalho que precisa ser completada,
sendo que no primeiro dia da Sprint o trabalho restante será
igual ao trabalho total.
Figura 4.Gráfico de Burndown.
Os dias estão na linha inferior do gráfico, e o acompanhamen-
to é simples. Em resumo, o dia atual deve ter menos trabalho
restante do que o dia anterior. Visualmente podemos fazer uma
comparação fácil que nos ajudará muito na identificação da
evolução dos trabalhos, permitindo saber se estão adiantados
ou atrasados, da seguinte forma:
1. No primeiro dia da Sprint, monte o gráfico colocando na
coluna da esquerda a quantidade de trabalho necessário para
completar a Sprint;
2. Na linha inferior coloque os dias em que a Sprint ocorrerá;
3. Por fim, trace uma linha ligando o total de trabalhos que
precisam ser completados (coluna à esquerda) ao último dia da
Sprint (à direita). Esta linha representará a velocidade média
do time para atingir a meta da Sprint;
4. Ao final de cada dia da Sprint, ou no máximo no início de
cada dia, marque no quadro a quantidade de trabalho restante
na coluna referente ao dia específico;
5. Trace uma nova reta ligando os pontos marcados com o total
de trabalho restante a cada dia. Pronto, você terá a velocidade
real do time.
Na ilustração da Figura 4, a linha vermelha representa a
estimativa dos trabalhos a serem completados por dia, ou seja,
a velocidade esperada marcada no início da Sprint.
A linha azul mostra a velocidade real do time de acordo com
os trabalhos que estão sendo completados a cada dia. Caso a
linha azul (real) esteja acima da linha vermelha (estimada), a
Sprint está atrasada, caso contrário, está adiantada.
Para a opção do quadro físico fixado em uma parede, o time
do projeto pode atualizar as tarefas antes ou durante as reu-
niões diárias, que é a melhor opção.
Para a opção de taskboards virtuais através de softwares, opte
por ferramentas que se integrem com os ambientes de desenvol-
vimento e já atualizem automaticamente as tarefas em tempo
real.Porexemplo,quandoumdesenvolvedorencerraumatarefa
pela ferramenta de desenvolvimento, esta por sua vez atualiza
o software que mantém a taskboard também atualizada.
Comunicação visual
Seguindo as etapas descritas, e principalmente usando os
artefatos sugeridos pelo Scrum, teremos uma comunicação
visual muito eficiente. A equipe de execução e gerência do
projeto, bem como a gerência sênior que tenha acesso ao qua-
dro de tarefas e ao gráfico de Burndown, terá total acesso ao
andamento do projeto.
Informações como quantidade de trabalho estimado e reali-
zado, equipe alocada, planejamento, imprevistos, velocidade,
riscos e atrasos poderão ser visualizados por todos, mantendo
todas as informações relevantes claras e transparentes.
O impacto visual tem ainda uma característica importantís-
sima. Provavelmente muitas pessoas olham para estas evidên-
cias destacadas e pensam: “Mas com isso os meus erros e os da
minha equipe ficarão a mostra!”. Exatamente! E é por isso que
este modelo de trabalho se torna tão interessante.
Os problemas e falhas realmente ficarão evidenciados, se
tornando um problema para os times que não buscam melhorar
e corrigir seus defeitos. Para os demais, os resultados serão os
melhores possíveis, porque a própria equipe buscará a cada
iteração (Sprint) melhorar os seus resultados.
Os bons times buscarão transformar o taskboard em uma
evidência de seu bom trabalho, e não em um problema que
mostra para todos os seus erros. Esta qualidade que o Scrum
proporciona pode ser entendida como um processo de me-
lhoria contínua.
Comunicação formal
Com os trabalhos sendo realizados conforme as definições
do tradicional plano de gerenciamento do projeto e seguindo
as cerimônias, regras e artefatos do Scrum descritos até agora,

não vão faltar dados para se montar relatórios de situação e
informações relevantes para reuniões de acompanhamento.
Mesmo com metodologias ágeis de gerenciamento de pro-
jetos, como Scrum, haverá momentos em que será preciso
gerar documentos formais para divulgação às gerências, pa-
trocinadores, clientes, parceiros, e outros. Além de que estes
relatórios podem ser oficiais para aceite e/ou recebimento de
parcelas financeiras de trabalho completado ou simplesmente
para acompanhamento gerencial.
A partir do plano de comunicação realizado no início do pro-
jeto, a equipe gerencial terá no planejamento oficial do projeto
alguns documentos conhecidos como meios de comunicação,
podendo ser, por exemplo:
1.Cronograma de tarefas atualizado, principalmente eviden-
ciando milestones, disponibilizado na internet em sites seguros
com acesso restrito;
2. Relatórios de situação divulgados semanalmente por
e-mail;
3. Apresentações executivas para o comitê gestor, realizadas
mensalmente.
Cronograma Macro (milestones)
O cronograma é uma ferramenta muito importante e in-
teressante para apoiar os trabalhos do gerente de projetos,
porém pode ser extremamente penosa e atrapalhar quando
mal utilizada.
O detalhamento excessivo é um problema comumente en-
contrado nos cronogramas, e que dificulta muito o seu uso.
Se este documento fosse criado apenas uma vez e nunca mais
alterado, tudo bem, mas na vida real dos projetos isso é quase
impossível. Quanto mais detalhado o cronograma, mais ma-
nutenção ele terá.
Para evitar este problema, uma sugestão é utilizar este docu-
mento de apoio sem grande detalhamento de itens, tarefas ou
níveis. Monte um cronograma mais macro e apenas com fases,
milestones e iterações (Sprints), como ilustrado na Figura 5.
Perceba que o cronograma fica mais enxuto, mas sem deixar
de fornecer as informações importantes sobre datas e etapas
concluídas. Claro que ele só funcionará corretamente se no
início do projeto for divulgado o conteúdo previsto dentro de
cada fase e etapa ilustrada no cronograma.
A boa comunicação fica evidente quando há eliminação de
duplicidadesedeexcessodedadosemrelatóriosdeacompanha-
mento periódicos. Se você precisar colocar todas as informações
do seu projeto, detalhadas ao máximo, em todos os seus relató-
rios de situação semanal ou mensal, com certeza houve falhas
graves de comunicação inicial, e estas continuam ocorrendo.
Relatórios de situação (Status Report)
Dependendo do tamanho, complexidade, valor ou impor-
tância de um projeto, os interessados nele podem querer
informações resumidas sobre a sua situação semanalmente,
quinzenalmente, mensalmente ou em outra frequência pré-
definida. Por isso é de suma importância que a equipe de
gerenciamento do projeto esteja preparada para fornecer as
informações relevantes sempre que necessário.
O Status Report é um documento geralmente muito requi-
sitado e utilizado por gerentes do mundo inteiro. O formato
ideal é aquele que consegue condensar todas as informações
importantes em uma única página. Principalmente porque o
objetivo deste relatório é informar rapidamente qual a situação
do projeto, e para isso ele precisa ser objetivo para que quem
o receba o leia na íntegra.
A equipe gerencial precisa ser clara e direta com problemas,
soluções, dificuldades, fracassos e até mesmo com os sucessos
e resultados obtidos. Então não é preciso fazer documentos ex-
tensos e cansativos. Informe o que é preciso, e se for necessário,
o interessado solicitará uma reunião ou documentos auxiliares
para esclarecimentos e maiores detalhes.
Um conteúdo interessante para um Status Report objetivo é
apontar a situação geral dos trabalhos completados, podendo
ser atrasado, em dia ou adiantado, e a situação financeira do
projeto, apontando se os gastos estão dentro do previsto, abaixo
ou acima do orçamento.
Como complemento, a equipe gerencial pode colocar a fase
em que o projeto se encontra e as últimas realizações. Além do
apontamento de riscos para os próximos períodos e eventuais
obstáculos que estejam impedindo os trabalhos.
Figura 5.Cronograma com milestones

Todas estas informações são encontradas facilmente com o
resultado da aplicação das cerimônias do Scrum como a reu-
nião diária, review e retrospectiva. Outra fonte de informação é
a análise das tarefas controladas pelo taskboard, e pela situação
do projeto mostrado no gráfico Burndown.
Por isso é tão importante seguir as boas práticas de um
modelo ou metodologia. Não é só burocracia, são passos na
direção de solucionar problemas rotineiros e que podem ser
evitados. Seguindo as cerimônias, regras e artefatos do Scrum,
naturalmente será gerado insumo para realizar a comunicação
do projeto de forma rápida, segura e eficiente.
Reuniões de comitê executivo
Além dos cronogramas e relatórios divulgados para os
stakeholders do projeto, frequentemente há necessidade de apre-
sentações executivas para um comitê gestor, como presidentes,
diretores e conselheiros.
Mais uma vez os materiais já gerados e utilizados para execu-
ção, acompanhamento e comunicação do projeto serão úteis.
Geralmente os gerentes montam apresentações em ferra-
mentas como o Microsoft PowerPoint, e resumem os dados do
último cronograma atualizado e do último Status Report para
compor a apresentação.
Dependendo do projeto a apresentação é focada mais na
parte financeira, ou mais na parte de valor agregado e tarefas
completadas, não costumando fugir muito disso. Mais uma
vez as informações necessárias para a montagem de uma
apresentação como esta podem ser coletadas, acompanhadas e
resumidas através dos processos descritos neste artigo, ficando
mais fácil e rápido resgatá-las no momento oportuno.
Conclusão
Tendo a comunicação como principal ferramenta de trabalho
para se atingir o objetivo do projeto, é possível se alcançar
excelentes resultados. Principalmente quando se segue boas
práticas e teorias reconhecidas pelo mercado, tais como o
Scrum, combinando-as com experiências reais em projetos que
foram bem sucedidos com a ajuda de uma boa comunicação.
Como foi demonstrado, o Scrum é uma ótima abordagem
para melhorar a comunicação de todo o time do projeto
durante a execução do mesmo, mostrando claramente quais
trabalhos devem ser feitos, ou estão sendo realizados, ou já
foram completados.
Os artefatos deste gerenciamento ágil também fornecem
informações sobre velocidade e tamanho da equipe, riscos
evidentes através de impedimentos ou obstáculos aos traba-
lhos do time, além da situação atual do projeto, mostrando a
evolução de tarefas completadas.
O Scrum ainda fornece informações para as comunicações
maisformaisequeprecisamseguirlinhasmaisoficiaisdedivul-
gação, aprovação e registro, tais como cronogramas, relatórios
de situação e apresentações executivas para comitês gestores.
Esta união de modelos tradicionais com o ágil mais uma vez
se mostra positiva, e quando bem aplicada e complementada,
apóia de forma bem dinâmica e objetiva as equipes de geren-
ciamento de projetos.
Conforme o uso em conjunto destes dois modelos for cada
vez mais aplicado, e os resultados forem expressivamente
positivos, mais ficará evidente que não podemos considerar o
tradicional melhor que o ágil, e nem tão pouco o ágil melhor
que o tradicional.
As equipes de gerenciamento de projetos modernas e que
querem sobreviver neste mercado rápido, furioso e muitas
vezes cruel, não podem se apegar a apenas um conjunto de
conceitos, e precisam se adaptar, observar e acompanhar as
mudanças do mercado, das tecnologias e das metodologias.
Nada é perfeito, nem os seres humanos, nem as máquinas e
nem tão pouco os processos ou modelos, portanto, quando se
tem em mente que se pode unir os melhores pontos positivos
de cada abordagem, buscando uma melhor metodologia de
aplicação, as chances de sucesso são bem maiores do que
apostar todas as fichas em apenas uma delas.
Lembre-se sempre que o objetivo principal do gerenciamento
de projetos, independente da abordagem, se resume a entregar
um projeto com sucesso. Por isso pense sobre a possibilidade
de união de um modelo ágil como o Scrum a um modelo tra-
dicional, somando os pontos positivos, subtraindo os pontos
negativos, e obtendo como resultado final o sucesso de forma
mais controlada, fácil e segura.
Introdução ao Scrum,blog FabioCruz.com
www.fabiorcruz.wordpress.com/outros/introducao
Introdução ao PMBOK®,blog FabioCruz.com
www.fabiorcruz.wordpress.com/pmbok%c2%ae/introducao
Scrum Guide 2011,escrito por Ken Schwaber e Jeff Sutherland
www.scrum.org/scrumguides
Links
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazinetem que ser feita ao seu gosto.
Para isso, precisamos saber o que você,leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Dês
eu Feedback
sobrees
taedição

20 Engenharia de Software Magazine- Estimativas de tamanho em projetos de software utilizando pontos de função
Jhoney da Silva Lopes
jhoney.lopes@gmail.com
Graduando em Ciência da Computação
pela Universidade Federal deViçosa (UFV).
Atualmente é Diretor Presidente da em-
presa júnior No Bugs (www.nobugs.com.
br),AssessordapresidênciadaSkepDesign
(www.skepdesign.com) e Diretor Vice-
Presidente de O Primeiro Plano. Áreas de
interesse:Engenharia de Software,Empre-
endedorismo,GerenciamentodeProjetose
Business Intelligence.
José Luis Braga
zeluis@dpi.ufv.br
Pós-doutoramento em Tecnologias da In-
formação na University of Florida. Doutor
em Informática pelo Departamento de In-
formática da PUC-Rio. Mestre em Ciências
da Computação pelo Departamento de Ci-
ência da Computação da UFMG.Atualmen-
te é Professor Titular do Departamento de
Informática do Centro de Ciências Exatas
e Tecnológicas da Universidade Federal
de Viçosa-MG. Atua na área de Ciência da
Computação, com ênfase em Engenharia
de Software e Sistemas de Informação.
Áreas de Interesse:Qualidade de Software
com Foco em Processos, Engenharia de
Software Experimental, Engenharia de
Software Apoiada por Ontologias, Enge-
nharia de Software Baseada em Agentes,
Sistemas de Apoio à Decisão.
Estimativadesoftwarecomderivaçõesemcusto,pra-
zo e esforço é uma necessidade comum entre as em-
presasdeTI.Nessecontexto,oobjetivodesteartigoé
apresentar de forma simples, por meio de exemplos,
o uso de um método poderoso para a solução destes
problemas recorrentes, a APF (Análise de Ponto de
Função).
AnálisedePontodeFunçãoéummétododemedição
dotamanhofuncionaldeumsoftware,combaseem
operaçõesextraídasdosrequisitosfuncionais.Apartir
dessamediçãoinicialdetamanho,derivam-seoutras
medidascomo,porexemplo,otemponecessáriopara
desenvolvimento,eumaestimativainicialdecustos.
APF tem por definição medir o que o software deve
fazer,enãocomoeledeveserconstruído,portantoo
processo de medição é fundamentado em uma ava-
liaçãopadronizadadosrequisitoslógicosdousuário.
Na fase inicial de um projeto, existe a necessida-
de de obter o custo, prazo e o esforço de imple-
mentação para estabelecimento de contratos de
desenvolvimento. Análise de Ponto de Função é
um método de medição do tamanho funcional de
software que permite fazer essas avaliações com
base em informações disponíveis nas fases iniciais
dos projetos. O uso do método profissionaliza a
avaliação inicial de tamanho, permitindo repeti-
çãodoprocessoeaumentodoníveldematuridade
no gerenciamento de projetos.
Resumo
Nafaseinicialdeumprojeto,anecessidadeemob-
terocusto,prazoeoesforçoéobservadoemtodas
as empresas, pois as mesmas precisam gerar um
orçamentoparaosseusclienteseavaliarumasérie
de projeções. Este artigo organiza de forma sim-
ples e introdutória conhecimentos sobre a Análise
de Ponto de Função.
Inicialmente não se tem conhecimento de todas as
características do produto bem como da sua real
dimensão, por esse motivo é necessário utilizar
técnicas de extração de requisitos para realizar um
levantamento inicial dos mesmos e compreender
melhoroproblema.Osrequisitossãocondições,ca-
racterísticasoucapacidadesnecessáriasparaatingir
uma finalidade, categorizados na implementação
de sistemas em funcionais e não funcionais como
formadeestabelecercritériosdequalidade.
Uma vez definidos os requisitos, pode-se então
avaliar o tamanho do sistema em termos de suas
funcionalidades. Existem vários métodos de esti-
mativa, a APF (Análise de Ponto de Função) é uma
delas.Essemétodonãotemcomoobjetivorealizar
estimativas de prazo, custo e esforço para imple-
mentação de sistema, mas sim avaliar o tamanho
deumsistemaemtermosdesuasfuncionalidades.
Resulta desta avaliação o tamanho funcional do
sistema expresso em Pontos de Função (unidade
de medida do método). A partir do tamanho fun-
cional, podem ser derivadas estimativas adicio-
nais, como tempo e custo.
Estimativas de tamanho em projetos de
software utilizando pontos de função
Um tutorial voltado para micro e pequenas empresas
Engenharia
Nesta seção você encontra artigos voltados para testes,processo,
modelos,documentação,entre outros

E
ste artigo apresentará uma visão geral sobre todos os
passos necessários para utilização da análise de ponto
de função, para a realização de estimativas na fase
inicial de um projeto de desenvolvimento, proporcionando
ao leitor uma visão restrita do método, mas suficiente para
estimar um projeto em sua fase inicial e, com isso, realizar
derivações de acordo com suas necessidades.
A análise por pontos de função surgiu em 1979 na IBM
(International Business Machines) e foi desenvolvida por Alan
Albrecht. A aceitação foi muito grande, e uma quantidade
cada vez maior de pessoas começaram a utilizar o método,
resultando na criação do IFPUG (International Function Point
Users Group). Hoje o método é mantido e evoluído pelo IFPUG
e fundamenta-se em seis passos:
1. Determinar o tipo de contagem;
2. Identificar o escopo da contagem e a fronteira da
aplicação;
3. Contar funções:
a. Tipo dados;
b. Tipo transação;
4. Determinar a contagem de pontos de função não
ajustados;
5. Determinar o valor do fator de ajuste;
6. Calcular o número dos pontos de função ajustados.
Como foi dito, a APF é um método que visa medir o tama-
nho funcional de um software do ponto de vista do usuário e
possui como unidade de medida o ponto de função (PF) (ler
Nota do DevMan 1).
Nota do DevMan 1
Usuário: Em Análise de Ponto de Função,usuário possui um conceito mais amplo:
qualquer entidade que se relacione com o sistema ou que produza um ônus ao mes-
mo.Ex:Pessoa,aplicação,leis,restrições,etc.
É importante perceber que para a APF o usuário não é somente a pessoa que inte-
rage com o sistema.
Possui como base os seguintes objetivos:
• Medir as funcionalidades (ler Nota do DevMan 2) imple-
mentadas no sistema;
• Medir esforço de implementação e de manutenção do softwa-
re, independente de tecnologia, ou seja, a APF leva em consi-
deração o que o software faz e não como ele é construído;
• Simplicidade, o trabalho para aplicar a APF deve ser o mí-
nimo possível, ele não deve ser um ônus no desenvolvimento
do software.
É importante ter em mente, durante todo o processo da
utilização do método de análise de pontos de função, que o
usuário é quem define o que faz parte ou não do projeto, di-
ferentemente de alguns métodos que levam em consideração
a visão do desenvolvedor, ou seja, uma visão técnica. Na APF
o que importa é a visão do negócio e quem possui essa visão
é o usuário, lembrando que usuário na APF possui um con-
ceito amplo e não é somente a pessoa que irá interagir com o
software final.
Nota do DevMan 2
Funcionalidade:Funcionalidade é o conjunto de tarefas fornecidas pelo sistema para
poderrealizartransação,processamentoearmazenamentodosdadosdosusuários.
Determinar o tipo de contagem
O primeiro passo para a contagem será determinar qual o tipo
de contagem a ser realizada, como pode ser visto na Figura 1.
Na APF existem três tipos de contagem:
• Projeto de desenvolvimento;
• Projeto de melhoria;
• Aplicação.
Figura 1.Passos para a contagem dos pontos de função (VAZQUEZ,2009)
Este artigo tem por objetivo apresentar a solução de contagem
para projeto de desenvolvimento, mas serão apresentadas as
diferenças entre elas.
Projeto de desenvolvimento
Écaracterizadocomoprojetodedesenvolvimento,umnovopro-
jetodesdeafasedeextraçãoderequisitos(lerNotadoDevMan3)
até a instalação do mesmo. Neste tipo de projeto são contadas
na APF todas as funcionalidades fornecidas aos usuários até a
instalação do sistema, ou seja, funcionalidades de conversão (ler
NotadoDevMan 4)tambémsãocontadas.Sósepodesabertodos
os requisitos de um sistema após o término do projeto, sendo
assim, toda a contagem de um projeto de desenvolvimento pode
ser entendida como estimativa e não medição.
Projeto de melhoria
O projeto de melhoria mede todas as funcionalidades no-
vas, modificadas e excluídas de um determinado sistema.
Ao término de um projeto de melhoria a aplicação deverá
ser contada com o intuito de atualizar o valor em pontos de
função da mesma.

Aplicação
Entende-se por contagem do tipo aplicação um software
instalado, ou seja, a contagem após o término de um projeto
de desenvolvimento. Neste caso, não se leva em consideração
as funções do tipo conversão.
Aplicando o conhecimento – Determinar o tipo de
contagem
Neste artigo será realizada a contagem de um projeto
simples, extraído da base de projetos da No Bugs - Empresa
Júnior do Bacharelado em Ciência da Computação da Uni-
versidade Federal de Viçosa.
O foco deste artigo são as derivações dos pontos de função
para auxiliar na elaboração da proposta do projeto para o
cliente. A sua contagem será de um projeto de desenvolvi-
mento, um sistema simples de locação de veículos.
Identificar o escopo da contagem
O segundo passo para a contagem é identificar o escopo
da contagem e a fronteira da aplicação, como pode ser
visto na Figura 1. Muitas vezes a identificação do escopo
e da fronteira da aplicação não são levados tão a sério,
principalmente por empresas que não utilizam gerência
de projetos no gerenciamento do desenvolvimento de
software.
Esta é uma etapa crucial para o andamento do projeto,
a definição de um escopo (ler Nota do DevMan 5) errado
pode acarretar em prejuízos para o projeto ou até a perda
total dele. O escopo define quais funções serão incluídas
na contagem, ele pode abranger todas as funcionalidades,
apenas as funções utilizadas ou funções específicas.
A fronteira da aplicação é a linha que separa uma apli-
cação de outra. Dentro de um escopo de contagem pode
existir mais de uma aplicação a ser contada, por isso é
importante definir qual é a sua fronteira.
Nota do DevMan 3
Requisitos:São as necessidades e características que o sistema deve ter para atin-
gir as expectativas do cliente.A extração dos requisitos consiste em uma parte crítica
na elaboração de uma proposta,ela é parte determinante do sucesso ou fracasso de
um projeto.
Nota do DevMan 5
Escopo do Projeto: Escopo do projeto é o trabalho que precisa ser realizado para
entregarumproduto,serviçoouresultadocomascaracterísticasefunçõesespecifica-
das (PMBOK,2004),o escopo da contagem é tudo aquilo que deve ser contado.
Nota do DevMan 4
Funções de Conversão:Para um entendimento considere o exemplo:um sistema
A possui uma lista de funcionários cadastrados, o sistema B sendo contado deverá
incluirtodosessesfuncionáriosemsuabasededados,essafuncionalidadeserádispa-
rada uma única vez que é durante a instalação do sistema,sendo caracterizada como
função de conversão.
Uma sugestão simples para não errar nesta etapa é seguir
a regra do IFPUG que é determinar a fronteira da aplicação
baseado no Ponto de Vista do Usuário. O usuário define o que ele
entende sobre as atribuições do sistema e de cada aplicação.
Considera-se o exemplo apresentado na Figura 2, que mostra
três aplicações, AP01, AP02 e AP03, separadas por fronteiras
(círculos tracejados) e cada uma dessas aplicações interagem
umas com as outras, esta interação é feita a partir do que é
chamado de arquivos lógicos, que aparecem na figura como
quadrados preenchidos de preto.
Figura 2.Arquivos lógicos e fronteiras das aplicações
Aplicando o conhecimento – Identificar o escopo da
contagem
Como foi visto, nesta etapa devemos definir o escopo da
contagem e a fronteira da aplicação. No exemplo deste artigo,
trata-se de software destinado a uma empresa que realiza
locação de automóveis, o sistema é simples e composto por
uma única aplicação.
Contar funções do tipo dados
O terceiro passo para a contagem é dividido em duas par-
tes, contar funções do tipo dados e contar funções do tipo
transação, como pode ser visto na Figura 1. Funções do tipo
dados é o nome designado às funcionalidades fornecidas para
o armazenamento de dados na aplicação sendo contada (ler
Nota doDevMan6), são caracterizados como arquivos lógicos e
eles podem ser mantidos pela aplicação ou lida de outra, como
pode ser visto na Figura 2.
Arquivos lógicos que estão dentro da fronteira da aplicação
e mantidos pela mesma são chamados de Arquivos Lógicos

Internos (ALI), já os arquivos lógicos lidos de outra aplicação
são chamados de Arquivos de Interface Externa (AIE).
Nota do DevMan 6
Aplicação Contada: Como visto,um projeto pode ser composto por várias aplica-
ções internas que interagem umas com as outras, conforme a Figura 2.Quando um
projeto possui mais de uma aplicação, diz-se da aplicação sendo contada a que no
momento está sendo analisada, já projetos que possuem apenas uma aplicação, o
termo aplicação sendo contada refere-se a todo o projeto.
Arquivo Lógico Interno
Grupo lógico de dados persistentes e que são mantidos dentro
da fronteira da aplicação e alterados por meio de processos
elementares. Um processo elementar é a menor unidade de
atividade significativa para o usuário final (VAZQUEZ,2009).
É a menor funcionalidade disponibilizada ao usuário.
Considerando a Figura 2, a AP01 possui três arquivos lógicos
internos (ALI). À primeira vista, parecerá que cada tabela do
banco de dados da aplicação será um ALI. Essa é uma maneira
simples de entender o que seria um arquivo lógico, mas serão
mostrados alguns exemplos de que é um erro pensar dessa
forma, pois um grupo de tabelas pode ser considerado como
um único arquivo lógico, dependendo da forma como é utili-
zado pela aplicação.
Exemplos de ALI:
• Arquivo de configuração, conexão, segurança (senhas) man-
tidos pela aplicação;
• Tabelas ou grupos de tabelas do banco de dados mantidas
pela aplicação.
Não são exemplos:
• Arquivos temporários ou de backup;
• Tabelas temporárias ou views.
Arquivo de Interface Externa
Grupo lógico de dados persistentes mantidos dentro da fron-
teira de outra aplicação, mas requerido ou referenciado pela
aplicação que está sendo contada, ou seja, a aplicação sendo
contada acessa os dados presentes neste arquivo lógico, mas
o mesmo não está dentro da aplicação que está sendo contada
e sim em outra. Nesse caso denomina-se esse arquivo lógico
de arquivo de interface externa (AIE).
Considerando a Figura 2, a AP01 referencia arquivos lógicos
da AP02 e AP03, estes são os arquivos denominados de AIE.
Exemplos de AIE:
• Dados de segurança armazenados em arquivos lógicos e
mantidos por aplicações específicas a este fim;
• Dados salariais armazenados na aplicação financeira, mas
utilizados pela aplicação contada.
Não é exemplo:
• Dados armazenados na aplicação sendo contada e utilizados
por uma aplicação externa. Nesse caso a sua aplicação possui
um ALI e outra aplicação reconhece esses dados vindos de
um AIE.
Determinação da complexidade e da contribuição
Complexidade é o grau de influência que um arquivo lógico
tem para o tamanho funcional do sistema. A contribuição é
a conversão do grau de complexidade em pontos de função.
A complexidade é calculada a partir da contagem dos tipos de
dados e dos tipos de registro.
Tipos de dados (TD)
É um campo não recursivo de dado, único e reconhecido pelo
usuário, em uma visão geral e limitada. Por exemplo, poderiam
ser os atributos de uma tabela.
Tipos de Registro (TR)
É caracterizado por ser um subgrupo de dados.
Em uma análise míope, quando um agrupamento de tabelas
é reconhecido pelo usuário como um único arquivo lógico,
ALI ou AIE, a tabela reconhecida pelo usuário é contada e as
demais se tornam simplesmente tipos de registro, ou seja, essas
tabelas extras não pertencem à visão do negócio, pois o usuário
não as reconhece. Mas seus atributos são reconhecidos e, por
este motivo, devem gerar um impacto na contagem, sendo
denominado subgrupo de dados. Esses campos pertencentes
à visão do negócio e reconhecidos pelo usuário são atribuídos
aos demais arquivos lógicos que estão relacionados com esses
tipos de registro.
Considera-se como exemplo uma especialização, onde a
Figura 3 representa essa especialização na visão do usuário,
com os seguintes campos: id_func (código de identificação do
funcionário), salário, cro (número do registro para dentistas),
bolsa (bonificação no salário dos auxiliares).
Figura 3.Especialização na visão do usuário

Na modelagem, foram separados os diferentes tipos de fun-
cionários, como pode ser visto na Figura 4.
Neste exemplo contam-se os funcionários como uma ALI ou
AIE, pois como foi apresentado, o usuário não reconhece fun-
cionários como entidades diferentes, mas para a modelagem o
desenvolvedor optou por separar estes funcionários devido aos
atributos que os especializam. Como estas entidades criadas na
visão do desenvolvedor possuem atributos reconhecidos pelo

usuário, esse grupo de tabelas se constitui em uma ALI ou AIE
com três tipos de registro e esses atributos reconhecidos devem
ser contados como atributo de funcionários. São contados três
tipos de registro, pois todo arquivo lógico é um tipo de registro
dele mesmo e os atributos são somados a funcionários, pois
somente ele é reconhecido pelo usuário.
É importante perceber que esta solução é adotada uma vez que
o usuário enxerga Auxiliar e Dentista como Funcionário, e não
como entidades separadas, como pode ser visto na Figura 5. É
imprescindívelentenderqueummesmoproblemapodeteruma
contagem diferente com visões de negócios diferentes, ou seja,
o importante é o ponto de vista do usuário para a APF.
Figura 4.Especialização é um tipo de registro
Figura 5.Visão do Negócio
Tabela de complexidade
A tabela de complexidade é padronizada pelo IFPUG, todos
os usuários do método de análise de pontos de função utilizam
os mesmos valores.
Após o entendimento sobre tipo de dados e tipo de registro,
os mesmos serão utilizados para definir a complexidade do
arquivo lógico. Realiza-se a contagem dos tipos de registro e
tipos de dados de cada arquivo lógico, depois se verifica na
Tabela 1 o valor de cada um e o intervalo que pertence. Com
isso, define-se a ALI ou AIE como sendo de complexidade
baixa, média ou alta.
TiposdeRegistro
Tipos de Dados
< 20 20 – 50 > 50
1 Baixa Baixa Média
2 – 5 Baixa Média Alta
> 5 Média Alta Alta
Tabela 1.Complexidade ALI e AIE
Tabela de contribuição
A tabela de contribuição é padronizada pelo IFPUG, e todos
os usuários do método de análise de pontos de função utilizam
os mesmos valores.
Após identificar a complexidade de cada ALI e AIE do
sistema, é possível determinar a contribuição desses para a
contagem dos pontos de função.
Após verificar na Tabela 1 a complexidade do ALI ou AIE, a
tarefa para estabelecer a contribuição é muito simples, basta
saber a complexidade do seu arquivo lógico e se o mesmo é
um ALI ou AIE e verificar o valor na Tabela 2.
Tipo de Função Baixa Média Alta
Arquivo Lógico Interno 7 PF 10 PF 15 PF
Arquivo de Interface Externa 5 PF 7 PF 10 PF
Tabela 2.Tabela de contribuição
Aplicando o conhecimento – Contar Funções do tipo
dados
Para facilitar a identificação dos tipos de arquivos, deve-se
elaborar um modelo lógico. Uma dica geral e objetiva é contar
um arquivo lógico ALI ou AIE para cada tabela reconhecida
pelo usuário, ou seja, se a tabela existe no ponto de vista do
usuário ela deve ser contada, caso contrário não deve ser con-
tada. Se o usuário não reconhece a tabela, mas reconhece os
tipos de dados presentes na mesma, provavelmente essa tabela
será um tipo de registro.
A Figura 6 apresenta um esquema para classificar um ar-
quivo lógico.
Figura 6.Fluxo para classificação do tipo lógico
Passos para uma estimativa da contagem desta etapa
a) Elabora-se um modelo lógico seu projeto, como exempli-
ficado na Figura 7.
Identificam-se todas as tabelas reconhecidas pelo usuário, ou
seja, as que fazem parte da visão do negócio, classificando-as
como ALI ou AIE (vide Tabela 3).

Figura 7.Modelo lógico
Na Figura 7 as tabelas Usuário, Cliente e Carro foram carac-
terizadas como arquivo lógico interno e Aluga foi definida
como tipo de registro de Cliente e Carro, pois a mesma não é
reconhecida pelo usuário, mas os seus atributos são.
b) Faz-se uma análise da todas as tabelas que não estão na
visão do negócio:
• Se a tabela não pertence à visão do negócio, mas os seus
tipos de dados pertencem, deve-se contá-la como um tipo de
registro para cada arquivo lógico relacionado a ela, e atribuir
os seus tipos de dados a cada um deles;
• Se nem a tabela nem os seus tipos de dados pertencem à visão
do negócio, deve ser descartada da contagem.
A tabela Aluga foi considerada um tipo de registro, pois na
visão do negócio, os campos hora_aluguel e data_aluguel são
reconhecidos pelo usuário e por este motivo eles foram somados
aos tipos de dados de Cliente e Carro, conforme a Tabela 4.
Descrição Tipo Qtd.TDs Qtd.TRs
Usuário ALI 4 1
Cliente ALI 7 2
Carro ALI 8 2
Tabela 4.Tipo de Dado (TD) e Tipo de Registro (TR)
Quando se tem uma relação entre mais de um arquivo lógico
com uma entidade definida como tipo de registro, devem-se
identificar todos os atributos reconhecidos pelo usuário pre-
sentes nesta entidade tipo de registro e somá-los a todos os
arquivos lógicos que se relacionam com esta entidade. Isso é
necessário, pois estes atributos influenciam aos demais arqui-
vos lógicos e geram impacto no desenvolvimento do projeto.
c) Determinação da complexidade de cada arquivo lógico.
Para definir a complexidade basta analisar a quantidade de
tipos de dados mais as quantidades de tipos de registro e con-
ferir na Tabela 1. O resultado é apresentado na Tabela 5.
Descrição Tipo
Usuário ALI
Cliente ALI
Carro ALI
Tabela 3.Classificação dos arquivos lógicos
d) Determinação da contribuição de cada arquivo lógico e
realização a soma de todos.
Para determinar a contribuição basta verificar na Tabela 2 o
ponto de função referente a cada complexidade, o resultado é
apresentado na Tabela 6.
Descrição Tipo Qtd.TDs Qtd.TRs Complexidade Contribuição
Usuário ALI 4 1 Baixa 7
Cliente ALI 7 2 Baixa 7
Carro ALI 8 2 Baixa 7
Total de Pontos de Função = 21
Tabela 6.Contagem das funções do tipo dados
Contar funções do tipo transação
O terceiro passo para a contagem é dividido em duas partes,
contar funções do tipo dados e contar funções do tipo transa-
ção, como pode ser visto na Figura 1. Agora que foi aprendido
como contar funções do tipo dados, pode-se dar continuidade
à contagem da aplicação. As funções do tipo transação são as
funcionalidades base para o funcionamento do sistema, essas
funções são chamadas de processos elementares e são classi-
ficadas em Entradas Externas, Saídas Externas e Consultas
Externas.
Um processo elementar é a menor unidade de uma função
disponível ao usuário. Por exemplo, consultar clientes pode ser
entendido como uma função, mas o mesmo não pode ser en-
tendido como um processo elementar, uma vez que podem ser
realizadas inúmeras consultas diferentes aos clientes: consultar
clientes pelo nome, consultar clientes em débito, consultar
registro de clientes, e outras mais. Pode-se perceber que cada
consulta é uma funcionalidade única e independente. Desta
forma, para determinar um processo elementar é necessário
identificar todas as funcionalidades únicas e independentes
de uma função.
Uma observação importante é que um processo elementar
deve ser único. Por exemplo, consultas que diferem umas das
outras pela organização dos dados gerados, não podem ser
consideradas diferentes.
Entrada Externa (EE)
Uma entrada externa é um processo de controle, ela também
realiza o processamento de dados do sistema e direciona o
mesmo para atender os requisitos da aplicação. A principal
intenção da EE é realizar operações que visam manter (incluir,
alterar ou excluir) dados de um ou mais arquivos lógicos inter-
nos, realizando processamento, transação e armazenamento
de dados dos usuários do software.
Descrição Tipo Qtd.TDs Qtd.TRs Complexidade
Usuário ALI 4 1 Baixa
Cliente ALI 7 2 Baixa
Carro ALI 8 2 Baixa
Tabela 5.Complexidade

Uma EE deve ser única e não necessitar de ações anteriores e
nem sucessores. Por exemplo, no envio de um e-mail, escrever
o destinatário, o assunto e o corpo do e-mail não podem ser
entendidos como EE, pois não se constituem uma operação
completa, mas o conjunto de todas estas, e clicar no botão de
envio é que se caracteriza como uma EE.
Exemplos de Entrada Externa:
• Transações destinadas a manter ALI, incluir funcionário,
excluir funcionário, alterar funcionário e etc.;
• Operações;
• Processos destinados a realizar registros, por exemplo, em
um sistema de ponto eletrônico o usuário registra entrada e
saída.
Não são exemplos de Entrada Externa:
• Telas de filtro;
• Preenchimento de campos de dados;
• Telas de login;
• Gerar relatórios.
De modo geral, EEs possuem nomes característicos, como
incluir, alterar, salvar, excluir, editar, encaminhar, submeter
e registrar, dentre outros.
Saída Externa (SE)
Processo elementar destinado à apresentação de informação
ao usuário ou a outra aplicação externa que utilize cálculos
para processar essas informações.
A principal intenção de uma SE é apresentar informação para
o usuário a partir de lógica de processamento, ou seja, as in-
formações apresentadas devem passar por um processamento,
elas não devem ser simplesmente uma consulta simples. Este
processamento pode ter como objetivo manter ALIs ou alterar
o comportamento do sistema.
Exemplos de Saída Externa:
• Tela para liberar acesso (tela de login), sendo os dados da
transação criptografados;
• Relatórios financeiros, supondo esses gerados por cálculos;
• Consultas complexas com processamento de dados a partir
de cálculos;
• Apresentação de gráficos com dados processados a partir
de cálculos.
Não são exemplos de Saída Externa:
• Telas de filtro;
• Consultas simples, sem processamento de dados utilizando
cálculos.
Consulta Externa (CE)
Processo elementar que apresenta informação ao usuário ou
a outra aplicação externa por meio de recuperação simples.
Uma CE tem como principal intenção apresentar informações
ao usuário por meio de uma simples recuperação de dados
de uma ALI e/ou AIE. Esse processamento não deve possuir
lógica matemática, nem qualquer tipo de cálculo, não deve
gerar dados derivados e nem alterar o comportamento do
sistema. A CE é uma consulta simples e direta, com o retorno
da informação requisitada pelo usuário.
Exemplos de Consulta Externa:
• Consultar clientes pelo nome;
• Apresentar dados em formato gráfico a partir de recuperação
simples.
Não são exemplos de Consulta Externa:
• Relatórios financeiros, gerados a partir de cálculos;
• Telas de filtro.
Determinação da complexidade e da contribuição
Complexidade é o grau de influência que um processo elemen-
tar tem para o tamanho funcional do sistema. A contribuição é
a conversão do grau de complexidade em pontos de função.
Essa complexidade é calculada a partir da contagem dos tipos
de dados e dos arquivos referenciados.
Tipos de dados (TD)
É um campo não recursivo de dado, único e reconhecido pelo
usuário, ou seja, é cada campo preenchido ou apresentado ao
usuário. Por exemplo, em um formulário os campos nome, CPF,
endereço, o botão de confirmação, uma janela de mensagem
de erro, dentre outros, são tipos de dados. Já em um relatório,
o código do produto, o nome, a descrição, o valor, são tipos de
dados. Em um gráfico, o raciocínio é o mesmo, conta-se um
tipo de dado para o nome do produto, um para a quantidade
e um para o valor, no total tem-se três tipos de dados neste
relatório, como pode ser visto na Figura 8.
Figura 8.Apresentação de relatório gráfico

Arquivo Referenciado (AR)
Um arquivo referenciado é todo arquivo lógico lido, pode ser
um ALI ou AIE, ou todo arquivo lógico mantido, nesse caso
só pode ser um ALI. Um tipo de registro não é um arquivo
lógico, ele pertence a um arquivo lógico. Não se deve contar
tipos de registro e arquivos lógicos lidos várias vezes. Esses
são contados apenas uma única vez.

Requisitos para uma equipe ágil

Requisitos para uma equipe ágil

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (6)

Semelhante a Requisitos para uma equipe ágil

Semelhante a Requisitos para uma equipe ágil (20)

Requisitos para uma equipe ágil