Scrivere software in assenza di requisiti è un'abilità da possedere o una situazione che dovrei evitare?

Trovo che alcuni sviluppatori software siano molto abili in questo, e spesso i tempi sono elogiati per la loro capacità di fornire un concetto di lavoro con requisiti astratti. Francamente, questo mi fa impazzire, e non mi piace "inventarlo" mentre vado. Pensavo che fosse problematico, ma ho iniziato a percepire un cambiamento e mi chiedo se ho bisogno di modificare il mio processo di pensiero (e programmazione) quando mi viene data una direzione molto piccola. Dovrei iniziare ad acquisire questa abilità come abilità, o attenermi all'idea che la raccolta dei requisiti e le regole aziendali sono la prima priorità?

L'abilità non è quella di scrivere software senza requisiti. Si tratta invece di ottenere requisiti dal proprietario del progetto indipendentemente dal fatto che esista o meno una documentazione formale relativa ai requisiti.

La raccolta dei requisiti è sicuramente la tua prima priorità, ma non è necessario che tutte le esigenze del cliente vengano annotate in anticipo. Il rischio è ovviamente che potresti perdere alcune informazioni vitali che rendono inutile l'architettura del tuo sistema se non sei riuscito ad avere il giusto tipo di conversazioni con il tuo cliente, tuttavia non è insolito definire un prodotto e persino ottenere gran parte dello sviluppo fuori mano, rimandando le principali decisioni sull'architettura del sistema fino all'ultimo momento possibile. Questo è un approccio di sviluppo snello che ha lo scopo di garantire che non ti impegni a un'architettura potenzialmente incompatibile troppo presto nello sviluppo del tuo prodotto fino a quando non avrai informazioni più solide. Nelle situazioni descritte dall'OP nella sua domanda,

Sì, a volte è necessario guardare un po 'la sfera di cristallo per arrivare al cuore di ciò che il cliente sta veramente chiedendo, che è dove i picchi di prototipazione e il lento - e sì a volte doloroso - richiedono l'estrazione incrementale dei requisiti che sviluppi davvero buone capacità di relazione con il cliente, e anche la pazienza di rendertene conto con qualsiasi idea software complessa, che all'inizio il cliente spesso non sa molto più di te su ciò che il software deve effettivamente fare. Molto spesso, il cliente ti chiama in anticipo per dipendere dalla tua esperienza per definire i suoi requisiti in quanto il cliente non ha sempre l'esperienza o la conoscenza necessarie del processo di sviluppo del software.

Questo è molto ambiguo ...

Due cose che posso dire:

1. Ci sono molte persone tecniche di grande talento le cui carriere si fermano perché aspettano requisiti perfetti. Oppure giocano "Spiacente, non posso farlo, non era nei requisiti". La realtà è che la scrittura dei requisiti è molto difficile. La precisione richiesta per le buone esigenze è diversa da qualsiasi cosa la maggior parte degli uomini d'affari abbia mai creato. C'è un ponte tra tecnologia e business e le persone che fanno venire gli altri al 100% del modo di incontrarli di solito perdono.

2. Ci sono persone software che imparano i domini come buoni o migliori dei loro clienti. Queste persone valgono il loro peso in oro, anche se non sono al 100% i migliori sviluppatori. Ho visto persone di software anticipare le esigenze di marketing quantitativo dei migliori brand manager nel paese. Non erano i migliori nel codificare tutte le soluzioni, ma erano eroi perché potevano attraversare il ponte.

La vita non è fatta di bianchi e neri però. Se disegni una casella stretta intorno a te, ti limiterai. D'altro canto, anche un'organizzazione che rifiuta ciò che è necessario per creare la tecnologia è limitata. Dovrai vedere dove nel grigio preferisci essere.

I requisiti sono i passaggi del viaggio, una visione è la direzione

