SlideShare uma empresa Scribd logo
1 de 67
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)

Mais conteúdo relacionado

Mais procurados

Modelagem de Processos com BPMN e Tibco Business Studio
Modelagem de Processos com BPMN e Tibco Business StudioModelagem de Processos com BPMN e Tibco Business Studio
Modelagem de Processos com BPMN e Tibco Business StudioRildo (@rildosan) Santos
 
Gerenciamento de tempo em projetos
Gerenciamento de tempo em projetosGerenciamento de tempo em projetos
Gerenciamento de tempo em projetosPaulo Junior
 
FDD vs XP vs SCRUM
FDD vs XP vs SCRUMFDD vs XP vs SCRUM
FDD vs XP vs SCRUMfredcobain
 
Inovação, Projetos e Portfólio: Integração para Resultados Promissores
Inovação, Projetos e Portfólio: Integração para Resultados PromissoresInovação, Projetos e Portfólio: Integração para Resultados Promissores
Inovação, Projetos e Portfólio: Integração para Resultados PromissoresJose Ignacio Jaeger Neto, PMP, MSc
 
Gerenciamento de projetos aula 4 (escopo)
Gerenciamento de projetos   aula 4 (escopo)Gerenciamento de projetos   aula 4 (escopo)
Gerenciamento de projetos aula 4 (escopo)Paulo Junior
 
Practical Enterprise Architecture in Medium-size Corporation using TOGAF
Practical Enterprise Architecture in Medium-size Corporation using TOGAFPractical Enterprise Architecture in Medium-size Corporation using TOGAF
Practical Enterprise Architecture in Medium-size Corporation using TOGAFMichael Sukachev
 
Gerenciamento de integração de projetos
Gerenciamento de integração de projetosGerenciamento de integração de projetos
Gerenciamento de integração de projetosJúnior Rodrigues
 
Gestão da qualidade metodologia ágil v01 (2)
Gestão da qualidade   metodologia ágil v01 (2)Gestão da qualidade   metodologia ágil v01 (2)
Gestão da qualidade metodologia ágil v01 (2)Sabrina Mariana
 
Gestão de Serviços de TI com a ITIL. Uma introdução
Gestão de Serviços de TI com a ITIL. Uma introduçãoGestão de Serviços de TI com a ITIL. Uma introdução
Gestão de Serviços de TI com a ITIL. Uma introduçãoRildo (@rildosan) Santos
 
Aula 1 - Gestão de Projetos
Aula 1 - Gestão de ProjetosAula 1 - Gestão de Projetos
Aula 1 - Gestão de ProjetosFernando Dantas
 
Engenharia de Software Ágil (Scrum e FDD)
Engenharia de Software Ágil (Scrum e FDD)Engenharia de Software Ágil (Scrum e FDD)
Engenharia de Software Ágil (Scrum e FDD)Rildo (@rildosan) Santos
 

Mais procurados (20)

Modelagem de Processos com BPMN e Tibco Business Studio
Modelagem de Processos com BPMN e Tibco Business StudioModelagem de Processos com BPMN e Tibco Business Studio
Modelagem de Processos com BPMN e Tibco Business Studio
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Gestão Ágil de Projetos
Gestão Ágil de ProjetosGestão Ágil de Projetos
Gestão Ágil de Projetos
 
Gerenciamento de tempo em projetos
Gerenciamento de tempo em projetosGerenciamento de tempo em projetos
Gerenciamento de tempo em projetos
 
TOGAF em Ação
TOGAF em AçãoTOGAF em Ação
TOGAF em Ação
 
Gestão Estratégica da TI - Apresentação
Gestão Estratégica da TI - ApresentaçãoGestão Estratégica da TI - Apresentação
Gestão Estratégica da TI - Apresentação
 
FDD vs XP vs SCRUM
FDD vs XP vs SCRUMFDD vs XP vs SCRUM
FDD vs XP vs SCRUM
 
Inovação, Projetos e Portfólio: Integração para Resultados Promissores
Inovação, Projetos e Portfólio: Integração para Resultados PromissoresInovação, Projetos e Portfólio: Integração para Resultados Promissores
Inovação, Projetos e Portfólio: Integração para Resultados Promissores
 
