On encaixen les tecnologies per a automatitzar el desenvolupament i assistir al desenvolupador?
Com es produeix i opera el programari en la pràctica?
Les eines Low Code i No Code (per ex. Appinventor [4] , Budibase [5] , WebRatio [3] , Figma [6] , Debuild [7], etc.) ens permeten automatitzar el desenvolupament seguint un enfocament de disseny centrat en l’usuari (utilitzen interfícies gràfiques i configuracions fàcils d’usar per a crear les solucions) [1][2]. A més, existeixen eines tecnològiques de IA (per ex. GitHub copilot [8] o OpenAI [9] basades en GPT3) que poden usar-se com a assistent en les tasques de disseny i desenvolupament de codi. A continuació, per a comprendre millor les implicacions d’aquestes tecnologies podrien tenir en la producció i operacions programari, veurem com es duen a terme els projectes programari en la pràctica i perquè cada vegada cobra més força que seguim un enfocament de disseny orientat a l’usuari en contrast amb el cicle de vida clàssic de desenvolupament que tots coneixem (independentment de si ho fem en cascada o de manera iterativa-incremental).
Qualsevol que s’hagi enfrontat al disseny i desenvolupament d’un producte programari, i més encara si el projecte és d’I+D, sap de la incertesa inicial que tenen aquests projectes. El disseny i desenvolupament de prototips, permet que amb poc esforç, puguem adquirir coneixements més ràpidament sobre la solució que es necessita. A més, qualsevol canvi en el disseny exterior d’un producte (les seves interfícies) afectaran el disseny interior del producte, per la qual cosa, no sembla que tingui molt sentit que dissenyem el seu interior abans d’assegurar-nos que el seu disseny exterior no canviarà (o canviarà poc). Una vegada que estem segurs que l’exterior és “més estable”, podem dissenyar-lo i construir-lo de manera sistemàtica perquè sigui “útil” però sempre, tenint en compte que oferirem un servei i que hem d’assegurar certes “garanties”. La utilitat de l’artefacte és el que estaria, principalment, relacionat amb els requisits funcionals del producte mentre que la garantia (seguretat, capacitat, disponibilitat, continuïtat, etc.) estaria més relacionada amb el que anomenem requisits no funcionals. Al final, els requisits, estan presents en tot el cicle de vida del producte com s’observa en la Figura 1.
Com comentàvem, independentment del cicle de desenvolupament que seguim (per ex. trencada o iteratiu-incremental), tradicionalment les etapes clàssiques d’un desenvolupament de programari, sense entrar en les operacions, són: Elicitación de requisits, Anàlisis de requisits, Disseny, Construcció/Implementació, Proves. De fet, les etapes anteriors són les que apareixen en les plantilles del ministeri que utilitzem els auditors per a avaluar els projectes que es realitzen al nostre país per a qualificar un projecte com a “innovació tecnològica” o “I+D”. En aquests 3-4 anys com a avaluador, he pogut avaluar més de 50 projectes d’aquest tipus. De manera breu, algunes de les qüestions que he observat són:
• Es barreja el concepte de “Elicitación de requisits” amb el de “Anàlisi de requisits”. La elicitación només hauria de cobrir la comprensió i definició del problema (per ex. un model de negoci que descrigui la realitat actual, només per a entendre les necessitats), mentre que en l’anàlisi, hauria d’abordar-se la solució de manera independent a la tecnologia (per ex. interfícies, diagrama de classes, diagrama de casos, diagrama d’activitats, diagrama de seqüència, etc.).
• Es barreja el concepte de “Anàlisi de requisits” amb el de “Disseny”. Mentre que l’anàlisi és genèrica, el disseny és específic de la plataforma o la tecnologia que s’utilitzi per a construir la solució. En la majoria de projectes avaluats, en el Disseny s’inclouen diagrames d’Anàlisis (és a dir, genèrics, sense que s’especifiqui cap tecnologia).
• La documentació tècnica no sol seguir cap model de referència, estàndard o normativa (per ex. tècniques UML o BPMN). En aquest sentit, seria important que es normalitzés un mínim de documentació tècnica per a aquesta mena de projectes (cosa que estic segur que agrairíem tots els que avaluem aquest tipus de projectes).
• Quan s’inclouen proves, solen ser de baixa qualitat. Només s’aprecien activitats de verificació (passat, després de dissenyar i construir, assegurar-nos que hem dissenyat i construït la solució adequada), sent poques l’activitats de validació (futur, abans de dissenyar i construir, assegurar-se que la solució és l’adequada). Tampoc s’esmenten activitats de monitoratge continu (present, assegurar-se que el programari funciona en temps real) [10].
• En alguns casos, s’aporten pantalles que a vegades, no saps si són prototips o captures de pantalla reals del programari desenvolupat. No obstant això, se solen sol·licitar extractes de codi com a evidències que es va dur a terme el desenvolupament.
Quines estratègies podem inferir a partir de l’experiència pràctica com a estratègia per a la producció/operacions programari?
Si fem l’esforç de traslladar totes aquestes activitats a un model com el de la figura anterior, tindríem alguna cosa com el que es mostra en la Figura 2. En la següent figura, s’ha considerat un cicle de vida complet del producte programari, des de la seva concepció (Discovery), seguint pel seu disseny i desenvolupament (Development), fins a la seva posada en producció com un servei (Operations).
De forma molt resumida, els objectius i les principals activitats, serien les següents:
• Discovery: L’objectiu és aprendre com més aviat millor sobre el problema i la solució, reduir la incertesa tècnica i de negoci. S’aconsegueix mitjançant la construcció i validació d’un prototip d’un sol ús (negoci) i petites donem tècniques per a ajudar-nos a prendre decisions sobre els components tecnològics que utilitzarem en la construcció. És una activitat de recerca i de generació de coneixements.
• Development: L’objectiu és que la construcció sigui el més sistemàtica possible (no és ciència, és enginyeria). S’aconsegueix obtenint un programari que sigui “útil” per als seus usuaris i que hagi estat provat en un entorn de desenvolupament. És una activitat on es genera programari.
• Operations: L’objectiu és posar a la disposició dels usuaris el programari perquè puguin dur a terme les seves activitats. S’aconsegueix mitjançant la posada marxa d’un servei que permeti als usuaris utilitzar el programari amb “garanties”.
Si traslladem les activitats d’un cicle de desenvolupament clàssic a aquest cicle de vida de producte, ens adonarem que no sols cobreix Development. Per exemple, la elicitación de requisits, encaixaria en la comprensió i definició del problema. L’activitat d’Anàlisi de requisits quedaria separada en dues activitats: (Discovery) aquelles que afecten la definició externa de la solució (interfícies o prototipado) i (Development) aquelles relacionades amb la definició interna de la solució (diagrama de classes, diagrames de seqüència, etc.).
Les activitats de Disseny i Construcció, d’igual manera, quedarien separades en dues activitats: (Discovery) aquelles activitats que tenen com a objectiu dissenyar i construir una petita demo tècnica i (Development) aquelles activitats que tenen com a objectiu dissenyar i construir el programari.
L’activitat de Proves (i podem incloure monitoratge continu si incloem les operacions), quedarien separada en tres: (Discovery) proves del sistema que poden definir-se usant els prototips per a “validar” el programari mitjançant un prototip d’un sol ús, (Development) proves unitàries i d’integració que ens permeten “verificar” el programari i, finalment (Operations) monitoratge continu que ens permet, en temps real, controlar i fer un seguiment del servei que estem oferint.
Descobriment/Recerca, Desenvolupament i Operacions (Learn2Build vs Build2Learn)
Depenent del nostre context, podrien donar-se diferents situacions que implicarien que puguem posar el focus més en Discovery (per ex. aplicant un procés Design Thinking), o bé, en Development i Operations (per ex. aplicant el conjunt de bones pràctiques de DevOps).
L’enfocament Learn2Build permet potenciar l’aprenentatge prèviament a la construcció. És útil quan ens trobem en un context amb una incertesa alta de negoci i tècnica. És a dir, no tenim clar quin és problema, què hem de construir ni com ho construirem. Una estratègia que encaixaria en aquest enfocament seria un procés Design Thinking o la metodologia Design Sprint [12]. També encaixarien els mètodes de SAPIENS que veurem a continuació. La validació de l’artefacte (almenys sobre la seva utilitat, no la seva garantia) en etapes molt primerenques ens permet reduir els esforços i el cost que impliquen trobar possibles avantatge competitives (que veurem més endavant i que és un concepte relacionat amb la innovació).
D’altra banda, l’enfocament Build2Learn permet potenciar l’obtenció de productes funcionals que aportin un valor real a l’usuari [11][13]. Sobre això, és molt important la definició de valor, i aquí caldria diferenciar el “Valor” que s’aporta:
1. Si només abordem un “Desenvolupament” on el desplegament es duu a terme només en un entorn de desenvolupament i l’usuari encara no pot treure-li partit al programari del qual s’aporta
2. Si a més integrem les “Operacions” on el desplegament es duu a terme tant en entorns de pre-producció com en entorns de producció reals, permetent als usuaris que utilitzin el programari sota unes garanties d’ús.
A més, aquest enfocament requereix que disposem d’un equip tècnicament molt madur, ja que el cost de dissenyar i construir solucions programari ha de ser molt similar al disseny i construcció d’un prototip d’un sol ús. A més, també podria requerir l’aplicació d’unes mínimes estratègies de descobriment i gestió de requisits (per ex. Llegeixin Inception [14] o Agile Inception), ja que és molt important que es dugui a terme una bona planificació per a prioritzar aquelles característiques funcionals (utilitat) i no funcionals (garanties) que preveemos que aportarien més valor al negoci.
Amb tot l’anterior, l’important és que tinguem un equip que, a cada moment s’adapti a les circumstàncies segons el context com es mostra en la Figura 6, on en un moment determinat podríem començar aplicant només un enfocament Learn2Build (Discovery), en un altre moment combinar tots dos enfocaments però sense desplegar en producció (Discovery & Development), o bé, només aplicar un enfocament Build2Learn desplegant en entorns de producció (Development & Operations).
A més és important que es dugui a terme una execució sistèmica del procés enfront del que seria una execució improvisada. La principal diferència és que tinguem clara la nostra estratègia (quins processos i etapes de les anteriors duem a terme) i les nostres tàctiques (quins mètodes, tècniques i artefactes programari utilitzes en aquests processos). Sobre això últim, us deixo una frase del Llibre “L’Art de la guerra” de Sun Tzu que dóna lloc a la reflexió sobre estratègia i tàctica en enginyeria del programari: “Estratègia sense tàctica és el camí més lent cap a la victòria, Les tàctiques sense estratègia són el soroll abans de la derrota”.
Gestió i millora contínua
Sent conscients dels diferents contextos i estratègies on poden aplicar-se les diferents estratègies, l’important és que l’organització dugui a terme aquestes pràctiques de la forma més sistemàtica possible, i no treballar de forma improvisada.
D’altra banda, aquest procés sistèmic (fem el mateix, obtenim resultats similars), ens permet identificar a més si un determinat canvi en les nostres estratègies i tàctiques (per ex. utilitzar una nova eina en lloc d’una altra) ens permet millorar o no. En la següent figura, es mostra l’estratègia que seguiria qualsevol procés de gestió. Qualsevol dels enfocaments que hem vist anteriorment que combinin enfocaments Learn2Build i Build2Learn encaixaria en la “Execució” del procés de gestió. Millorar la nostra eficàcia implicaria complir els nostres objectius (per ex. que complim amb l’abast planificat) mentre que millorar la nostra eficiència implicaria realitzar algun canvi en la nostra estratègia que millorés la nostra execució (per ex. complim objectius amb menor cost en temps o recursos).
Conclusions
Finalment, finalitzarem amb les conclusions més rellevants:
• Diferents contextos (problemes) requereixen estratègies diferents (solucions). Considerar una estratègia que tingui en compte el cicle de vida del producte (no sols del desenvolupament):
- Descobriment, Desenvolupament, Operacions
- 2 enfocaments en funció del context (incertesa tècnica i de negoci): Learn2Build vs Build2Learn
• Sobre gestió i millora contínua
- És important que l’organització dugui a terme la seva estratègia de la forma més sistemàtica possible (mai de forma improvisada).
- Millorar la nostra eficàcia implicaria complir els nostres objectius mentre que millorar la nostra eficiència implicaria realitzar algun canvi en la nostra estratègia que millorés la nostra execució.
REFERÈNCIES
[1]. El País, “Low Code cómo aparender a programar sin saber programar”, accesible online: https://elpais.com/tecnologia/2022-05-06/low-code-como-aprender-a-programar-sin-saber-programar.html, últim accès: Juliol 2022
[3]. WebRatio, accessible online: https://www.webratio.com/site/content/es/plataforma-de-desarrollo, últim accès: Juliol 2022
[4]. MIT Appinventor, accesible online: https://appinventor.mit.edu, últim accès: Juliol 2022
[5]. BuidBase, accesible online: https://budibase.com, últim accès: Juliol 2022
[6]. Figma, accesible online: https://www.figma.com/, últim accès: Juliol 2022
[7]. Debuild, accessible online: https://debuild.app/, últim accès: Juliol 2022
[8]. GitHub copilot, accesible online: https://github.com/features/copilot, últim accès: Juliol 2022
[9]. OpenAI examples, accesible online: https://beta.openai.com/examples/, últim accès: Juliol 2022
[10]. Morales-Trujillo et al. “A Testability and Observability Framework to Assure Traceability Requirements on System of Systems.” Journal of Web Engineering (2020): 297-318.
[11]. Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press, LLC. Print ISBN:978-1942788003.
[12]. Jake Knapp, J. Z. (15 de 12 de 2016). Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. First Simon & Schuster. ISBN 978-1-5011-2174-6. Obtenido de http://www.gv.com/sprint/
[13]. Forsgren, N., Humble, J., & Kim, G. (2018). The Science of Lean Software and DevOps. ACCELERATE. Building and Scaling High Performing Technology Organizations. IT REVOLUTION. ISBN:9781942788331.
[14]. Paulo Caroli (2019), Lean Inception: How to Align People and Build the Right Product, ISBN 10: 8594377134.