Le pratiche di programmazione estreme rendono l'applicazione più soggetta a errori? [chiuso]

Over-involvement with the customer in the process leads to the expression of customer wishes rather than needs.

Ciò presuppone che il cliente sia una sorta di oracolo perfetto per i requisiti del sistema. Uno dei principi fondamentali di XP è che il cliente è non un oracolo perfetto e che è necessario un feedback costante basato su un vero software di spedizione per determinare le vere esigenze del mercato, dei clienti e, in ultima analisi, degli stakeholder .

Many products have multiple customers which lead to conflicting needs and opinions, creating unnecessary blockades.

Sì, e il regolare coinvolgimento di questi clienti contribuirà a rendere espliciti questi conflitti e aiuterà a risolverli nel tempo. Nascondere il problema non lo farà andare via.

Many products don’t have any external customers, where the product is made for internal use or to be sold in the future. In these cases, the team itself is playing the user as well as the developer, hence killing the effectiveness of the process.

Gli stakeholder interni non sono fondamentalmente diversi dagli stakeholder esterni. Non hai spiegato in che modo le metodologie non XP affrontano questo problema.

Not many things exist in formal documentation, this informality leads to vague vision and can create problems where the customer might say that this is not what we asked etc. etc.

XP comporta frequenti feedback incrementali tra gli stakeholder e gli sviluppatori. Se questi errori di comunicazione esistono, possono essere scoperti durante le iterazioni iniziali e possono essere risolti prima che influiscano in modo significativo sulle iterazioni successive. L'alternativa è che questi errori di comunicazione non vengono scoperti fino a poco prima che il prodotto venga spedito.

Penso che l'equivoco fondamentale sia che XP non sta creando questi problemi. È solo esponendoli . Processi che espongono e correggono i problemi in anticipo e spesso sono generalmente meno inclini agli errori, non di più.

Alcuni pensieri:

• Too much involvements of the customer in the process make him start expressing his wishes rather than his needs to the software

C'è sempre un equilibrio tra avere una specifica dettagliata e stabile e rispondere al cliente. Extreme ha lo scopo di aumentare la reattività al cliente e, naturalmente, è possibile andare troppo lontano in quella direzione. Quindi questa è una preoccupazione legittima (specialmente in base alla modalità di fatturazione del progetto: se si tratta di un contratto a prezzo fisso, ovviamente è necessario averlo ben specificato).

Nella mia esperienza, comunque, non importa quanto siano buone le tue specifiche, spesso devi cambiarle per fare "ciò che il cliente desidera" comunque. Extreme ti aiuta a fare quei cambiamenti il prima possibile, invece di dopo hai costruito un programma enorme e complicato alle specifiche.

• Many products have multiple customers which lead to conflicting needs and opinions leading unnecessary blockades

Naturalmente, risolvere problemi conflittuali in una situazione del genere sarà sempre un problema per il quale è necessario un buon processo da affrontare. Se il processo per ottenere un feedback da parte dei clienti è lungo e complesso, allora renderebbe la Programmazione estrema meno efficace, quindi penso che sia una preoccupazione legittima.

• Many products don’t have any external customers (products organization made for them or to be selling in future). In this case the team itself is playing the user as well as the developer hence killing the effectiveness of the process.

Non penso che questo sia assolutamente legittimo. L'idea alla base di Extreme è che i clienti non realizzino ciò che vogliono fino a quando non iniziano effettivamente a realizzarlo. Questo è altrettanto vero per i "clienti" interni come quelli esterni.

E se stai sviluppando qualcosa che non ha ancora clienti (come un prodotto non ancora pubblicato) devi avere qualcuno (o qualche gruppo) che agisce come un ipotetico cliente e decide cosa le persone vorranno. Extreme funziona altrettanto bene con loro in qualità di cliente.

Ho lavorato su un prodotto come questo, che era destinato a clienti esterni ma non ancora rilasciato. Anche se non l'abbiamo etichettato come "Extreme Programming", abbiamo usato un processo di sviluppo iterativo allo stesso modo senza una specifica formale estesa e con build frequenti. L'ho trovato abbastanza efficace.

• Not many things exists in formal documentation, this informality leads to vague vision and can create problems where the customer might say that this is not what we asked etc. etc.

Sì, tutto ciò che non è documentato è un problema. Extreme, dal momento che non è guidato da una specifica formale, potrebbe rendere più facile non documentare le cose. Ma Extreme non significa automaticamente "le cose non sono documentate". Dovresti comunque creare documentazione, ma viene creata insieme al programma piuttosto che in anticipo. E in alcuni casi significherà documentare il comportamento dopo averlo implementato. Questo non è un problema di per sé.

