Skip to content
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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

JarvisScienz
Copy link

Vedi #222

@Cadienvan
Copy link
Member

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!

@JarvisScienz
Copy link
Author

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 😄 )

@BrianAtzori
Copy link
Member

@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 😄

@Cadienvan
Copy link
Member

@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!

@Cadienvan Cadienvan marked this pull request as draft July 27, 2024 13:28
@Cadienvan Cadienvan linked an issue Sep 7, 2024 that may be closed by this pull request
## 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[🆕]: Metodologie di sviluppo
4 participants