En tancar Estil, llegibilitat i refactorització quedava pendent una sola cosa, la més important de totes: construir alguna cosa sencera des de zero, tu sol. Aquest mòdul és exactament això. Durant vuit mòduls, cada peça de TascaFàcil venia proposada —l'enunciat deia quina classe calia, quin mètode faltava, quina prova escriure—; a partir d'aquí les decisions són teves. I la primera decisió, la que condiciona totes les altres, és què construiràs i fins on. Aquesta lliçó no escriu ni una línia de codi: serveix per triar una idea que valgui la pena, retallar-la fins a una mida que puguis acabar i deixar-la escrita en un document d'una pàgina que serà el teu contracte amb tu mateix. Sona poc espectacular comparat amb programar, però és la diferència entre un projecte acabat i una altra carpeta a mig fer al disc dur.

1. Què s'espera del projecte final
2. Com t'avaluaràs: la rúbrica
3. Triar la idea: cinc criteris
4. Catàleg de sis idees de projecte
5. Delimitar l'abast amb MoSCoW
6. Requisits funcionals i no funcionals
7. Criteris d'acceptació
8. Casos d'ús i casos límit
9. El document de definició
10. Exemple resolt: LesMevesDespeses
11. Com es va definir TascaFàcil en el seu dia
12. Errors comuns i consells
13. Exercicis
14. Conclusió

El projecte final és una aplicació de línia d'ordres, escrita per tu, que resol un problema concret de cap a cap. No busca ser original ni impressionant: busca demostrar que saps recórrer el camí complet des d'una idea fins a un programa que una altra persona pot descarregar, executar i entendre.

Aquestes són les característiques que ha de tenir:

• Funciona sense tu al davant. Algú clona el repositori, llegeix el README.md, executa una ordre i el programa arrenca.
• Desa dades entre execucions. Tanques el programa, el tornes a obrir i les teves dades continuen allà (mòdul 5).
• Està organitzat en mòduls i funcions, no en un únic fitxer de 600 línies (mòduls 4 i 7).
• No es trenca amb una entrada estranya. Escriure «trenta» on demana un número no ha de produir un traceback (mòdul 8).
• Té proves automatitzades del que de debò importa (08-04).
• Viu a Git, amb historial llegible i un README.md que l'explica (08-01 i 08-03).

I una nota sobre la mida: un projecte d'aquest tipus són entre 300 i 800 línies de codi, repartides en quatre o cinc fitxers, i entre 15 i 25 hores de feina per a algú que acaba de completar aquest curs. TascaFàcil, en la seva v1.0, té aquest ordre de magnitud. Si la teva idea sembla necessitar molt més, no és que siguis lent: és que la idea és massa gran i cal retallar-la, que és just el que fa l'apartat 5.

El recorregut del mòdul complet és aquest, i aquesta lliçó és només la primera casella:

Convé entendre per què l'ordre és aquest. Cada casella redueix la incertesa de la següent: sense definició no saps què dissenyar, sense disseny programes a cegues i reescrius tres vegades, i sense un projecte acabat no hi ha res per presentar. No és burocràcia: és la manera més barata d'equivocar-se, perquè canviar una frase del document costa un minut i canviar una decisió ja programada costa una tarda.

No hi ha cap professor que et posi nota, així que la nota te la poses tu —i perquè això signifiqui alguna cosa cal una rúbrica escrita abans de començar, no després. Llegeix-la ara, guarda-la i torna-hi a Presentació del projecte, on la faràs servir de debò.

Per calcular la nota, multiplica la puntuació de cada fila pel seu pes i suma. Un projecte que treu 2,5 de mitjana ja és un projecte digne per a algú que comença; apuntar al 4 en tot des del primer intent és la manera més ràpida de no acabar. I fixa't en una cosa important: només el 25 % és «funcionalitat». La resta és com està fet. Això també és una decisió pedagògica deliberada.

La temptació és triar la idea més ambiciosa que se t'acudeixi. Resisteix. Un bon projecte final compleix aquests cinc criteris:

