APF Estimativas

Processo

engenharia

magazine
Conheça os modelos
de processo pessoal
de software
Processo
Edição 44 - Ano 04 Uma visão geral
do CMMI

Aprimore suas estimativas de tamanho de projeto

Agilidade Agilidade Requisitos
Requisitos para Scrum e o gerenciamento Gerenciando mudanças
alcançar agilidade de projetos - Parte 3 a partir de requisitos

Modelos de processo pessoal
http://www.devmedia.com.br/post-23264-Modelos-de-processo-pessoal.html

Desenvolvimento Desenvolvimento
Desenvolvimento de aplicações de Conheça técnicas para manter
realidade aumentada seu código “limpo” – Parte 6

Rodrigo Oliveira Spí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ção do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de
consultoria na COPPE/UFRJ. É Colaborador da Engenharia de Software Magazine.

Ano 4 - 44ª Edição - 2012 Marco Antônio Pereira Araújo
maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Linha de Pesquisa
em Engenharia de Software, Especialista em Métodos Estatísticos Computacionais e Bacharel em
Corpo Editorial
Matemática com Habilitação em Informática pela UFJF, Professor e Coordenador do curso de Ba-
charelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora, Professor do
Editor
Rodrigo Oliveira Spínola curso de Bacharelado em Sistemas de Informação da Faculdade Metodista Granbery, Professor e
Diretor do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação
Colaboradores Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador
Marco Antônio Pereira Araújo da Engenharia de Software Magazine.
Eduardo Oliveira Spínola

Jornalista Responsável Eduardo Oliveira Spínola
Kaline Dolabella - JP24185 eduspinola@gmail.com
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. É ba-
Na Web
charel em Ciências da Computação pela Universidade Salvador (UNIFACS) onde atualmente cursa o
www.devmedia.com.br/central
(21) 3382-5038 mestrado em Sistemas e Computação na linha de Engenharia de Software, sendo membro do GESA
(Grupo de Engenharia de Software e Aplicações).

Atendimento ao Leitor Fale com o Editor!
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo você

você tiver algum problema no recebimento do seu exemplar ou precisar de algum gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a vontade para

esclarecimento sobre assinaturas, exemplares anteriores, endereço de bancas de entrar em contato com os editores e dar a sua sugestão!

jornal, entre outros, entre em contato com: 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
www.devmedia.com.br/mancad
(21) 2220-5338 de publicar.

Apoio
Publicidade
Para informações sobre veiculação de anúncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br

EDITORIAL

N
a fase inicial de um projeto, a necessidade em obter o custo, prazo e o Neste contexto, esta edição da Engenharia de Software Magazine destaca
esforço é observado em todas as empresas, pois as mesmas precisam como tema de capa Análise de Ponto de Função. Para isto, trazemos um artigo
gerar um orçamento para os seus clientes e avaliar uma série de cujo objetivo é apresentar de forma simples, por meio de exemplos, o uso de
projeções. um método poderoso para a solução destes problemas recorrentes, a APF
Inicialmente não se tem conhecimento de todas as características do produto (Análise de Ponto de Função).
bem como da sua real dimensão, por esse motivo é necessário utilizar técnicas Além deste artigo, teremos mais sete nesta edição:
de extração de requisitos para realizar um levantamento inicial dos mesmos e • Requisitos para agilidade no desenvolvimento de software
compreender melhor o problema. Os requisitos são condições, características • Scrum e o gerenciamento de projetos – Parte 3
ou capacidades necessárias para atingir uma finalidade, categorizados na • Modelos de processo pessoal
implementação de sistemas em funcionais e não funcionais como forma de • CMMI – Uma visão Geral
estabelecer critérios de qualidade. • Gerenciando mudanças a partir de requisitos
Uma vez definidos os requisitos, pode-se então avaliar o tamanho do sistema • Introdução ao desenvolvimento de aplicações de realidade aumentada
em termos de suas funcionalidades. Existem vários métodos de estimativa, a • Boas práticas para escrita de métodos, funções e procedimentos – Parte 6
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 Equipe Editorial Engenharia de Software Magazine
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.

ÍNDICE

Agilidade
06 - Requisitos para agilidade no desenvolvimento de software
Flavio S. Mariotti

13 - Scrum e o gerenciamento de projetos – Parte 3
Fábio Cruz

Engenharia Aplicada
20 - Estimativas de tamanho em projetos de software utilizando pontos de função
Jhoney da Silva Lopes e José Luis Braga

Engenharia Fundamentos
32 - CMMI – Uma visão Geral
Lenildo Morais

36 - Gerenciando mudanças a partir de requisitos
José Alberto Zimermann, Thiago Carvalho de Sousa e Rodrigo Oliveira Spínola

Arquitetura e Desenvolvimento
42 - Introdução ao desenvolvimento de aplicações de realidade aumentada
André Luis Tosato, Victor Angelo Marcorin, Thiago Salhab Alves e Paulo Barreto da Silva

47 - Boas práticas para escrita de métodos, funções e procedimentos – Parte 6
Jacimar Fernandes Tavares e Marco Antônio Pereira Araújo

Edição 05 - Engenharia de Software Magazine 5

Agilidade

Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

Requisitos para agilidade no
desenvolvimento de software
Necessidades requeridas para equipe, programas e empresa

