Tot i ser un gran devorador de literatura sobre gestió de projectes, hi ha un tema que mai he trobat (o almenys amb l’abast necessari) i és el de com gestionar un microprojecte o un projecte mitja amb un equip molt petit (1 o 2 persones on una d’elles és també el cap de projecte). Podríem dir que aquests escenaris son els més comuns a trobar (sobretot a Espanya) i els menys atesos per les metodologies existents? Per què? Un petit projecte no necessita cap metodologia per a gestionar-se?

Jo crec que per més petit que sigui un projecte, cal un mínim de gestió per a poder respondre les preguntes basiques de que hem de fer? Que hem fet? Quant ens falta? Acabarem a temps? Preguntes que hem de poder respondre per a nosaltres mateixos o per a clients, comercials… El que esta clar que és que aquesta gestió tampoc ha de ser un maldecap afegit a la tasca de desenvolupar de la qual ja en som responsables.

Doncs com que no tot és anar desenvolupant funcionalitats per arribar a tenir una versió per entregar al client i anar omplint els trackers que ens demana el cap per anar comptabilitzant les hores fetes, una de les coses que estic fent és establir una metodologia adaptada a escenaris com el plantejat a partir de metodologies diferents (especialment les àgils) i que pugui quadrar amb els pocs recursos que es dona en general als equips de desenvolupament. Perquè la veritat, en moltes de les empreses per les quals he treballat, és difícil que t’arribin a donar un altre persona per poder fer programació per parelles, o que el el client participi en planificacions d’sprints o…

Quan tingui al document potable, el publicaré en aquestes pagines per a que hi aporteu la vostra visió i experiència.

Avui he llegit una anecdota molt interessant al blog de Pensamientos Agiles, en un post que parla de llibre col.laboratiu que publicarà O’Reilly: “97 Things Every Software Architect Should Know“.

El text diu:

“Las entradas que hay ahora mismo son realmente interesantes, y por comentar una, la más votada de todas (No pongas tu curriculum por encima de los requisitos) me ha recordado a un Arquitecto de Software con el que coincidí y que no dudaba recomendar el utilizar WebSphere MQ y Coherence para una determinada tarea porque le apetecía aprender esas tecnologías. No cabe lugar a duda de la validez de las tecnologías, pero en este caso estas tecnologías no se escogieron, para suerte para el bolsillo del cliente y para las personas que tendrían que lidiar con éstas y disgusto de esta persona en particular.”

Certament, un cas com aquest tots l’hem trobat. Fins i tot jo l’he viscut en la meva etapa més “junior” on deixant-me portar per hypes del moment he arribat a aconsellar productes que han dificultat el desenvolupament del projecte. Evidentment que en un projecte aprendrem coses, però diguem que no és l’espai més adequat per testar noves tecnologies ja que aquesta formació no és (o no hauria de ser) imputable al client i no dominar les eines ens pot fer errar de bastant les nostres estimacions de carrega de treball.

A part, també hi ha el tema dels recursos humans: Sempre serà més fàcil trobar programadors especialistes en alguna de les tecnologies conegudes que d’altres tecnologies hype del moment.

Llegit al blog del IIAP, evidentment es refereix a una gestió de projectes tradicional (no agil). Ho he trobat força interessant, sobretot perque ja és més del que fan moltes empreses amb les que he treballat

Els pasos per la planificació serien:

1. Desenvolupar el WBS (Work Breakdown Structure - segons el PMI, una descomposició jeràrquica de tots els lliurables en lliurables més petits paquets de treball).

2. Preparar una llista de tasques en base als entregables paquets de treball del WBS.

3. Establir duracions i dependencias entre les tasques.

4. Asignar recursos a les tasques.

5. Determinar la ruta crítica del projecte. La ruta crítica seria aquella seqüència de tasques que determina si o si la durada del projecte. Un retras en una d’aquestes tasques es tradueix en un retras del projecte. Es important determinar aquesta ruta per saber a quines son les tasques on podem tenir un cert marge d’error i quines son aquelles a les que hem de dedicar mes esforços i control.

6. Anivellar els recursos: Cal asegurar que els recursos no estan sobreassignats dia a dia. Per això es pot utilitzar la següent tècnica:

• Retrasar tasques no crítiques.
• Assignar un recurs diferent a una tasca.
• Canviar dependencies entre tasques.
• Partir en dos una tasca.

Actualització: A les fases 1 i 2 he canviat el concepte d’entregrables pel de paquets de treball, ja que no tots els paquets de treball es converteixen en un entregable al client.

L’empresa on estic treballant, es proveïdora de continguts e-learning per una important empresa del sector i recentment ens han encarregat la producció d’un nombre elevat de cursos amb uns timing molt ajustats.
Per a millorar la nostre productivitat hem apostat pel desenvolupament d’un framework que transformi XML a SWF per a que persones que no en tinguin ni idea de flash, puguin posar-se a produir contingut.
La realització d’aquest framework s’ha externalitzat i ha costat un bon grapat de milers d’euros, però, estem molt contents del resultat.

El problema està en que no és trivial protegir aquesta inversió:

• No podem evitar que l’empresa que en ha desenvolupat el framework, l’utilitzi per als seus propis desenvolupaments. En certa manera és logic que ho faci.
• Com que nosaltres entreguem totes les fonts al nostre client, ens és impossible separar el “motor” de les pantalles generades, per tant, es molt possible que el client pugui utilitzar el nostre desenvolupament en altres projectes o fins i tot passar el codi a un altre proveïdor en cas que ho vulgui fer.

Així doncs, la solució per la qual jo optaria és la de llicenciar aquest framework sota una llicencia del tipus GPL (no se encara quina). Amb aquesta opció, crec que tots son avantatges per nosaltres.

• Per una banda evitem que algú altre es pugui apropiar del codi.
• Si es fan millores, nosaltres també en gaudirem d’elles.
• Si es crea una comunitat que hi treballa darrera, el projecte s’enriquirà i perfeccionarà. Ja només des del punt de vista de testeig i detecció / reparació d’errors és un gran avantatge.
• I sobretot, és importantíssim prendre la iniciativa en aquest projecte i poder posicionar-nos comodament en el seu lideratge. És bona imatge per l’empresa a la vegada que podem anar definint una mica cap a on volem tirar.

Aquesta és la meva opinió. Pels primers feedbacks obtinguts crec que tirarem més aviat per aquí i a la vegada potser aconsegueixo arrastrar algún que altre producte que tenim. Mica en mica va canviant la mentalitat de les empreses.

Ja postejaré com acaba tot plegat.