Scrum Product Owner
Scrum Product OwnerScrum Product Owner
Scrum Product Owner
 
Arquitetura de Negócios
Arquitetura de NegóciosArquitetura de Negócios
Arquitetura de Negócios
 
Gerenciamento de projetos aula 4 (escopo)
Gerenciamento de projetos   aula 4 (escopo)Gerenciamento de projetos   aula 4 (escopo)
Gerenciamento de projetos aula 4 (escopo)
 
Practical Enterprise Architecture in Medium-size Corporation using TOGAF
Practical Enterprise Architecture in Medium-size Corporation using TOGAFPractical Enterprise Architecture in Medium-size Corporation using TOGAF
Practical Enterprise Architecture in Medium-size Corporation using TOGAF
 
Gerenciamento de integração de projetos
Gerenciamento de integração de projetosGerenciamento de integração de projetos
Gerenciamento de integração de projetos
 
Aula 5 Governança de TI
Aula 5   Governança de TIAula 5   Governança de TI
Aula 5 Governança de TI
 
Gestão da qualidade metodologia ágil v01 (2)
Gestão da qualidade   metodologia ágil v01 (2)Gestão da qualidade   metodologia ágil v01 (2)
Gestão da qualidade metodologia ágil v01 (2)
 
Gestão de Serviços de TI com a ITIL. Uma introdução
Gestão de Serviços de TI com a ITIL. Uma introduçãoGestão de Serviços de TI com a ITIL. Uma introdução
Gestão de Serviços de TI com a ITIL. Uma introdução
 
Governança de TI
Governança de TIGovernança de TI
Governança de TI
 
Aula 1 - Gestão de Projetos
Aula 1 - Gestão de ProjetosAula 1 - Gestão de Projetos
Aula 1 - Gestão de Projetos
 
Engenharia de Software Ágil (Scrum e FDD)
Engenharia de Software Ágil (Scrum e FDD)Engenharia de Software Ágil (Scrum e FDD)
Engenharia de Software Ágil (Scrum e FDD)
 
Manual de oslo
Manual de osloManual de oslo
Manual de oslo
 

Destaque

Verificação, Validação e Teste de Software
Verificação, Validação e Teste de SoftwareVerificação, Validação e Teste de Software
Verificação, Validação e Teste de SoftwareCamilo Almendra
 
Kelli Janae Lindsay : LRA Uganda
Kelli Janae Lindsay : LRA Uganda Kelli Janae Lindsay : LRA Uganda
Kelli Janae Lindsay : LRA Uganda Kelli Kling
 
Final copy lra conflict uganda
Final copy lra conflict ugandaFinal copy lra conflict uganda
Final copy lra conflict ugandaKelli Kling
 
LRA Presentation 1
LRA Presentation 1LRA Presentation 1
LRA Presentation 1ildikoscurr
 
Gj Sue Tr Policy
Gj Sue Tr PolicyGj Sue Tr Policy
Gj Sue Tr PolicyCallieO
 
Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1Fernando Palma
 
Introdução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem práticaIntrodução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem práticaFabrício Campos
 
C-LRA Program Evaluation and Needs Assessment
C-LRA Program Evaluation and Needs AssessmentC-LRA Program Evaluation and Needs Assessment
C-LRA Program Evaluation and Needs AssessmentRobert Grossman-Vermaas
 
LRA Investor Presentation 13 05-17
LRA Investor Presentation 13 05-17 LRA Investor Presentation 13 05-17
LRA Investor Presentation 13 05-17 Lara_Exploration
 
Semantic Relations
Semantic RelationsSemantic Relations
Semantic RelationsJennifer Lee
 
Open Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen EinsatzOpen Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen EinsatzMatthias Stürmer
 
Projektmanagement 2.0: Social Software für die Projektkommunikation
Projektmanagement 2.0: Social Software für die ProjektkommunikationProjektmanagement 2.0: Social Software für die Projektkommunikation
Projektmanagement 2.0: Social Software für die ProjektkommunikationKommunikation-zweinull
 
13 03-01 lra investor presentation
13 03-01 lra investor presentation13 03-01 lra investor presentation
13 03-01 lra investor presentationLara_Exploration
 
