Usuari:Alvaro Berruezo/proves

Experiències i aprovació

Enquestes

S'han realitzat diverses enquestes en termes de qualitat, productivitat i satisfacció general de l'empresa. L'enquesta anomenada l'estat de la metodologia àgil o l'estat d'àgil es realitza cada any des de 2006 amb milers de participants de la comunitat de desenvolupament de programari. Dels resultats de les enquestes de 2013 es pot concloure que el 73% dels enquestats creuen que àgil ajuda a completar projectes més ràpid; el 92% creu que àgil millor l'habilitat per controlar canvis en el les prioritats dels clients; i el 87% pensa que l'àgil millora la productivitat del seu equip de desenvolupament. Un altra enquesta realitzada anteriorment al 2006, destaca beneficis similars.

Àgil a gran escala i distribuït

El desenvolupament de programari a gran escala amb l'àgil continua sent avui dia un àrea de recerca activa. El desenvolupament amb l'àgil s'ha vist com el més adequat per a determinats entorns, incloent-hi petits equips d'experts. Amb tot això, l'àgil ha tingut una bona recepció a tota Europa durant els últims anys.

No obstant, alguns aspectes que poden influenciar negativament en l'èxit d'un projecte àgil són:

• Els desenvolupaments a gran escala (més de 20 desenvolupadors).
• Desenvolupaments distribuïts a llocs diversos (sense emplaçament comú).
• El fet de forçar un projecte per sistemes crítics, com pot ser programari per aviònica, és una opció arriscada.

Problemes freqüents amb l'àgil

Els equips que implementen àgil sovint tenen dificultats en la transició de mètodes més clàssics com el desenvolupament en cascada. Alguns dels problemes enfrontats per equips d'implementació de processos àgils són els següents:

Afegir històries a un sprint en progrés. És perjudicial pel flux establert per l'àgil. Scrum certament ofereix provisió per canviar les prioritats del backlog de producte a meitat de projecte, no obstant això això ha de passar entre els sprints i no durant. Si hi ha un problema que es planteja que requereix afegir-se, és millor una finalització anormal de l'sprint. Això no vol dir que la història d'un usuari no pugui ser expandida. Els equips han fer front a la nova informació que pot resultar en tasques addicionals per a una història d'un usuari. Si la nova informació impedeix que la història d'un usuari sigui llegida durant l'sprint, llavors s'hauria de dur a terme al següent sprint. No obstant això, durant la següent planificació d'sprint, aquesta història ha de ser la de major prioritat respecta les altres històries.

Falta de suport dels patrocinadors: Àgil sovint s'implementa com un esforç base en les organitzacions pels equips de desenvolupament de programari que tracten d'optimitzar els seus processos de desenvolupament. Al no tenir el suport del patrocinador, els equips poden tenir dificultats i resistències per part dels socis de negoci o per part d'altres equips de desenvolupament i gestió.

Entrenament insuficient: Una enquesta realitzada per Version One troba als enquestats la insuficiència d'entrenament com la causa més important de fracassos en projectes àgils. Els equips cauen en la trampa d'assumir els processos de reducció en comparació amb altres metodologies com la cascada. Això vol dir que no hi ha regles específiques per àgil. Per altra banda, l'entrenament i formació és un requisit indispensable per dur a terme àgil.

El paper del propietari del producte no està ben definit. El propietari del producte és responsable de representar a l'empresa en l'activitat de desenvolupament. Un error comú és tenir el rol de propietari del producte fixat per algú de l'equip de desenvolupament. Fer que l'equip de desenvolupament ocupi aquest rol resulta en què l'equip pren les seves pròpies decisions sense una comunicació real per part de l'empresa. A més a més, les qüestions d'empreses s'intenten resoldre internament o bé hi han retards a l'hora de comunicar-se exteriorment. Aquests problemes poden resultar en problemes interns i desviar el procés de col·laboració dirigit per àgil.

