Jorge Luis BublitzConsultor

ContextoMetodologiasAgilidade e Metodologias ÁgeisMudanças FDD

“É 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 BirrellA Practical Handbook for Software

Development, 1985

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

“O limite do caos é definido como um estado natural entre ordem e caos, um amplo

compromisso entre estrutura e surpresa. O limite do caos pode ser visualizado como um

estado instável, parcialmente estruturado (...). É instável porque é constantemente atraído para

o caos ou para a ordem absoluta.”

Juan Nogueira, Surfing the Edge of Chaos: Applications to Software Engineering, 2000

Falharam

23%

Concluídos com Sucesso

28%

Completadoscom Alterações

49%

Projetos de Software

Standish Group – www.standishgroup.com

“Nenhum floco de neve em uma

avalanche se sente responsável por ela”

Stanislaw Lecescritor polonês

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

previsível e mais eficiente Impõe disciplinas rígidas Processos detalhados = Documentação Planejamento é a ênfase

Passam a impressão de serem uma PANACÉIA – cura para todos os males

Também chamado de Modelo em Cascata (Waterfall)

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

orçamentos e implementação de sistemas inteiros

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

Qualidade

Prazo

Custo

Escopo

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

1. Qualidade do que é ágil2. Desembaraço, ligeireza, presteza de

movimentos3. Mobilidade, perspicácia, vivacidade

Geralmente associa-se AGILIDADE com Rapidez, Flexibilidade, Leveza

“Agilidade é a habilidade para criar e responder às mudanças, para lucrar num ambiente turbulento de negócios, para equilibrar

flexibilidade e estabilidade.”

Jim HighsmithAgile Software

Development Ecosystems2002

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”

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

Princípios Ágeis

Satisfação do Cliente

Responder às Mudanças

Entrega frequente

MotivaçãoSoftware

que Funciona

Ritmo Constante

Simplicidade

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

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

Apoio das instâncias superiores

Gerenciamento de equipes

Problemas técnicos

Interação com outros departamentos

Interação com clientes

Projetos e Processos

Única constante do universo:MUDANÇA

Para melhorar

Para motivar

Para nos tornarmos mais eficientes e eficazes

Para nos tornarmos mais ágeis

“Um projeto é um problema agendado

para solução.”

“Um projeto é uma coleção de valor agendada para

realização.”

Joseph Moses Juran(1904-2008)

David J. Anderson

É um empreendimento não repetitivo, que possui as seguintes características: É temporário

Resulta em produto(s) que não existia(m) antes, ou existirá(ão) de forma diferente (exclusividade)

Possui restrições em custo, prazo, qualidade, recursos

Exige uma coordenação para ser executado (isto é, possui certo grau de complexidade)

Conduzido por pessoas

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)

É 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

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

“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.”

Jorge L. Bublitz

Revisão: Adail Muniz

1997-1998, Singapura Contexto: Desenvolvimento de um

grande sistema de empréstimos para um banco internacional

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

Decisão: Implantação das metodologias de OOAD de Peter Coad e de Gerência de Projetos de Jeff De Luca

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

Jeff De Luca Peter Coad

Stephen Palmer John Mac Felsing

Inovação Contínua

Adaptabilidade do Produto

Cronogramas Reduzidos de Entrega

Adaptabilidade das Pessoas e Processos

Resultados Confiáveis

Fornece a estrutura suficiente para equipes maiores

Enfatiza a produção de software de qualidade Entrega resultados frequentes, 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

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

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

<ação> <resultado> <objeto>

Calcular o total do salário do funcionário

ação objeto resultado

Novidade? Nunca viu algo parecido?

ENTRADA PROCESSAMENTOPROCESSAMENTO SAÍDA

Emitir recibo de entrega do processo

Autorizar a entrada fora do horário do expediente do funcionário

Assinar digitalmente o documento PDF

Autorizar a transferência do equipamento

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 É fácil de determinar quando está pronta

Fonte: www.heptagon.com.br Autor: Adail Muniz

Sua equipe não ficar assim:

Formadas dinamicamente Única forma de desenvolver por feature e

manter a posse de código Sob a coordenação de um Programador-

Chefe Múltiplas mentes projetando Comparação entre alternativas e escolha

da mais apropriada Membros são os Donos 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

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 simulacros ou objetos semelhantes

Representa algo que necessita ser registrado, que ocorre em algum momento ou durante ou intervalo de tempo

São atividades, eventos e serviços

Exemplos: Uma venda é algo que

acontece num certo momento

Uma estada (período de tempo)

Cor Rosa

Representa:

Uma Pessoa

Um certo local

Algo objeto (normalmente concreto)

Desempenham papéis nos Eventos

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

Cor Verde

É a representação de um papel que é desempenhado pelo “Pessoa-Coisa-Lugar”

Exemplos:

Uma pessoa, num hotel, pode ser funcionário, hóspede, terceirizado, ...

Um aeroporto pode ser local de origem, destino ou escala de um vôo

Cor Amarelo

É como um item num catálogo

Usado para concentrar dados comuns a diversos objetos

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

Cor Azul

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

Preocupa-se mais com a formado 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

Diagrama de: Classes *

Sequência

Estados

Casos de Uso

Lista preliminar de Features

Anotações nos Modelos

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

Categorizada em 3 níveis:1. Áreas de Negócio

2. Atividades de Negócio (Conjunto de Features)

3. Passos (Features) Artefatos produzidos: Lista de Features

Requisitos mais detalhados

