Engenharia de Software Ágil: SCRUM e FDD

Share Embed Donate


Short Description

SCRUM e o FDD são Métodos Ágeis que são utilizados para desenvolvimento de software. Fizemos uma pequena demonstração de...

Description

Engenharia de Software Ágil    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

SCRUM e FDD

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Rildo F Santos

[email protected] [email protected] r twitter: @rildosan blog: http://rildosan.blogspot.com/

Sobre o autor: Rildo F. Santos    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Coach e Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil. A Gestão Ágil ajuda as empresas a responder mais rápido as demandas de negócio e mudanças. A Gestão 2.0, abrange Planejamento Estratégico, Gestão por Processos Ágeis, Gestão de Projetos Ágeis, Tecnologia da Informação (Métodos Ágeis), Inovação e Liderança. Minha Experiência: Tenho mais de 10.000 horas de experiência experiência em Gestão de Negócios, Gestão de Inovação, I novação, Governança Governança e Engenharia de Software. Formado em Administração de Empresas, Pós-Graduado Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia Engenharia de Software pela Universidade Mackenzie.

Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java na Sun Microsystems Microsystems e na IBM. Conheço Métodos Ágeis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço), RUP/UP - Processo Unificado, Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias. Sou professor de curso de MBA da Fiap e f ui professor de pós-graduação da Fasp e IBTA. Possuo fortes conhecimentos conhecimentos de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e GRC - Governance, Governance, Risk and Compliance), SOX, Basel Basel II e PCI; E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento Conheciment o dos principais frameworks e padrões: ITIL, Cobit, ISO 27001 e ISO 15999; Desempenhei Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software, Projetista de Software e Analista de Sistema em diversos segmentos: Financeiro, Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, Comunicação, Segurança Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás. Possuo as certificações: CSM - Certified SCRUM Master, Master, CSPO - Certified SCRUM SCRUM Product Owner , SUN Java Certified Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games; Sou membro do IIBA-International IIBA-International Institute of Business Analysis Analysis (Canada) Onde estou: Twitter: http://twitter.com/rildosan Blog: http://rildosan.blogspot.com/

Comentário inicial:    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Para desenvolver um software (ou produto), os métodos ágeis são altamente recomendáveis, recomendáveis, contudo, sempre existem muitas dúvidas na adoção dos métodos: - Quais Quais métodos métodos devemos devemos usar usar ? - Posso usar mais de um método para para desenvolver desenvolver um software software ? - Quais são as práticas de engenharia engenharia de software software que devemos utilizar utilizar ? - A metodologia de desenvolvimento desenvolvimento existente poderá ser utilizada utilizada junto com o SCRUM ? - Poderei elaborar o “Product Backlog” a partir dos Casos de Uso ? - Como utiliz utilizar ar SCRUM SCRUM e FDD juntos juntos ? Nesta apresentação responderemos algumas questões, mas focaremos na questão: Como utilizar SCRUM e FDD juntos ?

Método Ágil, Respostas:    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

- Quais são as prátic práticas as de engenharia engenharia de software software que devemos utilizar ? R: você poderá utilizar as práticas de engenharia que já são conhecidas da sua equipe ou utilizar as práticas de engenharia de software ágeis, tais como: FDD FD D e XP. XP. - A minha metodologia de desenvolvimento será que poderei utilizar junto com o SCRUM ? R: Sim, o SCRUM é um framework para o Gerenciamento de Projetos, é possível usar uma metodologia de desenvolvimento de software junto com SCRUM (principalmente se ela for focada em práticas de engenharia de software)

- Poderei elaborar o “Product Backlog” a partir dos Casos de Uso ?    M R: Sim, é possível utilizar toda experiência, o  ,    i   g conhecimento e cultura adquirida com o SCRUM.    A   z    i    B    l   a    i   r   o    t   u    T

- Posso utiliza utilizarr SCRUM e FDD juntos juntos ? R. Sim, vou responder de forma mais detalhada esta questão...

