Introduction to Agile Methodology with a focus on XP, Scrum and Kanban

1. agile engineering
Ciro Donato Caiazzo
Senior Developer Consultant
@CyrusD87
Bologna, 29/6/2015

2. Agenda
 Agile engineering
 Modello Waterfall vs XP
 User stories
 Vision e Product canvas
 Framework Agile
 Scrum
 Pair Programming
 TDD
 Refactoring
 Collective code ownership
 Source control system
 Continuous integration

3. Agile Engineering
Motivazione

4. Modello Waterfall
REQUIREMENTS
ANALYSIS
DESIGN
IMPLEMENTATION
TESTING
PRODUCTION

5. Modello Waterfall - Caratteristiche
 Il processo di sviluppo è sequenziale
 Si completa una fase prima di passare alla successiva
 L’ output di una fase è usato come input per la fase successiva
 In ogni fase del processo viene prodotta documentazione

6. Modello Waterfall – Mal di pancia
 I Requisiti spesso sono astratti e possono essere
interpretati in modo differente
 Nessun valore per il cliente/utente prima della fase
‘Production’
 Feedback solo alla fine del progetto
 Il costo di un cambiamento è molto alto
 ….

7. Modello Waterfall
Il costo di un cambiamento cresce in modo esponenziale

8. Manifesto Agile
«Scopriamo modi migliori di sviluppare il software facendolo
ed aiutando gli altri a farlo. Da queste esperienze, siamo
giunti a privilegiare i seguenti elementi :
Gli individui e le loro interazioni rispetto ai processi ed agli strumenti
Software funzionante rispetto ad un’ampia documentazione
La collaborazione col cliente rispetto alla negoziazione dei contratti
La pronta risposta ai cambiamenti rispetto all’esecuzione di un piano
Ovvero, anche se attribuiamo un valore agli elementi riportati a destra, riteniamo più
importanti quelli a sinistra»
Kent Beck et al. (2001).
manifesto for agile software development

9. XP- eXtreme Programming
Un presupposto fondamentale di XP è che il costo di un cambiamento
nel software è pressoché costante nel tempo

10. «Un team Agile può diventare più veloce del
cliente»

11. XP- eXtreme Programming

12. XP Values - Communication
 La comunicazione tra i vari attori (clienti, developer, etc) è
fondamentale
 Tutti possono parlare con tutti
 XP enfatizza la comunicazione in molte delle sue pratiche (User
stories, Pair Programming, Daily stand-up meeting, Collective
ownership, etc)

13. XP Values - Simplicity
 Fai la cosa più semplice che possa funzionare
(DTSTTCPW) principle (conosciuto anche come KISS)
 Mantieni la descrizione formale il più semplice e chiara possibile

14. XP Values - Feedback
 Da parte del cliente
 I Test restituiscono un feedback sullo stato del sistema
 Quando il cliente scrive nuove user stories i developer forniscono
una stima per la realizzazione
 Una nuova release è prodotta ogni 2-3 settimane in modo tale che
il cliente possa dare un feedback

15. XP Values - Courage
 Coraggio nell’ accettare il feedback
 Coraggio nel buttare via il codice (prototipi, spike)
 Coraggio nel ri-fattorizzare l’ architettura del sistema

16. XP – User stories : 3C
 Descrizione ad alto livello di una funzionalità utile al
raggiungimento di un obiettivo di business.
User story = Card + Conversation + Confirmation

17. Card
Ogni user story si focalizza su
 chi è l’ utente – AS A;
 sul cosa vuole fare - I WANT
 qual è lo scopo - SO THAT
In un modo comprensibile sia al tecnico che al cliente.

18. Conversation
 Si discute la user story con il cliente e tutti i membri del team
(developer, designer, tester, ecc)
 Ci si focalizza bene su tutte e tre le componenti della storia (AS – I
WANT – SO THAT)
 Si fanno le domande per capire l’ obiettivo di business della storia
 Può accadere che l’ output della conversation sia di non
implementare la US poiché non genera valore all’ utente finale
Conversation
Clienti
(Esperti del dominio)
Team
(Esperti tecnici)

19. Confirmation
Una volta che la Card è stata validata occorrono dei criteri per
decidere come verificarla… Acceptance Criteria
Esempio