individuais, com a adoção de alguns métodos como
De que se trata o artigo?
XP, Scrum, Lean entre outros. No entanto, esses
Este artigo apresenta uma proposta sobre níveis
métodos começaram a se espalhar para o nível das
de requisitos ágeis, práticas correspondentes aos
empresas e uma série de fatores começaram a exigir
papéis sugeridos e um modelo organizacional que
um escopo organizacional mais amplo para suportar
proporciona um formato de empresa ágil. O objetivo
os desafios da governança desses novos processos.
é escrever os requisitos que se fazem necessários para
Neste sentido, o objetivo do artigo é fornecer um
a criação de uma equipe ágil, programas que ofereçam
modelo que ajude a obter uma visão elevada do
suporte ao primeiro nível e a fase e maturidade da
conceito ágil e seus requisitos para maturidade de
empresa ágil.
uma empresa ágil.
Em que situação o tema é útil?
Na última década, a criação de modelos de engenharia Resumo DevMan
de software cada vez mais ágeis foi a mudança mais Este artigo discute o tema requisitos para agilidade
significativa que afetou as empresas de software no desenvolvimento de software. Para isso, será
desde o advento do modelo em cascata na década de apresentado, sob diferentes perspectivas, como
1970. Nos últimos cincos anos, as metodologias ágeis a questão da agilidade pode ser considerada em
começaram a se espalhar nas empresas de software. equipes de projetos de software que trabalhem
As iniciativas geralmente começaram com equipes considerando os princípios da agilidade.

O
desenvolvimento de software TI, vêm disponibilizando diversas meto-
Flavio S. Mariotti se tornou um dos fatores mais dologias para apoiar essa difícil tarefa de
flaviomariotti@gmail.com
importantes da tecnologia. desenvolvimento de software, tais como:
Especialista em Engenharia e Arquitetura
de Software. Pós Graduado pelo Instituto O software que é produzido hoje se tor- modelo cascata, espiral, RAD, RUP,
de Pesquisa Avançada de Tecnologia IBTA na rapidamente um item fundamental Crystal, Scrum (ler Nota Devman 1),
em Engenharia de Software baseado em para organizações e usuários finais no XP (ler Nota Devman 2), FDD (ler Nota
SOA. Bacharel em Sistemas de Informação intuito de acelerar e auxiliar a execução Devman 3), Lean, DSDM entre outros.
pela UNIUBE e técnico em Processamento
de diferentes tarefas. Com a evolução rápida dos recursos
de Dados pela FEB. Consultor independente
no desenvolvimento de software em Nos últimos 50 anos diferentes grupos, computacionais, o escopo do software se
arquitetura OO, SOA, GIS e Plataforma .NET. especialistas e pesquisadores da área de altera com a mesma velocidade, exigindo

6 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software

agilidade

como um dos principais itens do desenvolvimento de software suporte aos processos, como distribuir a responsabilidade
a agilidade na produção. Porém, como criar produtos com me- de cada envolvido no processo e qual a importância dessa
nos tempo e com a mesma eficiência? São dúvidas como essas distribuição.
que vem transformando nossas metodologias na tentativa de
alcançar o melhor e mais ágil modelo de desenvolvimento de Requisitos ágeis para a equipe
software. É importante ressaltar que o modelo de equipe que será
Contudo, será que somente uma boa metodologia é o sufi- apresentado neste artigo tem como principal propósito au-
ciente para apoiar essa difícil missão? A resposta certamente é xiliar o time de desenvolvimento a se organizar ao definir
NÃO. Para se obter agilidade no processo de desenvolvimento papéis, distribuir responsabilidades e criar as atividades para
de software é preciso aplicar o conceito nos três pilares que um projeto no modelo ágil. Sendo assim, é de total valia usar
fazem parte deste trabalho, que são: equipe, programas e em- esses conceitos para modelar e adequar a sua equipe na sua
presa. Esse é o principal objetivo deste artigo, proporcionar realidade.
ao leitor uma breve abordagem do que se faz necessário para Sabemos que um dos grandes desafios é fazer com que a
atingir a agilidade no desenvolvimento de software, quais os equipe incorpore o modelo ágil para contribuir ao máximo
requisitos para criar um time ágil, quais os pilares e processos com o time. Recomendo aos interessados pela teoria da lide-
que envolvem esse trabalho, qual o papel da empresa para dar rança de pessoas dar uma no lida modelo Tuckman’s stages of
group development proposto pelo psicólogo americano Bruce
Wayne Tuckman.

