[Extreme Programming] - Meningen en ervaringen (onderbouwd)

[arthurvanstrien]

Beste mede Tweakers,

Extreme Programming bestaat al een lange tijd maar het wordt nog op veel plekken toegepast. Om deze redenen moeten studenten zoals ik, onszelf verdiepen in Extreme Programming. Graag zou ik benieuwd zijn naar de meningen en positieve / negatieve ervaringen van mede Tweakers om hier van te leren. Er is nogal wat haat tegen Extreme Programming dus gelieve wel je mening goed te onderbouwen als je deze geeft.

Laten we hopen dat we allemaal wat kunnen leren van de gedeelde ervaringen .


Sidenote: dit is het allereerste forum topic wat ik ooit gemaakt heb. Mocht ik het dus niet goed begrepen hebben, geef dat dan even netjes aan, dan corrigeer ik dat even .

[Creepy]

Misschien goed om jouw mening eerste te geven? Of in elk geval je gedachten ervan op dit moment als je er alleen nog maar over hebt gelezen..

[BCC]

Dit klinkt als een huiswerk opdracht die je moet doen?

[arthurvanstrien]

Creepy schreef op zondag 22 januari 2017 @ 20:04:
Misschien goed om jouw mening eerste te geven? Of in elk geval je gedachten ervan op dit moment als je er alleen nog maar over hebt gelezen..

Ik heb er op het moment al een heel verslag over geschreven en heb er al even mee gewerkt. Dit is echter steeds in een schoolomgeving gebeurd. Nu ben ik dus benieuwd wat mensen hun ervaringen zijn met XP in een echte werkomgeving. Ik kan er tot nu toe juist alleen mijn eigen mening er over geven, mijn doel van deze post is kennis uit te wisselen en hopelijk daarmee mijn en andermans kennis te verrijken.

Wat ik eigenlijk te hoop te weten te komen is:
Wordt Extreme Programming nog vaak gebruikt bij bedrijven?
Vinden programmeurs het een lekkere manier van werken?


Wat mijn eigen mening verder is:
Extreme Programming heeft met zijn van Agile afkomende structuur een aantal heel belangrijke gebruiken in zich zitten. Zoals bijvoorbeeld het werken in iteraties, het principe niet over te werken (want anders gaat de kwaliteit omlaag) en een stevige nadruk op het testen van je code. Dit zijn dingen waar je naar mijn mening erg goed van pas kunnen komen.
Er is één ding wat ik echter minder vind aan Extreme Programming en dat is pair programming. Zelf werkt dat bij mij niet zo erg goed omdat ik mij dan niet kan concentreren.

[arthurvanstrien]

BCC schreef op zondag 22 januari 2017 @ 20:06:
Dit klinkt als een huiswerk opdracht die je moet doen?

Wij moeten ons voor onze opleiding verdiepen in het gebruik van Extreme Programming en hier een verslag over schrijven. Hiervoor mogen wij niet alleen onze mening gebruiken maar moeten wij ook de meningen van andere programmeurs verwerken. Deze post leek mij een leuke manier om wat meningen te weten te komen. Als je namelijk googelt of zoekt naar blogs over Extreme Programming krijg je namelijk alleen te horen wat alle negatieve punten zijn. Vaak zijn het zelfs halve tirades. Mensen op de Tweakers fora zijn naar mijn mening best sociaal dus ik verwacht niet dat mensen hier met modder gaan gooien. Als het echter niet de bedoeling is een topic te starten over een onderwerp omdat de reden waarom je besloot het topic te starten een verslag/opdracht is, geef dat dan even aan. Ik ben zelf niet zo actief op fora en zoals te lezen is, is dit mijn eerste forum post ooit.

[AlphaRomeo]

arthurvanstrien schreef op zondag 22 januari 2017 @ 21:31:
[...]
Er is één ding wat ik echter minder vind aan Extreme Programming en dat is pair programming. Zelf werkt dat bij mij niet zo erg goed omdat ik mij dan niet kan concentreren.