Risiken von Open Source Software
Risiken von Open Source SoftwareRisiken von Open Source Software
Risiken von Open Source SoftwareMatthias Stürmer
 
Das Potential von freier Software (Open Source) für KMUs
Das Potential von freier Software (Open Source) für KMUsDas Potential von freier Software (Open Source) für KMUs
Das Potential von freier Software (Open Source) für KMUsMatthias Stürmer
 

Destaque (20)

Verificação, Validação e Teste de Software
Verificação, Validação e Teste de SoftwareVerificação, Validação e Teste de Software
Verificação, Validação e Teste de Software
 
Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
 
Kelli Janae Lindsay : LRA Uganda
Kelli Janae Lindsay : LRA Uganda Kelli Janae Lindsay : LRA Uganda
Kelli Janae Lindsay : LRA Uganda
 
Final copy lra conflict uganda
Final copy lra conflict ugandaFinal copy lra conflict uganda
Final copy lra conflict uganda
 
LRA Presentation (1)
LRA Presentation (1)LRA Presentation (1)
LRA Presentation (1)
 
LRA Presentation 1
LRA Presentation 1LRA Presentation 1
LRA Presentation 1
 
Gj Sue Tr Policy
Gj Sue Tr PolicyGj Sue Tr Policy
Gj Sue Tr Policy
 
Ctai Teste De Software Aula 1
Ctai Teste De Software Aula 1Ctai Teste De Software Aula 1
Ctai Teste De Software Aula 1
 
Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1
 
Introdução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem práticaIntrodução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem prática
 
C-LRA Program Evaluation and Needs Assessment
C-LRA Program Evaluation and Needs AssessmentC-LRA Program Evaluation and Needs Assessment
C-LRA Program Evaluation and Needs Assessment
 
LRA Investor Presentation 13 05-17
LRA Investor Presentation 13 05-17 LRA Investor Presentation 13 05-17
LRA Investor Presentation 13 05-17
 
Conflict in North Uganda
Conflict in North UgandaConflict in North Uganda
Conflict in North Uganda
 
Semantic Relations
Semantic RelationsSemantic Relations
Semantic Relations
 
Open Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen EinsatzOpen Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen Einsatz
 
Projektmanagement 2.0: Social Software für die Projektkommunikation
Projektmanagement 2.0: Social Software für die ProjektkommunikationProjektmanagement 2.0: Social Software für die Projektkommunikation
Projektmanagement 2.0: Social Software für die Projektkommunikation
 
13 03-01 lra investor presentation
13 03-01 lra investor presentation13 03-01 lra investor presentation
13 03-01 lra investor presentation
 
20100822 opensmt bruttomesso
20100822 opensmt bruttomesso20100822 opensmt bruttomesso
20100822 opensmt bruttomesso
 
Risiken von Open Source Software
Risiken von Open Source SoftwareRisiken von Open Source Software
Risiken von Open Source Software
 
Das Potential von freier Software (Open Source) für KMUs
Das Potential von freier Software (Open Source) für KMUsDas Potential von freier Software (Open Source) für KMUs
Das Potential von freier Software (Open Source) für KMUs
 

Semelhante a Engenharia de Software 100% Agil (SCRUM, FDD e XP)

Workshop Scrum Product Owner, Delírios de PO em Dia de Verão v6
Workshop Scrum Product Owner, Delírios de PO em Dia de Verão v6Workshop Scrum Product Owner, Delírios de PO em Dia de Verão v6
Workshop Scrum Product Owner, Delírios de PO em Dia de Verão v6Rildo (@rildosan) Santos
 
Tutorial BizAgi - Modelagem de Processos com BPMN e BizAgi
Tutorial BizAgi - Modelagem de Processos com BPMN e BizAgiTutorial BizAgi - Modelagem de Processos com BPMN e BizAgi
Tutorial BizAgi - Modelagem de Processos com BPMN e BizAgiRildo (@rildosan) Santos
 
Análise, Simulação e Melhoria de Processo com WBM
Análise, Simulação e Melhoria de Processo com WBMAnálise, Simulação e Melhoria de Processo com WBM
Análise, Simulação e Melhoria de Processo com WBMRildo (@rildosan) Santos
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREErnesto Bedrikow
 
