Processos Ágeis de Desenvolvimento de Software Márcio Amorim mkamorim@gmail.com Milton Campos miltoncampospe@gmail.com Recife-PE, 2009 PADS

Estrutura do Capítulo 9.1 Introdução 9.2 Origem Ágil 9.3 Extreme Programming – XP 9.4 Scrum 9.5 Feature Driven Development – FDD 9.6 Dynamic Systems Development Method - DSDM 9.7 Considerações Finais 9.8 Exercício 9.9 Referências Bibliográficas CIN/UFPE Márcio Amorim / Milton Campos

Estrutura do Processo no Capítulo 9.5 Processo X 9.5.1 A Aplicabilidade do X. 9.5.2 Características do X. 9.5.3 Ciclo de Vida do X. 9.5.4 Papéis do X. 9.5.5 Práticas do X. CIN/UFPE Márcio Amorim / Milton Campos

Contextualização A Engenharia de software vêm recorrentemente enfrentando o cenário onde ... as aplicações são cada vez mais complexas... o tempo de desenvolvimento é cada vez menor... há necessidade de diminuição de custos ... busca constante pelo aumento da qualidade.

Contextualização Processos tradicionais tornaram-se “pesados” para a engenharia de software Muita burocracia Muita documentação Pouca flexibilidade a mudanças no projeto Não contemplam o cenário atual Conflito de interesses

Origem Ágil Reunião entre 17 gurus da comunidade de desenvolvimento: Kent Beck, Mike Beedle, Arie Van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas. Realizada entre os dias 11 e 13 de fevereiro de 2001 em uma estação de esqui nas montanhas de Utah, Estados Unidos, CIN/UFPE Márcio Amorim / Milton Campos

Manifesto for Agile Software Development Origem Ágil Manifesto for Agile Software Development We are uncovering better ways of developing  software by doing it and helping others do it.  Through this work we have come to value: Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan  That is, while there is value in the items on  the right, we value the items on the left more.  CIN/UFPE Márcio Amorim / Milton Campos

eXtreme Programming XP Márcio Amorim mkamorim@gmail.com Milton Campos miltoncampospe@gmail.com XP

eXtreme Programming Em meados de 1990, Kent Beck procurou formas mais simples e eficientes de desenvolver software Identificou o que tornava simples e o que dificultava o desenvolvimento de software Em Março de 1996, ele iniciou um projeto com novos conceitos que resultaram no processo XP - eXtreme Programming CIN/UFPE Márcio Amorim / Milton Campos

eXtreme Programming “Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança” Kent Beck CIN/UFPE Márcio Amorim / Milton Campos

Características do XP Equipes pequenas e médias; Requisitos vagos; Valores, Princípios e Práticas; Foco na programação. CIN/UFPE Márcio Amorim / Milton Campos

Papéis do XP Gerente de Projeto Analista de Teste Coach Desenvolvedor Cliente Redator Técnico CIN/UFPE Márcio Amorim / Milton Campos

Valores do XP Comunicação; Simplicidade; Feedback; e Coragem. CIN/UFPE Márcio Amorim / Milton Campos

Princípios do XP Feedback rápido; Assumir simplicidade; Mudanças incrementais; e Trabalho de qualidade. CIN/UFPE Márcio Amorim / Milton Campos

Práticas do XP Cliente Presente; Jogo de Planejamento; Stand Up Meeting; Programação Pareada; Desenvolvimento guiado pelos testes; Refatoração; CIN/UFPE Márcio Amorim / Milton Campos

Práticas do XP Código Coletivo; Código Padronizado; Projeto Simples; Metáfora; Ritmo Sustentável; Integração Continua; e Pequenas Versões. CIN/UFPE Márcio Amorim / Milton Campos

