FAMÍLIA CRYSTAL

Prévia do material em texto

AULA 3 
 
 
 
 
 
 
 
 
 
 
DIFERENTES METODOLOGIAS 
ÁGEIS DE PROJETOS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Profª Ana Paula Costacurta 
 
 
2 
TEMA 1 – FAMÍLIA CRYSTAL 
Crystal é uma família de metodologias centrada em pessoas e 
comunicação. O tamanho e criticidade do projeto é o que define qual metodologia 
Crystal será utilizada. 
Existem duas regras comuns à família de metodologia Crystal: 
desenvolvimento incremental, com incrementos de no máximo quatro meses, e 
realização de oficinas de reflexão pré e pós-incremental. 
As metodologias Crystal possuem dois valores essenciais: comunicação 
centrada em pessoas e alta tolerância. Essas metodologias focam em 
colaboração direta e menor ênfase em documentações e emissões de relatórios, 
o que pode acarretar menos visibilidade sobre o progresso da equipe. 
Neste tema, veremos uma visão geral sobre a família de metodologia 
Crystal para conhecermos um pouco das características. 
Os tópicos que serão abordados: 
1. O que é Família Crystal; 
2. Características da Família Crystal. 
1.1 O que é Família Crystal 
A maneira de abordar a metodologia por projeto permite que o projeto use 
técnicas de adaptações para ajustar rapidamente. O nome Crystal é uma metáfora 
a cor e dureza de um cristal, em que a metodologia é indexada por cores: claro, 
amarelo, laranja, vermelho e assim por diante. Está entre uma das metodologias 
mais flexíveis, pois não depende de nenhum conjunto de processos ou 
ferramentas. 
Na Figura 3, podemos observar as duas dimensões. Quando se move para 
direita, significa coordenar mais pessoas; já o movimento para cima significa mais 
rigor e cerimônia. 
 
 
 
3 
Figura 1 – Nomes por cores das Metodologias Crystal 
 
