Corso di Ingegneria del Softwareingsoft1/Lezioni2008-2009/... · Test first development An...

Corso di Ingegneria del Software

Paolo Bottoni

Blocco 3: Sviluppo rapido e metodi agili

Lucidi tradotti e adattati a partire dalla versione in inglese presente a http://iansommerville.com/software-engineering-book/slides/

Blocco3AgileIngegneria del Software 2

Obiettivi

• Discutere essenza di metodi di sviluppo agili

• Discutere metodi di gestione di processi agili

Blocco3Agile 3

Sviluppo rapido di software

• Ambienti in rapido cambiamento, organizzazioni di

fronte a nuove opportunità e concorrenza

• Richiesta nuovo software

• Sviluppo e consegna rapidi spesso requisito critico

• Qualità inferiore accettabile se possibile consegna

rapida di funzionalità essenziale

Ingegneria del Software

Blocco3Agile 4

Applicabilità

• Ambiente in cambiamento

– Impossibile arrivare a insieme di requisiti di sistema

stabile e coerente

• Modello a cascata non praticabile

• Approccio basato su specifica e consegna

iterative solo modo per consegna rapida


Blocco3Agile 5

Metodi agili

• Insoddisfazione con sovraccarico connesso a

metodi basati su piano

– Focalizzazione su codice e non su progetto

– Approccio iterativo a sviluppo software

– Consegna rapida software funzionante

– Evoluzione software in base a evoluzione requisiti

• Meglio adattati a sistemi organizzativi medio-

piccoli o a prodotti per PC


Agile manifesto

• 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

Ingegneria del Software 6Blocco3Agile

Sviluppo guidato da piano o agile I


Sviluppo guidato da piano o agile II

• Sviluppo guidato da piano

– Identifica diversi stadi di sviluppo

• Identifica in anticipo prodotti dei diversi stadi

– Non necessariamente modello a cascata

• Possibile sviluppo incrementale guidato da piano

– Iterazione entro specifiche attività

• Sviluppo agile

– Specifica, progetto, implementazione e validazione

interfogliate. Prodotti di processo di sviluppo negoziati

durante processo stesso


Blocco3Agile 9

Principi di metodi agili

Principio Descrizione

Coinvolgimento cliente Il cliente dovrebbe essere strettamente coinvolto lungo tutto il processo di sviluppo. Il suo ruolo è di fornire e prioritizzare nuovi requisiti di sistema e valuatare le iterazioni del sistema.

Consegna incrementale Il software è sviluppato in incrementi, con il cliente che specifica quali requisiti includere in ogni incremento.

Persone, non processi Le capacità del gruppo di sviluppo dovrebbero essere riconosciute e sfruttate. Il gruppo dovrebbe essere libero di sviluppare i propri metodi di lavoro senza processi prescrittivi.

Abbracciare il cambiamento Attendersi che i requisiti di sistema cambieranno e progettare il sistema così che li possa includere.

Mantenere la semplicità Focalizzarsi sulla semplicità sia del software da sviluppare sia del processo di sviluppo usato. Dove possibile, lavorare attivamente per eliminare complessità dal sistema.


Blocco3Agile 10

Problemi con metodi agili

• Difficoltà mantenere interesse clienti in processo

• Coinvolgimento intenso– Membri gruppo possono non essere adatti

• Diversi interessi in gioco– Prioritizzazione cambiamenti può essere difficile

• Mantenimento semplicità richiede lavoro aggiuntivo

• Contratti possono essere problema– Comune ad altri approcci a sviluppo iterativo

• Più adatti per sviluppo nuovo software– Ma gran parte costi software legati a mantenimento

• Più adatti per piccole squadre localizzate


Applicabilità metodi agili

• Sviluppo prodotti medio-piccoli per vendita

– Tipico caso: applicazioni mobili

– Sviluppo di sistemi per cliente quando cliente si impegna

a coinvolgimento in processo di sviluppo.

– Poche regole esterne che possano influenzare software


Blocco3Agile 12

Programmazione estrema (XP)

• Approccio "estremo" a sviluppo iterativo– Nuove versioni costruite più volte per giorno

– Incrementi consegnati a clienti ogni due settimane

– Suite completa di test eseguita per ogni costruzione

– Costruzione accettata solo se supera intera suite


Decomporre storie

in compiti

Selezionare storie

utente per rilascioPianificare rilascio

Rilasciare il

softwareValutare il sistema

Sviluppare / integrare /

provare software

Blocco3Agile 13

Pratiche di programmazione estrema I

Incremental planning Requirements are recorded on Story Cards and the Stories to beincluded in a release are determined by the time available and

their relative priority. The developers break these Stories intodevelopment "tas ks" .

