-
-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: aggiunta nuova pagina Metodologie di sviluppo #240
base: main
Are you sure you want to change the base?
Conversation
Ciao @JarvisScienz , grazie mille per il tuo contributo! Da quando ti abbiamo scritto ad ora sono passati parecchi mesi e nel frattempo un capitolo simile, anche se su temi in alcuni casi leggermente differenti, è già stato steso (https://il-libro-open-source.github.io/book/docs/it/ciclo-del-feedback/). Cosa ne pensi di contribuire alla modifica di quello, integrando e adattando quanto già presente, evitando quindi duplicazioni di contenuto? La PR puoi lasciarla tranquillamente aperta, semplicemente ti suggerisco di modificare l'altro contenuto piuttosto che crearne uno nuovo :) Mi piace molto lo stile di scrittura e non vedo l'ora di vederlo adattato a quanto già presente! |
Ciao @Cadienvan, si purtroppo è passato un po' di tempo, speravo di essere più celere nella stesura. Non appena sarò un po' più libero contribuirò a quel capito (e magari anche ad altri 😄 ) |
@JarvisScienz se poi hai bisogno non esitare a scrivermi, qui nei commenti o anche su LinkedIn, così possiamo discutere come proseguire questo capitolo oppure trovare spazio in altri per le contribuzioni 😄 |
@JarvisScienz Per il momento sposto in draft per evitare di perdere il bel contenuto scritto, ma evitando che qualche ambassador possa fare review su un contenuto comunque da rivedere! Non ti preoccupare per il tempo, l'importante è che tu sia d'accordo con il suggerimento! |
## Storie di Sviluppo: Viaggio tra le Metodologie del Software | ||
|
||
Nel mondo frenetico dello sviluppo software, dove codici prendono vita e idee si trasformano in realtà, le metodologie sono la bussola che guida il processo. Ogni metodologia ha la sua storia, il suo fascino e le sue battaglie, raccontandoci l'evoluzione del pensiero e l'ingegno di chi le ha create. | ||
La narrazione di una buona storia parte sempre dalle sue radici e quando si parla di metodologie di sviluppo e passato, non si può non citare il pilastro delle metodologie: Modello a cascata. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
La narrazione di una buona storia parte sempre dalle sue radici e quando si parla di metodologie di sviluppo e passato, non si può non citare il pilastro delle metodologie: Modello a cascata. | |
La narrazione di una buona storia parte sempre dalle sue radici e quando si parla di metodologie di sviluppo e passato, non si può non citare il pilastro delle metodologie: il Modello a cascata. |
Mi sembra più scorrevole
|
||
DeGrace non introdusse idee rivoluzionarie, ma cercò di dare un po' di flessibilità alla metodologia Waterfall. Nel modello di DeGrace, tutte le fasi di sviluppo del software vicine si sovrappongono tra loro. Ciò significa che, durante la fase di codifica vera e propria, sono stati eseguiti anche la progettazione dettagliata e i test. | ||
|
||
Quello che doveva essere il suo punto di forza alla fine si rivelò la sua debolezza. Se Waterfall era una metodologia troppo rigida, Sashimi era troppo traballante. Nessuno sapeva cosa stesse succedendo esattamente in un dato momento, la gestione del progetto divenne un disastro. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quello che doveva essere il suo punto di forza alla fine si rivelò la sua debolezza. Se Waterfall era una metodologia troppo rigida, Sashimi era troppo traballante. Nessuno sapeva cosa stesse succedendo esattamente in un dato momento, la gestione del progetto divenne un disastro. | |
Quello che doveva essere il suo punto di forza alla fine si rivelò la sua debolezza. Se Waterfall era una metodologia troppo rigida, Sashimi era troppo traballante. Nessuno sapeva cosa stesse succedendo esattamente in un dato momento, la gestione dei progetti finiva con il diventare un disastro. |
Ho la sensazione che con "la gestione del progetto" si faccia riferimento ad un preciso progetto. Che non c'è.
|
||
## Scrum: Rugby nello Sviluppo | ||
|
||
Il framework Scrum suddivide il tempo del ciclo di sviluppo in periodi di lavoro specifici chiamati sprint. Prima dello “sprint” vero e proprio, viene convocata una sessione di pianificazione in cui vengono assegnati i compiti e fissati gli obiettivi. Il product Owner delineerà un product backlog con priorità e discuterà con i team come completare ciascun elemento in backlog. Il gruppo stima collettivamente lo sforzo richiesto, il che porta a una previsione dello sprint che elenca la quantità di lavoro che può essere completata dal backlog. Scrum fornisce la struttura per aiutare i team a lavorare insieme. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Il framework Scrum suddivide il tempo del ciclo di sviluppo in periodi di lavoro specifici chiamati sprint. Prima dello “sprint” vero e proprio, viene convocata una sessione di pianificazione in cui vengono assegnati i compiti e fissati gli obiettivi. Il product Owner delineerà un product backlog con priorità e discuterà con i team come completare ciascun elemento in backlog. Il gruppo stima collettivamente lo sforzo richiesto, il che porta a una previsione dello sprint che elenca la quantità di lavoro che può essere completata dal backlog. Scrum fornisce la struttura per aiutare i team a lavorare insieme. | |
Il framework Scrum suddivide il tempo del ciclo di sviluppo in periodi di lavoro specifici chiamati sprint. Prima dello “sprint” vero e proprio, viene convocata una sessione di pianificazione in cui vengono assegnati i compiti e fissati gli obiettivi. Il product Owner delineerà un product backlog con priorità e discuterà con i team come completare ciascun elemento in backlog. Il gruppo stima collettivamente lo sforzo richiesto, il che porta a una previsione dello sprint. Questa, elenca la quantità di lavoro che può essere completata dal backlog. Scrum fornisce la struttura per aiutare i team a lavorare insieme. |
|
||
I tre ruoli cardine della metodologia sono: | ||
|
||
**Proprietario del prodotto**, questa persona è responsabile della pianificazione iniziale, dell'assegnazione delle attività, della definizione delle priorità e del mantenimento della comunicazione durante tutto il progetto. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per quanto sia bello usare l'italiano, davvero, ci ho messo un po' a capire che cosa fosse il proprietario del prodotto. Quantomeno metterei anche la versione italiana, ma quella inglese è di uso comune.
Vedi #222