Aanpak Java Applicatie bouwen met clubje mensen

[Furion2000]

Goedemiddag,

Met de clubje ontwikkelaars (ervaren en onervaren) die binnen een monoliet werken van 18 jaar (incl een eigen UI java webframework), word er normaal gesproken 1x in de 2 maanden een pizza sessie gehouden om de twee weken een hoofdstuk(ken) uit een boek gelezen.

Nu is het volgende idee op tafel gekomen;
Een nieuwe simpele applicatie bouwen met Spring, UI framework (e.g. Angular, React), REST en NoSQL database, gewoon een volledige stack waarbij niemand echt ervaring in heeft of thuis in is. Idee was een soort sport poule spel waarbij je op teams kunt gokken etc. Gewoon puur om kennis te maken met nieuwe frameworks.

Welke tijd krijgen we momenteel van het bedrijf:
30 min bespreking om de week
1x in de 2 maanden pizza sessie van 15:00 tot 21:00

Hoe gieten wij dit in een vat? was de vraag die wij ons nu afvroegen.

Vragen voor jullie dus:
- Hebben jullie ervaring hiermee en hoe kunnen we dit aanpakken?
- Google als leidraad gebruiken of zijn hier boeken/cursussen (udemy) voor aan te raden?
- Hoe management enthousiast krijgen mocht er tijd extra nodig zijn?

[Mint]

Hebben de ervaren personen in je groep geen idee over hoe dit aan te pakken? Het lijkt me dat je eerst begint met wat je wilt bereiken en dat in hapklare brokken opsplitst zodat iedereen een brok kan oppakken.

Qua frameworks die je wilt gaan gebruiken is het een kwestie van rondzoeken, er zijn vast voldoende tutorials te vinden.

Hoe management enthousiast krijgen? Uitleggen wat je van plan bent, aangeven welk probleem je oplost of welk een proces je op welke manier verbetert en het allerbelangrijkste: maak een kosten/baten analyse. Management is doorgaans geïnteresseerd in wat het nu kost of hoe groot het huidige probleem is, hoe groot de investering is, hoeveel het na de verandering gaat besparen en daarmee wat de ROI (Return On Investment) is.
Ik weet niet wat je van plan bent om te bouwen, maar kijk ook naar de toekomst. Misschien dat je oplossing op de korte termijn niet veel oplevert maar dat op de lange termijn bepaalde werkzaamheden sneller/makkelijker worden?

Edit: zo te zien is de startpost bijgewerkt. Het idee is dus om met nieuwe frameworks aan de slag te gaan. Je kunt dit bij management aankaarten als het verbreden van de kennis van developers. Wellicht dat het nieuwe implementatiemogelijkheden of -inzichten biedt die je toe kunt passen in jullie huidige codebase? Als je straks meer tijd/resources wilt hebben, heb je ook vast een beter idee van hoe je werkgever ermee gebaat is of kan zijn.

[ Voor 18% gewijzigd door Mint op 16-10-2019 16:17 ]

[Furion2000]

Het is meer het idee dat we hands on ervaring krijgen van begin tot eind. Een groep van zo'n 9 die allemaal leert van hetgeen wat we gaan doen. Dus niet de een UI en de ander REST, allemaal hands on ervaring met hetzelfde.

Dus eerder groepjes van 3 en dan allemaal dezelfde 'brok' gaan maken.

Het is niet dat de ervaren mensen dit niet weten, ze hebben dit zelfs al eerder gedaan, maar ik wil wel eens weten of anderen hier ervaring mee hebben en dat als positief ervaren hebben. Ik denk dat er genoeg bedrijven zijn die dit soort dingen ondernemen toch?

Voor het management is deze tijd voor 'vrije zelf ontwikkeling' en is de enige baat, de werknemer ruimte geven voor zelfontwikkeling. Mocht er iets uitkomen is mooi meegenomen, maar meer niet.

[ Voor 5% gewijzigd door Furion2000 op 16-10-2019 16:27 ]

[Nick_S]

1 .Begin op https://start.spring.io/ en zet daar een applicatie in elkaar
2. Pak dit uit en stop het in een git repository die je met elkaar deelt
3. Begin met mob programming en laat de driver en navigator elke 10 minuten door draaien.
4. Begin met een makkelijk JUnit 5 test.

Laat verder iedereen een onderwerp oppakken en daar de week later een kennissessie over geven van een half uur. Vaak biedt het kijken van een goede conferentie talk via Youtube voldoende diepte om daarna het in een half uur na te vertellen met wat voorbeelden.

[edit] En management enthousiast krijgen? Volgens mij is het de taak van elke developer om z'n eigen kennis van ontwikkelen en frameworks op orde te houden, daar heb je geen management voor nodig.