Ciclo de Vida do XP A fase de exploração É anterior à construção do sistema; Investigações de possíveis soluções são feitas e verifica-se a viabilidade de tais soluções; Os programadores elaboram possíveis arquiteturas e fazem considerações sobre o ambiente tecnológico (hardware, rede, software, performance, tráfego) onde o sistema irá rodar. CIN/UFPE Márcio Amorim / Milton Campos

Ciclo de Vida do XP A fase de planejamento inicial Definição das estórias pelo cliente; Os programadores assinalam dificuldades; Escolhas das estórias por valor de negócio. CIN/UFPE Márcio Amorim / Milton Campos

Ciclo de Vida do XP Iterações do release São escritos os casos de teste funcionais e de unidade. Os programadores vão seguindo mais ou menos o seguinte fluxo de atividades na seguinte ordem (em cada iteração): escrita dos casos de testes; projeto e refatoramento; codificação; realização dos testes; e integração. CIN/UFPE Márcio Amorim / Milton Campos

Ciclo de Vida do XP A fase de manutenção pode ser considerada como uma característica inerente a um projeto XP; Em XP você está simultaneamente produzindo novas funcionalidades, mantendo o sistema existente rodando, incorporando novas pessoas na equipe e melhorando o código. CIN/UFPE Márcio Amorim / Milton Campos

Ciclo de Vida do XP A fase de morte Atendendo o que foi solicitado pelo cliente; Economicamente inviável, devido a dificuldades de adicionar funcionalidades a um custo baixo e devido a uma alta taxa de erros. CIN/UFPE Márcio Amorim / Milton Campos

Referências Bibliográficas MANHÃES Teles, Vinícius. Extreme Programming. 1. ed. Novatec Editora, 2004. BECK, Kent. Programação Extrema Explicada: acolha as mudanças. 1. ed. Bookman, 2004. MANHÃES Teles, Vinícius. Um Estudo de Caso da Adoção das Práticas e Valores do Extreme Programming. Dissertação (mestrado em informática) – Universidade Federal do Rio de Janeiro - UFRJ, IM / DCC, 2005. CIN/UFPE Márcio Amorim / Milton Campos

Scrum Márcio Amorim Milton Campos mkamorim@gmail.com miltoncampospe@gmail.com

SCRUM Ênfase dada ao gerenciamento do projeto. Atividades de monitoramento e feedback Não estabelece técnicas para o desenvolvimento Equipes pequenas (máximo 7 pessoas) Requisitos que são pouco estáveis ou desconhecidos Ciclos curtos (Sprint máx. 30 dias) Envolvimento do “cliente” Ken Schwaber e Jeff Sutherland

Papéis no Scrum Product Owner (PO): representa os interesses de todos no projeto, define as funcionalidades e as priorizam. Scrum Master (SM): facilitador, apóia a equipe no uso adequado do processo, promove reuniões, remove os impedimentos Time: desenvolve as funcionalidades

Scrum Agile Methodology 12/04/2017 Main Flow Product Backlog - Uma lista com todo o trabalho desejado para o projeto. Product owner redefine as prioridades no início de cada sprint Creative Commons “Some Rights Reserved” 2008 left (left@dev.java.net)

Scrum Agile Methodology 12/04/2017 Product Backlog Backlog item (BLI) Business Value (BV) [BLI001] As a standard user, search for a movie 1000 [BLI002] As a standard user, search for movie reviews [BLI003] As a standard user, view the top movies [BLI004] As a standard user, search for theaters 700 [BLI005] As a standard user, search for movie trailers [BLI006] As a standard user, create the user profile 500 [BLI007] As a standard user, edit the user profile 300 [BLI008] Integration with LDAP 100 Creative Commons “Some Rights Reserved” 2008 left (left@dev.java.net)

Scrum Agile Methodology 12/04/2017 Main Flow Sprint Planning 1: Máximo de 4 horas para revisar o product backlog, determinar o objetivo da sprint, escolher e estimar IBLs Creative Commons “Some Rights Reserved” 2008 left (left@dev.java.net)

