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.