[ Voor 18% gewijzigd door Nick_S op 16-10-2019 16:40 ]

[Mercatres]

Ik ben onlangs (nuja, een half jaar geleden) met iets vergelijkbaars begonnen. Weliswaar niet in context van een bedrijf, maar vanuit de lokale hackerspace.
Het idee speelde al langer om een reeks workshops rond nieuwe (web)tech te doen, en toen er plots een externe partij vroeg of we hun excel management systeem om wilden bouwen naar iets nieuws, leek dat een heel mooie combinatie.
Wij zijn dan in samenspraak met de klant (de externe partij), rond te tafel gaan zitten om te kijken wat ze exact wilden. Toen dat min of meer duidelijk was hebben we onze kant van 't verhaal eens duidelijk gemaakt:
- Moderne webtech stack (in professionele context, dus niets te exotisch): .NET Core 2.x en Angular2+
- Project opvolging in Agile/Scrum
- Het volledige plaatje (dus van conceptie tot oplevering)
- Alles open source

De klant was hier mee akkoord, en een paar weken later konden we aan de slag met een teampje van 4 man. Eénjte daarvan is puur frontend, een andere doet pure backend en dan nog twee full stack met DevOps erbij. Ik nam hierbij ook nog de rol als Scrum Master (en een beetje PO) op, en hield me vooral in het begin bezig met de initiele opzet. Ik werk professioneel met eerdergenomende stack, dus kon men bij mij ter rade komen met vragen.
Inmiddels naderen we het einde van eerste release, en zijn er toch al enkele punten die ik je kan meegeven:
- Zorg dat het leuk blijft.
- Zorg voor een goede rolverdeling (Inclusief project mgmt, process opvolging, ...)
- Maak in het begin weloverwogen keuzes rond de te gebruiken stack (die heb je in dit geval al gemaakt, denk ik)
- Bij ons blijft het idee: iedereen werkt er vrijwillig aan mee, maar we verwachten wel dat je je blijft inzetten per sprint. We komen 1x per week 's avonds samen (ook met pizza ) en meestal is iedereen er wel. Als het een keer niet lukt voor iemand, is dat ook niet erg. Daarin helpt natuurlijk ook dat we onze sprint planning ook braafjes doen aan 't begin van elke sprint en nemen we de resourceplanning daarin mee.
- Zorg voor regelmatige demo's die gerespecteerd worden. Wij doen sprints van een maand, en aan het einde van elke maand komt de klant langs om te kijken naar onze vooruitgang. Het fijne is dat de klant (die totaal geen ervaring heeft met software) hier wel goed in mee doet.

Ik zeg niet dat Agile/Scrum de way to go is voor elk proces, maar wat wel belangirjk is dat je een proces hebt. Iets dat tastbaar is en liefst ook snel te begrijpen is.
De meerwaarde van iemand in je team hebben die de stack kent is trouwens veel meer waard dan eender welke online course.

[Hydra]

Furion2000 schreef op woensdag 16 oktober 2019 @ 16:07:
Nu is het volgende idee op tafel gekomen;
Een nieuwe simpele applicatie bouwen met Spring, UI framework (e.g. Angular, React), REST en NoSQL database, gewoon een volledige stack waarbij niemand echt ervaring in heeft of thuis in is. Idee was een soort sport poule spel waarbij je op teams kunt gokken etc. Gewoon puur om kennis te maken met nieuwe frameworks.

Ik werk zelf als freelance Java dev en werk hier dus dagelijks mee. Ik wil je wel alvast meegeven; ga niet voor een NoSQL database tenzij je voor een specifieke usecase een specifieke NoSQL database nodig hebt. Als primaire database zijn ze vrijwel niet geschikt en ga je over het algemeen snel tegen beperkingen aanlopen.

Welke tijd krijgen we momenteel van het bedrijf:
30 min bespreking om de week
1x in de 2 maanden pizza sessie van 15:00 tot 21:00

Da's gewoon enorm weinig met te lange tussenpozen om echt iets te ontwikkelen vrees ik. Als het gaat om die stack te leren, heb je er denk ik meer aan om gewoon workshops te organiseren in die tijd van 15:00 tot 21:00 om een bepaald stuk van de techniek te gaan bekijken.

Echt samenwerken in een project gaat je, door de overhead van samen in 1 applicatie te werken, niet veel opleveren. En omdat er zo'n lange tijd tussen zit, begin je bijna overnieuw iedere keer.