Small Releases The minimal useful set of functionality that provides business

value is developed first. Releases of the system are frequent andincrementally add functionality to the first release.

Simple Design Enough design is carried out to meet the current requirementsand no more.

Test first development An automated unit test framework is used to write tests for a newpiece of functionality before that functionality itself is

implemented.

Refactoring All developers are expected to refactor the code continuously as

soon as possible code improvements are found. This keeps thecode simple and maintainable.


Blocco3Agile 14

Pratiche di programmazione estrema II

Pair Programming Developers work in pairs, checking each other’s work and

providing the support to always do a good job.

Collective Ownership The pairs of developers work on all areas of the system, so that

no islands of expertise develop and all the developers own all the

code. Anyone can change anything.

Continuous Integration As soon as work on a task is complete it is integrated into the

whole system. After any such integration, all the unit tests in the

system must pass.

Sustainable pace Large amounts of over-time are not considered acceptable as the

net effect is often to reduce code quality and medium term

productivity

On-site Customer A representative of the end-user of the system (the Customer)

should be available full time for the use of the XP team. In an

extreme programming process, the customer is a member of the

development team and is responsible for bringing system

requirements to the team for implementation.


Blocco3Agile 15

Scenari di requisiti XP

• Requisiti utente espressi come scenari o storie

• Storie scritte su schede, squadra di sviluppo le

suddivide in compiti di implementazione

• Compiti base per stime schedulazione e costo

• Cliente sceglie storie da includere in prossimo

rilascio in base a priorità e stime schedulazione


Una storia da MentCare


Esempi di schede di compiti


Blocco3Agile 18

XP e cambiamento

• Principio generale di SE: progettare per mutamento – Razionalità spesa per anticipazione cambiamento

• riduce costi successivi in ciclo di vita

• XP prospettiva inversa:– Cambiamenti non affidabilmente anticipabili

• Invece: costante miglioramento codice (refactoring) – Rende cambiamenti più facili quando necessari

– Codice non necessariamente più efficiente


Blocco3Agile 19

Test in XP

• Sviluppo con test come prima cosa

• Sviluppo incrementale di test da scenari

• Coinvolgimento utenti in sviluppo e validazione test

• Infrastrutture automatizzate di test usate per

eseguire test di componente su ogni nuova release


Blocco3Agile 20

Descrizione di caso di test


Blocco3Agile 21

Sviluppo con test come prima cosa

• Scrivere test prima di codice– Chiarifica requisiti da implementare

• Test scritti come programmi piuttosto che dati – Possono essere eseguiti automaticamente

– Test include controllo di esecuzione corretta

• Tutti test nuovi e precedenti eseguiti automaticamente su ogni nuova funzionalità– Controlla nuova funzionalità non introduca errori


Problemi per testing

• Programmatori preferiscono programmare a

testare. Prendono scorciatoie, ad esempio non

scrivono test per ogni possibile eccezione

• Problemi scrittura incrementale test

– Per esempio in GUI, test unitari che seguono logica

di presentazione e flusso di lavoro fra schermi

• Difficile valutare completezza di insieme di test,

indipendentemente da loro numero

Blocco3Agile 22Ingegneria del Software

Blocco3Agile 23

Programmazione a coppie

• In XP, programmatori lavorano a coppie, sedendo

insieme per sviluppare codice

• Aiuta a sviluppare proprietà comune codice e diffonde

conoscenza in squadra

• Funziona come processo di revisione informale: ogni

linea di codice è vista da più persone

• Incoraggia refactoring: intero gruppo può beneficiarne

• Misure indicano produttività simile a quella di due

persone che lavorano indipendentemente


Scrum

• Metodo agile focalizzato su gestione sviluppo

iterativo piuttosto che su pratiche agili specifiche

• Tre fasi

– Pianificazione schematica: stabilisce obiettivi generali

progetto e definisce architettura software

– Serie di cicli di “sprint”, ogni ciclo sviluppa incremento

– Chiusura, rifinisce progetto, completa documentazione

(aiuti, manuali utente), valuta lezioni apprese


Scrum terminology I

Scrum term Definition

Development team A self-organizing group of software developers, which should be no more than

7 people. They are responsible for developing the software and other

essential project documents.

Potentially shippable

product increment

The software increment that is delivered from a sprint. The idea is that this

should be ‘potentially shippable’ which means that it is in a finished state and

no further work, such as testing, is needed to incorporate it into the final

product. In practice, this is not always achievable.

Product backlog This is a list of ‘to do’ items which the Scrum team must tackle. They may be

feature definitions for the software, software requirements, user stories or

descriptions of supplementary tasks that are needed, such as architecture

definition or user documentation.

Product owner An individual (or possibly a small group) whose job is to identify product