Fonte: Costacurta, 2021. 
O nível de criticidade do sistema envolve a perda causada por um defeito 
que aparece durante a operação. Ele é dividido em quatro categorias: 
• Perda de conforto (Confort): a realização de algo que não traria prejuízo 
financeiro, apenas um desconforto. Como exemplo, podemos colocar um 
sistema de pedidos de comida que emite um pedido de lasanha no lugar 
de um pedido de pizza; 
• Perda de dinheiro discricionário (Discretionary Money): a realização de 
um faturamento errado que pode ser ajustado. Como exemplo, podemos 
colocar um sistema de companhia telefônica que emite a fatura do cliente 
errada; com um simples telefonema, o cliente consegue que sua fatura seja 
corregida; 
• Perda de dinheiro essencial (Essencial Money): o erro pode gerar danos 
reais que não são possíveis de consertar com simples telefonema. Como 
exemplo, podemos citar sistema de veículo autônomo, em que um erro não 
poderá ser consertado com apenas uma ligação; 
• Perda de vida (Life): são programas que podem matar pessoas. Como 
exemplo, podemos citar sistema de controle de uma usina nuclear ou 
ônibus espacial. 
 
 
4 
1.2 Características da Família Crystal 
A família Crystal possui um código genético em comum (Cockburn, 2004, 
p. 5): 
• Modelo de jogo econômico-cooperativo: leva as pessoas em um projeto 
a pensarem sobre o seu trabalho de uma forma muito específica, focada e 
eficaz. O desenvolvimento de software é comparado com um jogo 
cooperativo de invenção e comunicação com objetivo principal entregar um 
softeware útil e funcional e, consequentemente, preparar-se para o próximo 
jogo (Cockburn, 2002); 
• Seleção de prioridades: são prioridades em comum a todas as 
metodologias da família Crystal – a segurança no resultado do projeto, 
eficiência no desenvolvimento e habitabilidade das convenções, ou seja, 
desenvolvedores podem conviver com elas; 
• Seleção de propriedades: a equipe de projeto deve buscar sete 
propriedades de segurança, sendo que as três primeiras são essenciais. 
Veremos quais são as sete propriedades na sequência; 
• Seleção de princípios: são utilizados para guiar no design da metodologia. 
Veremos quais são os sete princípios na sequência; 
• Seleção de estratégias e técnicas: utilizadas para modelagem de 
metodologia, planejamento e melhoria reflexiva, em que são utilizadas com 
um conjunto inicial e Crystal. Não se requer que se utilize nenhuma técnica 
específica. Estudaremos esse item na sequência; 
• Funções e produtos de trabalho: as funções e produtos de trabalhos não 
são totalmente necessários nem totalmente opcionais. Estudaremos esse 
assunto na sequência. 
TEMA 2 – CRYSTAL NA PRÁTICA 
2.1 Os sete princípios 
Na concepção e avaliação de metodologias, existem sete princípios úteis 
(Cockburn, 2002): 
1. Comunicação interativa face a face: canal mais barato e rápido para a 
troca de informações; 
 
 
5 
2. Peso da metodologia é custo: a complexidade da metodologia e 
diretamente proporcional ao custo; 
3. Metodologias diferentes de acordo com tamanho da equipe: equipes 
maiores necessitam de metodologias diferenciadas com mais rigor; 
4. Maior formalidade para projetos maiores: é apropriada para projetos 
com maior criticidade; 
5. Feedback e comunicação eficiente: diminui a necessidade de resultados 
intermediários que não funcionam; 
6. Disciplina, habilidades e compreensão, formalidade e documentação: 
as metodologias leves se baseiam em compreensão, disciplina e habilidade 
mais do que em documentação, processo e formalidade das metodologias 
tradicionais; 
7. Eficiência: é dispensável em atividades sem gargalo sem retrabalho e 
utilização as capacidades ociosas. 
2.2 As sete propriedades 
Para se terem melhores equipes Cockburn (2004), sugerem-se sete 
propriedades aplicáveis a todos os tamanhos de projetos: 
1. Entregas frequentes: entrega funcional e código testado a cada poucos 
meses; 
2. Comunicação próxima: comunicação livre e sem barreiras, em que a 
informação flui naturalmente entre os membros da equipe; 
3. Melhoria reflexiva: reuniões para discussão do que pode funcionar melhor 
e fazer mudanças para próxima interação, ou seja, refletir para melhorar; 
4. Segurança pessoal: possibilidade de apresentar suas ideias e opiniões 
sem medo de represálias; 
5. Foco: planejamento de atividades e tranquilidade para trabalhar no que foi 
planejamento sem interrupções; 
6. Fácil acesso à especialistas: rápido feedback sobre a qualidade do 
produto, permitindo realizar testes e entregas frequentes; 
7. Ambiente técnico com testes automatizados, Gerenciamento de 
configuração e Integração contínua: testes contínuos, correções dos 
erros e repositório de código podem facilitar a resolução de problemas já 
no início do projeto. 
 
 
6 
2.3 Estratégias e técnicas 
Apresentaremos nesse tema um bom conjunto inicial de estratégias e 
técnicas que são recomendadas por desenvolvedores experientes. 
Na Imagem 6, veremos um resumo de estratégias e técnicas que serão 
abordados neste tema. 
Figura 2 – Resumo de Estratégias e técnicas 
 
