Què me costarà…?

Escrit per Aaloy a 25 de July , 2006 a les 8:55 p.m.

A la gent que ens dedicam a la programació i a la gestió de projectes és habitual que ens ens demanin que estimem què costa un projecte en termes d'hores de feina. Cada un pot fer servir el mètode d'estimació que millor li vagi: el dit a l'aire, punts funció, Mark II, estimació per casos d'ús, etc.

Aquests mètodes acaben donant un nombre de mesos home, que hi ha que tenir en compte que segons el que demani el client poc te a veure amb el que costarà realment el projecte.

És a dir, per anar bé, el que hem de donar a més del cost calculat en hores de desenvolupament és el cost del projecte en funció de la gent que hi volguem dedicar i de l'aviat que el client vulgui el projecte.

Hi ha tot un conjunt de taules per fer això, les més útils que he vist són les de McConnell, però a vegades no les tenim a mà. Una opció és anar a aquesta web i consultar-les, però en cas de que tampoc poguem fer-ho, perquè estam davant el client i no es cosa de dir-li, "deixa'm un ordenador i ho miro", convé tenir a mà un petit xul·letari que ens ajudi a sortir del pas, sempre diguent, però, que és una estimació subjecte a una valoració més fina.

Partim de l'estimació hen mesos-home que hem fet, suposem per exemple que li deim al nostre client que el cost de desenvolupament del projecte és de 80 mesos-home, el següent que ens demanarà el client és que quan ho podem tenir. Aquí comença la diversió.

Com a opció inicial li podem presentar la opció de desenvolupament òptim. Aquesta opció ve donada per la fórmula

temps = 3 * (estimació) ^(1/3)

Que el factor multiplicador 3 pot variar segons el coneixement que tinguem de la nostra empresa i de l'equip de desenvolupament. Es recomana que el factor estigui entre 2 i 4.

Així doncs la primera aproximació que li donaríem al client és: 13 mesos amb un equip d'entre 6 i 7 desenvolupadors (80/13). Això vol dir que ja hem estat capaços de donar-li una primera xifra: tant de quan seria òptim tenir el projecte acabat, com de quants desenvolupadors necessitarem per tenir-ho a temps. D'aquí ja es dedueix un cost del projecte, ja que basta multiplicar desenvolupadors pel cost de cada un. Suposem a 2000 Eur per més, tendríem un cost de 14.000 Eur mensuals, és a dir, 182.000 Eur [1]. És a dir, el cost de cada mes home és de 2.275 Eur.

Les coses però no solen funcionar així, els 13 mesos proposats potser són massa pel client, ens demana que ho hauríem de tenir en 8 mesos. El cost en aquest cas no és el mateix, ens estan demanant una compressió dels plaços d'entrega, i això vol dir posar més gent al projecte. El primer que hem de fer és calcular el nou esforç

nou esforç = esforç inicial / factor compressió

En el nostre cas

nou esforç = 80 / (8/13) = 130 homes-mes amb un factor de compressió de 0,615.

Aquí ja tenim un petit problema ja que el factor de compressió més gran que es considera factible està entre 0,75 i 0,80. Siem optimistes i suposem un factor de 0,75, ja que tenim un equip molt bo. Això vol dir que la data d'entrega més optimista que podem donar és de 9,75 mesos, 10 mesos per no anar massa estrets. Si hem fet bé el càlcul de dedicació una data més curta implica anar cap a un "Death March project" i hem de dedicar els nostres millors esforços a fer-ho entendre al client.

Suposem doncs que accepta la nova data, l'eforç que li hem de presentar és ara

nou esforç = 80 / 0,75 = 106,7 mesos-home ~ 107

amb un equip d'onze programadors. Això vol dir pujar el cost del projecte fins als 220.000 Eur.

Són sols quatre números però que ens ajuden a veure com un desenvolupament que s'allunyi d'unes dates d'entrega òptimes s'encareix, bé en termes de cost real o bé en termes de cost en personal, obligat hores extres no renumerades, que es vulgui reconèixer o no a la llarga passa factura a l'empresa. Els pressuposts tancats, doncs s'han de fer no tan sols en termes d'hores calculades, sinó també tenint en compte el cost addicional que hi ha quan escurçam el temps d'entrega.

Així que a la pregunta de què costarà un projecte, hem de demanar a més de les especificacions per poder-ne fer la valoració, el temps en que el client ho vol tenir, i si més no, donar-li l'alternativa d'allargar el desenvolupament i disminuir-ne el cost.

--
[1] Les xifres són redones i inventades, no cal dir-ho supòs.

1 comentari, 0 trackbacks (URL) , Tags: Informàtica


Lectura a la fresca

Escrit per Aaloy a 23 de July , 2006 a les 10:26 p.m.

