Sull’Interpretazione Dei “Giorni Uomo”

Nel contesto della consulenza software, la fatidica domanda “quanto tempo serve per terminare questo sviluppo” è più pericolosa di quello che possa sembrare, perché diversi stakeholder daranno diversi significati alla risposta. Così diversi che sarà anche sottointesa un’unità di misura diversa ad una risposta sia tipicamente espressa in giorni.

Ipotizziamo che il Professionista IT, che per conto della propria azienda di consulenza segue un progetto da un cliente affermi che “lo sviluppo delle nuove feature sarà terminato in 10 giorni”, intendendo un effort misurato in giorni uomo. Quindi immagina che lavorandoci saltuariamente con un collega, per portare avanti anche altre commesse, possa pubblicare in produzione le nuove feature tra una ventina di giorni, garantendo comunque che l’effort del reparto di sviluppo si attesti sui 10 giorni.

Il Collega del professionista, anche lui assegnato al progetto, capisce invece che si hanno ancora 10 giorni di tempo per lavorare al progetto, indipendentemente dal numero di persone che saranno coinvolte e questo lo rincuorerà poiché, vista la scadenza così prossima, e visto che quella routine proprio non sa come scriverla, sarà possibile delegare il gravoso compito a qualche altro collega.

Il Commerciale dell’azienda IT deve ovviamente assicurarsi che l’attività sia abbastanza redditizia per coprire non solo il costo di sviluppo ma anche una quota parte delle spese aziendali: l’affitto dell’ufficio, i costi di gestione, oltre che assicurare un’ovvia remunerazione. Il manager decide quindi di applicare un markup alla stima del professionista, proponendo al cliente una quotazione nella quale per trasparenza indica che l’effort sarà di 15 giorni uomo.

Il Manager lato cliente conosce il costo del progetto, e sapendo in quanto tempo sarà consegnato, con una rapida divisione calcola il costo giornaliero del professionista. Ottiene una cifra che tipicamente reputa troppo alta per il costo di uno sviluppatore e chiede quindi uno sconto all’azienda IT sulla quotazione del progetto perché comprende che la logica da sviluppare sia complessa, ma quel compenso giornaliero supera ogni limite di costo ragionevole.

Il PM del cliente, a cui il professionista riporta, pressato da più fronti, intende che le feature saranno rilasciate in produzione al massimo entro 15 giorni, che sarà considerato un lasso di tempo troppo lungo, quindi chiede di restringere i tempi di consegna a 10 giorni.

L’Esperto IT del cliente chiederà una riunione nella quale al professionista sarà chiesto di giustificare come mai lo sviluppo è stato quotato in 15 giorni, quando dalla sua esperienza, potrebbero tranquillamente bastarne 10. Il professionista, dal canto suo, sarà in linea di massima concorde con l’esperto del cliente ma dovrà arrovellarsi per ideare delle giustificazioni tecniche che giustifichino la stima comprensiva di mark up presentata dal proprio commerciale.

Tutto questo accade perché le varie figure coinvolte danno al concetto di tempo un significato totalmente diverso tra loro.

Per il Professionista la risposta è espressa in “giorni uomo previsti del team di sviluppo”. E’ una misurazione del tempo durante il quale gli sviluppatori dovranno impegnarsi per lo sviluppo del progetto. Il Professionista avrà anche incluso in questa misura un cuscinetto temporale per garantire di consegnare il lavoro entro il tempo espresso quindi più correttamente il Professionista intende la risposta come quel periodo di tempo che con una confidenza del 90% gli sviluppatori dovranno spendere nel progetto per garantire il rilascio delle funzionalità.

Per il Collega, i dieci giorni sono semplicemente dieci giorni di calendario. Se la consegna del progetto acquisisse una priorità altissima, egli sarebbe giustificato a pensare che l’Azienda dovrebbe includere nel progetto un numero illimitato di nuovi sviluppatori, a patto di rispettare la data di consegna, tra dieci giorni.

Per il Commerciale, la risposta da dare al Cliente, sentito il parere del Professionista, “è quell’ammontare di giornate che al costo per sviluppatore giornaliero preconcordato con il Cliente garantisce un’adeguata copertura dei costi e remunerazione”. E’ interessante notare come per il Commerciale, quindi, la “giornata” sia semplicemente un’unità di misura di valuta. Non euro, ma giornate, quindi.

Per il PM i quindici giorni sono, nello scenario migliore, il lasso di tempo entro il quale potrà smarcare l’attività come completata. Essendo lo scenario migliore, tuttavia, il tempo di completamento sarà in realtà aumentato del 50% nel progetto come misura precauzionale, allungando quindi l’attività a 21 giorni.

Il Manager del Cliente intende i 15 giorni come il costo economico della sola attività di sviluppo, dimenticandosi che ogni attività con scopo di lucro prevede ovviamente un margine economico. Eseguendo una semplice divisione ottiene un prezzo legato all’attività di un singolo sviluppatore che ritiene troppo elevato.

Infine l’Esperto IT del Cliente, intende i 15 giorni come puro effort, proprio come il Professionista, che però ne aveva stimati solo 10. L’Esperto ed il Professionista si confronteranno quindi su uno scostamento delle rispettive stime del 50% quando in realtà sono d’accordo almeno sul significato da dare alla quotazione su cui stanno discutendo.