Quando si tratta di fatturazione, spesso hai bisogno di una documentazione scritta su esattamente ciò che verrà consegnato prima di iniziare il lavoro. Questo può essere più difficile con Extreme Programming.

Conclusione : Extreme è una metodologia che, come ogni cosa, presenta vantaggi e svantaggi. Devi tenere a mente entrambi quando lo usi (o lo insegna).

Le tue domande riguardano solo due argomenti principali di XP: "comunicazione diretta con il cliente" e "documentazione non troppo formale". Quindi, dal mio punto di vista, questa non è una domanda "XP", sono argomenti che fanno parte di qualsiasi altro processo di sviluppo agile che conosca.

Ecco i miei pensieri:

Too much involvements of the customer in the process make him start expressing his wishes rather than his needs to the software.

Bene, se si dispone di un processo a cascata, con una specifica completamente dettagliata in anticipo, con un sacco di requisiti, si può ottenere nei guai o quali di questi requisiti sono solo desideri e quali sono reali esigenze. Il modo più semplice per chiarire questo è IMHO che parla al cliente e gli mostra diverse alternative - ogni volta che arrivi a un punto in cui è necessario un chiarimento. Quindi è vero il contrario: lo "sviluppo agile" ti aiuterà a gestire meglio "bisogni e desideri".

Many products have multiple customers which lead to conflicting needs and opinions leading unnecessary blockades

Sì, con una specifica completamente dettagliata in anticipo quei conflitti potrebbero essere stati risolti prima lo sviluppo inizia (se si è fortunati). La soluzione a questo problema in un processo agile consiste nell'avere poche persone sul lato cliente che parlano direttamente con gli sviluppatori e un rappresentante responsabile per i clienti che possono prendere decisioni definitive in caso di conflitti.

Many products don’t have any external customers (products organization made for them or to be selling in future). In this case the team itself is playing the user as well as the developer hence killing the effectiveness of the process.

No, non è corretto, se solo gli utenti interni appartengono alla stessa società degli sviluppatori, "cliente sul sito" è molto più facile da installare rispetto a quando si hanno solo clienti esterni. Se hai no utenti diretti a portata di mano, potrebbe essere un problema, ma questo non è un problema specifico per l'agilità - dovrai quindi trovare qualcuno che assume il ruolo di un utente potenziale (e questa persona in genere non appartiene al team degli sviluppatori).

Not many things exists in formal documentation, this informality leads to vague vision and can create problems where the customer might say that this is not what we asked etc. etc.

Secondo la mia esperienza, se sviluppi seguendo una specifica formale senza comunicazione costante con il cliente, la possibilità di sviluppare qualcosa in cui i clienti dicono "questo non è quello che ho chiesto" è> 100 volte più alto di quando parli al cliente ogni giorno . Se anche tu riscontri ancora il problema, c'è una soluzione semplice: dopo ogni sessione cliente, scrivi una breve nota scritta su ciò che hai concordato. Se necessario, inviare quella nota al cliente e dargli la possibilità di apportare correzioni. Questo funziona in un processo agile così come in qualsiasi altro tipo di progetto.

Too much involvements of the customer in the process make him start expressing his wishes rather than his needs to the software

Stai sviluppando un software basato su ciò di cui un cliente ha bisogno? Cosa succede se un cliente vuole? Rifiuterai il cliente perché "hey cliente, costruisco solo software basato sulla necessità! ??"

Sono stato internato in un negozio di programmazione estremo e agile. Ho visto di persona le interazioni settimanali con i clienti che a volte hanno fatto impazzire QA e gli sviluppatori. Ma hanno consegnato esattamente ciò che il cliente desiderava, quando lo desiderava, ed è stato chiaro durante "Show and Tell" con il cliente cosa ha fatto, cosa non ha fatto e cosa dovrebbe essere come voleva.

Many products have multiple customers which lead to conflicting needs and opinions leading unnecessary blockades

Blocchi non necessari se il negozio estremo e agile chiarisce gli obiettivi dell'implementazione e quali saranno e non saranno incorporati nel prodotto. Diverse versioni dello stesso prodotto sono anche una possibilità e dipende da ciò che viene negoziato. Questo non deve essere un punto di contesa che blocca la produttività o porta a blocchi inutili.

Many products don’t have any external customers (products organization made for them or to be selling in future). In this case the team itself is playing the user as well as the developer hence killing the effectiveness of the process.

Non necessariamente. Anche un'interfaccia utente esterna con la quale si intervistano persone a caso per strada per determinare quale interfaccia per un particolare dispositivo sarebbe interessante per loro è una possibilità.