20. Confirmation
Se il bancomat accetta la carta e il titolare ha i fondi necessari allora
l’ operazione di prelievo si conclude con esito positivo.
Criterio di accettazione troppo vago!!

21. Confirmation
Utilizzo di esempi concreti: Lista di Scenari
http://dannorth.net/whats-in-a-story/

22. Agile : Dall’ idea di prodotto alla realizzazione

23. Dall’ idea di prodotto alla realizzazione
product idea Capture and validate
initial assumption
Define the business
model
Define the product
features
http://www.agilereloaded.it/2013/08/26/product-canvas/

24. Vision canvas – initial assumptions

25. Product canvas - Define the product features

26. Framework Agile

27. Agile Umbrella
Agile
Scrum
Kanban
Crystal
XP
DSDM
FDD
RUP
… and few more

28. Scrum e Kanban
Scrum Kanban
Prescrive iterazioni timeboxed Le iterazioni timeboxed sono opzionali
Il team si impegna a realizzare una quantità
di lavoro specifico nel corso dell'iterazione
corrente.
L’ impegno è opzionale
Il WIP viene limitato indirettamente (per
sprint) .
Il WIP è limitato direttamente (per stato di
workflow). (WIP LIMIT)
Vengono prescritte le stime Le stime sono opzionali.
Impossibile aggiungere elementi a iterazione
in corso.
È possibile aggiungere nuovi item ogni
qualvolta ci sia capacità disponibile
Uno sprint backlog è di proprietà di uno
specifico team.
Una kanban board può essere condivisa tra
più team individui.

29. Scrum e Kanban
Scrum Kanban
Prescrive 3 ruoli (PO/SM/Team) Non prescrive nessun ruolo.
Una Scrum board viene resettata ad ogni
sprint.
Una Kanban board è persistente.
Prescrive un product backlog con priorità. La Priorità è opzionale..

30. Scrum e Kanban
 Scrum più adatto allo sviluppo di un nuovo prodotto
 Kanban più appropriato per la gestione dei progetti

31. Scrum

32. Scrum – Ruoli
Product owner
Team
Scrum master

33. Scrum – Product Owner
 Responsabile per il Return of Investment (ROI)
 Definisce la Vision di prodotto e quindi la roadmap
di prodotto
 Stabilisce le priorità
 E’ focalizzato più sul «cosa» che sul «come»

34. Scrum – Team
 E’ un gruppo di 4-9 persone (small team)
 Può essere composto non solo da developer ma anche da
designer, digital strategist, ecc
 Ha l’ obiettivo di implementare il prodotto e realizza una
«potentially shippable product increment» alla fine di ogni
sprint
 Collaborazione
(Il team dovrebbe lavorare nella stessa stanza per migliorare la
collaborazione)
 Self-organizing

35. Scrum – Scrum master
 Non ha un ruolo di project manager
 Rimuove gli ostacoli e fornisce la guida del processo
 E’ un facilitatore tra il product owner e il team
http://scrummasterchecklist.org/

36. Scrum – Sprint
 Lo Sprint o «iterazione» è un unità di tempo di circa 2-4 settimane
 In uno Sprint vengono implementate una serie di features definite
nel Product Backlog
 Parte con uno Sprint planning meeting
 Termina con uno Sprint Review meeting

37. Scrum – Artifact
 Product backlog
 Sprint backlog
 Burndown

38. Scrum – Product backlog
 Lista di item da implementare
 Ordinato per priorità
 La priorità è stabilita dal Product Owner
 Tutte le entry sono stimate
 Viene aggiornato regolarmente
+
-

39. Scrum – Sprint backlog
 Contiene tutte le attività prese dal Product Backlog che dovranno
essere svolte durante lo Sprint corrente

40. Scrum – Burndown

41. Scrum – Board

42. Scrum – Board

43. Scrum – Meeting
SPRINT REVIEW
MEETING
DAILY SCRUM MEETING
SPRINT PLANNING
MEETING
SPRINT RETROSPECTIVE
MEETING

44. Scrum – Sprint planning meeting
 Ogni Sprint inizia con uno Sprint planning meeting
 Product Owner e Team decidono quali user stories implementare