CV Jorge Ramos Ago 2014
CV Jorge Ramos Ago 2014CV Jorge Ramos Ago 2014
CV Jorge Ramos Ago 2014Jorge Ramos
 
Mapeamento e Modelagem de Processos de Negócios com BPMN
Mapeamento e Modelagem de Processos de Negócios com BPMNMapeamento e Modelagem de Processos de Negócios com BPMN
Mapeamento e Modelagem de Processos de Negócios com BPMNJean Israel B. Feijó
 
Mapeamento e Modelagem de Processos de Negócios com BPM
Mapeamento e Modelagem de Processos de Negócios com BPMMapeamento e Modelagem de Processos de Negócios com BPM
Mapeamento e Modelagem de Processos de Negócios com BPMRogério Araújo
 
Como Melhorar a Qualidade dos Serviços de TI Com as Práticas da ITIL
Como Melhorar a Qualidade dos Serviços de TI Com as Práticas da ITILComo Melhorar a Qualidade dos Serviços de TI Com as Práticas da ITIL
Como Melhorar a Qualidade dos Serviços de TI Com as Práticas da ITILRildo (@rildosan) Santos
 
Mapeamento e Modelagem de Processos de Negócio com BPMN
Mapeamento e Modelagem de Processos de Negócio com BPMNMapeamento e Modelagem de Processos de Negócio com BPMN
Mapeamento e Modelagem de Processos de Negócio com BPMNRildo (@rildosan) Santos
 
Produtividade em Desenvolvimento de Software
Produtividade em Desenvolvimento de SoftwareProdutividade em Desenvolvimento de Software
Produtividade em Desenvolvimento de SoftwareRildo (@rildosan) Santos
 
Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos ÁgeisAldo Pires
 
Tutorial Planning Poker Para Times Remotos
Tutorial Planning Poker Para Times RemotosTutorial Planning Poker Para Times Remotos
Tutorial Planning Poker Para Times RemotosRildo (@rildosan) Santos
 

Semelhante a Engenharia de Software 100% Agil (SCRUM, FDD e XP) (20)

Kanban para Desenvolvimento de Software
Kanban para Desenvolvimento de SoftwareKanban para Desenvolvimento de Software
Kanban para Desenvolvimento de Software
 
Workshop Scrum Product Owner, Delírios de PO em Dia de Verão v6
Workshop Scrum Product Owner, Delírios de PO em Dia de Verão v6Workshop Scrum Product Owner, Delírios de PO em Dia de Verão v6
Workshop Scrum Product Owner, Delírios de PO em Dia de Verão v6
 
Gestão por Processo
Gestão por ProcessoGestão por Processo
Gestão por Processo
 
Tutorial BizAgi - Modelagem de Processos com BPMN e BizAgi
Tutorial BizAgi - Modelagem de Processos com BPMN e BizAgiTutorial BizAgi - Modelagem de Processos com BPMN e BizAgi
Tutorial BizAgi - Modelagem de Processos com BPMN e BizAgi
 
Análise, Simulação e Melhoria de Processo com WBM
Análise, Simulação e Melhoria de Processo com WBMAnálise, Simulação e Melhoria de Processo com WBM
Análise, Simulação e Melhoria de Processo com WBM
 
20141128-Carlos-Eduardo-Capparelli
20141128-Carlos-Eduardo-Capparelli20141128-Carlos-Eduardo-Capparelli
20141128-Carlos-Eduardo-Capparelli
 
Melhoria de Processo de Negócio
Melhoria de Processo de NegócioMelhoria de Processo de Negócio
Melhoria de Processo de Negócio
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWARE
 
CV Jorge Ramos Ago 2014
CV Jorge Ramos Ago 2014CV Jorge Ramos Ago 2014
CV Jorge Ramos Ago 2014
 
Mapeamento e Modelagem de Processos de Negócios com BPMN
Mapeamento e Modelagem de Processos de Negócios com BPMNMapeamento e Modelagem de Processos de Negócios com BPMN
Mapeamento e Modelagem de Processos de Negócios com BPMN
 
Mapeamento e Modelagem de Processos de Negócios com BPM
Mapeamento e Modelagem de Processos de Negócios com BPMMapeamento e Modelagem de Processos de Negócios com BPM
Mapeamento e Modelagem de Processos de Negócios com BPM
 
