Metodologias Ágeis de Desenvolvimento de Software

Metodologias Ágeis de

Desenvolvimento de Software

Ademar Aguiar www.fe.up.pt/~aaguiar [email protected]

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

• 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

• 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