Mob programming

[Theodor Augustin Dumitrescu]

Ciao ragazzi, spero che vada tutto bene.

Vi segnalo questo meetup. Avete mai sperimentato il mob programming? Io dovrei iniziare a marzo con un gruppo di 5 sviluppatori. 

https://www.meetup.com/bucharest-software-craftsmanship-community/events/283093142/

[Mario Alexandro Santini]

On 1/20/22 4:08 PM, Theodor Augustin Dumitrescu wrote:
> Ciao ragazzi, spero che vada tutto bene.
>

Ciao Theodor,

> Vi segnalo questo meetup. Avete mai sperimentato il mob programming?
> Io dovrei iniziare a marzo con un gruppo di 5 sviluppatori.
>
> https://www.meetup.com/bucharest-software-craftsmanship-community/events/283093142/

> <https://www.meetup.com/bucharest-software-craftsmanship-community/events/283093142/>
>
Ne avevo già sentito parlare, ma mai approfondito.

Posso chiederti da cosa nasce questa scelta?


Mario

[Theodor Augustin Dumitrescu]

Ciao Mario,

>  Posso chiederti da cosa nasce questa scelta?

Noi siamo ancora in una fase sperimentale quindi per ora non posso fare un discorso sui vantaggi/svantaggi. 

Per avere un po’ di contesto, il mio team è all’interno di un team più grande, e questo ci permette di essere molto protetti dalle distrazione esterne durante i sprint. Detto ciò, noi stiamo studiando la riscrittura di tutti i software attualmente in utilizzo in completa libertà su carta bianca.

 

Il mob torna utilissimo perché nel nostro piccolo gruppo un paio di persone sono esperte del vecchio dominio e quello aziendale, un’altra è esperta delle tecnologie che intendiamo utilizzare, un’altra delle architetture esterne con cui il vecchio dominio si integra, etc. Pertanto col mob dovendo affrontare tutte le tematiche insieme permette di passare queste conoscenze dal singolo al resto del gruppo. Inoltre, una volta omogeneizzata la conoscenza, non ci saranno problemi nei momenti in cui avviene una rotazione dei membri del team.

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Socraten" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a socraten+u...@googlegroups.com.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/socraten/45647927-0c57-384c-d502-9b3e7ea96bdf%40gmail.com.

[Simone Bordet]

Ciao,

On Fri, Jan 21, 2022 at 8:09 AM Theodor Augustin Dumitrescu
<th.the...@gmail.com> wrote:
> Per avere un po’ di contesto, il mio team è all’interno di un team più grande, e questo ci permette di essere molto protetti dalle distrazione esterne durante i sprint. Detto ciò, noi stiamo studiando la riscrittura di tutti i software attualmente in utilizzo in completa libertà su carta bianca.

Wow! Posso chiedere come mai?
Che tecnologie userete?

--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

[Mario Alexandro Santini]

Ciao,

On 1/21/22 10:10 AM, Simone Bordet wrote:
> Wow! Posso chiedere come mai?
> Che tecnologie userete?
>

Anche io sono curioso. :)

Ma nel frattempo i sistemi continuano ad essere aggiornati con nuove
funzionalità o si parla di software consolidati e stabili, salvo qualche
bug che emerge?


Mario

[Theodor Augustin Dumitrescu]

Un po’ di delay, scusate. 

> Wow! Posso chiedere come mai?

Principalmente perché tante parti del vecchio software sono frutto di fornitori esterni e nel tempo ne hanno risentito molto. 

 > Che tecnologie userete?

L’idea sarebbe di arrivare su Java17 con webflux di spring 6 ed adottare graalvm appena spring porta il suo plugin al di fuori dalla beta. 

Al momento il passaggio a 17 è rallentato dal fatto che tanti strumenti interni (librerie, tools, etc) usano cose che nel tempo sono state deprecate/rimosse, lato jdk ma anche in spring.

Buona domenica,

Theodor

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Socraten" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a socraten+u...@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/socraten/240624ec-6e31-2407-f52b-c3ba02ab96d7%40gmail.com.

