Cos'è Developer Anarchy?


24

Ho letto di Developer (o Programmer) Anarchy, che sembra essere definito come una metodologia di sviluppo post-Agile. Ho trovato alcune risorse su di esso ( 1 , 2 ) ma non sembra essere molto là fuori.

Mi chiedevo se qualcuno avesse delle buone risorse dove poter saperne di più _ su come implementarlo, pro e contro, confronto con altre metodologie ecc.


1
Non ne ho mai sentito parlare prima, ma mi sembra un po 'contraddittorio. Dicono "... la formalità e le regole sono vincolanti per la creatività e la produttività" ma allo stesso tempo hanno incontri regolari (come parte della metodologia?). Non riesco a credere che la descrizione di tale metodologia inizi impostando una regola.
Giorgio,

Leggendolo per la prima volta, mi sembra che sia stato fatto da una persona o da persone che hanno avuto esperienza solo con Agile. Perché questo "Developer Anarchy" è un esempio da manuale di "agile fatto bene". Per esempio. agile correttamente implementato.
Euforico

Il primo link che citi sembra contenere già tutto ciò che stai cercando.
Michael Borgwardt,

2
Che parola d'ordine adorabile!
CesarGon,

1
@CesarGon: le parole d'ordine sono più facili da inventare rispetto a metodologie davvero nuove. ;-)
Giorgio

Risposte:


46

Posso indicarti i pensieri di Alistair Cockburn su questo aspetto dei "veri" progetti Agile:

Un membro della famiglia di metodologie Crystal è Crystal Clear. Crystal Clear può essere descritto a un ascoltatore di livello 3 con le seguenti parole:

“Metti 4-6 persone in una stanza con postazioni di lavoro e lavagne e accesso agli utenti. Invitali a consegnare agli utenti software in esecuzione e testati ogni uno o due mesi, altrimenti lasciali soli. "

In effetti, ho descritto Crystal Clear in quelle parole a un esperto sponsor del progetto. Seguì quelle istruzioni e riferì cinque mesi dopo, "Abbiamo fatto quello che hai detto e ha funzionato!"

Ho intervistato il capo squadra alcuni mesi dopo e il suo rapporto era breve quanto le mie istruzioni:

“Seguendo il tuo suggerimento, noi quattro abbiamo rilevato questa sala conferenze, che ha connessioni di rete. Lo abbiamo tenuto per tutti e quattro i mesi, attingendo alle lavagne laggiù e distribuendo il software mentre procedevamo. Ha funzionato alla grande. "

ecco di cosa si trattava agile, e sembra che questo sia l'approccio adottato dalla metodologia Anarchy - il punto è che, se hai sperimentato ragazzi , allora puoi dire loro di "saziarsi e farlo funzionare" e loro faranno proprio questo . (questo non funziona con persone meno esperte, non lasceresti che una squadra di junior lo faccia senza almeno un po 'di supervisione).

Tutto il senso di agilità che si è sviluppato nel corso degli anni, come standup giornalieri e scrum board, sessioni di grooming del backlog del prodotto, riunioni pre-meeting sulle riunioni di pianificazione della sessione di grooming del backlog del prodotto. spese generali per la consegna corretta del prodotto.

Troppo oggi, però, queste cose sono considerate obbligatorie e la metodologia "agile" scende in un sistema che ha più processo rispetto ai vecchi metodi!


14
"Troppo oggi, però, queste cose sono viste come obbligatorie e la metodologia 'agile' scende in un sistema che ha più processi rispetto ai vecchi metodi!": Colpisci un punto importante (+1). Ho lavorato con SCRUM in un team di sviluppatori esperti e la nostra sensazione, dopo due anni è che ... eravamo più agili prima, quando non avevamo incontri quotidiani (ci incontravamo due volte a settimana) e molte altre attività è successo "quando il team decide che sono necessari" anziché "quando la metodologia li prescrive".
Giorgio

9
+1. In definitiva, penso che queste metodologie siano indicative di un ciclo in corso: metodologie pesanti falliscono ripetutamente, (alcune) persone si rendono conto che i programmatori sono abbastanza intelligenti da gestire le cose, radere il processo e generalmente le cose funzionano - ma il processo leggero è provato con squadre povere o inesperte, fallisce o manca le stime, il processo viene aggiunto per aumentare la "certezza" e la "prevedibilità" e il ciclo continua.
asthasr,

Gahhh ... quel ciclo sembra preciso e deprimente.
Graham,


1
@syrion: potresti avere ragione. Ho letto da qualche parte che le pratiche agili hanno funzionato per programmatori esperti. Quindi programmatori così esperti che avevano allenato team inesperti dovevano scrivere delle regole per loro (perché il coaching continuo costa molto ed è meglio che alcune regole siano scritte in un libro). In questo modo si svilupparono nuove metodologie come SCRUM e simili: così le persone possono ora vendere libri o certificazioni. Ma il vero spirito di agilità è applicare il tuo buon senso invece delle regole scritte da altri. Le regole sono linee guida ma sono considerate da molti come una religione.
Giorgio,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.