Nota do DevMan 1 Funções e responsabilidades da equipe
Ao estudar e analisar diversos modelos organizacionais de
Scrum: Scrum é um framework para gerenciamento de projetos ágeis muito uma equipe ágil proposta em diferentes metodologias como
utilizado na área de desenvolvimento de software. Uma das principais características XP, Scrum, Lean, entre outros, chega-se à conclusão de que a
do Scrum é permitir o desenvolvimento de produtos complexos de uma forma estrutura organizacional de uma equipe ágil é basicamente a
incremental e iterativa, contribuindo para decompor um grande produto complexo, mesma em todas metodologias.
em pequenos subprodutos mais simples, mais rápidos e mais fáceis de serem O Scrum, por exemplo, propõe um modelo que se divide em
desenvolvidos e entregues. No Scrum estas iterações são chamadas de Sprints, e uma três principais funções, são eles: Scrum Master (Responsável
característica marcante de sua estrutura e aplicação é o controle sobre os trabalhos Ágil), Product Owner (Proprietário do Produto) e o resto da
realizados, e a possibilidade de correção e adaptação rápida, permitindo que a equipe
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 3
FDD: O FDD é uma metodologia que serve tanto para o gerenciamento de projetos
quanto para a Engenharia de Software. Isto a torna mais complexa quando comparada
Nota do DevMan 2 com outras metodologias ágeis. Por exemplo, o RUP (Rational Unified Process) da IBM,
uma metodologia considerada tradicional, trata o gerenciamento de projetos como
XP: O eXtreme Programming ou XP é um modelo ágil de desenvolvimento de uma disciplina dentro do seu framework, já que o seu foco está na Engenharia de
software criado em 1996 por Kent Bech no Departamento de Computação da Software em si. Já o SCRUM, tem no papel do Scrum Master, uma figura parecida com
montadora de carros Daimler Chrysler. Ele possui muitas diferenças em relação a de um Gerente de Projetos formal, mas que tem seu foco na facilitação dos trabalhos
a outros modelos, podendo ser aplicado a projetos de alto risco e com requisitos por parte da equipe técnica. O foco dessa metodologia está na auto-organização da
dinâmicos (vagos ou em constante mudança), conduzidos por equipes de tamanho equipe e, para isso, são necessários analistas seniores.
médio e pequeno.
O ponto forte da metodologia FDD está na capacidade de realizar features. Para esta
Como todo método ágil, o XP procura responder com velocidade às mudanças nas metodologia, uma pequena feature possui um alto valor para o cliente. O exemplo de
especificações do projeto, com base em princípios, valores e práticas bem definidos. uma feature está em um caso de uso com a função de “calcular a média de salário dos
Este método enfatiza o desenvolvimento rápido garantindo a satisfação do cliente gestores” ou de “realizar um relatório integrado de vendas” e assim por diante. Veja
,
e cumprindo as estimativas do projeto. O XP baseia-se em cinco valores para guiar que não é estranha a menção do termo “caso de uso” para exemplificar uma feature,
o desenvolvimento: Comunicação, Coragem, Feedback, Respeito e Simplicidade. já que a ideia é similar. Essa descrição do requisito que o FDD chama de feature são
Segundo Beck, o método oferece ainda 12 práticas, a saber: i) Jogo do planejamento; os casos de uso no RUP e as estórias utilizadas no XP. O site www.agilemodeling.
ii) Versões pequenas; iii) Metáfora; iv) Projeto simples; v) Teste; vi) Refatoração; vii) com/essays/fdd.htm destaca que uma lista de features é inicialmente indicada para
Programação em pares; viii) Propriedade coletiva do código; ix) Integração contínua; que seja elaborado o planejamento do projeto com estimativas de esforço para sua
x) 40 horas de trabalho semanal; xi) Cliente presente; e xii) Padrões de codificação. execução. Basicamente, esta é a proposta do FDD.


equipe que consiste principalmente de desenvolvedores e na equipe e se torna a metodologia do time, as regras são
testadores de software. auto-impostas, fazendo com que a participação do Responsável
Ágil se torne menos frequente e necessária. Resumidamente,
Composição da equipe ágil as responsabilidades desta função se dividem em:
A Figura 1 representa de forma gráfica o modelo organiza- • Facilitar o progresso da equipe em direção à meta;
cional de uma equipe ágil. Na sequência conheremos cada • Liderar os esforços da equipe e buscar a melhoria
um desses papéis. contínua;
• Fazer cumprir as regras do processo ágil;
• Eliminar obstáculos.

Desenvolvedores e Testadores
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
Figura 1. Ilustração do nível de equipes o modelo de programação em par com outro desenvolvedor,
ou também emparelhado com um testador ou outro modelo
Proprietário do produto ágil, de forma a operar mais independente e ter interfaces com
Como já definido no Scrum, o proprietário do produto tem múltiplos testadores e desenvolvedores. Contudo, a responsa-
como característica atuar como a única função arbitrária, ou bilidade desta função é basicamente a mesma, são elas:
seja, esse papel é responsável por determinar e priorizar as • Codificar os requisitos;
necessidades dos utilizadores e gerenciar os itens acumulados • Colaborar com os testadores e proprietários do produto
(product backlog). É importante lembrar que esse artigo não garantindo a codificação do produto de forma padronizada
descreve Scrum como metodologia a ser seguida. Indepen- conforme definição da equipe;
dente da metodologia que sua equipe adotou como ágil, é • Codificar e executar as unit test;
recomendada a aplicação da função proprietário do produto, • Garantir o check-in e check-out do código feito diariamente;
já que esse papel vem mostrando verdadeiros avanços na • Participar ativamente na melhoria do ambiente de
simplificação do trabalho exercido pela equipe. desenvolvimento.
Contudo, as responsabilidades do proprietário do produ-
to são ainda maiores. Segundo o princípio Agile Manisfesto Testadores
#4 - “Homens de negócio e desenvolvedores devem trabalharem Os testadores são parte fundamental e integrante da equipe
juntos diariamente durante o andamento do projeto”. Com base ágil. Os testadores estarão presentes logo no primeiro código a
nesse princípio, o proprietário do produto é a função ideal ser liberado, e se faz necessário passar pela aplicação de testes
para orientar a equipe e participar diariamente com a mesma e aprovação do time de testadores. A principal responsabilida-
em suas atividades no intuito de direcionar e definir suas de atribuída a essa função é a liberação do código fonte para
prioridades. produção ou continuidade do fluxo de trabalho. É de extrema
Podemos dizer então que o proprietário do produto é o prin- importância o cumprimento desse requisito para se obter
cipal responsável pela definição e priorização de requisitos. qualidade e agilidade no desenvolvimento de software. Outras
Portanto, a função proprietário do produto é responsável pelas responsabilidades atribuídas a essa função são:
seguintes atribuições: • Criar casos de testes e aprovação;
• Trabalhar com todos stakeholders (gerentes, analistas, clientes • Interface com os desenvolvedores e proprietário do produto
e interessados) do projeto para determinar os requisitos; para garantir e certificar o entendimento das funcionalidades
• Priorizar as atividades com base no valor relativo do requeridas;
cliente; • Executar os testes de aprovação;
• Definir motivos para iteração, atuar e elaborar relatórios, • Desenvolver teste de aprovação para a atualização de com-
participar e revisar processos buscando melhoria contínua. ponentes no ambiente de produção.

