Aula FDD CESAR Recife GAP

• Engº Jorge Luis Bublitz

CESAR - GAPDESENVOLVIMENTO DIRIGIDO

A FUNCIONALIDADES"A FDD disciplina as equipes a pensarem um pouco antes

de sair fazendo e a fazer aos poucos enquanto continuam aprendendo, demonstrando claramente o que

vão fazer e o que estão fazendo."

sexta-feira, 22 de abril de 2011

• Contexto

• Metodologias

• Agilidade e Metodologias Ágeis

• Mudanças

• FDD

Agenda


Contexto


“É o ato de elaborar e implementar um sistema computacional, isto é,

transformar a necessidade de um utilizador ou de um mercado em um

produto de software.”

Nick Birrell

A Practical Handbook for Software

Development, 1985

O que é Desenvolvimento de Software?


• Caótica• Eterno ciclo “programar e depurar”• Sem planejamento claramente definido• Dificuldade em adicionar novos

recursos (funcionalidades)• Fase de testes e depuração na

produção• Estimativa de Tempo/Custo difícil de

ser determinada

Características


The Caos Report - 1995

Concluídos com Sucesso16%

Concluídos com Alterações53%

Falharam31%

Standish Group – www.standishgroup.com





Falharam23%






Falharam24%



Vamos Analisar

25,00 50,00 75,00 100,00

19941996199820002002200420062009

Sucesso Alterações Falharam



Funcionalidades/Funções Utilizadas em um Sistema

Sempre7%

Muito13%

Algumas Vezes16%

Raramente19%

Nunca45%



http://www.standishgroup.com

http://www.standishgroup.com

Culpado(s)???

Clientes

AnalistasDesenvolvedores

Processo

Ferramentas


• Não existe uma solução mágica e única, mas sim um conjunto de práticas reconhecidamente eficientes.

• Desenvolvimento Incremental, Refinamento de Requisitos, BONS PROJETISTAS...

A Solução é...


• Melhorar a qualidade do software implica na melhoria do processo pelo qual o mesmo é produzido.

• Assumir práticas de sucesso

• Garantir que estas práticas serão seguidas durante o desenvolvimento

• Ser fácil de seguir

• Evoluir com o aprendizado do grupo

A Solução é...


• Adoção de Metodologias• Objetivo: tornar o desenvolvimento

mais previsível e mais eficiente• Impõe disciplinas rígidas• Processos detalhados• Planejamento é a ênfase• Passam a impressão de serem uma

PANACÉIA

A Solução utilizada até hoje:


Metodologias


Levantamento de Requisitos

Projeto

Implementação

Testes

Implantação

Modelo Tradicional


• Também chamado de Modelo em Cascata (Waterfall)

• Proposto por Winston W. Royce - 1970!!!• Orientado para documentação• Ênfase em planejamento, horários, prazos,

orçamentos e implementação de sistemas inteiros

• Há variantes: Incremental, Evolucionário, ...

Modelo Tradicional


Novos Tempos (??)

Maior Qualidade

Menor Custo

Menor Tempo


Novos Problemas (?)

Escopo

Qualidade Prazo

Custo


Análise OO


• É um método de análise que examina os requisitos a partir da perspectiva das classes e objetos encontrados no vocabulário do domínio do problema

• Enfatiza a construção de modelos do mundo real usando uma visão de mundo orientada por objetos

Análise Orientada por Objetos


Em meados dos anos 70 e início dos anos 80 (1989 a 1994) vários métodos de

modelagem orientada a objetos surgiram, sendo que os principais foram:

• Booch (Grady Booch)• OMT (Rumbaugh)• OOSE (Jacobson)• Shlaer/Mellor (Sally Shlaer e Stephen

Mellor)• Coad/Yourdon (Peter Coad e Ed

Yourdon)

Métodos Orientados a Objetos


Neste cenário Grady Booch e James Rumbaugh juntaram forças através da Rational Corporation para unificar os métodos Booch e OMT que resultou

na versão 0.8 do Método Unificado, lançado em outubro de 1995.

Grady Booch James Rumbaugh .

Método Unificado


• No final de 1995, Ivar Jacobson juntou-se a equipe fundindo o método OOSE (Object-Oriented Software Engineering)

• Booch, Rumbaugh e Jacobson estavam motivados a criar uma linguagem unificada para modelar sistemas complexos de qualquer tipo:

• missão crítica• tempo real• cliente/servidor

• Após o apoio de parceiros importantes como Microsoft, Hewlett-Packard, Oracle, IBM, dentre outras em janeiro de 1997 foi lançado a UML 1.0 (Unified Modeling Language)

UML


Evolução


• Estáticos:• Use Cases• Classes• Pacotes

• Dinâmicos:• Interação

• Sequência• Colaboração

• Estado (Statechart)• Atividade

Diagramas da UML


Caso de Uso


Classe


Seqüência


Atividade


Estado


• Análise Essencial dizia O QUE fazer e QUANDO

• Quando surge a UML, o mercado queria uma um substituto para a Análise Essencial

• UML é uma Linguagem e não um Processo

• Ela fornece os elementos, mas não define QUANDO usar

• O mercado rejeitou a UML por não compreendê-la

A Decepção


Agilidade e Metodologias Ágeis


• a.gi.li.da.de sf (lat agilitate)

1. Qualidade do que é ágil

2. Desembaraço, ligeireza, presteza de movimentos

3. Mobilidade, perspicácia, vivacidade• Geralmente associa-se

AGILIDADE com Rapidez, Flexibilidade, Leveza

Agilidade


“Agilidade é a habilidade para criar e responder às mudanças, para lucrar

num ambiente turbulento de negócios, para equilibrar flexibilidade

e estabilidade.”Jim Highsmith

Agile Software Development Ecosystems

2002

Agilidade - Software


• Antes chamadas de “Metodologias Leves”

• Tornou-se popular no ano de 2001

• 17 grandes pensadores em processo de desenvolvimento de software

• Se encontraram para que cada um explicasse a maneira como desenvolviam projetos de software

• E como trabalhavam para que a equipe respondesse rapidamente às mudanças

• A partir deste encontro foi criada a

“Aliança Ágil”

• Estabelecimento dos valores do

“Manifesto Ágil”

Metodologias Ágeis


Estamos descobrindo melhores maneiras de desenvolver software, fazendo-o e ajudando outros a fazê-lo.Através deste trabalho passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas.Software que funciona mais que documentação detalhada.Colaboração do cliente mais que negociações contratuais.

Responder às mudanças mais que seguir um plano.

Isto é, embora haja valor nos itens do lado direito, nós valorizamos mais os do lado esquerdo.

www.agilemanifesto.org

Manifesto para o Desenvolvimento Ágil de Software


Princípios Ágeis

• Satisfação do Cliente

• Responder às Mudanças

• Entrega Freqüente

• Motivação

• Software que Funciona

• Ritmo Constante

• Simplicidade


O Manifesto Ágil não pode ser interpretado como indicando que ferramentas, processo, documentos,

contratos ou planos são desprezíveis. • Ferramentas são críticas para acelerar o

desenvolvimento e reduzir custos• Contratos são vitais para iniciar as relações

desenvolvedor-cliente• Documentação auxilia a comunicação• Entretanto, os itens à esquerda são os mais

cruciais• Sem indivíduos hábeis, software funcionando,

interações fortes com clientes e rapidez de resposta às mudanças, a entrega do produto será quase impossível

