is it worth to dive into Agile world?

Sì.

Isn't agile more useful when you don't have all the requirement upfront and you get your requirement in phases??

False.

Quando non hai tutti i requisiti, è il modo solo per fare progressi. Qualsiasi altra cosa richiede supposizioni fantasiose che alla fine saranno dimostrate false. Agile fa semplicemente meno ipotesi fantasiose.

Quando hai tutti i requisiti, devi ancora seguire tutti i principi di Agile.

Leggi questo prima di procedere oltre: link

Tutti di questi punti sono veri indipendentemente da quanto tu sappia dei requisiti.

Trovi ancora benefici dall'uso di un metodo Agile come Scrum, perché avrai aspettative più realistiche.

whats the best practice to design database? Let's say in our first iteration we just create a login system (user can login, logout etc).

Che terribile prima iterazione.

Do we just need to create Users table without worrying about other tables? And other tables would be evolved as our product would progress?

Sì. Si crea il database in modo incrementale.

Fai tutto in modo incrementale.

Hai la priorità in base a ciò che crea il maggior valore per gli utenti . Considerazioni tecniche non fantasiose (e sciocche).

Now my question is as we have all the requirements even before start of project (as we are re-writing the existing product), is it worth to dive into Agile world?

Sì, anche se immagino ci siano probabilmente più di alcune possibili modifiche al modo in cui l'applicazione è attualmente progettata in quanto sarebbe il momento di ripulire i vari debiti tecnici per avere un design più pulito, date le informazioni conosciute ora.

Isn't agile more useful when you don't have all the requirement upfront and you get your requirement in phases??

Quanto sei sicuro che quei requisiti non cambieranno mentre crei di nuovo l'applicazione? Sei sicuro che il disegno che stai prendendo non verrà mai refactored?

Secondly, let's say if we jump into Agile, whats the best practice to design database? Let's say in our first iteration we just create a login system (user can login, logout etc). Do we just need to create Users table without worrying about other tables? And other tables would be evolved as our product would progress?

Ci sono molte opzioni diverse qui. Fallo quanto basta per farlo funzionare. Se la tabella Utenti è tutto ciò che è necessario, ottimo. Se ci sono alcune altre tabelle che qualcuno vuole avere quindi il DB è in una forma più normalizzata, allora questo potrebbe renderlo migliore. Non sarai perfetto la prima volta e Agile è tutto un tentativo e fissa un tipo di metodologia come una volta che mostri ciò che hai l'utente avrà spesso feedback che è ciò che fa andare avanti e indietro Agile ... (Anche dove il nuovo i requisiti arriveranno perché le persone potrebbero iniziare a chiedere anche cose)

I work for a small product based company. We are about to re-write our existing product from scratch. We are planing to adopt Agile methodology for our development. Now my question is as we have all the requirements even before start of project (as we are re-writing the existing product), is it worth to dive into Agile world?

Una piccola azienda (gestione) che sta pianificando di utilizzare pratiche agili è in un'ottima posizione di partenza poiché i suoi tipici sviluppatori che guidano l'adozione. Ti consiglierei di identificare i leader disposti a continuare a guidare l'adozione a livello di squadra (formazione, istituzionalizzazione, ecc.)

Con i requisiti in mano, chiedi ai tuoi utenti cosa vorrebbero vedere in un'unica iterazione. Quindi, consegnalo. Ripeti l'iterazione successiva e di nuovo. Gli utenti che sono in grado di toccare presto il tuo lavoro contribuiranno a perfezionare i requisiti man mano che vai. Se non si dispone di processi automatizzati o se il team non comprende lo sviluppo continuo, pianificare il tempo per assicurarsi che lo faccia.

Agile è applicabile a qualsiasi progetto di sviluppo e non specificamente per progetti greenfield completi che non hanno ancora requisiti specifici. La gestione del progetto agile rende il tuo auto-apprendimento del tuo progetto e auto-miglioramento adottando piccoli passaggi, rivedendo spesso i passaggi e migliorando i passaggi successivi. Ci sono molti blog su Agile in giro. Google è tuo amico ...

Per quanto riguarda la tua domanda specifica sullo sviluppo del database Agile, sei sulla strada giusta. Puoi sviluppare la gestione degli utenti senza preoccuparti del resto all'inizio. Questo probabilmente finirà in qualche rielaborazione quando andrete oltre nel progetto, ma questo può essere considerato un costo di una piccola iterazione focalizzata. Un approccio di medio raggio dovrebbe indagare un po 'più in anticipo il modello del tuo database e creare qualche progetto che possa far avanzare alcuni sprint. In questo modo, avrai meno rilavorazioni.

Secondly, let's say if we jump into Agile, whats the best practice to design database? Let's say in our first iteration we just create a login system (user can login, logout etc). Do we just need to create Users table without worrying about other tables? And other tables would be evolved as our product would progress?