[Andrea Selva]

Ciao, 

On Sun, Jan 23, 2022 at 5:18 AM Theodor Augustin Dumitrescu <th.the...@gmail.com> wrote:

Un po’ di delay, scusate. 

> Wow! Posso chiedere come mai?

Principalmente perché tante parti del vecchio software sono frutto di fornitori esterni e nel tempo ne hanno risentito molto. 

Come fate a garantire di catturare tutto il contesto che nel tempo è stato sedimentato nei vecchi sistemi?
Anche se avete nel team gente che c'ha lavorato è difficile, ci si dimentica facilmente il motivo per cui si sono fatte certe cose in un modo piuttosto che un'altro. 

 

 > Che tecnologie userete?

L’idea sarebbe di arrivare su Java17 con webflux di spring 6 ed adottare graalvm appena spring porta il suo plugin al di fuori dalla beta. 

Al momento il passaggio a 17 è rallentato dal fatto che tanti strumenti interni (librerie, tools, etc) usano cose che nel tempo sono state deprecate/rimosse, lato jdk ma anche in spring.

A prendere un tool alla 1.0.0, anche se stiamo parlando di Spring, vi prendete un rischio, soprattutto se il sistema/i che andrete a sostituire è core per il business.

Il fallimento del progetto è un output accettabile per il committente?

Curiosità personale, avete valutato la strada del refactoring?

 

Buona domenica,

Theodor

 

Ciao

 Andrea

 

On Fri, 21 Jan 2022 at 11:13, Mario Alexandro Santini <alexm...@gmail.com> wrote:

Ciao,


On 1/21/22 10:10 AM, Simone Bordet wrote:
> Wow! Posso chiedere come mai?
> Che tecnologie userete?
>
Anche io sono curioso. :)

Ma nel frattempo i sistemi continuano ad essere aggiornati con nuove
funzionalità o si parla di software consolidati e stabili, salvo qualche
bug che emerge?


Mario

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Socraten" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a socraten+u...@googlegroups.com.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/socraten/240624ec-6e31-2407-f52b-c3ba02ab96d7%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jugtaa/CAO4RVpkLVqyQynLwBUkrXu80pCBNtD2r38bcbmiRcAkyMwgrMA%40mail.gmail.com.

[Nicola Pedot]

Grazie della condivisione link Theodor.

Mai sperimentato il mob, pare un'ottima tecnica per scenari come il tuo.

Al solito temo possa scontare problematiche di tecniche simili in agile e  trovare qualche freno in persone rispettabilmente introverse, se invece nel team ci sono le persone che "stanno al gioco" è un formidabile acceleratore.

NiPe

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Socraten" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a socraten+u...@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/socraten/CAO4RVpk8NsbHR1_H6qB2jxoq6aP5ZgfOYEN_xOuDmZwd-4KnpQ%40mail.gmail.com.

[Mario Alexandro Santini]

Ciao,

On Thu, Jan 27, 2022 at 8:35 AM Nicola Pedot <nicola...@gmail.com> wrote:

Al solito temo possa scontare problematiche di tecniche simili in agile e  trovare qualche freno in persone rispettabilmente introverse, se invece nel team ci sono le persone che "stanno al gioco" è un formidabile acceleratore.

Bravo Nicola, hai sollevato un punto importante, di cui non si parla abbastanza, ovvero come coinvolgere le persone in un lavoro di team?

Può sembrare una domanda scontata, perché lavorare in team, per gli informatici oggi è ritenuta una cosa normale.

Tuttavia le dinamiche che si generano fra le persone sono complicate, anche in un gruppo di persone che lavorano ad un progetto e che dovrebbero avere uno scopo comune.

Diventa importante imporre una struttura, un percorso e cercare di frenare l'improvvisazione.

Almeno, questo è quello che posso dire dalla mia esperienza nelle riunioni e discussioni tecniche. Si rischia di deragliare dall'argomento principale, di perdere il focus.

Inoltre, c'è anche la possibilità che si creino delle fazioni, perché le persone si affezionano a tool, librerie, soluzioni diverse per diversi motivi e poi difendono a spada tratta la propria posizione.