Cuidado com o Manifesto Radical


Já é um movimento de grande sucesso• Centenas (milhares?) de instituições

já usam• Milhares de projetos já foram

completados• Opinião geral dos que tentaram é

positiva• Alguns estudos científicos começam

a aparecer

O Sucesso das Metodologias Ágeis


Quem Adotou ou Está Adotando?


• Proporcionalmente, as metodologias tradicionais ainda dominam

• Metodologias Ágeis exigem mudança cultural, o que não é nada fácil

• Metodologias Ágeis foram criadas por especialistas em Desenvolvimento de Software

• Em geral o poder de decisão não está nas mãos desses especialistas

Mas...


• Apoio das instâncias superiores

• Gerenciamento de equipes

• Problemas técnicos

• Interação com outros departamentos

• Interação com clientes

Maiores Dificuldades


Representam uma grande fonte de problemas

Pessoas


• Não é assim que eu sempre fiz• Medo de perder o controle• O chão desabou, como agir?• E a minha autoridade?

Gerentes Tradicionais


• Peões que não sabem de nada vão mexer na minha arquitetura?

• Não quero olhar para código, isso é coisa para programadores...

• E a minha autoridade?

Arquitetos


• Quebra da rotina• Sempre fiz assim, por que

tenho que fazer diferente agora?

• Especificação incompleta, testes, código limpo?

• Isso não é tudo desperdício?

• Não quero a responsabilidade

Programadores


• Estão tirando o meu emprego?• Vou ter que aprender a programar?

Testadores


• Onde está a especificação completa?• Se vocês não sabem ainda o que

querem, não venham me pedir para implementar agora coisas que vou ter que mudar depois.

• Eu é quem modelo o Banco, vocês apenas escrevem o código.

• Nós sempre fizemos assim e sempre deu certo, por que mudar agora?

DBAs


• Onde estão as minhas garantias?

• Qual é o preço final?• Se eu pagar tudo, quero

todas as funcionalidades!• Estou pagando para você

fazer o trabalho, por que eu devo estar presente? Você quer que eu faça o seu trabalho?

Clientes


• Eu li o livro ____• mas não sei ainda como

começar• Eu li o livro ____

• mas fiz tudo e não deu certo• Eu li bastante o livro ____,

pratiquei escondido, sei como fazer

• mas não consigo convencer o meu gerente a experimentar.

Coach novato


• Métodos Ágeis é muito bom, sou a favor• mas vamos incluir estes 113 formulários e 184

procedimentos para tornar o resultado de melhor qualidade

• Métodos Ágeis é muito bom, sou a favor• mas vamos usar essa ferramenta que compramos

para controlar todos os passos do desenvolvimento para atingirmos a qualidade total

• Métodos Ágeis é muito bom, sou a favor• mas precisamos fazer uma coleta de requisitos

detalhada e um planejamento completo antes de começar a implementar, caso contrário vamos fazer besteira.

Métodos Pseudo-Ágeis


• Métodos Ágeis é muito bom, sou a favor• mas nós é quem vamos implementar o sistema,

então vamos explicar ao cliente quais são as funcionalidades mais importantes.

• Métodos Ágeis é muito bom, sou a favor• mas como nós estamos pagando, vamos definir

as ferramentas e as tecnologias que os programadores irão utilizar para que eles não façam bobagem.

• Métodos Ágeis é muito bom, sou a favor• mas infelizmente, não podemos nos dar ao luxo

de escrever testes para tudo, isso é radicalismo.



Levantamento de Requisitos

Projeto

Implementação

Testes

Implantação


XP, Scrum, ...

Implantação com Testes


Mitos sobre as Metodologias Ágeis


“Extreme Programming (XP) é um processo de desenvolvimento que possibilita a criação de software de alta qualidade, de maneira ágil,

econômica e flexível.“ - Vinícius M. Teles

• Valores: ■ Princípios:• Comunicação ■ Feedback rápido• Simplicidade ■ Presumir simplicidade• Feedback ■ Mudanças

incrementais• Coragem ■ Abraçar mudanças

■ Trabalho de Qualidade

Programação Radical


• Agilidade = XP• É apenas um processo ágil, centrado no

desenvolvedor

• Fatos:• Há vários outros processos e metodologias,

como FDD, Scrum, Lean, Crystal, MSF for Agile, ASD, DSDM, RAD, etc.

• Agilidade é mais habilidade e atitude do que a adoção de um processo

• O Projeto C3, que deu origem à XP foi cancelado!

Principal Mito


Documentação não é necessária!• Fatos:

• Empresas passam por auditorias (Fiscal, SOX, ISO)• Processos definidos precisam de um nível razoável

de documentação (CMMI, MPS.BR...)• A documentação deve ser apropriada para o

propósito em questão (quantidade, qualidade, profundidade, abrangência, etc.)

• Há vários níveis de interesses e necessidades na organização, cada um com seu tipo e grau de A documentação deve ser apropriada para o propósito em questão (quantidade, qualidade, profundidade, abrangência, etc.)

• Há vários níveis de interesses e necessidades na organização, cada um com seu tipo e grau de “documentabilidade”

Consequência #1


Modelagem?? Nem pensar!• Fatos:

• Scott Ambler demonstrou o valor da Modelagem Ágil• Metodologias ágeis, como a FDD, utilizam a

modelagem como vantagem e não como carga inútil• “Uma imagem vale mais do que mil palavras” (ou,

talvez, linhas de código?)• A geração automática de código, proporcionada por

várias ferramentas (Borland Together, ECO e outros), é um fator para aumento de produtividade, padronização e diminuição de defeitos

• A capacidade de entender, memorizar e comunicar é muito maior com imagens do que com textos apenas (alguém aí é da época dos terminais verdes, CP/M, MS-DOS...?)

Consequência #2


Ferramentas?? Não, obrigado! Talvez as gratuitas...• Fatos:

• Ferramentas adequadas aumentam a produtividade• A automação ajuda a padronizar e reforçar o processo,

facilitando a adoção e institucionalização• O problema não é tanto a ferramenta, mas principalmente

os hábitos:

Consequência #3


Os testes são os requisitos, por isso os requisitos são desnecessários!

• Fatos:• Existem vários tipos de requisitos: de negócio, de

usuário, funcionais, não-funcionais, infra-estrutura, ...

• Existem vários tipos de testes: unitários, de integração, de usabilidade, de regressão, de carga, de stress, etc.

• Os testes são derivados dos requisitos, geralmente os de usuário (cenários de casos de uso) e funcionais

• Há uma relação N-N entre testes e requisitos• A rastreabilidade ajuda na sincronização entre eles

• Os testes manuais continuarão existindo (100% de automação é 99% improvável)

Consequência #4


Agilidade é coisa nova, de 2000 prá cá...• Fatos:

• Os valores, conceitos e práticas são antigos (conhecidos e praticados a mais de 15 anos)

• Algumas metodologias e processos já existiam antes de 2000:

• FDD (1997), mas várias práticas são anteriores a 1990

• Scrum (1993), mas as bases vêm de meados da década de 1980

• RAD (década de 1980 e início de 1990)• Agilidade, como conceito, faz parte da

natureza!

Consequência #5


• Prêmio Nobel de Física em 1965• QED - Eletrodinâmica Quântica

• Trabalhou no projeto Manhattan (1942- 1946)

