SlideShare uma empresa Scribd logo
1 de 54
Baixar para ler offline
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.




                                                                                                                   Edição 44 - Engenharia de Software Magazine                   7
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


8   Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
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


                                                                                       Edição 44 - Engenharia de Software Magazine   9
• 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.


10    Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
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


                                                                                   Edição 44 - Engenharia de Software Magazine    11
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




12   Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
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),


                                                                                                        Edição 44 - Engenharia de Software Magazine                13
ú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


                                                                                     Edição 44 - Engenharia de Software Magazine   15
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


16   Engenharia de Software Magazine - Scrum e o gerenciamento de projetos – Parte 3
Gerenciamento d e Projetos



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,


                                                                                   Edição 44 - Engenharia de Software Magazine   17
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 in-                  do 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.


18   Engenharia de Software Magazine - Scrum e o gerenciamento de projetos – Parte 3
Gerenciamento d e Projetos



  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




                                                                                        Edição 44 - Engenharia de Software Magazine                  19
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas
APF Estimativas

Mais conteúdo relacionado

Mais procurados

Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De SoftwareFelipe Goulart
 
Engenharia de Software - Wikipedia
Engenharia de Software - WikipediaEngenharia de Software - Wikipedia
Engenharia de Software - WikipediaRobson Silva Espig
 
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Sérgio Souza Costa
 
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1Renato Leal
 
Uma Introdução a Engenharia de Software
Uma Introdução a Engenharia de SoftwareUma Introdução a Engenharia de Software
Uma Introdução a Engenharia de SoftwareVinicius Garcia
 
Cap1 introd-engenharia de software
Cap1 introd-engenharia de softwareCap1 introd-engenharia de software
Cap1 introd-engenharia de softwareAdilson Nascimento
 
Gestão Ágil de Projetos com Scrum e FDD - Manoel Pimentel
Gestão Ágil de Projetos com Scrum e FDD - Manoel PimentelGestão Ágil de Projetos com Scrum e FDD - Manoel Pimentel
Gestão Ágil de Projetos com Scrum e FDD - Manoel PimentelManoel Pimentel Medeiros
 
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UMLDesenhando Componentes de Software com UML
Desenhando Componentes de Software com UMLRildo (@rildosan) Santos
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Softwareeros.viggiano
 
Engenharia de Software Pressman
Engenharia de Software PressmanEngenharia de Software Pressman
Engenharia de Software PressmanSimoneinfo
 
JAD e levantamento de requisitos
JAD e levantamento de requisitosJAD e levantamento de requisitos
JAD e levantamento de requisitosEduardo Castro
 
LIVRO PROPRIETÁRIO - ENGENHARIA DE USABILIDADE E INTERFACES
LIVRO PROPRIETÁRIO - ENGENHARIA DE USABILIDADE E INTERFACESLIVRO PROPRIETÁRIO - ENGENHARIA DE USABILIDADE E INTERFACES
LIVRO PROPRIETÁRIO - ENGENHARIA DE USABILIDADE E INTERFACESOs Fantasmas !
 
LIVRO PROPRIETÁRIO - QUALIDADE DE SOFTWARE
LIVRO PROPRIETÁRIO - QUALIDADE DE SOFTWARELIVRO PROPRIETÁRIO - QUALIDADE DE SOFTWARE
LIVRO PROPRIETÁRIO - QUALIDADE DE SOFTWAREOs Fantasmas !
 
Princípios da engenharia de software (marcello thiry)
Princípios da engenharia de software (marcello thiry)Princípios da engenharia de software (marcello thiry)
Princípios da engenharia de software (marcello thiry)Marcello Thiry
 
O (papel do) Arquiteto de Software
O (papel do) Arquiteto de SoftwareO (papel do) Arquiteto de Software
O (papel do) Arquiteto de SoftwarePeter Jandl Junior
 
Aula 1 2-es
Aula 1 2-esAula 1 2-es
Aula 1 2-escifjovo
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixCris Fidelix
 

Mais procurados (20)

Aula1 introducao engsw
Aula1 introducao engswAula1 introducao engsw
Aula1 introducao engsw
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Engenharia de software
Engenharia de softwareEngenharia de software
Engenharia de software
 
Engenharia de Software - Wikipedia
Engenharia de Software - WikipediaEngenharia de Software - Wikipedia
Engenharia de Software - Wikipedia
 
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
 
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1
 
Uma Introdução a Engenharia de Software
Uma Introdução a Engenharia de SoftwareUma Introdução a Engenharia de Software
Uma Introdução a Engenharia de Software
 
Cap1 introd-engenharia de software
Cap1 introd-engenharia de softwareCap1 introd-engenharia de software
Cap1 introd-engenharia de software
 
