PGP - Aula T 4 Modelos Ágeis

PGP - Aula T 4

Modelos Ágeis

5 - Outubro - 2015

Carlos Duarte, FCUL, Departamento de Informática

Revisão dos principais

modelos tradicionais

Modelo em cascata

Communication Planning Modeling Construction Deployment analysis design _code test project initiation

requirement gathering _estimating scheduling tracking delivery support feedback

Modelo incremental

Modelos evolutivos:


Modelo em Espiral

communication planning modeling construction deployment delivery feedback start analysis design code test estimation scheduling risk analysis

Processo Unificado

software increment Release Inception Elaboration construction transition production

Que modelo usar?

• _{Projeto caracterizado por}

• _{Requisitos sobre funcionalidades core estáveis} • _{Requisitos sobre outras funcionalidades}

indeterminados

• _{Prazos apertados}

Sumário e Referências

• _Sumário

• _{Modelos ágeis de processos de}

desenvolvimento de software

• Referências

Cada vez mais o desenvolvimento de software é caracterizado pela mudança

• _requisitos • _mercados • _aplicações • _equipas • _tecnologia

Manifesto para o

desenvolvimento Ágil de software

• _{“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.”

O que é a “Agilidade”

• Resposta efectiva às alterações (rápida e

adaptativa)

• Comunicação efectiva com todos os

stakeholders

• _{Cliente faz parte da equipa}

• _{Organização das equipas de forma a que}

controlem o trabalho realizado Resultando em

• _{Entrega rápida e incremental do software}

Pressupostos para um

processo ágil

• _{É difícil prever quais os requisitos que vão mudar e}

como vão evoluir as prioridades do cliente

• Para vários tipos de software o design e a

construção são atividades interligadas (devem ser feitas consecutivamente para que os modelos de design possam ser validados)

• _{Análise, desenho e construção não são tão}

previsíveis como gostaríamos

Gerir imprevisibilidade

Gerir imprevisibilidade

Imprevisibilidade Adaptável Obriga a poder mudar rapidamente as condições do projeto Incrementalmente Para que haja

progresso e não apenas adaptação Feedback Protótipos funcionais permitem obter precisa de

Processo Ágil

• _{É impulsionado por descrições do cliente sobre o}

que é pretendido

• _{Reconhece que os planos têm “vida-curta”} • _{O software é desenvolvido iterativamente com}

ênfase nas actividades de construção

• Entrega de múltiplos “incrementos de software” • _{Adaptação à medida que as alterações ocorrem}

Princípios de Agilidade

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a

couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the

environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face–to–face conversation.

Princípios de Agilidade

7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The

sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10.Simplicity – the art of maximizing the amount of work not done – is essential.

11.The best architectures, requirements, and designs emerge from self–organizing teams.

12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Extreme Programming

(XP)

Extreme Programming (XP)

• _{Processo ágil mais usado} • _{Proposto por Kent Beck}

• _{Paradigma de desenvolvimento preferido:}

object-oriented

• _{4 atividades: planning, design, coding, testing}

Extreme Programming (XP)

unit test continuous integration acceptance testing pair programming Release user stories values

acceptance test criteria iteration plan simple design CRC cards spike solutions prototypes refactoring software increment project velocity computed

Extreme Programming (XP)

• _{XP Planning}

• _{Begins with the creation of “user stories”}

Extreme Programming (XP)

• _{User stories}

• _{descrevem outputs, características e}

funcionalidades do software a construir

• cada história é escrita pelo cliente e colocada

num cartão

• _{a cada história é atribuído um valor (i.e. a}

Extreme Programming (XP)

• _{XP Planning}

• _{Begins with the creation of “user stories”}

• Agile team assesses each story and assigns a cost • Stories are grouped to for a deliverable increment

• _{A commitment is made on delivery date}

• _{After the first increment “project velocity” is used to}

help define subsequent delivery dates for other increments

Extreme Programming (XP)

• _{A qualquer momento o cliente pode} • _{adicionar histórias}

• _{mudar o valor de uma história existente} • _{dividir histórias}

• _{eliminar histórias}

Extreme Programming (XP)

• _{XP Design}

• _{Follows the KIS principle}

• Encourage the use of CRC cards

• _{For difficult design problems, suggests the}

creation of “spike solutions”—a design prototype

• _{Encourages “refactoring”—an iterative refinement}

of the internal program design

Extreme Programming (XP)

• _{CRC cards}

(Class-Responsibility-Collaborator)

• _{Forma de identificar e organizar as}

classes relevantes para o sistema

• _{Cada cartão tem 3 secções} • _Nome

• _{Responsabilidades - atributos e}

operações relevantes para a classe

• _{Colaboradores - as classes que}

têm de fornecer informação para que esta classe possa cumprir as suas responsabilidades Class: Description: Responsibility: Collaborator: Class: Description: Responsibility: Collaborator: Class: Description: Responsibility: Collaborator: Class: FloorPlan Description: Responsibility: Collaborator:

incorporates walls, doors and windows shows position of video cameras defines floor plan name/type manages floor plan positioning scales floor plan for display scales floor plan for display

Wall Camera

Extreme Programming (XP)

• _{XP Coding}

• _{Recommends the construction of a unit test for}

a story before coding commences

• _{Encourages “pair programming”}

• _{Real-time problem solving and quality}

assurance

Extreme Programming (XP)

• _{XP Testing}

• _{All unit tests are executed daily}

• _{“Acceptance tests” are defined by the customer}

and executed to assess customer visible functionality

Extreme Programming (XP)

• _{Papéis dos membros da equipa} • _Tracker

• _{circula e pergunta aos programadores como}

vão, escuta as respostas e toma ações em função das respostas

• ações incluem sugerir uma sessão de CRC,

marcar uma reunião com o Customer, pedir ajuda ao Coach ou a outro Programmer

Extreme Programming (XP)

• Papéis dos membros da equipa

• _Customer

• _{escreve e explica (e decide sobre) as User}

Stories

• _{especifica Testes Funcionais}

• _{marca as prioridades}

Extreme Programming (XP)

• _{Papéis dos membros da equipa}

• _{Programmer (extreme programmer)} • estima custos as stories

• define tarefas de desenvolvimento

• _{estima duração das stories e das tarefas} • _{implementa stories}

• _{implementa testes unitários}

Extreme Programming (XP)

• Papéis dos membros da equipa

• _Tester

• _{implementa e executa testes funcionais}

• _{(testes unitários são feitos pelos Programmers)}

• recolhe resultados dos testes

• _{garante que as pessoas sabem quando os}

Extreme Programming (XP)

• _{Papéis dos membros da equipa}

• _Coach

• _{marca reuniões (e.g. iteration plan, commitment schedule)}

• _{gere as reuniões}

• _{regista os resultados das reuniões}

• _{coordena-se com o Tracker}

• _{é o mentor da equipa}

Scrum

• Proposto por Schwaber e Beedle

• 5 atividades: requirements, analysis, design,

evolution, delivery

• _{Em cada atividade o trabalho é desenvolvido em}

vários “sprints”

• _{O número de sprints de cada atividade depende}

da complexidade e tamanho do projeto

Scrum

• _Backlog

• _{lista, ordenada por prioridade, dos requisitos do}

cliente

• podem ser adicionados itens ao backlog a qualquer

momento

• _{o “gestor de projeto” avalia o backlog e ordena as}

prioridades sempre que necessário

• product backlog + sprint backlog

Scrum

• Sprints

• unidades de trabalho necessárias para

completar um item do backlog que devem caber dentro de um período pré-definido (time-box) - tipicamente 2 semanas

• _{não são introduzidas mudanças no sprint}

Scrum

• _{Scrum meetings}

• _{reuniões diárias curtas, tipicamente de 15 minutos em}

pé

• 3 questões devem ser respondidas por todos os

elementos

• _{o que fizeste desde a última reunião?} • _{que obstáculos enfrentas?}

• _{o que pensas conseguir fazer até à próxima reunião?}

Scrum

• _Demos

• _{entregar o incremento ao cliente de forma a que}

este possa ser demonstrado e avaliado

• a demo não tem de incluir todas as

funcionalidades do produto, mas apenas

Scrum

• _{Papéis dos membros da equipa}

• _{Product owner}

• _{partilha a visão do produto}

• _{ordena por prioridade as user stories a construir}

• _{toma as decisões chave}

• _{mantém o backlog}

• _{assegura a comunicação entre stakeholders}

• _{gerir as expetativas do cliente e o orçamento}

• _{assegura a qualidade do produto}

• _{pede melhorias quando necessário}

Scrum

• _{Papéis dos membros da equipa} • Scrum master

• _{responsável por resolver qualquer problema}

que a equipa enfrente durante o desenvolvimento

• _{deve criar e manter as melhores condições de}

trabalho para a equipa

Scrum

• Papéis dos membros da equipa • _{Scrum development team}

• equipa multi-disciplinar responsável por

desenvolver o produto

• _{programadores, analistas, testers, etc.} • _{trabalham em conjunto}

• responsáveis por identificar a complexidade

das tarefas e estimar esforço para estas

Scrum

Outros modelos

Dynamic Systems

Development Method

• _{Princípios do DSDM}

• _{Envolvimento ativo dos utilizadores é imperativo}

• _{As equipas devem poder tomar decisões}

• _{O foco é na entrega frequente de produtos}

• _{Desenvolvimento iterativo e incremental é necessário para}

convergir para uma solução

• _{Todas as mudanças feitas são reversíveis}

Dynamic Systems

Development Method

• _{Adaptação da regra de Pareto}

• _{80% da aplicação pode ser entregue em 20% do}

tempo que demoraria a entregar 100% da aplicação

• Corolário DSDM: em cada iteração faz-se o

trabalho suficiente para permitir a passagem à próxima iteração

Dynamic Systems

Development Method

• _Etapas

• _{Feasibility study - estabelece os requisitos de}

negócio e restrições básicos

• Business study - identifica os requisitos

funcionais e de informação

• _{A partir daqui há ciclos iterativos com as}

Dynamic Systems

Development Method

• _Etapas

• _{Functional model iteration}

• _{produção de protótipos incrementais que}

demonstram funcionalidades

• recolha de requisitos a partir do feedback

recolhido

• _{os protótipos não se pretendem descartáveis}

Dynamic Systems

Development Method

• Etapas

• Design and build iteration

• garante que os protótipos construídos na fase

anterior têm valia operacional

• _{pode ocorrer paralelamente à fase anterior} • _{Implementation}

• _{coloca o último incremento no ambiente operacional} • _{mudanças podem ser requisitadas quando se}

Agile Modeling

• _{Agile Modeling procura aplicar os princípios da agilidade à tarefa}

de modelação

• _Princípios

• _{Ter um objetivo para os modelos}

• _{e.g. comunicar ao cliente, entender melhor um aspeto do}

software

• _{torna mais fácil identificar a notação e o nível de detalhe a}

empregar

• Usar múltiplos modelos

• _{cada modelo deve apresentar uma perspectiva diferente do}

sistema

• só se devem usar aqueles que produzem valor adicional

Agile Modeling

• Princípios

• Levar pouca bagagem

• à medida que o trabalho evolui manter apenas os modelos que oferecem valor a longo-prazo e descartar os outros

• O conteúdo é mais importante que a apresentação

• a modelação deve fornecer informação e isso é mais importante que a correção sintática

• Conhecer os modelos e ferramentas para os criar

• vantagens e desvantagens de cada um

• Adaptar

• a aproximação de modelação seguida deve ser adaptada às necessidades da equipa

Agile Unified Process

• _Filosofia

• _{“Serial in the large”} • _{“Iterative in the small”}

• _{Segue as atividades clássicas do processo}

unificado, mas em cada atividade a equipa segue uma aproximação iterativa ágil

Agile Unified Process

• _{Cada iteração tem as seguintes atividades:}

• _Modelação

• _{representação UML do negócio e do domínio do}

problema

• _{modelos devem ser apenas o necessário}

• _{Implementação}

• _{os modelos são transformados em código}

• _Teste

Agile Unified Process

• _{Cada iteração tem as seguintes atividades:} • Deployment

• _{entrega de incremento}

• _{recolha de feedback dos utilizadores finais} • _{Configuration and project management}

• _{gestão de mudanças; gestão de risco; controlo do}

progresso; coordenação das atividades da equipa

• _{Environment management}

• _{coordenação da infra-estrutura de apoio ao processo e}

à equipa (e.g. ferramentas, standards, etc.)

Seleção do Modelo de

Processo

Seleção do Modelo de

Processo

Sequencial Iterativa

Requisitos Estáveis Instáveis ou pouco

entendidos

Desenho Familiar e repetível Complexo e desafiante

Equipa Conhece o contexto Estranha ao contexto

Risco Reduzido Elevado

Previsibilidade Importante Negligenciável

Alterações Caras Baratas

Modelos iterativos

Próxima aula