Per molte applicazioni una specifica tecnica altamente dettagliata è fin troppo anticipata poiché una breve discussione potrebbe rendere inutile il loro documento accuratamente composto. Invece, inizia con una visione. Se tutti comprendono il quadro generale, i requisiti possono essere completati lungo le discussioni.

Come sviluppatore devi imparare a usare queste discussioni per cercare i requisiti . Ciò significa porre al cliente domande chiave che lo inducono a pensare a come la loro decisione oggi si adatta alla visione generale. Quanto prima si svolgono queste discussioni più dettagliate, tanto più rapidamente la visione complessiva si solidificherà in un progetto coerente.

Dovresti tenere traccia dei risultati di queste discussioni in una sorta di tracker dei problemi in modo che altri possano commentarli se hanno perso la discussione originale. E in modo che tu possa avere un record a cui tu, o altri membri del vostro team, potete fare riferimento nel caso abbiate bisogno di chiarimenti.

Quindi, impara a programmare contro la visione, ma sii pronto a pescare per quei requisiti quando sarà il momento.

Steve Jobs credeva che i clienti non fossero in grado di descrivere esattamente come avrebbero dovuto apparire i prodotti futuri, quindi è compito tuo consegnarli. Quindi, a meno che tu non fornisca software personalizzato in ogni momento, dimentica le specifiche formali e inizia creando prototipi e lasciando che i clienti giochino con loro e ti diano ciò che pensano. Devi mettere la persona giusta a fare il prototipo e hanno bisogno di aiuto. Lo dico per esperienza: sono la scimmia di prototipazione che ama creare interfacce intuitive e ho collaborato con qualcuno nel prodotto che capisce cosa vogliono i clienti e può spiegare le cose sulla carta o usando Excel.

Nessuno di noi è un genio, ma pensiamo allo stesso modo - puoi quasi dire che abbiamo chimica e abbiamo avuto un impatto enorme su quali cose vengono costruite e su come. Ora, solo un team medio-grande può permettersi di avere un prototipo e un non programmatore che sviluppa esclusivamente prodotti, ma ne vale la pena. Il prototipo è la fase più economica nello sviluppo del software, quindi ha senso solo l'interfaccia utente e il comportamento apparente giusto. Non ho letto Code Complete ma penso che ci sia qualcosa di simile scritto in quel libro.

Le specifiche sono belle da avere, ma non sono mai perfette. Esiste un teorema al riguardo. Non puoi provare che le specifiche sono complete e non puoi provare che lo strumento non ha bug o che si fermerà :)

Tuttavia, le società di software spediscono software continuamente nonostante queste imperfezioni nel processo. Le specifiche non saranno mai perfette. Le specifiche sono anche UNNATURAL e obsolete. Una specifica per un prototipo è come la tabella del logaritmo è per un singolo grafico: una specifica è essenzialmente una brochure noiosa che deve essere stampata mentre è possibile interagire con uno strumento / grafico. Controlla http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html per l'ispirazione.

Ora, le specifiche sono buone se devi avere un contratto per coprire il culo. Ma una specifica dovrebbe ancora venire dopo un prototipo, non prima. Il tuo compito è capire come rendere i prototipi economici.

Ho spesso trovato che in alcune situazioni ho bisogno di agire come un analista di business, scoprire esattamente come il business attualmente lavora, come la gente pensa funziona (spesso cose molto diverse), e come avrebbero come farlo funzionare.

Ho trovato successo essendo sempre chiaro sulle decisioni che sono stato costretto a prendere per costruire il software. Spiego il mio ragionamento, scrivo documentazione su ciò che ho scoperto, faccio grafici e li distribuisco a tutti, ecc.

