Blog

Il significato e l'origine del "debito tecnico" La metafora del debito tecnico (TD) nel contesto del software è stata coniata da Ward Cunningham che all'epoca stava lavorando alla codifica di un sistema finanziario. Ha utilizzato la metafora per spiegare ai suoi colleghi finanziari le ragioni per il refactoring e la riscrittura di parti di codici man mano che la conoscenza dei requisiti si evolveva. "Quando prende scorciatoie e fornisce codice che non è del tutto adatto al compito di programmazione del momento, un team di sviluppo incorre in TD. Questo debito diminuisce la produttività. Questa perdita di produttività è nell'interesse del TD." La spiegazione originale prevista da Ward era abbastanza [...]

Di seguito sono riportati alcuni approfondimenti sull'importanza di individuare i difetti dei requisiti prima della progettazione o della codifica. Per un team di sviluppo software è molto utile individuare tempestivamente i difetti. Ancora meglio è prevenire del tutto i difetti. Requisiti eccellenti sono una forma efficace di prevenzione dei difetti e di rilavorazione. Un requisito ambiguo può comportare un notevole spreco di sforzi. I difetti si manifestano prima dell'inizio della codifica I difetti si manifestano nei requisiti e nell'architettura prima ancora che la codifica abbia inizio. Immaginiamo di operare in un settore assicurativo e che gli imprenditori abbiano deciso che un sistema nuovo (o modificato) [...]

Suddivisione della storia: perfezionamento fino ad una granularità ottimale Una storia apparentemente piccola potrebbe rivelarsi molto più grande del previsto. Solo perfezionando o suddividendo la storia puoi scoprirlo. La suddivisione della storia può essere effettuata all'inizio o subito prima dello sprint precedente. Ti consigliamo di farlo il prima possibile per evitare sorprese tardive. Consideriamo la "suddivisione della storia" e il "perfezionamento della storia" come attività molto simili. Si tratta di ottimizzare la granularità della user story scritta. Cosa sono le storie degli utenti Per quei team che sono in grado di co-localizzare, la storia dell'utente può essere solo un promemoria di una conversazione. [...]

L'individuazione dei requisiti riguarda la scoperta dei reali requisiti aziendali e dei requisiti di sistema di qualsiasi progetto software. Si tratta innanzitutto di scoprire ciò che è necessario e poi di articolare le scoperte distillate in artefatti che possono essere utilizzati come base per descrivere ciò che deve essere fatto. È insolito che i reali requisiti aziendali (e i conseguenti requisiti di sistema) possano essere individuati rapidamente. Sebbene la raccolta dei requisiti venga talvolta definita raccolta dei requisiti, questa è un'espressione fuorviante. I veri requisiti sono più simili a un tesoro sepolto in un campo che a raccolti che possono essere raccolti. A volte un'indicazione di [...]

Vediamo come e perché potremmo voler garantire la qualità delle storie degli utenti. Le storie degli utenti inadeguate portano a riunioni inutili, sprechi e rielaborazioni. Migliorare la storia dell'utente il più presto possibile nel ciclo di vita dello sviluppo è un modo efficace per ridurre al minimo gli sprechi e le rielaborazioni. La garanzia della qualità è un approccio sistematico per determinare se un "prodotto" soddisfa criteri accettabili. Per la QA delle storie degli utenti dobbiamo prima definire cosa piace al bene? Qual è la differenza tra storie utente di buona qualità (e insieme di storie utente) e scarsa qualità. Per lo sviluppo agile del software tendiamo a [...]