L'estiu és una bona èpica per llegir, el dia s'allarga i els vespres fa ganes estar una estoneta més a la fresca llegint, sempre i quant els moscarts no ho impedeixin.

Aquest cap de setmana he acabat de llegir el llibre de Joel on Sofware. He de dir que no m'ha decebut. Hi ha alguns capítols fluixets i algunes contradiccions (sobretot quan parla de llenguatges de programació i .Net) però en definitiva el llibre és molt aprofitable. Potser tècnicament no arriba al nivell d'autors com De Marco o McConnell, però té un llenguatge molt proper i entenidor.

Són especialment bons els capítols dedicatas a la gestió de projectes, al test de Joel, del que ja n'he parlat a aquest blog i els consells que dóna referents a la gestió de projectes i desenvolupadors.

Al llarg del llibre Joel posa molt a Microsoft com a exemple de bones pràctiques, de quan ell hi era, diu, però tampoc se n'està de criticar-ho quan fa falta. És força interessant l'anàlisi que fa al capítol 42 quan diu que Microsoft ha perdut la guerra de les APIs. També és molt interessant el capítol que dedica a la microeconomia, és molt de l'estil d'una conferència que va fer Ricardo Galli a les primeres jornades de Bulma a campos. He de dir que tot i que Joel ho explica molt bé la d'En Ricardo era encara millor. No sé si La té publicada a Bulma. En Pau que està en tot m'ha passat l'enllaç

En definitiva, un llibre per tenir-ho aprop i anar rellegint de tant en tant capítols seleccionats. Potser no en treurem moltes dades ni estadístiques del llibre, però segur que raons per fer les coses "com toca".

Com que l'altra dia els d'Amazon es portaren i m'entegaren les comandes força aviat puc seguir amb el mateix tipus de lectura estiuenca. Ara li toca el torn a Walzing with Bears dels autors de Peopleware. L'he començat a fullejar i per ara pinta molt bé. El llibre va de gestió de projectes i concretament de la gestió del risc en els projectes. Una de les primeres idees que hi ha és que si un projecte no té risc no val la pena fer-ho. Qui no s'arrisca no pispa! :)

La veritat és que no sabia si seguir amb Walzing with Bears o amb Death March d'Edward Yourdon. Gestió del risc o com sobreviure a projectes condemnats? He optat per l'optimisme moderat i anar cap a la gestió del risc, la lectura de Death March potser ara mateix encara no me fa falta. Esper que no ho necessiti! :)

3 comentaris, 0 trackbacks (URL) , Tags: Informàtica


Curs de Ruby

Escrit per Aaloy a 18 de July , 2006 a les 1:08 a.m.

Avui hem començat el curs de Ruby organitzat per la CAEB. Per ara la cosa pinta bé. He estat llegint coses del Ruby, especialment des de que hi va haver el boom del Ruby on Rails (RoR pels amics), i un curset de 20 hores com aquest pot ajudar bastant a aclarir coses. Encara que hi ha força informació a la xarxa és molt més interessant i productiu que t'ho conti algú com en Guillem que anar-te cercant la vida tu mateix.

Aquests darrers dies han aparegut algunes compartives interesants damunt els bastiments de persistència basats en el model MVC que han sorgit recentment:

La primera compara Django, RoR i un bastiment MVC per PHP anomenat Symfony. La segona compara Django amb una altra bastiment molt més 'a la Rails' però fet amb Python com és Pylons.

Personalment he de dir que m'agrada molt la claritat que té Django i me n'alegra comprovar que és el bastiment que surt més ben parat de les comparatives. Tot i això en totes podem veure que qualsevol dels bastiments aguanta prou bé una càrrega que ja la voldria qualsevol pel seu web. A més la quantitat de peticions que és capaç d'aguantar el bastiment depén també de la màquina, amb la qual cosa tenim que podem augmentar moltíssim el nombre de peticions que podem aguantar sols fent una inversió major en la màquina.

En Joel Spolsky apunta al seu blog una presentació feta per Sean Kelly de la NASA comparant Django, Rails, Zope, TurboGears i J2EE i ens avisa als programadors de J2EE que després de veure la presentació mai més voldrem saber res de J2EE per fer aplicacions web.

Bé, ara per ara encara m'estic devallant la presentació (ONO no m'ha volgut/pogut posar la connexió a casa i encara estic amb una ADSL, però això és un altra tema), però amb el que ja conec d'aquests bastiments i el que conec de J2EE no crec que me n'endugui cap sorpresa. Per moltes aplicacions la complexitat que suposa el J2EE no és necessària, més quan la suposada escalabilitat que ens dona el J2EE es veu superada amb una mínima inversió en màquina i fent servir un d'aquests bastiments.

