Non è possibile comprendere un determinato punto dei Principi del Manifesto Agile

24

Stavo leggendo i principi del Manifesto Agile . Tutto sembra chiaro e ragionevole, tranne per un punto:

La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale.

Non lo capisco. Questo significa che il lavoro che non è stato fatto dovrebbe essere in qualche modo esagerato? Se è così, non ha davvero senso.

agile management

— SuperM
fonte

2

+1 per contrastare il voto negativo: qui hai una domanda sorprendentemente interessante.

1

Vedi anche Wu Wei e immagina come può essere applicato allo sviluppo del software in generale. È la naturale progressione della filosofia espressa nella tua domanda.

30

Rimuovi il commento tra parentesi. Ciò che rimane è "La semplicità è essenziale", che tra l'altro è un'applicazione del principio alla sua stessa espressione.

La semplicità è essenziale, perché hai distillato ciò di cui hai veramente bisogno, rimuovendo ciò che rende il compito a portata di mano più pesante, meno elegante: complesso.

Ho sempre interpretato nel senso dell'opinione di Pascal sulla brevità : " Avrei scritto una lettera più breve, ma non avrei avuto il tempo. " Devi evitare ciò che non è segnato (dalla lettera, dal codice) e questo è un compito attivo e non facile. Non è qualcosa che accade da solo.

— Francesco
fonte

35

L'idea è di evitare di svolgere un lavoro non necessario, ovvero "massimizzare la quantità di lavoro non svolto".

Quindi, se in un progetto tradizionale pianificassi e costruissi un ottimo sistema di base astratto per consentire a tutte le tue possibili esigenze in un secondo momento, lo salti e costruisci la cosa più semplice che può funzionare per i requisiti attuali . Non costruire cose che non ti servono.

YAGNI è un concetto correlato.

— Joachim Sauer
fonte

5

Per coincidenza, questo è probabilmente il principio agile con cui sono meno d'accordo . Preso all'estremo, la lungimiranza astratta è ciò che ci separa dagli altri animali ... Dico che dobbiamo usarlo ogni volta che possiamo. Ovviamente so a che tipo di atrocità deve essere una reazione il principio, ma un po 'di lungimiranza non farà male. A volte è YAGNI, ma ho visto alcuni sviluppatori così dogmatici che non si fermeranno nemmeno a pensare qualche ora prima (e rendersi conto che la semplicità che stanno implementando ora non sarà nemmeno sufficiente in 4-8 ore).

— Max

2

@Max, penso che sia necessario vedere prevedere possibili cambiamenti futuri. Qui è dove la lungimiranza è di grande aiuto. E gli sviluppatori che descrivi sono più simili agli struzzi, che si nascondono nella sabbia.

— superM

7

Clienti @Max non vogliono pagare per quello che pensa che potrebbe avere bisogno in futuro, vogliono pagare per quello che hanno bisogno in questo momento come il più presto possibile . Ci sono miliardi di dollari di sforzi sprecati ogni mese su buone intenzioni di "questo farà risparmiare così tanto tempo dopo" e che "dopo" non arriva mai, ma le cose sono complesse, buggy e in ritardo a causa di tutta quella "lungimiranza"

15

@Max: YAGNI riguarda il rinvio delle decisioni all'ultimo momento responsabile . Quello di cui stai parlando è ritardare la decisione all'ultimo momento possibile , che è davvero una Bad Idea ™. Il fatto è: non avrai mai meno informazioni su cui basare una decisione di quante ne hai in questo momento. Nel peggiore dei casi, avrai le stesse informazioni domani. Ma di solito, avrai imparato qualcosa da allora. Nel caso lei ha citato, si sa che si è andando bisogno, in modo da YAGNI semplicemente non si applica. Cercare di applicarlo è davvero stupido in quel caso.

— Jörg W Mittag,

2

@Max: quello che stai descrivendo qui è l'esatto contrario di massimizzare la quantità di lavoro non svolto. Sta facendo il doppio del lavoro.

— pdr

5

In passato chiamavamo questa "doratura". Il requisito per un martello è che può colpire un chiodo in un pezzo di legno. Non fa niente di meglio per essere un martello placcato in oro.

Molte volte uno sviluppatore suggerisce di utilizzare un nuovo framework interessante o di aggiungere funzionalità che non sono necessarie. Annoteremo questa idea, ma per questa versione non la faremo. Massimizzeremo il lavoro non svolto. È abbastanza difficile consegnare il software in tempo, quindi non fornire più codice del necessario. Se deve essere fatto, alla fine entrerà nel piano e sarà fatto al momento opportuno.

— Stuart Woodward
fonte

4

Questa idea è molto simile a un concetto del Toyota Production System (TPS) , che ha portato alla Lean Manufacturing più generica e quindi all'applicazione di tali tecniche allo sviluppo del software Lean . Il TPS precede significativamente il movimento agile, con le sue radici nella produzione alla fine degli anni '50.

Il concetto di massimizzare la quantità di lavoro non svolto è simile all'eliminazione degli sprechi. Nell'ambiente di produzione, i rifiuti includono cose come la sovrapproduzione di beni, l'attesa di risorse, la circolazione non necessaria di persone o prodotti, troppo inventario e prodotti difettosi. In Lean Software Development, questi rifiuti sono stati tradotti in funzionalità non necessarie, ritardi nel processo di sviluppo, requisiti poco chiari che rallentano la produzione di software, mancanza di test e ritardi nella comunicazione.

L'idea generale di entrambi i concetti è la stessa: le cose che non aggiungono valore sono dispendiose e dovrebbero essere ridotte al minimo. L'obiettivo finale è aumentare la qualità riducendo tempi e costi di produzione.

— Thomas Owens
fonte