1. Resol un problema que tu tens. Si el programa t'ha de resultar útil de debò, l'acabaràs; si és un exercici abstracte, l'abandonaràs a la primera dificultat. Pensa en què apuntes avui en un paper, en una nota del mòbil o en un full de càlcul desordenat.
2. És abastable. Ha de cabre en quatre o cinc entitats com a màxim i en un grapat d'operacions. Si per descriure'l necessites més de cinc frases, és massa gran.
3. Fa servir dades que et pots inventar. Res de dependre d'una API externa, d'una base de dades corporativa o d'un fitxer que no tens. Has de poder crear vint registres de prova en deu minuts.
4. Es pot acabar. Hi ha una versió mínima identificable que ja és útil. Si el projecte només té sentit «quan estigui tot», és mal projecte.
5. Encaixa amb el que saps. Aquest curs t'ha donat fitxers, col·leccions, classes i línia d'ordres. Un projecte que necessiti gràfics, web o àudio t'obligarà a aprendre una altra cosa abans d'aplicar el que has après, i això és per a més endavant.

Un contrast útil: «una xarxa social per a aficionats a la fotografia» falla en tots els criteris; «un registre de les plantes de casa amb quan toca regar cadascuna» els compleix tots i, a més, es fa servir.

Si no se t'acut res, tria d'aquí. Totes estan dimensionades per a la mida de l'apartat 1 i totes exerciten el curs complet, però cadascuna insisteix en coses diferents:

Aquesta última fila mereix un aclariment, perquè és la més honesta de les sis: copiar l'estructura de TascaFàcil i canviar-li el domini és un projecte final perfectament vàlid. No aprens menys per tenir un mapa; la feina de traduir un disseny a un altre domini és exactament el que es fa a la vida professional. Això sí: canvia'l de debò —entitats pròpies, camps propis, informes propis—, no rebategis variables.

I un avís sobre la cinquena: el generador de menús és la més divertida i la més traïdora, perquè la generació amb restriccions (no repetir plat, equilibrar categories) es complica molt de pressa. Tria-la només si comences per la versió ximple: triar a l'atzar sense cap restricció.

El perill més gran del teu primer projecte no és que sigui difícil: és que no s'acabi mai. I no s'acaba perquè l'abast creix mentre programes. Estàs implementant la llista de despeses, se t'acut que estaria bé filtrar per rang de dates, i ja que filtres, exportar a Excel, i ja que exportes, un gràfic... Al cap de tres setmanes no hi ha ni gràfic ni llista. A això se'n diu scope creep, lliscament de l'abast, i l'antídot és escriure l'abast abans i no negociar-hi.

La tècnica MoSCoW classifica tot el que se t'acudeixi en quatre calaixos:

El calaix W sembla un calaix de les escombraries i és justament el contrari: és el que et protegeix. Escriure «no hi haurà interfície gràfica», «no hi haurà multiusuari», «no hi haurà sincronització al núvol» converteix una mancança en una decisió. Quan a la presentació et preguntin per què no hi ha interfície gràfica, la resposta «ho vaig deixar fora expressament per centrar-me en el model de dades» és professional; «no vaig tenir temps» no ho és. I durant el desenvolupament, cada vegada que se t'acudeixi una idea nova, no la implementes: l'apuntes al calaix C i continues.

Exemple, per a un gestor de despeses:

• Must: registrar despesa, llistar despeses del mes, total per categoria, desar i carregar, esborrar una despesa.
• Should: editar una despesa, filtrar per rang de dates, exportar a CSV.
• Could: pressupost mensual amb avís en superar-lo, despeses recurrents.
• Won't: interfície gràfica, diversos usuaris, multidivisa, importar del banc, gràfics.

Amb els calaixos plens, toca convertir els Must i Should en requisits: frases precises i verificables. N'hi ha de dos tipus i convé no barrejar-los:

Els funcionals s'escriuen bé amb la plantilla d'històries d'usuari:

Com a <rol> vull <acció> per <benefici>.