Gestão Ágil de Projetos com Scrum e FDD - Manoel Pimentel
Gestão Ágil de Projetos com Scrum e FDD - Manoel PimentelGestão Ágil de Projetos com Scrum e FDD - Manoel Pimentel
Gestão Ágil de Projetos com Scrum e FDD - Manoel Pimentel
 
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UMLDesenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Aula4 levantamento requisitos
Aula4 levantamento requisitosAula4 levantamento requisitos
Aula4 levantamento requisitos
 
Engenharia de Software Pressman
Engenharia de Software PressmanEngenharia de Software Pressman
Engenharia de Software Pressman
 
JAD e levantamento de requisitos
JAD e levantamento de requisitosJAD e levantamento de requisitos
JAD e levantamento de requisitos
 
LIVRO PROPRIETÁRIO - ENGENHARIA DE USABILIDADE E INTERFACES
LIVRO PROPRIETÁRIO - ENGENHARIA DE USABILIDADE E INTERFACESLIVRO PROPRIETÁRIO - ENGENHARIA DE USABILIDADE E INTERFACES
LIVRO PROPRIETÁRIO - ENGENHARIA DE USABILIDADE E INTERFACES
 
LIVRO PROPRIETÁRIO - QUALIDADE DE SOFTWARE
LIVRO PROPRIETÁRIO - QUALIDADE DE SOFTWARELIVRO PROPRIETÁRIO - QUALIDADE DE SOFTWARE
LIVRO PROPRIETÁRIO - QUALIDADE DE SOFTWARE
 
Princípios da engenharia de software (marcello thiry)
Princípios da engenharia de software (marcello thiry)Princípios da engenharia de software (marcello thiry)
Princípios da engenharia de software (marcello thiry)
 
O (papel do) Arquiteto de Software
O (papel do) Arquiteto de SoftwareO (papel do) Arquiteto de Software
O (papel do) Arquiteto de Software
 
Aula 1 2-es
Aula 1 2-esAula 1 2-es
Aula 1 2-es
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
 

Semelhante a APF Estimativas

Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9wilsonguns
 
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhDDisciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhDRogerio P C do Nascimento
 
cms_files_81187_1648754282Material_Doutorado_Profissional_em_Engenharia_de_So...
cms_files_81187_1648754282Material_Doutorado_Profissional_em_Engenharia_de_So...cms_files_81187_1648754282Material_Doutorado_Profissional_em_Engenharia_de_So...
cms_files_81187_1648754282Material_Doutorado_Profissional_em_Engenharia_de_So...Ricardo Roberto MSc, MBA
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREErnesto Bedrikow
 
Apresentação da disciplina de Introdução à Informática
Apresentação da disciplina de Introdução à InformáticaApresentação da disciplina de Introdução à Informática
Apresentação da disciplina de Introdução à InformáticaKéssia Marchi
 
Apresentação da Disciplina Gerência de Projetos - DCOMP - UFS
Apresentação da Disciplina Gerência de Projetos - DCOMP - UFSApresentação da Disciplina Gerência de Projetos - DCOMP - UFS
Apresentação da Disciplina Gerência de Projetos - DCOMP - UFSRogerio P C do Nascimento
 
Curso Pratico em Gestao de Projetos com MS Project
Curso Pratico em Gestao de Projetos com MS ProjectCurso Pratico em Gestao de Projetos com MS Project
Curso Pratico em Gestao de Projetos com MS ProjectGrupo Treinar
 
PROCC UFS.br :: Apresentação Disciplina PGPS - Planejamento e Gerencia de Pro...
PROCC UFS.br :: Apresentação Disciplina PGPS - Planejamento e Gerencia de Pro...PROCC UFS.br :: Apresentação Disciplina PGPS - Planejamento e Gerencia de Pro...
PROCC UFS.br :: Apresentação Disciplina PGPS - Planejamento e Gerencia de Pro...Rogerio P C do Nascimento
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWMatheus Costa
 
02 Introdução à engenharia de software - conceitos fundamentais
02 Introdução à engenharia de software - conceitos fundamentais02 Introdução à engenharia de software - conceitos fundamentais
02 Introdução à engenharia de software - conceitos fundamentaisWaldemar Roberti
 
Apresentação do curso técnico de informática modalidade EAD
Apresentação do curso técnico de informática modalidade EADApresentação do curso técnico de informática modalidade EAD
Apresentação do curso técnico de informática modalidade EADavleite
 
Qualidade de Software, Conceitos Modelos e Situação Atual
Qualidade de Software, Conceitos Modelos e Situação AtualQualidade de Software, Conceitos Modelos e Situação Atual
Qualidade de Software, Conceitos Modelos e Situação AtualSidnei Viana Dos Santos
 

Semelhante a APF Estimativas (20)

Aula1 Apresentacao TEES
Aula1 Apresentacao TEESAula1 Apresentacao TEES
Aula1 Apresentacao TEES
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
 
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhDDisciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
 
RAD - Métodos ágeis
RAD - Métodos ágeisRAD - Métodos ágeis
RAD - Métodos ágeis
 
Rup e metodos ágies
Rup e metodos ágiesRup e metodos ágies
Rup e metodos ágies
 
Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
 
