PGP - Aula T 4 Modelos Ágeis

Transcrição

1 PGP - Aula T 4 Modelos Ágeis 5 - Outubro Carlos Duarte, FCUL, Departamento de Informática Revisão dos principais modelos tradicionais

2 Modelo em cascata Communication project initiation requirement gathering Planning estimating scheduling tracking Modeling analysis design Construction code test Deployment delivery support feedback Modelo incremental

3 Modelos evolutivos: Modelo em Espiral communication planning estimation scheduling risk analysis start modeling analysis design deployment delivery feedback construction code test Processo Unificado Elabor atio n Inception Release software increment transition co nstr uction production

4 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 Pressman, capítulos 5, 10

5 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. Kent Beck et al. 2001

6 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 O custo da mudança

7 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 Obriga a poder mudar rapidamente as condições do projeto Para que haja progresso e não apenas adaptação Imprevisibilidade Adaptável Incrementalmente precisa de Protótipos funcionais permitem obter Feedback

8 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.

9 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)

10 Extreme Programming (XP) Processo ágil mais usado Proposto por Kent Beck Paradigma de desenvolvimento preferido: objectoriented 4 atividades: planning, design, coding, testing Extreme Programming (XP) user stories values acceptance test criteria iteration plan simple design CRC cards spike solutions prototypes refactoring pair programming Release software increment project velocity computed unit test continuous integration acceptance testing

11 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 prioridade)

12 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 A equipa modifica o planeamento em resposta

13 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: Class: Description: Class: Description: Class: FloorPlan Description: Responsibility: Description: Collaborator: Responsibility: Collaborator: Responsibility: Collaborator: Responsibility: Collaborator: defines floor plan name/type manages floor plan positioning scales floor plan for display scales floor plan for display incorporates walls, doors and windows shows position of video cameras Wall Camera

14 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

15 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 assiste às sessões de CRC

16 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 resultados dos testes pioram

17 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

18 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

19 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 backlog durante a sua execução

20 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 aquelas que estavam previstas para a time-box

21 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 facilitador + dinamizador

22 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 Papéis dos membros da equipa

23 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 Testes são integrados no ciclo de desenvolvimento

24 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 Etapas Dynamic Systems Development Method 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 seguintes fases:

25 Etapas Dynamic Systems Development Method 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 Etapas Dynamic Systems Development Method 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 operacionaliza o incremento

26 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

27 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 desenhar e executar testes (semelhante ao XP)

28 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

29 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 Modelo sequencial

30 Modelos iterativos Próxima aula Planeamento de projetos: conceitos, plano