En dat is nu juist wat voor mij wel goed werkt. Als wij een moeilijk probleem hebben, wiskundig van aard, of bijvoorbeeld een probleem wat lastig te reproduceren is en bij een klant vandaan komt werkt het juist heel goed om te pair programmen. Dit geldt trouwens ook voor architectuurkeuzes die je maakt waarbij je met zijn tweeën altijd een betere structuur op kunt zetten dan alleen. Een review kan ook helpen, maar dan is het kwaad al geschied. Je argument 'ik kan me dan niet concentreren' snap ik niet helemaal, de ander houdt je dan wel bij de les toch? Misschien werkt dit anders in een schoolomgeving dan in een professioneel ontwikkelteam.

[Caelorum]

Extreme Programming doen wij niet aan, maar pair programming zeker wel. Bij een complexe bug zitten er vaak twee of soms drie mensen achter 1 scherm. Anders is het gewoon vrijwel niet te doen binnen een redelijke tijd.
Voor architectuurkeuzes lijkt het mij overigens niet geschikt. Die dingen kan je beter in een aparte ruimte zonder computers en met een whiteboard uitdenken en voordat je met code aan de slag gaat.

[Swedish Clown]

Caelorum schreef op maandag 23 januari 2017 @ 08:09:
[...]

Voor architectuurkeuzes lijkt het mij overigens niet geschikt. Die dingen kan je beter in een aparte ruimte zonder computers en met een whiteboard uitdenken en voordat je met code aan de slag gaat.

Daar hebben wij dus een Team Area voor. Een enorme hoekbank, 55" TV, een desktop (of mogelijkheid om een laptop aan te sluiten) omringd met white boards. Niet alleen pair programming wordt daar gedaan ook MOB programming indien er een complex probleem is of een nieuw project gestart wordt waar iedereen hetzelfde niveau van kennis over moet hebben.

Persoonlijk wordt ik heel moe van de duizenden verschillende methodes en labels die je overal aan kan plakken. Geen van deze methodes is perfect, allen hebben voor- en nadelen. De truuk is om te pakken wat werkt voor het team en dat iteratief te verbeteren. Kleine iteraties werkt misschien fantastisch voor project X maar is een drama voor project Y. Wees pragmatisch en pas je werk stijl aan aan de omgeving en de mensen waar je mee werkt in plaats van andersom.

[Knutselsmurf]

Caelorum schreef op maandag 23 januari 2017 @ 08:09:
Voor architectuurkeuzes lijkt het mij overigens niet geschikt. Die dingen kan je beter in een aparte ruimte zonder computers en met een whiteboard uitdenken en voordat je met code aan de slag gaat.

Maar als je programming iets verder trekt dan alleen het code kloppen, dan val het maken van architectuurkeuzes ook onder programming. Met 2 of 3 personen en een whiteboard brainstormen is dan ook een vorm van pair programming.

[arthurvanstrien]

AlphaRomeo schreef op maandag 23 januari 2017 @ 07:47:
[...]

En dat is nu juist wat voor mij wel goed werkt. Als wij een moeilijk probleem hebben, wiskundig van aard, of bijvoorbeeld een probleem wat lastig te reproduceren is en bij een klant vandaan komt werkt het juist heel goed om te pair programmen. Dit geldt trouwens ook voor architectuurkeuzes die je maakt waarbij je met zijn tweeën altijd een betere structuur op kunt zetten dan alleen. Een review kan ook helpen, maar dan is het kwaad al geschied. Je argument 'ik kan me dan niet concentreren' snap ik niet helemaal, de ander houdt je dan wel bij de les toch? Misschien werkt dit anders in een schoolomgeving dan in een professioneel ontwikkelteam.

O, bij problemen ben ik ook voorstander van pair programming maar Extreme Programming verplicht je de gehele tijd om te pair programmen. Doen jullie dat dus ook de gehele tijd? Of is het alleen als je op problemen stuit.

Wat mijn concentratie betreft: we zijn allemaal anders en dat is gewoon een eigenschap van mijzelf. Ik kan mij gewoon niet goed concentreren als ik geluiden of andere prikkels van de omgeving krijg.

[arthurvanstrien]

Brakkie41 schreef op maandag 23 januari 2017 @ 08:21:
[...]


Daar hebben wij dus een Team Area voor. Een enorme hoekbank, 55" TV, een desktop (of mogelijkheid om een laptop aan te sluiten) omringd met white boards. Niet alleen pair programming wordt daar gedaan ook MOB programming indien er een complex probleem is of een nieuw project gestart wordt waar iedereen hetzelfde niveau van kennis over moet hebben.