Como Melhorar a Qualidade dos Serviços de TI Com as Práticas da ITIL
Como Melhorar a Qualidade dos Serviços de TI Com as Práticas da ITILComo Melhorar a Qualidade dos Serviços de TI Com as Práticas da ITIL
Como Melhorar a Qualidade dos Serviços de TI Com as Práticas da ITIL
 
Mapeamento e Modelagem de Processos de Negócio com BPMN
Mapeamento e Modelagem de Processos de Negócio com BPMNMapeamento e Modelagem de Processos de Negócio com BPMN
Mapeamento e Modelagem de Processos de Negócio com BPMN
 
Tutorial Visio Modelagem de Processos
Tutorial Visio Modelagem de ProcessosTutorial Visio Modelagem de Processos
Tutorial Visio Modelagem de Processos
 
Produtividade em Desenvolvimento de Software
Produtividade em Desenvolvimento de SoftwareProdutividade em Desenvolvimento de Software
Produtividade em Desenvolvimento de Software
 
Notação BPMN v. 1.2
Notação BPMN v. 1.2Notação BPMN v. 1.2
Notação BPMN v. 1.2
 
Notação BPMN v. 1.2
Notação BPMN v. 1.2 Notação BPMN v. 1.2
Notação BPMN v. 1.2
 
Carlos Eduardo Capparelli
Carlos Eduardo CapparelliCarlos Eduardo Capparelli
Carlos Eduardo Capparelli
 
Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos Ágeis
 
Tutorial Planning Poker Para Times Remotos
Tutorial Planning Poker Para Times RemotosTutorial Planning Poker Para Times Remotos
Tutorial Planning Poker Para Times Remotos
 

Mais de Rildo (@rildosan) Santos

Minicurso Fundamentos da Análise de Negócio 3.0
Minicurso Fundamentos da Análise de Negócio 3.0Minicurso Fundamentos da Análise de Negócio 3.0
Minicurso Fundamentos da Análise de Negócio 3.0Rildo (@rildosan) Santos
 
Minicurso Gestão Ágil de Projetos com Abordagem Híbrida
Minicurso Gestão Ágil de Projetos com Abordagem HíbridaMinicurso Gestão Ágil de Projetos com Abordagem Híbrida
Minicurso Gestão Ágil de Projetos com Abordagem HíbridaRildo (@rildosan) Santos
 
Digital Business Design (Design de Negócios Digitais)
Digital Business Design (Design de Negócios Digitais)Digital Business Design (Design de Negócios Digitais)
Digital Business Design (Design de Negócios Digitais)Rildo (@rildosan) Santos
 
Novidades da Sétima Edição do Guia PMBOK
Novidades da Sétima Edição do Guia PMBOKNovidades da Sétima Edição do Guia PMBOK
Novidades da Sétima Edição do Guia PMBOKRildo (@rildosan) Santos
 
Portfólio de Análise de Negócio: Consultoria, Treinamento e Mentoria
Portfólio de Análise de Negócio: Consultoria, Treinamento e MentoriaPortfólio de Análise de Negócio: Consultoria, Treinamento e Mentoria
Portfólio de Análise de Negócio: Consultoria, Treinamento e MentoriaRildo (@rildosan) Santos
 

Mais de Rildo (@rildosan) Santos (20)

Feedback. Arte de dar e receber feedback
Feedback. Arte de dar e receber feedbackFeedback. Arte de dar e receber feedback
Feedback. Arte de dar e receber feedback
 
Minicurso Meça o que importa com OKR
Minicurso Meça o que importa com OKRMinicurso Meça o que importa com OKR
Minicurso Meça o que importa com OKR
 
Minicurso Fundamentos da Análise de Negócio 3.0
Minicurso Fundamentos da Análise de Negócio 3.0Minicurso Fundamentos da Análise de Negócio 3.0
Minicurso Fundamentos da Análise de Negócio 3.0
 
Meça o que importa com OKR
Meça o que importa com OKRMeça o que importa com OKR
Meça o que importa com OKR
 
Scrum Experience
Scrum ExperienceScrum Experience
Scrum Experience
 
