Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #21252 > unrolled thread

Metodologie Agile

Back to article view | Back to it.comp.www.php

Contents

  Metodologie Agile Gerry <no-user@no-mail.it> - 2016-10-31 11:26 +0100
    Re: Metodologie Agile Alessandro Pellizzari <shuriken@amiran.it> - 2016-10-31 11:35 +0000
      Re: Metodologie Agile Gerry <no-user@no-mail.it> - 2016-10-31 16:12 +0100
        Re: Metodologie Agile Alessandro Pellizzari <shuriken@amiran.it> - 2016-10-31 17:27 +0000
          Re: Metodologie Agile Gerry <no-user@no-mail.it> - 2016-10-31 19:27 +0100
          Re: Metodologie Agile Gerry <no-user@no-mail.it> - 2016-10-31 19:34 +0100

#21252 — Metodologie Agile

Ciao,
premetto che abbiamo sempre lavorato su linguaggi tradizionali con la 
classica metodologia di progetto, "waterfall".
Un paio di noi hanno esperienza con la programmazione ad oggetti, in 
Delphi, ma il metodo di lavoro è sempre quello.

Stiamo impostando un progetto PHP per il quale entrerà a far parte un 
programmatore ed un altro paio andremo a formarli.
Questo e quelli che seguiranno sono progetti "Business Oriented".

A partire da questi, volevamo incominciare a documentare i progetti in 
UML ed approcciare una metodologia Agile.
Tra le tante, ci incuriosivano la xP, la Lean Software Development e la 
Scrum
Però, lette diverse pagine nel Web, la mia prima impressione è che 
possono aver senso per gruppi di lavoro di alcune decine di persone 
mentre possono essere una palla al piede per gruppi di lavoro 
estremamente ridotti.

Qualcuno di voi le utilizza? In che contesto? Utilizzate qualche 
strumento per la documentazione?

Grazie
Gerry

[toc] | [next] | [standalone]

#21253

On 31/10/2016 10:26, Gerry wrote:

> A partire da questi, volevamo incominciare a documentare i progetti in
> UML ed approcciare una metodologia Agile.

Penso di non aver mai fatto un diagramma UML in vita mia... :P

Come documentazione, poi, li trovo controproduttivi.

Fare un diagramma dell'architettura generale ha senso, ma dettagliare 
ogni classe sa tanto di waterfall e ben poco di agile.

> Tra le tante, ci incuriosivano la xP, la Lean Software Development e la
> Scrum
> Però, lette diverse pagine nel Web, la mia prima impressione è che
> possono aver senso per gruppi di lavoro di alcune decine di persone
> mentre possono essere una palla al piede per gruppi di lavoro
> estremamente ridotti.

È l'esatto contrario. Una metodologia agile funziona meglio con team 
piccoli (meno di 10 persone), e solitamente si consiglia di spezzare i 
team più grandi in team più piccoli, idealmente di 5-6 persone.

> Qualcuno di voi le utilizza? In che contesto? Utilizzate qualche
> strumento per la documentazione?

Bada bene che non sono un esperto, e onestamente non saprei dirti le 
differenze tra i 3 che citi.

Il succo dello sviluppo agile è che non devi mai programmare oltre 1-2 
settimane in anticipo. Puoi avere una visione generale oltre quel limite 
temporale, ma potresti cambiarla dopo le prime 2 settimane.