Questo è quanto può accadere, nel peggiore dei casi, quando non c’è univocità nell’interpretazione dell’effort o precisione nella definizione dei termini o chiari rapporti tra fornitore e cliente.

 

 

 

Diff in Java

A workmate of mine is currently deep involved in a big deploy. He has to take a huge amount of sql scripts out of our SCM, check them manually to discover if the other programmers have followed the internal coding standard and fix them if this is not the case.

While it is still a mistery to me why nobody though to it, I started the development of a small tool that could possibly automatically check and fix all the errors.

Part of this tool is a diff style window that show the user what the tool is fixing. It seems that diff in Java is a quite required feature, so, here’s my solution.

Obviously I didn’t reinvented the weel and my implementation is 100% based on the one published on wikibooks. My implementation consist of a couple of class.
The first one is able to give access to strings line by line.

  1. public class LineFile {
  2.  
  3.  private List lines;
  4.  
  5.  public LineFile(InputStream in) {
  6.   try {
  7.    lines = IOUtils.readLines(in);
  8.   } catch (Exception e) {
  9.    throw new RuntimeException(e);
  10.   }
  11.  }
  12.  
  13.  public LineFile(File f) {
  14.   try{
  15.    lines = IOUtils.readLines(new FileInputStream(f));
  16.   }catch(Exception e){
  17.    throw new RuntimeException(e);
  18.   }
  19.  }
  20.  
  21.  public LineFile(String from) {
  22.   try {
  23.    lines = IOUtils.readLines(new ByteArrayInputStream(from.getBytes()));
  24.   } catch (IOException e) {
  25.    throw new RuntimeException(e);
  26.   }
  27.  }
  28.  
  29. public String lineAt(int index){
  30.  if(index>=0 && index<lines.size()){
  31.  return lines.get(index);
  32.  }
  33.  return null;
  34.  }
  35.  
  36.  public int lines() {
  37.  return lines!=null ? lines.size() : 0;
  38.  }
  39. }

The second one is the actual implementation of the diff algorithm, and is based on considering each line as the most little element the algorithm can consider.

  1. public class LineFile {
  2.  
  3.  private List<String> lines;
  4.  
  5.  public LineFile(InputStream in) {
  6.   try {
  7.    lines = IOUtils.readLines(in);
  8.   } catch (Exception e) {
  9.    throw new RuntimeException(e);
  10.   }  
  11.  }
  12.  
  13.  public LineFile(File f) {
  14.   try{
  15.    lines = IOUtils.readLines(new FileInputStream(f));  
  16.   }catch(Exception e){
  17.    throw new RuntimeException(e);
  18.   }
  19.  }
  20.  
  21.  public LineFile(String from) {
  22.   try {
  23.    lines = IOUtils.readLines(new ByteArrayInputStream(from.getBytes()));
  24.   } catch (IOException e) {
  25.    throw new RuntimeException(e);
  26.   }
  27.  }
  28.  
  29.  public String lineAt(int index){
  30.   if(index>=0 && index<lines.size()){
  31.    return lines.get(index);
  32.   }
  33.   return null;
  34.  }
  35.  
  36.  public int lines() {
  37.   return lines!=null ? lines.size() : 0;
  38.  }
  39. }

Finally, to give you an idea of how it performs, here’s a couple of screenshots from the application.

If you need more details regarding the code, don’t hesitate and drop me a message!

Good environment variable values during iPhone development

Directly from GHUnit, a small note about which environment variables to set while developing for the iPhone.

Environment Variable:                 Default:  Set to:
NSDebugEnabled                           NO       YES
NSZombieEnabled                          NO       YES
NSDeallocateZombies                      NO       NO (or YES)
NSHangOnUncaughtException                NO       YES
NSAutoreleaseFreedObjectCheckEnabled     NO       YES

Actually, I keep forgetting them, so I hope this will be useful to me.

Here an example that shows how to set those environment variables.

Setting iPhone development variables in XCode

Get rid of folder that should not be versioned

If you work with subversion, for sure you had the problem to tell to subversion to ignore a folder inside your working copy. This happens for example if your IDE builds the sources in a folder inside your working copy. From the very first commit you’ll start noticing that subversion wants to add that “build” folder to your repository. But, obviously, this is not a good practice.

So you can tell subversion to ignore a folder. Just move in the folder that contains the folder you want to be ignored by subversion and type the following command.

svn propset svn:ignore <dir_you_want_to_be_ignored> .

The “dot” at the end is important! It means you’re specifying which folders of the current folder you want to be ignored.

Please note that <dir_you_want_to_be_ignored> should be written without trailing slashes. So for example if you want the build directory not to be managed by subversion, type…

svn propset svn:ignore build .

And not…

svn propset svn:ignore build/ .

This is a quick tip. I always forget how to do it, so I wrote that little note.

Chosing the number of decimal digits when printing a number with iPhone

This is a small snippet, useful whenever you want to convert a floating point number in a string with a fixed number of decimal digits.

NSNumberFormatter *format = [NSNumberFormatter new];
 [format setMaximumFractionDigits:1];
 NSNumber *aNumber = [[NSNumber alloc ] initWithDouble:54.4235264];
 NSString label = [[NSString alloc] initWithFormat:@"The number is %@", [format stringForObjectValue:aNumber]];
 [distance release];
 [format release];

Obviously the NSNumberFormatter class offers plenty of other method you can use to customize the way your numbers should be rendered.