features or requirements, prioritize these for development and continuously

review the product backlog to ensure that the project continues to meet critical

business needs. The Product Owner can be a customer but might also be a

product manager in a software company or other stakeholder representative.


Scrum terminology II

Scrum term Definition

Scrum A daily meeting of the Scrum team that reviews progress and prioritizes

work to be done that day. Ideally, this should be a short face-to-face

meeting that includes the whole team.

ScrumMaster The ScrumMaster is responsible for ensuring that the Scrum process is

followed and guides the team in the effective use of Scrum. He or she is

responsible for interfacing with the rest of the company and for ensuring

that the Scrum team is not diverted by outside interference. The Scrum

developers are adamant that the ScrumMaster should not be thought of

as a project manager. Others, however, may not always find it easy to

see the difference.

Sprint A development iteration. Sprints are usually 2-4 weeks long.

Velocity An estimate of how much product backlog effort that a team can cover in

a single sprint. Understanding a team’s velocity helps them estimate

what can be covered in a sprint and provides a basis for measuring

improving performance.


Ciclo di sprint


Scrum

Ciclo di sprint in Scrum I

• Lunghezza fissata, normalmente 2-4 settimane

• Punto di partenza è backlog di prodotto

• Fase di selezione coinvolge intera squadra, si

lavora con cliente per selezionare caratteristiche e

funzionalità da backlog da sviluppare durante sprint


Ciclo di sprint in Scrum II

• Raggiunto accordo, auto-organizzazione squadra

• Squadra viene isolata da cliente e organizzazione,

comunicazioni tramite ‘Scrum master’

– Suo ruolo proteggere la squadra da distrazioni esterne

• Finito sprint, lavoro rivisto e presentato a

stakeholder


Lavoro di squadra

• Scrum master facilitatore, organizza incontri

giornalieri, mantiene backlog lavoro da svolgere,

registra decisioni, misura progresso, comunica con

clienti e direzione

• Scrum, brevi incontri quotidiani, team condivide

informazione, descrive progresso da incontro

precedente, problemi riscontrati, piano per giorno

– Ogni membro ha visione complessiva, se ci sono

problemi può ripianificare lavoro a breve scadenza


Benefici

• Prodotto decomposto in insieme di pezzi

– Gestibili e comprensibili

• Requisiti instabili non frenano progresso

• Squadra ha visibilità totale, migliora comunicazione

• Clienti vedono consegna puntuale incrementi,

ottengono informazione su funzionamento

• Si stabilisce fiducia fra clienti e sviluppatori,

creazione cultura positiva verso successo progetto


Scrum distribuito


Aumento di scala per metodi agili

• ‘Scaling up’, uso di metodi agili per sviluppo di

grandi sistemi, non adatti a piccola squadra

• ‘Scaling out’, introduzione di metodi agili in grande

organizzazione con anni di esperienza

• Fondamentali da mantenere:

– Pianificazione flessibile, rilasci frequenti, integrazione

continua, sviluppo guidato da test, buona comunicazione


Aspetti contrattuali

• Contratti per sistemi custom in genere basati

su specifica di cosa deve essere implementato

• Questo impedisce alternanza di specifica e

sviluppo tipica di sviluppo agile

• Occorre contratto che paga in base a tempo

sviluppatore e non in base a funzionalità

– Visto come rischio da dipartimenti legali, non è

garantito quanto verrà consegnato


Manutenzione software

• Due questioni fondamentali

– Sistemi sviluppati con approccio agile sono

manutenibili, vista che documentazione è minima?

– Metodi agili possono essere usati efficacemente per far

evolvere sistema in risposta a richieste cliente?

• Problemi se squadra originale dispersa


Manutenzione agile

• Problemi

– Mancanza documentazione su prodotto

– Mantenimento impegno clienti

– Mantenimento continuità squadra sviluppo

• Squadra conosce e capisce cosa va fatto

• Problema per sistemi di lunga durata


Metodi agili e metodi basati su piano

• Molti processi includono elementi di entrambi

• Equilibrio dipende da:

– Specifica di dettaglio e progetto prima di

implementazione necessari?

– Strategia di consegna incrementale con valutazione

reazioni eventi realistica?

– Quanto è grande sistema da sviluppare?


Fattori di valutazione


Take away

• Metodi agili centrati su codice da produrre

• NON SIGNIFICA programmare senza visione

• Disciplina per mantenere progetto focalizzato

Blocco3AgileIngegneria del Software 39

Corso di Ingegneria del Softwareingsoft1/Lezioni2008-2009/... · Test first development An...

Documents

Transcript of Corso di Ingegneria del Softwareingsoft1/Lezioni2008-2009/... · Test first development An...