• Enquanto os mainframes não chegavam, simulou algoritmos de cálculos com papel, calculadoras manuais e pessoas (um exército de secretárias!)

• Foi capaz de depurar, descobrir erros nos algoritmos e fazer otimizações para acelerar os cálculos!

• Quando as máquinas chegaram, foi só codificar e rodar!

Richard Feynman: Agilista??


• “Foco em datas na pior forma possível: ciclos curtos, entregas rápidas, estimativas e re-estimativas freqüentes”

• Esse foco agressivo na entrega fere a base geral de código, porque as pessoas não dão a mão para ajudar uns aos outros, e as tarefas “domésticas” são negligenciadas

• Eles ficam exaustos por causa do ritmo invariante e das horas anti-naturalmente regulares

• “São todos novos, com medo de falar, e nenhum deles têm mesmo certeza se é a Agilidade que está causando o problema”

• Esse pessoal Ágil é evasivo: “esquivando-se da crítica ao abraçar qualquer coisa boa e repudiando qualquer coisa má”

A “MÁ” Agilidade


• A estrutura da organização contém hierarquia, mas na prática ela parece bastante “plana” (código dos gerentes)

• As pessoas evoluem os processos quando necessário (em vez dos processos oprimirem as pessoas)

• Grande disciplina é praticada com relação à base de código

• A “folga” está embutida no sistema

A “BOA” Agilidade


• Permitir aos desenvolvedores explorar outras idéias que os interessem

• Os incentivos são ligados ao valor de negócio de cada projeto

• A organização facilita o foco na codificação• Por exemplo, fornecendo boas

ferramentas e lanches gratuitos ☺• As pessoas são tratadas com respeito• As requisições são simplesmente

enfileiradas e priorizadas

A “BOA” Agilidade


Projetos e Processos

Mudanças


• Única constante do universo:MUDANÇA

• Para melhorar• Para motivar• Para nos tornarmos mais eficientes

e eficazes• Para nos tornarmos mais ágeis

Porque mudar??


• Para 88% dos 1.150 CEOs de todo mundo ouvidos no início de 2009 pela consultoria americana Pricewaterhouse-Coopers a competência mais importante para um executivo atualmente é a flexibilidade para se adaptar a mudanças

• “E não basta ter facilidade para aceitar o novo. O profissional deve ser um provocador de mudanças e levar as pessoas junto com ele”, José Aurélio Drummond Jr., presidente da Whirlpool

Além disso...


O Processo de Mudança


• Tradicional

• Ser capaz de controlar / eliminar a incerteza

• Planejamento e controle de progresso através do Caminho Crítico / EVA

• Replanejar deve ser a exceção sempre

• Controle rígido do escopo do projeto

• Teorias básicas: Gerenciamento Total da QualidadeControle Estatístico de Processos

Diferenças de Paradigmas

• Ágil

• Ser capaz de lidar com a incerteza

• Planejamento e controle de progresso através da Corrente Crítica / Buffers

• Replanejar deve ser a regra (há limites práticos)

• Controle do escopo das iterações

• Teorias básicas: Teoria do CaosTeoria das Restrições (TOC)Produção Enxuta (Lean)


Planejar X Plano

“Um plano não é nada... Mas planejar é tudo!”

Dwight D. Eisenhower34º Pres. EUA

(1953-1961)


• O propósito de um processo de desenvolvimento de software é:

• capacitar e reforçar a entrega repetível de software que funciona...

• no prazo adequado e eficiente em relação ao seu custo...

• fornecendo informação precisa e significativa a todos os papéis principais, dentro e fora de um projeto...

• com o mínimo de interrupção para os desenvolvedores

Coad, De Luca (JMCU)

Para que serve um Processo?


• É bem delimitado• Claramente define tarefas, que são focadas

nos resultados• Produz progresso e informação de status

precisos• Rapidamente torna-se uma questão de

hábito• Ajuda a equipe a manter a qualidade e

administrar a complexidade• Otimiza comunicação dentro e fora da

equipe

Características de um bom Processo


• Capacita a organização a responder facilmente à mudança

• Entrega código funcionando ao mercado mais rapidamente (do que com outros métodos – atuais ou anteriores)

• Produz código funcionando de alta qualidade• Aumenta a produtividade• Aumenta a satisfação do cliente• Fornece um ambiente de alta satisfação com

o trabalho para uma equipe bem motivada

O Processo Ágil...


Desenvolvimento Dirigido a

Funcionalidades


• “FDD é uma metodologia iterativa e incremental de gerenciamento e engenharia de software, que combina as melhores práticas de outras abordagens ágeis com técnicas centradas no modelo, que podem escalar para equipes e projetos maiores.

• É caracterizada por uma ênfase na qualidade em todo o processo e um monitoramento de progresso direto, preciso, intuitivo e acurado.

• Sua principal finalidade é a entrega tangível e frequente de software funcional.”

Autor: Jorge L. Bublitz

Revisão: Adail Muniz

Definição


•1997-1998, Singapura•Contexto: Desenvolvimento de um grande sistema de empréstimos para o United Overseas Bank•Anteriormente, após 2 anos de consultoria, 3.500 páginas de casos de (in)uso e um modelo de objetos com centenas de classes, foi avaliado como impossível

Onde nasceu a FDD


• Decisão: Implantação das metodologias de OOAD de Peter Coad e de PM de Jeff De Luca

• Resultado: 2.000 Features entregues por uma equipe de 50 pessoas, 15 meses após a contratação da dupla

Decisão x Resultado


Jeff De Luca Peter Coad

Stephen Palmer John Mac Felsing

Os “Culpados”


Sede do United Overseas Bank David Anderson, o GUI-Man

Peter Coad e aEquipe de Modelagem

Paul Szego eStephen Palmer

Jeff De Luca e osProgramadores

O Berço da FDD


• Inovação Contínua• Adaptabilidade do Produto• Cronogramas Reduzidos de Entrega• Adaptabilidade das Pessoas e

Processos• Resultados Confiáveis

O que a FDD pode proporcionar??


Principais Características


• Fornece a estrutura suficiente para equipes maiores

• Enfatiza a produção de software de qualidade• Entrega resultados freqüentes, tangíveis e

funcionais• Realiza trabalho significativo desde o início,

antes de tornar-se altamente iterativa• Fornece informação de estado e progresso de

forma simples e compreensível• Agrada a clientes, gerentes e

desenvolvedores

Características da FDD


• Característica ou funcionalidade• Pequena o suficiente para ser implementada

no máximo em 2 semanas• Oferece valor para o cliente• Mapeia passos em uma atividade de negócio• Pode ser um passo de um caso de uso,

podendo ser às vezes o próprio caso de uso• Conceito muito próximo de requisito

funcional

O que é Feature?


MODELO

• <A><R><O>• <Ação> <Resultado> <Objeto>

• Calcular o Total da Venda


• Calcular o total do salário• Autorizar a entrada fora do horário do expediente

do funcionário• Assinar digitalmente o documento PDF• Autorizar a transação com o cartão do cliente• Calcular o desconto de uma venda • Listar os clientes ativos da empresa • Destacar os clientes devedores de uma filial • Imprimir a nota fiscal de uma venda • Validar a senha de um usuário • Efetuar a matrícula do aluno no curso

Outros Exemplos


• Coloque as seguintes funcionalidades no modelo sugerido (<a><r><o>):

• O usuário é validado antes de entrar no sistema• Ao vender um produto, seu estoque é