Responsável Ágil Especialistas
O responsável ágil é geralmente o papel do líder do projeto. Não podemos deixar de ressaltar a importância de recursos
Essa função tem como responsabilidade dirigir o time para compartilhados e interfaces para outras funções. Segundo o
alcançar suas metas e, em alguns projetos, é importante so- princípio Agile Manifesto #11 - “As melhores arquiteturas, requisitos e
mente na fase de transição. Quando o modelo ágil é imposto projetos emergentes de equipe auto-organizadas.”. Assim sendo, se faz


agilidade

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


• contrato é o suficiente; das necessidades da equipe de recursos. No caso do Scrum, o
• Finaliza o desenvolvimento da camada sem um produto proprietário do produto irá auxiliar a equipe de componente
potencialmente utilizável. 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
Figura 2. Ilustração de arquitetura de projeto decisão, é necessário compreender a fundo as vantagens e
desvantagens das equipes descritas acima para uma escolha
A proposta da equipe de recursos seria, em vez de ter equipes apropriada.
separadas por camadas da arquitetura, termos as equipes de Nas grandes empresas, onde há diversas equipes, recursos
recursos trabalhando em todas as camadas. e sistemas que em algumas vezes são compostos por siste-
Algumas vantagens podem ser obtidas neste modelo orga- mas ou componentes, o modelo de equipes provavelmente
nizacional, são elas: será uma mistura entre equipes de recursos e equipes de
• As equipes de recursos têm mais habilidades para avaliar componentes.
o impacto das decisões de projetos. Essa habilidade é adquira É recomendado uma certa inclinação para as equipes de re-
pelo fato do time construir a funcionalidade de ponta a ponta, cursos. Alguns especialistas acreditam que uma boa estratégia
isso maximiza o aprendizado dos membros auxiliando nas para empresa ágil é permanecer no 70%-30% ou 80%-20% de
decisões que se fazem necessárias para o projeto; equipes de recursos para equipes de componentes. O espe-
• Reduz o desperdício de esforços da equipe, ou seja, o risco de cialista em projetos ágeis, Chad Holdor, ou como ele gosta de
criar funcionalidade demasiada é consideravelmente menor; ser chamado, o Agile Ninja, publicou um vídeo em seu blog
• Garante que as pessoas certas estão falando, ou seja, uma detalhando claramente as diferenças entre equipes de recursos
equipe de recursos inclui todas as habilidades necessárias para e equipes de componentes e no final recomenda um modelo
ir da idéia a execução do recurso; ágil combinando membros da equipe de componentes para
• Diminui o risco de integração do componente com os re- fazer a equipe ágil como ilustrado na Figura 3. Esse vídeo pode
cursos, ou seja, um componente desenvolvido pela equipe ser encontrado no endereço: http://www.scaledagiledelivery.
de componente só tem valor depois de integrado ao produto com/2011/04/28/component-vs-feature-team/.
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 Figura 3. Combinando membros da equipe de componentes para fazer a
cliente. Um exemplo seria uma equipe de componente desen- equipe de recursos
volvendo uma camada de mapeamento entre a aplicação e o
banco de dados. A equipe de sistemas
O gerenciamento de equipe de componentes nem sempre Como visto, as equipes ágeis são os motores de produção
é uma tarefa fácil. Geralmente as equipes de componentes de um software. Aprendemos que cada equipe precisa ter
trabalham paralelas às equipes de recursos. É importante habilidades necessárias para especificar, projetar, codificar e
garantir que a equipe de componentes tenha conhecimento testar os componentes e recursos de seu domínio.


agilidade