Les tres parts tenen funció. El rol t'obliga a pensar qui fa servir això (encara que siguis tu). L'acció ha de ser un verb concret: «registrar», «llistar», «exportar», mai «gestionar» ni «manejar», que no volen dir res. I el benefici és el que justifica el requisit: si no saps acabar la frase, probablement el requisit sobra. Numera'ls —RF-1, RF-2...— perquè els citaràs als commits, a les proves i al README.

Escriu entre cinc i vuit requisits funcionals i tres o quatre de no funcionals. Menys de cinc funcionals sol indicar un projecte massa petit; més de vuit, un que no acabaràs.

Un requisit sense criteri d'acceptació és una intenció. El criteri d'acceptació respon a: com sé, sense discussió possible, que això està fet? S'escriu com una llista de comprovacions observables, i la seva gran virtut és que es converteix gairebé literalment en proves quan arribis a 09-03.

Compara:

La segona columna és comprovable per qualsevol, inclòs tu mateix d'aquí a dues setmanes. Un bon criteri d'acceptació té entre tres i cinc punts, descriu el que s'observa des de fora (no com està implementat) i inclou almenys un cas d'error.

Un cas d'ús és el recorregut complet d'una tasca de l'usuari, del principi al final, explicat com una seqüència. Serveix per descobrir passos que els requisits no esmenten:

Escrit així es veuen coses que no eren al requisit: que cal carregar dades en arrencar, que fa falta un identificador, que convé confirmar amb un missatge. Amb dos o tres casos d'ús dels fluxos principals n'hi ha prou.

Els casos límit són les situacions estranyes que trenquen el programa si no les vas preveure. Pensa-les ara, no quan apareguin:

La fila de fitxers és la que més vegades oblida qui comença, i és la que garanteix un traceback a la primera demostració: el programa es va provar sempre amb dades ja existents i ningú no va executar mai la primera arrencada.

Tot l'anterior cap en una pàgina. Copia aquesta plantilla en un fitxer DEFINICIO.md dins del repositori i omple-la; és el teu contracte amb tu mateix i la referència a la qual tornaràs quan dubtis si alguna cosa entra o no al projecte.

L'apartat 9 mereix atenció especial. Escriu avui, per escrit, què vol dir «acabat»: «Tots els RF marcats com a Must funcionen, hi ha proves del model i del magatzem, el README explica com instal·lar i fer servir, i existeix l'etiqueta v1.0». Sense aquesta frase escrita, «acabat» es desplaça cada setmana.

Aquest és el document de definició complet del projecte de mostra que acompanyarà les lliçons 09-02, 09-03 i 09-04. L'anomenarem LesMevesDespeses.

1. Problema. Arribo a final de mes sense saber en què se m'han anat els diners. Apunto les despeses en notes del mòbil que no reviso mai i no tinc manera de veure quant gasto en menjar davant de transport.

2. Solució proposada. Una aplicació de línia d'ordres que registra despeses i ingressos amb categoria i data, els desa en un fitxer JSON i mostra informes mensuals per categoria.

3. Abast (MoSCoW).

4. Requisits funcionals.

5. Requisits no funcionals.

• RNF-1. Cap entrada de l'usuari provoca un traceback: tot error es mostra com a missatge i torna al menú.
• RNF-2. Les dades es desen en un únic fitxer JSON llegible, editable a mà i amb codificació UTF-8.
• RNF-3. Qualsevol operació respon en menys d'un segon amb fins a 2.000 moviments.
• RNF-4. El programa funciona amb Python 3.10 o superior sense instal·lar dependències externes.

6. Casos d'ús principals. CU-1 registrar una despesa (el de l'apartat 8); CU-2 consultar el desglossament d'un mes; CU-3 corregir un error esborrant i tornant a registrar.

7. Casos límit previstos. Primera arrencada sense fitxer; JSON corromput a mà; mes sense moviments; import amb coma decimal (12,50); id inexistent en esborrar; categoria escrita com a «Menjar» i «menjar»; mes mal escrit (2026-13).

