Come mantenere la gestione fuori dal nostro processo di sviluppo

Sono un ingegnere del software in un team di sviluppo software. Negli ultimi 3 anni abbiamo lavorato per un cliente interno su un nuovo prodotto. Ora che questo prodotto è finito, lavoreremo su nuove importanti funzionalità per i prodotti esistenti. Per una caratteristica particolare, la gestione del prodotto ha indovinato lo sviluppo di 150 ore. Insieme al nostro project manager abbiamo creato un piano molto dettagliato e arriviamo a uno sforzo di 300 ore. Ieri ne abbiamo discusso e pensano che abbiamo ampiamente sopravvalutato le cose.

Nella nostra pianificazione abbiamo stimato ore per la scrittura di unit test, la loro idea è di scaricarli per risparmiare tempo. La decisione non è stata ancora presa e difenderò questa pianificazione e i test unitari, se necessario. Ma quello che non mi piace davvero qui è che la gestione sta interferendo con il nostro processo di sviluppo. Come posso tenerli fuori dal nostro processo di sviluppo? E quali argomenti posso usare per mantenere in atto i test unitari (oltre alla qualità e al risparmio di tempo a lungo termine)?

Come nota a margine, la nostra azienda ha 3 team di ingegneri e il team in cui mi trovo consegna i loro software in tempo (dare o prendere un margine del 10%). Mentre gli altri team consegnano sempre in ritardo, principalmente a causa della sottovalutazione nella pianificazione. Pianificano solo la codifica e non la gestione, i test e la gestione al suo interno.

Per prima cosa, lasciami dire che sono completamente d'accordo con la tua posizione. Può essere frustrante quando si ha una mancanza di comprensione o un'interruzione della comunicazione tra le diverse parti dell'azienda. Detto questo, non credo 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 metti? Se non ne hai, dovresti iniziare a raccogliere quelle cifre o mostrare alcune ricerche per sostenere le tue affermazioni.

Ho avuto a che fare con scenari simili e ho risposto a questa domanda su un argomento simile . Ho anche scritto un blog su come l'ho affrontato qui:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Nel caso in cui non abbiate voglia di inseguire link, ripeterò il mio riassunto dalla domanda correlata:

Per riassumere, ho confrontato le nostre ore stimate con le ore effettive per il progetto e quindi ho confrontato il nostro tasso di difetto con il tasso di difetto di altri team. Nel nostro caso questi numeri sono stati confrontati favorevolmente e non c'erano più preoccupazioni.

La mia conclusione basata su questa esperienza è:

... il modo migliore per convincere chiunque che il tuo approccio al fare qualcosa è pratico e pragmatico, è farlo e misurarlo con altri approcci. Alla gente non importa del dogma o del perché pensi che qualcosa dovrebbe essere il modo migliore. Solo mostrando alle persone i numeri e misurando l'efficacia del tuo approccio puoi davvero dimostrare che le tue pratiche sono efficaci.

Se il tuo team di gestione non accetta di investire ciò che vede come ulteriori 150 ore in test unitari, forse puoi convincerli a investire in una piccola area del prodotto (o anche accettare di risucchiarti le ore per fornire alcuni dati ). Effettuare i test unitari in quell'area del prodotto, quindi raccogliere i dati sui tassi di difetto in quell'area del prodotto e sui costi per trovare e correggere tali difetti rispetto ai tassi di difetto in altre aree del prodotto. Spero che raccoglierai alcuni dati per il backup del tuo caso e questo non sarà un problema per il tuo prossimo progetto.

La regola numero uno da seguire, indipendentemente dal metodo utilizzato, è quella

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

La stima e la definizione delle priorità sono due forze che lavorano molto bene insieme quando entrambe le parti accettano le proprie responsabilità. Quindi, invece di perdere tempo a discutere, concorda 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 passa a 500 ore.

Raccontagli del debito tecnico e del valore dei test unitari

Guarda questo post da alcune belle idee sul debito tecnico. Seguendo questo post puoi accedere al seguente pdf

Mi piace questo post sul valore del test unitario (probabilmente ce ne sono altri da trovare)