Probabilmente non farai una buona impressione rifiutando di fare qualsiasi lavoro fino a quando non verranno consegnati i requisiti completi. Ma raccogliendo tu stesso requisiti di buona qualità (senza necessariamente attirare l'attenzione sul fatto), raggiungerai lo stesso obiettivo del software di qualità.

E sì, come hanno detto altri commentatori, costruisci sempre il software supponendo che cambierà. Il cambiamento è l'unica costante su cui puoi contare. Costruisci sempre il tuo software abbastanza flessibile e modulare in modo che non sia doloroso aggiornarlo quando compaiono improvvisamente nuovi requisiti.

Se vuoi lavorare come sviluppatore software all'avvio, è un'abilità da possedere.

Se vuoi lavorare in una società di consulenza, è una situazione da evitare a tutti i costi. Questo perché la tua azienda viene pagata in base al modo in cui implementi le specifiche / i requisiti e non a quanto bene hai risolto il problema del cliente.

Se stai programmando per divertimento nel tuo tempo libero, allora è la tua chiamata. Se non ti senti qualificato per effettuare la chiamata per i tuoi progetti per il tempo libero, prova un paio in ogni modo e vedi cosa funziona. Inoltre, non è necessaria una misura unica, alcuni progetti richiedono l'uno o l'altro tipo di approccio. Di solito, se scegli quello sbagliato in uno di questi progetti, lo scoprirai abbastanza velocemente.

Un po 'di entrambi. Devi soddisfare i tuoi clienti, il che significa che devi sapere cosa vogliono. D'altro canto, i clienti sono notoriamente cattivi nel comunicare ciò che vogliono veramente.

Quindi vuoi evitare scenari in cui non sai cosa vogliono i clienti, ma inevitabilmente ti imbatterai in uno scenario in cui i requisiti sono "squishy" nel migliore dei casi e ingannevoli nel peggiore dei casi. Un buon programmatore del mondo reale richiede adattabilità.

Non è possibile scrivere un programma senza requisiti. Anche il 'Hello World' ha il requisito: produrre output. Quindi, penso che tu stia chiedendo dei requisiti formali, sotto forma di un grosso stack di qualcosa di simile a UML. E per quanto riguarda quelli, ho incontrato 2 tipi di persone:

1) Persone che necessitano di requisiti formali. Hanno bisogno di sapere esattamente cosa fare e, nella migliore delle ipotesi, come farlo. Amano le frasi come La procedura A che prende l'argomento B produrrà C , e odiano quelle: il programma dovrebbe rendere più efficace il lavoro del nostro dipartimento . Di solito sono animali da compagnia.

2) Le persone che sono opposte a 1. Odiano sentirsi dire cosa fare e come fare, amano sentirsi dire cosa si dovrebbe ottenere. A loro piace parlare con il cliente, analizzare ciò che dicono e quindi sviluppare la propria soluzione. Di solito sono liberi professionisti e non si adattano bene alla società.

Non dirò quale di questi è meglio. Entrambi hanno i loro pro e contro. Sono semplicemente adeguati per le altre condizioni.

NON è possibile sviluppare software operativo senza conoscere i Requisiti; ma puoi avere una buona dose di jolly nello sviluppare ciò che la tua esperienza ti dice che i Requisiti sono probabiliessere. Lo sviluppo agile utilizza una combinazione di tecniche "intuitive", tra cui la regola 80:20 e la "scoperta" dei requisiti mediante prototipazione. In altre parole, un team di sviluppo esperto fa una migliore ipotesi su ciò che è necessario e produce un prototipo del software. La regola 80:20 dice che saranno corretti all'80%. Le parti interessate del progetto riesaminano quindi il prototipo tangibile. Il loro feedback inizia a colmare il gap del 20% nella nostra comprensione dei Requisiti. Quindi, in effetti, Agile non riguarda la scrittura di software senza requisiti, ma piuttosto l'utilizzo della tua esperienza precedente per dire "vuoi qualcosa del genere?" Il che, nell'80% dei casi, ti consentirà di fare un balzo in avanti e confermare ciò che è veramente necessario più velocemente che spostarti attraverso i processi dei Requisiti tradizionali.

Chi ha detto che Agile stava scrivendo codice in assenza di requisiti? So che il Manifesto è stato interpretato in questo modo da alcuni ... ma questo non lo rende giusto.