Relevant papers, articles and ideas translated by novel translators,
as part of their Language Internship Program at Ibidem Group.
as part of their Language Internship Program at Ibidem Group.
El desenvolupament basat en el comportament (sigles en anglès: BDD) és una metodologia “outside-in”. Comença des de fora identificant resultats de negoci i després aprofundeix en el conjunt de característiques que aconseguiran aquests resultats. Cada característica es plasma en una “història” que defineix l’abast de la característica, conjuntament amb els seus criteris d’acceptabilitat. Aquest article presenta l’enfocament del BDD per definir i identificar històries, i els seus criteris d’acceptabilitat.
El desenvolupament de programari consisteix en la creació de programari específic per aconseguir resultats de negoci. Sembla obvi, però sovint hi ha factors polítics o ambientals que fan que ens n’oblidem. De vegades, pot semblar que el desenvolupament de software només serveixi per generar informes optimistes perquè la direcció estigui contenta o per mantenir ocupats els treballadors, però d’això ja en parlarem un altre dia.
Normalment, els resultats de negoci són massa amplis per posar-se a programar directament (per on es comença si el resultat és “estalviar un 5 % dels costos operatius”?). Cal, doncs, definir els requisits a un nivell intermedi per poder posar-nos mans a l’obra.
El desenvolupament basat en el comportament (BDD) se centra en la idea que qualsevol requisit pot convertir-se en un codi implementat, provat i llest per ser utilitzat de forma simple i efectiva, sempre que el requisit sigui prou específic perquè tothom entengui de què tracta. Per fer-ho necessitem trobar la manera de descriure el requisit perquè tothom (empresaris, analistes, desenvolupadors i testers) entengui de la mateixa manera l’abast del treball. A partir d'aquí ells ja es poden posar d’acord sobre què entenen per “resolt” i així ens estalviem confrontacions posteriors de l'estil de “això no és el que volia” o “vaig oblidar-me de dir-te això”.
Aquest, doncs, és el paper d’una història. Ha de ser la descripció d’un requisit i el seu benefici de negocis, amb tot un seguit de criteris per establir que s’ha “resolt”. Es tracta d’una definició més rigorosa que altres metodologies més àgils, en què es descriu com a “promesa d’una conversa” o “descripció d’una característica”. Una història BBD pot descriure simplement un requisit no funcional, sempre que aquest treball estigui a l’abast de l'empresa i s’hi estigui d’acord.
El BDD proporciona una estructura per a una història. De totes maneres, no és obligatori. Podeu utilitzar un format diferent i que se segueixi considerant BDD, però presento aquest model perquè s’ha demostrat que funciona en projectes de tot tipus. Com a mínim, la vostra història hauria de contenir tots els elements que consten a la plantilla. La plantilla de la història és així: Títol (una línia que descrigui la història)
Narrativa: Com a [un rol] Vull [característica] Perquè [benefici] Criteris d'acceptabilitat: (Presentats com a escenaris) Escenari 1: Títol Si [context] I [més context]... Quan [esdeveniment] Llavors [resultat] I [un altre resultat] Escenari 2: ... Explicant la història
Una història hauria de ser el producte d’una conversa entre diverses persones. Un analista financer parla a un inversor1 sobre la característica o el requisit i això els ajuda a emmarcar-lo dins de la narrativa de la història. Llavors, un tester ajuda a definir l'abast de la història, segons els criteris d'acceptabilitat, i determina quins escenaris importen i quins són menys útils. Un representant tècnic estimarà la quantitat de feina que comporta la història i proporcionarà enfocaments alternatius. Moltes grans idees per a sistemes provenen de les persones que les desenvolupen i de qui les sol·licita en primer lloc.
Segurament, aquest serà un procés repetitiu. L’inversor tindrà una idea del que vol però no sabrà quanta feina comporta o com s’ha de distribuir. Amb l'ajuda d'experts tècnics i de proves, entendran la relació costos-beneficis de cada escenari i podran decidir si realment volen la característica en qüestió. És clar que això també s’equilibra amb els altres requisits: És millor cobrir més casos en aquesta història o canviar d’història?
De vegades l'equip de desenvolupadors no tindrà prou informació per fer una primera estimació. En aquests casos, pot ser que decideixin fer treball d’investigació per entendre millor el requisit. (Tractaré la planificació més detalladament en un altre article.)
Amb l’exemple de l'article que presenta el BBD, fixem-nos en els requisits per retirar diners d’un caixer automàtic:
Història: El titular del compte retira efectiu Com a titular del compte Vull retirar efectiu d’un caixer automàtic Per poder treure diners quan el banc està tancat Escenari 1: El compte té prou diners Si suposem que el saldo del compte és de \100 $ I la targeta és vàlida I el caixer té prou diners Quan el titular demana \20 $ Llavors, el caixer automàtic hauria d’oferir \20 $ I el saldo del compte hauria de quedar a \80 $ I s’hauria d'expulsar la targeta Escenari 2: El compte té prou diners Si suposem que el saldo del compte és de \10$ I la targeta és vàlida I el caixer té prou diners Quan el titular demana \20 $ Llavors, el caixer automàtic no hauria d’oferir diners. I el caixer automàtic hauria de comunicar que no hi ha prou diners. I el saldo del compte hauria de ser \20$ I s’hauria d'expulsar la targeta Escenari 3: La targeta s’ha desactivat Si la targeta s’ha desactivat Quan el titular demana \20 $ Llavors, el caixer hauria de retenir la targeta I el caixer hauria de comunicar que s’ha retingut la targeta Escenari 4: El caixer automàtic no disposa de prou diners ...Com podeu veure, hi ha moltíssims escenaris per tenir en compte, alguns relacionats amb el saldo del compte, d’altres amb la targeta i d’altres amb el caixer. Analitzem la història per saber si funciona.
El títol de la història, “Titular del compte retira efectiu”, descriu una activitat que el titular del compte vol realitzar. Fins que no implementem aquesta característica, el titular del compte no podrà treure diners del caixer automàtic. Quan l’hàgim activat, sí. Això ens proporciona un punt de partida obvi per determinar què significa “resolt”.
Si el títol fos “Gestió del compte” o “Comportament del caixer”, hauríem de perdre més temps per saber de què tracta. Per exemple, “Gestió del compte” podria incloure demanar un préstec, i “Comportament del caixer” podria incloure el procés de canviar el codi secret de la targeta. El títol de la història sempre ha de descriure el comportament real d’un usuari del sistema.
La plantilla “Com a [rol], vull [característica] per a [benefici]” té grans avantatges. Si s’especifica el rol a la narrativa, ja se sap a qui dirigir-se pel que fa a la característica. Si s’especifica el benefici, el programador tindrà en compte per a què es vol la característica en qüestió.
Quan us adoneu que la característica no proporciona el benefici que se li atribuïa es fa més interessant. Normalment això significa que falta una història. Hi ha una història amb la característica en qüestió que proporciona un benefici diferent (però útil), i una altra història amagada per la qual es necessitarà una característica diferent per proporcionar el benefici descrit.
La història d’exemple ens mostra que al titular d’un compte li interessa la característica proporcionada, per tant, sabem per on començar a explorar què hauria d’oferir.
S’haurien de poder posar els escenaris en paral·lel i saber en què es diferencien només amb el títol. En el nostre exemple es pot veure que les descripcions dels escenaris només especifiquen què canvia entre cada un d’ells. No cal escriure “el titular d’un compte retira diners d’un compte amb saldo insuficient i se li comunica que no es pot realitzar la transacció”. Només amb el títol s'ha de poder saber ràpidament si aquest és l'escenari que busqueu o no.
Aquest és el canvi de comportament més important que he vist en equips que incorporen BDD. Només fent que tant els usuaris dels negocis com els analistes, els testers i els desenvolupadors utilitzin el vocabulari de “si/quan/llavors”, tots us adonareu que les ambigüitats desapareixen.
No obstant això, no tots els escenaris són tan simples. Alguns es representen millor com una seqüència d'esdeveniments descrits com: si [context] quan [jo faig alguna cosa] llavors [això passa], quan [faig una altra cosa], llavors [passa aquesta altra cosa], etcètera. Un exemple d'això és una web-assistent, on segueixes un seguit de pantalles que conformen un model de dades complex. És molt apropiat per barrejar seqüències d'esdeveniments i resultats, sempre que es tingui el costum de pensar d’aquesta manera.
Un comportament interessant que sorgeix és que la qualitat de la conversa canvia. Ben aviat descobrireu que us heu oblidat d’alguna condició (“bé, clar que el compte està al descobert”) o us haureu oblidat de verificar algun resultat (“bé, clar que el titular del compte recupera la seva targeta”). Això ho vaig veure en un projecte en concret, on el desenvolupador cap va dir-me que veia com els analistes i els desenvolupadors no paraven de treballar amb objectius contradictoris però que no trobava la manera de demostrar-los-ho. Després de pocs dies d’haver introduït el vocabulari de si/quan/llavors, va poder presenciar una gran millora en la qualitat de les seves interaccions.
Les condicions que sobren distreuen i compliquen la comprensió d'aquell que llegeix la història per primer cop, ja sigui des del punt de vista tècnic o empresarial. De la mateixa manera, les condicions que faltin es basaran en el que cadascú suposi. Si pots obtenir un resultat diferent a partir de les condicions proporcionades, llavors significa que falta alguna cosa.
A l'exemple, en el primer escenari hi ha informació sobre el saldo del compte, la targeta i el mateix caixer automàtic. Tota aquesta informació és necessària per definir completament l'escenari. Al tercer escenari no es diu res sobre el saldo del compte o si el caixer té diners. Això implica que la màquina retindrà la targeta sigui quin sigui el saldo del compte o l'estat del caixer.
L'esdeveniment ha de ser molt senzill, normalment ha de ser una invocació senzilla per al codi de producció. Com ja hem comentat anteriorment, alguns escenaris són més complicats que aquest, però la majoria tractaran només un esdeveniment. Només canviaran pel context (les condicions) i els resultats esperats corresponents.
No hi ha normes que estipulin com s’ha de fer, sempre que la informació es divideixi en parts demostrables. En general, si hi ha més de cinc o sis escenaris, la història es pot dividir i agrupar segons els escenaris que s’assemblin.
De l'exemple del caixer automàtic no podem dir quants escenaris més en sortirien, però estic segur que uns quants més. Essencialment hi ha tres “peces mòbils” a la història: el saldo del compte, l'estat de la targeta i l'estat del caixer. Podríem donar més detalls de la targeta: què passa si està caducada? No podré treure diners, però me la retornarà, el caixer? I si el caixer s’espatlla just quan s'està realitzant la transacció? I si el meu compte té servei de descobert? Seria millor dividir la història en diverses subhistòries:
El titular del compte retira efectiu (supòsits: El caixer funciona i la targeta és vàlida) El titular del compte retira efectiu amb una targeta invàlida (supòsits: el caixer funciona) El titular del compte retira efectiu d’un caixer defectuós (supòsits: la targeta és vàlida)
Tot i que pot semblar artificiós, permet demostrar progrés en termes de negocis i proporciona més dades per poder fer-ne un seguiment. El que importa és dividir la història segons línies de negocis i, per tant, segons els diferents escenaris (i fer que els supòsits siguin explícits). No recomanem buscar línies tècniques (per exemple, gestionar les bases de dades en aquesta iteració i el GUI en la següent). D'aquesta manera, l’empresa pot comprovar el procés per si sola i no haver-vos de creure cegament.
Hi ha casos i casos. M’encanta com Alistair Cockburn descriu els casos d’ús (en contraposició amb les versions de sobreenginyeria que m’he trobat en projectes de desenvolupament en cascada). Ara bé, com que no tinc gaire experiència en projectes gestionats per casos, deixaré que faci les comparacions algú altre.
De fet, estic d’acord amb el seu procediment de començar amb la precisió més baixa (d’un resultat o objectiu) i treballar cap a precisions més altes, tenint cada cop més escenaris d'excepció. En BDD, això significa començar pels resultats de negoci i treballar a través d’àrees funcionals d’alt nivell per aprofundir en històries específiques amb criteris d'acceptabilitat.
En realitat, és igual quin procés se segueixi a l’hora d’identificar i elaborar els requisits. Podeu redactar documents amb els requisits si això us ajuda a ordenar les idees. De totes maneres, no és recomanable utilitzar aquests documents com si ja comprenguessin tots els vostres pensaments, perquè no és així. El que s’ha de fer és agafar el document dels requeriments i tots els casos d’ús i deixar-los a un costat per començar a definir històries a partir dels resultats de negoci, tot això sabent que tota la feina feta fa que tinguem presents totes les respostes (o, si més no, tenir una idea clara de la feina a fer).
El desenvolupament basat en el comportament utilitza una història com a unitat bàsica de funcionalitat i, per tant, també d’entrega. Els criteris d'acceptabilitat són una part intrínseca de la història, ja que defineixen l’abast del comportament i ens proporcionen una definició comuna de què entenem per “resolt”. També s’utilitzen com a base de l'estimació a l’hora d’elaborar la planificació.
Sobretot cal tenir en compte que les històries són els resultats de converses entre inversors del projecte, analistes empresarials, testers i desenvolupadors. El BDD té tant a veure amb les interaccions entre diverses persones com amb els resultats del procés de desenvolupament.
1. De fet, hauria de ser la persona a qui li importa de veritat la característica, així que podria ser tant algú de l’àmbit operacional o legal com de seguretat, depenent de cada història.
Esta es la versión en Catalán del artículo "What's in a story?", originalmente escrito y publicado por Dann North. Este texto ha sido traducido de Inglés a Catalán por un estudiante de traducción, dentro del programa "Ideas worth translating", liderado por el departamento de Español y Catalán de Ibidem Group en colaboración con universidades y agencias de traducción de España. Se trata de un ejercicio de traducción, totalmente gratuito y sin coste alguno, por lo que a pesar de haber sido revisado antes de su publicación, podría contener alguna errata. Si este fuera el caso, por favor indíquenoslo. Si es ud. escritor y quiere solicitar una traducción gratuita de Español o Catalán a Inglés en el marco de nuestro programa "Ideas Worth Translating", contacte con nuestro equipo indicando en el asunto del mail "IWS: Traducción a Catalán".
This is an Spanish version of the article "What's in a story?", originally written and published by Dann North. This text has been translated from English into Catalan by a translation student, within the academic program "Ideas worth translating", led by the Spanish and Catalan Department of IBIDEM GROUP in collaboration with language universities and translations agencies in Spain. Please bear in mind that this is an academic exercise, a free-of-charge complimentary translation. It has been reviewed by a professional translator before publishing; however, if you do find any mistake or misspelling, please get in touch with us. If you are a writer and want to request a free translation from English into Spanish or Catalan within our program "Ideas worth translating", please send us an email with the subject "IWS: Translation into Catalan".
Copyright 2022 IBIDEM GROUP SL · Legal notice · Site map