Come mantenere la gestione fuori dal nostro processo di sviluppo

In primo luogo, lasciatemi dire che condivido pienamente la tua posizione. Può essere frustrante quando si ha una mancanza di comprensione o una ripartizione della comunicazione tra diverse parti dell'azienda. Detto questo, non penso che dovresti cercare di tenerli fuori. Invece dovresti mostrare loro i numeri sul perché questa è una buona idea. Quali fatti hai che giustificano il test unitario vale lo sforzo che ci hai messo? Se non ne hai, allora dovresti iniziare a raccogliere quelle cifre, oppure mostrare qualche ricerca per eseguire il backup delle attestazioni.

Ho avuto a che fare con scenari simili io e I ha risposto a questa domanda su un argomento simile . Ho anche parlato di come ho affrontato qui:

link

Nel caso in cui non ti senti come link chasing, ripeterò il mio riassunto dalla domanda correlata:

To summarize, I compared our estimated hours against actual hours for the project and then compared our defect rate against other teams' defect rate. In our case these numbers compared favourably and there were no more concerns.

La mia conclusione basata su questa esperienza è:

...the best way to convince anyone that your approach to doing something is practical and pragmatic, is to do it and measure it against other approaches. People don’t care about dogma, or why you think something should be the best way. Only by showing people the numbers and measuring the effectiveness of your approach can you truly show that your practices are effective.

Se il tuo team di gestione non è d'accordo nell'investire ciò che vedono come ulteriori 150 ore di test unitario, forse puoi convincerli a investire in una piccola area del prodotto (o addirittura a impegnarti a succhiargli le ore per fornire alcuni dati). I test unitari in quell'area del prodotto raccolgono quindi i dati sulle percentuali dei difetti in quell'area del prodotto e il costo per trovare e correggere tali difetti rispetto alle percentuali dei difetti in altre aree del prodotto. Spero che raccogli alcuni dati per eseguire il backup del tuo caso e questo sarà un non-problema per il tuo prossimo progetto.

La regola numero uno da seguire, indipendentemente dal metodo che usi, è

1. Gli sviluppatori dovrebbero avere il diritto di stimare il proprio lavoro.
2. Le parti interessate dovrebbero avere il diritto di stabilire la priorità tra quel lavoro.

La stima e la definizione delle priorità sono due forze che funzionano molto bene insieme una volta che entrambe le parti accettano le proprie responsabilità. Quindi, invece di perdere tempo a discutere, concorda su questo e rispetta che entrambe le parti faranno il loro lavoro al meglio delle loro capacità.

Potresti sottolineare che i test unitari fanno risparmiare tempo, quindi se li lasci cadere la stima arriva a 500 ore.

Informali sul debito tecnico e sul valore del test unitario

questo post da qualche bella idea di sul debito tecnico. A seguito di questo post puoi accedere al seguente pdf

Mi piace questo post sul valore dei test unitari (probabilmente ci sono altri da trovare)

La speranza non è di toglierli dal tuo processo di sviluppo, ma coinvolgerli e impegnarli nel modo giusto.