Scrum Agile Methodology 12/04/2017 Sprint Planning 1 BLI BV Size [Story Points (SP)] BV/SP [IBL003] As a standard user, view the top movies 1000 2 500 [IBL002] As a standard user, search for movie reviews 3 333 [IBL001] As a standard user, search for a movie 5 200 [IBL004] As a standard user, search for theaters 700 13 53 [IBL005] As a standard user, search for movie trailers [IBL006] As a standard user, create the user profile 21 23 Creative Commons “Some Rights Reserved” 2008 left (left@dev.java.net)

Scrum Agile Methodology 12/04/2017 Main Flow Definir as tarefas necessárias para construir as funcionalidades do produto com base nas IBLs selecionadas Creative Commons “Some Rights Reserved” 2008 left (left@dev.java.net)

Scrum Agile Methodology 12/04/2017 Sprint Backlog IBLs Tasks To Do Work In Progress Done [IBL001] [IBL003] [IBL002] Requirements Analysis and Design Coding Test Code Review Deployment Requirements Analysis and Design Coding Test Code Review Deployment Requirements Analysis and Design Coding Test Code Review Deployment Creative Commons “Some Rights Reserved” 2008 left (left@dev.java.net)

Scrum Agile Methodology 12/04/2017 Main Flow Creative Commons “Some Rights Reserved” 2008 left (left@dev.java.net)

Scrum Agile Methodology 12/04/2017 Daily Scrums Reunião diária de 15 minutos Mesmo local e hora todo os dias Cada integrante do time, responde: O que você terminou desde a última reunião? O que vai terminar antes da próxima reunião? Quais os impedimentos? Creative Commons “Some Rights Reserved” 2008 left (left@dev.java.net)

Scrum Agile Methodology 12/04/2017 Sprint – The Task Board IBLs Tasks To Do Work In Progress Done [IBL001] [IBL003] [IBL002] Requirements Analysis and Design Coding Test Code Review Deployment Requirements Analysis and Design Coding Code Review Deployment Test dev 0 imp dev 1 Requirements Analysis and Design Coding Test Code Review Deployment Creative Commons “Some Rights Reserved” 2008 left (left@dev.java.net)

Scrum Agile Methodology 12/04/2017 Burndown Chart Creative Commons “Some Rights Reserved” 2008 left (left@dev.java.net)

Scrum Agile Methodology 12/04/2017 Main Flow Creative Commons “Some Rights Reserved” 2008 left (left@dev.java.net)

Scrum Agile Methodology 12/04/2017 Sprint Review Meeting Participa todos os stakeholders Apresentação do que foi “feito” durante a Sprint Creative Commons “Some Rights Reserved” 2008 left (left@dev.java.net)

Scrum Agile Methodology 12/04/2017 Sprint Retrospective Participa o time e o PO Melhoria do Processo Soluções para os problemas críticos Creative Commons “Some Rights Reserved” 2008 left (left@dev.java.net)

Referências Bibliográficas Schwaber, K., Agile Project Management With Scrum, Microsoft, 2004. Schwaber, K. and Beedle, M., Agile Software Development With Scrum. NJ: Prentence Hall, 2002. CIN/UFPE Márcio Amorim / Milton Campos

Feature Driven Development Márcio Amorim mkamorim@gmail.com Milton Campos miltoncampospe@gmail.com FDD

Feature Driven Development ... após 2 anos de consultoria, 3.500 páginas de casos de uso e um modelo de objetos com centenas de classes, foi avaliado como impossível. CIN/UFPE Márcio Amorim / Milton Campos

Feature Driven Development Criada em 1997 em um grande projeto em Java para o United Overseas Bank, em Singapura; Nasceu a partir da experiência de análise e modelagem orientadas por objetos de Peter Coad, e de gerenciamento de projetos de Jeff De Luca; CIN/UFPE Márcio Amorim / Milton Campos