Els equips no estan focalitzats. El procés àgil requereix que els equips que estan realitzant el projecte siguin conscients dels compromisos del projecte. S'espera que durant un sprint pugi haver una tasca que no sigui de l'àrea del desenvolupador. Encara que si els membres de l'equip tenen múltiples projectes que serà difícil per a qualsevol capacitat addicional que estigui disponible per ajudar a completar l'sprint.

Excés de preparació i/o planificació. Els equips poden dedicar massa temps en planificar o preparar les tasques. Aquest és un error comú per equips menys familiaritzats amb el procés àgil on els equips se senten obligats a comprendre completament detalladament totes les històries dels altres usuaris.

Resolució de problemes. L'Scrum diari està destinat a ser una reunió ocasional amb tots els membres de l'equip per disseminar informació. Si la resolució de problemes ocorre sovint pot involucrar a diversos membres del grup el qual no és el millor ús del temps.

Assignació de tasques. Un dels beneficis de l'àgil és la pressa de decisions en front als problemes. A més, les decisions s'han de fer properes a la implementació a diferència del tradicional mètode de la cascada. Si als membres de l'equip se'ls assignen tasques per altres o massa d'hora en el procés, llavors els beneficis de la presa de decisions es poden perdre. Una altre problema és la correcta assignació de tasques de manera que encaixin en determinats rols. Els propis membres del equip han de poder escollir les tasques més adients per les seves habilitats.

L'ScrumMaster com a contribuïdor. Encara que no està prohibit per l'àgil, l'ScrumMaster s'ha d'assegurar que té la capacitat d'actual com a cap primer i no treballar en les tasques del projecte. El lloc d'ScrumMaster serveix per facilitar el procés d'Scrum. Tenir l'ScrumMaster fent multi tasca pot resultant en massa canvis de context per a ser productiu. Pot perjudicar a la capacitat de l'ScrumMaster per desfer tasques bloquejadores.

Falta d'automatització de proves. Degut a la naturalesa iterativa del mètode àgil les múltiples proves per projectes són sovint necessàries. L'automatització de mètodes d'assaig també suporta la continua refactorització requerida per un mètode iteratiu de desenvolupament de programari. No obstant a vegades treu massa temps als programadors pel qual no es fa sempre. Per altra banda l'automatització de proves també és compatible amb la refactorització contínua requerida pel desenvolupament de programari iteratiu. Permetent que un desenvolupador executi ràpidament les proves per confirmar que la refactorització no ha modificat la funcionalitat de l'aplicació pot reduir la càrrega de treball i augmentar la confiança en què els esforços de neteja no han introduït nous problemes.

Permetre l'acumulació de deute tècnic. El fet de centrar-se en lliurar una nova funcionalitat pot resultat en un deute tècnic acumulat. Els equips han de permetre's un temps per solucionar defectes i refactoritzar. El deute tècnic obstaculitza les habilitats per planejar incrementant el nombre de tasques no programades com a defectes de producció, el qual desvia l'equip del progrés del projecte.

Intent de prendre's en excés un sprint. Un concepte freqüentment confós en l'ús d'àgil és que permet el canvi continu. El backlog d'un sprint es un conjunt de feina que pot ser realitzada durant l'sprint. No necessàriament s'han de dur a terme totes les tasques. Tampoc hi pot haver un canvi continu perquè pot resultar en ineficiències degut a temps perdut, esforços i recursos invertits.

Temps fix, els recursos, abast i qualitat. L'àgil fixa un temps (la duració de l'sprint) i uns recursos mentre que l'abast i la qualitat es mantenen variables. El client o el propietari del producte sovint suggereix per un abast fix per a un determinat sprint. No obstant, els equips han d'estar preparats per gestionar el temps, els recursos i l'abast (conegut com Triangle de la gestió de projectes). Tractar d'afegir abast al temps fixat recursos de l'àgil pot resultar en la disminució de la qualitat del producte.