7 sprechi nello sviluppo software snello e come prevenirli

Il pensiero del processo snello dà la priorità all'eliminazione e alla riduzione della raccolta dei rifiuti. Nonostante l'approccio "snello" adottato dalle grandi aziende, alcune pratiche standard di "rifiuto" persistono a causa della loro "natura evidente". La natura che è profondamente scolpita nelle pratiche umane e organizzative è ostinata fino a quando non viene adottata un approccio rigoroso.

Che cosa sono i rifiuti?

Tutto ciò che richiede risorse/tempo o impegno ma non produce risultati rilevanti in termini di prestazioni o entrate è chiamato "rifiuto".

In definitiva, la procedura di “riduzione dei rifiuti” è progettata e guidata per aumentare la produttività ei risultati del team.

Tuttavia, ora che lo sviluppo software snello è il capostipite dell'agile, possiamo adottare questi sette principi di riduzione degli sprechi sull'ingegneria e lo sviluppo del software per produrre prodotti e servizi efficaci, ridurre i costi e accelerare il time-to-market dei prodotti.

1. Lavoro parzialmente svolto

Se il lavoro precedente non viene mai riavviato, quello sforzo è stato uno spreco.

Qualsiasi lavoro fino a quando non è terminato/completato non si aggiunge alla proposta di valore del cliente; quindi, è una perdita di tempo e difficoltà a mantenere il codice se messo in attesa.

Un esempio contemporaneo è quando un cliente richiede modifiche o funzionalità extra su un prodotto. L'azienda si impegna a finirli con urgenza; il team di sviluppo deve interrompere il lavoro in corso e agire in base ai requisiti. Nella stessa pagina, se il lavoro precedente non viene mai riavviato, è stato uno spreco di fatica.

o

Documentazione non codificata: i requisiti sono dettagliati in modo completo ma non vengono mai implementati.

Come ridurre questo spreco?

• L'obiettivo dovrebbe essere "finire" e non solo "iniziare" un progetto.
• Ridurre gli incarichi di lavoro in corso.
• Smetti di aspettare le specifiche dettagliate su ogni requisito fino a quando il team non sarà pronto per implementare gli sforzi (non sarà quindi una causa persa).

2. Processi extra

Qualsiasi processo aggiunto o documentazione non letta che non trasmetta valore pratico e prolunghi inutilmente i tempi o la realizzazione del mercato del prodotto è uno spreco.

Tuttavia, le politiche aziendali spesso impongono tali documenti, con notevoli scartoffie ma mai letti. Questi sforzi sono stravaganti.

Esempi tipici:

• Dettagli non necessari della documentazione.
• Gestione aggiuntiva o pianificazione senza esecuzione.

Come ridurlo?

Le organizzazioni possono distinguere tra ciò che è una causa/sforzo persa e ciò che porta valore al tavolo, l'attenzione dovrebbe essere sulla produzione di risultati significativi e incanalare gli sforzi per svolgere un lavoro più "di qualità" limitando il lavoro "in quantità".

3. Funzionalità extra

Qualsiasi caratteristica o caratteristica di basso valore che viene aggiunta per/dal cliente ma non richiesta/non contribuisce all'aumento delle entrate è uno spreco di fatica.

Le aziende commettono questo errore di sviluppo quando aggiungono funzionalità che non saranno molto utilizzate o esercitate; questa nuova funzionalità rimane effettivamente inattiva e aumenta la complessità dell'applicazione.

La regola del software 80/20 gioca un ruolo significativo: l'80% degli utenti utilizza solo il 20% delle sue funzionalità. Pertanto, l'obiettivo dovrebbe essere quello di rendere quelle funzionalità del 20% di prim'ordine per mantenere gli utenti esistenti.

I codici aggiuntivi hanno i loro svantaggi:

• Aumenta la complessità dell'applicazione.
• Può creare un potenziale punto di arresto anomalo dell'applicazione.
• Richiede inutili sforzi successivi nel monitoraggio e nella manutenzione durante il ciclo di vita del prodotto.

Come ridurre questo spreco?
Concentrati sullo sviluppo iterativo, il che significa che durante il rilascio iniziale del prodotto, crea solide funzionalità primarie che definiscono l'USP della tua applicazione.

Concentrati sul renderlo funzionale e convalidare l'apprendimento del continuo avanzamento del prodotto. Inoltre, continua a creare funzionalità appropriate in base alla tua analisi di mercato, al comportamento dei consumatori e al feedback.

4. Cambio attività

Assegnare le persone a più attività quando non si sentono a proprio agio con esso e ostacola il loro processo esistente può richiedere un'enorme quantità di giorni. Il modo più efficiente per portare a termine una o due attività specifiche è finirne una alla volta.

Durante il passaggio da un'attività all'altra, c'è un piccolo costo per chiudere quella esistente e ottenere slancio sull'altra, questo è chiamato cambio di contesto e se ti aspetti una transizione costante dall'una all'altra, questi cambi di contenuto si accumulano ritardando il "risultato" o "tempi di consegna".

Come ridurlo?

Semplice: una cosa alla volta.

• Riduci il cambio di contenuto.
• Riduci al minimo le interruzioni o le distrazioni.
• Rimanda quelli senza importanza.
• Assegna risorse come un progetto alla volta.

5. Attesa/Ritardi

Le dipendenze di approvazione dovrebbero essere programmate principalmente durante la roadmap del prodotto; se non viene assegnato un intervallo di tempo specifico, essere pronti per risposte e feedback ritardati. I ritardi impediscono inoltre al consumatore di rendersi conto del valore reale del prodotto. Ma, come sviluppatori o designer, devi aspettare l'approvazione sul lavoro svolto; quindi, non puoi evitare del tutto il time-lapse.

Cosa puoi fare per ridurlo?

• Scegli/assegna qualcosa in attesa del feedback esistente.
• Assegna tempo per inserire e rivedere.
• Prendi in considerazione chiamate rapide, conversazioni faccia a faccia piuttosto che inviare le modifiche tramite e-mail.
• Feedback regolare.

6. Movimento

Se i team di sviluppo o di ricerca sono stati sparpagliati con le informazioni acquisite e non le hanno contrassegnate/etichettate in modo appropriato, può volerci un'eternità per eliminare la confusione e il drop-in. Se le informazioni vengono smarrite ogni volta che viene consegnato un deliverable; ostacolerà drasticamente i risultati.

Come ridurlo?

• Etichettare le assegnazioni o le risorse acquisite.
• Riduci i tempi di feedback.
• Collaborazioni faccia a faccia.

7. Difetto

Quantità di rifiuti causati dal difetto = (Impatto del difetto) x (Tempo in cui non viene rilevato)

A causa della sua complessità, lo sviluppo del software rende inevitabili i difetti, ma il problema sorge quando sono prolungati nell'esecuzione e nella correzione o il costo sostenuto per la correzione o l'impatto della rilavorazione. Inoltre, i principali errori e bug del codice possono potenzialmente influenzare e ostacolare l'intero ciclo di vita del prodotto e renderlo vulnerabile alle minacce alla sicurezza, provocando perdite di milioni di entrate.

Cosa puoi fare per ridurlo?

• Prove immediate.
• Integrazione costante.
• Test del prodotto e rilasciato al più presto.