IMHO è necessario scrivere la pianificazione originale in basso, aggiungere i capitoli 1 e 2 (non in un'appendice) in cui si spiega il debito tecnico e il valore del test unitario. Offri loro alternative:

• meno ore (non l'intero 150, sembra ridicolo) dove ogni cambiamento (durante la fase di sviluppo e durante la manutenzione) in media richiederà:
  • piccole 4 ore
  • media 16 ore
  • grandi 40 ore
• le ore stimate in cui ogni cambiamento (fase di sviluppo e durante la manutenzione) richiederà in media:
  • piccola 2 ore
  • media 8 ore
  • grandi 20 ore

(Le ore sono solo indicative, sei in grado di fornire stime adeguate.)

Non dimenticare di includere il tuo track record per consegne puntuali al budget.

Annota e discuti con loro. Potrebbero avere alcuni punti preziosi in funzioni che in realtà non hanno bisogno in questo momento o un debito tecnico che sono disposti a prendere per consegnare in tempo. Assicurati solo che siano scelte consapevoli.

Spero che questo aiuti e buona fortuna.

Non puoi tenerli completamente fuori dal processo, dopo che pagano le tue retribuzioni e useranno il tuo prodotto (se non direttamente, presumibilmente qualcuno nella tua azienda è l'utente finale).

I manager che accusano gli sviluppatori di sopravvalutare il tempo è uno scenario molto comune nella mia esperienza e, se non affrontato, può portare a una corsa agli armamenti piuttosto stupida in cui le prossime stime sono raddoppiate perché sapete che i capi le ridurranno a metà, sappi che li dividono, quindi li quadruplichi ecc. ecc. È necessario evitare questo circolo vizioso se possibile.

Supponendo che non ci sia una ragione "drop dead" per la scadenza, suggerirei 2 cose.

1. Fornisci un piano dettagliato di ciò che pensi di poter fare in 150 ore, attenendosi al tuo attuale approccio di lavoro di alta qualità. Enumera esattamente ciò che può essere consegnato in questo intervallo di tempo. risposta da KeesDijk ha alcuni ottimi collegamenti sulla pianificazione a livello di grana fine.
2. Continua nello stesso stile di pianificazione dettagliata per coprire tutte le funzionalità e mostra come ci vorranno 300 ore (o qualsiasi altra cosa venga fuori).

Quindi mettiti al lavoro e riferisci regolarmente sui progressi e se possibile avere alcuni risultati a intervalli regolari. Questo dovrebbe dare fiducia alla gestione nelle tue capacità di stima e capacità di fornire.

Chiedi loro la base delle loro stime. È giusto discutere delle discrepanze. I test delle unità di dumping sono una falsa economia, ciò che non si spende per scrivere i test unitari che si spenderanno in un debugger più avanti (e più a lungo). In sostanza, hai documentato il fatto che hai intenzione di testare il lavoro che hai completato. Ti stanno dicendo di non provare affatto . Sia che tu collauda usando i test unitari o i test ad hoc mentre sviluppi il progetto, devi comunque tener conto di quel tempo. La rimozione del tempo assegnato per il test dell'unità rimuove anche il tempo assegnato per i test ad hoc.

Linea di fondo: attaccati alle tue armi con la tua stima. Il tuo track record mostra di sapere di cosa stai parlando e può dare una risposta ragionevole sulla base della tua stima (ipotesi, aspettative, performance passate, ecc.). Sembra che il tuo superiore non abbia la visibilità di cui hanno bisogno per creare una stima ragionevole. Stanno assumendo 8 ore al giorno senza interruzioni per le riunioni? Stanno preparando il budget per i test di sistema nelle loro stime? Come hanno trovato il numero che è metà del tuo, considerando il tuo track record?

Prima di tutto, non dividere i "test delle unità di scrittura" come un'attività separata da stimare, pianificare e potenzialmente tagliare. Le tue stime dovrebbero essere al livello di funzionalità "Implement the XYZ - 18 hours". Queste 18 ore dovrebbero includere tutto ciò che serve nel tuo processo per ottenere quella funzione su "DONE", incluso "write unit tests".

Questo è un buon modo per portare lo sviluppo non tecnico "fuori dal tuo processo di sviluppo". Non includere il tuo processo di sviluppo nell'elenco delle attività o la pianificazione del progetto che gli dai!

In secondo luogo, sembra che la tua squadra stia già offrendo buoni prodotti a loro e in tempo, ma che le altre squadre non lo sono. Forse questo gruppo di gestione è abituato a dover microgestire queste squadre. Gioca ai tuoi punti di forza: offri loro degli aggiornamenti settimanali o bisettimanali con funzioni di lavoro e ti daranno le spalle sul "processo di sviluppo".

Vorrei stimare che ci vorrebbero 300 ore e se budget 150 danno loro l'opzione che sarà o buggy rush job o in ritardo per essere consegnato. Quando il progetto è completo ed è come prevedi, puoi semplicemente dire loro che è quello che hai chiesto.

Cosa farebbe Wally?

Ci sono diversi modi di interpretare ciò che il management ti chiede, uno è che non vogliono che tu risponda in tempo.

Sembra assurdo? Sì, ma in che altro modo possono sapere che non stai sopravvalutando? Non rispettare le scadenze (allentamento se necessario), se dovessi scivolare e consegnare accidentalmente qualcosa in tempo assicurati di guardare veramente stanco per non dare l'impressione che fosse una passeggiata nel parco.