Effettuando la localizzazione di ogni Sprint

Mettere semplicemente questo, come molte domande sui processi, si riduce a una decisione in termini di costi / benefici.

Molte delle pratiche descritte nei processi agili riguardano la riduzione del tempo trascorso nell '"ultimo miglio" - questo è un esempio di uno di questi.

A differenza delle pratiche con altri scopi (qualità, correttezza, ecc.), le pratiche volte a garantire la possibilità di rilasciare il prodotto in qualsiasi momento hanno un costo netto ad esse associato.

Garantire che il prodotto che si sta sviluppando sia sempre pronto per essere rilasciato in qualsiasi momento ha un costo che non è direttamente trasformato in beneficio allo stesso modo in cui garantisce che sia alla qualità di produzione.

Ho diviso questi due aspetti perché presentano differenze importanti. Ad esempio:

Garantire che un prodotto sia ben testato e privo di bug in qualsiasi momento ha un costo, ma il vantaggio è il tempo ridotto per correggere i bug man mano che vengono trovati, produrre nuove funzionalità e minori possibilità di rielaborazione su larga scala dopo che si sono trovati bug fondamentale. Quasi sempre il vantaggio tangibile sarà maggiore del costo tangibile.

Garantire che un prodotto sia veloce e semplice da distribuire ha un costo ma ti salverà quando verrai rilasciato e il vantaggio si moltiplica quando rilasci frequentemente. Più spesso si rilascia, più è probabile che il costo si realizzi in risparmi. Di nuovo, il beneficio tangibile sarà generalmente maggiore del costo.

Garantire che un prodotto sia correttamente localizzato in qualsiasi momento ha un costo, ma raramente si tradurrà in un tangibile beneficio economico. Ciò è particolarmente vero quando una terza parte è coinvolta come una relazione di lunga data e continua con una terza parte in genere costano di più (in termini di tempo e costi) rispetto a brevi raffiche di lavoro pezzo.

La domanda è: ci sono altri benefici che guadagni che rendono il costo utile?

In questo caso, il più grande vantaggio risiede nella possibilità di ridurre il tempo impiegato dal rilascio del candidato all'effettivo rilascio: ritorna all'ultimo miglio.

Un modo per pensarci è come magazzino in un magazzino. Lo sviluppo di software è un modo di costruire titoli - finché questo stock non è sugli scaffali (il software è rilasciato) non genera entrate. In alcuni scenari, anche il valore scende sullo scaffale.

Quindi una domanda che si può porre è "Per quanto tempo possiamo sopportare che il nostro stock sia sullo scaffale senza generare valore?". Per i sistemi basati sull'efficienza interna questo potrebbe essere settimane, per prodotti innovativi di primo mercato potrebbero essere ore. Più il tempo è breve, più "pronto per la produzione" è necessario che il tuo software sia sempre disponibile.

Un'altra domanda potrebbe essere "Quanto è probabile che il nostro cliente decida in un punto arbitrario di rilasciare il software?". Cioè, nello sprint 3 di 6 decidono che a loro piace così tanto il software che lo vogliono subito. Se la situazione è probabile, per quanto tempo staranno bene aspettando?

Inoltre, vedrà il software nel suo stato interamente localizzato gettare luce su domande che altrimenti rimarrebbero senza risposta? La visione di una versione tradotta del sito generalmente fa cambiare direzione al cliente o aiuta a convalidare la direzione corrente? C'è quindi un valore nel vederlo prima nel tuo processo?

Hai altri processi nell '"ultimo miglio" che ti trattengono più a lungo? Se l'unica cosa che stai aspettando nelle ultime 2 settimane sono le traduzioni, genererai un beneficio maggiore rispetto a quello che sarebbe necessario aspettare 2 settimane per l'aggiornamento delle infrastrutture, le parti interessate senior per firmare il lavoro, ecc.

Perché trovi che devi fare una nuova traduzione? È perché i requisiti del testo cambiano man mano che il sistema si sviluppa - una conseguenza inevitabile del cambiamento nel sistema. Oppure è più che le persone non sono disposte a impegnarsi in un corpo di testo all'inizio del processo quando probabilmente dovrebbe essere in grado di farlo. È possibile che la traduzione continua si concentri sull'assicurare la correttezza in ogni momento?

Infine, quanto costerà? Hai guardato la quantità di ri-traduzione sarà richiesto? Qual è il costo incrementale della traduzione frammentaria? Se questa è una decisione in termini di costi / benefici, è necessario non solo chiarire i benefici, ma calcolare il costo tangibile.

Quindi, il mio consiglio sarebbe:

• Scopri i vantaggi nella tua situazione specifica.
• Calcola i costi.
• Prendi la decisione in base ai fatti.

Chi sono i veri clienti (al contrario degli utenti beta)? Si aspettano testo completamente tradotto?

Se l'idea è di lasciare che il prodotto cuoce per alcuni sprint per ottenere un feedback, è possibile rinviare la traduzione in modo che sia programmata per arrivare in tempo per la consegna finale. Altrimenti, traduci per ogni sprint; in questo modo il lavoro è "fatto". Se ha bisogno di essere cambiato in seguito, accettalo come un costo. Il punto non è quello di ridurre ogni singola spesa ad ogni passo; è per ridurlo in generale e rendere il processo più sano e agile.

Inoltre, se il tuo testo "apprezza maggiormente il cambiamento" dopo alcuni sprint, forse un po 'di sforzo può essere messo nella scelta di un testo migliore in primo luogo, se possibile.

Applicare la regola "potenzialmente spedibile" nella misura in cui ha senso. Usa il tuo buon senso dove non lo fa. (Il senso comune a volte è chiamato "regola 0" in agile)

Una squadra dovrebbe evitare di impegnarsi in un lavoro al di fuori del proprio potere. Le traduzioni in genere si basano su traduttori esterni al team. Quindi la squadra non dovrebbe impegnarsi in questo.

In breve: inserisci la tua definizione di fatto "Pronto per la traduzione".

E riservare un po 'di tempo prima del rilascio per completare quei piccoli elementi che sono stati lasciati fuori dal D.do.D.

Per i puristi agili (quelli che lo interpretano fin troppo alla lettera), questo è davvero un piccolo pezzetto di "cascata". Ma funziona.

La localizzazione dovrebbe essere completata per ogni versione. Se rilasci una volta per sprint, localizza una volta per sprint. Se rilasci ogni 4 sprint, localizza una volta ogni 4 sprint. Avere un periodo di blocco delle stringhe prima del rilascio in cui non si apportano modifiche alle stringhe nella base di codici in modo che i traduttori abbiano il tempo di aggiornare le cose.