Como utilizar SCRUM e FDD juntos ?    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

SCRUM

FDD

Eles são compatíveis ? Qual é o papel de cada um no processo processo de desenvolvimento desenvolvimento de software ? Eles são complementares ?

O que é o SCRUM ?    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

The New, New Product Development Game

TimeBoxes

SmallTalk Engineering Tools

Iterative, Incremental Development

O que é SCRUM ? SCRUM é um processo iterativo e incremental para desenvolvimento de qualquer produto ou gerenciamento de qualquer trabalho... SRUM é: Processo Proces so empírico empírico de gerenciamento gerenciamento e controle. - Faz a inspeção inspeção e adaptação adaptação em em loops de feedback - Faz entrega entrega de valor valor ao cliente em em até 30 dias; - “Escalável” para suportar grandes projetos - Comp Compatíve atívell com CMM3 e ISO9001 ISO9001 - Extrem Extremamente amente simples, simples, mas mas muito resistente... Valores do Scrum: Valores Scrum::: - Transp ransparênc arência ia -Integridade: assim que perceber algo, faça algo - Ser empírico - Au Auto-org to-organiza anização ção - Ent Entreg regaa de valor valor

O coração do SCRUM    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Legenda:

Revisão da Sprint

Planejamento da Sprint

Cerimônias

Retrospectiva da Sprint

Reunião diária

artefatos

24 horas Visão

Produto Backlog

Sprint Backlog 2-4 Semanas

Papéis • Product Owner (PO) • ScrumMaster (SM) • Equipe Scrum

Cerimônias

Produto

Artefatos

• Planejamento da Sprint • Product Backlog • Reunião Diária • Sprint Backlog • Revisão da Sprint • Burndown (gráfico) • Retrospectiva da Sprint

Burndown

ROAD MAP do SCRUM    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Visão do Produto

Planejamento da Sprint

Product Backlog

Selected Selected Product Product Backlog

Sprint Backlog Tarefas da Sprint

Reunião diária

Product Onwer facilita ajuda

Equipe

SCRUM Master facilita facilita

Execução da Sprint

Revisão da Sprint Produto Retrospectiva da Sprint

Papéis    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

O SCRUM tem somente três papéis: Product Onwer (PO), SCRUM Master (SM) e a equipe SCRUM. Product Owner, responsável por: - Defin Definir ir a Visão Visão do Produto Produto - Elabo Elaborar rar e mante manterr o Produc Productt Backlog - Definir a prioridade e ROI; - Repre Representa sentarr o clien cliente te - Aceitar ou rejeitar os entregáveis SCRUM Master é responsável por: - Ser um um líder líder (servidor); (servidor); - Remover Remover impedi impedimento mentos; s; - Proteger a equipe; - Aj Ajuda udarr o PO (com Product Backlog);  - Ser o facilit facilitador ador da equipe equipe;; - Garantir as práticas SCRUM. Equipe SCRUM é responsável por: - Fazer Fazer estimati estimativa va;; - Definir Definir as as tarefas; tarefas; - Desenvolver o produto; - Garantir a qualidade do produto; - Apresenta Apresentarr o produto ao cliente cliente Equipe: auto-gerenciável e multifuncional 

A Equipe e Comprometimento:    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Envolvidos

Comprometidos

Stakeholders (clientes e usuários finais)

Product Onwer

Equipe

SCRUM Master

Cerimônias:    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

Reunião de Planejamento da Sprint (8 horas) Participantes: PO, Equipe e SCRUM MASTER Esta reunião é primeira reunião, seu objetivo é fazer o planejamento da Sprint. Ela é dividida em duas partes.Na primeira parte o PO definirá prioridade, seleção dos itens do backlog e meta da Sprint. Na segunda parte a equipe definirá a Sprint Backlog (que são as tarefas necessárias necessárias para cumprir a meta).

