Beruflich Dokumente
Kultur Dokumente
de Software
“100%” Ágil
SCRUM, FDD e XP
Rildo F Santos
rildo.santos@etecnologia.com.br
rildo.santos@companyweb.com.br
twitter: @rildosan
blog: http://rildosan.blogspot.com/
VersãoVersão
4 6 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
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.
Engenharia de Software Ágil (SCRUM, FDD e XP)
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
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;
Onde estou:
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/
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.
SCRUM FDD
Gestão de Projetos
Requisitos de Software
E a codificação e
os testes
do software ?
Práticas de
Engenharia de
Software
Ágeis ?
SCRUM FDD
Gestão de Projetos
Requisitos de Software
Agora sim...
100% Ágil
XP
desenvolvimento
de Software
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 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 9
Engenharia de Software Ágil (SCRUM, FDD e XP) O coração do SCRUM
Legenda:
Retrospectiva
Revisão da Sprint
Cerimônias Planejamento
da Sprint
da Sprint
artefatos Reunião
diária
24 horas
Visão do
Produto
Tarefas
da Sprint
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
e a equipe SCRUM.
Product Owner, responsável por:
- Definir a Visão do Produto
- Elaborar e manter o Product
Backlog
- 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 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 12
Engenharia de Software Ágil (SCRUM, FDD e XP) A Equipe e Comprometimento:
Envolvidos Comprometidos
SCRUM Master
Equipe
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.
Cebola do Planejamento
Product Owner
Se você já conhece
o FDD, pule esta
parte
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.
Apresentação
(Visões e Controladores de Interface)
Negócio
(Domínio do Problema)
Interface com
Persistência
outros sistemas
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.
XP
desenvolvimento
de Software
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.
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
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.
Integração Contínua (Continuous Integration): Sempre que produzir uma nova funcionalidade,
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.
http://www.extremeprogramming.org/rules.html
Versão 6 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 34
Engenharia de Software Ágil (SCRUM, FDD e XP) 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:
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.
- Experiências concretas:
Antes de tomar decisões deve-se experimentar algumas alternativas.
- Responsabilidade aceita:
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.
Custo
escopo
Prazo Qualidade
Versão 6 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 38
Engenharia de Software Ágil (SCRUM, FDD e XP) 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.
Detalhes da Iteração
Detalhes da Desenvolvimento
Planejando:
Estórias do usuário
Planejando liberações (releases) e pequenas liberações
Dividir projetos em iterações (ciclos)
Medindo velocidade do projeto
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.
SCRUM FDD
Gestão de Projetos
Requisitos de Software
XP
Colocando tudo
junto... desenvolvimento
de Software
SCRUM
XP FDD
Cliente /
Product Onwer
Desenvolvedores /
Equipe1,2
Manager /
SCRUM Master
Refactoring
2 XP: Refactoring
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
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 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 55
As práticas XP (ou Regras)1:
2
Codificação:
Engenharia de Software Ágil (SCRUM, FDD e XP)
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
Propriedade Coletiva:
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.
Integração Contínua:
Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à
versão atual do sistema.
Testes:
Podem ser de diversos tipos, tais como: de aceitação; que são criados pelos clientes junto com
analistas, para determinar a aceitação da funcionalidade do sistema; TDD; Testes de Integração e
outros;
Refatoração: (Designing)
É 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 do
código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de
código fonte.
Padronização do código:
A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir
estas regras. A código fonte final deve parecer ter sido feito por apenas um programador.
Uma classe com acoplamento alto (forte) depende de muitas outras classes. Tais
classes são indesejáveis; elas sofrem dos seguinte problemas:
- Mudança em classes relacionadas forçam mudanças locais;
- Mais difícil de compreender isoladamente;
- Mais difícil de reusar porque o seu uso requer a presença adicional das classes
que ela depende.
O problema: A classe “Cliente” realiza a “interface” iPessoa (isto quer dizes que todos os
métodos assinados na interface deve ser implementado na classe) Uma vez
que se declare uma nova assinatura de método na interface iPessoa será
necessário implementar este novo método na classe Cliente.
Cliente
A solução: Criação de nova classe “PessoaAdapter” (Design Patterns: Adapter) esta classe
se relacionará com a interface iPessoa, desta forma todas as modificações ou
novos implementações serão feitas nesta classe.
Desta forma reduziremos o acoplamento entre a interface e a classe Cliente
<<interface>>
iPessoa
Relacionamento de Realização
PessoaAdapter Benefícios:
• Mudança na interface não afeta a classe cliente
• Facilita o reúso.
Cliente
Não temos como afirmar que a combinação destes métodos podem ser utilizados para
todos projetos de software e que esses projetos terão sucesso.
Cada equipe deve avaliar a possibilidade de utilizar a Engenharia de Software Ágil, de
acordo com suas necessidades e experiência.
Entre em contato:
- eventos@companyweb.com.br
- rildo.santos@companyweb.com.br
- rildo.santos@etecnologia.com.br
XP:
http://www.extremeprogramming.org
SCRUM:
SCRUM Product Owner
http://www.slideshare.net/Ridlo/scrum-product-owner
SCRUM Experience
http://www.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum
O uso desta técnica aprimora a concepção (design) de um software e evita a deterioração tão
comum durante o ciclo de vida de um código. Esta deterioração é geralmente causada por
mudanças com objetivos de curto prazo ou por alterações realizadas sem a clara compreensão da
concepção do sistema.
Fonte: http://pt.wikipedia.org/wiki/Refatora%C3%A7%C3%A3o
http://etecnologia.ning.com/
Versão 6 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 64
Engenharia de Software Ágil (SCRUM, FDD e XP) Notas:
Marcas Registradas:
Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial são de
responsabilidade de seus proprietários. O autor informa não estar associada a nenhum produto e/ou
fornecedor apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes
podem ter sido utilizados, e desde já o autor informa que o uso é apenas ilustrativo e/ou educativo, não
visando ao lucro, favorecimento ou desmerecimento do produto/fabricante.
Melhoria e Revisão:
Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema
ou erro envie um e-mail nós.
Criticas e Sugestões:
Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor
envie um e-mail para nós.
Imagens:
Google, Flickr e Banco de Imagem.
de Software
“100%” Ágil
SCRUM, FDD e XP
Rildo F Santos
rildo.santos@etecnologia.com.br
rildo.santos@companyweb.com.br
twitter: @rildosan
blog: http://rildosan.blogspot.com/
VersãoVersão
4 6 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010