Sovint el problema és convèncer a uns i altres de que la solució basada en lleguatges dinàmiques és més adeqüada per aquell problema que la basada en J2EE, però clar, tenim el problema de la uniformitat i dels consultors. La uniformitat en tant en quant pareix que els programadors sols han de ser especialistes en un sol llenguatge i els consultors que defugen de recomanar qualsevol cosa que no soni a J2EE i que són els mateixos que fa un grapat d'anys lloaven les meravelles dels EJBs.

Estam anant al curs de Rails perquè encara que no sé si el farem servir a l'Empresa, segur que no ens farà gens de mal conèixer un nou llenguatge, sempre se n'aprenen coses i pots agafar moltes idees. Si sols conèixes un llenguatge la teva programació es veu massa condicionada pel que es pot fer en aquell llenguatge i deixes d'explorar altres alternatives potser més adients. Personalment crec que hi haurà certes aplicacions, especialment les que han de connectar amb bases de dades existents que són més senzilles de fer anar amb tecnologia J2EE de cotenidor fi (Hibernate+Spring+Jsp damunt Tomcat) i que d'altres és molt millor desenvolupar-les amb qualsevol dels bastiments de les comparacions anteriors.

La falta d'uniformitat no és un inconvenient, és un avantatge competitiu en aquests casos, ara sols falta convèncer als consultors ...

3 comentaris, 0 trackbacks (URL) , Tags: Informàtica


Joel On Sofware: El llibre

Escrit per Aaloy a 07 de July , 2006 a les 5:09 p.m.

L'altra dia vaig rebre del llibre de Joen on Sofware via Amazon. El llibre, publicat per l'editorial Apress recull bona part dels articles publicats per Joel Spolsky al seu blog. [3]

Tot i que els articles es poden llegir directament per la web, tenir un recull així en format llibre és molt interessant, més aquests dies d'estiu, on tenir un llibre i llegir-ho a la fresca és molt més còmode que tenir l'escalforeta del portàtil (per que en tengui).

L'estic fullejant i me pareix que disfrutaré molt de la lectura. Aquest home és un gran comunicador, amb unes idees força interessants [1]. Per exemple, a un dels articles que he anat per atzar, tracta de l'inutilitat de gestionar un projecte amb un sistema Microsoft Project. Que el programa sigui de Microsoft o sigui el project tant fa, la idea és que un gestor de projectes d'aquest estil encaixa molt malament amb el desenvolupament de programari. Hi estic totalment d'acord. Darrerament sols faig servir el Planner o el DotProject per poder fer el dibuixet inicial, després la gestió del projecte és molt més senzilla de seguir amb eines com Trac o directament amb un sistema de ticketing.

Els de Debian supòs també són de la mateixa opinió, ja que pel que explicà n'Amaya i n'Adeodato a les Jornades de Bulma, tot allà es fa mitjançant un ticket al Bugzilla.

Com deia, el bo que té aquest autor és la claretat amb que s'expressa. En aquest tema, per exemple, justifica que no fa falta cap project perquè la gent, els programadors, no sóm intercanviables. Que corregir un error duu molt més temps a algú que no ha fet el codi que a l'autor, que un expert en web services [2] no és fàcilment substituïble per algú que fins el moment s'ha estat encarregant de la capa de persistència. Així doncs un dels punts forts d'aquests programes de gestió, com és l'assignació de recursos resulta que no es pot fer servir.

L'altra punt fort dels programes de gestió de projectes és el de les dependències. Poder canviar i gestionar dependències es ven com un gran avanç. Tal com diu Joel a l'article en programació les dependències solen ser tan obvies que gairebé no fa falta ni tenir-ne cura del seguiment. Complilareu el programa si encara no l'heu codificat? Els gestors de projectes animen a posar una dependència en aquestes fases, però es tan obvi que resulta un poc còmic.

Supòs que hi haurà gent que dirà que els projectes de programació sí que es poden controlar perfectament amb un Project, però m'agradaria saber el nombre de projectes que se'ls han retrassat, o com poden controlar la feina que fa cada programador sense tenir que anar cada matí a fer la ronda.

El sistemes com Trac o la gestió de projectes mitjançant sistemes de Ticketing permeten conèixer l'estat del projecte veient la feina que s'ha fet cada dia, els tickets que s'han tancat, els tickets que queden, si han aparegut nous errors. Està clar que això implica més feina, s'ha de ser curós a l'hora d'entrar-ho tot com a ticket, però a canvi tenin um projecte molt més controlat i no un sols dibuixet amb barretes de colorins.

--------------
[1] I va fer feina per Microsoft!
[2] Està més de moda que els sockets que fa servir Joel a l'article :)
[3] Les gràcies novament a Juan Moreno per passar-me l'enllaç.

0 comentaris, 0 trackbacks (URL)