Reunião Diária (15 minutos) Participantes: Equipe e SCRUM MASTER M ASTER Nesta reunião somente membros da equipe devem participar. A duração dela é de 15 minutos. As pessoas  fazem a reunião de pé. O objetivo desta reunião é fazer que as pessoas respondam 3 questões: - O que eu fiz ontem ontem ? - O que vou vou fazer hoje ? - Encontrei Encontrei algum impedime impedimento nto ?

Revisão da Sprint (4 horas*) Participantes: PO, Equipe e SCRUM MASTER

Esta reunião acontece no final da Sprint, opcionalmente outras pessoas podem ser convidadas (se necessário).    M O objetivo da reunião é apresentar o que a equipe fez durante a Sprint e fazer a entrega do produto (software  , funcionando) para o PO. (Normalmente é apresentado uma demo do software).    i   g Geralmente ela é feita em um auditório ou em uma sala de reunião    A   z    i    B    l   a    i   r   o    t   u    T

Retrospectiva da Sprint (3 horas*) Participantes: Equipe e SCRUM MASTER M ASTER Esta reunião acontece logo após a Revisão da Sprint. O objetivo dela é avaliar o que deu certo e que deu errado durante a Sprint, e fazer os ajustes possíveis possíveis para a próxima Sprint, ou seja, o ciclo de melhoria contínua.

O que é o FDD (Feature Driven Development) Development) ?    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) é uma metodologia ágil para gerenciamento e desenvolvimento de software.

Ela combina as melhores práticas do gerenciamento ágil de projetos com uma abordagem completa para Engenharia de Software orientada por objetos, conquistando os três principais públicos de um projeto de software: - Cl Clie ient ntes es,, - Gere Gerent ntes es,, -Desenvolvedores. Seus princípios e práticas proporcionam um equilíbrio entre as filosofias tradicionais e as mais    M extremas, proporcionando proporcionando uma transição mais suave  ,    i conservadoras, e a   g para organizações mais conservadoras,    A   z retomada da responsabilidade para as organizações    i    B    l que se desiludiram com as propostas mais radicais.   a    i   r   o    t   u    T

O lema da FDD é: "Resultados freqüentes, tangíveis e funcionais."

O FDD FDD foi criada em 1997 num grande grande projeto em Java para o United Overseas Bank, em Singapura. Nasceu a partir da experiência de análise e modelagem orientadas por objetos de Peter Coad, e de gerenciamento de projetos de Jeff De Luca. Foi inicialmente publicada em 1999, no capítulo 6 do livro "Java Modeling in Color with UML", de Peter Coad, Eric Lefebvre e Jeff De Luca . Em 2002, Stephen Palmer (gerente de desenvolvimento do projeto em Singapura) e John Mac Felsing (arquiteto senior na TogetherSoft) TogetherSoft) publicaram o livro "A Practical Guide to Feature Driven Development", com a versão completa, atualizada e comentada da metodologia. Em 2003, David Anderson, que foi o especialista em interface com o usuário, no projeto de Cingapura, publicou um marco na literatura Ágil, " Agile Management for Software Engineering: Using the Theory of Constraints for Business Results", onde oferece uma análise profunda sobre a FDD (entre outras metodologias), além de material inédito sobre a FDD.

FDD (Feature Driven Development) Development)    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

O que é o FDD (Feature Driven Development) Development) ?    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

A FDD é uma metodologia muito objetiva. Possui apenas duas fases: - Concepção & Planejamento: Pensar um pouco antes de fazer (tipicamente de 1 a 2 semanas) - Construção: Fazer de forma iterativa (tipicamente em iterações de 2 semanas) Os cinco processos são bem definidos e integrados: DMA (Desenvolver um Modelo Abrangente): Abrangente): Análise Orientada por Objetos CLF (Construir a Lista de Funcionalidades): Decomposição Funcional PPF (Planejar por Funcionalidade): Planejamento Incremental DPF (Detalhar por Funcionalidade): Desenho (Projeto) Orientado por Objetos Teste Orientados por Objetos CPF (Construir por Funcionalidade): Programação e Teste

