Il linguaggio di programmazione PHP
 

Metodologie Agile

Gerry 31 Ott 2016 11:26
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
Alessandro Pellizzari 31 Ott 2016 12:35
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 ******* 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.
Gerry 31 Ott 2016 16:12
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 ******* 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
Alessandro Pellizzari 31 Ott 2016 18:27
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.
Gerry 31 Ott 2016 19:27
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
Gerry 31 Ott 2016 19:34
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

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Il linguaggio di programmazione PHP | Tutti i gruppi | it.comp.www.php | Notizie e discussioni php | Php Mobile | Servizio di consultazione news.