Fonte: Costacurta, 2021 
2.3.1 Estratégias 
As cinco estratégias dos métodos Crystal são: 
1. Exploratório 360°: estratégia utilizada durante a fase de Fretamento 
(Chartering), em que é realizada a análise do projeto em todas as direções; 
2. Vença Cedo: estratégia de gerenciamento de projetos, que trabalha com 
entrega de algo de valor no início do projeto para ganhar autoconfiança; 
3. Esqueleto ambulante: é uma pequena implantação do sistema com a 
ligação dos principais componentes arquitetônicos para obter feedback 
mais rápido do cliente. A arquitetura e a funcionalidade podem então evoluir 
em paralelo; 
4. Rearquitetura incremental: estratégias relacionadas para priorizar o 
trabalho nas primeiras iterações. A partir do esqueleto ambulante, o 
 
 
7 
sistema precisará evoluir e também para lidar com as mudanças de 
requisitos ao longo do tempo; 
5. Radiadores de informação: uma estratégia de comunicação, em que as 
informações ficam disponíveis em lugar visível, o que possibilita à equipe 
solucionar todas as dúvidas. 
2.4 Técnicas 
As novetécnicas dos métodos Crystal são: 
1. Modelagem de Metodologia: coleta de informações sobre experiências 
anteriores e as usando para chegar às convenções iniciais; 
2. Oficina de reflexão: pausa de uma hora para reflexão após cada entrega, 
no formato de oficina para melhoria reflexiva sobre o trabalho, e realização 
de pequenas alterações nas próximas entregas, caso seja necessário; 
3. Planejamento Relâmpago: que, às vezes, também chamo de "jam 
session" de planejamento de projeto (como no jazz), para enfatizar sua 
natureza colaborativa, uma técnica de planejamento de projeto rápida e 
colaborativa, em que é realizada uma lista de dependências entre as 
tarefas; 
4. Estimativa Delphi: uma maneira de chegar a uma estimativa inicial para o 
projeto total; 
6. Reuniões diárias rápidas: uma maneira rápida e eficiente de passar 
informações ao redor da equipe diariamente, não sendo o foco discutir 
problemas e sim identificá-los; 
7. Projeto Ágil de Interface: uma versão rápida do design centrado no uso; 
8. Processo em miniatura: redução do projeto e oficinas para entendimento 
do projeto e redução do tempo do processo; 
9. Programação lado a lado: uma alternativa menos intensa à programação 
em pares; 
10. Gráficos Burn: uma maneira eficiente de planejar e relatar o 
progresso, particularmente adequado para uso em Radiadores de 
Informação. 
 
 
 
8 
TEMA 3 – CRYSTAL CLEAR 
A metodologia Crystal Clear é aplicada a equipes que contém duas a seis 
pessoas. Essa equipe deve estar alocada em uma mesma sala ou escritório que 
sejam adjacentes ou próximos. Inicialmente, a aplicação da metodologia exige a 
necessidade de realizar uma análise das forças e fraquezas da organização e se 
adequar às recomendações do Crystal Clear. 
A metodologia Crystal Clear é para equipes que desejam criar sua maneira 
pessoal, forte e eficaz de desenvolvimento de software. É uma metodologia que 
compartilha algumas características com XP. Porém, é uma metodologia menos 
exigente. 
A Crystal Clear requer as três primeiras propriedades: entrega frequente, 
comunicação próxima e melhoria reflexiva. As outras quatro são utilizadas por 
equipes que desejam ir mais além da zona de segurança. 
3.1 Processo 
O Crystal Clear usa ciclos aninhados de vários comprimentos. Na maioria 
dos projetos, podem ser percebidos sete ciclos: 
1. Ciclo de Projeto (Project Cycle): possui duração variável, com três partes: 
fretamento (chartering), dois ou mais ciclos de entrega (delivery cycles) e 
encerramento do projeto (completation ritual); 
2. Ciclo de Entrega (Delivery Cycle): possui duração de uma semana a três 
meses, com três ou quatro partes: recalibração do plano de liberação 
(recalibration of the release plan), uma ou mais interações (iterations), 
entrega para usuário final (delivery to real users) e conclusão (completion 
ritual); 
3. Ciclo de Interação (Iteration Cycle): possui duração de uma a três 
semanas, com três partes: planejamento (planning), atividades diárias 
(daily activities) e ciclo de interação (integration cycle) e conclusão 
(completion ritual); 
4. Ciclo Semanal (Weekly Cycle): segue o ritmo do calendário e mostra todo 
o trabalho realizado por uma semana; 
5. Ciclo de Integração (Integration Cycle): possui duração de 30 minutos a 
três dias e forma de exceção é conforme prática da equipe. Ver as 
propriedades: ambiente técnico com testes automatizados (Technical 
 
 
9 
Environment with Automated Tests), gerenciamento de configuração 
(Configuration Management) e integração frequente (Frequent Integration). 
6. Ciclo diário (Daily Cycles): segue o ritmo do calendário e mostra todo o 
trabalho realizado diariamente; 
7. Episódio de desenvolvimento (Development Episode): possui duração 
de alguns minutos ou horas. É onde o programador realiza o design, 
programação e testes unitários de uma tarefa. 
3.2 Atividade de fretamento 
A atividade de fretamento (Chartering) envolve várias atividades. A seguir, 
veremos as listas mais importantes: 
1. Criar a equipe principal (Build the Team): definição de um patrocinador 
executivo (Executive Sponsor), um designer leader (Lead Designer) e, se 
necessário, um usuário chave (key user). Após isso, ainda serão 
adicionados mais duas ou três pessoas a equipe. 
2. Realizar um exploratório 360º (Perform the Exploratory 360°): realiza 
uma verificação geral sobre as questões chaves e verificar todas as 
soluções e escolha da mais adequada para se certificar que o projeto não 
fracassará. Essa análise resulta em ajustes ou decisão de cancelar o 
projeto; 
3. Definição da metodologia (Shape the methodology): verificar todas as 
opções e escolha da melhor metodologia. Não deve demorar mais do que 
uma semana e pode ser realizado em dois dias. Pode ser feito utilizando a 
técnica Modelagem de Metodologia. Nada mais é do que as convenções 
que a equipe concorda em adotar; 
4. Planejamento inicial do projeto (Build the initial project plan): os 
desenvolvedores com o restante da equipe farão o planejamento da fase 
inicial. Existem várias maneiras de construir um plano básico dentro dos 
limites de tolerância do Crystal. Podemos citar alguns, como a técnica de 
planejamento Blitz, DSDM, Scrum e XP. 
3.3 Papéis e responsabilidades 
A metodologia Crystal Clear possui apenas uma equipe de projetos. Nas 
demais metodologias da família, há mais de uma equipe. 
 
 
10 
As metodologias da família Crystal possuem os principais papéis: 
Patrocinador Executivo (Executive Sponsor), Designer Líder (Lead Designer), 
Programador (Designer-Programmer) e Usuário Embaixador (Ambassador User) 
Possui papéis adicionais: Coordenador (Coordinator), Especialista de 
Negócios (Business Expert), redator (Writer), e testador (Tester). 
Na Tabela 1, podemos ver as responsabilidades de cada um dos papéis. 
Tabela 1 – Produtos de trabalho gerados por cada papel 
Papel Produto de trabalho 
Patrocinador Declaração de missão e as prioridades de troca 
Time como Grupo Estrutura do time e suas convenções 
Resultados do workshop de reflexão 
Coordenador O mapa do projeto 
O plano de liberação 
O status do projeto 
A lista de riscos 
O plano e o status da iteração 
O cronograma de visualização 
O especialista em 
negócios e o usuário 
Embaixador 
A lista ator-objetivo 
O arquivo de casos de uso e requisitos 
O modelo de função do usuário 
Designer principal (líder) Descrição da arquitetura 
Designer-Programador Os rascunhos da tela 
O modelo de domínio comum 
Os rascunhos e notas de design 
O código fonte 
Testador O relatório de erro naquele momento 
Redator O manual de ajuda do usuário 
Fonte: Costacurta, 2021. 
TEMA 4 – MÉTODO DE DESENVOLVIMENTO DE SISTEMAS DINÂMICOS 
O método de desenvolvimento de sistemas dinâmicos (Dynamic Systems 
Development Method – DSDM) é uma estrutura para gestão e entrega de projetos 
 
 
11 
ágeis. Foi criado, inicialmente, em 1994, por meio de uma colaboração de vários 
profissionais de projetos e muitas empresas em busca de criar qualidade nos 
processos de desenvolvimento rápido de aplicativos (Rapid Application 
Development – RAD1). Inicialmente, as empresas criaram um consórcio DSDM, 
como uma organização sem fins lucrativos. Em 2007, o DSDM consortium se 
tornou o DSDM universalmente disponível e, em 2016, foi denominado Agile 
Bussiness Conssortium. 
A DSDM Aterm, versão anterior ao DSDM, é uma implementação 
independente de fornecedor, sendo uma abordagem genérica para o 
gerenciamento de projetos ágil de projetos, sem focar exclusivamente na entrega 
de softeware. Em 2016, foi substituída pela versão DSDM Agile Project 
Framework. 
O DSDM Agile Project Framework, evolução do DSDM Aterm, em que a 
estrutura retém os princípios e adota as mesmas práticas robustas do DSDM 
Aterm, junto com um conjunto de funções e responsabilidades que são ideais. 
Nesse tema, vemos uma visão geral sobre a metodologia DSDM para 
conhecermosum pouco das características. 
Os tópicos que serão abordados: 
1. Filosofia; 
2. Princípios; 
3. Práticas. 
4.1 Filosofia 
Segundo DSDM (2021), a filosofia DSDM é baseada na ideia que “O 
melhor valor de negócios surge quando os projetos estão alinhados para 
objetivos de negócios claros, entregam com frequência e envolvem a 
colaboração de pessoas motivadas e capacitadas”. 
 
1 A metodologia RAD era muito popular em 90, priorizava uma prototipagem rápida e interações 
através de feedbacks do usuário. 
 
 
12 
Figura 3 – Filosofia DSDM (DSDM, 2021) 
 
A filosofia DSDM conta com um apoio de oito princípios que constroem a 
mentalidade e os comportamentos necessários para trazer a filosofia à vida. 
Esses princípios possuem apoio em 4 elementos: Pessoas, Processo, Produtos e 
Práticas. As pessoas possuem funções e responsabilidades definidas, com um 
processo Ágil, permitindo um ciclo de vida iterativo e incremental para 
desenvolvimento e entrega de formais, em que os produtos são claramente 
definidos e utilizando práticas para auxiliar a alcançar os melhores resultados. 
Podemos ver na Figura 3, de forma gráfica, a filosofia DSDM. 
4.2 Princípios 
É recomendado às equipes que adotem uma mentalidade que tenha como 
base os oito princípios do DSDM. Com isso, será possível obter todos os 
benefícios da estrutura DSDM. A seguir, podemos ver a lista dos oito princípios: 
1. Focar na necessidade do negócio (Focus on the business need): tomar 
as decisões tendo em mente sempre o objetivo principal do projeto; 
2. Entregar no prazo (Deliver on time): o fator de sucesso mais crítico; 
 
 
13 
3. Colaborar (Collaborate): as equipes colaborativas sempre superam as 
equipes tradicionais; 
4. Nunca comprometer a qualidade (Never compromise quality): o foco 
deve ser sempre entregar o sistema com qualidade boa o suficiente; 
5. Construir gradativamente a partir de fundações firmes (Build 
incrementally from firm foundations): realizar análise suficiente e 
projetar com antecipação; 
6. Desenvolver iterativamente (Develop iteratively): revisar o trabalho a 
cada iteração e coletar o feedback; 
7. Comunicar de forma contínua e clara (Communicate continuously and 
clearly): má comunicação pode levar ao fracasso do projeto; 
8. Demonstrar controle (Demonstrate control): garantir o controle contínuo 
do projeto com gerenciamento proativo de planos. 
4.3 Práticas 
No centro do DSDM, está uma coleção de práticas: 
• Caixa de Tempo (Timeboxing): período fixo de tempo, no qual, ao final, 
um objetivo foi alcançado. Cria motivação e pressão para atingir um 
objetivo em um período fixo; 
• Priorização de MoSCoW (MOSCOW Prioritisation): compreender a 
prioridade relativa dos requisitos ajuda a equipe a progredir e cumprir os 
prazos; 
• Oficinas (Workshops): oficinas facilitadas são uma prática comprovada 
para impulsionar a tomada de decisão e adesão rápida e de alta qualidade; 
• Modelagem (Modelling): Os modelos e protótipos ajudam a confirmar as 
expectativas e o entendimento, o que melhora a comunicação entre o 
projeto e os grupos de partes interessadas; 
• Prototipagem (Prototyping): como muitas metodologias ágeis, a 
prototipagem é essencial para testar a execução do projeto em um estágio 
conceitual inicial. É uma maneira de mapear as funções básicas, descobrir 
fraquezas gritantes e permitir que os usuários testem o software. 
 
 
 
 
14 
TEMA 5 – ABORDAGEM DSDM 
A Abordagem DSDM se diferencia das demais abordagens ágeis por 
manter a função de Gerente de projetos e se considera compatível com as 
abordagens de gerenciamento de projeto como PRINCE2 e PMI. 
Nesse tema, estudaremos uma visão geral sobre o funcionamento da 
metodologia DSDM. Os tópicos que serão abordados: 
1. Processo; 
2. Funções e responsabilidades; 
3. Produtos. 
5.1 Processo 
O processo de projeto DSDM integra o gerenciamento de projetos e 
desenvolvimento de produtos em um único processo. O modelo de processo 
DSDM compreende uma estrutura que apresenta as fases do DSDM. O Processo 
do Projeto tem quatro fases principais: Viabilidade, Fundações, Desenvolvimento 
Evolutivo e Implantação. Essas são precedidas pela Fase de Pré-Projeto e 
seguidas pela Fase de Pós-Projeto, totalizando seis fases. Na Figura 4, podemos 
ver graficamente o processo DSDM. 
Figura 4 – Modelo de Processo DSDM (DSDM, 2021) 
 
 
 
15 
5.2 Fases do Processo DSDM 
• Pré-projeto (Pre-Project): garante que o início do projeto seja realizado 
corretamente com base em um objetivo definido de forma clara; 
• Viabilidade (Feasibility): verifique se o projeto é tecnicamente viável e se 
o projeto proposto é viável; 
• Fundações (Foundations): as equipes passam algumas semanas 
estabelecendo a fim de compreender o âmbito do trabalho, como será 
executado, por quem, quando e onde. Essa fase leva a investigação 
preliminar da Viabilidade para o próximo nível, compreensão fundamental 
(mas não detalhada) da lógica do negócio para o projeto, a solução 
potencial que será criada pelo projeto, além de como o desenvolvimento e 
a entrega da solução serão gerenciados; 
• Desenvolvimento evolutivo (Evolutionary Development): com objetivo 
de desenvolver a solução, será necessário aplicar as práticas básicas. A 
equipe de desenvolvimento de solução cria incrementos de solução, 
explorando de forma interativa os detalhes de baixo nível dos requisitos e 
testando de forma contínua; 
• Implementação (Deployment): compreende três atividade principais – 
montar (assemble), revisar (review) e implantar (deploy) a versão – em que 
pode ser a solução final ou um subconjunto da solução final; 
• Pós-projeto (Post-Project): quantifique os benefícios entregues pelo 
projeto. 
5.3 Funções e responsabilidades 
O padrão no desenvolvimento de sistemas ágeis é ter uma lista de funções 
para serem preenchidas. A base para o sucesso de qualquer projeto é trabalho 
em equipe de forma eficaz, e a metodologia DSDM reconhece essa necessidade 
e atribui as funções e responsabilidades de forma clara a cada pessoa em um 
projeto. Na Figura 15, podemos ver o modelo da equipe DSDM 
As funções são agrupadas em três categorias: Equipe de Projeto, Equipe 
de desenvolvimento de soluções e Equipe de apoio. O esquema de cores na 
Figura 15 é o seguinte: 
• Laranja: interesses comerciais, funções que representam a visão 
comercial; 
 
 
16 
• Verde: solução / interesses técnicos, funções que representam a solução / 
visão técnica; 
• Azul: interesses de gestão, funções que representam a visão de gestão / 
liderança; 
• Cinza: interesses do processo, funções que representam a visão do 
processo; 
• Mistura de duas cores: uma função que abrange duas áreas distintas de 
interesse; por exemplo, Analista de Negócios, que tem um foco comercial 
e uma solução / técnica. 
 
 
 
17 
De acordo com seu manual (DSDM, 2021), essas são as funções 
essenciais em qualquer ambiente DSDM: 
• Gerente de projeto (Project Manager): função da Equipe de Projeto que 
se concentra no gerenciamento do ambiente de trabalho, coordenando 
todos os aspectos da gestão do projeto em um alto nível; 
• Coordenador técnico (Technical Coordinator): função da Equipe de 
Projeto que projetará a arquitetura do sistema e será responsável pelo 
controle de qualidade de todos os elementos técnicos; 
• Patrocinador de negócio (Business Sponsor): função da Equipe de 
Projeto responsável pelos casos de negócios e orçamentos do projeto. São 
os tomadores de decisão final e o único ponto de escalonamento final; 
• Visionário do negócio (Business Visionary): fornecendo direção de alto 
nível e uma visão do futuro; 
• Analista de negócios (Business Analyst): facilitador do relacionamento 
entre Equipe de Projeto e Equipe de Desenvolvimento de Soluções, 
garantindo que as decisões precisas e adequadas sejam tomadas e que as 
necessidades de negócios sejam modeladas e analisadas corretamente; 
• Embaixadordo negócio (Business Ambassador): função da Equipe de 
Desenvolvimento de Soluções que é o representante das necessidades de 
negócio dentro da Equipe de Desenvolvimento de Soluções. Participa da 
criação e priorização dos requisitos, fornece detalhes do dia a dia dos 
requisitos durante o desenvolvimento e, durante o desenvolvimento, é o 
principal tomador de decisões; 
• Líder de equipe (Team Leader): função de liderança da Equipe de 
Desenvolvimento de Soluções, que é responsável pela coordenação e 
facilitação da colaboração. Não é uma função de gerenciamento, trabalha 
com a equipe para planejar e coordena todos os aspectos da entrega do 
produto em nível detalhado; 
• Desenvolvedor de soluções (Solution Developer): é uma função da 
Equipe de Desenvolvimento de Soluções que interpreta os requisitos e 
traduz em um incremento de solução que atenda às necessidades 
funcionais e não funcionais; 
• Testador de solução (Solutions Tester): é uma função da Equipe de 
Desenvolvimento de Soluções com poderes, integrado à equipe e 
realizando testes em todo o projeto de acordo com a estratégia acordada; 
 
 
18 
• Facilitador das oficinas (Workshop Facilitador): função da Equipe de 
Apoio, que é responsável por gerenciar o processo de oficinas, sendo 
responsável por organizar e facilitar uma sessão para permitir aos 
participantes alcançarem o objetivo da oficina; 
• Técnico DSDM (DSDM Coach): função fundamental da Equipe de Apoio 
para equipe com pouca experiência no uso do DSM para auxiliar os 
membros a obter o máximo da abordagem. O ideal é que o técnico seja 
certificado em DSDM Coach. 
• Consultor técnico (Technical Advisor): apoia a equipe com fornecimento 
de informações técnicas e especializadas da perspectiva dos responsáveis 
pelo gerenciamento de mudanças operacionais, suporte operacional, 
manutenção contínua da solução etc.; 
• Consultor de negócios (Business Advisor): chamado para fornecer 
informações específicas e especializadas para o desenvolvimento ou teste 
de soluções, é um especialista no assunto de negócio. 
5.4 Produtos 
O DSDM descreve um conjunto de produtos a serem considerados 
conforme o avanço do projeto. Nem todos os produtos são necessários para todos 
os projetos e existe flexibilidade na formalidade de cada produto. O DSDM 
identifica dois tipos distintos de produto: 
• Produtos evolutivos: sofrem evolução com o tempo, abrangem várias 
fases do projeto e podem ter sua linha de base mais de uma vez durante 
esse tempo; 
• Produtos milestone: criados em uma fase e normalmente cumprem um 
propósito específico dentro dessa fase como um ponto de verificação ou 
para facilitar os processos de governança. 
 
 
 
 
 
 
19 
Figura 6 – Ciclo de vida do projeto na abordagem DSDM (DSDM, 2021) 
 
Na Abordagem DSDM, os produtos e em que eles aparecem no ciclo de 
vida do projeto são mostrados no Diagrama 17. Os significados das cores são: 
• Produto laranja: focados nos negócios; 
• Produto verde: contribuem para a solução que está sendo criada pelo 
projeto; 
• Produto azul: cobrem os interesses de gerenciamento e controle do 
projeto; 
• Produto G: podem desempenhar um papel nos processos de governança, 
como gateways de aprovação, e podem ser usados para demonstrar a 
conformidade da solução com os padrões corporativos e regulatórios, 
quando necessário. 
Na Tabela 2, podemos ver as funções e quais são os produtos produzidos. 
 
 
 
20 
Tabela 2 – Tabela de Produtos 
Produtor Produtos 
Analista de negócios Termos de Referência (Term of Reference) – Todos 
podem ter ideias no projeto. 
Caso de Negócio (Business Case) 
Lista de Requisitos Priorizados (Prioritised Req’s List – 
PRL) 
Definição da Arquitetura da Solução (Solution 
Architecture Definition) 
Coordenador Técnico Definição da Abordagem de Desenvolvimento 
(Development Approach definition) 
Gerente de Projeto Plano de Entrega (Delivery Plan) 
Definição da Abordagem de Gestão (Management 
Approach Definition) 
Avaliação de Viabilidade (Feasibility Assessment) 
Resumo da Fundação (Foundation Summary) 
Relatório de Revisão do Projeto (Project Review 
Report) 
Avaliação de benefícios (Benefits Assessment) 
Equipe de 
Desenvolvimento de 
Soluções 
Solução em evolução (Envolving Solution) 
Plano Timebox (TimeBox Plan) 
Líder de Equipe Registro de revisão do Timebox (Timebox Review 
Record) 
Fonte: Costacurta, 2021. 
 
 
 
21 
REFERÊNCIAS 
ABRAHAMSSON, P. et al. Agile Software Development Methods: Review and 
Analysis. Proc. Espoo 2002, p. 03-107. Disponível em: 
<https://www.researchgate.net/publication/292542090_Agile_Software_Develop
ment_Methods_Review_and_Analysis>. Acesso em: 7 dez. 2021. 
COCKBURN, A. Agile Software Development, 2002. Disponível em: 
<https://www.researchgate.net/publication/235616359_Agile_Software_Develop
ment> Acesso em: 7 dez. 2021. 
COCKBURN, A. Crystal clear a human-powered methodology for small 
teams. 2004. Disponível em: 
<https://www.researchgate.net/publication/234820806_Crystal_ clear_a_human-
powered_methodology_for_small_teams>. Acesso em: 7 dez. 2021. 
DSDM. O DSDM Agile Project Framework (de 2014 em diante). Disponível em: 
<https://www.agilebusiness.org/page/TheDSDMAgileProjectFramework>. Acesso 
em: 7 dez. 2021.