nello sprint corrente => WHAT
 Se necessario le user stories possono essere divise in storie più
piccole in modo da poter essere completate nello sprint corrente
 Vengono definiti I task concreti per portare a termine le storie
scelte => HOW

45. Scrum – Daily (Stand-up) Scrum meeting
 E’ un breve incontro quotidiano (circa 15 minuti) da tenere all’
inizio della giornata lavorativa
 Ogni membro del team deve rispondere a tre domande:
 Cosa è stato fatto dall’ ultimo Daily Scrum meeting?
 Cosa verrà fatto fino al prossimo Daily Scrum meeting?
 Quali sono gli ostacoli/impedimenti al raggiungimento/completamento del
task?
 Ogni impedimento/preoccupazione deve essere fatta presente allo
Scrum Master che dovrà gestirla dopo il meeting

46. Scrum – Review meeting
 E’ un incontro molto informale (no presentazioni power point,
video, ecc )
 Meeting di condivisione delle user stories che sono state
completate (in accordo alla Definition of Done) nello sprint corrente
 Come? Demo delle nuove features
 Chi partecipa? Team, Product Owner, Scrum Master, Cliente altri…

47. Scrum – Retrospective meeting
 Segue l’ approccio “Inspect and Adapt”
 Obiettivo : Miglioramento continuo

48. Scrum – Release meeting
E’ una linea guida che serve a chiarire
 Aspettative
 Features che dovranno essere realizzate e quando
 Nell’ ambito di più sprint (di solito 2-3)

49. Pair Programming

50. Pair Programming
2 persone su un unico task e un un’
unica tastiera:
 Il “driver” scrive il codice
 Il “navigator” o “observer” aiuta
svolgendo un ruolo di
supervisione e di revisione
simultanea del codice