atualizado• A compra será paga com cartão de crédito• O sistema notifica o cliente sobre o envio do

seu pedido• A recepcionista escolhe o quarto do hóspede a

partir de uma lista de unidades disponíveis• O médico verifica sua agenda para marcar a

próxima consulta do paciente• Ao parir sua cria, a vaca deve ser registrada

como não estando mais prenha

Exercício


• Modelagem de Objetos do Domínio• Desenvolvimento por Feature• Posse individual de classe (código)• Equipes de Features• Inspeções• Builds regulares• Gerenciamento de configuração• Relatório/visibilidade de resultados

Melhores Práticas da FDD


• Diagramas de classes com os principais tipos deobjetos no domínio do problema e suas relações

• Auxilia na captura e esclarecimento dos requisitos

• Possibilita um entendimento comum e mais completosobre o domínio do problema

• O modelo de objetos do domínio• É o mapa da estrada, que guiará a jornada• Fornece uma estrutura abrangente na qual adicionar funcionalidade• Ajuda a manter a integridade conceitual do sistema• Reduz a quantidade de refactoring• É uma forma de armazenamento e comunicação concisa,

relativamente acessível e reutilizável, para todos os envolvidos no projeto

1) Modelagem de Objetos do Domínio


Exemplo de Modelo de Domínio


• Pensamento sistêmico, processual,visando o resultado final

• As features são o que o cliente realmente usará

• Ele entende os termos, o valor e o progresso• Ele pode priorizar pela importância para o negócio

• O teste é objetivo (funciona ou não funciona)• É fácil de se determinar quando está pronta• Garante a distribuição organizada de

responsabilidades através das classes/módulos• É comum a várias abordagens de

desenvolvimento (funcional, estruturada, orientada por objetos, etc.)

2) Desenvolvimento por Funcionalidade


Área 1 Atividade 1.1

Feature 1.1.1 Feature 1.1.2

Atividade 1.2 Feature 1.2.1 Feature 1.2.2

Área 2 Atividade 2.1 Feature 2.1.1 Feature 2.1.2

Atividade 2.2 Feature 2.2.1

ClasseA

ClasseB

ClasseC

As Features Preenchem oModelo de Domínio


Objeto1TelaA

Objeto2ClasseB

Objeto3ClasseC

Objeto4ClasseD

Usuário1: feature1

1.1: operacaoC1

1.2: operacaoA1

2.1.1: operacaoD12.1: operacaoC2

2.2: operacaoA2

2: feature2

1.1.1: operacaoD1

As Features Preenchem oModelo de Domínio


• Estipula quem (pessoa ou papel) é oresponsável final pelo conteúdo de umaclasse (pedaço de código)

• O dono garante que o propósito da classe é mantido e que as alterações são apropriadas

• Há um especialista disponível para explicar como um trecho particular do código funciona, especialmente para classes complexas ou críticas para o negócio

• O dono pode implementar uma melhoria mais rapidamente do que outro desenvolvedor

• O dono, pessoalmente, possui algo do que se orgulhar por ter feito bem

3) Posse individual de classe (código)


• Formadas dinamicamente• Única forma de desenvolver por

feature e manter a posse de código• Sob a coordenação de um

Programador Líder• Múltiplas mentes projetando

• Comparação entre alternativas e escolha da mais apropriada

• Membros são os Proprietários de Classes relevantes

• Benefício da Posse de Código• Enfatiza o trabalho em equipe

• Ninguém termina enquanto a equipe de features não terminar

4) Equipes de Features


• Quando bem feitas, são muito úteis na melhoria da qualidade do design e do código

• São recomendadas desde 1970 e a evidência pesa fortemente a seu favor

• Numa experiência com 11 programas, o erro médio por 100 linhas de código caiu de 4,5 para 0,82

• Inspeções cortam erros em mais de 80%• 1 hora de inspeção pode evitar

de 5 a 30 horas de correções

• Benefícios secundários• Transferência de conhecimento• Conformidade com padrões 0%

15%

30%

45%

60%

24%

35%

45%

55%60%

Técnica

Taxa Média de Detecção de Defeitos

Teste UnitárioTeste FuncionalTeste de IntegraçãoInspeção de DesignInspeção de Código

Jones, C.L. “A Process-Integrated Approach to Defect Prevention”, IBM Systems Journal, 1985

5) Inspeções


Prof. Guilherm

e Horta, C

OPPE/U

FRJ, 2004

Detecção Antecipada de Defeitos


1Planejamento

2Detecção

3Coleção

4Correção

Artefato

Form.Planejamento

Form.Relato deDefeitos



ArtefatoCorrigido

Organizador

Inspetor

ModeradorInspetor

Autor

Autor

Ad-HocTécnicas de Leitura

Checklists

Prof. Guilherme Horta, COPPE/UFRJ, 2004

Como Conduzir Uma Inspeção


• Em intervalos regulares, compilar o sistema comtodas as features completadas até o momento

• Semanalmente, diariamente ou continuamente

• Ajuda a antecipar erros de integração

• Garante que sempre haverá alguma coisa paramostrar ao cliente

• Oportunidades• Geração de documentação• Execução de scripts de auditorias e métricas• Testes de regressão• Notas da versão (novas features, defeitos corrigidos, etc.)

• Os resultados podem ser publicados na intranet do projeto

6) Montagens Freqüentes


• Disciplina que suporta e controla as evoluções e modificações em artefatos-chave dentro do ciclo de desenvolvimento de um software

• Objetivos• Facilitar o desenvolvimento de software• Garantir a integridade dos produtos• Controlar efetivamente as modificações

• Itens de Configuração: Artefatos gerados oumanipulados durante o ciclo de vida da aplicação

• Arquivos, Requisitos, Documentos, Modelos, Testes

• Processos, Contratos, Regulamentações• Solicitações de Mudança, Defeitos, Tarefas

PrincipaisArtefatos de

Desenvolvimento

Desenvolvimentodo Produto

Gerenciamento

7) Gerenciamento de Configuração


• Versionamento

• Check out/check in• Histórico de revisões• Branching & Merging• Visões de Projeto

• Gestão de Mudanças

• Acompanhamento de defeitos• Listas de Melhoria• Associações• Rastreabilidade

• Gestão de Tarefas

• Criação e Acompanhamento• Ficha de tempo

Gerenciamento de Processo Definição de Workflow Critérios de Entrada/Saída Notificações Garantia de Segurança

Gerenciamento de Montagem Identificação de

Dependências Controle de Montagens

Gerenciamento de Liberação Rótulos Estados Promocionais Implantação

Tarefas Rotineiras doGerenciamento de Configuração


Para que o cliente e os gestores possam direcionar o projeto corretamente é preciso Uma figura acurada do estado atual do projeto Saber o quão rápido a equipe adiciona

funcionalidade O resultado geral desejado

Ter um método simples, de baixa sobrecarga, para coletar informação de progresso de forma acurada e confiável

Formatos de relatórios objetivos e intuitivos, para todos os interessados no projeto

8) Relatório/Visibilidade de Resultados


Os Papéis


Principais Papéis

GERENTE DE PROJETOS

Especialista Domínio do

Negócio

Gerente de Desenvolvimento

Programador Líder

Arquiteto Líder

Proprietário de Classes


• Coordena as ações da equipe do projeto, controla o progresso e reporta para a alta gerência e interessados no projeto