Persoonlijk wordt ik heel moe van de duizenden verschillende methodes en labels die je overal aan kan plakken. Geen van deze methodes is perfect, allen hebben voor- en nadelen. De truuk is om te pakken wat werkt voor het team en dat iteratief te verbeteren. Kleine iteraties werkt misschien fantastisch voor project X maar is een drama voor project Y. Wees pragmatisch en pas je werk stijl aan aan de omgeving en de mensen waar je mee werkt in plaats van andersom.

Dus wat jij eigenlijk zegt over het gebruik van ontwikkelmethodes in de praktijk, is dat je niet een bestaande uitkiest maar je gewoon alle goede eigenschappen van verschillende methodes door elkaar heen gebruikt? En dat die mengelmoes van methodes dus veranderd per project. Dat is heel logisch van één kant gezien maar zorgt dat er niet voor dat jullie een moment moeten wennen aan het nieuwe "recept" als jullie een nieuw project beginnen?

[Verwijderd]

arthurvanstrien schreef op maandag 23 januari 2017 @ 16:33:
[...]


Dus wat jij eigenlijk zegt over het gebruik van ontwikkelmethodes in de praktijk, is dat je niet een bestaande uitkiest maar je gewoon alle goede eigenschappen van verschillende methodes door elkaar heen gebruikt? En dat die mengelmoes van methodes dus veranderd per project. Dat is heel logisch van één kant gezien maar zorgt dat er niet voor dat jullie een moment moeten wennen aan het nieuwe "recept" als jullie een nieuw project beginnen?

Zolang je niet vastzit aan een bepaalde methode (vanuit ISO of weet ik veel wat) is het toch juist heel menselijk/natuurlijk om de beste eigenschappen bij elkaar te brengen en daar je eigen draai aan te geven? Extreme Programming staat vast heel leuk in een schoolboek maar ik betwijfel of het veel wordt toegepast in de praktijk, in die pure vorm dan.

[Caelorum]

arthurvanstrien schreef op maandag 23 januari 2017 @ 16:28:
[...]
Wat mijn concentratie betreft: we zijn allemaal anders en dat is gewoon een eigenschap van mijzelf. Ik kan mij gewoon niet goed concentreren als ik geluiden of andere prikkels van de omgeving krijg.

Daar had ik tijdens mijn studie ook last van, maar in een bedrijfsomgeving eigenlijk totaal niet. Je bent dan ook op een hele andere manier bezig met de taken die voor je liggen. Ik zou daar niet pair programming op beoordelen, iig niet totdat je het in een aantal verschillende settings hebt geprobeerd.

Knutselsmurf schreef op maandag 23 januari 2017 @ 15:23:
[...]

Maar als je programming iets verder trekt dan alleen het code kloppen, dan val het maken van architectuurkeuzes ook onder programming. Met 2 of 3 personen en een whiteboard brainstormen is dan ook een vorm van pair programming.

Tuurlijk, maar met pair programming wordt doorgaans juist samen achter 1 PC zitten bedoelt. En hoewel je prima de architectuur kan ontwerpen achter een PC, doe ik dat liever niet, omdat de verleiding om even naar de huidige code (en 1000 en 1 andere dingen) te kijken te groot wordt.

[arthurvanstrien]

Verwijderd schreef op maandag 23 januari 2017 @ 16:48:
[...]


Zolang je niet vastzit aan een bepaalde methode (vanuit ISO of weet ik veel wat) is het toch juist heel menselijk/natuurlijk om de beste eigenschappen bij elkaar te brengen en daar je eigen draai aan te geven? Extreme Programming staat vast heel leuk in een schoolboek maar ik betwijfel of het veel wordt toegepast in de praktijk, in die pure vorm dan.

Ik verwachte ook al dat het in de praktijk niet strak werd toegepast en dat het inderdaad heel mooi stond in een schoolboek. Daarom ben ik dus dit topic gestart om er achter te komen of het in de praktijk toegepast werd. Zoals ik begrijp uit de reacties worden veel elementen die in Extreme Programming zitten toegepast in de praktijk. Want het motto is: maak die code zo goed mogelijk en zo efficient mogelijk en alles wat daar bij helpt gebruik je natuurlijk gewoon.

[Tarkin]

Extreme Programming is inderdaad een niche in de niche.