8. Dades d'exemple. Un dades_exemple.json amb 20 moviments repartits en dos mesos i cinc categories, generat a mà una vegada i versionat al repositori.

9. Definició d'acabat. Els set RF funcionen; hi ha proves de model, agregació i cicle desar/carregar; el README explica instal·lació, ús i limitacions; existeix l'etiqueta v1.0.

TascaFàcil va passar per aquest mateix procés, encara que no ho veiessis. El seu document de definició deia: «La Marta coordina tres persones a l'Estudi Alba i porta el repartiment de feina en una llibreta; quan algú pregunta què li toca, s'ha de buscar a mà». Els seus Must van ser afegir tasca, llistar, marcar completada, eliminar i desar. Els seus Won't van ser explícits i sostinguts fins al final: sense interfície gràfica, sense diversos usuaris simultanis, sense notificacions i sense sincronització. Tota la resta que vas aprendre amb ell —les prioritats, TascaRecurrent, el resum per responsable, el CSV— eren Should que van entrar quan els Must ja estaven en verd.

Comparar els dos documents ensenya una cosa: són gairebé idèntics en forma i completament diferents en contingut. El procés és el mateix sempre; l'únic que canvia és el domini.

• Triar un projecte massa gran. És l'error número u i no té remei a mig camí. Norma pràctica: si en acabar de definir-lo et sembla «massa fàcil», la mida és probablement la correcta. Un projecte petit i acabat ensenya deu vegades més que un d'ambiciós i abandonat.
• Saltar-se el document per «ganes de programar». La temptació és començar a teclejar la primera hora. Escriure la definició costa 45 minuts i estalvia dies de reescriptura, perquè descobreixes abans de programar que necessitaves un identificador o que dues entitats eren en realitat la mateixa.
• Requisits que no es poden verificar. «Que sigui intuïtiu», «que vagi ràpid», «que sigui bonic». Reescriu-los com una cosa observable: «el menú cap en una pantalla sense desplaçament», «respon en menys d'un segon amb 2.000 registres».
• Deixar el calaix Won't buit. Si no hi ha res que no facis, és que no has decidit res. Força't a escriure almenys quatre exclusions.
• Confondre requisit amb solució. «Vull desar les dades en JSON» no és un requisit, és una decisió de disseny i li toca a Planificació i disseny. El requisit és «vull que les meves dades no es perdin en tancar».
• Consell: tria un domini que coneguis. Si ets músic, un catàleg de partitures; si corres, un registre d'entrenaments. Conèixer el domini t'estalvia la meitat dels dubtes de disseny, perquè ja saps quins camps importen.
• Consell: la regla de les 20 fitxes. Abans d'escriure codi, imagina 20 registres reals del teu projecte. Si no ets capaç d'inventar-te'ls, el domini encara no està clar.

Aquests exercicis són els primers passos reals del teu projecte. Fes-los en un fitxer DEFINICIO.md de debò; el faràs servir a les quatre lliçons següents.

Escriu tres idees candidates —almenys una sortida del catàleg de l'apartat 4 i almenys una de pròpia— i avalua cadascuna contra els cinc criteris de l'apartat 3 en una taula amb puntuació d'1 a 3. Tria la guanyadora i escriu un paràgraf de tres o quatre frases explicant el problema real que resol i a qui.

Per a la idea guanyadora, omple els quatre calaixos: 5 o 6 Must, 3 o 4 Should, els Could que vulguis i un mínim de 4 Won't. Després fes la prova de l'àcid: tapa els Should i els Could i pregunta't si el que queda ja et resultaria útil. Si la resposta és no, algun Should ha de pujar a Must; si la resposta és «me'n sobra la meitat», baixa algun Must.

Converteix els Must i Should en 5 a 8 requisits funcionals numerats amb la plantilla «Com a / vull / per», cadascun amb tres o més criteris d'acceptació, i afegeix 3 o 4 requisits no funcionals. Després recorre la taula de famílies de l'apartat 8 i escriu almenys un cas límit de cada família aplicat al teu projecte.

