Non fare mai nulla fino a quando non sei pronto per usarlo, anche nel software? [Principio Toyota] [chiuso]

Question

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.

Answer 1

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 "

Answer 2

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.

Answer 3

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

Answer 4

È 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 :)