Ecco il breve e il dolce: guadagnerà slancio.
Molti datori di lavoro hanno posto molta enfasi sull'esperienza passata, sulle scuole in cui sei stato e, per mancanza di un modo migliore di dire "essere bruciato". Contrariamente alla credenza popolare, lo sviluppo del software non è tanto creativo quanto uno sforzo come molti di noi nella tecnologia vorrebbero credere. Nelle aree in cui consente e richiede persino creatività, in genere richiede la comprensione di personaggi / storie degli utenti finali, requisiti di sistema, domini aziendali, economia, processo di ingegneria del software e architettura del software molto prima di entrare nella costruzione del software [codifica].
Dall'avvento del Movimento Agile, il consenso è stato erroneamente posto in primo piano su programmazione e sviluppo. Questa è stata in realtà una cattiva interpretazione di ciò che gli autori del Manifesto Agile stavano cercando di ottenere sebbene potrebbe essere difficile ricavarlo dal Manifesto. Agile ha preso a prestito pesantemente e persino adottato direttamente i principi LEAN. LEAN si concentra sul personale addetto all'implementazione, ma solo dal punto di vista del fatto che questi individui sono più vicini ai clienti effettivi dell'azienda [ leggi: cliente contrattuale ].
Perché questa distinzione è importante? I dipendenti dell'implementazione sentono direttamente l'impatto di molte decisioni, sia positive che negative. Pertanto, sono posizionati in modo univoco per apportare semplici modifiche che possono avere un impatto drammatico su prestazioni e qualità. Purtroppo, spesso non sono completamente coinvolti per la loro conoscenza del cliente finale, lasciando molte opportunità per migliorare le prestazioni e la qualità del prodotto sul tavolo. La missione di LEAN è quella di offrire costantemente maggiore valore al cliente finale raggiungendo livelli sempre più elevati di efficacia attraverso la rimozione dei rifiuti, aumentando la velocità di consegna e il miglioramento della qualità. Agile ha spinto la busta sulla rimozione dei rifiuti all'interno dello spazio di costruzione del software, ma la vera efficacia dal punto di vista del cliente finale [e del cliente finale] è stata minima.
A tal fine, vale la pena notare i risultati positivi in termini di velocità e qualità come un chiaro miglioramento nell'artigianato del codice [mescolando scienza e arte] ci hanno spinto in avanti sul fronte della costruzione, ma nel processo abbiamo perso di vista ciò che è importante: il cliente. E non intendo solo l'utente finale, ma il cliente finale dell'azienda. Proprio come in LEAN, tutto parte dal cliente reale e procede a ritroso. Cosa c'entra questo con CSDA e CSDP dell'IEEE? Plenty.
Per cominciare, spesso ci vuole una persona radicata nel tipo di comprensione riflessa nelle discipline ingegneristiche per comprendere appieno che un processo deve essere sempre focalizzato sull'obiettivo generale, tenendo conto della sua effettiva efficacia, pietre miliari e attributi di qualità. Se ti manca qualcuno di questi tratti, non riesci a fornire pieno valore al tuo cliente [aziendale] contrattuale, che a sua volta potrebbe generare un'ondata di eventi che diminuiscono il valore per i clienti finali / clienti dell'azienda. Non bene.
Inoltre, la capacità di assumere responsabilità di leadership [che se si dispone di un team autogestito {come mandato Agile} richiede che tutti siano in grado di condurre ad un certo grado] di solito richiede una buona ampiezza e profondità di comprensione della materia in questione, il funzioni con cui interagisce, nonché la capacità di comunicare queste conoscenze a più parti interessate da una varietà di ambienti. La realtà è che, qualunque sia la descrizione del lavoro, le persone si aspettano che gli sviluppatori siano ingegneri nel profondo. Che sono persone intelligenti e di talento con ampiezza e profondità per le loro competenze, che comprendono la padronanza delle loro attività primarie, nonché la capacità di comprendere e risolvere per il dominio problematico di qualsiasi cliente contrattuale.
Allora perché la grande novità di Agile quando si discute di CSDA e CSDP? Semplice - Fondazione. Se hai un team di CSDA e CSDP, anche se in qualche modo hanno imbrogliato, avranno comunque una discreta conoscenza di dove vanno tutti i processi e le discipline all'interno dell'ingegneria del software, perché sono lì e quando tornare a loro come mezzo di unificare la comprensione prima di avanzare in una nuova direzione. Quella Fondazione creerà un'opportunità per la consegna coerente delle pratiche di sviluppo del software, attraverso le metodologie SDLC e la capacità di ruotare tra e / o combinare i metodi SDLC abbastanza facilmente. IEEE ha creato una strada per i professionisti dell'informatica, che si tratti di specialisti in ingegneria, laureati in CS, professionisti IT o sviluppatori autodidatta, per unificare e dimostrare una comprensione di base di sviluppo software, consegna, e il processo di disattivazione come disciplina di ingegneria che è degna di rispetto e che dovrebbe essere trattata con rispetto. E a causa di questi fattori, acquisirà slancio.