Área de Negócio (Gerenciamento/Administração de...)

Atividade (<Verbo Infinitivo> ...)

• Feature 1

• Feature 2

• Feature 3

Atividade

• Feature 4

• Feature 5

• Feature 6

• Feature 7

• Feature 8

Atividade

• Feature 9

• Feature 10

• Feature 11

Gerenciamento de Recursos Humanos

Análise da

Documentação

• Feature 12

• Feature 13

Registro de

Novos

Servidores

• Feature 14

• Feature 15

• Feature 16

Registro de

Cursos e

Eventos

• Feature x

• Feature y

• Feature z

Classe A

Classe B

Classe C

Área n

Atividade X

Feature 1

Feature 2

Atividade Y

Feature 3

Feature 4

Feature 5

...

Com a Lista e o Modelo, deve-se agora planejar a ordem na qual as funcionalidades serão implementadas, tendo com base:

A necessidade do usuário

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”

Pressuposto: a equipe usa UML em cores e arquétipos

A Escala de 5 Pontos

Nº Estimado de Classes na Feature

Complexidade da Feature

Esforço(Pessoa-Dia)

1 1 1

2 2 2

3 3 3

4 4 5

5 5 8 (ou mais)

Interação 1

• (10)

Interação 2

• (8)

Interação 3

• (13)

Interação n

• (y)

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 Cuidado para não quebrar em pontos que causem

problemas

Deve-se refinar o projeto para cada Featureou Conjunto de Features relacionadas

Artefatos produzidos:

Modelos detalhados (Classes e Sequência)

Esqueletos de Classes com métodos

Pacote de Trabalho detalhado

Relatório de progresso atualizado

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

Testes* e Inspeções são realizados

O código final – o aprovado – é promovido

Status da Atividade:

Em andamentoRequer atençãoCompletadaNão iniciada

Nome da Atividade

de Negócio

(nº de features)

75%

Mês/Ano

Fonte: www.heptagon.com.br Autor: Adail Muniz

Autorização para Entrada fora do Horário do Expediente

Como funciona hoje:1. Servidor preenche Requerimento2. Chefia imediata autoriza3. Chefia Superior também autoriza4. Encaminha requerimento a Seção de

Segurança5. Encaminha Requerimentos Autorizados a

guarita

1. Servidor preenche requerimento em uma página da Intranet, acessada através de senha

2. Chefia imediata recebe e-mail com a solicitação e ali mesmo clica em “link” para acessar o sistema, que pode autorizar ou não

3. Sendo autorizada, é enviada e-mail para Chefia Superior, que também pode autorizar ou não

4. Chefe da Segurança recebe e-mail informando da autorização

5. O sistema gera uma página automaticamente a cada dia com os requerimentos autorizados

Autenticar usuário no sistema Preencher o requerimento de autorização Enviar e-mail a Chefia Imediata Autorizar/Recusar o requerimento pela Chefia

Imediata Enviar e-mail a Chefia Superior Autorizar/Recusar o requerimento pela Chefia

Superior Enviar e-mail ao Chefe da Segurança Gerar listagem de requerimentos autorizados

1ª Entrega

• Autenticar usuário no sistema

• Preencher o requerimento de autorização

2ª Entrega

• Autorizar/Recusar o requerimento pela Chefia Imediata

• Autorizar/Recusar o requerimento pela Chefia Superior

• Gerar listagem de requerimentos autorizados

3ª Entrega

• Enviar e-mail a Chefia Imediata

• Enviar e-mail a Chefia Superior

• Enviar e-mail ao Chefe da Segurança

RUP

• Rigorosidade

• Controle

• Equipes grandes

XP / SCRUM

• Agilidade

• Liberdade

• Equipes pequenas

Quero apenas oProcesso Suficiente

Escalável para Equipes Pequenas, Médias e Grandes

Estratégia

Portfólio

Produto

Entrega

Interação

DiaFeito pela equipe Feito pela equipe de projeto

Feito pela gerência superior

• Gerência de Requisitos

• Planejamento de Projeto

• Monitoramento e Controle de Projeto

• Gerência de Acordos Com Fornecedores –Gerência de Subcontratação

• Medição e Análise

• Garantia da Qualidade do Processo e do Produto

• Gerência de Configuração

Nível 2 –Gerenciado

Foco: Gerência Básica de Projetos

Fonte: www.heptagon.com.br Autor: Adail Muniz

• Desenvolvimento de Requisitos

• Solução Técnica

• Integração do Produto

• Verificação

• Validação

• Foco no Processo Organizacional

• Definição do Processo Organizacional

• Treinamento Organizacional

• Gerenciamento de Risco

• Análise e Tomada de Decisão

• Ambiente Organizacional para Integração

Nível 3 –Definido

Foco: Padronização do

Processo

Fonte: www.heptagon.com.br Autor: Adail Muniz

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!!

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

Principal divulgador da FDD no Brasil

Adail Muniz Retamal Heptaman

www.heptagon.com.br

"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."

Jorge Luis Bublitz

Formado em Administração de Empresas MBA em Planejamento Estratégico Pós-Graduação (Especialização) em Engenharia de Sistemas

Chefe da Seção de Banco de Dados (TRE-MT) Certificação Delphi e JBuilder Artigos publicados nas revistas Micro Sistemas (!?) e Clube Delphi

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

Jorge FDDMan

bublitz@tre-mt.gov.br

Email e MSN:bublitz@hotmail.com

Páginas:http://bublitz.tripod.com

http://jorge-fdd.blogspot.com