Er zijn wel al meer bedrijven die Agile Scrum/Kanban beginnen toe te passen, XP is dan nog een brug te ver meestal.

Ikzelf heb wel in zo'n omgeving gewerkt jaren en ik ben hier hevig fan van. Ja het is intensiever om dagelijks met 2 achter 1 pc te zitten, maar uiteindelijk heb je betere code en minder bugs in je code (het is bewezen dat je 60% minder bugs produceert hierdoor).

Het is zeker niet voor iedereen weggelegd, je moet het echt willen doen want anders werkt het niet, maar als je in zo'n team zit met zo'n mindset, dan kan je echt enorm verschil maken.

[CurlyMo]

Tarkin schreef op dinsdag 24 januari 2017 @ 11:03:
Ja het is intensiever om dagelijks met 2 achter 1 pc te zitten, maar uiteindelijk heb je betere code en minder bugs in je code (het is bewezen dat je 60% minder bugs produceert hierdoor).

Ik ben wel benieuwd naar die onderzoeken, niet als kritiek maar als pure nieuwsgierigheid.

[Tarkin]

CurlyMo schreef op dinsdag 24 januari 2017 @ 11:06:
[...]

Ik ben wel benieuwd naar die onderzoeken, niet als kritiek maar als pure nieuwsgierigheid.

Ik kan ze niet zo snel vinden (heb het ook vooral van horen zeggen dat dat % de bugsreduce er is), eigen eravring is wel dat het aantal bugs gaandeweg gestaag daalt en dat er minder bijkomen. Alleen al door de groepsdynamiek en agile ways,
hier is er eentje:
https://raygun.com/blog/2...-pair-programming-really/

[Hydra]

Caelorum schreef op maandag 23 januari 2017 @ 08:09:
Extreme Programming doen wij niet aan, maar pair programming zeker wel. Bij een complexe bug zitten er vaak twee of soms drie mensen achter 1 scherm. Anders is het gewoon vrijwel niet te doen binnen een redelijke tijd.

Dat is niet het pair programming van XP; meer een 'lite' versie. In XP's versie zit je dus continue samen achter een scherm. Mob programming is een nog extremere versie hiervan; dan doe je hetzelfde met een team van 5 ofzo.

Beide vormen werken voor mij niet. Samen naar een bug kijken; prima. Maar 'gewone' implementatie werkt voor mij veel beter als ik gewoon in m'n eigen focus bubble kan werken.

Tarkin schreef op dinsdag 24 januari 2017 @ 11:09:
Ik kan ze niet zo snel vinden (heb het ook vooral van horen zeggen dat dat % de bugsreduce er is), eigen eravring is wel dat het aantal bugs gaandeweg gestaag daalt en dat er minder bijkomen. Alleen al door de groepsdynamiek en agile ways,

Nu gooi je een aantal zaken op een hoop. Peer reviews naderhand vangen ook bugs zonder dat je twee dure devs naast elkaar hebt zitten continue. Je kunt prima 'agile' werken zonder continue met 2 of meer man achter een scherm te zitten.

arthurvanstrien schreef op maandag 23 januari 2017 @ 16:57:
Ik verwachte ook al dat het in de praktijk niet strak werd toegepast en dat het inderdaad heel mooi stond in een schoolboek. Daarom ben ik dus dit topic gestart om er achter te komen of het in de praktijk toegepast werd. Zoals ik begrijp uit de reacties worden veel elementen die in Extreme Programming zitten toegepast in de praktijk. Want het motto is: maak die code zo goed mogelijk en zo efficient mogelijk en alles wat daar bij helpt gebruik je natuurlijk gewoon.

Sterker nog, regel 1 van het Agile Manifesto: "Individuals and interactions over processes and tools". Als je processen oplegt doe je per definitie niet aan 'agile'. Een enorm belangrijk onderdeel van agile development is de retrospective elke cyclus waarbij je kijkt naar wat wel en niet werkt en het proces daarop aanpast.

[ Voor 53% gewijzigd door Hydra op 24-01-2017 14:27 ]

[Tarkin]

Hydra schreef op dinsdag 24 januari 2017 @ 14:21:
[...]