• Responsável pelo gerenciamento de: escopo, tempo, custo, qualidade, riscos, comunicação, recursos humanos, suprimentos e integração

• Responsável por todos os assuntos administrativos do projeto, o que inclui o gerenciamento de recursos, orçamento, equipamentos e outros.

• Principal meta é fornecer subsídios para que nenhum fator externo atrapalhe a produtividade da equipe do projeto

Gerente de Projeto


• Possui habilidades técnicas e gerenciais necessárias para coordenar as ações da equipe de desenvolvimento, operacionalizando as decisões tomadas pelo gerente de projeto

• Responsável por liderar o dia-a-dia do desenvolvimento do produto.

• Por ser o responsável por resolver qualquer conflito técnico que exista entre programadores- chefes, precisa possuir boa experiência no desenvolvimento de software e nas tecnologias que estarão sendo utilizadas no projeto

Gerente de Desenvolvimento


• Compreende as regras e a dinâmica do domínio do problema sendo considerado

• É o responsável por informar a equipe do projeto sobre o que deve ser feito para que o produto do projeto seja adequado às necessidades dos usuários

• Usa o seu conhecimento no negócio para apresentar à equipe do projeto as necessidades para que o software possua valor real

• Deve estar sempre disponível para fornecer aos desenvolvedores maior detalhamento sobre determinada funcionalidade

• É um um membro fixo da equipe e sempre esta fornecendo feedback das entregas para todos os envolvidos.

Especialista no Domínio de Negócio


• É um profissional com experiência em análise e modelagem orientada a objetos, capaz de liderar a equipe no desenvolvimento do modelo que será construído para implementar as features identificadas

• Possui habilidade para atuar como facilitador na absorção das regras de negócio

• Será ele o responsável pela última palavra em toda arquitetura do sistema.

Arquiteto Líder


• Também chamado de Progranador-Chefe

• É um profissional mais experiente, que possui reconhecimento como tal pela equipe

• Coordena o desenvolvimento das features, monta as equipes de features e participa das definições técnicas, além de ser também um Proprietário de Classes

• Normalmente é atribuído a ele a propriedade das classes mais complexas do sistema

• Possui papel fundamental nas fases de absorção do conhecimento de negócio e no planejamento das funcionalidades.

Programador Líder


• É um desenvolvedor da equipe, ao qual foram atribuídas certas classes do modelo

• Sempre que uma feature for escolhida para desenvolvimento e necessitar dos serviços oferecidos por algumas das classes que estão sob sua “custódia”, ele será escalado para participar da equipe de features nessa iteração

• Programa, diagrama, testa e documenta as funcionalidades a ele atribuídas pelo Programador-chefe da equipe.

Proprietário de Classes


Gerente de Versão

Guru da Linguagem

Engenheiro de Desenvolvimento

Produtor de Ferramentas e

Utilitários

Administrador de SistemasTestadores

Implantadores Escritores Técnicos

Funções de Apoio


Os 5 Processos


Concepção e Planejamento

Construção

Desenvolverum ModeloAbrangente

PlanejarporFeature

Mais conteúdo na forma

Mais forma que conteúdo

Modelo de Objetos

Pacotes de Trabalho

Requisitos

Produto

Plano deDesenvolvimento

Progresso

Construira Lista de Features

Fonte: Heptagon – www.heptagon.com.br

Os 5 Processos

DetalharporFeature

ConstruirporFeature


Desenvolver um Modelo Abrangente Modelagem dos Processos de Negócio (BPM) Captura de Requisitos Análise Orientada por Objetos (OOA)

Construir a Lista de Features Decomposição Funcional

Planejar por Feature Plano de Desenvolvimento Prioridade, Dependência, Distribuição de Trabalho

Detalhar por Feature Design/Projeto OO (OOD), Estudo Detalhado

Construir por Feature Programação OO (OOP) Inspeção, Testes, Integração

O Porquê de Cada Processo


Feature-Driven Development

Discussões Iniciais Sobre RequisitosObter Patrocínio da Gerência

Escolha da Linguagem de Programação

Escolha da Plataforma Tecnológica

Protótipo Técnico

Protótipo da Interface com o Usuário

Limpeza de Dados

Conversão de Dados

Teste de Carga

Sistema Piloto

Desenvolvimento em Fases

Teste de Aceitação do Usuário

Teste do SistemaGerenciamento das Alterações nos Requisitos

Gerenciamento de Problemas

Gerenciamento de Recursos

Alocação de Pessoal

Preparação de Orçamento

Planejamento Geral

Desenvolver um Modelo Abrangente

Construir a Lista de Features

Planejar por Feature

Detalhar por Feature

Construir por Feature

O Contexto da FDD


Gestão Ágil de Projetos


Construção

Análise OO PlanejamentoDecomposição Funcional

Projeto OO Programaçãoe Teste OO

Engenhariade Requisitos

Desenvolvimento de Requisitos

Gerênciade Requisitos

Gerênciade Configuração

Principais Disciplinas Envolvidas


Análise OO É um método de análise que examina os requisitos a

partir da perspectiva das classes e objetos encontrados no vocabulário do domínio do problema

Enfatiza a construção de modelos do mundo real usando uma visão de mundo orientada por objetos

Desenho/Projeto OO É um método de projeto que abrange o processo de

decomposição orientado por objetos e uma notação para descrever os modelos lógicos e físicos, estáticos e dinâmicos, do sistema sendo projetado

Enfatiza a estruturação eficaz e apropriada de um sistema complexo, sem se prender a detalhes de implementação

Análise e Desenho/ProjetoOrientados por Objetos


Programação OO É um método de implementação no qual os programas são

organizados como coleções cooperativas de objetos, cada qual representando uma instância de alguma classe e cujas classes são todas membros de uma hierarquia de classes unidas por relacionamentos de herança

Enfatiza o uso de objetos, e não de algoritmos, como blocos de construção lógica fundamentais

Teste OO É um método de verificação do comportamento dos objetos em

tempo de execução Enfatiza inicialmente o comportamento individual (unitário) de

cada classe de objetos, passando para o relacionamento entre objetos, seu funcionamento como componente/serviço, e a orquestração entre os componentes/serviços

Programação e TesteOrientados por Objetos


Meta

CondiçãoNecessária



ObjetivoIntermediário








Estabelecer o Propósito do Projeto


Engenharia deRequisitos

IIT Management & GovernanceGerenciamento & Governança de TI

Demanda Estratégica & Operacional

ANÁLISE

Priorização | Verificação |Riscos | Estimação

GERENCIAMENTO

Armazenamento | Medição & Auditoria | Ligação & Rastreamento | Relatórios | Segurança

Nec

essi

dade

s de

Neg

ócio

Operações de TI (Produção)

DESCOBERTATécnicas | Glossário |

Fronteiras do Sistema |Stakeholders

ESPECIFICAÇÃODetalhar Requisitos | Protótipo |Modelo de Cenários de Negócio |

Modelo de Casos de Uso

VALIDAÇÃO

Revisão | Assinatura |Baseline

Engenharia de Requisitos


Karl Wiegers, “Software Requirements”

Requisitosde Negócio

Requisitosde Usuário

Requisitosde Sistema

RequisitosFuncionais

Regras deNegócio

Atributosde Qualidade

InterfacesExternas

Restrições

Documento de Visão e Escopo

Casos de Uso

Especificação deRequisitos de Software

Funcionais Não-Funcionais

Tipos de Requisitos