La speranza non è di farli uscire dal processo di sviluppo ma di coinvolgerli e impegnarli nel modo giusto.

IMHO è necessario annotare la pianificazione originale, aggiungere i capitoli 1 e 2 (non in un'appendice) in cui si spiega il debito tecnico e il valore dei test unitari. Dai loro delle alternative:

• meno ore (non tutte le 150, che sembrano ridicole) in cui ogni cambiamento (durante la fase di sviluppo e durante la manutenzione) richiederà in media:
  • piccole 4 ore
  • medie 16 ore
  • grandi 40 ore
• le ore stimate in cui ogni cambiamento (fase di sviluppo e durante la manutenzione) richiederà in media:
  • piccole 2 ore
  • medie 8 ore
  • grandi 20 ore

(Le ore sono solo indicative. Sei meglio equipaggiato per fornire stime adeguate.)

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

Scrivilo e discuterne con loro. Potrebbero avere alcuni punti preziosi in caratteristiche che in realtà non sono necessarie in questo momento o alcuni debiti tecnici che sono disposti a prendere per consegnare in tempo. Assicurati solo che siano scelte consapevoli.

Spero che questo aiuti e buona fortuna.

Prima di tutto, non suddividere i "test di unità di scrittura" come attività separata da stimare, programmare e potenzialmente tagliare. Le tue stime dovrebbero essere a livello di funzionalità "Implementa XYZ - 18 ore". Quelle 18 ore dovrebbero includere tutto ciò che serve nel processo per portare quella funzione su "FATTO", inclusi i "test di unità di scrittura".

Questo è un buon modo per ottenere lo sviluppo non tecnico "fuori dal processo di sviluppo". Non includere il processo di sviluppo nell'elenco delle attività o nella pianificazione del progetto che fornisci loro!

In secondo luogo, sembra che il tuo team stia già fornendo loro buoni prodotti e in tempo, ma che altri team non lo sono. Forse questo gruppo di gestione è abituato a dover microgestire quei team. Sfrutta i tuoi punti di forza: offri di mostrare loro aggiornamenti settimanali o bisettimanali con funzionalità funzionanti e ti lasceranno alle spalle il "processo di sviluppo".

Una volta mi trovavo in una situazione in cui stavo lavorando con una base di codice in un ottimo stato; era necessaria una nuova funzionalità stimolante in un arco di tempo molto breve, e sono riuscito a fornire la funzione in un tempo molto breve. A quel punto la base di codice era in uno stato molto peggiore. Quindi la funzionalità è stata consegnata, ma il mio lavoro non è stato completato: ho dovuto riportare tutto in uno stato altrettanto buono.

Ho spiegato al manager due livelli in questo modo: è come fare un lavoro di pittura a casa tua. Se tutti gli strumenti sono lì dove appartengono e in buono stato, tutti i pennelli puliti e così via, puoi fare un lavoro di verniciatura molto rapidamente. Ma poi devi passare il tempo per rimettere in ordine tutti i tuoi strumenti. Se non lo fai, il tuo prossimo lavoro di verniciatura richiederà molto più tempo. In realtà, non ricorderai dove si trovano i tuoi strumenti, i tuoi pennelli non possono più essere recuperati e ti costa molto più tempo e denaro extra come se avessi fatto immediatamente il lavoro di pulizia.

E lo stesso nel mio lavoro di programmazione: ripulendo, porto la base di codice in uno stato in cui posso consegnare qualcosa molto rapidamente di nuovo la prossima volta che è necessario. In caso contrario, la prossima volta ci vorrà molto più tempo.

Non puoi tenerli completamente fuori dal tuo processo, dopo tutto pagano i tuoi stipendi 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 sono uno scenario molto comune nella mia esperienza e, se non affrontato, possono portare a una corsa agli armamenti piuttosto stupida in cui le prossime stime sono raddoppiate perché sai che i capi li dimezzeranno, lo sanno così li quadrano, quindi li quadrupli ecc. ecc. Devi evitare questo circolo vizioso, se possibile.

Supponendo che non vi sia alcun motivo "drop dead" per la scadenza, suggerirei 2 cose.

1. Fornisci un piano dettagliato di ciò che pensi di poter fare in 150 ore, attenendoti al tuo attuale approccio di lavoro di alta qualità. Enumera esattamente ciò che può essere consegnato in questo lasso di tempo. La risposta di KeesDijk ha alcuni ottimi collegamenti sulla pianificazione a un livello ben preciso.
2. Procedere nello stesso stile di pianificazione dettagliata per coprire tutte le funzionalità e mostrare come ci vorranno 300 ore (o qualunque sia il risultato).

Quindi mettiti al lavoro e riferisci regolarmente sui progressi e, se possibile, disponi di alcuni risultati a intervalli regolari. Ciò dovrebbe dare alla direzione fiducia nelle tue capacità di stima e capacità di fornire.

Chiedi loro la base delle loro stime. È giusto discutere delle discrepanze. Dumping unit test è una falsa economia, ciò che non spendi per scrivere unit test che dovrai spendere in un debugger in seguito (e più a lungo). In sostanza, hai documentato il fatto che prevedi di testare il lavoro completato. Ti stanno dicendo di non provare affatto . Sia che testiate usando unit test o test ad hoc mentre sviluppate il progetto, dovete comunque tenere conto di quel tempo. La rimozione del tempo assegnato per i test unitari rimuove anche il tempo assegnato per i test ad hoc.

Bottom line: attenersi alle pistole con il tuo preventivo. Il tuo track record mostra che sai 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 ha bisogno per creare una stima ragionevole. Stanno assumendo giorni di 8 ore senza interruzioni per le riunioni? Stanno iscrivendo il budget per i test di sistema nelle loro stime? Come hanno ottenuto il numero che è la metà del tuo, considerando il tuo track record?

Stimerei che ci vorranno 300 ore e se il loro budget 150 dà loro l'opzione, sarà un lavoro di buggy 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?

Esistono diversi modi per interpretare ciò che la direzione 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 (allentate se necessario), se dovessi scivolare e consegnare accidentalmente qualcosa in tempo, assicurati di sembrare davvero stanco per non dare l'impressione che fosse una passeggiata nel parco.

Sei in un sottaceto. Se ti attieni alle tue pistole e vuoi continuare con i test unitari e vuoi rivendicare le 300 ore, diventerai nemico.

Se si riducono a 150 ore e si eseguono i test dell'unità di mandrino, è possibile consegnare un prodotto più veloce, ma causerà dolore lungo la strada, con un costo di manutenzione più elevato.

Ad ogni modo, perdi.

O almeno così sembra.

Vedi, non stai gestendo un laboratorio scientifico all'università. State fornendo un servizio aziendale a un'unità aziendale in una società che fornisce servizi ai clienti in un ecosistema di aziende. La tua azienda potrebbe aver bisogno del tuo prodotto per iniziare a fornire servizi migliori e più veloci ai suoi clienti, aumentando così le entrate necessarie.

Vedete, ciò di cui avete bisogno è un'analisi del ROI e non avete tutti i dati per effettuare tale analisi. Hai solo una parte della parte di costo (non conosci i numeri delle buste paga di tutti) e certamente non hai le parti delle entrate, specialmente non le proiezioni delle entrate.

Il tuo management, che ci crediate o no, è abile nel fare le proiezioni del ROI (questo è ciò che insegnano nella business school) e potrebbe aver eseguito più proiezioni del ROI e inventare "se agiamo ora faremo molti più soldi anche pagando il triplo per la manutenzione del software di cui si lamentano i bozos nell'IT ".

Quindi, se si desidera gestire il comune, avviare la propria azienda. Vedrai, non è così facile.

In altre parole: fai quello che ti viene detto. Se la direzione sa cosa sta facendo, verrai avanti. In caso contrario, sei senza lavoro, unit test o no.

Qual è il ROI che chiedi? Ritorno sugli investimenti. È un brutto nome però. Deve essere Return On Timely Investment (ROTI), perché il tempismo è tutto negli investimenti.