Nu gooi je een aantal zaken op een hoop. Peer reviews naderhand vangen ook bugs zonder dat je twee dure devs naast elkaar hebt zitten continue. Je kunt prima 'agile' werken zonder continue met 2 of meer man achter een scherm te zitten.

Misschien wel, maar de ervaring leert wel dat er met peer reviews meer bugs door sluipen dan tijdens het pair programmen.

Het heeft er m.i. ook meer mee te maken dat er een gezonde dwang op testen lag bij Pair programmen. Begon je niet je test te schrijven, dan had je altijd een pair om je op het rechte pad te houden. Dat heb je niet als je in je eigen bubble zit (ik betrap me er zelf ook op hoor). Tijdens het peer reviewen ga je dan wel bepaalde zaken op het zicht eruit halen, maar ik merk op m'n huidig project dat het minder effectief is dan pairen.

Het is ook lastiger om after the facts te zeggen tegen de developer je moet meer testen schrijven. Van het moment dat je dat moet doen en afdwingen, krijg je geen kwalitatieve tests bij. De developer in kwestie gaat dan gewoon de bestaande situatie (zoals die voor hem lijkt te werken) aftesten en niet (zoals TDD betaamd) eerst de test schrijven en dan pas de implementatie.

Pair programmen past juist heel goed bij het Agile gebeuren, net omdat het die interactie hoog in het vaandel draagt. Ipv verplichte meetings achteraf (zoals code revieuws) gebeurt het gewoon elke moment van de dag. Ik snap wel dat het voor veel bedrijven een stap te ver is om 2 mensen achter 1 pc te zetten.

Een heel effectieve manier van pairen is ook een rotatiesysteem met een team. de ene helft blijft op hun story als lead en werken daaraan totdat die af is, elke dag komt er iemand anders bij hem zitten. Zo heb je altijd verse inzichten en wordt het werk nooit saai. Langs de andere kant heb je wel de basis aangezien de lead alle designkeuzes van die story weet.

[Hydra]

Tarkin schreef op dinsdag 24 januari 2017 @ 14:56:
[...]


Misschien wel, maar de ervaring leert wel dat er met peer reviews meer bugs door sluipen dan tijdens het pair programmen.

Het heeft er m.i. ook meer mee te maken dat er een gezonde dwang op testen lag bij Pair programmen. Begon je niet je test te schrijven, dan had je altijd een pair om je op het rechte pad te houden. Dat heb je niet als je in je eigen bubble zit (ik betrap me er zelf ook op hoor). Tijdens het peer reviewen ga je dan wel bepaalde zaken op het zicht eruit halen, maar ik merk op m'n huidig project dat het minder effectief is dan pairen.

Het is ook lastiger om after the facts te zeggen tegen de developer je moet meer testen schrijven. Van het moment dat je dat moet doen en afdwingen, krijg je geen kwalitatieve tests bij. De developer in kwestie gaat dan gewoon de bestaande situatie (zoals die voor hem lijkt te werken) aftesten en niet (zoals TDD betaamd) eerst de test schrijven en dan pas de implementatie.

Pair programmen past juist heel goed bij het Agile gebeuren, net omdat het die interactie hoog in het vaandel draagt. Ipv verplichte meetings achteraf (zoals code revieuws) gebeurt het gewoon elke moment van de dag. Ik snap wel dat het voor veel bedrijven een stap te ver is om 2 mensen achter 1 pc te zetten.

Een heel effectieve manier van pairen is ook een rotatiesysteem met een team. de ene helft blijft op hun story als lead en werken daaraan totdat die af is, elke dag komt er iemand anders bij hem zitten. Zo heb je altijd verse inzichten en wordt het werk nooit saai. Langs de andere kant heb je wel de basis aangezien de lead alle designkeuzes van die story weet.

Waar dit een beetje op neer komt is dat er kennelijk weinig discipline is om het 'goed' te doen (kwa bijvoorbeeld test coverage) als mensen niet meekijken. Dan is m.i. pair programming vooral het soort 'dwang' waar ik persoonlijk erg slecht op reageer.

Mij ga je niet overtuigen trouwens; ik heb 't genoeg gedaan om te weten dat het voor mij niet werkt.

[Tarkin]

Ik weet dat we er al over gediscussieerd hebben
Jij zal dan inderdaad iemand zijn voor wie het niet werkt. Zolang het werk maar afgeraakt no problem.

