Content
- Per què l’Àgil TI?
- Com aborda la metodologia àgil els problemes del model de cascada?
- Com ha afectat àgil la indústria informàtica?
- Sense errors, sense estrès: la vostra guia pas a pas per crear programes que canvien la vida sense destruir la vida
- Raons BT es van traslladar a pràctiques àgils
- Mala gestió dels requisits
- Disseny deficient de programari
- Restriccions de desenvolupament
- Què va fer BT per solucionar els problemes anteriors?
- Conclusió
Font: Darkovujic / Dreamstime.com
Emportar:
Per a molts, el model de desenvolupament de programari de cascades ha estat l'estàndard durant dècades, però ara s'està substituint per la metodologia àgil, molt més flexible.
La metodologia àgil per al desenvolupament de programari pot afectar positivament la indústria informàtica. Els resultats de l’adopció de metodologia àgil es poden mesurar de diverses maneres. Un canvi ràpid de les sol·licituds de canvi de programari, menys errors, la mesura quantitativa del rendiment de l’equip i els colls d’ampolla són tot un reflex de la implementació exitosa d’Agile. Per mesurar l'impacte d'Agile, una organització ha de comparar diverses mètriques relacionades amb el desenvolupament pre-àgil i el post-àgil. L’impacte real d’Agile no es pot mesurar només amb l’augment d’ingressos o l’augment del nombre d’errors solucionats. Cal tenir en compte diversos paràmetres interns per comprendre l'impacte real. (Per obtenir més informació sobre el desenvolupament àgil, vegeu Agile Software Development 101.)
Per què l’Àgil TI?
La indústria informàtica s'ha inclinat cap a les pràctiques àgils, principalment a causa de les restriccions del model de desenvolupament de programari en cascada. Generalment, s'ha observat que les empreses informàtiques no són capaços de respondre a les exigències canviants dels clients o de les situacions del mercat ni de reduir costos amb el model de cascada del desenvolupament de programari. Fins i tot si contrabalançem aquesta inclinació aclaparadora cap a la metodologia àgil i considerem que l’al·lusió només es presenta, hi ha molta retroalimentació empírica contra el model de cascada.
En poques paraules, el model de cascada és un model de desenvolupament de programari on el treball es realitza de forma seqüencial: una fase rere l’altra. Hi ha cinc fases d’aquest model: requisits, disseny, implementació, verificació i manteniment. Normalment, un cop finalitzada una fase, és difícil, si no és impossible, fer canvis a una fase anterior. Per tant, el supòsit és que els requisits estan pràcticament fixats. La diferència principal amb el model Agile consisteix en el supòsit que no hi haurà cap canvi en els requisits. Àgil assumeix que les situacions empresarials canviaran i també ho faran els requisits. De manera que el programari es lliura en fragments més petits per ss, mentre que, en el model de cascada, el primer lliurament o alliberament es fa després de molt de temps. (Per obtenir més informació sobre el desenvolupament, vegeu Com Apache Spark ajuda al desenvolupament d’aplicacions ràpides.)
La crítica més destacada contra el model de cascada ha estat la suposició que no hi haurà cap canvi en els requisits. La mateixa suposició és defectuosa i irreal. Per exemple, el 2001, un estudi sobre 1.027 projectes informàtics als EUA va demostrar que aquesta suposició era el motiu més gran del fracàs dels projectes informàtics.
En un altre exemple, Craig Larman, l’autor del llibre "Agile and Iterative Development: A Manager's Guide", ha assenyalat com una sèrie de projectes executats pel Departament de Defensa (DoD) amb el model de cascada dels EUA no han aconseguit assolir els seus objectius. Al llarg dels anys vuitanta i noranta, la DoD va ser obligada a utilitzar el model de cascada per als seus projectes de desenvolupament de programari segons els estàndards publicats a DoD STD 2167. Les estadístiques impactants van revelar que el 75% d'aquests programes no es van utilitzar mai. Després d'aquest informe, es va posar en marxa una colla de treball del Dr. Frederick Brooks, un conegut expert en enginyeria de programari. El grup de treball va aparèixer amb un informe que va comentar que “DoD STD 2167 també necessita una revisió radical per reflectir les bones pràctiques modernes. El desenvolupament evolutiu és tècnicament millor i estalvia temps i diners ”.
Els quatre supòsits següents del model de cascada havien fracassat en els escenaris del món real:
- Els requisits donats estan raonablement ben definits i, per tant, no canviaran significativament.
- Fins i tot si els requisits canvien durant la fase de desenvolupament, seran prou petits perquè s’acomodin dins del cicle de desenvolupament.
- La integració del sistema, que es produeix després del lliurament del programari, es desenvoluparà segons el pla.
- La innovació del programari i l’esforç necessari per innovar es realitzaran segons un calendari previst i previsible.
Com aborda la metodologia àgil els problemes del model de cascada?
La metodologia àgil és fonamentalment diferent del model de cascades i això es desprèn dels seus supòsits:
- Ningú, ni tan sols el client, pot conèixer o comprendre els requisits. No hi ha garantia de que els requisits no canviaran.
- Els canvis de requisit poden no ser petits i manejables. De fet, vindran en diverses mides i continuaran venint. Per tant, el programari es lliurarà en petits increments per fer un seguiment dels canvis.
Com ha afectat àgil la indústria informàtica?
Àgil s'està adoptant en molts llocs, mentre que moltes empreses estan planificant l'adopció d'Agile. Malgrat que Àgil ha fet canvis fonamentals a la indústria informàtica, els fets i les xifres són encara una mica difícils d’obtenir. Però l’impacte d’Agile es pot entendre amb l’estudi de cas de British Telecom (BT) que es presenta a continuació.
Sense errors, sense estrès: la vostra guia pas a pas per crear programes que canvien la vida sense destruir la vida
No podeu millorar les vostres habilitats de programació quan ningú es preocupa per la qualitat del programari.
Raons BT es van traslladar a pràctiques àgils
BT va començar a experimentar diversos problemes amb les seves pràctiques de desenvolupament de programari des del 2004. BT va desenvolupar diversos projectes de programari, tant simples com complexos. Molts projectes de programari no van poder desenvolupar una producció de qualitat en el termini acordat. BT va trobar que els problemes devien les seves arrels al model de cascada. Així doncs, reforçar el model de cascada no va ajudar. A continuació, es descriuen les principals causes dels problemes:
Mala gestió dels requisits
- S'han donat massa requisits per complir-se en un termini massa limitat.
- Molts requisits eren irrellevants per a les necessitats del negoci.
- Gairebé tots, si no a tots els requisits, se'ls assignava un estatus d'alta prioritat.
- Els requisits representaven les necessitats empresarials actuals sense tenir en compte els escenaris futurs. Això va deixar oberta la possibilitat de futurs canvis de programari.
Disseny deficient de programari
- Tenint en compte la gran quantitat de requisits, els dissenyadors van passar massa temps només intentant esbrinar què significaven els requisits. Es va deixar poc temps per al disseny real.
- Els analistes de requisits es van traslladar a altres tasques, i van tenir coneixement no tàcit i no escrit.
- Els dos factors anteriors van donar lloc a un disseny deficient. Els dissenyadors encara havien de lliurar segons la línia de temps original.
Restriccions de desenvolupament
La codificació va ser precipitada i de mala qualitat a causa del disseny defectuós de programari. Els desenvolupadors s'adonarien que un disseny de programari deficient donaria lloc a un codi deficient, però, tot i així, s'havia de lliurar segons el calendari acordat. Es van notificar molts errors durant la integració perquè no es van executar proves de unitat ni proves de regressió.
Quan es desplega el programari, el client constata que els requisits ja han canviat i també passa amb l'escenari empresarial. El programari també presenta molts problemes. Efectivament, tot l'esforç del desenvolupament de programari es considera malgastat.
Què va fer BT per solucionar els problemes anteriors?
BT es va adonar que reforçar el model de cascada no era la resposta als problemes. Necessitava un nou enfocament. Així doncs, va decidir implementar l’enfocament àgil. Segons el nou enfocament, es van decidir les següents qüestions:
- En lloc del cicle de desenvolupament de dotze mesos, BT ara lliuraria peces de programari viables en un cicle de 90 dies. La idea era centrar-se en un o dos problemes comercials i orientar-se a lliurar una solució de programari en un termini de 90 dies. L’inici d’aquest cicle va estar marcat per una intensa discussió entre diferents parts interessades de manera que es van identificar, analitzar i prioritzar els requisits clarament.
- L’objectiu era proporcionar valors empresarials clars i tangibles. El client intern estava sota pressió per proporcionar uns requisits clars. Així, en lloc d'objectius vagos, es van donar històries d'usuaris amb criteris d'acceptació clars.
- El programari que es lliuraria seria completament provat i documentat. El programari passaria per proves d'integració freqüents per identificar problemes abans.
Amb l’enfocament àgil, BT es podria adaptar als canvis de requeriments o situacions empresarials amb més facilitat. La qualitat del codi va millorar i es van solucionar els errors bàsics d’última hora.
Conclusió
Àgil, per tots els seus avantatges i el bombo que hi ha al seu voltant, encara es troba en una etapa en què el seu potencial no es troba plenament realitzat. Això es deu al fet que moltes organitzacions estan personalitzant l'enfocament fins a l'extensió de modificar els seus principis originals. Com a resultat, en alguns casos, el model de cascada està tornant. Si bé la personalització continuarà, és important mantenir els principis bàsics d'Agiles. Moltes organitzacions asseguren ser totalment àgils, però encara tenen algun camí per recórrer per convertir-se en una empresa realment àgil.