Not many things exists in formal documentation, this informality leads to vague vision and can create problems where the customer might say that this is not what we asked etc. etc.

Quindi è necessario utilizzare la documentazione formale. La documentazione formale tiene i piedi del cliente sul fuoco e un "questo è quello che ci hai detto che volevi" la punch-card a una linea coincide con la documentazione e l'interazione con il cliente, quindi non ci sono scuse. Come ho avuto l'opportunità di vedere questo in azione come stagista in un negozio estremo e agile, il cliente ha firmato sulla documentazione settimanale. Il cliente ha anche avuto la possibilità di implementare le modifiche e ha dovuto firmare anche quelle. Se c'è carenza di documentazione, c'è un invito al disastro.

The questions is why such conflicting opinions exists regarding XP, is it the matter of different scenarios or is there something else and till what extent the claim (as written in the title) is true.

Direi che dipende dall'intelligenza del negozio. XP e Agile sono linee guida e non istruzioni. Per operare con successo con XP e Agile, deve essere incorporato nelle pratiche operative e utilizzato nell'intera organizzazione. Il chilometraggio sarà sempre variabile e alcuni sosterranno senza dubbio che è cattivo, alcuni diranno che è buono. dove ho internato, è stato indubbiamente buono e ho avuto molto successo.

Dalla mia esperienza, quanto rigidi sono i principi di XP e Agile sembrano determinare se, quando incorporato nel "grind quotidiano", quanto successo ha lo sviluppo del software. Dove sono stato internato, l'interazione con il cliente ha guidato tutto e non è stato fatto nulla senza che un cliente, in primo luogo, avesse dichiarato che avrebbe dovuto essere eseguito. Il modo in cui questo negozio ha gestito le sue operazioni ha fornito un buon successo misurabile utilizzando solidi principi di sviluppo come parte del framework XP e Agile strettamente integrati in tutto ciò che fanno.

Se ci atteniamo alla domanda originale di

I am conducting academic research on the topic of Extreme Programming and whether its practices lead to creating space for more errors and bugs in applications.

Non sono sicuro che le preoccupazioni espresse siano rilevanti per la domanda.

Se c'è una paura del coinvolgimento del cliente che porta a desideri piuttosto che a bisogni, cercherò il team per essere sicuro che stia correttamente rompendo gli articoli in piccole versioni con disegni semplici. Dopodiché dare la priorità a quegli articoli in modo tale che il team possa lavorare a un ritmo sostenibile.

Se lo sforzo ha più clienti che non possono concordare necessità e opinioni, che speranza c'è di poter testare che il software soddisfi le esigenze dei clienti. È meglio che queste cose vengano chiarite all'inizio dello SDLC piuttosto che dopo.

Se il team deve essere l'utente per XP, questo non uccide il processo XP. In effetti, è specificato che il cliente è un membro del team. A volte questo membro del team è un dipendente interno piuttosto che un "vero cliente", è importante che l'individuo sia abilitato a rappresentare le esigenze del cliente. Non vedo come questa preoccupazione sia più rilevante per XP rispetto a qualsiasi altro approccio, sia esso agile o tradizionale.

Non ci sono molte cose nella documentazione formale? Se fatto correttamente, i team di XP dedicheranno più tempo alla pianificazione rispetto a un team tradizionale. Inoltre, poiché le specifiche sono scritte congiuntamente tra i membri del team di business e di mentalità tecnica all'inizio di ogni iterazione, le specifiche tendono ad essere più accurate rispetto al grande design in anticipo.

XP si concentra sugli aspetti di sviluppo (ingegneria) di un progetto. Le cose che dovrebbero essere discusse quando si considera XP sono:

• La curva di apprendimento per lo sviluppo guidato dai test interferisce con lo sviluppo di un prodotto di qualità.
• Quanto è difficile creare test di qualità che porteranno a un codice di qualità.
• Quanto è probabile che gli sviluppatori "ingannino" il ciclo di sviluppo basato su test e scrivano prima il codice, poi il test più tardi. Importa?
• Quanto sono efficaci gli sviluppatori che lavorano in coppia rispetto allo sviluppo più tradizionale (una persona che scrive il codice per una funzione).
• Il design iterativo / emergente porta a sistemi più stabili e scalabili rispetto ai sistemi progettati in anticipo.
• Quanto è efficace l'integrazione continua per prevenire proattivamente i difetti del software.

Per me quelle sono le domande da considerare con XP. Le preoccupazioni sollevate sopra sembrano essere più adatte per una discussione su Scrum (che è molto comunemente associato a XP).

Per i riferimenti vedrei:

link

o

link

Saluti e buona fortuna con la tua ricerca.