Metodologias Ágeis de
Desenvolvimento de Software
Ademar Aguiar www.fe.up.pt/~aaguiar ademar.aguiar@fe.up.pt
Projectos de Software
Possuem quatro variáveis de controlo
• Custo • Tempo • Qualidade
• Âmbito (da Funcionalidade)
Não é possível fixar o valor de todas as variáveis
simultaneamente
Processos
Desafio• Garantir “elevada qualidade” do produto desenvolvido • Alcançar “elevada produtividade” de desenvolvimento
• Possibilitar "boa previsibilidade" dos resultados do processo.
Componentes: who? what? when? why? how?
• Papéis • Artefactos • Actividades
• Técnicas, práticas e ferramentas
Meios e Fins
• Sugerem práticas por forma a melhorar as capacidades da equipa • Introduzem formalidades para melhorar a disciplina da equipa
• Obrigam a documentar para melhorar a comunicação e o conhecimento da equipa
Processos Rígidos
Processos “rígidos” (“heavyweight”), sustentados em muita
documentação e burocracia.
São muito preventivos, tentando evitar situações dispendiosas em
vez de as optimizar.
As medidas para evitar estas situações dispendiosas são muitas
vezes mais caras do que os problemas originais.
Requisitos exaustivamente analisados.
Procura e eliminação de erros antes do seu aparecimento no
código.
Dispendiosos meios para avaliar e monitorizar o processo em si. Elaboração, análise e verificação de modelos de forma bastante
extensiva.
Os custos de alterações/erros
Project Phase
Solução tradicional
Tentar puxar as alterações o mais possível para o início do
projecto.
Project Phase
Consequências
As medidas introduzidas aumentam
globalmente os custos das alterações/erros.
Project Phase
O orçamento resiste à pressão...
O orçamento resiste à pressão e reduz os custos à custa de
restrições nos recursos humanos, o que faz aumentar os prazos.
Project Phase
Problemas
Pouco feedback• Fraca compreensão de outras disciplinas de engenharia mais maduras.
• Tratam a engenharia como um processo metódico, perfeitamente replicável. • Resultado: recomenda elaboração gradual com feedback limitado para fases
de desenvolvimento iniciais; nos processos iterativos, este feedback é realizado em cada iteração.
Sobre-engenharia
• Fraca analogia com outras disciplinas de engenharia.
• Encaram a codificação como algo análogo a construção ou manufactura, actividades em que se evita construir ou produzir algo sem ter confiança no seu desenho (porque esses passos são muito dispendiosos).
• Resultado: recomendam outros passos dispendiosos, incluindo modelos muito detalhados, análise de modelos, e inspecção cuidadosa para detectar erros antes da fase de codificação.
Processos Ágeis
Processos simples, flexíveis (“lightweight”), sustentados no
conhecimento tácito da equipa,
Lidam muito facilmente com a mudança.
Usam outras formas para baixar os custos das alterações/erros. Usam formas económicas de evitar erros.
Reduzem o custo global de desenvolvimento.
Na prática, engenharia envolve criatividade, tentativa-e-erro,
iteratividade, experimentação e prototipagem.
Os processos ágeis incorporam estes aspectos com múltiplos
ciclos de feedback fortemente interrelacionados a vários níveis de escala.
Processos Disciplinados vs Ágeis
Ambos têm vantagens e desvantagens.
Deve-se utilizar o processo mais simples capaz de garantir o
sucesso do projecto, tendo em consideração os riscos associados aos requisitos, equipa, cliente, produto, etc.
“The Agile Manifesto – I”
We are uncovering better ways of developing software by doing it and helping others to 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.
“The Agile Manifesto – II”
Our highest priority is to satisfy the customer
through early and continuous delivery of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work
“The Agile Manifesto – III”
Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying
information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a constant pace indefinitely.
“The Agile Manifesto – IV”
Continuous attention to technical excellence and good
design enhances agility.
Simplicity – the art of maximizing the amount of work not
done – is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior accordingly.
Exemplos de processos
Adaptive Software Development (ASD) Agile Modeling
Crystal methods
Dynamic System Development Methodology (DSDM) eXtreme Programming (XP)
Feature Driven Development Lean Development
Scrum
Open source software development.
(LEIC|MEI)/MADS
“Metodologias Ágeis de
Pré-requisitos
Mínimos
• Conhecimentos de engenharia de software • Experiência de desenvolvimento de software
Preferenciais
• Interesse em melhorar a produtividade de equipas de desenvolvimento de software
Objectivos
Desenvolver as capacidades mínimas e adquir os conhecimentos fundamentais
necessários para autonomamente iniciarem desenvolvimento ágil de software.
Aprender o essencial sobre métodos ágeis, a sua filosofia, os valores, a sua necessidade
e aplicabilidade, e os desafios e oportunidades que suscitam nas pessoas e organizações que desenvolvem software.
Dotar os participantes com conhecimentos e experiência prática sobre as práticas de
desenvolvimento ágil de software:
• planeamento de iterações, testes unitários, refactoring, pattern-based design, autoria colectiva de código, programação em pares, integração contínua
Dar a conhecer algumas das variantes mais conhecidas.
Apreensão dos conhecimentos primordialmente através da sua aplicação prática num
caso de estudo real a desenvolver ao longo do semestre, exclusivamente nas aulas.
Os participantes aprenderão a trabalhar em equipa, a integrar outros intervenientes do
projecto em decisões de desenho e planeamento, e a delegar, negociar e rever estas decisões em grupo.
Utilizar um ambiente de desenvolvimento integrado (IDE) que suporta e incentiva o
Componentes da disciplina
Aulas
• 14 aulas x 3 horas = 42 horas
• Breve apresentação de conhecimentos teóricos
- Reuniões de projecto - Reuniões “Stand-up”
• Desenvolvimento ágil de um projecto (1-2 equipas)
- Instalações: sala de aula
- Programação: em pares e exclusivamente nas aulas - Desenvolvimento “contra-o-tempo”: o tempo da aula
- Requisitos vagos e em mudança: o cliente tem direito a mudar de ideias... - Entregas frequentes: semanais? quinzenais?
- Profissionalismo elevado: um-por-todos e todos-por-um - Maximizar a satisfação do cliente
Sessões de atendimento
• 13 sessões x 3 horas = 39 horas
• Especialmente para preparação das iterações
Avaliação
Avaliação distribuída com exame final. Componentes de Avaliação.
• 6 questões teóricas para desenvolvimento individual, até 1 página A4, fora de aulas e avaliação qualitativa “Satisfaz/Não satisfaz”. • 1 teste individual com consulta, duração de 120 minutos, 5
questões, 3 das quais “similares” às questões propostas.
• 1 projecto de desenvolvimento, semestral em grupo, avaliado
globalmente e semanalmente com base no seu valor para o cliente. • Avaliação individual pelos docentes com base no profissionalismo
demonstrado durante o projecto (estimado/realizado) e a qualidade das respostas às questões.
Nota Final
Bibliografia
Extreme Programming Explained by Kent Beck, Addison-Wesley Pub Co; 1st edition
(October 5, 1999), ISBN:0201616416
Extreme Programming Installed, by Ron Jeffries, Ann Anderson, Chet Hendrickson,
Ronald E. Jeffries, Addison-Wesley Professional; 1st edition (October 13, 2000), ISBN:0201708426
Planning Extreme Programming, by Kent Beck, Martin Fowler, Addison-Wesley
Professional; 1st edition (October 13, 2000), ISBN:0201710919
Refactoring, by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts,
Addison-Wesley Pub Co; 1st edition (June 28, 1999), ISBN:0201485672
Adaptive Software Development: A Collaborative Approach to Managing Complex
Systems, by James A. Highsmith III, Dorset House Publishing Company, Incorporated
(December 1, 1999), ISBN:0932633404
Agile Software Development, by Alistair Cockburn, Addison-Wesley Pub Co; 1st edition
(December 15, 2001), ISBN:0201699699
Agile Software Development, Principles, Patterns, and Practices, by Robert C. Martin,
Prentice Hall; 1st edition (October 15, 2002), ISBN:0135974445
Test Driven Development, by Kent Beck, Addison-Wesley Professional; 1st edition
(November 8, 2002), ISBN:0321146530