Esta apresentação faz uma demonstração de como combinar os métodos ágeis: SCRUM, FDD e XP para tornar o Ciclo de Desenvo...
Engenharia de Software “100%” Ágil
) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
SCRUM, FDD e XP
Rildo F Santos
[email protected] [email protected] r twitter: @rildosan blog: http://rildosan.blogspot.com/
) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
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 de Software pela Universidade Mackenzie. Fui instrutor de Tecnologia de Orientação a Objetos, Obj etos, 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, 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, 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 Certified SCRUM Master, CSPO CSPO - Certified Certified SCRUM Product Owner Owner , SUN Java Certified Certified Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games; Sou membro do IIBA-International IIBA-International Institute of Business Analysis Analysis (Canada) (Canada ) Onde estou: Twitter: http://twitter.com/rildosan Blog: http://rildosan.blogspot.com/
Comentário inicial:
) P X e D D F , M U R C S ( l i Para desenvolver um software (ou produto), os métodos ágeis são altamente g recomendáveis e já descobrimentos que podemos usar diversos métodos juntos. Á e r a O Scrum pode ser utilizado para a Gestão de Projetos. Contudo, ele não faz abordagem w sobre a engenharia de software. t f o S O FDD pode ser utilizado para Engenharia de Software: Requisitos de Software e também e para arquitetura. d a i r Mas, será que faltou algo ? a SIM, FALTOU! Você ainda não é 100% Ágil... h n e 1 g > E a codificação, testes, patterns, refactoring ...O quê podemos usar ? n Nesta apresentação vamos responder como usar “XP”, que é método ágil, para o E desenvolvimento de software (codificação, testes e refactoring).
Engenharia de Software Ágil, ainda falta algo...
Engenharia de Software Ágil ? ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
SCRUM
FDD
Gestão de Projetos Requisitos de Software
E a codificação e os testes do software ?
Não somos 100% Ágeis
Engenharia de Software Ágil ? ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Ciclo de Desenvolvimento de Software na Visão Ágil
Práticas de Engenharia de Software Ágeis ?
Engenharia de Software Ágil ? ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
SCRUM
FDD
Gestão de Projetos Requisitos de Software
Agora sim... 100% Ágil
XP desenvolvimento de Software
Engenharia de Software Ágil: Qual o papel de cada um ? ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r Engenharia de Software “100% “Ágil: a h n O SCRUM é utilizado para a Gestão de Projetos. Já para as práticas de e g Enegnharia de Software utilizamos o FDD (requisitos de software e n arquitetura) e as Prát Prátic icas as XP para desenvolvimento de software E
(codificação, testes e refactoring).
Sobre SCRUM: ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Se você já conhece o SCRUM, pule esta parte
O que é o SCRUM ? ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
The New, New Product Development Game
TimeBoxes
SmallTalk Engineering Tools
Iterative, Incremental Development
O que é SCRUM ? SCRUM é um processo iterativo e incremental para desenvolvimento de qualquer produto ou gerenciamento de qualquer trabalho... SRUM é: Processo Proce sso empírico empírico de gerenciamento gerenciamento e controle. - Faz a inspeção inspeção e adaptação adaptação em em loops de feedback - Faz entrega de valor valor ao cliente em até 30 dias; - “Escalável” para suportar grandes projetos - Compa Compatív tível el com CMM3 e ISO9001 ISO9001 - Extre Extremament mamentee simples, simples, mas muito resistente... Valores do Scrum: Valores Scrum::: - Tr Transpa ansparênci rênciaa -Integridade: assim que perceber algo, faça algo - Ser empírico - Aut Auto-org o-organiza anização ção - Entre Entrega ga de val valor or
O coração do SCRUM ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Legenda:
Revisão da Sprint
Planejamento da Sprint
Cerimônias
Retrospectiva da Sprint
Reunião diária
artefatos
24 horas Visão
Produto Backlog
Sprint Backlog 2-4 Semanas
Papéis • Product Owner (PO) • ScrumMaster (SM) • Equipe Scrum
Cerimônias
Produto
Artefatos
• Planejamento da Sprint • Product Backlog • Reunião Diária • Sprint Backlog • Revisão da Sprint • Burndown (gráfico) Retrospectiva da Sprint • Retrospectiva
Burndown
ROAD MAP do SCRUM ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Visão do Produto
Planejamento da Sprint
Product Backlog
Selected Selected Product Product Backlog
Sprint Backlog Tarefas da Sprint
Reunião diária
Product Onwer facilita ajuda
Equipe
SCRUM Master facilita facilita
Execução da Sprint
Revisão da Sprint Produto Retrospectiva da Sprint
Papéis ) O SCRUM tem somente três papéis: Product Onwer (PO), SCRUM Master (SM) P X e a equipe SCRUM. e Product Owner, responsável responsável por: D - Definir a Vis Visão ão do Produto Produto D F - Elabor Elaborar ar e manter o Produc Productt , Backlog M - Definir a prioridade e ROI; U R - Repres Representar entar o cliente cliente C - Aceitar ou rejeitar os entregáveis S ( l i SCRUM Master é responsável por: g - Ser um líder líder (servidor); (servidor); Á - Remover Remover impedim impedimentos entos;; e r - Proteger a equipe; a w - Aj Ajuda udarr o PO (com Product Backlog); t f - Ser o facili facilitador tador da equipe; equipe; o S - Garantir as práticas SCRUM. e d Equipe SCRUM é responsável por: a i - Fazer estimativ estimativa; a; r a - Definir Definir as tarefas tarefas;; h Desenvolver o produto; produt o; - Desenvolver n e - Garantir a qualidade do produto; g - Apresen Apresentar tar o produto ao cliente cliente n E Equipe: auto-gerenciável e multifuncional
A Equipe e Comprometimento: ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Envolvidos
Comprometidos
Stakeholders (clientes e usuários finais)
Product Onwer
Equipe
SCRUM Master
TimeBox e Sprint ) O que é Timebox ? P É um conceito diz que a quantidade de tempo (horas ou dias) é imutável, ou seja, X aumentar. Assim, evita-se atraso no prazo de e a quantidade de horas não poderá aumentar. entrega e facilita o planejamento. D D quanto se erra a estimativa de tempo (leia-se: horas ou dias) de uma F Entretanto, quanto , Sprint (leia-se: iteração), neste caso é recomendável reduzir o escopo da Sprint, Mdesde que não afete a meta da Sprint (isto é discutido um mais a frente) ao invés U de aumentar a quantidade de horas/dias. R C S Timebox = Um prazo ou tempo (dias/horas por exemplo) bem definido e ( imutável. l i g Á O que é uma Sprint ? e É uma iteração (que pode ser parte de uma release) que deve ser realizada de 2 a r a 4 semanas, no qual a equipe do projeto deverá produzir um entregável de valor wpara o cliente (lembre-se do dos Princípios do Manifesto Ágil). t f o A entrega entrega de valor é a meta da Sprint que deverá esta bem definida e combinada S com o cliente, antes do começo da execução da Sprint. e d conceito de Timebox é aplicado a Sprint. Sprint. a O conceito i r O conceito de timebox é aplicado as cerimônias cerimônias (reuniões) do Scrum. Todas Todas as reuniões são a h Timeboxed: n - Reunião de Planejamento Planejamento da Sprint (8 horas) horas) e - Reunião Diária (15 minutos) minutos) g Reunião Diária Revisão da Sprint (4 horas*) n - Reunião de Revisão Retrospectiva da Sprint (3 horas*) E - Reunião de Retrospectiva Nota: * A quantidade de horas pode variar de acordo com a necessidade (por exemplo, apresenta ção do que será entregue ao
Desenvolvimento Iterativo e Incremental:
) P X Incremental e D D F , M U R C S ( l i Iterativo g Á e r a w t f o S e d a i r a h n e g n E
Entrega 1
Entrega 2
Entrega 3 Devido a complexidade, tamanho, mudanças de requisitos, urgência e necessidade de demonstrar valor mais rápido, fica quase inconcebível desenvolver software utilizado o modelo cascata, ou seja desenvolver todo o software de uma única vez. 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.
Planejamento no SCRUM, O Planehamento Ágil :
) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Cebola do Planejamento
Product Backlog:
) P O que é Product Backlog ? X É uma lista contendo todas as funcionalidades desejadas para um produto. e O produto deve ter somente um Product Backlog (PB) independente número de equipes D que está trabalhando no projeto. D F PB poderá ser criado de diversas maneiras: , - Com Estórias de Usuário, Com Casos de Uso ou Com “Features” “Features” (funcionalidades de M produto). U R Exemplo de Product Backlog: Sistema de Reserva On-Line On-Lin e C S ( l i g Á e r a w Product Owner t f o Product Owner (PO), é responsável por S elaborar e manter Product Backlog e atualizado, bem como priorizar seus itens. d a i r a h n e g n E
Cerimônias: ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Reunião de Planejamento da Sprint (8 horas) Participantes: PO, Equipe e SCRUM MASTER M ASTER 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 necessárias para cumprir a meta).
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 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 eu fiz ontem ontem ? - O que vou vou fazer fazer hoje ? - Encontrei Encontrei algum impedim impedimento ento ?
Revisão da Sprint (4 horas*) Participantes: PO, Equipe e SCRUM MASTER M ASTER 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 du rante a Sprint e fazer a entrega do produto (software (softw are funcionando) para o PO. (Normalmente é apresentado uma demo do software). Geralmente ela é feita feita em um auditório ou em uma sala de reunião
Retrospectiva 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.
Engenharia de Software Ágil ? ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Se você já conhece o FDD, pule esta parte
O que é o FDD (Feature Driven Development) Development) ? ) P Feature Driven Development (Desenvolvimento X Guiado por Funcionalidades) é uma metodologia ágil e para gerenciamento e desenvolvimento de software. soft ware. D D F Ela combina as melhores práticas do gerenciamento , Mágil de projetos com uma abordagem completa para U Engenharia de Software orientada por objetos, R C conquistando os três principais públicos de um S ( projeto de software: l i - Cl ient ntes es,, g Clie Á - Gere Gerent ntes es,, e -Desenvolvedores. r a w t f Seus princípios e práticas proporcionam um o S equilíbrio entre as filosofias tradicionais e as mais e extremas, proporcionando uma transição mais suave d a para organizações mais conservadoras, e a i r retomada da responsabilidade para as organizações a h que se desiludiram com as propostas mais radicais. n e g n O lema da FDD é: "Resultados freqüentes, E tangíveis e funcionais."
O FDD foi criada em 1997 1997 num grande projeto em Java para o United Overseas Bank, em Singapura. Nasceu a partir da experiência de análise e modelagem orientadas por objetos de Peter Coad, e de gerenciamento de projetos de Jeff De Luca. Luca. Foi inicialmente publicada em 1999, no capítulo 6 do livro "Java Modeling in Color with UML", de Peter Coad, Eric Lefebvre e Jeff De Luca. Em 2002, Stephen Palmer (gerente de desenvolvimento do projeto em Singapura) e John Mac Felsing (arquiteto senior na TogetherSoft) publicaram o livro "A Practical Guide to Feature Driven Development", com a versão completa, atualizada e comentada da metodologia. Em 2003, David Anderson, que foi o especialista em interface com o usuário, no projeto de Cingapura, publicou um marco na literatura Ágil, "Agile "Agile Management for Software Engineering: Using the Theory of Constraints for Business Results", onde oferece uma análise profunda sobre a FDD (entre outras metodologias), além de material inédito sobre a FDD.
FDD (Feature Driven Development) ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
O que é o FDD (Feature Driven Development) Development) ? ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
A FDD é uma metodologia muito objetiva. Possui apenas duas fases: - Concepção Concepção & Planejamento: Planejamento: Pensar um pouco antes de fazer fazer (tipicamente de 1 a 2 semanas) - Construção: Construção: Fazer de forma iterativa iterativa (tipicamente em iterações iterações de 2 semanas) semanas) Os cinco processos são bem definidos e integrados: 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 características peculiares: - Resultado Resultadoss úteis úteis a cada cada duas duas semanas semanas ou ou menos menos - Blocos bem bem pequenos pequenos de funcionalidade funcionalidade valorizada pelo cliente, chamados "Features" "Features" - Planejam Planejamento ento detalh detalhado ado e guia guia para para medição medição - Rastre Rastreab abilid ilidad adee e relató relatório rioss - Monitoramento Monitoramento detalhado dentro dentro do projeto, projeto, com resumos de alto nível nível para clientes e gerentes, tudo em termos de negócio - Fornece uma uma forma de saber, saber, dentro dos primeiros primeiros 10% de um projeto, projeto, se o plano e a estimativa são sólidos
Os Processos ) A FDD é, classicamente, descrita por cinco processos: P X Desenvolver um Modelo Abrang Abrangente: ente: pode envolver desenvolvimento de requisitos, e DMA - Desenvolver D análise orientada por objetos, modelagem lógica de dados e outras técnicas para entendimento do D domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível, F que guiará a equipe durante os ciclos de construção. , M Construir uma Lista de Funcionalidad Funcionalidades: es: decomposição funcional funcional do modelo do domínio, U CLF - Construir R em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados da C atividade (funcionalidades). O resultado é uma hierarquia de funcionalidades que representa o S ( produto a ser construído (também chamado de product backlog , ou lista de espera do produto). l i g por Funcionalidade Funcionalidade:: abrange a estimativa de complexidade e dependência das Á PPF - Planejar por e funcionalidades, também levando em consideração a prioridade e valor para o negócio/cliente. O r a resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada w para a construção. t f o já dentro de uma iteração de construção, a equipe detalha os por Funcionalidad Funcionalidade: e: já S DPF - Detalhar por e requisitos e outros artefatos para a codificação de cada funcionalidade, incluindo os testes. O d projeto para as funcionalidades é inspecionado. O resultado é o modelo de domínio mais a i r detalhado e os esqueletos de código prontos para serem preenchidos. a h CPF - Construir Construir por Funcionali Funcionalidade: dade: cada esqueleto de código é preenchido, testado e n e inspecionado. O resultado é um incremento do produto integrado ao repositório principal de código, g com qualidade e potencial para ser usado pelo cliente/usuário. n E
Visão da Arquitetura: ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Apresentação (Visões (Visões e Controlad Controladores ores de Interface) Interface)
Negócio (Domínio do Problema)
Persistência
Inte Interf rfac acee com com outros sistemas
Sobre UML Color ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
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 novo e de novo - apenas um nome nome diferente para se adequar adequar ao domínio. Estes eram chamados chamados de arquétipos 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 representam um momento ou intervalo de tempo? tempo? Um exemplo seria um objeto que armazena temporariamente as informações de login durante o processo de Autenticação. Amarelo Amarelo - papéis papéis - É uma maneira de participar participar de uma atividade (por qualquer qualquer pessoa, lugar ou coisa) ? Assinatura em um sistema como um administrador, administrador, que muda m uda o comportamento do programa, exigindo uma senha que contas de convidado não, é um exemplo. simplesmente uma descrição descrição do catálogocatálogo- como a que classifica ou objeto 'rótulos„ Um ? Azul - Descriç Descrição ão - É simplesmente 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. unicamente identificável. identificável. Normalmente, se você passar a Verde - parte, lugar ou coisa - algo tangível, unicamente três perguntas 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.
Exemplo: UML em cores: ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
As disciplinas envolvidas: ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Gestão Ágil de Projetos
Fonte: Adail Adail Muniz Retamal - www.heptagon.c www.heptagon.com om
Engenharia de Software Ágil: XP ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
XP desenvolvimento de Software
Engenharia de Software Ágil: XP ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
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.
Engenharia de Software Ágil: XP (Extreme Programming) ) Programação eXtrema: Desenvolvendo Software Software com Qualidade e Agilidade P - Programação X e O XP é uma técnica revolucionária de desenvolvimento de software que se opõe a uma D série de premissas adotadas pelos métodos tradicionais de engenharia de software. XP D consiste numa série de práticas e regras que permitem aos programadores desenvolver F software de alta qualidade de uma forma dinâmica e ágil. , M U R C S ( l i g A metodologia metodologia se baseia nas seguintes práticas (2000): Á e r a Programação Pareada w Jogo do Planejamento t f Propriedade Coletiva Coletiva do Código o Versões Pequenas S Integração Contínua e Freqüente e Metáfora d Ritmo Sustentável a Projeto Simples i r Desenvolvimento a Desenvolvimento Orientado por Testes Cliente com os desenvolvedores h Padrão de Código n Testes dos Clientes e g Refatoração n E
Engenharia de Software Ágil: XP ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Comentários sobre algumas práticas: Jogo de Planejamento (Planning (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 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 (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 (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 program ador experiente em controlar comunicação em sistemas em tempo real, como com o controle de tráfego aéreo. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto. Projeto Simples (Simple ( Simple Design ): ): Simplicidade é um princípio da XP 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. XP. Código fácil deve ser identificado e substituído por código simples.
Engenharia de Software Ágil: XP ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Comentários sobre algumas práticas: Testes de Aceitação (Customer (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 (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 (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 (Pair Programming ): ): é a programação em par/dupla num único computador computado r. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. instrutor. Como é apenas um com computador putador,, 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 busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado. Padrões de Codificação (Coding (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. mem bros.
Engenharia de Software Ágil: XP ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Comentários sobre algumas práticas: Refatoração (Refactoring (Refactoring ): ): É um processo que permite perm ite a melhoria continua da programação, com o mínimo de introdução de erros e mantendo m antendo 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 (Continuous Integration ): ): Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta aum enta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma form a contínua permite saber o status real da programação.
Engenharia Engenhar ia de Software Ágil: As NOVAS NOVAS práticas prática s XP (ou Regras) ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E http://www.extremeprogramming.org/r http://www.extremeprogr amming.org/rules.html ules.html
Engenharia de Software Ágil: XP ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Os princípios fundamentais são: - Feedback Feedback rápido: rápido: Quanto mais demorado o feedback menor m enor o aprendizado produzido por ele. - Simplic Simplicidade idade assumida: assumida: Desenvolver a solução mais simples que possa funcionar. Não construir complexidade desnecessária - Mudança Mudança increme incremental: ntal: 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 Aceitar mudanças mudanças:: A mudança é inevitável. inevitável. Ao invés de combater a mudança, aceitá-la como normal e saudável para o projeto. - Trabal Trabalho ho de qualidade: qualidade: Todos gostam de fazer um trabalho de qualidade; se as pessoas que estão no projeto não gostam da qualidade do do trabalho que estão fazendo, a tendência do projeto é fracassar. fracassar.
Engenharia de Software Ágil: XP ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Além destes princípios fundamentais, existem outros que também são importantes:
- Ensinar Ensinar a aprender: aprender: Melhor do que um monte m onte 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. - Pequeno Pequeno investime investimento nto inicial inicial:: Muito dinheiro logo no início do projeto não faz bem; 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 Jogar para para ganhar: 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ênci Experiências as concretas: concretas: Antes de tomar decisões deve-se experimentar algumas alternativas. - Comunicação Comunicação honesta honesta e aberta: Falta de comunicação dentro da equipe prejudica o ambiente de trabalho e o projeto como um todo.
Engenharia de Software Ágil: XP ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Além destes princípios fundamentais, existem outros que também são importantes:
- Traba raballhar har de acor acordo do com o insti stinto nto das das pess pessoa oas, s, e não não cont ontra ele: Pessoas gostam de fazer um bom trabalho, como elas gostam de comunicar-se e Ente Entend nder er essa essass cara caract cter erís ístitica cass nat naturai uraiss irá irá cria criarr um time time feli felizz e de suce sucess sso. o.
de aprender.
- Respon Responsab sabil ilida idade de aceit aceita: a: Pessoas que tomam tarefas para si irão fazer um trabalho melhor que aquelas que têm tarefas desi design gnad adas as a elas elas.. A resp respon onsa sabi bililida dade de não não deve deve ser ser impo impost staa às pess pessoa oas, s, mas mas acei aceitta por por elas elas.. - Adaptação Adaptação local local:: Os costumes e práticas de desenvolvimento locais devem ser respeitados ao máximo quando da implantação impla ntação da XP XP.. - Viag Viagem em lev leve: Não carregue documentação que não seja essencial para o projeto; projeto ; jogue fora tudo aquilo que não precisa mais. O código é a documentação mais atualizada. - Mediç Medição ão hone honest sta: a: Medir sempre o desenvolvimento, mas nunca numa maneira que não seja suportada pelos inst instru rumen mento toss disp dispon onív ívei eis, s, ou pela pela simpl simples es nece necess ssid idad adee de have haverr mens mensur uraç ação ão..
Engenharia de Software Ágil: XP ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), 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.
Custo
escopo Prazo
Qualidade
Engenharia de Software Ágil: XP ) Práticas de programação: P X O processo de programação tem como características a programação em pares e e a propriedade coletiva do código. D D F Na programação em pares (em dupla), dois programadores ocupam um único , computador. computador. Embora, a princípio, isto possa ser visto como um desperdício de M esforços, várias vantagens podem ser obtidas. Esta estratégia aumenta a U R qualidade do código e não altera o tempo de entrega, uma vez que haverá um C ganho posterior nas etapas de retirada de erros (defeitos). Os dois S programadores atuam de forma colaborativa. Enquanto o que está com o ( (sintaxe, variáveis, l i teclado e mouse está pensando diretamente na codificação (sintaxe, g 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 e uma visão mais crítica corrigindo erros dos companheiros e pode pensar nas r a futuras mudanças e etapas posteriores. Isto permite que a tradicionalmente w prática do codifica-e-conserta, criticada nas origens do desenvolvimento de t f software, possa ser realiza sem perda da qualidade do software. o S e A propriedade coletiva do código é outra característica fundamental do d método XP, XP, com a rotatividade do código entre os programadores e reuniões a freqüentes para estabilizar o código. A propriedade coletiva encoraja o time i r todo a contribuir com novas idéias. Qualquer membro do time pode adicionar a h funcionalidade, corrigir erros ou re-fabricar o código. Não existe a figura do n arquiteto chefe. Todos Todos são responsáveis pelo código inteiro. Não existe alguém e m udanças. Reuniões freqüentes devem ser definidas como g para aprovar as mudanças. n parte do processo iterativo de programação. Estas reuniões devem ser curtas e E são realizadas com todos de pé (stand up meeting).
Engenharia de Software Ágil: XP ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
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 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.
Engenharia de Software Ágil: XP em Detalhes ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Detalhes da Iteração
Engenharia de Software Ágil: XP em Detalhes ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Detalhes da Desenvolvimento Desenvolvimento
Engenharia de Software Ágil: XP em Detalhes ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Código: Propriedade Coletiva
Engenharia de Software Ágil: XP ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Planejamento e Feedback:
Engenharia de Software Ágil: XP ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
RESUMO - Regras e Práticas 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 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.
Engenharia de Software Ágil ? ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
SCRUM
FDD
Gestão de Projetos Requisitos de Software
XP Colocando tudo junto...
desenvolvimento de Software
Colocando tudo junto: Scrum, FDD e XP ) P X e D D F , M U R C S ( l i g Á e r a w t f Antes de falarmos sobre a Trilogia Trilogia (SCRUM, (SCRU M, FDD e XP). Precisamos esclarecer o S algumas coisas como: e XP dá conta de todo ciclo de desenvolvimento de software (isto quer dizer sem a d necessidade do Scrum e FDD). Contudo, para isto seja uma verdade a equipe tem que ter a i experiênci as nas práticas XP. XP. r alta maturidade e experiências a h n Você poderia questionar, por que precisamos utilizar os três, a trilogia. e g A resposta é simples: Ao usar dos três métodos ágeis, estaríamos utilizando o que cada n um tem de melhor, assim podemos criar um robusto ciclo de desenvolvimento desenvolviment o de software E
baseado nas práticas dos métodos ágeis.
Gerenciamento (SCRUM) e Engenharia de Software (FDD e XP) X P) ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
SCRUM
XP
FDD
Equipe: XP vs SCRUM vs SCRUM ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Cliente / Product Onwer
Desenvolvedores / Equipe 1,2
Manager / SCRUM Master
1 - (Desenvo (Desenvolv lvedore edores) s) / Equipe: 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”).
Juntando o SCRUM, FDD e XP: “A Engenharia de Software Ágil” ) P FDD X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Práticas XP: Codificação
Testes
Refactoring
Exemplos da “A Engenharia de Software Ágil”: ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
1
Utilizando o FDD para criar o “Product Backlog”
2
XP: Refactoring
FDD - FBS: Feature Feature Breakdown Breakdown Structure: Structure:
1
) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h FBS (Feature BreakDown Structure) é uma prática para engenharia de requisito de software. n e g FBS cria uma “estrutura analista de funcionalidades”, como estamos estamos trabalhando com FDD, cada f eature n deve representar um item do Product Backlog E
FDD - O Que é Feature Feature ? (Pela (Pela visão visão da FDD) ) característica): P Funcionalidade (ou característica): X Pequena o suficiente para ser implementada no máximo máxim o em 01 iteração e Oferece valor para o cliente D D F Mapeia passos em uma atividade de negócio: , – Pode ser um passo de um Caso de Uso (ou user stories) M – Às vezes pode ser o próprio Caso de Uso (ou user stories) U R C Conceito muito próximo ao de um requisito funcional S ( l i Modelo: < ação> ação> resultado> g Á - Liberar apartamento para locação Calcular o total total de uma nota fiscal fiscal e - Calcular r a - Autorizar uma transação transação com cartão w - Emitir uma nota fiscal fiscal t f Calcular total total da conta conta do cliente cliente o - Calcular S - Imprimir Imprimir o relatório relatório para conferênc conferência ia e d a i r a h n e g n E Fonte: Adail Adail Muniz Retamal - www.heptagon.com www.heptagon.com
1
FDD - Gerenciado Gerenciado ROI ROI com Business Business Value Value ) P Business Value será uma moeda de troca durante o projeto e o cliente X empresta um determinado valor dessa moeda para a equipe e esta por sua vez, terá e que devolver o valor correspondente em forma de software, ou seja, é uma dívida D que a equipe assume com o cliente e que deverá ser amortizada a cada ciclo(Sprint), D F até que a mesma seja totalmente liquidada (zerada). , M U Exemplo de “Product BackLog” baseado no FDD: R C Business Área de Item S Value Negócio ( l i 100 Reserva Os clientes poderão fazer reserva de apartamento g Á 50 Reserva Os clientes poderão cancelar a reserva e r 50 Reserva Os clientes poderão fazer alterações de data da reserva a w t 40 Reserva Os cliente poderão fazer consulta de reservas f o 100 Reserva Criação de o Book de Reserva S e d 80 Pagamento O meio de pagamento da da reserva serão por ca cartão de crédito a i r 60 Apartamento Os apartamentos deverão ser cadastros a h n 40 Apar Aparta tam mento ento Os apar aparta tam mento entoss são são clas classi sififica cado doss por por cate catego gori riaa e g 60 Cliente Precisamos registrar os dados dos clientes n E
1
As práticas XP (ou Regras): ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
2
Utilizaremos estas práticas (regras) do XP para o desenvolvimento de software. Opcionalmente também podemos considerar Refactor (Designing)
http://www.extremeprogramming.org/r http://www.extremeprogr amming.org/rules.html ules.html
As práticas XP (ou Regras) 1: ) Codificação: P Cliente sempre sempre disponív disponível; el; X - Cliente escritos de acordo com padrões padrões (Padronização (Padronização do código); e - Código devem ser escritos código; D - Primeiro teste (unitário) o código; D -Toda produção de código é feito através da programação pareada (em duplas); F integração código por vez; , - Apenas um par faz integração M - A integração é frequente frequente (Integração (Integração Contínua); U - Computador dedicado para integração integração (Integração (Integração Contínua); R Computador configurado e dedicado código é de propriedade propriedade coletiva. coletiva. C - O código S ( l i Testes: g - Todos códigos devem devem ter testes unitários; Á passar ar todos os testes unitários antes de serem liberados; e - Todos códigos devem pass r encontrado testes testes são criados; criados; a - Quando um "bug" é encontrado w - Testes Aceitação são frequentes e seus resultados ("scores") são publicados. t f o S Desingning: e - Refatorar quando quando e sempre que possível. d a i r a h n e g n E
2
Detalhando algumas práticas XP: ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
2
Programação Pareada: É a programação em par (dupla) num único computador. Reduz Reduz o numero de bugs e equilibra a equipe. Propriedade Coletiva: O código-fonte não tem dono e ninguém precisa solicitar 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 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 compatibilidade com o código já existente. existente. Refabricar melhora a clareza do código, divide-o divide-o em módulos mais coesos e de maior reaproveitamento, 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.
As práticas XP. Refactoring 1: ) Acoplamento (Low Coupling) P X e É uma medida da interdependência relativa relativa entre as classes. D Depende da complexidade de interface entre as classes. D Baixo acoplamento é o desejável, pois, ele favorece o Reúso. F , Como manter o baixo acoplamento ? M U R - Solução: Atribuir uma responsabili responsabilidade dade de forma que o acoplamento acoplamento permaneça C fraco S ( l i g Como suportar uma dependência baixa e aumentar o reúso? Á O acoplamento é uma medida de quão fortemente uma classe está ligada a uma ou e r mais classes, tem conhecimento das mesmas ou depende delas. a Uma classe com acoplamento baixo (fraco) não é dependente de muitas classes. w t f o Uma classe com acoplamento alto (forte) depende de muitas outras classes. Tais Tais S classes são indesejáveis; elas sofrem dos seguinte problemas: e - Mudança em classes classes relacionadas forçam mudanças locais; locais; d a - Mais difícil difícil de compreender isoladamente; isoladamente; i r - Mais difícil de reusar porque o seu uso requer a presença adicional adicional das classes a h que ela depende. n e g n E 1- Não apresentaremos apresentaremos código, somente os modelos UML
2
As práticas XP. Refactoring: ) P X O problema: e D D F , M U R C S ( l i g Á A solução: e r a w t f o S e d a i r a h n e g n E
2
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. iPessoa
Relacionamento de Realização
Cliente
Criação de nova classe “PessoaAdapter” (Design Patterns: Adapter) Adapter ) esta classe se relacionará com a interface iPessoa, desta forma todas as modificações m odificações ou novos implementações serão feitas nesta classe. Desta forma reduziremos o acoplamento entre a interface e a classe Cliente iPessoa Relacionamento de Realização
PessoaAdapter
Cliente
Benefícios: Mudança na interface não afeta a classe cliente • Facilita o reúso. •
Conclusão
) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d Não temos como afirmar que a combinação combinação destes métodos podem ser utilizados utilizados para a i todos projetos de software e que esses projetos terão sucesso. r a Cada equipe deve avaliar a possibilidade de utilizar a Engenharia de Software Ágil, de h n acordo com suas necessidades e experiência. e g n Mas devemos experimentar a combinação dos métodos ágeis com o objetivo de E usar as suas melhores práticas para gerar valor ao negócio (ao cliente).
Gostou ? ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Gostou...Que saber mais, conhecer mais os métodos ágeis, como SCRUM, FDD e XP: Participe do nosso treinamento: Formação de Engenharia de Software Ágil Entre em contato: - eventos@c eventos@company ompanyweb.co web.com.br m.br -
[email protected] - rildo.santo rildo.santos@ete s@etecnolog cnologia.co ia.com.br m.br
Formação Engenharia de Software Ágil As melhores práticas para o desenvolvimento de software softw are ágil Conteúdo Programático Gestão de Projeto de desenvolvimento de Software com SCRUM (16 horas) - Ciclo de Produto Produto (8 horas) horas) : •Papel do Product Onwer •Visão do Produto •Roadmap do Produto •Plano de Release do Produto •Product Backlog •*Workshop do Produto e Requisitos - Ciclo do Processo (8 horas) Papel do SCRUM Master Papel da Equipe SCRUM Reunião ão de Planejamento: •Estimativa •Definição DoD •Sprint Backlog •Reuniões Diárias •Impedimentos
- Engenharia de Software com as práticas práticas FDD+BDD e XP (8 horas) Ciclo do desenvolvimento da Sprint com práticas FDD, XP e BDD Revisão da Sprint (Revisão do produto da Sprint) Retrospectiva Retrospectiva (Revisão do processo processo - Lições aprendidas) Implementação da Fábrica Ágil (8 horas) Planejamento da implementação da Fábrica Ágil Fatores críticos de sucesso Ferramentas, pessoas e processos Capacitação da equipe
Carga horária: 32 horas Local: São Paulo
) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Referências e Créditos: FDD, Créditos: Adail Muniz Retamal - www.heptagon.com Manoel Pimentel Medeiros (Visão Ágil - http://www.visaoagil.com ) XP: http://www.extremeprogramming.org SCRUM: SCRUM Product Owner http://www.slideshare.net/Ridlo/scrum-product-owner
SCRUM Experience http://www.slideshar http://www.slideshare.net/Ridlo/ e.net/Ridlo/scrum-experie scrum-experience-o-tutorial-s nce-o-tutorial-scrum crum
Glossário e Referência (Refactoring):
) 1 Refactoring: P X Refatoração (do inglês Refactoring ) é o processo de modificar um sistema de software para e melhorar a estrutura interna do código sem alterar seu comportamento externo. D D O uso desta técnica aprimora a concepção ( design ) de um software e evita a deterioração tão F 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 M concepção do sistema. U R C Outra consequência é a melhora no entendimento do código, o que facilita a manutenção e evita a S ( inclusão de defeitos. Esta melhora no entendimento vem da constante alteração do código com l objetivo de facilitar a comunicação de motivações, intenções e objetivos por parte do programador. i g É fundamental que o sistema de software possua testes automatizados para realizar refatoração. Á Desta forma, será possível garantir a que o comportamento externo não foi alterado. e r a O livro mais importante im portante sobre refatoração é Refactoring: Improving w t the Design of Existing Code (ISBN Code (ISBN 0201485672) de Martin Fowler, Fowler, f onde são explicados os conceitos, motivações e uma série de o S refatorações descritas passo a passo. e d Veja Veja o livro no Google Books: http://bit.ly/cStfaU a i r a h n e g n E Fonte: http://pt.wikipedia.org/wiki/Refatora%C3%A7%C3%A3o http://pt.wikipedia.org/wiki/Refatora%C3%A7%C3%A3o
Quer Mais ? ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Gostou quer mais, gostaria de receber outros materiais sobre o mesmo tema e novas versões deste material... Envie um e- mail para com subject: “Quero entrar na comunidade” para
[email protected] que te enviaremos um convite para participar participar da nossa comunidade
http://etecnologia.ning.com/
) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Notas: Marcas Registrad Registradas: as: 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 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.
Rildo F dos Santos (
[email protected]. (
[email protected]) br)
Licença: ) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
Engenharia de Software “100%” Ágil
) P X e D D F , M U R C S ( l i g Á e r a w t f o S e d a i r a h n e g n E
SCRUM, FDD e XP
Rildo F Santos
[email protected] [email protected] r twitter: @rildosan blog: http://rildosan.blogspot.com/
