Your SlideShare is downloading. ×
Processo             engenharia                                                 magazine                                  ...
Rodrigo Oliveira Spínola                                                                                                  ...
ÍNDICEAgilidade06 - Requisitos para agilidade no desenvolvimento de software                                              ...
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 ...
agilidadecomo um dos principais itens do desenvolvimento de software                                  suporte aos processo...
equipe que consiste principalmente de desenvolvedores e                   na equipe e se torna a metodologia do time, as r...
agilidadenecessário estabelecer um trabalho colaborativo com especialista       desenvolver e testar o software. Neste nív...
• contrato é o suficiente;                                               das necessidades da equipe de recursos. No caso d...
agilidade  No entanto, no nível de programa, essas equipes formadas        backlog do programa como recursos normais, ou s...
de software exige novos artefatos e níveis ainda mais altos de           É importante que essa administração ocorra de for...
Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros Scrum e o...
últimas realizações do período, principais riscos, situação fi-         Scrum. Porém, não iremos comparar o Scrum a nenhum...
Gerenciamento d e Projetospartes interessadas (stakeholders) pelo projeto, e geralmente        monitoramento, usaremos ape...
Estamos falando destes dois artefatos porque precisamos               • Laranja: Tarefas planejadas;de dados para acompanh...
Gerenciamento d e Projetosde até um mês. Maiores detalhes sobre as Sprints podem ser en-       4. Ao final de cada dia da ...
Figura 5. Cronograma com milestonesnão vão faltar dados para se montar relatórios de situação e            início do proje...
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Engenharia de Software - Pontos de função
Upcoming SlideShare
Loading in...5
×

Engenharia de Software - Pontos de função

