Qual è la mentalità ideale per uno sviluppatore che partecipa a una riunione di raccolta dei requisiti?

Rispondere alle tue domande in ordine:

1. La mentalità che entra in questo in termini di preparazione è quella di porre le domande giuste in modo che l'utente sappia esattamente ciò che desidera . Questo è molto più difficile di quanto sembri. Devo sottolineare ponendo le domande giuste . Sii specifico, se c'è qualche ambiguità, fai un'altra domanda. Di solito durante questi incontri una risposta da parte del cliente genera 3 nuove domande. Una volta che sai cosa vogliono, allora il tuo compito è capire come impatta i diversi sistemi, non i loro.

Se c'è qualcosa che il cliente vuole in termini di requisiti che sono impossibili, allora diglielo (i miei professori lo chiamavano "ali su un'auto"). A volte i clienti non conoscono abbastanza bene il software per conoscerne le capacità. Lavoraci.

2. No, viene durante la fase di progettazione. Se non può funzionare, i requisiti sono rivisitati.

3. Non preoccuparti di farlo bene la prima volta, perché sicuramente non lo farai. I requisiti si infastidiscono sempre per il fatto di essere creep, i clienti che vogliono cose nuove ma che non ti dicono mai, ecc. Preparati poi vai con il flusso.

Gli utenti la maggior parte delle volte sanno esattamente il loro lavoro quotidiano e quali problemi devono risolvere. Ciò che in genere non sanno è

a) come deve essere esattamente il software per supportare tale processo.

b) come possono spiegarti il loro processo.

Quindi concentrati sulle domande per capire cosa vogliono veramente l'utente (i loro obiettivi, il loro processo di lavoro), e non se un pulsante dovrebbe essere blu, rosso, a sinistra o a destra del la finestra di dialogo. Spesso non è tanto importante chiarire qualsiasi ambiguità, ma le corrette ambiguità.

Riguardo ai "dettagli di basso livello": evitare che durante l'incontro - spesso ci sono diverse soluzioni per raggiungere lo stesso obiettivo, con diversi dettagli di basso livello, diversi costi / sforzi di sviluppo, diversa fattibilità. Per la mia esperienza, è molto meglio pensare un po 'ai requisiti (dopo l'incontro!), E suggerire una soluzione fattibile più avanti, quando hai fatto un'analisi approfondita dei requisiti.

E cerca di evitare di preoccuparti del potenziale sforzo di sviluppo per requisiti specifici (almeno, non durante la riunione). Solo scrivere tutti i requisiti non significa che dovranno essere implementati 1: 1. Dopo il vostro incontro, voi o il team avrete la possibilità di analizzarli, fare stime per l'implementazione (probabilmente diverse stime per le diverse soluzioni possibili per lo stesso requisito), e in seguito i requisiti saranno prioritizzati o discussi di nuovo. Quello che dovresti evitare è dire alla gente qualsiasi stima durante la riunione dallo stomaco, anche se chiedono o cercano di farti pressione. Dì solo "Ti darò una risposta più tardi".

Quello che cerco di sottolineare quando faccio la raccolta dei requisiti è che se questo è per la sostituzione di un sistema esistente, non pensare a come si fanno le cose nel sistema esistente, ma piuttosto quale sarebbe il modo ideale per realizzare ciò che è necessario fare.

Così spesso gli utenti sono bloccati nel modo in cui le cose sono fatte possono solo descrivere le loro esigenze in quel modo.

La cosa più importante per te come implementatore è capire che cosa stanno veramente cercando di realizzare. Un libro che mi ha aiutato mentre stavo imparando come fare analisi di business era Modelli di requisiti software questo libro spiega come ottenere una più profonda comprensione di alcuni dei requisiti impliciti che a volte vengono ignorati.

Anche Domain Driven Design è un buon libro da studiare (specialmente con il concetto di Linguaggio Ucraino , che in pratica dice che utilizzare i termini usati dagli esperti di dominio non tradurli in "speak speak" così tanto si perde nella traduzione).

Un altro elemento che è importante è diventare il più rapidamente possibile informato sul tuo dominio di destinazione. Quando mi sono sviluppato per un'azienda di logistica, credo che abbia imparato meglio su Shipper, Destinatari, Parti responsabili, Carichi inferiori, Hub, Docks e tutto ciò che dovevo sapere per avere una conversazione intelligente con l'azienda. Quando ho lavorato per una compagnia petrolifera ho avuto il tempo di conoscere Bores, Wells, Fields, Output, Saturation e tutte quelle cose divertenti che sono andate con quell'industria.

Questo è il consiglio più prezioso che posso dare, conoscere il settore per il quale stai sviluppando il software e sarai in grado di raccogliere i migliori requisiti dagli utenti.