Het probleem is dat ik hier op het werk verscheidene mensen heb die niet de discipline hebben om na te denken bij het developen, en liever lui dan moe zijn. Dus half werkende code en weinig deftige testen. Bij zulke mensen zou het wel heel goed werken (en heel goed zijn voor het bedrijf, ofwel gaan ze erin mee, ofwel geraken ze gefrustreerd en gaan ze hun "kunde" ergens anders uitvoeren, altijd een win-win voor het bedrijf). Maar helaas.

En voor je het zegt, nee ze worden niet buitengegooid, want ze werken als een trouwe indier. Kan jij x implemnteren wordt altijd beantwoord met een ja, tegen gisteren? ja,... Business is dus heel blij dat ze zulke mensen hebben, maar langs de andere kant wel klagen over de shitty code, tjah.

[Hydra]

Tarkin schreef op dinsdag 24 januari 2017 @ 15:18:
Het probleem is dat ik hier op het werk verscheidene mensen heb die niet de discipline hebben om na te denken bij het developen, en liever lui dan moe zijn.

Het voordeel dat ik heb (consulting) is dat de eindklant zulke mensen over het algemeen gewoon wegstuurt. Je gaat niet zo rond de 100E per uur betalen voor een dev die "liever lui dan moe is".

Ik snap zeker wel dat extreme programming 'help' als 'stick' tegen zulke mensen maar dat zou voor mij persoonlijk alleen maar demotiverend werken. Ik werk liever met intrinsiek gemotiveerde developers.

[Swedish Clown]

arthurvanstrien schreef op maandag 23 januari 2017 @ 16:33:
[...]


Dus wat jij eigenlijk zegt over het gebruik van ontwikkelmethodes in de praktijk, is dat je niet een bestaande uitkiest maar je gewoon alle goede eigenschappen van verschillende methodes door elkaar heen gebruikt? En dat die mengelmoes van methodes dus veranderd per project. Dat is heel logisch van één kant gezien maar zorgt dat er niet voor dat jullie een moment moeten wennen aan het nieuwe "recept" als jullie een nieuw project beginnen?

In de praktijk valt dit heel erg mee. Om even een voorbeeld te geven. Wij proberen de tickets altijd zo klein mogelijk te houden en grote feature branches te vermijden. Bij ons laatste project bleek al vrij snel dat deze methode voor dat specifieke project niet effectief was. Dus pragmatische oplossen, afwijken van onze standaard werkwijze en toch voor een feature branch gegaan. De review was een pain in the ass maar onze velocity ging rap omhoog.

Hydra schreef op dinsdag 24 januari 2017 @ 14:21:

Sterker nog, regel 1 van het Agile Manifesto: "Individuals and interactions over processes and tools".

[Douweegbertje]

Ik had er om eerlijk te zijn nooit van gehoord, echter ken ik het principe dan weer wel. Ik snap het uitgangspunt ook wel, maar het vergt wel weer een "offer" dat je met 2 man constant bezig bent.

Dan mijn andere ervaring: iedereen heeft zijn eigen style en werkwijzes. Vaak kun je betere code te krijgen door "iemand zn ding te laten doen". Je kan een bepaalde functionaliteit op verschillende manieren implementeren en ik vind dat er niet een "perfecte" manier is.

Normaal doen wij vooraf een aantal dingen bespreken en daaruit komen ook bepaalde pointers van "denk je hier aan" of "ik zou het zo doen". Uiteindelijk is de keuze aan de programmeur voor dat stukje. Uiteindelijk is er ook gewoon een review proces. Tenzij het echt 'slecht' is, komen hier alleen super kleine feedback puntjes uit wat meestal niet eens met de architectuur te maken heeft.


In elk geval hebben we gewoon standaarden en is onderling bekend wat gebruikelijke flows zijn. De programmeurs hebben voldoende kennis en weten genoeg van het onderwerp af. Persoonlijk voorkomt dat de noodzaak van XP. De hoeveelheid feedback die je daarvan zou krijgen zou richting nihil gaan omdat "het toch al goed is".
Bij onduidelijkheden of structurele architecturele vraagstukken overleggen we ad-hoc.

Ik kan mij voorstellen dat je bij enorm complexe projecten en een ongelijkmatig team (kennis verschil, geen eenheid etc.) men voordeel kan boeken bij XP.