2,593

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,593
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
229
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "Engenharia de Software - Pontos de função"

  1. 1. Processo engenharia magazine Conheça os modelos de processo pessoal de software Processo Edição 44 - Ano 04 Uma visão geral do CMMIAprimore suas estimativas de tamanho de projeto Agilidade Agilidade Requisitos Requisitos para Scrum e o gerenciamento Gerenciando mudançasalcanç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.htmlDesenvolvimento DesenvolvimentoDesenvolvimento de aplicações de Conheça técnicas para manterrealidade aumentada seu código “limpo” – Parte 6
  2. 2. 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 emCorpo 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 doEditorRodrigo 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çãoColaboradores Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, ColaboradorMarco Antônio Pereira Araújo da Engenharia de Software Magazine.Eduardo Oliveira SpínolaJornalista Responsável Eduardo Oliveira SpínolaKaline 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 owww.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 paraesclarecimento 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ê gostariawww.devmedia.com.br/mancad(21) 2220-5338 de publicar. ApoioPublicidadePara informações sobre veiculação de anúncio na revista ou no site entre emcontato com:publicidade@devmedia.com.brEDITORIAL 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.
  3. 3. ÍNDICEAgilidade06 - Requisitos para agilidade no desenvolvimento de software Flavio S. Mariotti13 - Scrum e o gerenciamento de projetos – Parte 3 Fábio CruzEngenharia Aplicada20 - Estimativas de tamanho em projetos de software utilizando pontos de função Jhoney da Silva Lopes e José Luis BragaEngenharia Fundamentos32 - CMMI – Uma visão Geral Lenildo Morais36 - Gerenciando mudanças a partir de requisitos José Alberto Zimermann, Thiago Carvalho de Sousa e Rodrigo Oliveira SpínolaArquitetura e Desenvolvimento42 - Introdução ao desenvolvimento de aplicações de realidade aumentada André Luis Tosato, Victor Angelo Marcorin, Thiago Salhab Alves e Paulo Barreto da Silva47 - Boas práticas para escrita de métodos, funções e procedimentos – Parte 6 Jacimar Fernandes Tavares e Marco Antônio Pereira Araújo
  4. 4. Edição 05 - Engenharia de Software Magazine 5
  5. 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, exigindo6 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
  6. 6. agilidadecomo um dos principais itens do desenvolvimento de software suporte aos processos, como distribuir a responsabilidadea agilidade na produção. Porém, como criar produtos com me- de cada envolvido no processo e qual a importância dessanos tempo e com a mesma eficiência? São dúvidas como essas distribuição.que vem transformando nossas metodologias na tentativa dealcançar o melhor e mais ágil modelo de desenvolvimento de Requisitos ágeis para a equipesoftware. É 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 definirNÃO. Para se obter agilidade no processo de desenvolvimento papéis, distribuir responsabilidades e criar as atividades parade software é preciso aplicar o conceito nos três pilares que um projeto no modelo ágil. Sendo assim, é de total valia usarfazem parte deste trabalho, que são: equipe, programas e em- esses conceitos para modelar e adequar a sua equipe na suapresa. 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 aatingir a agilidade no desenvolvimento de software, quais os equipe incorpore o modelo ágil para contribuir ao máximorequisitos 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
  7. 7. equipe que consiste principalmente de desenvolvedores e na equipe e se torna a metodologia do time, as regras sãotestadores 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 melhoriaum 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 serFigura 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 modeloProprietá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 padronizadadescreve 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 desimplificaçã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 equipejuntos diariamente durante o andamento do projeto”. Com base ágil. Os testadores estarão presentes logo no primeiro código anesse princípio, o proprietário do produto é a função ideal ser liberado, e se faz necessário passar pela aplicação de testespara 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 paraprioridades. 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 obtercipal responsável pela definição e priorização de requisitos. qualidade e agilidade no desenvolvimento de software. OutrasPortanto, 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 produtoe 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 recursosEssa função tem como responsabilidade dirigir o time para compartilhados e interfaces para outras funções. Segundo oalcançar suas metas e, em alguns projetos, é importante so- princípio Agile Manifesto #11 - “As melhores arquiteturas, requisitos emente na fase de transição. Quando o modelo ágil é imposto projetos emergentes de equipe auto-organizadas.”. Assim sendo, se faz8 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
  8. 8. agilidadenecessário estabelecer um trabalho colaborativo com especialista desenvolver e testar o software. Neste nível as equipes sãoque, 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 ágeisConceito á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 momentonão exclui a principal necessidade de criar aplicativos eficien- os problemas são outros e a empresa irá enfrentar diferentestes 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 manterfrase 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 conformerequisitos de software. Este item ágil atualmente faz parte necessário para enfrentar as limitações e dificuldades nados 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óriasde usuários são breves declarações de usuários expressando Equipes recursos e equipes componentessuas intenções que descrevem um recurso que o sistema “pre- Nesta parte do artigo será apresentado como funcionam ascisa” 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. Percebertrar 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 recursosO 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 equipesexistam 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 nao 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 componentesRequisitos á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
  9. 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 componentepotencialmente 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 deFigura 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, recursosrecursos 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 provavelmentenizacional, 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égiaisso maximiza o aprendizado dos membros auxiliando nas para empresa ágil é permanecer no 70%-30% ou 80%-20% dedecisõ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 decriar 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 recursosequipe de recursos inclui todas as habilidades necessárias para e equipes de componentes e no final recomenda um modeloir 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 podecursos, 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 integraro trabalho da equipe de componente ao produto precisa sercalculado. O especialista em projetos ágeis, Mike Cohn, publicou umartigo em seu blog apresentando alguns benefícios obtidoscom 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 derecursos, 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 entreguea uma outra equipe do projeto, em vez de diretamente ao Figura 3. Combinando membros da equipe de componentes para fazer acliente. Um exemplo seria uma equipe de componente desen- equipe de recursosvolvendo uma camada de mapeamento entre a aplicação e obanco 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 tertrabalham paralelas às equipes de recursos. É importante habilidades necessárias para especificar, projetar, codificar egarantir 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
  10. 10. agilidade No entanto, no nível de programa, essas equipes formadas backlog do programa como recursos normais, ou seja, usandopor pessoas podem não ter todas as características necessárias o mesmo conceito de histórias de usuários. Alguns exemplospara 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 principaisde 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 sejade 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, paracada produto existe um time de planejamento e lançamentoque a empresa utiliza para alinhar as equipes técnicas com asequipes de negócios para o lançamento. Esta equipe é necessária porque, embora as equipes ágeissejam habilitadas, não tem necessariamente a visibilidadedo negócio, ou até mesmo a autoridade para decidir quandoserá a entrega do produto para o usuário final. Geralmenteessa equipe é formada pelos principais membros do nível deprograma 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 ilustraA reunião tem como principal foco debater a situação do um modelo simples para aplicação de testes de qualidade nosproduto, 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 visibilidadeampla e o gerenciamento sênior semanal para o estado de Figura 5. Modelo básico de teste de requisitos não-funcionaisliberaçã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 testesresulta nos dados do planejamento da versão que são usados de qualidade de sistemas. Este termo indica que estes testespara 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 derecursos priorizando conforme a necessidade do negócio. A Requisitos ágeis para a empresaFigura 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, encontramosduto, 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 conformidadesimprevisí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, paratais como: confiabilidade, desempenho, qualidade, compatibili- empresas que contém muitos produtos em que a governançadade 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
  11. 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ãoRequisitos 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 modeloEste tema é o item que representa uma série de iniciativas que mental que ajude a elevar o alcance de abstração e escala paraimpulsionam 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, artefatosindivíduos que tem a responsabilidade final com as linhas de e processos que são necessários para alcançar o desenvolvimentonegócio. Em algumas empresas, esse processo pode ser com- ágil. Foi apresentado um modelo organizacional para auxiliar naparado 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. Nestacom 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 emanutenção; arquitetura de melhoria contínua.• Investimento em novos produtos, novos serviços ou trabalho Linkscomercial 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, 2008Arquitetura: 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-Wesleysitos que resultam em agilidade, a empresa pode evitar alguns Professional, 2009acontecimentos 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 ede 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 mausinvestimentos. www.devmedia.com.br/esmag/feedback12 Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
  12. 12. 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
  13. 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 gerenciamentoque podem variar um pouco de acordo com o projeto e com a de projetos como uma área de conhecimento geral, com seusnecessidade 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, acontrolado 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 duasforma resumida demais e deixando de ser um valor real para abordagens, agindo de forma complementar e influenciandoquem as recebe, ou seja, deixando de informar aos interessa- diretamente no resultado da comunicação do projeto.dos dados importantes sobre o projeto. Este comportamentofaz parecer que a comunicação não é necessária quando tudo Gerenciamento ativo e não reativoestá 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çõesem 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 nainformando e posicionando desde o início do projeto. Sendo prática a sua ocorrência ainda é alarmante, é que os gerentesassim, o primeiro recado é que a comunicação deve ser reali- de projetos, ou as equipes de gerenciamento, não acompanhamzada 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 aprojeto deve ser simples, e é obrigatória para qualquer gerente. informação é solicitada, a gerência precisa reagir ao pedido ePoré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, podendonã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 prontosê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 preferencialmentecação geral de um projeto, este artigo se propõe a apresentar devem ser as mais recentes possíveis. Neste ponto é que oum 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 tradicionalcom 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 tradicionaisforam descritos nas primeiras duas partes desta série de arti- trazem em seu conteúdo a orientação de se criar um plano degos, 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 documentodas 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 amunicação mais eficaz e eficiente, será demonstrado aqui como frequência de circulação de cada relatório informativo, e porcomunicar 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 dode 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 demostraremos como o Scrum complementa o gerenciamento requisitos, escopo, mudanças, riscos e qualidade. Todos estestradicional, assim como o gerenciamento tradicional apóia o sub-planos fornecem informações importantes para várias14 Engenharia de Software Magazine - Scrum e o gerenciamento de projetos – Parte 3
  14. 14. Gerenciamento d e Projetospartes interessadas (stakeholders) pelo projeto, e geralmente monitoramento, usaremos apenas a estória que definiremosfazem 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> parapertinentes 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 criandoao 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 livroquais 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 colocartamente, 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 aequipe gerencial usará como artefatos de comunicação, alémde como e quando cada documento será distribuído. Note que esta preparação para se comunicar no decorrerdo projeto, já é uma comunicação efetiva, e demonstra quehá clareza e transparência na forma com que o projeto seráconduzido e acompanhado. Figura 1. Estórias em post-itsArtefatos 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 estado Produto, que é o conjunto de todos os requisitos e trabalhos cerimônia é parte integrante do Scrum e foi descrita em maisnecessá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, entreoutros documentos relevantes. Tarefas Partindo de um Backlog do Produto completo para o projeto, Na primeira parte desta reunião de planejamento, o timeou para uma versão de entrega (release), se consegue obter os pró- entende as estórias e determina o tamanho de cada uma. Estaximos e mais detalhados documentos que fornecerão os dados estimativa servirá como artefato para medir o desempenhoimportantes 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 queentregar na próxima Sprint. A partir desta seleção de itens do possam ser determinadas em horas para conclusão, e devemBacklog, 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 tarefasEngenharia de Software Magazine. menores será um dos mais importantes artefatos de controle que usaremos ao longo do projeto, pois estas tarefas menoresEstó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 conjuntoitem de Backlog poderá dar origem a mais de uma estória, por de trabalhos. Este conjunto de trabalhos poderá ser ilustradoquestõ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 eacompanhamento. É aqui que começamos a ter artefatos paramelhorar a comunicação, principalmente no nível gerencial. Um exemplo para um fácil entendimento é um “cadastrode livros”, que é um item de Backlog possuindo protótipo detela, modelo de dados, especificação de regra de negócio ecaso de uso. Estes são todos os documentos que compõem oitem 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
  15. 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 sobrebreve 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 sercaçã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 umuma 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 itemna 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 dativa 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çãolado 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 deestó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ópriosprevistas e que surjam ao longo do desenvolvimento, e/ou integrantes do time mantêm as tarefas atualizadas no quadrocolunas 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 Burndownpost-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 menores16 Engenharia de Software Magazine - Scrum e o gerenciamento de projetos – Parte 3
  16. 16. Gerenciamento d e Projetosde 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 decontrados 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 totalacompanhar a evolução do projeto. Porém, como fazer este acom- de trabalho restante a cada dia. Pronto, você terá a velocidadepanhamento e saber se o projeto está atrasado ou adiantado? real do time. A resposta não é tão difícil quanto parece, principalmentedepois de termos falado sobre o Backlog da Sprint, estórias Na ilustração da Figura 4, a linha vermelha representa ae 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 comfas 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 anão. Para resolver este problema entra em ação o último artefato linha azul (real) esteja acima da linha vermelha (estimada), ado 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 timerestante 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, optecompletadas 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 tempodas estimativas dos esforços restantes para se terminar os real. Por exemplo, quando um desenvolvedor encerra uma tarefatrabalhos contidos no Backlog da Sprint. Por isso, olhando o pela ferramenta de desenvolvimento, esta por sua vez atualizagrá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 visualigual 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 queFigura 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 melhorarto é simples. Em resumo, o dia atual deve ter menos trabalho e corrigir seus defeitos. Para os demais, os resultados serão osrestante do que o dia anterior. Visualmente podemos fazer uma melhores possíveis, porque a própria equipe buscará a cadacomparaçã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 umaou atrasados, da seguinte forma: evidência de seu bom trabalho, e não em um problema que1. No primeiro dia da Sprint, monte o gráfico colocando na mostra para todos os seus erros. Esta qualidade que o Scrumcoluna 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 formalprecisam ser completados (coluna à esquerda) ao último dia da Com os trabalhos sendo realizados conforme as definiçõesSprint (à direita). Esta linha representará a velocidade média do tradicional plano de gerenciamento do projeto e seguindodo 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
  17. 17. Figura 5. Cronograma com milestonesnã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 deinformaçõ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 dejetos, 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çõestrocinadores, 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 falhasparcelas 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 quererpodendo 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 decom acesso restrito; gerenciamento do projeto esteja preparada para fornecer as2. 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 formatomensalmente. ideal é aquele que consegue condensar todas as informações importantes em uma única página. Principalmente porque oCronograma 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 quemteressante 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 auxiliaresalterado, 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 domento de apoio sem grande detalhamento de itens, tarefas ou projeto, apontando se os gastos estão dentro do previsto, abaixoní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 dode fornecer as informações importantes sobre datas e etapas apontamento de riscos para os próximos períodos e eventuaisconcluí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

×