Também chamada de “Modelagem de Objetos do Domínio”

Preocupa-se mais com a forma do que com o conteúdo

Auxilia na captura e esclarecimentos dos requisitos

Possibilita um entendimento comum e mais completo sobre o domínio do problema

1. Desenvolver um Modelo Abrangente


É uma atividade inicial de estudo, análise e modelagem do sistema

Realizada em grupos O modelo gerado é suficientemente

abrangente, mas não detalhado O objetivo é ter uma definição a priori do

que será feito, para guiar a equipe durante a fase de construção

Artefatos produzidos: Diagramas de classes, sequência,

atividades, estados, casos de uso Lista preliminar de requisitos Anotações nos modelos

DPF CPF


DMA CLF PPF


Formar a Equipede Modelagem

(Gerente do Projeto)

Conduzir um EstudoDirigido Sobre o

Domínio de Negócio(Ger. Projeto, Especialistas)

Estudar Documentos(Equipe de Modelagem)

Desenvolver Modelosem Pequenos Grupos(Equipe de Modelagemem pequenos grupos)

Desenvolver umModelo como Equipe

(Equipe de Modelagem)

Refinar o Modelo deObjetos Completo

(Arquiteto Líder,Equipe de Modelagem)

Escrever ComentáriosSobre o Modelo(Arquiteto Líder,

Programador Líder)

opcional



Apresentação

Negócio – Domínio do Problema

Persistência Interface com Outros Sistemas

FOCO

Arquitetura em Camadas


Padrão de análise e modelagem desenvolvido por Peter Coad, na última metade da década de 1990

Auxilia tanto na criação quanto na melhoria de modelos da classes

Fácil de aprender e explicar Propõe a utilização de 4 arquétipos

arquétipo. s.m. 1 modelo ou padrão passível de ser reproduzido em simulacros ou objetos semelhantes; 2 idéia que serve de base para a classificação dos objetos sensíveis; 3 Derivação: por extensão de sentido: qualquer modelo, tipo, paradigma. (Dic. Houaiss da Língua Portuguesa).

UML em Cores


Representa algo que necessita ser registrado,por razões de negócio ou até mesmo legais, queocorre em algum momento no tempo ou duranteum intervalo de tempo

São atividades, eventos e serviços Um momento-intervalo também pode ter

“mi-detalhes”, ou seja, ser composto porpequenas etapas do evento total

Exemplos: Uma venda é algo que acontece num certo momento Uma estada é o período de tempo que o veículo fica sob a

responsabilidade do estacionamento Para identificar esse arquétipo usamos a cor rosa e o

estereótipo <<moment-interval>>; também usa-se a sigla MI; para os detalhes, usamos o estereótipo <<mi-detail>>

É comum a classe estar acompanhada de um diagrama de máquina de estados, para definir seu comportamento em tempo de execução

Arquétipo: Momento-Intervalo


Representa: Uma pessoa (física ou jurídica) Um certo local (endereço, casa, privado ou público) Algum objeto, geralmente concreto

São entidades que devem ser registradas nosistema por desempenharem papéis nas atividades (momentos-intervalos)

Uma mesma pessoa pode participar de eventos distintos, através de papéis diferentes

Identificamos esse arquétipo com a cor verde e o estereótipo correspondente: <<party>>, <<place>> ou <<thing>>

É onde geralmente aparecem os “cadastros” e “relatórios” simples

Arquétipo: Pessoa-Lugar-Coisa


É a representação de um papel que édesempenhado por pessoa, lugar ou coisa,em um determinado evento do negócio(momento-intervalo)

É mais comumente aplicado a pessoas, mas épossível utilizá-lo com lugares e até mesmo com coisas

Exemplo: Um aeroporto pode desempenhar o papel de local de

origem, destino ou escala de um vôo Uma pessoa, num hotel, pode ser recepcionista,

gerente, hóspede, vigilante, etc. Sua cor é o amarelo e o estereótipo é

<<role>>

Arquétipo: Papel


É como um item num catálogo, definindo ascaracterísticas de uma determinada coisa,lugar ou até mesmo pessoa (menos comum,mas possível)

Usado para concentrar dados comuns adiversos objetos, possibilitando perguntas denegócio interessantes, como a quantidade deobjetos de um determinado tipo

Aparece na cor azul (quase cinza, dependendo da ferramenta de modelagem) e usa-se o estereótipo <<description>>

São as famosas “referências” usadas em combos e lookups

Arquétipo: Descrição


Padrão para análise OO (Camada de Negócio)

Mostra o relacionamento entre os arquétipos

Diminui a variação no processo de modelagem

Padroniza o entendimento Equipe de Negócio Equipe de TI

Domain Neutral Component(Componente Genérico de Modelagem)


Quarto

IDStatus

Hospede

ScoreDtUltVisita

Hotel

NomeEnderecoEstrelas

PessoaFisica

Nome CPF

Estadia

DHInicioDHTerminoValorTotal

*

Funcionario

DtAdmissaoCTPS

*

*

Servico

DataHoraValor

*

TipoQuarto

DescricaoNumSoltNumCasalFumante?

*

UML Sem Cores


Quarto

IDStatus

Hospede

ScoreDtUltVisita

Hotel

NomeEnderecoEstrelas

PessoaFisica

Nome CPF

Estadia

DHInicioDHTerminoValorTotal

*

Funcionario

DtAdmissaoCTPS

*

*

Servico

DataHoraValor

*

TipoQuarto

DescricaoNumSoltNumCasalFumante?

*

UML em Cores


Com o modelo básico criado, deve-se agora criar uma lista de features

É uma decomposição funcional do domínio do negócio

Categorizada em 3 níveis: Áreas de Negócio (Grandes Conjuntos de

Features) Atividades de Negócio (Conjuntos de Features) Passos da Atividade de Negócio (Features)

Artefatos produzidos: Lista de Features Requisitos mais detalhados

DPF CPF

2. Construir a Lista de Features

PPFCLFDMA


Formar a Equipede Lista de Features(Gerente do Projeto,

Gerente de Desenvolvimento)

Construir aLista de Features

(Equipe deLista de Features)

2. Construir a Lista de Features


Sistema ouAplicação

Área de Negócio Área de Negócio Área de Negócio

Atividade de Negócio







Atividade de NegócioFuncionalidade

Funcionalidade

Gerenciamento de ...

<Substantivo><VerboInfinitivo> ...

<Ação> <Resultado> <Objeto>

FBS: Feature Breakdown Structure


Classe A

Classe B

Classe C

Área n

Atividade XFeature 1Feature 2

Atividade YFeature 3Feature 4Feature 5

...

As Features preenchem o Modelo


Com a lista e o modelo, deve-se agora planejar a ordem na qual as funcionalidades serão implementadas, tendo como base: a necessidade do usuário (importância, prioridade) as dependências entre elas a carga de trabalho da equipe de desenvolvimento a complexidade das funcionalidades

As responsabilidades são distribuídas para a equipe

Artefatos produzidos: Plano de desenvolvimento Pacotes de trabalho Lista de classes com seus donos

DPF CPF

Processo Nº 3:Planejar por Feature

DMA CLF PPF


Formar a Equipede Planejamento

(Gerente do Projeto)

Determinar a Sequênciade Desenvolvimento

(Equipe de Planejamento)

Atribuir Conjuntos deFeatures para

Programadores Líderes(Equipe de Planejamento)