A FDD chama a atenção por algumas características peculiares: - Resultados Resultados úteis a cada cada duas duas semanas semanas ou ou menos menos - Blocos bem bem pequenos pequenos de funcionalidade funcionalidade valorizad valorizadaa pelo cliente, cliente, chamados chamados "Features" "Features" - Planejament Planejamentoo detalh detalhado ado e guia guia para para medição medição - Rastre Rastreabi abilida lidade de e relat relatóri órios os - Monitoramen Monitoramento to detalhado detalhado dentro dentro do projeto, projeto, com resumos resumos de alto alto nível para para clientes clientes e gerentes, tudo em termos de negócio - Fornece Fornece uma forma de saber saber,, dentro dos dos primeiros primeiros 10% de um projeto, projeto, se o plano e a estimativa são sólidos

Os Processos    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

A FDD é, classicamente, descrita por cinco processos: DMA - Desenvolver um Modelo Modelo Abrangente: Abrangente: pode envolver desenvolvimento de requisitos, análise orientada por objetos, modelagem lógica de dados e outras técnicas para entendimento do domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção. CLF - Construir Construir uma Lista de Funcionalidad Funcionalidades: es: decomposição funcional do modelo do domínio, em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados da atividade (funcionalidades). O resultado é uma hierarquia de funcionalidades que representa o produto a ser construído (também chamado de product backlog , ou lista de espera do produto). PPF - Planejar Planejar por Funcional Funcionalidade: idade: abrange a estimativa de complexidade e dependência das funcionalidades, também levando em consideração a prioridade e valor para o negócio/cliente. O resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada para a construção. DPF - Detalhar Detalhar por Funcionali Funcionalidade: dade: já  já dentro de uma iteração de construção, a equipe detalha os requisitos e outros artefatos para a codificação de cada funcionalidade, incluindo os testes. O projeto para as funcionalidades é inspecionado. O resultado é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos. CPF - Construir Construir por Funciona Funcionalidade lidade:: cada esqueleto de código é preenchido, testado e inspecionado. O resultado é um incremento do produto integrado ao repositório principal de código, com qualidade e potencial para ser usado pelo cliente/usuário.

Visão da Arquitetura: Arquitetura:    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Apresentação (Visões (Visões e Controlado Controladores res de Interfa Interface) ce)

Negócio (Domínio do Problema)

Persistência

Inte Interf rfac acee com com outros sistemas

Sobre UML Color    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

UML (Unified Modeling Language). O sistema de UML Color é um conjunto de quatro cores associadas a UML coloração indica quais vários arquétipos se aplicam ao objeto UML. UML tipicamente identifica um estereótipo com um comentário entre parênteses, para cada objeto que identifica se é uma classe, interface, etc.

Estas cores foram pela primeira vez sugerida por Peter Coad , Eric Lefebvre e Jeff De Luca em uma série de artigos no The Letter Coad e posteriormente publicado em seu livro Java  Modeling em cores com UML.

Ao longo de centenas de modelos de domínio, ficou claro que quatro grandes "tipos" de classes apareceu de novo e de novo - apenas um nome diferente para se adequar ao domínio. Estes eram chamados de arquétipos (depois de muita discussão), que serve para transmitir que as classes de um arquétipo dado seguem mais ou menos da mesma forma. Isto é, atributos , métodos , associações e interfaces são bastante semelhantes entre as classes de um determinado arquétipo. Ao tentar classificar um determinado domínio de classe, tipicamente uma pergunta sobre os padrões de cor, nesta ordem: Rosa: momento, intervalo - Será que representam um momento ou intervalo intervalo de tempo? Um exemplo seria um objeto que armazena temporariamente temporariamente as informações de login durante o processo de Autenticação.

