El Blog de Trespams

Quan hom es planteja un projecte informàtic la primera decisió que s'ha de prendre és quina metodologia seguirem a l'hora de desenvolupar el projecte. Bé, hi ha que dir que potser el que farem és començar passant de tota metodologia (code like hell, que en diuen) però com que aquest escrit anirà damunt metodologies i no damunt l'absència de la mateixa, doncs ho deixaré estar. :)

De la mateixa manera que cada llenguatge de programació nou promet ser la bala de plata que acabi amb tots els mals de la programació i ser el llenguatge de programació definitiu, les metodologies de programació ens prometen poder dur el control dels nostres projectes, millorar-ne la gestió, poder entregar-los en els plaços acordats i deixar satisfet el client. Si algú ha trobat una metodologia que s'adapti a tots el projectes i a tots els equips i que faci tot això, per favor, avisau-me, però tot i així permeteu-me que no m'ho acabi de creure.

En un món ideal el clàssic mètode en cascada seria el millor: analitzan els requisits, en feim un disseny preliminar, aquest s'aprova, feim un disseny detallat on tot està perfectament definit i es comença a codificar. Quan tot està llest s'entrega al client i aquest tot satisfet diu: "perfecte és exactament el que he demanat i és això el que volia". Però clar, això és exactament el que no passa i el que ha fet que s'estigui parlant des de fa temps de la crisi del sofware.

Així doncs s'han anat cercant metodologies de programació que siguin molt més flexibles a l'hora de tractar amb clients reals on les especificacions són poc exactes i on el client no sap exactament el que vol. Estam parlant de projectes amb un risc molt gran, no per la seva gestió, sinó perquè hom no pot estimar la durada del mateix amb unes mínimes garanties. Així s'han de cercar metodologies que ens permetin gestionar l'incertesa, adaptar-nos el més ràpid possible als canvis, ... Les metodologies àgils, com l'extreme programming o el Feature Driven Development intenten ser una resposta a aquest problemes. Unit Test, desenvolupament iteratiu i incremental són pilars fonamentals d'aquestes metodologies

Amb tot la majoria de les metodologies que conec, tant les clàssiques com les més noves tenen un problema fonamental en la seva aplicació: l'escalabilitat per avall. La majoria de metodologies estan orientades a tractar amb projectes grans, amb un nombre considerable de programadors (de l'ordre de cinquanta o més) i quan hom passa les seves indicacions cap a equips de programació petits, de l'ordre de cinc programadors o menys, les tècniques que s'aplicaven a projectes amb molts de programadors deixen d'aplicar-se. Moltes de les metodologies i els seus formalismes tendeixen a solucionar un dels problemes més importants en el desenvolupament de projectes amb molts programadors: la comunicació entre la gent i la seva coordinació. Aquest és un dels riscs més elevats en tot projecte gran i una de les raons de l'augment de la complexitat d'aquest projectes.

Així tractant de miminitzar aquest tipues de problemes s'obliden dels projectes amb un nombre petit de gent. En aquests tipus de projectes podem aplicar tècniques que fan que el rendiment es multipliqui i que sovint no estan contemplades en les metodologies orientades a projectes grans. En un projecte on hi ha implicada poca gent:

• Els problemes de comunicació són mínims si podem situar els nostres programadors en un entorn adequat i pròxims entre si.
• Podem seleccionar millor els nostres programadors. Això vol dir que és més senzill trobar gent per damunt de la mitjana
• Podem aplicar tècniques basades en la regla del 20%. Es a dir, sols farà falta un 20% de la documentació que necessitariem en un projecte gran.
• Podem introduïr abans millores tecnològiques. No és el mateix formar a 50 persones que a 5.
• La consolidació de l'equip es crítica, però a la vegada també és més senzilla de fer.
• Es poden detectar abans els "egos problemàtics"
• Es pot establir una estructura de feina informal on es potencii l'iniciativa personal i la meritocràcia sense que hi hagi problemes de pèrdua de informació o de cohesió en el projecte.
• És molt més bo de fer conèixer a cada integrant del grup i saber-ne els seus punts febles i les seves mancances
• El grau de confiança entre la gent pot ser molt més gran. Més confiança implica millor ambient de feina, millor ambient implica millor productivitat.

En definitiva, ens podem recoltzar molt més en les persones que en la tècnica. La paperassa generada en els equips grans és sovint necessària perquè és sovint la única manera de tractar amb equips de gent on no tothom té la mateixa motivació a l'hora de fer feina (això no s'aplica a projectes voluntaris de codi obert, on la motivació personal és diferent). Aquesta paperassa, però, no és necessària en projectes amb poca gent i la metodologia de programació s'ha d'adaptar a aquesta situació. Per mi una possible recepta seria la següent:

• Lloga la millor gent que puguis pagar. Està demostrat que els bons programadors/es poden rendir fina a 10 vegades més de mitjana i el seu sou no és deu vegades superior
• La feina i l'ambient de feina ha de ser motivador i divertit. Als programadors ens agraden les coses noves. És molt avorrit programar sense innovar i l'avorriment mata la productivitat.
• És important disposar d'un bon equip i això s'ha de compatibilitzar amb el primer punt. La productivitat d'un equip pot ser fins a tres vegades superior a la de la suma dels individuos que el formen.
• La paperassa ha de ser la justa i necessària per l'envergadura del projecte i la gent que hi ha implicada. No hi ha perquè fer un model UML totalment detallat, tots els diagrames de seqüència, etc quan amb un diagrama de les classes de negoci i un parell de reunions formals n'hi ha prou.
• La utilització del CVS i un control d'errors per mi és fonamental. Ara per ara em seria molt difícil concebre un model de programació en grup sense un control de versions.
• La informació del projecte ha de ser pública i a l'abast dels programadors. Tant a nivell d'anàlisi, de les tasques que s'han de fer com dels plaços d'entrega
• S'ha d'establir un sistema de control d'error compartit. Els error s'han de registar per a que cada un pugui aprendre dels errors dels altres
• El codi és comú i la responsabilitat és compartida. Si ho romps ho arregles, però si no hi ets ho faig jo.
• La idea del Feature Driven Development en que que fa a la manera d'organitzar la feina és l'adequada per projectes on el client no sap massa bé el que vol o que hom prevegi que hi haurà força canvis. Dóna l'oportunitat de sempre tenir quelcom que funciona.

Per mi la clau de l'èxit d'un projecte informàtic no és el llenguatge de programació triat, la clau és la gent i com ens corportam els programadors i què ens motiva. Quan es proporciona un entorn adequat un grup cohesionat de programadors bons pot triplicar la productivitat individual pel mateix tipus de projecte. Què vol dir això? Poder abastar projectes destinats a un equip de 15 programadors amb un equip de cinc sense que els plaços d'entrega es multipliquin per tres i arribar a projectes que d'altra manera no s'hi podria arribar.

La bala de plata potser no es trobi tant en la tecnologia, sinó en la gent que ha d'aplicar aquesta tecnologia, en la manera en que gestionam els recursos humans que tenim, en la manera en què seleccionam el personal, en la manera en què feim que aquest personal estigui content amb la feina que fa i amb l'empresa per la que treballa.