Feature Driven Development Primeira publicação em 1999, no do livro Java Modeling in Color with UML, de Peter Coad, Eric Lefebvre e Jeff De Luca; Em 2002, Stephen Palmer e John Mac Felsing publicaram o livro A Pratical Guide to Feature Driven Development, com a versão completa; CIN/UFPE Márcio Amorim / Milton Campos

Feature Driven Development Em 2003, David Anderson, o livro Agile Management for Software Engineering: Using the Theory of Constraints for Business Results, considerado por muitos como um marco na literatura ágil. CIN/UFPE Márcio Amorim / Milton Campos

Feature Driven Development Metodologia ágil para o processo de engenharia de software, com foco na entrega frequente do sistema funcionando e na utilização de boas práticas durante o ciclo de desenvolvimento. CIN/UFPE Márcio Amorim / Milton Campos

Características do FDD Situa-se numa posição intermediária entre as abordagens mais tradicionais e as ágeis; Envolvimento do cliente nos processos de planejamento e desenvolvimento de software; CIN/UFPE Márcio Amorim / Milton Campos

Características do FDD Não é extremamente focada apenas na programação ou no modelo, mas sim utiliza o bom senso para abstrair o melhor dos dois mundos; Tamanho dos times de 16 – 20 membros, suportando composições bem maiores; CIN/UFPE Márcio Amorim / Milton Campos

Características do FDD Entrega resultados funcionais e tangíveis a cada 2 semanas ou menos; Pequenos blocos de funcionalidades (features) valorizados pelo cliente; Planejamento detalhado e guiado para medição; Produção de software com qualidade. CIN/UFPE Márcio Amorim / Milton Campos

Papéis do FDD Suporte Documentador Testador Gestor de projeto Adm. de sistemas Gestor de desenvolvimento Eng. de builds CLIENTE Guru de linguagem Chefe de design Papéis: Programador chefe Gestor de atividade Primário Secundário Adicionais Dono de classe Especialista CIN/UFPE Márcio Amorim / Milton Campos

Práticas Modelagem de objetos de domínio; Desenvolvimento por feature; Posse individual do código/classe; Equipes de features; Inspeções e builds reguladores; Gerenciamento de configuração; Relatório/visibilidade de resultados. CIN/UFPE Márcio Amorim / Milton Campos

Estrutura 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). CIN/UFPE Márcio Amorim / Milton Campos

Estrutura Possui cinco processos bem definidos e integrados: Desenvolver um Modelo Abrangente: Análise Orientada por Objetos Construir a Lista de Funcionalidades: Decomposição Funcional Planejar por Funcionalidade: Planejamento Incremental Detalhar por Funcionalidade: Desenho (Projeto) Orientado por Objetos Construir por Funcionalidade: Programação e Teste Orientados por Objetos CIN/UFPE Márcio Amorim / Milton Campos

Estrutura CIN/UFPE Márcio Amorim / Milton Campos

Os 5 processos DMA É uma atividade inicial que abrange todo o projeto, na qual realiza-se um estudo dirigido sobre o escopo do sistema e seu contexto, bem como outros mais detalhados sobre o domínio do negócio para cada área a ser modelada. CLIENTE Especialista Programador-chefe Arquiteto-chefe CIN/UFPE Márcio Amorim / Milton Campos

Estrutura CIN/UFPE Márcio Amorim / Milton Campos

Os 5 processos CLF É uma atividade inicial que abrange todo o projeto, para identificar todas as funcionalidades que satisfaçam aos requisitos, formando assim a lista categorizada de funcionalidades. Decompor funcionalmente o domínio em áreas de negócio; Atividades de negócio dentro delas; e Passos dentro de cada atividade de negócio. CLIENTE Especialista Programador-chefe Arquiteto-chefe CIN/UFPE Márcio Amorim / Milton Campos

Estrutura CIN/UFPE Márcio Amorim / Milton Campos