Vragen voor jullie dus:
- Hebben jullie ervaring hiermee en hoe kunnen we dit aanpakken?
- Google als leidraad gebruiken of zijn hier boeken/cursussen (udemy) voor aan te raden?
- Hoe management enthousiast krijgen mocht er tijd extra nodig zijn?

Ervaring; ja. Ik ben primair back-end Java dev en werk dagelijks met Spring. Ook vrij veel ervaring met React en Angular. Wat betreft het hoe; hoe mensen leren is erg persoonlijk. Het is nogal afhankelijk van hun zelf-lerende vermogen of gewoon de officiele Spring tutorials e.d. genoeg zijn, of dat een cursus nodig is. Weet wel dat zo'n cursus alleen al behoorlijk wat tijd gaat kosten.

Wat betreft het management: welk 'nut' heeft dit precies voor het bedrijf? Waar zit voor hen de winst?

[Furion2000]

Oke thanks en kort en bondige samenvatting (ivm even tijdgebrek);
- TIjd is karig voor full blown applicatie, beter thuiswerkopdrachten en dan 30 min gebruiken om te presenteren en dan gezamelijk een grote opdracht tijdens de pizza sessie
- Management overtuigen dat ze hier iets aan hebben
- Tutorials op Youtube zou genoeg moeten zijn voor de meeste devs
- Fun factor hoog houden

Thanks allen voor de input en bevestigingen!

[Hydra]

@Furion2000 mocht je nog ergens over willen sparren kwa Java en/of Spring development mag je me altijd benaderen, via dit topic of DM.

[Furion2000]

@Hydra Thanks! Momenteel vooral druk bezig voor mijzelf met het spelen met OCR en afgelopen weekend een uur vast gezeten omdat Spring Initializr tegenwoordig schijnbaar het weg zet als modules en als je het import als project, Maven allemaal gaat zeuren dat hij dependencies niet ziet

Jullie advies heb ik even doorgezet naar de architect die de club leid en het is dus even afwachten wat er gaat gebeuren. Lijkt mij wel leuk om wat oefeningen voor te bereiden voor mijn collegi!

[labee]

YouTube: Silicon Valley S01E05 scrum scene

[johnkeates]

Wat je stack betreft: je kan behalve zelf alles samen te stellen ook nadat je kennis hebt opgedaan met Spring Boot en losse angular/react spullen een alles-in-een toolbox als JHipster gebruiken. Dat is een template waarbij een moderne SPA of multipage+JS tegen een REST API aankletst die in Spring Boot en verwanten gebouwd is. Op die manier heb je een goed onderhouden ecosysteem waarbij je niet straks zelf het onderhoud aan alles moet doen (wat tot uitstel leidt en dat wordt dan weer afstel...). Als je iets dergelijks gebruikt heb je als een Spring of JS lib EOL gaat automatisch een upgrade pad naar de volgende versie inclusief compatibility met je backend (of als je frontend als die later EOL is dan je backend).

Het komt vaak voor dat een project met de beste intentie wordt neergezet maar uiteindelijk onmogelijk is om technisch bij te houden (om functioneel onderhoud maar even buiten scope te houden). Het is nooit set-and-forget, en dat zal het ook niet worden zolang er software geschreven wordt. Dan is het net zo makkelijk om je alvast klaar te maken zodat je niet over een paar jaar tegen hetzelfde probleem aanloopt.

Nu zijn er wel meer templates en ecosystemen die goed samen gaan, dus pin je vooral niet vast op de eerste beste optie, maar ter illustratie van JHipster's site (https://www.jhipster.tech):

JHipster is a development platform to generate, develop and deploy Spring Boot + Angular / React / Vue Web applications and Spring microservices.

Our goal is to generate for you a complete and modern Web app or microservice architecture, unifying:

A high-performance and robust Java stack on the server side with Spring Boot
A sleek, modern, mobile-first front-end with Angular, React and Bootstrap
A robust microservice architecture with the JHipster Registry, Netflix OSS, the Elastic Stack and Docker
A powerful workflow to build your application with Yeoman, Webpack and Maven/Gradle

Zoals met alles wat een beetje modern is maar wel compatible is met klassieke monolieten en SOA's kan je dus een project opstarten op basis van een ouderwetse MVC applicatie op een applicatie server met ergens een database en wat storage, of je kan het in een container gooien en verservicen zodat je bijv. een verhaal maakt dat met een paar containers of een enkele pod en wat backing state meteen horizontaal schaalbaar is.

Hoewel je werk en leer methode belangrijk is, is het net zo belangrijk om voor het 'echte' werk iets te gebruiken dat niet dermate custom is dat het bij de eerste beste verandering omvalt. Vandaar dit verhaal dus

[ Voor 4% gewijzigd door johnkeates op 19-10-2019 00:24 ]