Non fare mai nulla fino a quando non sei pronto per usarlo, anche nel software? [Principio Toyota] [chiuso]
-
02-07-2019 - |
Domanda
Stavo ascoltando un podcast . Dove hanno parlato dei principi che Toyota stava usando:
Non fare mai nulla finché non sei pronto per usarlo.
Penso che questo ci dica di guardare in altri luoghi, di imparare quali altre pratiche sono note da anni.
Soluzione
può applicarsi alla costruzione di software, ma non sono sicuro che si applica
Se consideriamo i cinque elementi in un " toyota-way del processo decisionale ", basato sul principio che" come si arriva alla decisione è importante tanto quanto la qualità della decisione ":
[umorismo modalità ON]
-
Scopri cosa sta realmente succedendo, incluso Genchi Gembutsu.
Tranne che qualche volta, finalmente capiamo cosa sta succedendo quando il cliente ci spiega alla fine del progetto;)
-
Comprensione delle cause sottostanti che spiegano le apparenze superficiali — chiedendo “Perché?” cinque volte.
Sicuro ma il client non è abbastanza disponibile durante il progetto;)
-
Considerando ampiamente soluzioni alternative e sviluppando una logica dettagliata per la soluzione preferita.
Troppo tardi, i programmatori stanno già programmando come matti :)
-
Costruire il consenso all'interno del team, inclusi dipendenti Toyota e partner esterni.
Oops quel programmatore sta già riscrivendo il sistema di autenticazione anche se quello vecchio funzionava bene
-
Usare veicoli di comunicazione molto efficienti per fare da uno a quattro, preferibilmente un lato di un foglio di carta.
Hai sentito " morte per powerpoint " ? Questo non è sempre il nostro punto forte;)
[umorismo modalità OFF]
Seriamente, come affermato dalle risposte precedenti, la filosofia Agile si rivolge ad alcuni dei principali inquilini di questo principio Toyota.
E potrebbe essere un po 'più ricco che solo "Non ne avrai bisogno", come descritto nel libro " Il modo Toyota "
Altri suggerimenti
Sorta di sì. Questa è una parte fondamentale della filosofia agile .
Fondamentalmente, favorisci la flessibilità e la velocità di risposta rispetto alle grandi specifiche e alle ingombranti specifiche. Uno dei modi migliori per farlo è quello di costruire solo abbastanza per soddisfare i tuoi attuali requisiti, perché non sai mai quando cambieranno.
Sono un po 'vecchie notizie. Viene spesso chiamato " Non ti servirà " (" You Arent 'Going Need It " in inglese non idomatico) e abbreviato YAGNI .
Problemi associati all'implementazione di una funzionalità quando non ne hai bisogno:
- l'implementazione richiede tempo per lo sviluppo di funzionalità necessarie
- la funzione è difficile da documentare e testare, poiché se non ne hai bisogno, chissà cosa dovrebbe fare esattamente?
- la manutenzione della funzione richiederà ulteriore tempo
- la funzione aggiunge ulteriore codice, complicando la base di codice
- la funzione potrebbe avere un effetto valanga, per cui suggerisce altre funzionalità che potresti voler aggiungere, anche se non sono necessarie
È una buona pratica agile pensare così. C'è anche qualcosa chiamato Test-Driven-Development, che ti aiuta a ottenere software senza bug (quasi), ma ha anche quell'effetto collaterale che NULLA è implementato che non usi.
Un esempio è la tua classe di raccolta. Se hai solo bisogno di un metodo Add e di un metodo ToArray, perché usare il tempo per implementare i metodi Remove and Count?
Quindi sì. Segui questo principio :)