- Dimensioni del progetto.
E 'facile da applicare agile in un nuovo progetto, relativamente piccola (decine $ K), con la tradizionale architettura client-server e gli utenti ben definiti / clienti, ma ..
che dire di un ri-scrittura di un progetto esistente grande (centinaia o milioni di $) con il software distribuito e molteplici stakeholders? È difficile da affrontare che in metodologie agili ... controllare questo articolo per ulteriori informazioni. - Proprietario del cliente o di un prodotto deve essere agile
Se tutti i vostri cliente vuole in realtà è un prodotto con un numero fisso di caratteristiche in un arco di tempo fisso, allora siete probabilmente a fallire. Si sono comunque anche se non si utilizza agile. Ma credo che il punto è agile non servirà a nulla.
In agile bisogna ridefinire continuamente i requisiti, rielaborare, li ri-priorità. Il tuo cliente deve sapere e accettare che. - L'organizzazione deve essere agile
Nessun punto di andare per un modello di iterazione base se la vostra azienda richiede ancora tutto il lavoro da firmare-off in una specifica anticipo. Per ottenere il valore corretto è necessario essere in grado di adattarsi lavori in corso durante l'avanzamento. - La tua squadra non potrebbe essere pronto
Sì, è vero la squadra non potrebbe essere abbastanza maturo per essere auto-gestione, ed è uno dei punti del manifesto agile. È necessario rendersi conto se avete intenzione di avviare agili e portare di conseguenza. (Ottimo articolo qui )
, potrebbe essere necessario resistere e treno / guida la tua squadra (e se stessi) per un tempo un po '.
approcci agili richiedono un cambiamento di mentalità. Cose semplici come dire che qualcosa è "DONE" il mezzo è pronto produzione. Ciò non significa che il codice è fatto e ora qualcuno dovrà assicurarsi che funzioni. La tua squadra ha bisogno di essere abbastanza maturo per propria e capire ciò che stanno per commettere. - Agile non significa che si sta per sviluppare un software più veloce.
Questo deve essere chiaro a tutti i project manager.
Aumenta il valore di business e ROI perché l'utilizzo agile il focus squadra sulle caratteristiche che sono una priorità per il valore di business e fornire in modo incrementale di lavoro del software a intervalli regolari .
Meno caratteristiche => più veloce
Se si considera solo il tempo totale, agile sta andando a richiedere più tempo a causa di continue code refactoring - Non farlo solo per il gusto di farlo
Embrace agile solo se si crede in esso. Non perché la gente dice che funziona.
O peggio ancora solo per dire ai vostri clienti vi sono una società 'agile'.
Ci sono molte società di successo che non ha mai usato.
Se si sta già utilizzando agili poi
- Assicurarsi di avere una definizione chiara e comunemente accettata di FATTO.
L'intero team ha bisogno di capire il processo. Assicurarsi che siano consapevoli, capire e accettare che. Gli artefatti sprint di produzione deve essere pronto.
Ricordate anche che se il risultato sprint non è effettivamente dispiegati alla produzione (per qualsiasi motivo) si sta piegando contratto. Basta tenere conto che la "produzione" bug potrebbe essere in agguato nel codice. - Guarda il debito tecnico
Molto spesso il debito tecnico tende ad accumularsi negli sprint a causa di. È necessario monitorare da vicino si e assegnati durante il vostro sprint per scremare fuori. - Non lasciate che i membri del team agire come proprietario del prodotto
Il proprietario del prodotto è il giocatore più importante. È quello che ti dice voglio fare ma soprattutto cosa fare prima.La corretta prioritizzazione del user story determinerà il successo o il fallimento del progetto e solo il proprietario dovrebbe farlo.
volte se si dispone di una grande squadra, si potrebbe essere tentati di avere qualcuno in squadra (molto probabilmente l'BA) indossare il prodotto proprietario cappello.
Questo può portare ad un sacco di problemi e incomprensioni. Uno dei punti chiave del manifesto agile è "la collaborazione del cliente sulla negoziazione del contratto". - La tua squadra è probabile che sia diverseNot ogni membro del team può prendere ogni storia. Qualcuno dice che non è agile sviluppatore Junior amichevole. Bene la sua un po 'di più. Si potrebbe avere diverse persone specializzate in diverse discipline e che creerà un sacco di contesa / dipendenze che devi affrontare.
- Trascorrere del tempo appropriata sul vostro automazione e integrazione continua
Parte del processo agile è quello di costruire continuamente e integrare il software. Gli sviluppatori hanno lo scopo di eseguire i test per tutto il giorno.
Se il vostro costruire impiega 30 minuti, il server applicazioni bisogno di un altro 5 e così via poi la produttività è davvero a soffrire. Passa un po 'di tempo per interrompere l'applicazione in piccoli pezzi più mantenibile.
Non trascinare causa insieme con la produttività del team sta per imbattersi in la cattiva abitudine di non correre o saltare la procedura. - Vada per il "semplice possibile", ma non dimenticare i principi di progettazione
L'idea è quella di ottenere un feedback il più presto possibile. Quindi, se l'applicazione sta per andare a generare grafici, non c'è niente di male ad avere una base di Excel prima versione per essere sicuri di capire che cosa vuole il cliente.
Quello che dovete fare attenzione è che l'architettura software e principi di progettazione non sono lasciati ! - Non dimenticare i requisiti non funzionali
utente storie solo parlare di funzione desiderata. La critica "quanto bene" attributi sono totalmente assenti. Gli stakeholder li aspetta e che comunque è quando si sta per finire nei guai.
Tutte le cose come le prestazioni, la scalabilità sono veramente facendo la differenza in questi giorni. Controlloperché cromo sta diventando sempre più popolare.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.