No entanto, no nível de programa, essas equipes formadas backlog do programa como recursos normais, ou seja, usando
por pessoas podem não ter todas as características necessárias o mesmo conceito de histórias de usuários. Alguns exemplos
para concluir uma solução completa. Com isso, às vezes se faz de como esses requisitos podem ser solicitados são:
necessário adicionar uma equipe que complemente as equipes • O cliente solicita que o aplicativo funcione nos principais
de recurso ou componentes. Essas equipes são formadas de navegadores do mercado;
sistemas que podem auxiliar nos testes de sistemas, sistema • O cliente exige que uma determinada funcionalidade seja
de garantia da qualidade, sistema de integração, suporte na executada em no máximo 30 segundos;
infraestrutura de desenvolvimento e etc. • O cliente solicita disponibilidade de 99,99% do sistema.

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; Figura 4. Ilustração básica de uma planilha de roteiros
• Proprietário e gerente do produto;
• Representantes de marketing; Teste de requisitos não-funcionais
• Gerentes associados aos produtos; Requisitos não-funcionais, como desempenho, disponibilida-
• Equipe de implantação do produto. de e outros do gênero, são frequentemente descritos pelo cliente
como qualidade do produto, porém devem ser aplicados no
É recomendado que essa equipe faça reuniões semanalmen- backlog como um histórico de usuário e tratado como recurso,
te ou em um período adequado à importância do produto. assim aplicando os testes para sua qualidade. A Figura 5 ilustra
A reunião tem como principal foco debater a situação do um modelo simples para aplicação de testes de qualidade nos
produto, tais como: status; onde estamos; se vamos cumprir requisitos não-funcionais.
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 Figura 5. Modelo básico de teste de requisitos não-funcionais
liberação do produto.
Geralmente a maior parte dos requisitos não-funcionais (0..*)
Roteiro ou Roadmap requerem um ou mais testes. Neste cenário, pode ser aplicado
A equipe de gerenciamento e liberação no final de cada fórum outro tipo de testes de aceitação. Aplica-se então os testes
resulta nos dados do planejamento da versão que são usados de qualidade de sistemas. Este termo indica que estes testes
para atualizar a planilha de roadmap. devem ser executados em intervalos periódicos no intuito de
O roteiro deve ser composto com as datas planejadas para validar o sistema.
os lançamentos de cada solução, cada qual com o consultor de
recursos priorizando conforme a necessidade do negócio. A Requisitos ágeis para a empresa
Figura 4 representa o modelo de um roadmap. O terceiro e último requisito ágil que será apresentado neste
O roteiro está sujeito a alterações em qualquer fase do pro- artigo é o nível empresa ou portfólio. Nesta etapa, encontramos
duto, essas alterações podem ser causadas por questões como: a função de gestão de portfólio que inclui equipes e organiza-
prioridade de negócio, fatores técnicos entre outros fatores ções dedicadas à gestão dos investimentos e conformidades
imprevisíveis, portanto, não se deve fazer compromissos ex- com a estratégia de negócio da organização.
ternos com planos além do próximo lançamento. Para muitas fábricas de software atualmente, independente
do tamanho de seus projetos ou equipes, o modelo de equi-
Requisitos não-funcionais pes junto ao modelo de programas podem ser o suficiente
A visão também precisa conter os requisitos não-funcionais, para gerenciar seus projetos de forma ágil. No entanto, para
tais como: confiabilidade, desempenho, qualidade, compatibili- empresas que contém muitos produtos em que a governança
dade e etc. Os requisitos não-funcionais devem ser descritos no e o modelo de gestão para o desenvolvimento de novos ativos


de software exige novos artefatos e níveis ainda mais altos de É importante que essa administração ocorra de forma contí-
abstração, a inclusão do modelo de portfólio pode ajudar no nua em cada um dos níveis apresentados.
gerenciamento desses novos desafios.
Conclusão
Requisitos de investimento É importante ressaltar que o modelo com níveis de equipes,
Um conjunto de temas de investimento estabelece os objetivos programas e empresas apresentados neste artigo é uma de-
de investimento em relação à empresa ou unidade de negócio. finição arbitrária. Portanto, o objetivo é fornecer um modelo
Este tema é o item que representa uma série de iniciativas que mental que ajude a elevar o alcance de abstração e escala para
impulsionam os investimentos da empresa para determinada se obter agilidade no desenvolvimento de software.
solução, produto ou serviço. Em resumo, vimos um conjunto de requisitos que são otimizados
para apoiar a entrega rápida das necessidades valiosas do cliente.
Equipe de gestão de portfólio Também vimos como as equipes ágeis podem alcançar a qualidade
A equipe de portfólio pode ser formada pelos gerentes ou mais alta através de testes funcionais e automação de teste.
responsáveis pelo negócio. Os membros desta equipe são os No nível de programa, foram apresentados requisitos, artefatos
indivíduos que tem a responsabilidade final com as linhas de e processos que são necessários para alcançar o desenvolvimento
negócio. Em algumas empresas, esse processo pode ser com- ágil. Foi apresentado um modelo organizacional para auxiliar na
parado aos processos de elaboração orçamentária anual. montagem de equipes otimizadas para a entrega ágil de valor.
A equipe de gestão de carteira/portfólio toma suas decisões E, para concluir, introduzimos o nível de empresa. Nesta
com base em uma combinação das seguintes opções: fase foi apresentada de forma resumida uma abordagem sobre
• Investimento em ofertas de produtos, melhorias, suporte e os temas de investimento estratégico, gestão de portfólio e
manutenção; arquitetura de melhoria contínua.
• Investimento em novos produtos, novos serviços ou trabalho
Links
comercial para ganhar novas fatias de mercado;
• Reduzir investimento para as ofertas existentes que estão Mike Cohn’s blog Succeeding with agile
http://www.mountaingoatsoftware.com/
chegando ao fim de sua vida útil ou lucrativa.
Chad Holdorf’s blog
Para fornecer governança e visibilidade nesta fase de investi- http://www.scaledagiledelivery.com/
mentos, a equipe de gerenciamento de portfólio pode ser diri-
Dean Leffingwell, Agile Software Requirements: Lean Requirements Practices for Teams,
gida pelas melhores práticas de um modelo de gerenciamento
Programs, and the Enterprise, Addison-Wesley Professional, 2010.
de projetos como PMO.
Craig Larman; Bas Vodde, Scanling Lean & Agile Development, Addison-Wesly Professional, 2008
Arquitetura: empresa, programa e equipe
Chris Sterling; Brent Barton, Managing Software Debt: Building for Inevitable Change, Addison-
Ao obter maturidade ágil a organização tende a continuar a
Professional, 2010.
construção e conservação de uma arquitetura de responsabili-
dade eficaz. Ao administrar e gerenciar esses níveis de requi- Mike Cohn, Succeeding with Agile: Software Development Using Scrum, Addison-Wesley
sitos que resultam em agilidade, a empresa pode evitar alguns Professional, 2009
acontecimentos ruins, porém comuns, como por exemplo:
Dê seu feedback sobre esta edição! Feedback
• Atrasos consideráveis para o lançamento do produto; eu
s
Dê

