Desenvolvimento Ágil de Software
Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento e entrega de maneira rápida são, portanto, o requisito mais crítico para o desenvolvimento de sistemas de software. Muitas empresas operam em um ambiente de mudanças rápidas, e por isso, muitas vezes, é praticamente impossível obter um conjunto completo de requisitos de software estável.
Métodos ágeis (Sommerville) Processos de desenvolvimento de software que planejam especificar completamente os requisitos e, em seguida, projetar, construir e testar o sistema não estão adaptados ao desenvolvimento rápido. Mudanças nos requisitos ou descoberta de problemas de requisitos, o projeto do sistema precisa ser refeito. Com a necessidade de desenvolvimento rápido e de processos capazes de lidar com mudanças de requisitos e a insatisfação com abordagens pesadas da engenharia de software levou um grande número de desenvolvedores a proporem na década de 1990, novos métodos ágeis.
Métodos ágeis (Sommerville) Métodos ágeis, universalmente, baseiamse em uma abordagem incremental para a especificação, o desenvolvimento e a entrega do software. Mais adequados ao desenvolvimento de aplicativos nos quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento.
Métodos ágeis (Sommerville) Entrega o software rapidamente aos clientes, em funcionamento. Podem propor alterações e novos requisitos a serem incluídos nas iterações posteriores do sistema. Têm como objetivo reduzir a burocracia do processo, evitando qualquer trabalho de valor duvidoso de longo prazo e qualquer documentação que provavelmente nunca será usada.
Manifesto Ágil
Métodos ágeis (Sommerville)
Mito
Desenvolvimento ágil e dirigido a planos (Sommerville) A maioria dos projetos de software inclui práticas das abordagens dirigidas a planos e ágil. Para optar por um equilíbrio entre as abordagens, é preciso responder algumas questões: 1- É importante ter uma especificação e um projeto muito detalhado antes de passar para a implementação? 2- É realista uma estratégia de entrega incremental em que você entrega o software aos clientes e rapidamente obtém um feedback? 3- Quão grande é o sistema que está em desenvolvimento? Entre outras questões em relação a equipe, ferramentas...
Principais Modelos extreme Programming Scrum FDD Lean Software Development Crystal Family (...)
extreme Programming Quando? Como?...
...o que é?
...programar ao extremo?
Práticas do XP (Pressman) Metáfora Requisitos são gravados em cartões de estória; Facilita a comunicação entre os interessados.
Prescrição de Medicamentos Kate é uma médica que deseja prescrever medicamentos para um paciente de uma clínica. O prontuário do paciente já está exibido em seu computador, assim, ela clica o campo medicação e pode selecionar medicação atual nova medicação ou formulário Se ela selecionar medicação atual, o sistema pede que ela verifique a dose. Se ela quiser mudar a dose, ela altera esta em seguida, confirma a prescrição. Se ela escolhe nova medicação o sistema assume que ela sabe qual medicação receitar...
Práticas do XP (Pressman) Projeto Simples Cada projeto é realizado para atender às necessidades atuais; O código deve ser o mais limpo possível; Pequenas Versões Entregas feitas através de pequenos releases de software funcionando; Fornece o valor do negócio;
Práticas do XP (Pressman) Refatoração os desenvolvedores devem melhorar o código constantemente; Remover redundâncias e duplicidades; Programação em Pares Os desenvolvedores trabalham em pares, checando mutuamente o trabalho realizado; Mesma máquina, mesmo mouse, mesmo monitor...
Práticas do XP (Sommerville) Propriedade coletiva do código Todos são responsáveis por todo o código e qualquer pessoa está autorizada a realizar mudanças. Padrão de Codificação O código é desenvolvido de acordo com um estilo e formato padrão; Ritmo sustentável Grandes quantidades de horas-extra não são consideradas aceitáveis; 40 horas por semana seria o ideal.
Práticas do XP (Pressman) Reuniões em Pé reuniões rápidas e diárias com a equipe, para discutir apenas o essencial; Cliente no local Um representante do usuário final do sistema deve estar o tempo todo disponível à equipe XP. Ele é um membro da equipe responsável por levar para equipe os requisitos de sistema.
Práticas do XP (Pressman) Desenvolvimento Orientado a Testes os testes tem uma estrutura unitário automatizado e são escritos antes mesmo das funcionalidades serem implementadas Integração Contínua O módulos são integrados o mais cedo possível. Após a integração, todos os testes de unidade do sistema devem ser realizados.
Práticas do XP (Pressman) Planejamento Incremental Requisitos são gravados em cartões de estórias e as estórias serão incluídas em um release. São priorizados para serem incluídos em determinada iteração.
Valores do XP (Pressman) Comunicação; Simplicidade; Feedback; Coragem; Respeito.
Scrum O nome é derivado de uma atividade em um jogo de Rugiby; É um framework de processo que possui técnicas variadas: papéis, artefatos, atividades... Está mais ligado a etapas de gestão do que com técnicas de desenvolvimento; Pode ser aplicado em qualquer contexto que se deseje resolver um problema com trabalho em equipe.
Scrum Características As equipes se auto-organizam; O produto que está se desenvolvendo evolui em uma série de sprints ; Não há prática de engenharia prescrita; Processo essencialmente gerencial
Scrum
Scrum - Artefatos Product Backlog Uma lista ordenada de tudo que é necessário no produto; Cada item deve ter sua prioridade; É replanejado (repriorizado) no início de cada Sprint.
Scrum - Artefatos Sprint Backlog Uma lista que a equipe se compromete a completar dentro de uma determinada Sprint; O itens são derivados a partir do Product Backlog; São considerados a prioridade que o cliente deu aos itens; Tempo e esforço estimados pela equipe para completar vários itens;
Scrum - Papéis Product Owner Define as funcionalidades do produto; Prioriza as funcionalidades de acordo com o valor para empresa; Aceita ou rejeita os resultados dos trabalhos.
Scrum - Papéis Team Contém de entre 5 a 9 pessoas; Multi-funcional Desenvolvedores, testadores... Dedicação Integral; Auto-organizável; Trocas de membro só na mudança de Sprints.
Scrum - Papéis Scrum Master Responsável pela aplicação dos valores e práticas do Scrum; Facilita resultados removendo obstáculos e interferências externas; Garante a plena funcionalidade e produtividade da equipe.
Scrum - Eventos Planejamento da Sprint selecionar itens do Product Backlog, e as tarefas são identificadas e estimadas; Reuniões Diárias Apenas membros da equipe, todos os dias, em pé durante 15 minutos; Revisão do Sprint Apresentação dos resultados obtidos; Todo o time participa; Analisa o produto.
Scrum - Eventos Retrospectiva da Sprint ocorre após a revisão da sprint e antes da próxima reunião de planejamento; Inspeciona como foi a última Sprint. Analisa o processo.
Feature Driven Development Por quem? Criado por Jeff de Luca e Peter Coad. Quando? 1977 em um projeto para um banco de Singapura. Como? procuravam algo para focar nas funcionalidades valiosas para o cliente; Algo mais estruturado para aplicar em equipes grandes (10 a 250 pessoas);
Feature Driven Development Papéis Project Manager o líder administrativo do projeto. Planeja orçamento, elabora relatórios e protege a equipe de distrações externas. Chief Architect Responsável pelo projeto geral do sistema; Tem a palavra técnica final sobre o software e sua arquitetura.
Feature Driven Development Papéis Development Manager Lidera as atividades diárias de desenvolvimento; Chief Programmers Programadores experientes; Lideram pequenas equipes de desenvolvedores individuais;
Feature Driven Development Papéis Class Owner Desenvolvedores individuais; Projetam, codificam, testam... Domain Experts Usuários, clientes, patrocinadores...
Feature Driven Development Processos
Metodologias ágeis Leitura do artigo para conhecer outras metodologias ágeis;