Blog

Spiegazione della rilavorazione del software La rilavorazione del software è il lavoro consequenziale che deriva dalla modifica di requisiti, progetti, codice e test dopo che un lavoro è già stato avviato. Nella maggior parte delle aziende software ciò rappresenta 30-50% di tutta l'attività. Generalmente escludiamo la correzione di bug dalla categoria delle rielaborazioni del software. La rilavorazione generalmente descrive il lavoro extra che è una conseguenza del “cambiamento dei requisiti”. Rilavorazione del software: positiva o negativa Alcune rilavorazioni possono essere viste come un indicatore positivo del fatto che il feedback degli utenti sta guidando il cambiamento verso ciò che è necessario. Ciò sarebbe giusto se i cambiamenti fossero imprevedibili. Tuttavia i tipici livelli di rilavorazione sul software [...]

Il significato di "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 piuttosto ristretta e [...]

Ecco alcuni spunti sul valore di trovare difetti nei requisiti prima della progettazione o della codifica. Per un team di sviluppo software è molto prezioso trovare i difetti in anticipo. Ancora meglio, è prevenire del tutto i difetti. I requisiti eccellenti sono una forma efficace di prevenzione dei difetti e prevenzione delle rilavorazioni. Un requisito ambiguo può portare a notevoli sprechi di sforzi. Prestando attenzione al rilevamento dei difetti nei requisiti software, i team incorreranno in meno sprechi e più spesso consegneranno correttamente al primo tentativo. I difetti si presentano prima dell'inizio della codifica I difetti si presentano nei requisiti e nell'architettura prima ancora che inizi la codifica. [...]

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 [...]