• Redução do risco de criar uma arquitetura sem capacidade A Engenharia de Software Magazine tem que ser feita ao seu gosto. sobre e
de se estender, deixando o sistema frágil e instável a mudanças, Para isso, precisamos saber o que você, leitor, acha da revista!
correndo o risco de ser totalmente reescrito;
s

ta
edição
Dê seu voto sobre este artigo, através do link:
• Evita o desperdício de esforços no desenvolvimento e maus
investimentos. www.devmedia.com.br/esmag/feedback


Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros

Scrum e o gerenciamento de projetos – Parte 3
O Scrum e a sua relação de aliança com o gerenciamento de projetos tradicional

De que se trata o artigo? informação através da união de artefatos de origem
Demonstrar como utilizar os artefatos de um geren- ágil com outros de origem tradicional, fornecendo
ciamento ágil como o Scrum, suportando e dando reflexões e provocando ações para unir as duas abor-
apoio aos artefatos também complementares do dagens em um mesmo projeto.
gerenciamento tradicional, apresentando como esta
união pode ser benéfica para um mesmo projeto, Resumo
principalmente na área de gerenciamento das co- Para se gerenciar projetos de desenvolvimento de
municações, proporcionando um acompanhamento softwares é preciso estar constantemente atuali-
transparente e bem próximo da execução do projeto. zado com as informações do projeto, e ao mesmo
tempo comunicar a todos os interessados com a
Em que situação o tema é útil? frequência necessária. Este artigo mostra como
Este artigo visa demonstrar como resolver problemas aliar os artefatos de uma abordagem ágil como o
gerados por falhas de comunicação entre a equipe do Scrum ao gerenciamento de projetos tradicional,
projeto, sua gerência sênior e o cliente, apresentando gerando benefícios e melhorando a comunicação
formas de eliminar os buracos causados pela falta de do projeto em várias direções.

I
ndependente do método utilizado Entende-se gerência sênior, neste caso,
Fábio Cruz para executar e gerenciar projetos, a como o patrocinador do projeto (Sponsor)
fabiorcruz@gmail.com comunicação continua sendo a área e as demais gerências compostas pelo
Graduado na área de TI e PMP certifica- mais importante quando se fala do su- corpo diretivo responsável pelo projeto,
do com mais de 17 anos de experiência
profissional, atuando sempre na área de
cesso em projetos. Simplesmente porque tanto na empresa executora quanto na
desenvolvimento de sistemas, sendo os úl- a comunicação precisa acontecer para empresa contratante.
timos 10 dedicados à liderança de equipes que o projeto seja entendido, executado Esta comunicação tem o objetivo
e à coordenação de projetos. Atualmente e entregue. principal de posicionar e informar.
gerente de projetos na empresa americana Outro objetivo fundamental da comu- Normalmente estes posicionamentos
Ascendant Technology, voluntário no PMI
Chapter de Santa Catarina e autor do blog
nicação é manter a gerência sênior das são requisitados periodicamente e
www.fabiocruz.com especializado em ge- empresas envolvidas com o projeto in- geralmente incluem análises de valor
renciamento de projetos. formadas sobre o andamento do mesmo. agregado, marcos principais (milestones),


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

14 Engenharia de Software Magazine - Scrum e o gerenciamento de projetos – Parte 3

Gerenciamento d e Projetos

partes interessadas (stakeholders) pelo projeto, e geralmente monitoramento, usaremos apenas a estória que definiremos
fazem parte do que será comunicado durante o projeto. a partir do seguinte padrão:
O plano de projeto pode conter, inclusive, informações “Como um <tipo de usuário>, eu quero <um objetivo> para
pertinentes de como as metodologias de gerenciamento de que <atenda uma necessidade>”.
projetos serão aplicadas e como funcionarão conjuntamente Pegando o nosso item de Backlog “cadastro de livros” e criando
ao longo do ciclo de vida do projeto. Já o plano de comu- uma estória com o padrão apresentado, teremos o seguinte:
nicação deverá informar quais artefatos serão utilizados, “Como um usuário administrador, eu quero cadastrar um livro
quais suas finalidades e origens conceituais (Scrum ou para que ele possa ser consultado por visitantes na internet”.
tradicional). Como pode ser observado, é possível resumir todas as necessi-
A partir destes documentos elaborados e divulgados corre- dades em poucas palavras, permitindo que seja possível colocar
tamente, todos os responsáveis ou interessados ligados dire- este texto em um post-it conforme ilustrado na Figura 1.
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.
Figura 1. Estórias em post-its