Solució 1. L'apartat 10 és la solució completa de l'exercici per a LesMevesDespeses. La taula d'avaluació prèvia va ser aquesta:

La tercera cau pel seu propi pes: depèn de dades externes que no controles. La segona era viable però el problema era menys propi —«estaria bé tenir-ho» no és el mateix que «em fa falta»—, i aquest matís és el que sosté la motivació a la setmana tres. Rúbrica d'autoavaluació: has puntuat almenys tres idees? La guanyadora té un 3 a «acabable»? Sabries explicar el problema a algú aliè en 30 segons?

Solució 2. El MoSCoW de LesMevesDespeses és a l'apartat 10. Fixa't en dues decisions concretes: «editar un moviment» és a Should i no a Must perquè amb esborrar i tornar a registrar ja es corregeix un error —el valor afegit d'editar és comoditat, no capacitat—, i «gràfics» és a Won't encara que sigui el primer que un imagina en una aplicació de despeses, perquè exigeix una biblioteca externa i tot un aprenentatge que no és el d'aquest curs. Rúbrica: tens 4 o més Won't? Cap cada Must en menys de tres hores de feina? Els Must sols ja componen un programa útil?

Solució 3. Els set RF, els quatre RNF i els casos límit de LesMevesDespeses són a l'apartat 10. Compara els teus criteris d'acceptació amb els de RF-3: mira que inclou el cas buit («Sense moviments a 2026-08») i el format d'entrada (AAAA-MM). Aquestes dues coses són les que després es converteixen en dos def test_... gairebé sense traducció. Rúbrica: tots els teus RF tenen verb concret? Cadascun té tres o més criteris observables? Almenys un criteri per requisit descriu què passa quan alguna cosa va malament? Tens un cas límit de cadascuna de les set famílies?

El projecte final és teu: una aplicació de línia d'ordres d'entre 300 i 800 línies que resol un problema real, desa dades, està organitzada en mòduls, no es trenca amb entrades estranyes, té proves i viu a Git. T'avaluaràs amb la rúbrica de sis criteris —funcionalitat, estructura, robustesa, documentació, proves i Git—, escrita abans de començar precisament perquè signifiqui alguna cosa. La idea es tria amb cinc criteris: que resolgui un problema propi, que sigui abastable, que faci servir dades inventables, que es pugui acabar i que encaixi amb el que has après; i si no n'apareix cap, allà hi ha el catàleg de sis, inclosa l'opció perfectament legítima de refer TascaFàcil per a un altre domini.

Després ve el que de debò decideix si el projecte s'acaba: l'abast. MoSCoW reparteix tot en imprescindible, hauria, podria i ara no, i el calaix Won't —explícit, escrit, sense remordiments— és el que impedeix que el projecte creixi mentre el programes. Els Must i Should es converteixen en requisits funcionals amb la plantilla «Com a <rol> vull <acció> per <benefici>» i en requisits no funcionals que descriuen com s'ha de comportar; cadascun amb els seus criteris d'acceptació, que responen sense discussió a quan està fet i que a 09-03 es convertiran gairebé literalment en proves. Els casos d'ús revelen els passos que els requisits obliden, i les set famílies de casos límit —buit, un, molts, entrada invàlida, duplicats, fitxers i extrems— eviten el traceback a la primera demostració. Tot això cap en un DEFINICIO.md d'una pàgina que acaba amb la frase més útil del document: què vol dir exactament «acabat». LesMevesDespeses, el gestor de despeses que acompanyarà la resta del mòdul, ja el té escrit sencer.

Amb el què tancat toca el com. A Planificació i disseny convertirem aquest document en decisions tècniques: quines entitats hi ha i si són classes o diccionaris, en quin format es desen les dades, com es reparteix el codi en capes i mòduls, quin aspecte té el menú, quins algorismes necessites escrits en pseudocodi abans de programar-los i en quin ordre ho faràs tot, sessió a sessió.