Atribuir Classes paraos Desenvolvedores

(Equipe de Planejamento)

Processo Nº 3:Planejar por Feature


Regra Empírica da FDD Cada semana de modelagem resulta em 12 semanas de construção Pressuposto: a equipe usa UML em Cores, arquétipos e DNC

Truco (ou Poker) da Estimativa A Escala de 5 Pontos

Nº Estimado de Classes na Feature

Complexidadeda Feature

Esforço(Pessoa-Dia)

1 1 0,5

2 2 1

3 3 2

4 4 4

5 5 8 (ou mais)

David Anderson, Agile Management for Software Engineering, 2003

Estimativas


Com as features devidamente estimadas, o plano de desenvolvimento é criado a partir da capacidade de produção

Com as features na ordem desejada, corta-se a lista em blocos que caibam nas durações das iterações (1 ou 2 semanas) Cuidado para não quebrar em pontos que causem problemas

Cada pacote de trabalho deve ser atribuído a um Programador Líder

Com as “datas” de cada iteração, preencher as “datas” planejadas de cada um dos 6 milestones (as datas geralmente são iguais para as features da iteração)

Iteração 1 Iteração 2 Iteração 3 Iteração 4

Pacote 1(10)

Pacote 2(8)

Pacote 3(13)

Pacote 4(15)

O Plano de Desenvolvimento


Agora na fase de construção propriamente dita, deve-se refinar o projeto (design) para cada feature ou conjunto de features relacionadas

A equipe de features será formada pelos proprietários das classes envolvidas

O resultado será um pacote de trabalho, sob a responsabilidade de um programador líder

Artefatos produzidos: Modelos detalhados (classes e seqüência) Esqueletos de classes com métodos Pacote de trabalho detalhado Relatório de inspeção do design Relatório de progresso atualizado

DPF CPF

4. Detalhar por Feature

DMA CLF PPF


Formar a Equipede Features

(Programador Líder)

Conduzir um EstudoDirigido Sobre o

Domínio de Negócio(Especialista no Domínio)

Estudar Documentosde Referência

(Equipe de Features)

Desenvolver osDiagramas de Sequência


Refinar o Modelode Objetos

(Programador Líder)

Escrever Prólogos deClasses e Métodos


Inspecionar oProjeto (Design)


opcional

opcional

opcional

4. Detalhar por Feature


Os proprietários de classes desenvolvem o código correspondente a cada feature

Os testes de unidade e as inspeções são realizados

O código final (aprovado) é promovido ao build atual

O resultado são funções com valor para o cliente (features)

Artefatos produzidos: Código fonte testado e integrado Relatórios de inspeção e testes Lista de alterações feitas/necessárias Relatório de progresso atualizado DPF CPF

5. Construir por Feature

DMA CLF PPF


Implementar Classese Métodos


Testes Unitários(Equipe de Features)

Conduzir uma Inspeçãono Código


Promover para o Build(Programador Líder,Equipe de Features)

5. Construir por Feature


Gerenciamento do Projeto


No ciclo iterativo (processos 4 e 5), o progresso é medido com base em 6 marcos (milestones) bem definidos

A cada etapa cumprida, o percentual respectivo é agregado ao total de progresso da feature

Estudo Dirigido Sobre o Domínio

1%

Desenho(Projeto)

40%

Inspeção doDesenho

3%

Codificação

45%

Inspeção doCódigo10%

Promoçãoao Build

1%

Nº 4: Detalhar por Feature Nº 5: Construir por Feature

DMA CLF PPF

DPF CPF

Medindo o Progresso


Legenda: Atividade em andamento Requer atenção Completada Não iniciada

Id Descrição P.C. D.C.Est. Dirig.Est. Dirig. DesignDesign Insp. DesignInsp. Design Codif.Codif. Insp. Cod.Insp. Cod. BuildBuild

Id Descrição P.C. D.C.Plan. Real. Plan. Real. Plan. Real. Plan. Real. Plan. Real. Plan. Real.

12 Agendar um serviço para um carro HM AS 10/02 10/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03

13 Incluir um novo cliente na lista de clientes HM VS 01/02 01/02 04/02 04/02 05/02 05/02 07/02 07/02 08/02 08/02 09/02 09/02

14 Registrar um serviço realizado num carro AR AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03

15 Registrar uma lista de peças utilizadas num serviço AR

ASSM

10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/0315 Registrar uma lista de peças

utilizadas num serviço ARASSM

Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03

16 Calcular o custo total das peças usadas num serviço HM

ASSM

10/02 10/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03

17 Enviar uma fatura para um cliente AR VS 08/03 10/03 13/03 17/03 19/03 20/03

18 Receber um pagamento por um serviço HM AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03

19 Registrar a opção de pagamento preferida por um cliente AR VS Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)

Monitorando as Features


NE

PendentesBacklog

Fulano

Beltrana

Sicrano

Zé

J.J.

Iniciadas Inspeção/Teste Finalizadas

N N I

N

N NE N I

N NN N

N N N

N N I

E

N

N

N

N N

N N I

Quadro de Tarefas


Início: Fim:

ID: Resp.:

Descrição:

Início:

Estimativa de retorno:

ID: Resp.:

Motivo:

RN12 Sic

18/06 09:15

VN: A

Fórmula de cálculo do imposto: I = ValorBruto * Aliquota

Aliquota -> parâmetro AI3Classe -> VendaTela -> pgVenda

Cartão de tarefa normal (azul)ou emergência (amarelo)

Cartão de impedimento (rosa)

Est.: 4

RN12 Sic

19/06 9:00

18/06 11:30

Classe Venda está sendo alterada

por outra tarefa

Exemplos de Kanbans


Mês/Ano

Porcentagem Completada:

Prazo de Entrega:Completada

Mês e Ano para entrega

Status da Atividade:

Barra de Progresso

Em andamento

Requer atenção (ex.: impedimento)

Completada

Nome daAtividade

de Negócio(nº features)

75%Ainda não iniciada

Iniciais PC

Reportando o Progresso


Painel de Progresso(Parking Lot)

!"#"$%&' ()*&$%&)"$+, -+"$./,***********************0,)12"+&%&*************************3&44&*%"*54,#4"66,**** 7/,*8$898&%&

:"4"$98&)"$+,*%"*;"$%&6*%"*54,%<+,6*=;5>* ?@A