Stai attento a esagerare con questo approccio. Può essere come costruire una casa e provare a finire un bagno completamente mentre le fondamenta stanno ancora tramontando. Le probabilità sono che dovrai completamente rifare parti significative del tuo lavoro se il fondamento dell'applicazione, il database e il modello degli oggetti sottostanti, non sono maturi o abbastanza stabili da supportare la struttura.

Inoltre, ricorda che dire che stai usando Agile / Scrum non ti esime dall'usare buone pratiche di ingegneria del software come il corretto test delle unità e il solido design di database e oggetti. Quando Agile viene applicato erroneamente, può facilmente cadere in un codice e fissare un progetto a spirale di morte che può essere molto doloroso o addirittura impossibile da recuperare.

Agile significa più produttività e flessibilità . Perché stai riscrivendo le tue applicazioni? I motivi potrebbero essere:

1. Modifica della piattaforma (da Windows a Linux, ad esempio)
2. Modifica della lingua (ad esempio da ASP.NET a PHP)
3. La quantità di refactoring è così alta che rende la riscrittura un'opzione di riduzione dei costi
4. Gli affari sono cambiati molto, quindi stai effettivamente creando una nuova applicazione (un nuovo brano, basato sullo stesso tema, se lo desideri)

In nessuno di questi motivi, non consegnerai il tuo prodotto durante la notte e, naturalmente, ci vorrà del tempo.

Avere un product backlog è solo uno degli elementi consigliati da Agile. Quello che dici di conoscere l'intera azienda significa che hai già molti IPB nel tuo backlog di prodotto.

Ma non è meglio consegnare parti del tuo nuovo prodotto alla fine di ogni sprint? Non ti renderà più agile e reattivo ai cambiamenti. Ad esempio, immagina di provare a rendere bella la nuova applicazione. Non è forse male sapere dopo 10 mesi che il tuo nuovo design non è accettabile? Non sarà una buona pratica se ti viene detto dopo 2-3 settimane a riguardo?

La mia risposta alla tua domanda è:

Lo sviluppo agile ha sicuramente molte cose da offrire, anche per le applicazioni riscritte.

is it worth to dive into Agile world?

Forse. Provare qualcosa di nuovo può essere rischioso, specialmente se è nuovo per tutti. Personalmente trovo che Agile sia utile quando fatto bene .

Isn't agile more useful when you don't have all the requirement upfront and you get your requirement in phases??

Può essere utile aiutare a guidare i requisiti se non li hai ancora. Tuttavia, ciò non significa che l'utilità sia limitata ai soli requisiti di guida.

whats the best practice to design database?

iterativamente. Utilizza le migrazioni del database.

Suggerimenti

• Se vuoi fare Agile è grandioso. Vorrei provare a chiedere a qualcuno che lo ha già fatto di aiutarti per il processo.

• Spesso le persone ignorano la fase di refactoring quando provano per la prima volta Agile. Non. Ucciderà il progetto.

• Pensa in sezioni verticali (funzionalità) anziché in livelli. Implementa sezioni verticali in modo da avere un sistema funzionante dopo aver completato la prima scheda funzione. Una volta funzionante, mantienilo funzionante e aggiungi semplicemente ogni scheda funzione.

Abbiamo utilizzato Agile in un progetto che comporta lo spostamento da una vecchia applicazione a una nuova serie di applicazioni e una nuova architettura. La nostra situazione è leggermente diversa in quanto stiamo provando non solo a rifare l'applicazione esistente (utilizzata internamente dai nostri reparti vendite, finanza, approvvigionamento e magazzino), ma stiamo cercando di migliorare l'esperienza di ogni reparto lungo la strada. Una sfida che abbiamo visto usando l'agile è che il valore aziendale per lo spostamento di parti della funzionalità per una determinata unità di business è elevato, ma le altre parti sono basse. Ci troviamo quindi a creare nuove applicazioni e mantenere attiva la vecchia applicazione durante la transizione. Stiamo avendo problemi a convincere il business a vedere il valore nel concentrare il passaggio di un "cliente" in un'applicazione completamente nuova. Stiamo comunque ottenendo molte storie di alto valore nei nostri sprint. Penso che presto arriveremo a una pinta, quando dovremo convincere il business che dobbiamo concentrarci su una unità alla volta.

Quindi, per rispondere alla domanda originale, sì agile è un buon modo per andare. Preparati a fare affidamento su alcune dipendenze e guida alcune decisioni dei team lungo il percorso.

La cosa più importante è che il processo di mischia ti sarà utile. Voglio dire se il tuo lavoro sarà migliore, prendilo. Ma non lo saprai mai a meno che non lo provi.

Un altro punto è che non c'è bisogno di prendere il processo di scrum dal libro. Prendi le cose che funzioneranno per te. Ad esempio, il nostro team non ha una mischia. Perché non ne abbiamo bisogno.

Per quanto riguarda la progettazione, dovresti provare a progettare in modo tale che le modifiche future non richiederanno molto tempo. Il tuo sistema deve essere robusto.