Minicurso Gestão Ágil de Projetos com Abordagem Híbrida
Minicurso Gestão Ágil de Projetos com Abordagem HíbridaMinicurso Gestão Ágil de Projetos com Abordagem Híbrida
Minicurso Gestão Ágil de Projetos com Abordagem Híbrida
 
Digital Business Design (Design de Negócios Digitais)
Digital Business Design (Design de Negócios Digitais)Digital Business Design (Design de Negócios Digitais)
Digital Business Design (Design de Negócios Digitais)
 
Novidades da Sétima Edição do Guia PMBOK
Novidades da Sétima Edição do Guia PMBOKNovidades da Sétima Edição do Guia PMBOK
Novidades da Sétima Edição do Guia PMBOK
 
Jornada de Aprendizado Lean BPM
Jornada de Aprendizado Lean BPM Jornada de Aprendizado Lean BPM
Jornada de Aprendizado Lean BPM
 
Tutorial Scrum Experience
Tutorial Scrum Experience Tutorial Scrum Experience
Tutorial Scrum Experience
 
Guia BPM CBOK(R)
Guia BPM CBOK(R)Guia BPM CBOK(R)
Guia BPM CBOK(R)
 
Scrum Master em ação
Scrum Master em açãoScrum Master em ação
Scrum Master em ação
 
Transformação Ágil
Transformação ÁgilTransformação Ágil
Transformação Ágil
 
Service Design Thinking
Service Design Thinking Service Design Thinking
Service Design Thinking
 
Gestão de Projetos Ágeis
Gestão de Projetos ÁgeisGestão de Projetos Ágeis
Gestão de Projetos Ágeis
 
Scrum, o tutorial definitivo
Scrum, o tutorial definitivo Scrum, o tutorial definitivo
Scrum, o tutorial definitivo
 
Feedback Canvas
Feedback CanvasFeedback Canvas
Feedback Canvas
 
Business Design Thinking
Business Design ThinkingBusiness Design Thinking
Business Design Thinking
 
Guia de Práticas de Análise de Negócio
Guia de Práticas de Análise de NegócioGuia de Práticas de Análise de Negócio
Guia de Práticas de Análise de Negócio
 
Portfólio de Análise de Negócio: Consultoria, Treinamento e Mentoria
Portfólio de Análise de Negócio: Consultoria, Treinamento e MentoriaPortfólio de Análise de Negócio: Consultoria, Treinamento e Mentoria
Portfólio de Análise de Negócio: Consultoria, Treinamento e Mentoria
 

Último

ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx2m Assessoria
 
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASCOI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASMarcio Venturelli
 
Aula 01 - Introducao a Processamento de Frutos e Hortalicas.pdf
Aula 01 - Introducao a Processamento de Frutos e Hortalicas.pdfAula 01 - Introducao a Processamento de Frutos e Hortalicas.pdf
Aula 01 - Introducao a Processamento de Frutos e Hortalicas.pdfInocencioHoracio3
 
Convergência TO e TI nas Usinas - Setor Sucroenergético
Convergência TO e TI nas Usinas - Setor SucroenergéticoConvergência TO e TI nas Usinas - Setor Sucroenergético
Convergência TO e TI nas Usinas - Setor SucroenergéticoMarcio Venturelli
 
Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiPaulo Pagliusi, PhD, CISM
 
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docxATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx2m Assessoria
 
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docxATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx2m Assessoria
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAMarcio Venturelli
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPaulo Pagliusi, PhD, CISM
 

Último (9)

ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
 
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASCOI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
 
Aula 01 - Introducao a Processamento de Frutos e Hortalicas.pdf
Aula 01 - Introducao a Processamento de Frutos e Hortalicas.pdfAula 01 - Introducao a Processamento de Frutos e Hortalicas.pdf
Aula 01 - Introducao a Processamento de Frutos e Hortalicas.pdf
 
Convergência TO e TI nas Usinas - Setor Sucroenergético
Convergência TO e TI nas Usinas - Setor SucroenergéticoConvergência TO e TI nas Usinas - Setor Sucroenergético
Convergência TO e TI nas Usinas - Setor Sucroenergético
 
Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo Pagliusi
 
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docxATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
 
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docxATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
 

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