($+4&%&*%"5"%8%,6

=??>

!"#$%&&'

()*+

0,$+4,2"*%"0,$+4&+,6

=B?>

,-.$%&&'

;"$%&*%"54,%<+,6

=CC>

/0#$%&&1

()*+

($D8,*%"54,%<+,6

=BE>

23.$%&&'

()*+

BFA

($+4"#&*%"54,%<+,6

=BF>

,-.$%&&'

()*4

?FA

G"2&+H48,6*%";"$%&6

=B@>

5"6$%&&1

IJAEEA ?A

:"4K*0,$+&6*%"*028"$+"6*=00>* EFA

-$L286"*%"54,1,6+&6*%"0,$+&6=C?>

/0#$%&&1

EJA

G"#86+4,*%"M4&$6&.N"6%&6*0,$+&6

=?F>

5"6$%&&1

OCA

-P"4+<4&%"*7,D&60,$+&6=BB>

/0#$%&&1

BFFA

:"4"$98&)"$+,*%"*(6+,Q<"*=:(>* E@A

R"S8$8./,*%"T$8%&%"6*%"(6+,Q<"=CU>

/0#$%&&1

BFFA

V,D8)"$+&./,%"*V"49&%,48&6

=BE>

738$%&&'

OCA

()*4

-9"8+"*%"G"Q<868.N"6%"*V,D8)"$+,

=BO>

5"6$%&&1

EIA

()*4

()*% ()*+

()*% ()*% ()*% ()*4

W86+")&0,)"498&2

=C?O>

,-.$%&&'

UJA


Diagrama de Fluxo Acumulado

Legenda:

Não iniciada Em andamento

Completada

Tempo (semanas)

Feat

ures

Prazo de Entrega(Lead Time)

Estoque Intermediário(Work in Progress)

Product Backlog

Controle de Produção


FDD eOutras Metodologias


Espectro de Metodologias

UP XPFDD


FDD x SCRUM x XP

FDD

SCRUM

XP


8. Incremento de Produto(pode ser liberado para uso)

6. Dia

5. Iteração(2 a 4 sem.)4. Tarefas

detalhadaspela equipe

1. Visão(RSI, marcos,

versões)

2. Lista de Espera (Backlog) de funcionalidadesdo produto, priorizada pelo Dono do Produto

3. Escopo da Corrida(Sprint)

7. Reuniões Diárias (em pé)


1DMA

3PPF

2CLF

Construção

4DPF

5CPF

9. Inspeção eAdaptação

Scrum e FDD


FDD XP

Certo planejamento inicial Planejamento durante o desenvolvimento

Refactoring é exceção Refactoring é a norma

Programadores Líderes e Proprietários de Classes Posse coletiva do código

Design formal eInspeções de código e modelo Programação em pares

FDD e XP: Algumas Diferenças


Iniciação Elaboração Construção TransiçãoProcesso Unificado

FDDDMA CLF PPF

DPF CPF

XP

UP, FDD, XP:Proposta de Uso Combinado


OID: Inovação e Implantação OrganizacionalCAR: Análise e Prevenção de Defeitos

5 EmOtimização

4 GerenciadoQuantitativam.

3 Definido

2 Gerenciado

MelhoriaContínua do

Processo

GerênciaQuantitativa

Padronizaçãodo Processo

GerênciaBásica deProjetos

QPM: Gerenciamento Quantitativo de ProjetoOPP: Performance do Processo Organizacional

RD: Desenvolvimento de RequisitosTS: Solução Técnica

PI: Integração de ProdutosVER: VerificaçãoVAL: Validação

OPF: Foco no Processo OrganizacionalOPD: Definição do Processo Organizacional

OT: Treinamento OrganizacionalIPM: Gerência Integrada de Projeto

RSKM: Gerência de RiscosDAR: Análise e Tomada de Decisão

REQM: Gerência de RequisitosPP: Planejamento de Projeto

PMC: Monitoramento e Controle de ProjetoSAM: Gerência de Acordos com Fornecedores

MA: Medição e AnálisePPQA: Garantia da Qualidade do Processo e do

ProdutoCM: Gerência de Configuração

1 Inicial

Áreas de ProcessosNível Foco ProdutividadeQualidade

RiscoRetrabalho

FDD

Agile CMMI


• É um método ágil e altamente adaptativo, que produz resultados freqüentes, tangíveis e funcionais

• Oferece vantagens dos métodos prescritivos (rigorosos), pois implementa o conceito importante de planejamento, mas sem os exageros de documentação e controle

• Oferece vantagens dos métodos ágeis, onde a preocupação maior é com a produção de código, mas toma o cuidado de planejar o suficiente e controlar o andamento do projeto

• Atende às necessidades dos clientes, gerentes e desenvolvedores

Resumindo, a FDD...


• Geralmente a iniciativa começa nos desenvolvedores• Uma das boas contribuições da XP

• Mas se o desenvolvimento se tornar ágil e a gerência continuar tradicional, haverá desgaste

• A diferença de impedância causa perdas• Assim, a Agilidade deve ser um objetivo comum• Gerência e Desenvolvedores devem responder:

• 1) O que mudar?• 2) Para o que mudar?• 3) Como causar a mudança?

• A escolha da(s) metodologia(s) será resultado do passo 3! Não faça isso antes! • Realize projetos pilotos para experimentar (e errar!)• Adapte a metodologia às suas necessidades

Dicas para ConvencerGerentes e Desenvolvedores


• Adotar Gestão Ágil e FDD não é uma panacéia

• Mas é um bom começo para a melhor compreensão dos caminhos a seguir

• Agilidade e Responsabilidade não são antagônicos, mas mutuamente necessários

Só para lembrar


A adoção da Gestão Ágil de Projetos e FDD, como qualquer tecnologia, deve ser acompanhada de uma revisão no comportamento, nas políticas, nas métricas e nas regras da organização e das pessoas

Muitos benefícios estão por vir, mas é preciso saber plantar e cuidar para poder colher

O retorno vale muitas vezes o investimento!

Motivação é a chave para mudanças!!

Conclusão


Agile Alliance www.agilealliance.org

Agile Project Management Leadership www.apln.org

Agile Management www.agilemanagement.net

FDD www.featuredrivendevelopment.com www.heptagon.com.br/fdd/

Grupos de Discussão http://groups.yahoo.com/group/AgileProjectManagement http://br.groups.yahoo.com/group/Agile-Brasil http://br.groups.yahoo.com/group/GUFDD

Para saber mais


http://www.agilealliance.org/

http://www.agilealliance.org/

http://www.apln.org/

http://www.apln.org/

http://www.agilemanagement.net/

http://www.agilemanagement.net/

http://www.featuredrivendevelopment.com/

http://www.featuredrivendevelopment.com/

http://www.heptagon.com.br/

http://www.heptagon.com.br/

http://groups.yahoo.com/group/AgileProjectManagement

http://groups.yahoo.com/group/AgileProjectManagement

http://br.groups.yahoo.com/group/Agile-Brasil

http://br.groups.yahoo.com/group/Agile-Brasil

http://br.groups.yahoo.com/group/GUFDD

http://br.groups.yahoo.com/group/GUFDD

Literatura Recomendada


Adail Muniz Retamal Heptaman

Agradecimento


Engenheiro de Sistemas Administração de Empresas MBA em Planejamento Estratégico

Chefe da Seção de Análise e Desenvolvimento (TRE-MT) Certificação Delphi e JBuilder

Artigos publicados nas revistas Micro Sistemas (!?), Clube Delphi e MundoPM

Palestrante no 12º Congresso MT Digital - 2008 Palestrante na Conferência da Borland – Borcon Revolutions

2007 Palestrante na Conferência Mundial da CodeGear – CodeRage III

2008

Assinante do Agile Manifesto Membro da Agile Aliance

Eng. Jorge Luis Bublitz


"No que diz respeito ao empenho, ao compromisso, ao

esforço e à dedicação, não

existe meio termo. Ou você faz uma coisa

bem feita ou não faz."

Frase


Valeu !!!!!Jorge FDDMan

Email e MSN:[email protected]

Páginas:h:p://bublitz.tripod.com

h:p://jorge-‐fdd.blogspot.com

Um abraço!!!!


mailto:[email protected]

mailto:[email protected]

http://bublitz.tripod.com/

http://bublitz.tripod.com/

http://jorge-fdd.blogspot.com/

http://jorge-fdd.blogspot.com/

Documents

Aula FDD CESAR Recife GAP