Situazione da evitare.

 

NiPe

[Theodor Augustin Dumitrescu]

Ciao,

>  Come fate a garantire di catturare tutto il contesto che nel tempo è stato sedimentato nei vecchi sistemi?

Non ci serve. L'idea è proprio quella di ideare tutto da zero. Sarà un problema di coloro che utilizzano le nostre API adattarsi. Se dovessi ragionare sulle cose che si sono fatte in passato, finirei nei stessi errori. 

> Curiosità personale, avete valutato la strada del refactoring?

Personalmente trovo il refactoring una cosa davvero inutile quando si raggiunge un certo livello di legacy, o nel caso in cui si stia parlando di servizi modificati continuamente a causa di decisioni di business. Vogliamo una strada nella quale siamo noi dev ad avere il potere sopra le modifiche e respingere eventuali richieste non congrue con l'architettura: "vuoi una API che ti dica quante mele hai nel frigo? noi non te la facciamo perché non ci interessano né le mele né il tuo frigo".

> A prendere un tool alla 1.0.0, anche se stiamo parlando di Spring, vi prendete un rischio, soprattutto se il sistema/i che andrete a sostituire è core per il business.

In realtà vogliamo  stare al passo  - ed io in particolare sto insistendo tanto -  col ciclo di vita delle release di Spring, che coincide ben o male con i rilasci delle JVM. 

> Al solito temo possa scontare problematiche di tecniche simili in agile e  trovare qualche freno in persone rispettabilmente introverse, se invece nel team ci sono le persone che "stanno al gioco" è un formidabile acceleratore.

Noi abbiamo deciso di ignorare il più possibile i tempi che ha in mente business. Da una settimana facciamo mob programming senza scrivere in realtà scritto nemmeno una riga di codice perchè stiamo tutto il tempo a discutere decisioni tecniche ed architetturali, e che strumenti/librerie dovremmo creare per aiutarci nei sviluppi futuri. Magari per il business sembra una perdita di tempo ma in realtà predere un mese (o  più) a fare il primo pezzo del puzzle, ti permette poi di realizzare tutti gli altri pezzi a velocità sempre più alta.

Per esempio oggi una persona del mob ha detto "ma stiamo dando per scontato il REST?" ed abbiamo intrapreso una discussione che probabilmente durerà anche la settimana prossima per capire se potrebbe aver senso integrare il nostro standard OpenAPI con qualcosa come RPC, Protobuf, Apache Avro, etc..

> Diventa importante imporre una struttura, un percorso e cercare di frenare l'improvvisazione.

Nei giorni scorsi, proprio in vista di  nuove persone nel futuro, abbiamo deciso di scrivere plugins gradle per ogni standard che decidiamo. Per esempio, se decidessimo che nel codice non devi usare autowired sui attributes ma gestire la CDI solo tramite constructor, allora ci sarà un plugin di gradle che andarà a controllare che tu non abbiamo utilizza Autowired a caso nel codice, e, nel caso ci fossero, ti impedirà di buildare il progetto. 

> Inoltre, c'è anche la possibilità che si creino delle fazioni, perché le persone si affezionano a tool, librerie, soluzioni diverse per diversi motivi e poi difendono a spada tratta la propria posizione.

In passato ho notato spesso in progetti che magari già usavano Vavr per i Try, Option, etc, utilizzava comunque apache-common per i Pair al post di utilizzare qualcosa come Tuple2 di Vavr. Questo tipo di cose vorrei cercare di evitarle creando dei momenti in cui proporre che librerie si utilizzano o meno. 
Considerando quello che è successo con log4j, a maggior ragione. Se ogni persona decidesse di utilizzare a piacere log4j, o qualche alternativa, come faresti dopo a capire velocemente in produzione quali servizi sono vulnerabili ai zero days?  

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "Socraten" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a socraten+u...@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/socraten/CAMUoZeekxJ9cr%3DX8%3DwcumYMUDa4dQxu1TxZ-ECB9XzjF3jE3GQ%40mail.gmail.com.