Artefatos do Scrum A partir das estórias definidas, o time poderá trabalhar
O primeiro dos artefatos importantes do Scrum é o Backlog na reunião de planejamento da Sprint. Lembrando que esta
do Produto, que é o conjunto de todos os requisitos e trabalhos cerimônia é parte integrante do Scrum e foi descrita em mais
necessários para entregar o projeto. Este artefato pode incluir detalhes na Engenharia de Software Magazine 43.
regras de negócios, protótipos de tela, casos de uso, entre
outros documentos relevantes. Tarefas
Partindo de um Backlog do Produto completo para o projeto, Na primeira parte desta reunião de planejamento, o time
ou para uma versão de entrega (release), se consegue obter os pró- entende as estórias e determina o tamanho de cada uma. Esta
ximos e mais detalhados documentos que fornecerão os dados estimativa servirá como artefato para medir o desempenho
importantes para que as comunicações do projeto aconteçam. dos trabalhos no futuro. Já na segunda parte, o time detalha
O Backlog do Produto se transforma no Backlog da Sprint, melhor as estórias, decompondo-as em tarefas menores.
que deverá conter apenas os trabalhos selecionados para se Estas tarefas devem ter um tamanho apropriado para que
entregar na próxima Sprint. A partir desta seleção de itens do possam ser determinadas em horas para conclusão, e devem
Backlog, a equipe poderá ser apresentada a outro artefato do ser independentes de outras atividades para que sejam consi-
Scrum, as estórias dos usuários. deradas finalizadas.
Falamos mais sobre Backlog do Produto na edição 43 da O resultado desta decomposição das estórias em tarefas
Engenharia de Software Magazine. menores será um dos mais importantes artefatos de controle
que usaremos ao longo do projeto, pois estas tarefas menores
Estórias do usuário serão utilizadas para que toda a equipe do projeto saiba o que
Uma estória do usuário (user story) é uma descrição resumida precisa ser realizado, o que está sendo trabalhado e o que já
que representa um item do Backlog, devendo ser sempre do foi concluído.
ponto de vista do usuário final do produto. Em alguns casos um Uma estória é uma macro atividade, que resume um conjunto
item de Backlog poderá dar origem a mais de uma estória, por de trabalhos. Este conjunto de trabalhos poderá ser ilustrado
questões de entendimento, ou para uma melhor visualização ou através de várias tarefas associadas, que por sua vez vão com-
até por uma estratégia de abordagem gerencial e de execução. por a estória, como ilustrado na Figura 2.
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 Figura 2. Decomposição da estória em tarefas


Estamos falando destes dois artefatos porque precisamos • Laranja: Tarefas planejadas;
de dados para acompanhamento e monitoramento do projeto • Verde: Tarefas não planejadas;
conforme ele é executado, além de contribuir para o forne- • Vermelho: Impedimento, ou seja, obstáculo que está impe-
cimento de informações consolidadas e atualizadas o mais dindo a realização de uma tarefa. Geralmente colocado sobre
breve possível. Com isso, começamos a colocar em prática a a tarefa impedida;
comunicação do projeto durante a execução. • Amarelo: Tarefas de teste.

Quadro de Tarefas (Taskboard) Com este quadro montado, a comunicação do projeto começa
Este é um dos artefatos fundamentais e característicos do a tomar uma forma naturalmente clara, objetiva e transparente.
Scrum, e possivelmente o que mais contribui para a comuni- Note que o quadro de tarefas ilustrado na Figura 3 pode ser
cação do projeto e colaboração do time. físico, e com isso fixado em uma parede bem visível para todos
O quadro de tarefas nada mais é do que um espaço reserva- os interessados nas informações ali contidas.
do para se colar ou fixar os post-its com as estórias e tarefas, Qualquer um que direcionar os olhares para o taskboard verá
separados por colunas e cores diferentes que proporcionam rapidamente um conjunto de informações condensadas em um
uma rápida identificação da atividade e sua situação, conforme único local, tais como:
ilustrada na Figura 3. 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
Figura 3. Quadro de tarefas do Scrum o planejado, pois de acordo com a regra do Scrum, somente
depois de todas as tarefas da primeira linha estarem na coluna
O formato mais utilizado para montar o quadro de tarefa é: “feito”, é que podem ser iniciadas as tarefas da segunda linha.
• Coluna 1: As estórias são colocadas uma embaixo da outra, Neste caso, pode se tomar providências ao perceber um item
na sequência da mais importante para a menos importante sendo realizado fora de prioridade.
de cima para baixo;
• Coluna 2: As tarefas “a fazer” ao lado direito da sua respec- Este quadro de tarefas também pode ser virtual, a partir da
tiva estória; utilização de softwares de gerenciamento ágil de projetos que
• Coluna 3: As tarefas que o time “está fazendo”, também ao permitem o cadastramento, acompanhamento e divulgação
lado da sua respectiva estória; completa do taskboard. Um exemplo de uma ferramenta com
• Coluna 4: As tarefas já concluídas (“feito”), na última coluna estas funções é o Rational Team Concert (RTC), que permite
à direita, também seguindo a mesma linha da sua respectiva o cadastro de projetos, de times, de Backlogs, de estórias e de
estória; tarefas, além do acompanhamento da taskboard e do gráfico
• Colunas complementares: Após a quarta coluna pode haver de Burndown.
a coluna “não planejados”, para o agrupamento de tarefas não Outro detalhe importante sobre o taskboard é que os próprios
previstas e que surjam ao longo do desenvolvimento, e/ou integrantes do time mantêm as tarefas atualizadas no quadro
colunas antes da “feito”, para separação de itens na etapa de pelo menos uma vez por dia, com influência principalmente da
“testes”, por exemplo. cerimônia conhecida como reunião diária, que pode ser vista em
maiores detalhes na segunda parte desta série de artigos.
Além das colunas distintas para cada etapa do desenvolvi-
mento, também é sugerido que as tarefas sejam colocadas em Gráfico de Burndown
post-its menores que as estórias e que seja adotada uma cor A Sprint é a principal iteração no Scrum, e ela nos ajuda a di-
diferente para cada tipo de tarefa, por exemplo: mensionar os trabalhos e controlar o projeto em ciclos menores