Os 5 processos PPF É uma atividade inicial que abrange todo o projeto, para produzir o plano de desenvolvimento. Planejam a ordem a partir das dependências, carga de trabalho do time e complexidade da funcionalidade; CLIENTE Gestor de Projeto Gestor de Desenvolvimento Programador-chefe CIN/UFPE Márcio Amorim / Milton Campos

Estrutura CIN/UFPE Márcio Amorim / Milton Campos

Os 5 processos DPF É uma atividade executada para cada funcionalidade, para produzir o pacote de projeto (design) para ela. Seleciona as funcionalidades e identificam os donos da classe; Produz o(s) diagrama(s) de seqüência para a(s) funcionalidade(s) atribuída(s) e refina o modelo de objetos. Planejamento ......................................... CLIENTE Planejamento completo Dono da classe Programador-chefe CIN/UFPE Márcio Amorim / Milton Campos

Estrutura CIN/UFPE Márcio Amorim / Milton Campos

Os 5 processos CPF É uma atividade executada para cada funcionalidade, para produzir uma função com valor para o cliente (funcionalidade). Os donos das classes implementam; O código passa por testes e inspeção; O código é promovido à versão atual (build). CLIENTE Eng. de build Dono da classe Dono da classe Programador-chefe CIN/UFPE Márcio Amorim / Milton Campos

Estrutura CIN/UFPE Márcio Amorim / Milton Campos

Estudo dirigido sobre o domínio Estrutura - medição 4 - DPF 5 - CPF Estudo dirigido sobre o domínio 1% Desenho do projeto 40% Inspeção do desenho 3% Codificação 45% Inspeção de código 10% Promoção ao build No ciclo iterativo (processos 4 e 5), o progresso é medido com base em 6 marcos ( milestones) bem definidos; A cada etapa cumprida, o percentual respectivo é agregado ao total de progresso da feature. CIN/UFPE Márcio Amorim / Milton Campos

Estrutura - progresso CIN/UFPE Márcio Amorim / Milton Campos Feature Status disponíveis:   NÃO INICIADA ANDAMENTO CONCLUÍDO ABORTADA BLI 7 - informar qual o caso de teste do bug Atualizar doc. requisitos Atualizar VO Ana 24-May Atualizar model Atualizar Magic Search para levar em consideração a nova coluna Milton 25-May Atualizar datagrid para listar os test cases Listar os possíveis test cases na tela de criação/edição do bug 26-May Persistir o test case do bug no banco de dados Atualizar Choose Column para visualizar / ocultar testcase Atualizar o histório pra salvar as alterações dos Testes 28-May Atualizar planilha de testes Executar testes sistêmicos Camila 29-May 31-May CIN/UFPE Márcio Amorim / Milton Campos

...,... implantação das metodologias de OOAD de Peter Coad e de gerência de projetos de Jeff De Luca. ...,...,... 15 meses após a contratação da dupla, 2.000 features entregues por uma equipe de 50 pessoas. CIN/UFPE Márcio Amorim / Milton Campos

Links e Materiais Portal FDD, mantido por Jeff De Luca, gerente do projeto original e criador da FDD FDD na Nebulon, empresa de Jeff De Luca Stephen Palmer, co-autor do Guia Prático da FDD, consultor sênior da Borland UK FDD Channel no Agile Management, site de David Anderson, autor do livro de mesmo nome, e participante do projeto que deu origem à FDD FDD na Agile Alliance Process Exchange, empresa de John Mac Felsing, co-autor do Guia Prático da FDD Grupo de Usuários da FDD (em Português Brasileiro) FDD na Heptagon FDD na InfoQ CIN/UFPE Márcio Amorim / Milton Campos

