SILVA, Francisco Eronildo da [1]
PINTO, Aurílio Guimarães [2]
FREITAS, Caio Guimarães [3]
ALMEIDA, Cristiany Caliri de [4]
RIBEIRO, Dallas dos Santos [5]
LEITE, Francisco Canindé da Silva [6]
OLIVIERA, Geveson de Souza [7]
MORAIS, Gilvanete Melo de [8]
PERES, Paulo Júnior de Jesus [9]
SILVA, Francisco Eronildo da; et.al. Applicabilità della metodologia Agile nello sviluppo di Software – mischia come un riferimento. Rivista scientifica multidisciplinare di nucleo di conoscenza. 07 edizione. anno 02, vol. 03. PP 05-16, ottobre 2017. ISSN: 0959-2448
Riepilogo
Questo studio si propone di analizzare la velocità che danno le metodologie agile il processo di sviluppo software, mostrando come le aziende utilizzano questi metodi come un modo per ridurre il tempo e lo sforzo nello sviluppo di software, prendendo come riferimento la metodologia SCRUM. La parte di metodologia agile della premessa su cui i risultati dovrebbero essere raggiunto rapidamente senza compromettere la qualità del prodotto finale (software), di conseguenza la mischia è una metodologia che mira a migliorare la pianificazione di progetti software cui premessa è rompere il prodotto in pezzi più piccoli e quindi offrire le funzionalità senza client aspettare troppo a lungo per visualizzarli. Tra gli autori hanno effettuato una ricerca per la costituzione di questo lavoro, concettuale evidenzia Aragona Fernandes (2014), Somerville (2007), Roger Pressman (2011), Kim Pries (2010) e Ken Schwaber (2014). Le conclusioni più importanti sono che l'uso di metodologie agile può dare sviluppo software rapido, mostrando più efficacia, dinamismo e offrendo vantaggi alle aziende che adottano la metodologia, questi fatti, ha dimostrate in questo lavoro.
Parole chiave: Agile, Scrum, governance, ingegneria del Software.
1. Introduzione
L'agile ha cominciato ad avere un'enfasi sulla 80. Il sito DEVMEDIA ha detto: "metodologie agili sono stati intorno per anni, poiché l'80, ma alcune informazioni andare attraverso la distorsione, che rendeva difficile all'inizio l'utilizzo di metodologie. Pertanto, gli sviluppatori sono giunti a comprendere la metodologia agile come qualcosa che può, in altre parole, possiamo sviluppare senza documentazione, alcun valore predefinito e con noncuranza. Questo non è vero, le metodologie agile possono portare al successo il progetto e sono utilizzate nel settore." Questo lavoro dimostra che l'uccisione di agile basato su autori rinomato l'organizzazione e le cure necessarie che il progetto di software devono essere efficienti ed efficaci, e ogni giorno, si ottiene lo sviluppo del software del mercato, utilizzato nelle industrie e enti pubblici che assumono fabbriche in outsourcing per sviluppare i loro sistemi.
Questo studio si limita per mostrare i benefici agili porta allo sviluppo del software. Ad esempio se avete il modus operandi dei CTI, società di software che opera nel mercato nazionale e adottando la metodologia di sviluppo di software comune, ma che dipende sia il client, optando per la metodologia agile.
La Soprintendenza del libero scambio zona SUFRAMA-Manaus, che, attraverso l'offerta, assunto al servizio della CTI e optato per il passaggio alla metodologia agile.
SUFRAMA è un'autorità federale responsabile della gestione di incentivi fiscali. La maggior parte dei loro sistemi sono critica e operano con limitazioni, quindi un'offerta il servizio di fabbrica software per lavorare con i metodi agili. L'opzione per i metodi agili in ragione di consegna veloce e di qualità perché il engessava tradizionale la metodologia di processo.
Il metodo agile dispensa con una risma di carta, si concentra sulla qualità del prodotto, perché ciò che conta per il client è il funzionamento del software.
È questo non entrare nei dettagli del cambiamento nella metodologia adottata dal SUFRAMA e sì, illustrare che varie industrie ed enti governativi, stanno optando per il cambiamento del vostro modello di sviluppo software per metodologia Agile.
Pur essendo un'opzione per lo sviluppo software, metodologia agile, che offre vari benefici allo sviluppo certamente potrebbe non essere adatto a tutti i progetti. Per una migliore comprensione del soggetto, è necessario rivedere alcune della storia di sviluppo agile.
L'obiettivo generale di questo lavoro è quello di fare una revisione sistematica della metodologia agile. Il metodo SCRUM sarà l'oggetto di questo studio, dove saranno elencati gli aspetti negativi e positivi.
Questa ricerca è giustificata dalla necessità che l'industria del software deve effettuare le consegne dei prodotti con il minor tempo possibile ai propri clienti, senza perdere di vista la qualità, l'economia e la soddisfazione.
La metodologia di questo studio è la ricerca descrittiva ed esplicativa, avendo come raccolta di dati bibliografici.
2. Sviluppo
Questo studio inizia esaminando il concetto di Software che è stato originariamente proposto nel 1968, in una conferenza organizzata per discutere di quello che allora si chiamava la "crisi del software". Software crisis ha provocato indirettamente l'introduzione di un nuovo computer hardware basato su circuiti integrati. L'applicazione di circuiti integrati di applicazioni informatiche, considerata non è fattibile, valide proposte. Il software risultante era più grande e più complesso di precedenti sistemi software (SOMMERVILLE, 2007).
Ingegneria del software è un ramo di ingegneria, il cui obiettivo è quello di sviluppare all'interno di sistemi di software di alta qualità costo appropriato. Ingegneria del software è una tecnologia a strati, che coinvolgono strumenti, metodi, processi e attenzione alla qualità. (SOMERVILLE, 2007). La terra di qualsiasi approccio ingegneristico (incluso il software) deve essere in un impegno organizzativo per la qualità.
Gestione totale della qualità sei Sigma1 (GYGI; DECARLO; WILLIAMS, 2008) e filosofie simili che promuovono una cultura di processi di miglioramento continuo e è questa cultura che, alla fine, conduce allo sviluppo di approcci sempre più efficaci nell'ingegneria del Software. La pietra angolare che supporta il software engineering è il focus sulla qualità (PRESSMAN, 2011).
Per quanto riguarda la storia dello sviluppo agile, lo stesso ha cominciato nel 2001, con il "Manifesto for Agile software development", che è stato firmato da Kent Beck, un ingegnere di software americano, creatore di Extreme Programming e Test-Driven e sedici più rinomato sviluppatori. Dettagli di questo fatto possono essere verificati presso l'indirizzo https://www.agilealliance.org/agile101/the-agile-manifesto/.
Il manifesto enfatizza gli individui e le interazioni nel corso di processi e strumenti; il software in esecuzione più di una documentazione completa, in collaborazione con il cliente invece di trattative dei contratti e le risposte di cambiare in seguito a un piano.
Questo non toglie l'importanza della documentazione o processi e in nessun modo riguardano l'inefficacia degli strumenti, mezzi, tuttavia, che la consegna del software è più apprezzata, come dichiara Pressman:
"L'ingegneria del software agile si mescola filosofia con un insieme di principi di sviluppo. La filosofia sostiene la soddisfazione del cliente e la consegna del Priore incrementale; progetto piccola squadre e altamente motivati; Metodi informali; Ingegneria del software minimi artefatti e, soprattutto, semplicità nello sviluppo generale. I principi di sviluppo la priorità di consegna più di analisi e design (anche se queste attività non sono scoraggiate); anche la priorità la comunicazione attiva e continua tra sviluppatori e clienti ". (Pressman, 2011)
Un progetto coinvolge persone e modifiche, soprattutto quando si tratta di consegne. In questo modo le metodologie agili, lavorando con i team altamente motivato, perché sono collegati direttamente al processo, coinvolti in ogni sua parte, sentendo la responsabilità su di sé il successo del lavoro e sapere che hai la possibilità di sostenere i cambiamenti durante l'intero processo di sviluppo.
Nello sviluppo agile, non è possibile apportare un piano completo di tutto ciò che noi dovremmo eseguire per poi iniziare lo sviluppo, senza contatto con il cliente, invece, sviluppato in modo incrementale, cioè il prodotto è fatto gradualmente e costantemente ha trasportato questo senso, qualsiasi cambiamento necessario richiesto dal client o visto da membri del progetto, in qualsiasi momento durante lo sviluppo, ne risultano danni non completo e la modifica può essere eseguita senza gravi danni, perché il progetto è in fase di sviluppo e non è stato completato.
Gli incrementi di iniziali del sistema possono fornire una caratteristica di alta priorità, in modo che clienti presto possono ottenere il valore per lo sviluppo del sistema. I clienti possono Visualizza i requisiti di pratica e specificare le modifiche occorre integrare nelle versioni successive del sistema.
In questo modo, il client può rendere più rapido l'utilizzo delle risorse di sistema. Che cosa sarebbero voluti mesi per essere consegnati in settimane e in grado di verificare bug e specificare nuove modifiche o miglioramenti, senza dover arrivare alla fine dello sviluppo per vedere i problemi.
Questa metodologia fornisce anche una maggiore conoscenza del sistema per la squadra, perché capirà il business a svilupparla, rendendolo, con maggiore velocità e precisione, e in caso di errori, la squadra perderà meno tempo per l'analisi e può correggere l'errore rapidamente.
Secondo Aguinaldo Aragona Fernandes (2014), inizialmente, la mischia è stata progettata con messa a fuoco nitida nella consegna di progetti di sviluppo di software in un ambiente complesso. Tuttavia, è stato sempre più applicato in progetti di sviluppo di prodotto di altre nature ".
Aragona afferma inoltre che:
"La mischia è costituito da un metodo iterativo e incrementale per la gestione di progetti complessi, il cui obiettivo è quello di garantire la consegna più veloce e massimizzare l'aderenza alle esigenze del cliente, la cooperazione tra i membri del team e la produttività di ogni partecipante. Uno dei metodi del cosiddetto "agile" è più diffuso nel settore it mercato, (Aragon Fernandes 2014).
Metodologie agili possono essere applicate in risoluzioni di problemi complessi, come lo sviluppo di software informa Schwaber:
"Il progetto complesso situazioni si verificano quando la complessità delle attività intermedia non consente un processo definito controllato, è possibile generare un prodotti di ciclo a livelli accettabili di qualità. La complessità di un progetto è direttamente proporzionale alla complessità delle esigenze dei clienti e la tecnologia in questione, ale per essere in gran parte dipendente dalle caratteristiche di ogni membro del team, tenendo conto della diversità di competenze, conoscenze, atteggiamenti ecc, che può essere trovato in qualsiasi gruppo di persone ". Schwaber (2004)
In situazioni come questa, Schwaber consiglia di utilizzare il concetto di controllo di processo empirico, che utilizza meccanismi come auto-organizzazione e senso di urgenza con seguenti pilastri:
"Visibilità: tutti gli aspetti che influenzano i risultati desiderati devono essere visibili ai processi di controllo.
Ispezione: i vari aspetti del processo dovrebbero passare attraverso ispezioni periodiche al fine di rilevare variazioni inaccettabili.
Adattamento: il processo o i prodotti intermedi devono essere regolati dopo ispezione per minimizzare le deviazioni future più severe, case caratteristiche e risultati rientrano nei limiti accettabili e mettere a repentaglio l'accettazione del prodotto finale. Schwaber (2004)
La mischia è strutturata in un insieme di pratiche condotte da squadre in ruoli specifici, organizzati in un flusso di attività o eventi di durata fissa, totalmente controllati con manufatti e regole ben definite, che mira ad ottenere prodotti utilizzabili a intervalli a corto di tempo.
Ogni pratiche di Scrum sono basate su uno "scheletro" rappresentato da iterazioni successive delle attività di sviluppo, (ogni uno generando un incremento del prodotto), ispezionate e regolate quotidiana dai membri del suo personale e orientato per un elenco dei requisiti iniziali.
All'inizio di ogni iterazione, il team esamina che cosa dovrebbe essere fatto e determina quali funzionalità vitali da consegnare alla fine dell'iterazione. Il team è libero di utilizzare il vostro sforzo nel resto dell'iterazione e la funzionalità alla fine il prodotto finale costruito.
La figura seguente mostra il flusso di mischia:
Su un progetto Scrum, tutte le responsabilità sono divise tra tre ruoli:
ProductOwner: persona responsabile della gestione del prodotto Backlog (assicurando che è visibile a tutti), generare e diffondere i requisiti di progetto, come pure il piano per consegne successive, definire le priorità dei risultati che porteranno il maggior valore aggiunto al progetto.
Scrum Master: responsabile per l'implementazione del metodo Scrum, anche come insegnare a tutti coinvolti nei progetti e garantire che tutti seguono le regole e le pratiche.
Scrum team: gruppo di sviluppo collettivamente responsabile per il successo di ogni iterazione e il progetto nel suo complesso, deve essere composto da persone multi-disciplinare in grado di auto-organizzazione e di autogestione.
Il processo sostenuto di Scrum copre i seguenti elementi come indicato di seguito:
La visione: deve essere preparato da ProductOwner, tra cui stampa e pianificare le tappe di consegna prodotto ogni Sprint, al fine di massimizzare il ritorno sull'investimento del progetto di sviluppo di prodotto.
Il Backlog di prodotto: anche preparato da ProductOwner, contiene un elenco dei requisiti funzionali e non funzionali, la priorità e diviso in releases (Sprint).
La riunione di pianificazione Sprint: il progetto si articola in Sprint dura trenta giorni di calendario, per essere eseguite una dopo l'altra, senza interruzioni. La pianificazione è fatto in un incontro con la partecipazione del Team Scrum e di ProductOwner, in due periodi di 4 ore ciascuna:
Nella prima ora è impostata che il campo di applicazione ("cosa") verrà trattato da Sprint, attraverso la selezione dei requisiti di Backlog del prodotto che verranno messi nel Backlog Sprint.
In 4 ore di ritardo, l'effettiva pianificazione dei compiti da eseguire nello Sprint, ("come") e l'inizio ufficiale della volata, a cui tempo inizia a decorrere il termine di 30 giorni.
Sprint: il proprio prodotto sviluppo iterazione, che ha una durata fissa. Uno Sprint include loro pianificazione riunioni, revisione e retrospettiva.
Il Daily Scrum: riunione giornaliera di quindici minuti, dove ogni membro del team risponde alle domande seguenti:
- Quello che ho fatto sul progetto dall'ultimo Daily Scrum?
- Che cosa ho intenzione di fare fino a quando il prossimo Daily Scrum?
- C'è qualche restrizione o impedimento a che io onoro il mio impegno di Sprint corrente e/o il progetto?
Inoltre, il team Sincronizza tutte le attività e programma incontri necessari per il proseguimento del progetto.
Dettagliare un po ' più punti di vista di parti finora.
Riunione di revisione dello Sprint: in 4 ore, il Team Scrum presenta il ProductOwner (e altre parti interessate) il lavoro generato nello Sprint e determina fra loro cosa fare nello Sprint successivo.
La riunione retrospettiva dello Sprint: in 3 ore, lo Scrum Master incoraggia i membri del team di rivedere la mischia sviluppo elaborare le pratiche di nascita e il modello di processo Scrum, al fine di renderlo più efficace e gratificante per lo Sprint successivo.
Secondo Schwaber (2004), lo Sprint pianificazione riunioni, Daily Scrum, la revisione e la retrospettiva dello Sprint sono, insieme, le pratiche di ispezione empirica e adattamento della mischia.
Ci sono due categorie di manufatti nel contesto della mischia: il Backlog tabelle e grafici che mostrano il lavoro che non hanno ancora fino alla fine (denominata BurndownCharts).
I ritardi sono tabelle: prodotto Backlog è costituito da un documento "dal vivo" sviluppato e mantenuto da ProductWoner che, per definizione, non è mai completo (dato che ci sono sempre miglioramenti da attuare in un prodotto fino a quando finalmente viene rimosso dalla circolazione). Contiene un elenco di tutte le modifiche che verranno apportate nel prodotto per le versioni future (caratteristiche, funzioni, tecnologie, adattamenti, miglioramenti, correzioni, ecc.). tali requisiti sono ordinati secondo priorità e dettagliati in termini di attributi di descrizione, complesse fattori/regolazioni e preventivi (di sforzo e termine) lungo gli sprint futuri.
Il Backlog Sprint: definisce le attività che il Team Scrum da eseguire per creare incrementi di prodotto (dal prodotto Backlog) durante l'esecuzione di uno Sprint. I tuoi dati dovrebbero essere sufficienti per poter essere accompagnati alle riunioni di Dario la mischia, nei compiti che durano tra quattro e 16 ore.
Ogni attività deve essere documentata, almeno in termini di vostra responsabile, lo stato (non iniziato, in progresso, completato) e la quantità di ore di lavoro rimanente ogni giorno dello Sprint.
Il BurndownCharts spettacolo, graficamente, la quantità di lavoro totale (altri sforzi) nel corso del tempo, riflettendo la correlazione con lo stato di avanzamento dei team del progetto nel ridurre il vostro lavoro. Può essere utilizzato nel contesto del prodotto Backlog (comprese tutte le volate) o all'interno di ciascuno degli sprint (Sprint Burndow).
Il mediano di mischia, come precedentemente accennato, è stato originariamente creato per l'utilizzo in progetti software in ambienti complessi, cioè dove i requisiti cambiano con una certa frequenza, che può avere l'ambito o il progetto WBS EAP o struttura di suddivisione del lavoro organizzato e strutturati in pacchetti di manufatti incrementale, coerenti e utilizzabili, per essere consegnato al cliente in periodi successivi di quindici ai trenta giorni ogni.
In un primo momento questo concetto è perfettamente applicabile a qualsiasi progetto o programma il cui obiettivo è lo sviluppo di prodotti o servizi di altra natura, o anche che comporta iniziative di miglioramento attraverso l'utilizzo di metodologie Lean, Six Sigma, ecc. In breve, la mischia è un approccio consigliato, che ha mostrato forte applicabilità, per progetti che richiedono la combinazione di competenze e conoscenze focalizzata ad una squadra e che coinvolgono gli sforzi collaborativi.
Secondo Pries & Quigley (2010) ci sono modi per adattare la mischia per applicazione in vari tipi di programmi e progetti complessi, come:
Combinazione con i metodi tradizionali di gestione del progetto: puoi collegare concetti e artefatti, come WBS (struttura di suddivisione del lavoro) e product Backlog, guadagnato analisi del valore, il BurndowsCharts e il piano di comunicazione, controllo delle riunioni Sprint (pianificazione, ogni giorno, recensione, retrospettive) ecc.
Gestione di programmi complessi: adozione di una mischia di Scrum, dove il Backlog di prodotto possa essere suddivisi in Sub-backlog, ciascuno consumato dai vostri rispettivi Team Scrum.
Competenze in aree funzionali che serve vari progetti (ad esempio, squadre di test o assicurazione qualità): nel prodotto Baclog, può venire in vari disegni e attività nel Backlog a un Spint, quelle attività che rientrano entro trenta giorni.
Combinato con la tecnologia sotto forma di "a cascata": si può dividere la pianificazione nel modello di durata fissa, per la sincronizzazione, ad esempio, una sequenza di Sprint con una pietra miliare (pietra miliare) prevista nel progetto, come pure avuto le attività di verifica e validazione del form evoluzione in ogni Sprint.
Combinando con l'approccio Six Sigma: si può avvolgere ciascuna delle fasi della metodologia DMAIC (Define, misura, analizza, migliora, controllo) in uno Sprint, in esecuzione uno dopo l'altro.
Schwaber (2004) menziona la possibilità di usando la mischia in un contesto di prezzo e contratto durata come preceduto. In questi casi, il Backlog di prodotto può essere utilizzato non solo per dimostrare al cliente che i requisiti sono stati capiti, ma anche la priorità di ogni generazione di valore è stata capita. I requisiti più rilevanti possono essere selezionati per il primo sprint e gli incrementi in funzionalità in modo affidabile ogni incontro di follow-up.
È importante sottolineare che l'adozione di Scrum per un'organizzazione dovrebbe essere fatto con cautela e che ci sono molte sfide da affrontare.
Facciamo collegare alcuni dei punti che, se non ben gestito, possono compromettere l'efficacia della metodologia Scrum:
È essenziale avere una squadra ben funziona gruppo, di lavoro, poiché il successo del lavoro dipende da uno sforzo intenso sulle competenze che ognuno ha come un differenziale;
È importante che ogni membro della mischia ha un forte senso di autogestione.
Garantire che i membri del team sono assegnati a un solo progetto.
È necessario verificare l'impegno di tutti i soggetti coinvolti (soprattutto da coloro che rappresentano il client).
È necessario assicurarsi che i ritardi sono ben documentati, così non ci siano equivoci tra coloro che sono coinvolti.
Ci possono essere alcune difficoltà per le attività da inserire in ogni riga di backlog, nonché di stabilire le dipendenze tra loro, che possono influenzare la pianificazione e i buoni progressi nell'attuazione degli sprint "atomizzare".
È necessario assicurarsi che tutte le riunioni (pianificazione, ogni giorno, recensione, retrospettiva) degli sprint sono trasportate fuori e che il fisso volte ricorrono in modo efficace, con il rischio di danneggiare il senso della disciplina, che è cruciale per il successo del metodo.
Conclusione
Prima le virgolette da vari autori, è noto per agilità e velocità che le metodologie agili, in particolare il mediano di mischia, scelto per illustrare l'altro in questo lavoro, dare alle imprese che assumono software factory.
Tra i vantaggi, possiamo evidenziare: la maggiore agilità nel controllo e nella gestione dello stato di avanzamento dei lavori, l'enfasi sul lavoro di squadra e concentrarsi su risultati rapidi, responsabilità condivisa con il gruppo causando un maggiore senso di impegno, consegne più rapide e efficienza, accorciare i commenti sottolineando comunicazione e maggiore soddisfazione del cliente di avere il tempo di consegna del software ridotto, senza perdere la qualità e aumentare il profitto dell'azienda.
Riferimenti
FERNANDES, A. A.; ABREU, V.F.: Distribuzione della governance, 4th ed., São Paulo, SP: Brasport libri ed editoria multimediale società Ltd., 2014.
PRESSMAN, approccio professionale di ingegneria del Software A 2011 r.. Traduzione Ariovaldo Griesi, Mario Moro Fecchio. 7 ° ed.-São Paulo, SP: MGH Editora Ltda, 2011.
PRIES, Kim H., QUIGLEI, Jon M. Scrum Project Management. CRC Press, 2010
SOMMERVILLE, i. ingegneria del Software. 8. Ed. São Paulo, Pearson Addison Wesley, 2007.
SCHWABER, Ken. Agile Project Mangement con Scrum. Microsoft Press, 2014.
Il manifesto agile. Disponibile a: <https: www.agilealliance.org/agile101/the-agile-manifesto/="">. Acceduto a sopra 21 ottobre 2016.</https:>
Manifesto per lo sviluppo Agile del Software. Disponibile a: <http: www.manifestoagil.com.br/="">.</http:> Acceduto a sopra 21 ottobre 2016.
Una panoramica della metodologia agile. Disponibile a: <http: www.devmedia.com.br/uma="" visao-geral-sobre-metodologia-agil/27944/="">.</http:> Acceduto a sopra 21 ottobre 2016.
[1] Laureato in informatica, si comporta come un server pubblico su SUFRAMA, come analista amministrativo-si.
[2] Laureato in informatica, si comporta come un server pubblico su SUFRAMA, come analista amministrativo-si.
[3] Laureato in informatica, si comporta come un server pubblico su SUFRAMA, come analista amministrativo-si.
[4] Laureato in economia aziendale, atti come dipendente pubblico il SUFRAMA, come amministratore.
[5] Laureato in informatica, si comporta come un server pubblico su SUFRAMA, come analista amministrativo-si.
[6] Laureato in informatica, si comporta come un server pubblico su SUFRAMA, come analista amministrativo-si.
[7] Laureato in informatica, atti come server SUFRAMA, come analista amministrativo-si.
[8] Si è laureato in economia e commercio, atti come dipendente pubblico il SUFRAMA, come economista.
[9] Laureato in informatica, si comporta come un server pubblico su SUFRAMA, come analista amministrativo-si.