de até um mês. Maiores detalhes sobre as Sprints podem ser en- 4. Ao final de cada dia da Sprint, ou no máximo no início de
contrados na Edição 42 da Engenharia de Software Magazine. cada dia, marque no quadro a quantidade de trabalho restante
A Sprint contém um conjunto de trabalhos a ser realizado em na coluna referente ao dia específico;
um determinado espaço de tempo, por isso ela é muito útil para 5. Trace uma nova reta ligando os pontos marcados com o total
acompanhar a evolução do projeto. Porém, como fazer este acom- de trabalho restante a cada dia. Pronto, você terá a velocidade
panhamento e saber se o projeto está atrasado ou adiantado? real do time.
A resposta não é tão difícil quanto parece, principalmente
depois de termos falado sobre o Backlog da Sprint, estórias Na ilustração da Figura 4, a linha vermelha representa a
e tarefas. estimativa dos trabalhos a serem completados por dia, ou seja,
Todas as tarefas que precisam ser realizadas dentro da Sprint a velocidade esperada marcada no início da Sprint.
estão no taskboard, no entanto apenas olhar para o quadro de tare- A linha azul mostra a velocidade real do time de acordo com
fas não diz a equipe de gerenciamento se o projeto está em dia ou os trabalhos que estão sendo completados a cada dia. Caso a
não. Para resolver este problema entra em ação o último artefato linha azul (real) esteja acima da linha vermelha (estimada), a
do Scrum que nos interessa aqui, o gráfico de Burndown. Sprint está atrasada, caso contrário, está adiantada.
O Scrum como abordagem ágil se preocupa com o esforço Para a opção do quadro físico fixado em uma parede, o time
restante para se terminar o trabalho, e não com o que já foi do projeto pode atualizar as tarefas antes ou durante as reu-
concluído. Em outras palavras, o que importa no controle niões diárias, que é a melhor opção.
do Scrum é a quantidade de tarefas que ainda precisam ser Para a opção de taskboards virtuais através de softwares, opte
completadas até o final da Sprint. por ferramentas que se integrem com os ambientes de desenvol-
O gráfico de Burndown representa visualmente a soma vimento e já atualizem automaticamente as tarefas em tempo
das estimativas dos esforços restantes para se terminar os real. Por exemplo, quando um desenvolvedor encerra uma tarefa
trabalhos contidos no Backlog da Sprint. Por isso, olhando o pela ferramenta de desenvolvimento, esta por sua vez atualiza
gráfico ilustrado na Figura 4, temos à esquerda uma coluna o software que mantém a taskboard também atualizada.
com a quantidade de trabalho que precisa ser completada,
sendo que no primeiro dia da Sprint o trabalho restante será Comunicação visual
igual ao trabalho total. 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
Figura 4. Gráfico de Burndown. este modelo de trabalho se torna tão interessante.
Os problemas e falhas realmente ficarão evidenciados, se
Os dias estão na linha inferior do gráfico, e o acompanhamen- tornando um problema para os times que não buscam melhorar
to é simples. Em resumo, o dia atual deve ter menos trabalho e corrigir seus defeitos. Para os demais, os resultados serão os
restante do que o dia anterior. Visualmente podemos fazer uma melhores possíveis, porque a própria equipe buscará a cada
comparação fácil que nos ajudará muito na identificação da iteração (Sprint) melhorar os seus resultados.
evolução dos trabalhos, permitindo saber se estão adiantados Os bons times buscarão transformar o taskboard em uma
ou atrasados, da seguinte forma: evidência de seu bom trabalho, e não em um problema que
1. No primeiro dia da Sprint, monte o gráfico colocando na mostra para todos os seus erros. Esta qualidade que o Scrum
coluna da esquerda a quantidade de trabalho necessário para proporciona pode ser entendida como um processo de me-
completar a Sprint; lhoria contínua.
2. Na linha inferior coloque os dias em que a Sprint ocorrerá;
3. Por fim, trace uma linha ligando o total de trabalhos que Comunicação formal
precisam ser completados (coluna à esquerda) ao último dia da Com os trabalhos sendo realizados conforme as definições
Sprint (à direita). Esta linha representará a velocidade média do tradicional plano de gerenciamento do projeto e seguindo
do time para atingir a meta da Sprint; as cerimônias, regras e artefatos do Scrum descritos até agora,


Figura 5. Cronograma com milestones

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



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

Os artefatos deste gerenciamento ágil também fornecem A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e

informações sobre velocidade e tamanho da equipe, riscos Para isso, precisamos saber o que você, leitor, acha da revista!
s

ta
evidentes através de impedimentos ou obstáculos aos traba- Dê seu voto sobre este artigo, através do link:
edição

lhos do time, além da situação atual do projeto, mostrando a
evolução de tarefas completadas. www.devmedia.com.br/esmag/feedback


APF Estimativas

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à APF Estimativas

Similaire à APF Estimativas (20)

Plus de Carlos Antonio Castro Oliveira

Plus de Carlos Antonio Castro Oliveira (6)

APF Estimativas