Links e Materiais Mini-curso de FDD, ministrado pelo Heptaman na BorCon 2005 Entrevista (mp3) com Jeff De Luca, para a Software Engineering Radio, da Alemanha Entrevista (pdf) com Jeff De Luca, para a IT Agile, da Alemanha Descrição original dos processos da FDD, no capítulo 6 do livro "Java Modeling in Color with UML" (1999) Video com David Anderson apresentando FDD, juntamente com Alistair Cockburn apresentando Crystal FDD em uma Casca de Banana, por Alexandre Magno Algumas implementações da FDD, por Jeff De Luca FDD: An Agile Alternative to XP, por Brad Appleton (CM Crossroads) CIN/UFPE Márcio Amorim / Milton Campos

Links e Materiais FDD em CM Crossroads, diversos artigos e muitos links sobre FDD, UML em Cores e outros recursos (por Brad Appleton) Understanding XP Through FDD FDD and XP: A Comparison, por Stephen Palmer Agile Modeling and Feature-Driven Development, por Scott Ambler Cognizant FDD Implementation, uma grande empresa indiana que ampliou a FDD CMMI or Agile: Why Not Embrace Both! Nota técnica oficial do SEI sobre a combinação entre o CMMI e Agile (com menções sobre a FDD) CIN/UFPE Márcio Amorim / Milton Campos

Referências Bibliográficas ANDERSON, D.J.. Agile Management for Software Engineering: Using the Theory of Constraints for Business Results. 2003 COAD, P.; et al. Java modeling in color with UML: enterprise components and process. Upper Saddle River, NJ: Prentice Hall, 1999. PALMER, Stephen. A practical Guide to Feature Driven Development. 2002. CIN/UFPE Márcio Amorim / Milton Campos

Dynamic Systems Development Method Márcio Amorim mkamorim@gmail.com Milton Campos miltoncampospe@gmail.com DSDM

DSDM Dynamic Systems Development Method Originalmente baseada no RAD Progenitor do XP Participação ativa dos usuários Fixa tempo e recursos ajustando a quantia de funcionalidades Pequenas equipes Suporta mudanças nos requisitos durante o ciclo de vida

Ciclo de Vida DSDM *Etapas de desenvolvimento completada até que seja possível iniciar o passo seguinte Análise da Viabilidade do DSDM Projetos – Pré-requisitos do DSDM, riscos (workshops) Análise do Negócio - nível examina o processo de financiamento, os utilizadores envolvidos e as suas necessidades e desejos. Define os requisitos, o plano inicial de desenvolvimento e a arquitetura inicial Análise Funcional - Modelo Funcional e o Protótipo Funcional. Testes pelos utilizadores Desenho – Protótipo de desenhos. Requisitos não funcionais respectivos

Técnicas do DSDM Timeboxing: Encapsulamento de tempo. Requisitos são escalonados com o princípio de Moscow. TEM de ter isto. DEVE ter isto se for possível ter todo. PODE ter isto se não afetar o resto. NÃO VAI ter isto agora mas SERIA bom ter no futuro.

Técnicas do DSDM Prototipagem: descoberta antecipada de possíveis problemas e testes pelos usuários. Workshops: stakeholders reúnem-se e discutem o projecto. Testes: obrigado em todas as iterações = boa qualidade

Referências Bibliográficas DSDM Consortium. Delivering Aginle Business Solution on Time. [Online]. Disponível em http://www.dsdm.org. Acesso em 18.09.2009. [Flowler, 2003] Fowler, Martin. The New Methodology. [Online]. Disponível em http://www.martinfowler.com/articles/newMethodology.html. Acesso em 07.09/2009 CIN/UFPE Márcio Amorim / Milton Campos

Tradicionais x Ágeis

... “Resultados frequentes, tangíveis e funcionais”. Considerações Finais Processos Ágeis ... ... “Resultados frequentes, tangíveis e funcionais”. CIN/UFPE Márcio Amorim / Milton Campos

Processos Ágeis de Desenvolvimento de Software Obrigado! Márcio Amorim mkamorim@gmail.com Milton Campos miltoncampospe@gmail.com PADS Processos Ágeis de Desenvolvimento de Software