Amarelo Amarelo - papéis papéis - É uma maneira de participar participar de uma atividade (por qualquer pessoa, lugar ou coisa) ? Assinatura em um sistema como um administrador, que muda o comportamento do programa,    M exigindo uma senha que contas de convidado não, é um exemplo.  ,    i   g Azul - Descrição Descrição - É simplesmente uma descrição descrição do catálogo-como a que classifica ou objeto 'rótulos„ Um ?    A Azul   z Se os usuários do sistema são rotulados com base no departamento de uma empresa em que trabalham    i    B dentro e isso não muda a forma como o sistema se comporta, isso seria uma    l   a descrição.    i   r parte, lugar ou coisa coisa - algo tangível, unicamente unicamente identificável. Normalmente, se você passar a   o Verde - parte,    t   u três perguntas acima e acabam por aqui, sua classe é um verde ". O usuário do sistema e as    T sub-seções do sistema são todos os que visitam PPTs.

Exemplo: UML em cores:    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

As disciplinas envolvidas:    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

Gestão Ágil de Projetos

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Fonte: Adail Muniz Retamal - www.heptagon.com

Juntando o SCRUM e o FDD:    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

SCRUM

Gerenciamento de Projeto

FDD

Engenharia de Software

O SCRUM e o FDD são complementares em muitos aspectos: -Podemos utilizar o SCRUM para o Gerenciamento - E o FDD para as práticas de Engenharia de Software

Gerenciamento (SCRUM) e Engenharia de Software (FDD, XP)    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

SCRUM

Gestão de Projeto

FDD

Engenharia de software

Juntando o SCRUM e o FDD:    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

FBS: Feature Breakdown Structure(FDD)    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

FBS (Feature BreakDown BreakDown Structure) é uma prática para engenharia engenharia de requisito requisito FBS cria uma “estrutura analista de funcionalidades”, como estamos trabalhando com FDD, cada

deve representar um item do Product Backlog

feature

O Que é Feature ? (Pela visão da FDD)    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

Funcionalidade (ou característica) Pequena o suficiente para ser implementada no máximo em 01 iteração Oferece valor para o cliente Mapeia passos em uma atividade de negócio:  – Pode ser um passo de um Caso de Uso (ou user stories)  – Às vezes pode ser o próprio Caso de Uso (ou user stories) Conceito muito próximo ao de um requisito funcional Modelo: < ação> ação> resultado> - Liberar Liberar apartamento apartamento para para locação - Calcular Calcular o total total de uma nota fiscal - Autorizar Autorizar uma transação transação com cartão cartão - Emitir Emitir uma nota nota fisca fiscall - Calcular Calcular total total da conta do do cliente cliente - Imprimir Imprimir o relatório relatório para conferê conferência ncia

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T Fonte: Adail Adail Muniz Retamal - www.heptagon.com

Modelando Modelando Funcion Funcionalida alidades des com Mind Map: Map:    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Gerenciado ROI com Business Value    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Business Value será uma moeda de troca durante o projeto e o cliente empresta um determinado valor dessa moeda para a equipe equipe e esta por sua vez, terá que devolver o valor correspondente em forma de software, ou seja, s eja, é uma dívida que a equipe assume com o cliente e que deverá ser amortizada a cada ciclo(Sprint), até que a mesma seja totalmente liquidada l iquidada (zerada). Exemplo de Product BackLog baseado no FDD: Business Value

Área de Negócio

Item

100

Reserva

Os clientes poderão fazer reserva de apartamento

50

Reserva

Os clientes poderão cancelar a reserva

50

Reserva

Os clientes poderão fazer alterações de data da reserva

40

Reserva

Os cliente poderão fazer consulta de reservas

100

Reserva

Criação de o Book de Reserva

80

Pagamento

O meio de pagamento da reserva serão por cartão de crédito

60

Apartamento

Os apartamentos deverão ser cadastros

40

Apar Aparta tame ment ntoo

Os apar aparta tame ment ntos os são são clas classi sififica cado doss por por cate catego gori riaa

60

Cliente

Precisamos registrar os dados dos clientes

