terça-feira, 29 de março de 2016

6. Referências 1. Portal do SISP - plataforma WikiSISP (http://www.sisp.gov.br/wikisisp/wiki/principal); 2. Portal Governo Eletrônico (www.governoeletronico.gov.br); 3. Portal Dados Abertos (www.dados.gov.br); 4. Portal da Legislação do Governo Federal (http://www4.planalto.gov.br/legislacao); 5. Frameworks disponíveis para a gestão e governança de TI; 6. Portal da Secretaria de Fiscalização de Tecnologia da Informação do Tribunal de Contas da União – SEFTI/TCU; 7. COBIT® 5 - Modelo Corporativo para Governança e Gestão de TI da Organização. Isaca® - www.isaca.org

https://www.amgasparin.wordpress.com
6. Referências 1. Portal do SISP - plataforma WikiSISP (http://www.sisp.gov.br/wikisisp/wiki/principal); 2. Portal Governo Eletrônico (www.governoeletronico.gov.br); 3. Portal Dados Abertos (www.dados.gov.br); 4. Portal da Legislação do Governo Federal (http://www4.planalto.gov.br/legislacao); 5. Frameworks disponíveis para a gestão e governança de TI; 6. Portal da Secretaria de Fiscalização de Tecnologia da Informação do Tribunal de Contas da União – SEFTI/TCU; 7. COBIT® 5 - Modelo Corporativo para Governança e Gestão de TI da Organização. Isaca® - www.isaca.org

http://sisp.gov.br/guiaagil/wiki/download/file/Guia_de_Projetos_Ageis_Final

Procurar · Indice

No registered users in community wiki
in last 10 minutes

Conceitos, Fundamentos e Papéis

Conceitos e Fundamentos

Adaptação: Significa que toda vez que uma variação prejudicial ao projeto é identificada, o processo deve ser ajustado imediatamente, como forma de evitar outros desvios;

Brainstorming: técnica dedicada a produzir um conjunto diverso de opções para um problema ou oportunidade;

DevOps: é relação de interdependência entre os desenvolvedores de software e os profissionais de tecnologia da informação que viabilizam a operação do software e necessidades afins por meio de um sistema de produção e integrado de pessoas, informação, ativos de hardware, serviços, ferramentas e aplicativos, que apoiam as atividades de gestão de projetos, produção e gerência de requisitos de software, construção de software, prototipação de interfaces gráficas de usuário, construção e disponibilização do banco de dados, testes automatizados, inspeção automatizada da qualidade dos produtos, integração contínua dos componentes de software, disponibilização automática do release em ambiente apropriado, gestão informatizada dos ambientes de disponibilização, gestão de configuração de artefatos de engenharia e gestão de mudanças. Todas estas atividades de engenharia de software são desenvolvidas por meio de processos, métodos e ferramentas, alguns destes são informatizados, promovendo o princípio da impessoalidade e a diminuição do esforço da execução pela automação de processos operacionais. Os profissionais especializados em DevOps são responsáveis pela sua instalação, configuração, disponibilização, operação, conectividade, continuidade, segurança e manutenção. O DevOps exige comunicação estreita entre os profissionais, colaboração contínua e cooperação máxima (Scaled Agile Framework, 2014), (SWEBOK, 2004);

Veja mais informações em:

http://guide.agilealliance.org/subway.html
http://www.scaledagileframework.com/devops/

Cobertura de Testes: os testes podem ser qualificados quanto a sua extensão e escopo. A cobertura é o limite de incidênciado teste, podendo atingir os seguintes níveis de abstração: negócio (teste de aceitação), requisitos (teste de sistema), projeto (teste de integração) e código (testes unitários);

Complexidade Ciclomática: Desenvolvida por Thomas J. McCabe em 1976, mede a quantidade de caminhos de execução independentes. Essa complexidade é computada através do grafo de fluxo de controle do programa: os nós do grafo correspondem a grupos indivisíveis de comandos, e uma aresta direcionada conecta dois nós se o segundo comando pode ser executado imediatamente após o primeiro. A complexidade ciclomática também pode ser aplicada a funções, módulos, métodos ou classes individuais de um programa. Uma estratégia de teste de verificação é testar cada caminho independente do programa, de modo que a quantidade de casos de teste será a complexidade ciclomática do código;

Débito técnico: pendências técnicas introduzidas no código em virtude de o mesmo ter sido implementado sem o design ou cuidados necessários. Estas pendências podem estar relacionadas com: qualidade, bom design que permita fácil adaptação e manutenção, testes,,etc. A existência de débito técnico indica que a tarefa não foi totalmente concluída e que a equipe deverá ter mais trabalho futuramente em virtude destas pendências deixadas no projeto. Veja mais informações em: http://martinfowler.com/bliki/TechnicalDebt.html http://martinfowler.com/bliki/TechnicalDebtQuadrant.html e http://www.ontechnicaldebt.com/

Defeito: problema no software que faz com que ele se comporte de forma distinta da esperada/desejada;

Desvio ou Impedimento: é todo problema que afeta o ritmo de trabalho da equipe do projeto, podendo comprometer o alcance da meta estabelecida para a Iteração ou Release;

Definição de Pronto: é um entendimento compartilhado entre os envolvidos no projeto (Instituição e contratada) do que significa trabalho completo, assegurando a transparência. O “Pronto” será utilizado para definir um nível de maturidade e ou qualidade de entregáveis em cada grupo de atividades do processo. Por exemplo: artefatos de planejamento, requisitos, incremento de software (iteração) e versão funcional do software (release);

Elevator Statement: O seu principal objetivo é a facilitação do entendimento do projeto. Cauteriza o entendimento sobre as razões e aspectos relevantes do projeto na mente coletiva. A técnica pode ser executada em uma sala com toda a equipe do projeto, isolada das demais pessoas e do ambiente de trabalho. Em seguida, o facilitador faz uma explanação das necessidades, negócio e problema para a equipe do projeto, a fim de estabelecer uma visão clara da solução e familiarizar a equipe com o negócio. Caso seja necessário envolva algum stakeholder da área de negócio. Elementos mais relevantes de um projeto:

PARA [Área de Negócio]
QUE [Necessidade ou Oportunidade]
O [Nome da Solução]
É UM [Categoria da Solução]
QUE [Principal benefício]
DIFERENTEMENTE DO [Solução ou condição atual]
NOSSA SOLUÇÃO [Principal diferenciação]

Por fim, a construção de uma visão do projeto e a internalização de seu propósito e de seus aspectos mais relevantes são inciativas que contribuem com a clareza e a determinação; Veja mais Informações: http://www.insistimento.com.br/empreendedorismo/auto-ajuda/como-criar-um-elevator-pitch-eficiente/

Épico: é uma necessidade de negócio não refinada, correspondendo a algum caso de negócio. O épico do produto ou do produto-parte de uma solução informatizada (de um determinado problema) será decomposto em características macrofuncionais que o refinam. A solução deve agregar valor perceptível ao negócio do cliente. (Scaled Agile Framework, 2014);

Funcionalidade: é a menor parte e mais elementar de um sistema informatizado, que agrega algum valor ao usuário. É uma história de usuário conforme definido pelo framework XP e que, para o Processo Unificado, seria equivalente à decomposição de um caso de uso ou mesmo à descrição do cenário de um caso de uso;

Grooming: é uma técnica para refinamento e aprimoramento do backlog do produto, precisa de atenção, cuidados contínuos e ser organizado cuidadosamente (Druckman, 2011). Refinar o backlog abrange os seguintes procedimentos:

1. A descoberta de novos itens, assim como alteração e remoção de itens antigos;

2. Quebrar histórias muito grandes;

3. A priorização dos itens do backlog (trazendo os mais importantes para o topo);

4. Preparar e refinar os itens mais importantes para a próxima reunião de planejamento;

5. Estimar e corrigir estimativas dos itens do backlog (em caso de novas descobertas);

6. Incluir critérios de aceitação.

A técnica contribui com a manutenção do foco, evitando distrações e desvios daquelas funcionalidades necessárias para o momento. Veja Mais Informações: http://guide.agilealliance.org/guide/backlog-grooming.html

Guias de Apoio: são metodologias e especificações técnicas que auxiliam no processo de desenvolvimento e manutenção de sistemas de informação da instituição. São eles:

Guia de Arquitetura: define a estrutura ou organização dos componentes do programa (módulos), a maneira com a qual estes componentes interagem e a estrutura da informação que é usada por estes componentes na instituição;
Guia de Banco de Dados: guia que concentra informações necessárias à criação e utilização de modelos de dados na instituição, tais como: modelo de dados corporativo definido, migração de dados, normalização de dados, sistema gerenciador de banco de dados e administração de dados;
Guia ou Roteiro de Métricas: apresenta um roteiro de métricas, com base em regras de contagem, para vários tipos de projetos de desenvolvimento e de manutenção de sistemas de informação, promovendo o uso de métricas objetivas nos contratos de prestação de serviços desses projetos;Guia de Segurança da Informação para Desenvolvimento de Software: documento que apresenta requisitos de segurança para implementação e observação no desenvolvimento de sistemas de informação no âmbito da instituição, trata questões como: controles criptográficos e segurança de arquivos do software;
Guia de Configuração e Mudança: documento que descreve o conjunto de atividades de controle de mudanças pela identificação dos produtos do trabalho que serão alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo para o gerenciamento de diferentes versões destes produtos, controlando as mudanças impostas, e auditando e relatando as mudanças realizadas;
Guia de Interface do Usuário: documento que define diretrizes da interface visual dos sistemas de informação, tais como: requisitos de usabilidade, navegabilidade, funcionalidades de tela e acessibilidade;
Guia de Testes de Sistemas: documento que define diretrizes para realização do plano de testes. Define os tipos de testes, artefatos e perfis envolvidos nos testes;
Guia de Especificação de Requisitos: documento que auxilia na definição de requisitos de um produto, sistematizando e normalizando o processo de especificação adotado pela instituição;

História de usuário (user story): descrição curta de uma característica do produto contada na perspectiva do usuário, utilizando uma linguagem comum ao negócio. Veja mais informações: http://www.extremeprogramming.org/rules/userstories.html http://www.mountaingoatsoftware.com/topics/user-stories

http://guide.agilealliance.org/guide/user-stories.html

Impact Mapping: técnica que auxilia a equipe a entregar software focado em objetivos de negócio, nas partes interessadas e suas necessidades.

Veja mais informações:

http://www.impactmapping.org/
http://gojko.net/papers/effect_maps.pdf

Incremento de Software: acréscimo de funcionalidades do produto de software final que é gerada a cada iteração. O incremento de software deve ser algo observável e, preferencialmente funcional, para que o dono do produto e demais usuários possam experimentá-lo da forma mais realista possível;

Inspeção: Todos os aspectos do processo de entrega que possam impactar o resultado final do projeto devem ser inspecionados frequentemente, para que qualquer variação prejudicial possa ser identificada e corrigida o mais rápido possível;

Iteração: um ciclo de desenvolvimento, de duração fixa e curta, que corresponde a uma subdivisão da release e que produz uma versão estável e executável do produto de software; Veja mais informações em: http://guide.agilealliance.org/guide/iteration.html

Meta: breve descrição em função dos objetivos de negócio e prazo que a equipe pretende alcançar durante um release ou iteração;

Produto: resultado final de um projeto, cuja finalidade é responder a demandas associadas ao software, ajustes na organização, necessidade de um ou mais clientes, avanços tecnológicos ou obrigatoriedades legais. O termo produto está relacionado a um produto físico, serviço ou associação de ambos. Independente da origem da demanda, um produto sempre é destinado a um cliente ou grupo de clientes, internos ou externos (Scrumex, 2014).

Product Vision Box: Nesta técnica, o facilitador captura informações sobre o problema ou necessidades para delinear a solução. Os stakeholders e o dono do produto são responsáveis pela transmissão do conhecimento das necessidades e do negócio. A técnica permite elencar as necessidades, aspectos do negócio, características e propósitos, e, assim, tecer os fundamentos e a anatomia da solução.Os interessados pela solução ajudarão a construir a visão do produto, esclarecendo não somente uma forma de resolver o problema proposto, como também elucidando desafios, dificuldades, riscos e expectativas. São elementos importantes do Product Vision Box, mas não se limitam a:

Visão da Solução;
Proposta de valor e o alinhamento estratégico gerencial;
Modelo de negócio;
Características do produto;
Exposição dos problemas e necessidades;
Oportunidades exploradas.

Finalmente, é possível, com esta técnica, extrair a visão que os donos do produto têm, reforçando o briefing (dossiê), o que garante, ao final de uma entrega, um produto funcional. Veja mais informações em: http://www.techrepublic.com/blog/tech-manager/define-the-vision-for-your-it-project-with-this-exercise/710

Release: conjunto de funcionalidades extraídas do backlog do produto. Representa entrega de um software funcional incluindo funcionalidades de uma ou mais Iterações;

Requisitos Funcionais: é a descrição do comportamento e a informação que a solução gerenciará. Descrevem capacidades que o sistema será capaz de executar em termos de comportamentos e operações – ações ou respostas específicas de aplicativos de tecnologia da informação (BABOK, 2011), (IEEE610, 1990);

Requisitos não Funcionais: são condições que não se relacionam diretamente ao comportamento ou funcionalidade da solução, mas descrevem condições ambientais sob as quais a solução deve permanecer efetiva, ou qualidades que os softwares precisam possuir. Também são conhecidos como requisitos de qualidade ou suplementares. Podem incluir requisitos relacionados à capacidade, velocidade, segurança, disponibilidade, arquitetura da informação e apresentação da interface com o usuário (BABOK, 2011);

Regras Transacionais ou de Execução: são determinadas condições de comportamento ou estado que o software deve assumir, também são conhecidas como regras de negócio. Os dados manipulados pelo software poderão assumir algum estado em determinadas condições definidas em uma regra (De Castro et al, 2014);

Requisitos de Dados: são estruturas de dados abstratas que definem qualidades ou características para as entidades do negócio. É qualquer tipo de dados necessário e manipulável pelo software (De Castro et al, 2014);

Refinamento dos Requisitos: considerando os aspectos do desenvolvimento ágil, define-se refinamento dos requisitos (retrabalho) como sendo os refinamentos referentes a funcionalidades que estão em desenvolvimento dentro de uma mesma release, ou seja, mudanças entre as iterações da release. Anexo V apresenta um quadro sobre itens de tipos de alterações em funcionalidades em métodos ágeis;

Scrum: é um framework de desenvolvimento ágil de software iterativo e incremental para o gerenciamento de desenvolvimento de produtos (Guia do Scrum, 2003); Veja mais informações em: http://guide.agilealliance.org/subway.html

Stakeholder: indivíduo ou organização que tem um direito, ação, declaração ou interesse no software em desenvolvimento;envolvido; interessado (PMBOK, 2004);

Time-box: a tradução literal é “caixa de tempo” e deve ser entendido como um intervalo de tempo para realização de uma atividade. É uma técnica utilizada para assegurar que atividades importantes do projeto sejam cumpridas e com o menor desperdício possível; Veja mais informações em: http://guide.agilealliance.org/guide/timebox.html

Teste de Software: consiste numa verificação dinâmica do comportamento de um programa em um conjunto finito de casos de teste contra o comportamento esperado.(SWEBOK, 2004), (IEEE610, 1990);

Teste de Operação: uma versão do software é disponibilizada no ambiente de produção para que um grupo restrito de usuários utilizem em circunstâncias reais. Aspectos funcionais e comportamentais do software são avaliados em uma implantação piloto no ambiente de produção (IEEE610, 1990);

Teste de Aceitação: teste escrito sob a perspectiva do cliente [BECK04]. Esse tipo de teste, geralmente, especifica o resultado esperado após a execução de determinada funcionalidade (IEEE610, 1990);

Teste de Sistema: o objetivo é executar as funcionalidades do sistema sob a ótica de quem utilizará, explorando as funcionalidades em busca de inconformidades em relação aos objetivos e especificações funcionais. Os testes são executados em condições operacionais similares, por exemplo, ambiente, interfaces sistêmicas e massas de dados, àquelas que um usuário utilizará na sua rotina de operação do software (IEEE610, 1990);

Teste de Integração: encontrar falhas provenientes da integração interna dos componentes de um software, ele conduz ao descobrimento de possíveis falhas, erros e defeitos associados à interface do software. A critério da gerência de projetos, os testes de comunicação entre interfaces com outros softwares (integração entre eles) poderá ser realizado (IEEE610, 1990);

Teste de Unidade: teste escrito sob a perspectiva do programador [BECK04], aplicado sobre a menor unidade de execução do código. Cada caso de teste deve avaliar um possível comportamento do código (IEEE610, 1990);

Teste de Desempenho: teste realizado para avaliar a adequação de um sistema ou componente com determinados requisitos de desempenho (IEEE610, 1990);

Papéis da Equipe da Instituição:

Analista de Infraestrutura de TI: é o representante da área de infraestrutura para o projeto;

Responsabilidades:

Definir e executar projetos de implantação de infraestrutura de TI;
Identificar e instalar infraestrutura de hardware, software e serviços para ambientes de TI (Teste, Homologação,Produção);
Planejar, executar, acompanhar e controlar os projetos de infraestrutura de TI, identificando riscos e impactos e garantindo o cumprimento das tarefas e prazos;
Desenvolver e analisar indicadores de desempenho a fim de mensurar os objetivos e desempenho da área;
Garantir a padronização dos processos internos, disponibilizando internamente os documentos relativos à área de infraestrutura.

Analista de Qualidade: representa diferentes perfis ligados a avaliação de qualidade de software, tais como: Analista de Teste, Arquiteto de Software, Analista de Banco de Dados, Analista de Configuração e Mudança e outros.

Responsabilidades:

Avaliar e definir processos de verificação da qualidade dos produtos entregues pela Contratada (artefatos, incremento de software e release);
Realizar testes de sistemas.

Analista de Métricas: é o responsável pelos serviços de medição de software.

Responsabilidades:

Realizar medições de software utilizando a métrica definida no contrato com a empresa de desenvolvimento de software.

Cliente: representante da área de negócio.

Responsabilidades:

É responsável pela solicitação e homologação dos serviços de desenvolvimento de software.

Coach: profissional experiente nas práticas do processo ágil que zela pela sua correta execução. Deve ter profundo conhecimento

das práticas ágeis adotadas, pois é ele que guiará os outros envolvidos no projeto a executar o processo e

práticas de forma adequada. Esse papel pode ser exercido pelo líder de projeto.

Responsabilidades:

Conhecer e disseminar processo e práticas de desenvolvimento ágil na instituição;
Orientar na execução correta das práticas ágeis;
Comunicar e negociar;
Trabalhar em equipe.

Dono do Produto (Product Owner): representante da área de negócio com conhecimento suficiente para definir e priorizar

requisitos do negócio e responder aos questionamentos da equipe de desenvolvimento. É o representante do cliente

e sua atuação tem por finalidade garantir a entrega do valor esperado através do produto final do projeto.

Responsabilidades:

Estabelecer a visão do produto;
Aprovar o Roadmap de releases do produto;
Gerenciar o backlog do produto, fornecendo e priorizando os requisitos;
Definir prioridades de negócio;
Conhecer e transmitir o processo de negócio e seus objetivos;
Detalhar os requisitos de cada funcionalidade;
Aceitar ou rejeitar produtos e serviços;
Gerenciar as expectativas dos stakeholders;
Resolver os itens de backlog não planejados;
Aprovar mudanças no projeto;
Preparar e Realizar Treinamentos;
Dar apoio à equipe da contratada de desenvolvimento durante todo o projeto;

Obs: O dono do produto é uma pessoa e não um comitê. O dono do produto pode representar o desejo de um comitê

no backlog do produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de backlog devem

convencer o dono do produto.

Líder de Projeto: é responsável do órgão ou entidade pelo projeto, que se relaciona com todos os envolvidos e atividades

do projeto.

Responsabilidades:

Orientar e acompanhar a execução das atividades do projeto;
Recebe, comunica e resolve desvios e impedimentos do projeto;
Comunicar o andamento do projeto aos interessados;
Acompanhar o cronograma das atividades do planejamento, iterações e releases do projeto e das ordens deserviço;
Auxiliar na definição e acompanhamento dos riscos do projeto;
Avaliar junto à área de TI as necessidades de recursos;
Avaliar o andamento do(s) projeto(s);
Gerenciar treinamentos da equipe de suporte e sustentação;
Atualizar o portfólio de projetos, com o devido status do(s) projeto(s);
Gerar informações de desempenho do projeto;

Obs: Ressalta-se que na estrutura de pessoal das organizações públicas existe o cargo em comissão com a denominação Gerente de Projeto. Este cargo pertence ao grupo de Direção e Assessoramento Superiores (DAS). Por exemplo, conforme Decreto no 7.063/2010, existem na estrutura regimental do Ministério do

Planejamento, Orçamento e Gestão os cargos DAS 101.4 – Gerente de Projetos e DAS 101.5 – Diretor de Programa. Para que não ocorra conflito com as nomenclaturas existentes, utilizaremos aqui a denominação Líder de Projetos.

Usuário: tipo de stakeholder que usa o produto de software. Pode ser interno ou externo a instituição;

Responsabilidades:

Auxiliar na definição dos itens de backlog;
Auxiliar na homologação e validação das entregas do projeto;

Papeis Relacionados à Instrução Normativa 04/2014:

Gestor do Contrato: verificar (IN04, 2014).

Fiscal Requisitante do Contrato: verificar (IN04, 2014).

Fiscal Técnico do Contrato: verificar (IN04, 2014).

Fiscal Administrativo do Contrato: verificar (IN04, 2014).

Papéis da Equipe da Contratada de Desenvolvimento de Software:

Preposto: verificar (IN04, 2014).

Mestre Scrum (Scrum Master): é um dos representantes da contratada de desenvolvimento de software. Deve trabalhar para o sucesso do projeto através da entrega de valor para o cliente, viabilizada pela atuação eficaz da equipe de desenvolvimento e apoio ao dono do produto.

Responsabilidades:

Remover impedimentos da equipe de desenvolvimento (problemas técnicos, administração de conflitos,itens não planejados);
Auxiliar o dono do produto com técnicas para o gerenciamento efetivo do backlog do produto;
Comunicar claramente a visão, objetivo e itens do backlog do produto para a equipe de desenvolvimento;
Ser o facilitador da equipe de desenvolvimento, garantindo sua plena produtividade;
Garantir a colaboração entre os diversos papéis e funções da equipe de desenvolvimento;
Facilitar eventos e reuniões do Scrum conforme exigidos ou necessários;
Aplicar e disseminar valores e práticas Scrum.

Equipe de Desenvolvimento (Time de Desenvolvimento): é um grupo de cinco a nove integrantes da contratada de desenvolvimento de software, que deve possuir uma característica multifuncional, auto-organizados, contando com analistas, arquitetos, programadores, testadores, administrador de banco de dados entre outros. Individualmente os integrantes da Equipe de desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence a toda equipe de desenvolvimento.

Responsabilidades:

Fazer as estimativas necessárias;
Definir as tarefas que serão realizadas;
Desenvolver o produto;
Realizar repasses de conhecimento para as equipes de suporte e sustentação;
Garantir a qualidade do produto;
Apresentar o produto ao cliente.

Gerente de Relacionamento (opcional): realiza o acompanhamento de todo o ciclo de atendimento da ordem de serviço

garantindo as entregas conforme compromissos firmados.

Responsabilidades:

Acompanhar o atendimento da Ordem Serviço no âmbito da contratada;
Identificar desvios e providenciar as ações necessárias para correção de rumos dentre todos os envolvidos;
A partir das necessidades do Dono do Produto, auxiliar no mapeamento de soluções;
Acompanhar o cronograma geral de atendimento e os compromissos firmados entre os envolvidos.
Agrupamentos em Equipes:
Equipe do Projeto: todos os envolvidos no projeto, equipe da instituição e equipe da contratada.

Principais Artefatos

Backlog da Iteração: é um subconjunto do backlog do produto, priorizado na reunião de planejamento pelos clientes e dono do produto e que representa os itens que serão desenvolvidos em uma determinado Iteração;

Backlog do Produto: é uma lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O backlog do produto lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto;

Documento de Visão: documento que contém as informações identificadas durante o entendimento da demanda, tais como objetivos de negócio, características-chaves, aspectos tecnológicos e riscos, utilizados para orientar o desenvolvimento do produto de software;

História de Usuário: descrição curta de uma característica-chave do produto contada na perspectiva do usuário, utilizando uma linguagem comum ao negócio e testes, que podem ser utilizados para determinar quando a história estará completa;

Gráfico Burndown: gráfico que mostra o esforço restante para a conclusão da iteração, bem como mostrar o quão próximo ou distante a equipe de desenvolvimento está de atingir a meta;

Plano do Release: descreve informações importantes do release, tais como: metas do release, quantidade e duração de Iterações, equipe do projeto, data estimada da entrega, valor estimado do release, premissas, riscos e impedimentos;

Plano da Iteração: descreve informações importantes da Iteração, tais como: Meta da Iteração, data inicial e final da Iteração, definições de pronto, itens de backlog selecionados e outros;

Quadro de Tarefas: tem por objetivo transformar o trabalho em andamento da iteração visível em um quadro para toda equipe, criando um sinal visual que indica que uma nova tarefa pode ou não ser iniciada, se iniciada mostra seu andamento e se o limite acordado de tarefas, para cada iteração, está sendo respeitado.

Roadmap: é uma visão global das necessidades do produto e uma ferramenta valiosa para o planejamento e organização da jornada de desenvolvimento de produtos. O dono do produto cria o roadmap de produtos, com a ajuda da equipe de desenvolvimento. O roteiro é usado para categorizar os requisitos, para priorizá-los, e para determinar um calendário para a sua liberação.

Reuniões da Iteração: Reunião de Planejamento da Iteração: consiste em uma reunião realizada no início de cada Iteração para planejar e

definir o que será entregue;

Reunião de Demonstração da Iteração: consiste em uma reunião executada no final da Iteração para demonstrar o incremento de software produzido;

Reunião de Retrospectiva da Iteração: consiste em uma reunião realizada no fim de cada Iteração, para registrar as lições aprendidas e fazer os ajustes possíveis para a próxima iteração, proporcionando assim, a melhoria contínua do processo.

Fluxo de Valor do Produto

A finalidade da construção de projetos de software é a entrega de um produto (ou versão funcional do produto de software) e a finalidade do produto é a entrega de valor agregado para o cliente. A entrega de valor é efetivada, através do atendimento das necessidades e expectativas do cliente. Os grupos de atividades de planejamento, construção do release e transição da figura 2 apresentam um fluxo de valor do produto de software, baseado na proposta descrita em Scrumex (Scrumex, 2014). Itens que determinam o fluxo de valor estão destacados na figura 2 pela cor alaranjada (objetivos de negócio, características-chaves do produto, requisitos, incremento de software e release). O modelo de construção de projetos de software, proposto neste guia, é realizado através de ciclos de entregas incrementais, por meio de releases. Os ciclos de entrega envolvem os grupos de atividades de planejamento, construção do release e transição, um para cada release. Após a finalização do grupo de atividades de construção do release é feita a transição dos produtos para o ambiente de produção. Nos tópicos abaixo serão descritos artefatos e informações que determinam o fluxo de valor do produto de software que permeia cada grupo de atividades de construção do projeto do modelo de referência da figura 2.

Fluxo de Valor entre Visão e Roadmap do Produto

O fluxo de valor do produto de software inicia-se no grupo de atividades de planejamento (construir a visão do produto e planejar o roadmap - cor azul escuro da figura 2), o qual consiste na identificação e compreensão das necessidades, problemas, objetivos de negócio, características-chaves do produto (software features), oportunidades, desafios e expectativas dos clientes. Também se Inclui neste grupo a elaboração do roadmap de releases. Ver a apresentação na figura 2. A compreensão do atual funcionamento dos processos de negócio é importante para capturar as problemáticas e insatisfações do cliente para, finalmente, identificar as macrofunções de uma possível solução. As características-chaves ou macrofunções são atributos de valor ou serviços providos pela solução, derivados dos objetivos de negócio, para satisfazer necessidades de negócio dos clientes, em outros termos, são os aspectos mais relevantes do produto de software que o cliente valorizará com mais facilidade. O artefato visão do produto reúne todo este conhecimento adquirido por meio de técnicas de elicitação de requisitos de software e análise de negócio. Para o mapeamento dos releases no roadmap, também é importante a discussão prévia da arquitetura inicial e a identidade visual do software a fim de identificar itens de backlog necessários para a primeira entrega. A Figura 3 ilustra o fluxo de valor entre visão do produto e do roadmap. Figura 3. Roadmap do Produto. Roadmap do Produto Características funcionais pendentes, melhorias no software, novas solicitações, correções, etc. Visão do Produto Release 1 Objetivos de Data Negócio Características Chaves do Produto Release 2 Release N Entrega de Valor Data Data 25 Guia de Projetos de Software com Práticas de Métodos Ágeis para o SISP Após a concepção do Documento de Visão, inicia-se o planejamento de cada entrega (release) o qual consiste no agrupamento de objetivos de negócio e características-chaves do produto por meio de critérios de priorização e de importância. Cada release é o lançamento de uma determinada versão de software incrementada com novas funcionalidades, as quais satisfazem determinados objetivos de negócio e características-chaves do produto de software. O registro cronológico de releases, assim como objetivos de negócio e características-chaves associadas, poderão ser consolidadas em um roadmap de entregas (planejamento de liberação de versões).

Fluxo de Valor no Planejamento do Release

O planejamento do release está contido no grupo de atividades de construção do release (atividades de cor verde da figura 2). O início de cada planejamento do release é marcado pela elaboração do backlog do produto, técnica extraída do Scrum. O backlog desdobra objetivos de negócio e características-chave do produto em requisitos de software (funcionais e não funcionais) e tarefas técnicas importantes para a construção de produtos de software. Para cada release, uma ou mais iterações deverão ocorrer. Este fluxo de valor está ilustrado na figura 4. Figura 4. Planejamento do Release. O planejamento do release, portanto, consiste em desdobrar objetivos de negócio e características-chaves do produto, correspondidas por itens de backlog. Os itens de backlog podem pertencer a um ou mais backlog de iterações. Eles são orientados por critérios de priorização de seleção de requisitos e cronograma do projeto. Nessa fase também devem ser definidos os conceitos de pronto e preparado, e qual será a duração fixa das iterações. Esse planejamento define o plano do release.

15.3.Fluxo de Valor na Iteração Na figura 2, nas atividades de construção do release, cada Iteração se inicia com planejamento específico, conforme a figura 5, onde é gerado o plano da iteração, com o objetivo de gerar um incremento de software. Os requisitos ou histórias de usuários contidas no backlog do release são selecionados conforme critérios definidos pelo dono do produto e equipe de desenvolvimento para compor o backlog da iteração. Esse backlog é consumido para produzir o incremento de softwaPlanejamento do Release Plano do Release Duração Objetivos de Negócio Características-Chaves do Produto Elaborar o Backlog do produto Data da Entrega Especificação Projeto Construção Teste Especificação Projeto Construção Teste Métrica Riscos Objetivos de Negócio ou Metas Custo e Esforço Especificação Projeto Construção Teste Backlog do Produto 26 Guia de Projetos de Software com Práticas de Métodos Ágeis para o SISP re da iteração. Durante a execução da Iteração, a critério da contratada, são executadas reuniões diárias e, ao final da iteração, é realizada a demonstração do produto e a retrospectiva da iteração. A validação do incremento de software da iteração poderá ocorrer em paralelo com a próxima iteração. Figura 5. Planejamento da Iteração.

Fluxo de Valor na Transição

As atividades de transição estão destacadas na figura 2 pela cor roxa. Cada release é homologado e liberado nas atividades de transição na forma de uma versão funcional e pronto para disponibilizar no ambiente de produção. Portanto as atividades de transição visam garantir que clientes e usuários tenham condições de usar o produto de software. Para facilitar o entendimento da cadeia de valor do produto de software apresentado nos grupos de atividades de construção do projeto apresentado na Figura 2, foi disponibilizado no Anexo II uma exemplificação dos itens que participam da cadeia de valor.