51. 2 persone fanno il lavoro di 1, perché?
 Due persone sono più efficienti di una
 Migliora la qualità del codice («Non mi è chiaro questo pezzo di
codice, lo miglioriamo?»
 Disciplina! («Ricorda che stiamo facendo TDD… scriviamo prima il
test»)
 Trasferimento di conoscenza e di competenze
 Non esiste l’ owner di un task
Tutto questo rispettando delle regole!!

52. Pair Programming - Regole
 Il “navigator” non deve distrarsi o peggio addormentarsi
 Il “driver” e il “navigator” dovrebbero invertire il ruolo
frequentemente
 Tutti devono fare pair con tutti (Il pair dovrebbe essere fatto
sempre con persone diverse, quando possibile)
 Ricordarsi di fare pausa
(Pomodoro Technique)

53. Test Driven Development
(Test Driven Design)

54. TDD - Procedura
1. Si parte dallo scrivere il test
2. Si fa in modo che il codice compili (barra rossa)
3. Si fa passare il test (barra verde)
4. Refactor (barra verde)
Expected ‘true’ but was ‘false’
Success
Success

55. TDD - Ciclo
RED
GREENREFACTOR
Da ripetere ogni 2-10
minuti

56. TDD - Test
UNIT
INTEGRATION
UI

57. TDD – FizzBuzz Game
Da 0 a 100
Se il numero è multiplo di 3, restituisci “Fizz”
Se è multiplo di 5, restituisci “Buzz”
Se è multiplo di 3 e 5, restituisci“FizzBuzz”
Altrimenti restituisci il numero!
0,1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz,
Buzz, 11, Fizz, 13, 14, FizzBuzz,
16, 17, Fizz, ..., 98, Fizz, Buzz

58. Refactoring

59. Refactoring
 Serve a migliorare in modo safe il design e la leggibilità del codice
 Non aggiunge/toglie funzionalità
 Quando va fatto?
Quando tutti i test vengono eseguiti con successo!
Success
Refactoring: Improving the Design of Existing Code
Martin Fowler - 1999

60. Code Smells
Sono debolezze di design che riducono la qualità del
software
«Code Smells are symptoms of poor design or
implementation choises»
[Martin Fowler]

61. Code Smells - Esempi
 Troppi commenti
 Codice duplicato, uguale o pressoché uguale, in diverse sezioni di
codice (viola il principio Don't Repeat Yourself).
 Metodo troppo lungo.
 Classe troppo grande.
 Lista di parametri troppo lunga (per metodi o funzioni).
 Feature envy[3] o data envy ("invidia dei dati"): una classe che usa
massicciamente i servizi o i dati di un'altra.
 …..

62. Collective Code Ownership

63. Collective Code Ownership
 Il codice non è di proprietà del singolo Developer ma è patrimonio
del team
 Se vi è la necessità di modificare qualcosa (scritta da qualcun altro)
la modifico, non bisogna chiedere l’ autorizzazione
 Se c’è la possibilità di migliorare il codice e quindi il design posso
farlo tranquillamente

64. Source Control System

65. Git
Git è un sistema software di controllo di versione distribuito, creato da
Linus Torvalds nel 2005. (da wikipedia)
https://git-scm.com/downloads
https://github.com/gitextensions/gitextensions

66. Git – Comandi di base
Consente di inizializzare un repository git in una directory esistente
git clone <url>
Consente di clonare il repository git posto all’ url passato come
parametro

67. Git – History
 Git lavora con un meccanismo di branch (Il branch di default è
master)
 Si avvale di history remote e locali (By default ORIGIN/MASTER)
 Consente di lavorare offline

68. Git – Commit
‘git clone’
‘git commit’

69. Git –Push
‘git push’

70. Git – Fetch
 Scenario 1
Situazione iniziale
‘git fetch’
‘git reset hard’ (su origin)

71. Git – Fetch
 Scenario 2
Situazione iniziale
‘git fetch’

72. Git – Merge
 Scenario 2
‘git merge’

73. Git – Rebase
 Scenario 2
‘git rebase’

74. GitFlow - Development

75. GitFlow - Release

76. Continuous integration

77. CI – Architettura

78. CI – Processo di base
Ad ogni commit
Se anche solo un test fallisce la build è marcata come red
Una release è potenzialmente rilasciabile ad ogni commit

79. CI – Motivazioni
 Efficienza
Posso automatizzare tutto (esecuzione test, creazione setup kit, ecc)
 Riproducibilità
L’ automazione riduce gli errori umani, versioning artifact e
tracciabilità
 Release
La mainline è sempre rilasciabile, riduzione tempi di creazione package
e rilasci
 Configurazioni multiple
Agent con OS, Browsers, Network, Database, ecc differenti

80. CI – Regole
 Il developer non può accedere alla macchina di Continuous
integration
 I package della release devono essere l’ output del processo di CI
(Non sono ammessi rilasci manuali con package creati dalla macchina
del developer)
 La macchina di CI è un ambiente incontaminato rispetto alla
macchina di un developer
(Il developer per sua natura sulla sua macchina installa di tutto)

81. CI – Build
 La Build è codice
 Non è statica ed evolve con l’ evolvere del progetto
 Deve entrare nel sistema di source control come il resto del codice

82. CI – Tools

83. CI –Anti-pattern
 Fragilità
 Fallimenti occasionali
 «Don’t touch that build» syndrome
 Interferenze
 Risorse condivise
 Limitazioni su build concorrenti
 Limitazioni su test concorrenti

84. CI –Anti-pattern
 Riproducibilità
 Lo script di build deve essere riproducibile anche sulla macchina del
developer
 Pochi feedback
 La build impiega troppo tempo

85. Esercitazione
 In gruppi creare il vision e product canvas di un nuovo
prodotto/servizio da lanciare sul mercato

86. Bibliografia
http://www.agilereloaded.it/2013/08/26/product-canvas/
http://www.businessmodelcanvas.it/bmc/business-model-canvas.html
http://www.romanpichler.com/blog/the-product-vision-board/
http://dannorth.net/whats-in-a-story/
http://www.ideato.it/technical-articles/user-stories-una-guida-pratica
http://www.infoq.com/resource/news/2010/01/kanban-scrum-
minibook/en/resources/KanbanAndScrum-
http://scrummasterchecklist.org/
Introduzione alle metodologie e pratiche agili by Ilias Bartolini
http://www.iprog.it/blog/utility/git-guida-rapida-software-backup/
Wikipedia
http://www.scrum-institute.org/

87. Grazie