cms_files_81187_1648754282Material_Doutorado_Profissional_em_Engenharia_de_So...
cms_files_81187_1648754282Material_Doutorado_Profissional_em_Engenharia_de_So...cms_files_81187_1648754282Material_Doutorado_Profissional_em_Engenharia_de_So...
cms_files_81187_1648754282Material_Doutorado_Profissional_em_Engenharia_de_So...
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWARE
 
Apresentação da disciplina de Introdução à Informática
Apresentação da disciplina de Introdução à InformáticaApresentação da disciplina de Introdução à Informática
Apresentação da disciplina de Introdução à Informática
 
Apresentação da Disciplina Gerência de Projetos - DCOMP - UFS
Apresentação da Disciplina Gerência de Projetos - DCOMP - UFSApresentação da Disciplina Gerência de Projetos - DCOMP - UFS
Apresentação da Disciplina Gerência de Projetos - DCOMP - UFS
 
Curso Pratico em Gestao de Projetos com MS Project
Curso Pratico em Gestao de Projetos com MS ProjectCurso Pratico em Gestao de Projetos com MS Project
Curso Pratico em Gestao de Projetos com MS Project
 
PROCC UFS.br :: Apresentação Disciplina PGPS - Planejamento e Gerencia de Pro...
PROCC UFS.br :: Apresentação Disciplina PGPS - Planejamento e Gerencia de Pro...PROCC UFS.br :: Apresentação Disciplina PGPS - Planejamento e Gerencia de Pro...
PROCC UFS.br :: Apresentação Disciplina PGPS - Planejamento e Gerencia de Pro...
 
Aula Apresentação de Gestão de Riscos
Aula Apresentação de Gestão de RiscosAula Apresentação de Gestão de Riscos
Aula Apresentação de Gestão de Riscos
 
Processo de Software
Processo de SoftwareProcesso de Software
Processo de Software
 
152191 11993
152191 11993152191 11993
152191 11993
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
02 Introdução à engenharia de software - conceitos fundamentais
02 Introdução à engenharia de software - conceitos fundamentais02 Introdução à engenharia de software - conceitos fundamentais
02 Introdução à engenharia de software - conceitos fundamentais
 
RAD - Métodos ágeis
RAD - Métodos ágeisRAD - Métodos ágeis
RAD - Métodos ágeis
 
Apresentação do curso técnico de informática modalidade EAD
Apresentação do curso técnico de informática modalidade EADApresentação do curso técnico de informática modalidade EAD
Apresentação do curso técnico de informática modalidade EAD
 
Qualidade de Software, Conceitos Modelos e Situação Atual
Qualidade de Software, Conceitos Modelos e Situação AtualQualidade de Software, Conceitos Modelos e Situação Atual
Qualidade de Software, Conceitos Modelos e Situação Atual
 

Mais de Carlos Antonio Castro Oliveira (6)

Bancos de dados relacionais
Bancos de dados relacionaisBancos de dados relacionais
Bancos de dados relacionais
 
Curso struts e hibernate
Curso struts e hibernateCurso struts e hibernate
Curso struts e hibernate
 
Aplicando logica orientada_a_objeto_em_java
Aplicando logica orientada_a_objeto_em_javaAplicando logica orientada_a_objeto_em_java
Aplicando logica orientada_a_objeto_em_java
 
Estudo de caso da adoção das práticas e valores do extreme programming
Estudo de caso da adoção das práticas e valores do extreme programmingEstudo de caso da adoção das práticas e valores do extreme programming
Estudo de caso da adoção das práticas e valores do extreme programming
 
Guia php
Guia phpGuia php
Guia php
 
Qualidade de software site bb
Qualidade de software   site bbQualidade de software   site bb
Qualidade de software site bb
 

APF Estimativas

  • 1. 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
  • 2.
  • 3. 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.
  • 4. Í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
  • 5. Edição 05 - Engenharia de Software Magazine 5
  • 6. 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
  • 7. 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. Edição 44 - Engenharia de Software Magazine 7
  • 8. 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 8 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
  • 9. 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 Edição 44 - Engenharia de Software Magazine 9
  • 10. • 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. 10 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
  • 11. 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 Edição 44 - Engenharia de Software Magazine 11
  • 12. 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 12 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
  • 13. 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), Edição 44 - Engenharia de Software Magazine 13
  • 14. ú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
  • 15. 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 Edição 44 - Engenharia de Software Magazine 15
  • 16. 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 16 Engenharia de Software Magazine - Scrum e o gerenciamento de projetos – Parte 3
  • 17. Gerenciamento d e Projetos 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, Edição 44 - Engenharia de Software Magazine 17
  • 18. 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 in- do 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. 18 Engenharia de Software Magazine - Scrum e o gerenciamento de projetos – Parte 3
  • 19. Gerenciamento d e Projetos 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 Edição 44 - Engenharia de Software Magazine 19