OK ?    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Você Você já percebeu percebeu que que utilizar utilizar o SCRUM e FDD juntos juntos pode facilitar e potencializar o entendimento dos requisitos de software. O SCRUM é excelente para o Gerenciamento de Projetos, contudo existe uma lacuna l acuna entre a Gestão de Projetos baseada em SCRUM e as práticas de engenharia de software. Ao utilizarmos o FDD conseguimos reduzir esta lacuna e se aproximar da Engenharia de Software Ágil. Devemos combinar, combinar, juntar as melhores práticas de cada método para termos um processo completo de Gestão de Projetos e de Engenharia de software Ágil

Gostou ?    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Gostou...Que saber mais, conhecer mais os métodos ágeis, como SCRUM SCR UM FDD e XP: Participe do nosso treinamento: Formação de Engenharia de Software Ágil Entre em contato: - eventos@ eventos@compan companyweb.co yweb.com.br m.br - [email protected] - rildo.santos rildo.santos@etec @etecnologi nologia.com.b a.com.brr

Formação Engenharia de Software Ágil As melhores práticas para o desenvolvimento de software ágil Conteúdo Programático Gestão de Projeto de desenvolvimento de Software com SCRUM (16 horas) - Ciclo de Produto (8 horas) : •Papel do Product Onwer •Visão do Produto •Roadmap do Produto •Plano de Release do Produto •Product Backlog •*Workshop do Produto e Requisitos  - Ciclo do Processo (8 horas) horas) Papel do SCRUM Master Papel da Equipe SCRUM Reunião de Planejamento: •Estimativa •Definição DoD •Sprint Backlog •Reuniões Diárias •Impedimentos

- Engenharia de Software Software com as práticas FDD+BDD e XP (8 horas) Ciclo do desenvolvimento da Sprint com práticas FDD, XP e BDD Revisão da Sprint (Revisão do produto da Sprint) Retrospectiva (Revisão do processo - Lições aprendidas) Implementação da Fábrica Ágil (8 horas) Planejamento da implementação da Fábrica Ágil Fatores críticos de sucesso Ferramentas, pessoas e processos Capacitação da equipe

Carga horária: 32 horas Local: São Paulo

Referências e Créditos:    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

FDD, Créditos: Adail Muniz Retamal - www.heptagon.com Manoel Pimentel Pimentel Medeiros (Visão Ágil - http://www.visaoagil.com ) SCRUM: SCRUM Product Owner http://www.slideshare.net/Ridlo/scrum-product-owner

SCRUM Experience http://www.slideshar http://www.slideshare.net/Ridl e.net/Ridlo/scrum-exper o/scrum-experience-o-tutor ience-o-tutorial-scrum ial-scrum

Quer Mais ?    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Gostou quer mais, gostaria de receber outros materiais sobre o mesmo tema e novas versões deste material... Envie um e- mail para com subject: “Quero entrar na comunidade” para [email protected] que te enviaremos um convite para participar participar da nossa comunidade comunidade

http://etecnologia.ning.com/

Notas:    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Marcas Registrada Registradas: s: Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial são de responsabilidade de seus proprietários. O autor informa não estar associada a nenhum produto e/ou fornecedor apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já o autor informa que o uso é apenas ilustrativo e/ou educativo, não visando ao lucro, favorecimento ou desmerecimento do produto/fabricante.

Melhoria e Revisão: Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema ou erro envie um e-mail nós. Criticas e Sugestões: Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um e-mail para nós. Imagens: Google, Flickr e Banco de Imagem.

Rildo F dos Santos ([email protected] ([email protected]) om.br)

Licença:    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Engenharia de Software Ágil    N    M    P    B   m   o   c   s   o    i   c    ó   g   e    N   e    d   s   o   s   s   e   c   o   r    P   e    d   m   e   g   a    l   e    d   o

SCRUM e FDD

   M  ,    i   g    A   z    i    B    l   a    i   r   o    t   u    T

Rildo F Santos

[email protected] [email protected] r twitter: @rildosan blog: http://rildosan.blogspot.com/

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF