O documento descreve como o Scrum, FDD e XP podem ser usados juntos para fornecer uma abordagem de engenharia de software 100% ágil. O Scrum é usado para gerenciamento de projetos, o FDD para requisitos e arquitetura de software, e as práticas XP para desenvolvimento de software como codificação, testes e refatoração.
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
1. Engenharia
de Software
“100%” Ágil
Engenharia de Software Ágil (SCRUM, FDD e XP)
SCRUM, FDD e XP
www.etecnologia.com.br
Rildo F Santos
rildo.santos@etecnologia.com.br
(11) 9123-5358
@rildosan
(11) 9962-4260 http://rildosan.blogspot.com/
Versão 4 6
Versão Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com
2. Sobre o autor: Rildo F. Santos
Coach e Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil.
A Gestão Ágil ajuda as empresas a responder mais rápido as demandas de negócio e mudanças. A Gestão 2.0,
abrange Planejamento Estratégico, Gestão por Processos Ágeis, Gestão de Projetos Ágeis, Tecnologia da Informação
(Métodos Ágeis), Inovação e Liderança.
Minha Experiência:
Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de
Software. Formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia
Engenharia de Software Ágil (SCRUM, FDD e XP)
de Software pela Universidade Mackenzie.
Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java na Sun Microsystems e na IBM.
Conheço Métodos Ágeis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço),
RUP/UP - Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias.
Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA.
Possuo fortes conhecimentos de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de
Projetos e GRC - Governance, Risk and Compliance), SOX, Basel II e PCI;
E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento dos principais
frameworks e padrões: ITIL, Cobit, ISO 27001 e ISO 15999;
Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software,
Projetista de Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro, Saúde,
Comunicação, Segurança Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.
Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified
Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;
Sou membro do IIBA-International Institute of Business Analysis (Canada)
Onde estou:
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 2
3. Comentário inicial:
Engenharia de Software Ágil, ainda falta algo...
Engenharia de Software Ágil (SCRUM, FDD e XP)
Para desenvolver um software (ou produto), os métodos ágeis são altamente
recomendáveis e já descobrimentos que podemos usar diversos métodos juntos.
O Scrum pode ser utilizado para a Gestão de Projetos. Contudo, ele não faz abordagem
sobre a engenharia de software.
O FDD pode ser utilizado para Engenharia de Software: Requisitos de Software e também
para arquitetura.
Mas, será que faltou algo ?
SIM, FALTOU! Você ainda não é 100% Ágil...
> E a codificação, testes, patterns, refactoring1...O quê podemos usar ?
Nesta apresentação vamos responder como usar “XP”, que é método ágil, para o
desenvolvimento de software (codificação, testes e refactoring).
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 3
4. Engenharia de Software Ágil ?
SCRUM FDD
Engenharia de Software Ágil (SCRUM, FDD e XP)
Gestão de Projetos
Requisitos de Software
E a codificação e
os testes
do software ?
Não somos 100%
Ágeis
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 4
5. Engenharia de Software Ágil ?
Ciclo de Desenvolvimento de Software na Visão Ágil
Engenharia de Software Ágil (SCRUM, FDD e XP)
Práticas de
Engenharia de
Software
Ágeis ?
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 5
6. Engenharia de Software Ágil ?
SCRUM
Engenharia de Software Ágil (SCRUM, FDD e XP)
FDD
Gestão de Projetos
Requisitos de Software
Agora sim...
100% Ágil
XP
desenvolvimento
de Software
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 6
7. Engenharia de Software Ágil (SCRUM, FDD e XP) Engenharia de Software Ágil: Qual o papel de cada um ?
Engenharia de Software “100% “Ágil:
O SCRUM é utilizado para a Gestão de Projetos. Já para as práticas de
Enegnharia de Software utilizamos o FDD (requisitos de software e
arquitetura) e as Práticas XP para desenvolvimento de software
(codificação, testes e refactoring).
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 7
8. Sobre SCRUM:
Se você já conhece
o SCRUM, pule esta
parte
Engenharia de Software Ágil (SCRUM, FDD e XP)
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 8
9. O que é o SCRUM ?
The New, New
Product Iterative,
Development Incremental O que é SCRUM ?
Game TimeBoxes Development SCRUM é um processo iterativo e
incremental para desenvolvimento de
qualquer produto ou gerenciamento de
qualquer trabalho...
Engenharia de Software Ágil (SCRUM, FDD e XP)
SmallTalk SRUM é:
Engineering Tools Processo empírico de gerenciamento e
controle.
- Faz a inspeção e adaptação em loops
de feedback
- Faz entrega de valor ao cliente em até
30 dias;
- “Escalável” para suportar grandes
projetos
- Compatível com CMM3 e ISO9001
- Extremamente simples, mas muito
resistente...
Valores do Scrum::
- Transparência
-Integridade: assim que perceber
algo, faça algo
- Ser empírico
- Auto-organização
- Entrega de valor
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 9
10. O coração do SCRUM
Legenda:
Retrospectiva
Revisão da Sprint
Cerimônias Planejamento
da Sprint
da Sprint
artefatos Reunião
diária
Engenharia de Software Ágil (SCRUM, FDD e XP)
24 horas
Visão Produto Sprint
Backlog Backlog
Produto
2-4 Semanas
Papéis Cerimônias Artefatos
• Product Owner (PO) • Planejamento da Sprint • Product Backlog
• ScrumMaster (SM) • Reunião Diária • Sprint Backlog
• Equipe Scrum • Revisão da Sprint • Burndown (gráfico) Burndown
• Retrospectiva da Sprint
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 10
11. ROAD MAP do SCRUM
Visão do
Produto
Product Planejamento Selected Product Sprint
Backlog da Sprint Backlog Backlog
Tarefas
da Sprint
Engenharia de Software Ágil (SCRUM, FDD e XP)
Reunião
diária
Equipe
Product
Onwer
facilita
SCRUM
ajuda
Master
facilita
Execução da
Sprint
facilita
Revisão da Sprint
Produto
Retrospectiva da Sprint
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 11
12. Papéis
O SCRUM tem somente três papéis: Product Onwer (PO), SCRUM Master (SM)
e a equipe SCRUM.
Product Owner, responsável por:
- Definir a Visão do Produto
- Elaborar e manter o Product
Backlog
Engenharia de Software Ágil (SCRUM, FDD e XP)
- Definir a prioridade e ROI;
- Representar o cliente
- Aceitar ou rejeitar os entregáveis
SCRUM Master é responsável por:
- Ser um líder (servidor);
- Remover impedimentos;
- Proteger a equipe;
- Ajudar o PO (com Product Backlog);
- Ser o facilitador da equipe;
- Garantir as práticas SCRUM.
Equipe SCRUM é responsável por:
- Fazer estimativa;
- Definir as tarefas;
- Desenvolver o produto;
- Garantir a qualidade do produto;
- Apresentar o produto ao cliente
Equipe: auto-gerenciável e multifuncional
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 12
13. Engenharia de Software Ágil (SCRUM, FDD e XP) A Equipe e Comprometimento:
Envolvidos Comprometidos
Stakeholders Product Onwer
(clientes e usuários finais)
SCRUM Master
Equipe
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 13
14. TimeBox e Sprint
O que é Timebox ?
É um conceito diz que a quantidade de tempo (horas ou dias) é imutável, ou seja,
a quantidade de horas não poderá aumentar. Assim, evita-se atraso no prazo de
entrega e facilita o planejamento.
Entretanto, quanto se erra a estimativa de tempo (leia-se: horas ou dias) de uma
Sprint (leia-se: iteração), neste caso é recomendável reduzir o escopo da Sprint,
Engenharia de Software Ágil (SCRUM, FDD e XP)
desde que não afete a meta da Sprint (isto é discutido um mais a frente) ao invés
de aumentar a quantidade de horas/dias.
Timebox = Um prazo ou tempo (dias/horas por exemplo) bem definido e
imutável.
O que é uma Sprint ?
É uma iteração (que pode ser parte de uma release) que deve ser realizada de 2 a
4 semanas, no qual a equipe do projeto deverá produzir um entregável de valor
para o cliente (lembre-se do dos Princípios do Manifesto Ágil).
A entrega de valor é a meta da Sprint que deverá esta bem definida e combinada
com o cliente, antes do começo da execução da Sprint.
O conceito de Timebox é aplicado a Sprint.
O conceito de timebox é aplicado as cerimônias (reuniões) do Scrum. Todas as reuniões são
Timeboxed:
- Reunião de Planejamento da Sprint (8 horas)
- Reunião Diária (15 minutos)
- Reunião de Revisão da Sprint (4 horas*)
- Reunião de Retrospectiva da Sprint (3 horas*)
Nota: * A quantidade de horas pode variar de acordo com a necessidade (por exemplo, apresentação do que será entregue ao
cliente) ou aquilo que será discutido/debatido, neste caso a Retrospectiva ela poderá variar entre 1 a 3 horas
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 14
15. Desenvolvimento Iterativo e Incremental:
Entrega 1 Entrega 2 Entrega 3
Incremental Devido a complexidade,
tamanho, mudanças de
requisitos, urgência e
necessidade de demonstrar
valor mais rápido, fica quase
inconcebível desenvolver
Engenharia de Software Ágil (SCRUM, FDD e XP)
software utilizado o modelo
cascata, ou seja desenvolver
todo o software de uma única
vez.
Iterativo
Desenvolvimento Iterativo e
incremental é uma estratégia
de planejamento (que segue a
linha dividir para conquistar
), onde o software é
construído em partes, ou seja,
em ciclos (iterações), a cada
iteração é feito um novo
incremento (parte do software
funcional) até completar o
software.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 15
16. Planejamento no SCRUM, O Planehamento Ágil :
Cebola do Planejamento
Engenharia de Software Ágil (SCRUM, FDD e XP)
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 16
17. Product Backlog:
O que é Product Backlog ?
É uma lista contendo todas as funcionalidades desejadas para um produto.
O produto deve ter somente um Product Backlog (PB) independente número de equipes
que está trabalhando no projeto.
PB poderá ser criado de diversas maneiras:
- Com Estórias de Usuário, Com Casos de Uso ou Com “Features” (funcionalidades de
Engenharia de Software Ágil (SCRUM, FDD e XP)
produto).
Exemplo de Product Backlog: Sistema de Reserva On-Line
Product Owner
Product Owner (PO), é responsável por
elaborar e manter Product Backlog
atualizado, bem como priorizar seus itens.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 17
18. Cerimônias:
Reunião de Planejamento da Sprint (8 horas)
Participantes: PO, Equipe e SCRUM MASTER
Esta reunião é primeira reunião, seu objetivo é fazer
o planejamento da Sprint. Ela é dividida em duas partes.Na primeira parte o PO definirá prioridade, seleção dos
itens do backlog e meta da Sprint.
Na segunda parte a equipe definirá a Sprint Backlog (que são as tarefas necessárias para cumprir a meta).
Engenharia de Software Ágil (SCRUM, FDD e XP)
Reunião Diária (15 minutos)
Participantes: Equipe e SCRUM MASTER
Nesta reunião somente membros da equipe devem participar. A duração dela é de 15 minutos. As pessoas
fazem a reunião de pé. O objetivo desta reunião é fazer que as pessoas respondam 3 questões:
- O que eu fiz ontem ?
- O que vou fazer hoje ?
- Encontrei algum impedimento ?
Revisão da Sprint (4 horas*)
Participantes: PO, Equipe e SCRUM MASTER
Esta reunião acontece no final da Sprint, opcionalmente outras pessoas podem ser convidadas (se necessário).
O objetivo da reunião é apresentar o que a equipe fez durante a Sprint e fazer a entrega do produto (software
funcionando) para o PO. (Normalmente é apresentado uma demo do software).
Geralmente ela é feita em um auditório ou em uma sala de reunião
Retrospectiva da Sprint (3 horas*)
Participantes: Equipe e SCRUM MASTER
Esta reunião acontece logo após a Revisão da Sprint.
O objetivo dela é avaliar o que deu certo e que deu errado durante a Sprint, e fazer os ajustes possíveis para
a próxima Sprint, ou seja, o ciclo de melhoria contínua.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 18
19. Engenharia de Software Ágil ?
Se você já conhece
o FDD, pule esta
parte
Engenharia de Software Ágil (SCRUM, FDD e XP)
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 19
20. O que é o FDD (Feature Driven Development) ?
O FDD foi criada em 1997 num grande
Feature Driven Development (Desenvolvimento projeto em Java para o United Overseas
Guiado por Funcionalidades) é uma metodologia ágil Bank, em Singapura.
para gerenciamento e desenvolvimento de software. Nasceu a partir da experiência de análise
e modelagem orientadas por objetos de
Peter Coad, e de gerenciamento de
Ela combina as melhores práticas do gerenciamento projetos de Jeff De Luca.
ágil de projetos com uma abordagem completa para Foi inicialmente publicada em 1999, no
Engenharia de Software Ágil (SCRUM, FDD e XP)
capítulo 6 do livro "Java Modeling in
Engenharia de Software orientada por objetos, Color with UML", de Peter Coad, Eric
conquistando os três principais públicos de um Lefebvre e Jeff De Luca.
projeto de software: Em 2002, Stephen Palmer (gerente de
- Clientes, desenvolvimento do projeto em
Singapura) e John Mac Felsing
- Gerentes, (arquiteto senior na TogetherSoft)
-Desenvolvedores. publicaram o livro "A Practical Guide to
Feature Driven Development", com a
- versão completa, atualizada e comentada
Seus princípios e práticas proporcionam um da metodologia.
equilíbrio entre as filosofias tradicionais e as mais Em 2003, David Anderson, que foi o
extremas, proporcionando uma transição mais suave especialista em interface com o usuário,
no projeto de Cingapura, publicou um
para organizações mais conservadoras, e a marco na literatura Ágil, "Agile
retomada da responsabilidade para as organizações Management for Software Engineering:
Using the Theory of Constraints for
que se desiludiram com as propostas mais radicais. Business Results", onde oferece uma
análise profunda sobre a FDD (entre
outras metodologias), além de material
O lema da FDD é: "Resultados freqüentes, inédito sobre a FDD.
tangíveis e funcionais."
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 20
21. Engenharia de Software Ágil (SCRUM, FDD e XP) FDD (Feature Driven Development)
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 21
22. O que é o FDD (Feature Driven Development) ?
A FDD é uma metodologia muito objetiva. Possui apenas duas fases:
- Concepção & Planejamento: Pensar um pouco antes de fazer (tipicamente de 1 a 2
semanas)
- Construção: Fazer de forma iterativa (tipicamente em iterações de 2 semanas)
Os cinco processos são bem definidos e integrados:
Engenharia de Software Ágil (SCRUM, FDD e XP)
DMA (Desenvolver um Modelo Abrangente): Análise Orientada por Objetos
CLF (Construir a Lista de Funcionalidades): Decomposição Funcional
PPF (Planejar por Funcionalidade): Planejamento Incremental
DPF (Detalhar por Funcionalidade): Desenho (Projeto) Orientado por Objetos
CPF (Construir por Funcionalidade): Programação e Teste Orientados por Objetos
A FDD chama a atenção por algumas características peculiares:
- Resultados úteis a cada duas semanas ou menos
- Blocos bem pequenos de funcionalidade valorizada pelo cliente, chamados "Features"
- Planejamento detalhado e guia para medição
- Rastreabilidade e relatórios
- Monitoramento detalhado dentro do projeto, com resumos de alto nível para clientes e
gerentes, tudo em termos de negócio
- Fornece uma forma de saber, dentro dos primeiros 10% de um projeto, se o plano e a
estimativa são sólidos
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 22
23. Os Processos
A FDD é, classicamente, descrita por cinco processos:
DMA - Desenvolver um Modelo Abrangente: pode envolver desenvolvimento de requisitos,
análise orientada por objetos, modelagem lógica de dados e outras técnicas para entendimento do
domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível,
que guiará a equipe durante os ciclos de construção.
Engenharia de Software Ágil (SCRUM, FDD e XP)
CLF - Construir uma Lista de Funcionalidades: decomposição funcional do modelo do domínio,
em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados da
atividade (funcionalidades). O resultado é uma hierarquia de funcionalidades que representa o
produto a ser construído (também chamado de product backlog, ou lista de espera do produto).
PPF - Planejar por Funcionalidade: abrange a estimativa de complexidade e dependência das
funcionalidades, também levando em consideração a prioridade e valor para o negócio/cliente. O
resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada
para a construção.
DPF - Detalhar por Funcionalidade: já dentro de uma iteração de construção, a equipe detalha os
requisitos e outros artefatos para a codificação de cada funcionalidade, incluindo os testes. O
projeto para as funcionalidades é inspecionado. O resultado é o modelo de domínio mais
detalhado e os esqueletos de código prontos para serem preenchidos.
CPF - Construir por Funcionalidade: cada esqueleto de código é preenchido, testado e
inspecionado. O resultado é um incremento do produto integrado ao repositório principal de código,
com qualidade e potencial para ser usado pelo cliente/usuário.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 23
24. Visão da Arquitetura:
Apresentação
(Visões e Controladores de Interface)
Engenharia de Software Ágil (SCRUM, FDD e XP)
Negócio
(Domínio do Problema)
Interface com
Persistência
outros sistemas
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 24
25. Sobre UML Color
UML Color é um conjunto de quatro cores associadas a UML (Unified Modeling Language). O sistema de
coloração indica quais vários arquétipos se aplicam ao objeto UML. UML tipicamente identifica um estereótipo
com um comentário entre parênteses, para cada objeto que identifica se é uma classe, interface, etc.
Estas cores foram pela primeira vez sugerida por Peter Coad , Eric Lefebvre e Jeff De Luca em
uma série de artigos no The Letter Coad e posteriormente publicado em seu livro Java
Modeling em cores com UML.
Ao longo de centenas de modelos de domínio, ficou claro que quatro grandes "tipos" de classes apareceu de
Engenharia de Software Ágil (SCRUM, FDD e XP)
novo e de novo - apenas um nome diferente para se adequar ao domínio. Estes eram chamados de arquétipos
(depois de muita discussão), que serve para transmitir que as classes de um arquétipo dado seguem mais ou
menos da mesma forma.
Isto é, atributos , métodos , associações e interfaces são bastante semelhantes entre as classes de um
determinado arquétipo.
Ao tentar classificar um determinado domínio de classe, tipicamente uma pergunta sobre os padrões de cor,
nesta ordem:
Rosa: momento, intervalo - Será que representam um momento ou intervalo de tempo? Um exemplo
seria um objeto que armazena temporariamente as informações de login durante o processo de
Autenticação.
Amarelo - papéis - É uma maneira de participar de uma atividade (por qualquer pessoa, lugar ou coisa) ?
Assinatura em um sistema como um administrador, que muda o comportamento do programa,
exigindo uma senha que contas de convidado não, é um exemplo.
Azul - Descrição - É simplesmente uma descrição do catálogo-como a que classifica ou objeto 'rótulos„ Um ?
Se os usuários do sistema são rotulados com base no departamento de uma empresa em que trabalham
dentro e isso não muda a forma como o sistema se comporta, isso seria uma
descrição.
Verde - parte, lugar ou coisa - algo tangível, unicamente identificável. Normalmente, se você passar a
três perguntas acima e acabam por aqui, sua classe é um verde ". O usuário do sistema e as
sub-seções do sistema são todos os que visitam PPTs.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 25
26. Engenharia de Software Ágil (SCRUM, FDD e XP) Exemplo: UML em cores:
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 26
27. As disciplinas envolvidas:
Gestão Ágil de Projetos
Engenharia de Software Ágil (SCRUM, FDD e XP)
Fonte: Adail Muniz Retamal - www.heptagon.com
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 27
28. Engenharia de Software Ágil (SCRUM, FDD e XP) Engenharia de Software Ágil: XP
XP
desenvolvimento
de Software
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 28
29. Engenharia de Software Ágil (SCRUM, FDD e XP) Engenharia de Software Ágil: XP
A Programação eXtrema (XP, do inglês eXtreming Programming) é um método ágil para
o processo de desenvolvimento de software ágil e iterativa. O método XP propõe um
processo leve, centrado no desenvolvimento iterativo e com a entrega constante de
pequenas partes da funcionalidade do software.
O primeiro projeto XP foi feito em março de 1996.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 29
30. Engenharia de Software Ágil: XP (Extreme Programming)
- Programação eXtrema: Desenvolvendo Software com Qualidade e Agilidade
O XP é uma técnica revolucionária de desenvolvimento de software que se opõe a uma
série de premissas adotadas pelos métodos tradicionais de engenharia de software. XP
consiste numa série de práticas e regras que permitem aos programadores desenvolver
software de alta qualidade de uma forma dinâmica e ágil.
Engenharia de Software Ágil (SCRUM, FDD e XP)
A metodologia se baseia nas seguintes práticas (2000):
Jogo do Planejamento Programação Pareada
Versões Pequenas Propriedade Coletiva do Código
Metáfora Integração Contínua e Freqüente
Projeto Simples Ritmo Sustentável
Desenvolvimento Orientado por Testes Cliente com os desenvolvedores
Testes dos Clientes Padrão de Código
Refatoração
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 30
31. Engenharia de Software Ágil: XP
Comentários sobre algumas práticas:
Jogo de Planejamento (Planning Game): O desenvolvimento é feito em iterações semanais. No início
da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. Essa reunião
recebe o nome de Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as
estimam. O cliente é essencial neste processo e assim ele fica sabendo o que está acontecendo e o
que vai acontecer no projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um
contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de
Engenharia de Software Ágil (SCRUM, FDD e XP)
projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente
testadas e prontas para serem postas em produção.
Pequenas Versões (Small Releases): A liberação de pequenas versões funcionais do projeto auxilia
muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está
comprando.
Metáfora (Metaphor): Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O
conceito de rápido para um cliente de um sistema jurídico é diferente para um programador experiente
em controlar comunicação em sistemas em tempo real, como controle de tráfego aéreo. É preciso
traduzir as palavras do cliente para o significado que ele espera dentro do projeto.
Projeto Simples (Simple Design): Simplicidade é um princípio da XP. Projeto simples significa dizer
que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no
sistema com a senha "123" e assim ter acesso a todo o sistema, você vai fazer o código exato para que
esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições
de acesso. Um erro comum ao adotar essa prática é a confusão por parte dos programadores de
código simples e código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução
mais simples por parte de projeto. Esse entendimento é fundamental para o bom andamento do XP.
Código fácil deve ser identificado e substituído por código simples.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 31
32. Engenharia de Software Ágil: XP
Comentários sobre algumas práticas:
Testes de Aceitação (Customer Tests): São testes construídos pelo cliente e conjunto de analistas e
testadores, para aceitar um determinado requisito do sistema.
Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho
saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando
Engenharia de Software Ágil (SCRUM, FDD e XP)
trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a
prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de
trabalho e a motivação da equipe devem estar sempre em harmonia.
Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se perder o foco nos assuntos,
produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.
Posse Coletiva (Collective Ownership): O código fonte não tem dono e ninguém precisa solicitar
permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as
partes do sistema.
Programação em Pares (Pair Programming): é a programação em par/dupla num único computador.
Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um
instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o
instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é
revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se
sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.
Padrões de Codificação (Coding Standards): A equipe de desenvolvimento precisa estabelecer
regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código
fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 32
33. Engenharia de Software Ágil: XP
Comentários sobre algumas práticas:
Refatoração (Refactoring): É um processo que permite a melhoria continua da programação, com o
mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refabricar
melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento,
evitando a duplicação de código-fonte;
Integração Contínua (Continuous Integration): Sempre que produzir uma nova funcionalidade,
Engenharia de Software Ágil (SCRUM, FDD e XP)
nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de
conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status
real da programação.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 33
34. Engenharia de Software Ágil (SCRUM, FDD e XP) Engenharia de Software Ágil: As NOVAS práticas XP (ou Regras)
http://www.extremeprogramming.org/rules.html
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 34
35. Engenharia de Software Ágil: XP
Os princípios fundamentais são:
- Feedback rápido:
Quanto mais demorado o feedback menor o aprendizado produzido por ele.
- Simplicidade assumida:
Engenharia de Software Ágil (SCRUM, FDD e XP)
Desenvolver a solução mais simples que possa funcionar. Não construir complexidade desnecessária
- Mudança incremental:
Grandes mudanças tendem a não funcionar; os problemas são normalmente esolvidos com uma
série de pequenas mudanças naquilo que faz diferença.
- Aceitar mudanças:
A mudança é inevitável. Ao invés de combater a mudança, aceitá-la como normal e saudável para o
projeto.
- Trabalho de qualidade:
Todos gostam de fazer um trabalho de qualidade; se as pessoas que estão no projeto não gostam da
qualidade do trabalho que estão fazendo, a tendência do projeto é fracassar.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 35
36. Engenharia de Software Ágil: XP
Além destes princípios fundamentais, existem outros que também são importantes:
- Ensinar a aprender:
Melhor do que um monte de frases doutrinárias, tais como "Você deve testar como XYZ...", devemos
focar em ensinar estratégias de se aprender quanto teste deve ser feito; isto também vale para o
refactoring de código, projeto, planejamento, etc.
Engenharia de Software Ágil (SCRUM, FDD e XP)
- Pequeno investimento inicial:
Muito dinheiro logo no início do projeto não faz bem; a melhor abordagem é ter dinheiro o suficiente
para começar e ir incrementando o orçamento conforme o retorno do investimento que vai sendo
dado para o cliente.
- Jogar para ganhar:
Deve-se sempre jogar para ganhar, e não jogar para não perder. Jogar para ganhar significa fazer o
que quer que seja necessário para obter sucesso no projeto, e nada que não ajude.
- Experiências concretas:
Antes de tomar decisões deve-se experimentar algumas alternativas.
- Comunicação honesta e aberta:
Falta de comunicação dentro da equipe prejudica o ambiente de trabalho e o projeto como um todo.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 36
37. Engenharia de Software Ágil: XP
Além destes princípios fundamentais, existem outros que também são importantes:
- Trabalhar de acordo com o instinto das pessoas, e não contra ele:
Pessoas gostam de fazer um bom trabalho, como elas gostam de comunicar-se e de aprender.
Entender essas características naturais irá criar um time feliz e de sucesso.
- Responsabilidade aceita:
Engenharia de Software Ágil (SCRUM, FDD e XP)
Pessoas que tomam tarefas para si irão fazer um trabalho melhor que aquelas que têm tarefas
designadas a elas. A responsabilidade não deve ser imposta às pessoas, mas aceita por elas.
- Adaptação local:
Os costumes e práticas de desenvolvimento locais devem ser respeitados ao máximo quando da
implantação da XP.
- Viagem leve:
Não carregue documentação que não seja essencial para o projeto; jogue fora tudo aquilo que
não precisa mais. O código é a documentação mais atualizada.
- Medição honesta:
Medir sempre o desenvolvimento, mas nunca numa maneira que não seja suportada pelos
instrumentos disponíveis, ou pela simples necessidade de haver mensuração.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 37
38. Engenharia de Software Ágil: XP
Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em
escopo.
Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o
negócio. Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas
serão adiadas ou canceladas.
Engenharia de Software Ágil (SCRUM, FDD e XP)
Custo
escopo
Prazo Qualidade
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 38
39. Engenharia de Software Ágil: XP
Práticas de programação:
O processo de programação tem como características a programação em pares
e a propriedade coletiva do código.
Na programação em pares (em dupla), dois programadores ocupam um único
computador. Embora, a princípio, isto possa ser visto como um desperdício de
Engenharia de Software Ágil (SCRUM, FDD e XP)
esforços, várias vantagens podem ser obtidas. Esta estratégia aumenta a
qualidade do código e não altera o tempo de entrega, uma vez que haverá um
ganho posterior nas etapas de retirada de erros (defeitos). Os dois
programadores atuam de forma colaborativa. Enquanto o que está com o
teclado e mouse está pensando diretamente na codificação (sintaxe, variáveis,
fluxos de controle, etc.), o outro pode pensar estrategicamente em como o
código irá interagir como outras partes do programa. Além disso, um atua com
uma visão mais crítica corrigindo erros dos companheiros e pode pensar nas
futuras mudanças e etapas posteriores. Isto permite que a tradicionalmente
prática do codifica-e-conserta, criticada nas origens do desenvolvimento de
software, possa ser realiza sem perda da qualidade do software.
A propriedade coletiva do código é outra característica fundamental do
método XP, com a rotatividade do código entre os programadores e reuniões
freqüentes para estabilizar o código. A propriedade coletiva encoraja o time
todo a contribuir com novas idéias. Qualquer membro do time pode adicionar
funcionalidade, corrigir erros ou re-fabricar o código. Não existe a figura do
arquiteto chefe. Todos são responsáveis pelo código inteiro. Não existe alguém
para aprovar as mudanças. Reuniões freqüentes devem ser definidas como
parte do processo iterativo de programação. Estas reuniões devem ser curtas e
são realizadas com todos de pé (stand up meeting).
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 39
40. Engenharia de Software Ágil: XP
Práticas de programação: (continuação)
A prática do codifica-e-refactoring também requer um processo constante de
teste de unidade e integração. Para isto funcionar bem, os desenvolvedores
devem trabalhar com uma ferramenta de testes automático e um repositório
coletivo do código fonte. Os desenvolvedores devem criar testes de unidades
e liberar o código apenas quando estiver 100% testado. Uma vez no
repositório, qualquer um pode fazer alterações e adicionar novas
Engenharia de Software Ágil (SCRUM, FDD e XP)
funcionalidades. Uma ferramenta de controle de versões é fundamental.
O refactoring é uma atividade fundamental e necessária para o XP
funcionar. Mesmo que o código esteja 100% testado, para viabilizar reuso,
ele precisa ser revisto para remover redundâncias, retirar funcionalidades
desnecessárias e modificar arquitetura obsoletas. O re-trabalho do código ao
longo de todo o ciclo de vida reduz o tempo total de entrega do código e
aumenta a qualidade do software produzido.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 40
41. Engenharia de Software Ágil (SCRUM, FDD e XP) Engenharia de Software Ágil: XP em Detalhes
Detalhes da Iteração
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 41
42. Engenharia de Software Ágil (SCRUM, FDD e XP) Engenharia de Software Ágil: XP em Detalhes
Detalhes da Desenvolvimento
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 42
43. Engenharia de Software Ágil (SCRUM, FDD e XP) Engenharia de Software Ágil: XP em Detalhes
Código: Propriedade Coletiva
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 43
44. Engenharia de Software Ágil: XP
Planejamento e Feedback:
Engenharia de Software Ágil (SCRUM, FDD e XP)
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 44
45. Engenharia de Software Ágil: XP
RESUMO - Regras e Práticas:
Planejando:
Estórias do usuário
Planejando liberações (releases) e pequenas liberações
Dividir projetos em iterações (ciclos)
Medindo velocidade do projeto
Engenharia de Software Ágil (SCRUM, FDD e XP)
Reuniões diárias em pé
Projetando (designing):
Simplicidade (não adicione funcionalidades antes do tempo)
Metáfora
Cartões CRC (Classes, Responsabilidades e Colaboração)
Refactoring (refactor)
Codificando:
O cliente deve estar sempre disponível.
Programação em pares.
Codificar de acordo com padrões acordados.
Codificar testes de unidade primeiro.
Integrar com freqüência.
O código é propriedade coletiva.
Testando:
Todo código deve ter os testes de unidade.
Cada unidade deve ser testada antes de liberada.
Quando um erro é encontrado, testes devem ser realizados.
Testes de aceitação devem ser freqüentes.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 45
46. Engenharia de Software Ágil ?
SCRUM
Engenharia de Software Ágil (SCRUM, FDD e XP)
FDD
Gestão de Projetos
Requisitos de Software
XP
Colocando tudo
junto... desenvolvimento
de Software
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 46
47. Engenharia de Software Ágil (SCRUM, FDD e XP) Colocando tudo junto: Scrum, FDD e XP
Antes de falarmos sobre a Trilogia (SCRUM, FDD e XP). Precisamos esclarecer
algumas coisas como:
XP dá conta de todo ciclo de desenvolvimento de software (isto quer dizer sem a
necessidade do Scrum e FDD). Contudo, para isto seja uma verdade a equipe tem que ter
alta maturidade e experiências nas práticas XP.
Você poderia questionar, por que precisamos utilizar os três, a trilogia.
A resposta é simples: Ao usar dos três métodos ágeis, estaríamos utilizando o que cada
um tem de melhor, assim podemos criar um robusto ciclo de desenvolvimento de software
baseado nas práticas dos métodos ágeis.
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 47
48. Engenharia de Software Ágil (SCRUM, FDD e XP) Gerenciamento (SCRUM) e Engenharia de Software (FDD e XP)
SCRUM
XP FDD
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 48
49. Equipe: XP vs SCRUM
Cliente /
Product Onwer
Engenharia de Software Ágil (SCRUM, FDD e XP)
Desenvolvedores /
Equipe1,2
Manager /
SCRUM Master
1 - (Desenvolvedores) / Equipe: São desenvolvedores, DBAs, Arquitetos, Analista de
Testes, Web Designer e todas as pessoas necessárias para desenvolvimento do software.
2 - Team Empowerment Equipe empoderada / Equipe Comprometida (“pigs”).
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 49
50. Juntando o SCRUM, FDD e XP: “A Engenharia de Software Ágil”
FDD Práticas XP:
Codificação Testes
Refactoring
Engenharia de Software Ágil (SCRUM, FDD e XP)
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 50
51. Exemplos da “A Engenharia de Software Ágil”:
1 Utilizando o FDD para criar o “Product Backlog”
Engenharia de Software Ágil (SCRUM, FDD e XP)
2 XP: Refactoring
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 51
52. FDD - FBS: Feature Breakdown Structure:
1
Engenharia de Software Ágil (SCRUM, FDD e XP)
FBS (Feature BreakDown Structure) é uma prática para engenharia de requisito de software.
FBS cria uma “estrutura analista de funcionalidades”, como estamos trabalhando com FDD, cada feature
deve representar um item do Product Backlog
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 52
53. FDD - O Que é Feature ? (Pela visão da FDD)
1
Funcionalidade (ou característica):
Pequena o suficiente para ser implementada no máximo em 01 iteração
Oferece valor para o cliente
Mapeia passos em uma atividade de negócio:
– Pode ser um passo de um Caso de Uso (ou user stories)
Engenharia de Software Ágil (SCRUM, FDD e XP)
– Às vezes pode ser o próprio Caso de Uso (ou user stories)
Conceito muito próximo ao de um requisito funcional
Modelo: < ação> <resultado> <objeto >
- Liberar apartamento para locação
- Calcular o total de uma nota fiscal
- Autorizar uma transação com cartão
- Emitir uma nota fiscal
- Calcular total da conta do cliente
- Imprimir o relatório para conferência
Fonte: Adail Muniz Retamal - www.heptagon.com
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 53
54. FDD - Gerenciado ROI com Business Value
1
Business Value será uma moeda de troca durante o projeto e o cliente
empresta um determinado valor dessa moeda para a equipe e esta por sua vez, terá
que devolver o valor correspondente em forma de software, ou seja, é uma dívida
que a equipe assume com o cliente e que deverá ser amortizada a cada ciclo(Sprint),
até que a mesma seja totalmente liquidada (zerada).
Engenharia de Software Ágil (SCRUM, FDD e XP)
Exemplo de “Product BackLog” baseado no FDD:
Business Área de Item
Value Negócio
100 Reserva Os clientes poderão fazer reserva de apartamento
50 Reserva Os clientes poderão cancelar a reserva
50 Reserva Os clientes poderão fazer alterações de data da reserva
40 Reserva Os cliente poderão fazer consulta de reservas
100 Reserva Criação de o Book de Reserva
80 Pagamento O meio de pagamento da reserva serão por cartão de
crédito
60 Apartamento Os apartamentos deverão ser cadastros
40 Apartamento Os apartamentos são classificados por categoria
60 Cliente Precisamos registrar os dados dos clientes
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 54
55. As práticas XP (ou Regras):
2
Engenharia de Software Ágil (SCRUM, FDD e XP)
Utilizaremos estas
práticas (regras) do
XP para o
desenvolvimento
de software.
Opcionalmente
também podemos
considerar Refactor
(Designing)
http://www.extremeprogramming.org/rules.html
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 55
56. As práticas XP (ou Regras)1:
2
Codificação:
- Cliente sempre disponível;
- Código devem ser escritos de acordo com padrões (Padronização do código);
- Primeiro teste (unitário) o código;
-Toda produção de código é feito através da programação pareada (em duplas);
- Apenas um par faz integração código por vez;
- A integração é frequente (Integração Contínua);
Engenharia de Software Ágil (SCRUM, FDD e XP)
- Computador configurado e dedicado para integração (Integração Contínua);
- O código é de propriedade coletiva.
Testes:
- Todos códigos devem ter testes unitários;
- Todos códigos devem passar todos os testes unitários antes de serem liberados;
- Quando um "bug" é encontrado testes são criados;
- Testes Aceitação são frequentes e seus resultados ("scores") são publicados.
Desingning:
- Refatorar quando e sempre que possível.
1- Tradução livre
Versão 6 Rildo Santos | @rildosan | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 56