La parte più difficile è iniziare, sia perché non hai idea di quanto 
tempo possa servire per implementare una certa funzionalità (se non 
l'hai mai fatta prima), sia perché è difficile decidere un subset di 
caratteristiche da avere per la prima versione.

Noi, come "tool", usiamo il planning poker per decidere le stime, Jira 
per tracciare i task, uno spreadsheet condiviso su GoogleDocs per avere 
un diagramma di gantt, github per le code review.

Per la documentazione abbiamo un misto di docblock e README.md nelle 
cartelle di ogni componente per gli sviluppatori, e usiamo Confluence 
per documentazione più generica.

Naturalmente puoi usare altri tool (per esempio Trello al posto di Jira, 
gitlab o bitbucket al posto di github, ecc.).

Bye.

[toc] | [prev] | [next] | [standalone]

#21254

Il 31/10/2016 12:35, Alessandro Pellizzari ha scritto:
> On 31/10/2016 10:26, Gerry wrote:
>
> ...
> Penso di non aver mai fatto un diagramma UML in vita mia... :P
>
> Come documentazione, poi, li trovo controproduttivi.
>
> Fare un diagramma dell'architettura generale ha senso, ma dettagliare
> ogni classe sa tanto di waterfall e ben poco di agile.
>

Neppure io, però ho preso atto molto presto che è impossibile 
documentare applicazioni ad oggetti con il buon vecchio flowchart.
Sul fatto che ogni 3 per 2 devi "incontrare il committente", ecco... in 
effetti non capisco dove stia la differenza con il Waterfall.

>> ...
>
> È l'esatto contrario. Una metodologia agile funziona meglio con team
> piccoli (meno di 10 persone), e solitamente si consiglia di spezzare i
> team più grandi in team più piccoli, idealmente di 5-6 persone.
>

Boh!
Sono partito dalla solita Wikipedia e poi giù per almeno una dozzina di 
altri siti con pagine e pagine sull'argomento.
Si ha l'idea di piccoli gruppi di lavoro, sì, ma dentro team molto più 
complessi.

Quando ne ho parlato coi colleghi mi hanno guardato come fossi se 
scappato da un zoo.
All'idea, poi, di far lavorare in copia due persone sullo stesso PC mi 
hanno subito detto "Pagati però la metà, vero?"

Volevo capire se nelle realtà tipicamente Italiane, fatta 
prevalentemente da piccole software house, Agile viene usata o se è una 
delle tante cose che uno studia all'università nella speranza di farsi 
assumere da Google :P

>...
> Noi, come "tool", usiamo il planning poker per decidere le stime, Jira
> per tracciare i task, uno spreadsheet condiviso su GoogleDocs per avere
> un diagramma di gantt, github per le code review.
>
> Per la documentazione abbiamo un misto di docblock e README.md nelle
> cartelle di ogni componente per gli sviluppatori, e usiamo Confluence
> per documentazione più generica.
>
> Naturalmente puoi usare altri tool (per esempio Trello al posto di Jira,
> gitlab o bitbucket al posto di github, ecc.).

Grazie per la dritta
Gerry

[toc] | [prev] | [next] | [standalone]

#21255

On 31/10/2016 15:12, Gerry wrote:

> Neppure io, però ho preso atto molto presto che è impossibile
> documentare applicazioni ad oggetti con il buon vecchio flowchart.

Ecco, l'unico flowchart che abbia mai fatto deve essere stato nel 1986 o 
87... :D

Il modo più semplice è di spezzare il più possibile l'applicazione in 
micro-moduli indipendenti o quasi. A quel punto hai una "superficie di 
contatto" col resto del mondo che è molto ridotta, e puoi riassumerla in 
un paio di interface, che diventeranno il tuo contratto. Documentate 
quelle, i loro metodi e, a grandi linee, cosa fanno, non ti serve sapere 
cosa fa tutto l'albero di classi sotto.

E quando ti serve saperlo (perché devi cambiare il comportamento, leggi 
il codice, fai le modifiche, fai girare i test e, se sono verdi, sei a 
posto.

Se rompi qualcosa significa che i test erano incompleti. :)

> Sul fatto che ogni 3 per 2 devi "incontrare il committente", ecco... in
> effetti non capisco dove stia la differenza con il Waterfall.

Qui dipende da cosa fai. Nel waterfall, in realtà, dovresti incontrare 
il committente per 1-2 settimane prima di iniziare a scrivere codice, 
stilare tutte le caratteristiche del progetto, pianificare tempi e modi, 
e, dopo 6 mesi o 1 anno, vai dal committente a mostrare il lavoro finito.

Con l'agile dovresti incontrarti con lui alla fine di ogni sprint per 
valutare i progressi e decidere cosa fare dopo.

Nella pratica nessuna delle due cose succede mai, e si tratta sempre di 
una via di mezzo.

> Sono partito dalla solita Wikipedia e poi giù per almeno una dozzina di
> altri siti con pagine e pagine sull'argomento.
> Si ha l'idea di piccoli gruppi di lavoro, sì, ma dentro team molto più
> complessi.

Dipende da quanto è grosso il progetto, ma l'idea di avere 
micro-progetti indipendenti di solito aiuta: se il progetto finale è 
grosso puoi avere mini-team (5 persone) che lavorano a ogni componente, 
quindi con 100 persone, potenzialmente, puoi lavorare su 20 componenti 
in parallelo e finire il lavoro in 1/20 del tempo.

Poi leggi "the mythical man-month" e cambi idea, ma è un'altra storia. :D

> All'idea, poi, di far lavorare in copia due persone sullo stesso PC mi
> hanno subito detto "Pagati però la metà, vero?"

Questa è la tipica obiezione al pair-programming.

Ma non è necessario che si lavori 24h/24 in pair.

Puoi farlo saltuariamente, mentre stai decidendo come deve essere una 
nuova funzionalità, o quando stai facendo un refactoring pericoloso, e 
un altro paio di occhi serve.

Immagino farete code-review. Quella non è una "perdita di tempo"?

A volte fare pair-programming accorcia i tempi di sviluppo, perché la 
seconda persona può vedere i problemi mentre la prima scrive codice, e 
la può fermare prima che lavori 3 giorni su qualcosa che poi va buttato via.

Ti è mai capitato di pensare a come implementare qualcosa e poi, 
parlandone con un collega, capire che c'era un errore di fondo nel 
ragionamento che ti avrebbe portato a nulla? Ecco, col pair-programming 
quello lo becchi presto.

Un'alternativa è che uno dei due scriva i test (basandosi 
sull'interface) mentre l'altro scrive il codice, ma questo, nella mia 
esperienza, è ancora più difficile, e presuppone un "mini-waterfall" per 
la definizione dell'interface.

> Volevo capire se nelle realtà tipicamente Italiane, fatta
> prevalentemente da piccole software house, Agile viene usata o se è una
> delle tante cose che uno studia all'università nella speranza di farsi
> assumere da Google :P

Il trucco è che io non sono (più) in una realtà italiana. :D

Ma all'estero è usato da praticamente tutti, compresa Microsoft.

In alcune aziende italiane, comunque, viene usato, e in modo abbastanza 
proficuo.

Bye.

[toc] | [prev] | [next] | [standalone]

#21256

Il 31/10/2016 18:27, Alessandro Pellizzari ha scritto:
> On 31/10/2016 15:12, Gerry wrote:
>
> Ecco, l'unico flowchart che abbia mai fatto deve essere stato nel 1986 o
> 87... :D
>

Che è più o meno quando io ho smesso di programmare direttamente :D


Per il resto... facciamocene una ragione e mi documento meglio su come 
gestire Agile.
Vorrà dire che quando mi monopolizzano la TV con XFactor saprò come 
passare il tempo.

Per il momento di ringrazio e vado a cercarmi the mythical man-month.

Gerry

[toc] | [prev] | [next] | [standalone]

#21257

Il 31/10/2016 18:27, Alessandro Pellizzari ha scritto:

> Poi leggi "the mythical man-month"

Ah, ma lo conosco.
Non l'ho letto, soltanto una sintesi che circolava tempo fa.
L'avevo portato in direzione per spiegare come mai il progetto era in 
ritardo di quasi un anno dopo che avevano insistito per affiancare al 
team interno di tre persone un secondo team esterno di circa 20. :D

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web