De Devschuur Coffee Corner - Iteratie ⓫

[orf]

Hoe kijken jullie aan tegen snelheid van developers? Dan bedoel ik natuurlijk geen onzinnig iets als aantal regels code als KPI, maar hoe snel iemand iets gedaan krijgt.

Wanneer is iets nog pragmatisch en wanneer slaat het door? Hoeveel tijd mogen tests kosten voor een story en hoeveel tijd mag een deploy kosten. Ik kom steeds wat verder van development te staan, maar vind het soms bizar wat voor inschattingen een team soms geeft. Terwijl het hier juist om een nieuw product gaat en niet om één of andere legacy app.

[Alex)]

Ik sta soms te kijken van de inschattingen die mensen geven, zonder argumentatie die verder gaat dan "Tsja, het is best wel complex!" Ik hoor vrijwel nooit waar de vermeende complexiteit dan in zou zitten.

Daarnaast vind ik "story points" maar een vrij waardeloze metric. Het is niet te peilen en iedereen heeft een ander idee van wat een story point nou inhoudt. En daarbij kan het ook nog eens zo zijn dat verschillende teams er verschillende ideeën op nahouden, waardoor je moet gaan 'omrekenen'.

[Twieka]

Alex) schreef op maandag 31 juli 2017 @ 23:21:
Ik sta soms te kijken van de inschattingen die mensen geven, zonder argumentatie die verder gaat dan "Tsja, het is best wel complex!" Ik hoor vrijwel nooit waar de vermeende complexiteit dan in zou zitten.

Daarnaast vind ik "story points" maar een vrij waardeloze metric. Het is niet te peilen en iedereen heeft een ander idee van wat een story point nou inhoudt. En daarbij kan het ook nog eens zo zijn dat verschillende teams er verschillende ideeën op nahouden, waardoor je moet gaan 'omrekenen'.

Dat is toch juist het idee? Dat ieder team z'n eigen story points aanhoudt. Kun je mbv. de velocity goed zien wanneer het team volgens de planning klaar zou moeten zijn. Hoe anders zou een project manager een goede inschatting kunnen maken?

[LangTall]

Rutix schreef op maandag 31 juli 2017 @ 15:36:
[...]

Hoe werkt dat dan als je met meerdere mensen onderhoud moet doen als de input mag verschillen?

Daar hebben wij een centraal ingestelde Jalopy voor. Heb je iig de formatting hetzelfde. En of je dat dan in Eclipse, Netbeans of IntelliJ doet maakt geen bal uit. Vim wordt wat lastiger, net als Sublime Text.

[Neko Koneko]

Alex) schreef op maandag 31 juli 2017 @ 23:21:
Ik sta soms te kijken van de inschattingen die mensen geven, zonder argumentatie die verder gaat dan "Tsja, het is best wel complex!" Ik hoor vrijwel nooit waar de vermeende complexiteit dan in zou zitten.

Daarnaast vind ik "story points" maar een vrij waardeloze metric. Het is niet te peilen en iedereen heeft een ander idee van wat een story point nou inhoudt. En daarbij kan het ook nog eens zo zijn dat verschillende teams er verschillende ideeën op nahouden, waardoor je moet gaan 'omrekenen'.

Ik ben zelf de meeste tijd vaak kwijt aan het uitzoeken hoe en waar ik iets moet wijzigen om het gewenste resultaat te krijgen. Nadeel als je een pakket onderhoud dat jarenlang door één man is geschreven en nooit goed gedocumenteerd is

En ik betrap me er keer op keer op dat ik dezelfde fout aan het maken ben en eigenlijk zaken zou moeten documenteren...

[orf]

Ik ben niet tegen story points en ik vind het goed als een team een vaste velocity heeft, zodat daar op gepland kan worden. Ik heb wel een probleem met het inschatten op complexiteit, waarbij elke relatie met het aantal uur verloren gaat. Zeker als het om kleine verbeterpunten gaat, het team alleen 1, 3, 8 of 13 punten op gooit en dat dit in aantal uur vermenigvuldigd met 2 wordt (of in Euro's vermenigvuldigd met 200).

Nu kwam er uit een lijstje met verbeteringen dat iemand voor alle <inputs> een type=text had gebruikt, terwijl er handigere types zijn. Die aanpassing werd ingeschat op 8 punten (en dus 1.600 euro). Ik kan me niet voorstellen dat iemand hier meer dan twee volle werkdagen mee bezig is. Ik kan me ook niet voorstellen dat iemand na twee dagen werken kan zeggen trots te zijn op wat je in die twee dagen gedaan hebt.

Maakt een developer dan niet de vertaling naar uren of zelfs Euro's? Zou een developer hier zelf financieel verantwoordelijk voor willen zijn? Of is dat iets abstracts dat gewoon door anderen geregeld moet worden, zodat je lekker kunt developen?

/rant

[ElkeBxl]

orf schreef op maandag 31 juli 2017 @ 23:12:
Hoeveel tijd mogen tests kosten voor een story en hoeveel tijd mag een deploy kosten. Ik kom steeds wat verder van development te staan, maar vind het soms bizar wat voor inschattingen een team soms geeft. Terwijl het hier juist om een nieuw product gaat en niet om één of andere legacy app.

Ik doe zowel development als af en toe analyse. Als ik analist op een project ben moet ik ook schattingen maken. Ik kijk in de eerste plaats altijd naar de requirements die we binnen krijgen maar ik heb ook al gehad dat ik bepaalde schattingen expres verhoogde door vele andere factoren.

Als ik moet samenwerken met de meer incompetente collega's van mijn team, dan kan het al snel ettelijke mandagen meer worden dat ik schat Bij sommigen doe ik de schatting tegenwoordig al maal anderhalf en overweeg ik zelfs om maal 2 te doen... Helaas heb ik al meegemaakt dat ik dan nog te laag geschat heb

Ook afhankelijk van de duidelijkheid van de requirements kan het al snel gebeuren dat ik er paar mandagen bij tel als buffer en om meer budget te hebben om bepaalde zaken uit te klaren.

[Hydra]

Een probleem met ons werk is dat het gewoon vrij makkelijk is een groot deel van de dag niks nuttigs te doen. Hierin is software engineering niet uniek maar wel vrij extreem in hoe simpel het is je manager te bullshitten over hoe lang iets duurt.

Dus nee, een paar input velden veranderen duurt geen twee dagen. Maar dat weet de manager niet.

[orf]

ElkeBxl schreef op dinsdag 1 augustus 2017 @ 08:50:
[...]

Ik doe zowel development als af en toe analyse. Als ik analist op een project ben moet ik ook schattingen maken. Ik kijk in de eerste plaats altijd naar de requirements die we binnen krijgen maar ik heb ook al gehad dat ik bepaalde schattingen expres verhoogde door vele andere factoren.

Als ik moet samenwerken met de meer incompetente collega's van mijn team, dan kan het al snel ettelijke mandagen meer worden dat ik schat Bij sommigen doe ik de schatting tegenwoordig al maal anderhalf en overweeg ik zelfs om maal 2 te doen... Helaas heb ik al meegemaakt dat ik dan nog te laag geschat heb

Ook afhankelijk van de duidelijkheid van de requirements kan het al snel gebeuren dat ik er paar mandagen bij tel als buffer en om meer budget te hebben om bepaalde zaken uit te klaren.

Vind je die incompetente collega's niet verschrikkelijk? Inschattingen verhogen of verdubbelen doen wij ook wel eens, omdat je soms wel weet dat je nu nog niet goed kan overzien hoe veel tijd iets gaat kosten, of hoe brak de documentatie van een API blijkt te zijn waardoor je veel tijd kwijt raakt.

Hydra schreef op dinsdag 1 augustus 2017 @ 08:54:
Dus nee, een paar input velden veranderen duurt geen twee dagen. Maar dat weet de manager niet.

Ik ben geen standaard manager met spreadsheets en gantt planningen. Ik heb 12 jaar ervaring met development en ik ben de eigenaar van het bureau, waardoor ik de relatie met uren en geld wel moet maken. Van deze inschattingen krijg ik de neiging om zelf in in een uurtje de aanpassing te doen, alleen om te laten zien dat de inschatting bullshit is.

Het gaat hier ook niet om mensen die graag niks doen, of iets anders doen met hun tijd. Ik weet wel dat er extreem defensief ingeschat wordt, omdat sommigen het verschrikkelijk vinden om ergens langer over te doen dan de inschatting. En sommigen lijken weinig pragmatisme te hebben en altijd te willen kiezen voor de meest complexe oplossing die eventueel rekening zou kunnen houden met alle edge-cases die mogelijk zouden kunnen zijn. Het lijkt ook dynamiek te zijn. In andere teams zie ik wel een "getting shit done" mentaliteit en ben ik soms juist weer verbaasd over wat ze leveren.

[Jan_V]

orf schreef op dinsdag 1 augustus 2017 @ 08:47:
Ik ben niet tegen story points en ik vind het goed als een team een vaste velocity heeft, zodat daar op gepland kan worden. Ik heb wel een probleem met het inschatten op complexiteit, waarbij elke relatie met het aantal uur verloren gaat. Zeker als het om kleine verbeterpunten gaat, het team alleen 1, 3, 8 of 13 punten op gooit en dat dit in aantal uur vermenigvuldigd met 2 wordt (of in Euro's vermenigvuldigd met 200).

Nu kwam er uit een lijstje met verbeteringen dat iemand voor alle <inputs> een type=text had gebruikt, terwijl er handigere types zijn. Die aanpassing werd ingeschat op 8 punten (en dus 1.600 euro). Ik kan me niet voorstellen dat iemand hier meer dan twee volle werkdagen mee bezig is. Ik kan me ook niet voorstellen dat iemand na twee dagen werken kan zeggen trots te zijn op wat je in die twee dagen gedaan hebt.

Maakt een developer dan niet de vertaling naar uren of zelfs Euro's? Zou een developer hier zelf financieel verantwoordelijk voor willen zijn? Of is dat iets abstracts dat gewoon door anderen geregeld moet worden, zodat je lekker kunt developen?

/rant

Het is natuurlijk afhankelijk van het project.

Het find-replacen van een 'text' naar iets anders hoeft niet perse lastig te zijn.
Wel handig om van tevoren even te speccen naar welk type een veld moet worden gewijzigd. Ook zal er natuurlijk een volledige regressietest moeten gaan plaatsvinden (al dan niet de automatische regressietesten aanpassen) om te constateren dat 'alles' nog goed werkt.
Afhankelijk van de hoeveelheid inputs en wijzigingen lijkt 2 dagen helemaal niet raar. Maar ik heb natuurlijk geen idee van de grootte van het project, opzet, werkprocessen, etc. ;-)

[alienfruit]

Maakt een developer dan niet de vertaling naar uren of zelfs Euro's? Zou een developer hier zelf financieel verantwoordelijk voor willen zijn? Of is dat iets abstracts dat gewoon door anderen geregeld moet worden, zodat je lekker kunt developen?

Tuurlijk niet. In de meeste gevallen had de ontwikkelaar zelf geen invloed in de technologie die werd gebruikt. Als ik met SAP moet werken dan verdubbel al mijn inschattingen met 1.8-2.3. Omdat elke SAP systeem bij de klant wel onbeschreven wijzigingen heeft en de analyst de boel niet voldoende heeft onderzocht zodat er minsten één ding over het hoofd is gezien en zodoende de ontwikkelaar vaak dubbel werkt moet doen of de key stakeholder bij de klant iets is vergeten op te schrijven. Of dat qua front-end werk iets erg makkelijk maar dat de aanpassingen in SAP veel meer werk kosten.

[ElkeBxl]

orf schreef op dinsdag 1 augustus 2017 @ 09:12:
[...]
Vind je die incompetente collega's niet verschrikkelijk? Inschattingen verhogen of verdubbelen doen wij ook wel eens, omdat je soms wel weet dat je nu nog niet goed kan overzien hoe veel tijd iets gaat kosten, of hoe brak de documentatie van een API blijkt te zijn waardoor je veel tijd kwijt raakt.

Ik heb er een bloedhekel aan. En ik meld het ook zo vaak als ik kan dat er hier echt teveel incompetente collega's rondlopen. Zelfs al eens gehad dat mijn manager een schatting vroeg en toen hij dan zei dat X ook op het project ging werken zei ik vlakaf: "dan gaan we er 10 mandagen bij moeten doen, dus 50 ipv 40 en dan schat ik nog superoptimistisch... heb je niemand beter om met mij en Y samen te werken?".

Ik kan helaas niet veel meer doen dan aan de alarmbel trekken en duidelijk communiceren wie/wat de reden is als we weeral eens deadline niet halen. Oh wat zou ik graag eens grote kuis houden...

[Ryur]

ElkeBxl schreef op dinsdag 1 augustus 2017 @ 09:55:
[...]
Ik kan helaas niet veel meer doen dan aan de alarmbel trekken en duidelijk communiceren wie/wat de reden is als we weeral eens deadline niet halen. Oh wat zou ik graag eens grote kuis houden...

Kuis = opruiming?

[alienfruit]

schoonmaken toch?

[Hydra]

ElkeBxl schreef op dinsdag 1 augustus 2017 @ 09:55:
Ik heb er een bloedhekel aan. En ik meld het ook zo vaak als ik kan dat er hier echt teveel incompetente collega's rondlopen. Zelfs al eens gehad dat mijn manager een schatting vroeg en toen hij dan zei dat X ook op het project ging werken zei ik vlakaf: "dan gaan we er 10 mandagen bij moeten doen, dus 50 ipv 40 en dan schat ik nog superoptimistisch... heb je niemand beter om met mij en Y samen te werken?".

Ik heb samen met een andere dev een keer een incompetente developer eruit gewieberd. Die incompetente dev deed over alles bizar lang en maakte er bovendien een puinhoop van. Voordat ik erbij kwam hebben de andere devs vaak genoeg geklaagd over hem maarja, hij was "goedkoop".

Ik was het in no time zat en we hebben een tijdje gewoon de tijdsinspanningen bijgehouden. Hij had dan voor een simpele feature 4 dagen nodig, wij 2 uur. Maar we hadden dan vaak 4 uur of meer tijd nodig zijn meuk te fixen. Dus toen was het opeens voor de eigenaar wel duidelijk dat die gast een netto negatieve bijdrage had.

Heb ook nul medelijden met hem. Hij was niet alleen een prutser, het was ook nog eens een enorme eikel die per definitie niks van me aan wou nemen omdat hij ouder was en langer bij het bedrijf werkte. Doei

orf schreef op dinsdag 1 augustus 2017 @ 09:12:
In andere teams zie ik wel een "getting shit done" mentaliteit en ben ik soms juist weer verbaasd over wat ze leveren.

Hier moet je wel mee oppassen. Ik zie om me heen dat veel developers enorm gevoelig zijn voor de perceptie van hun manager. Als de manager er blij van wordt dat ze gaan corner cutten en zo 2 dagen eerder klaar zijn met een feature is de druk om dat te doen en te blijven doen (maar de vorige keer duurde het maar X dagen?) een enorme factor in je code kwaliteit.

Getting shit done is goed, maar je moet geen technische schuld op gaan bouwen. En dat laatste zie ik toch wel erg vaak in projecten met onervaren managers (waarmee ik niet bedoel dat jij dat bent) die geen development ervaring hebben.

In mijn huidige project heeft de eerste data engineer er kwa architectuur een enorme teringzooi van gemaakt. De managers waren enorm blij met hem omdat 'ie zo snel dingen regelden. Die gast is alleen wel kort voor de live-gang vertrokken en heeft anderen met de gebakken peren laten zitten. Daar hebben we nu nog steeds last van.

[ Voor 30% gewijzigd door Hydra op 01-08-2017 10:47 ]

[ElkeBxl]

Ryur schreef op dinsdag 1 augustus 2017 @ 10:07:
[...]

Kuis = opruiming?

Correct!

Hydra schreef op dinsdag 1 augustus 2017 @ 10:43:
[...]

Ik was het in no time zat en we hebben een tijdje gewoon de tijdsinspanningen bijgehouden. Hij had dan voor een simpele feature 4 dagen nodig, wij 2 uur. Maar we hadden dan vaak 4 uur of meer tijd nodig zijn meuk te fixen. Dus toen was het opeens voor de eigenaar wel duidelijk dat die gast een netto negatieve bijdrage had.

Zoiets zouden wij hier ook eens moeten doen... Op 1 van die projecten waar X op werkte, heb ik samen met een collega meer gedaan op 50 mandagen over ons beide verdeeld dan hij op 200 mandagen deed. We hebben het project maar nipt nog kunnen rechttrekken maar ondertussen is het wel zwaar over budget gegaan en het is 2 maand later dan gepland opgeleverd... En de hoeveelheid shit die we moesten opkuisen was ongelofelijk. We hebben echt op het punt gestaan om gewoon alles weg te smijten en volledig from scratch te herbeginnen. Maar dat konden we moeilijk maken nadat er al 200 mandagen gespendeerd was op iets wat voor 230 mandagen geschat was, we zouden het nogal mogen gaan uitleggen als we 200 mandagen aan werk zouden wegsmijten... Oh wat zou ik graag mensen zoals X willen buitengooien, alleen heb ik die macht niet

[ Voor 3% gewijzigd door ElkeBxl op 01-08-2017 11:20 ]

[Alex)]

Twieka schreef op dinsdag 1 augustus 2017 @ 00:14:
[...]


Dat is toch juist het idee? Dat ieder team z'n eigen story points aanhoudt. Kun je mbv. de velocity goed zien wanneer het team volgens de planning klaar zou moeten zijn. Hoe anders zou een project manager een goede inschatting kunnen maken?

Misschien heeft dat ook wel te maken met het werken in sprints, ik vind dat helemaal geen fijne manier van werken. Het idee dat je elke 1/2/3 weken een nieuw "functionerend" product moet opleveren vind ik niet kloppen.

Soms zijn de wensen en technische implementatie daarvan nou eenmaal groter dan wat in 1 "sprint" opgepakt kan worden, en is opknippen daarvan onzinnig omdat je dan half-functionerende producten oplevert. Ik werk liever met een feature-based releaseschema: liever een wat langere doorlooptijd tot de volgende productierelease, maar dan wel in één keer goed.

Goed voorbeeld van hoe het niet moet; de onlangs vernieuwde NS-app. Toen die in de app stores verscheen zat het ding ramvol bugs die makkelijk opgelost hadden kunnen worden als er wat beter was getest en de release was uitgesteld.

Maar ja, dan zou de sprint goal wel niet zijn gehaald hè...

[Hydra]

ElkeBxl schreef op dinsdag 1 augustus 2017 @ 11:19:
Oh wat zou ik graag mensen zoals X willen buitengooien, alleen heb ik die macht niet

Managers zijn gevoelig voor feiten en getallen, niet voor puur iemand zwartmaken. Als je kunt aantonen dat die persoon een netto negatieve toevoeging is op het project is het al een stuk makkelijker.

[DevWouter]

Alex) schreef op dinsdag 1 augustus 2017 @ 11:19:
[...]

Misschien heeft dat ook wel te maken met het werken in sprints, ik vind dat helemaal geen fijne manier van werken. Het idee dat je elke 1/2/3 weken een nieuw "functionerend" product moet opleveren vind ik niet kloppen.

Een sprint mag zolang of zo kort zijn als je wilt. Zolang je maar time-boxed werkt (dus eerst de lengte bepalen, dan pas de sprint invullen). Een sprint mag dus 1 dag, 1 jaar zijn of 123 uur en 12 seconden. Het gaat er alleen omdat de lengte effectief is. Bij 1 dag heb je vaak te veel overhead en bij 1 jaar kan je niet tijdig bijsturen en 123 uur en 12 seconden is dusdanig exact dat het ingewikkeld wordt met plannen.

Verder is een oplevering ook een taak die rustig een onderdeel mag zijn van je sprint. Aan het eind van een sprint moet je het resultaat van de sprint bespreken, niet het product.

[cracking cloud]

orf schreef op dinsdag 1 augustus 2017 @ 09:12:
En sommigen lijken weinig pragmatisme te hebben en altijd te willen kiezen voor de meest complexe oplossing die eventueel rekening zou kunnen houden met alle edge-cases die mogelijk zouden kunnen zijn.

En die in de praktijk nooit gebeuren. Ik kies liever voor de 'dat fixen we dan wel weer' oplossing (waarbij 'dan' in de praktijk bijna nooit voor lijkt te komen)

[Alex)]

DevWouter schreef op dinsdag 1 augustus 2017 @ 11:55:
[...]


Zolang je maar time-boxed werkt (dus eerst de lengte bepalen, dan pas de sprint invullen). Een sprint mag dus 1 dag, 1 jaar zijn of 123 uur en 12 seconden. Het gaat er alleen omdat de lengte effectief is.

Maar waarom?

[ Voor 6% gewijzigd door Alex) op 01-08-2017 15:55 ]

[Megamind]

Alex) schreef op dinsdag 1 augustus 2017 @ 15:53:
[...]

Maar waarom?

Onze sprints waren zo random dat een release nu een sprint is, en die loopt vaak ook nog eens 1-2 weken uit

[orf]

Alex) schreef op dinsdag 1 augustus 2017 @ 15:53:
[...]

Maar waarom?

Omdat het goed is om tijd op fixed te zetten. Dat zorgt ervoor dat je zoveel mogelijk "waarde" toevoegt in een fixed periode. Dat werkt beter dan er bij de deadline achter komen dat je nog niet klaar bent en dat je langer de tijd nodig hebt en meer budget. Je kunt van te voren niet helemaal voorspellen hoe het gaat lopen en daarom kun je maar beter functionaliteiten bouwen op volgorde van prioriteit in plaats van dat alles even belangrijk is. Natuurlijk komt er halverwege het project vanalles aan functionaliteit bij, want je hebt nu eenmaal beter inzicht als je er mee bezig bent en hebt ervaren hoe iets werkt. In plaats van dat dan ook maar op te pakken als meerwerk, laat je iets anders dat minder belangrijk is vallen.

Dit vind ik een echt goede uitleg over SCRUM (en waarom bepaalde aspecten zo werken):

[Hydra]

Alex) schreef op dinsdag 1 augustus 2017 @ 15:53:
Maar waarom?

Zodat je in kleine iteraties werkt. Het is beter om er na 2 weken achter te komen dat een feature niet aanslaat bij gebruikers dan na 6 maanden. En die korte feedback loop heb je alleen maar als je snel achter elkaar released.

[Jan_V]

Hydra schreef op dinsdag 1 augustus 2017 @ 17:39:
[...]


Zodat je in kleine iteraties werkt. Het is beter om er na 2 weken achter te komen dat een feature niet aanslaat bij gebruikers dan na 6 maanden. En die korte feedback loop heb je alleen maar als je snel achter elkaar released.

Dat ja!

Persoonlijk vind ik het ook fijn om snel er achter te kunnen komen of bepaalde functionaliteit ook echt gemaakt kan worden in een bepaalde tijd. Aan de hand daarvan kun je mogelijk bepalen of de roi behaald kan worden of dat de specifieke feature herzien moet worden, of misschien zelfs helemaal geschrapt.

[Edit]
Ik moet er wel bij zetten dat het alleen maar werkt als je een relatief stabiel/vast team hebt en er iets wordt gedaan met de historische cijfers. Als stories niet allemaal relatief van elkaar worden ingeschat wordt het lastig om er metrics uit te herleiden

[ Voor 16% gewijzigd door Jan_V op 01-08-2017 19:01 ]

[Alex)]

Hydra schreef op dinsdag 1 augustus 2017 @ 17:39:
[...]


Zodat je in kleine iteraties werkt. Het is beter om er na 2 weken achter te komen dat een feature niet aanslaat bij gebruikers dan na 6 maanden. En die korte feedback loop heb je alleen maar als je snel achter elkaar released.

Maar waarom zou je dan in vaste iteraties werken? Waarom niet de lengte van de tijd tussen releases laten afhangen van wat erin zit?

6 maanden tussen twee releases is misschien wat veel, maar waarom zouden het steeds vaste tijdsperiodes moeten zijn? Waarom niet bijvoorbeeld 5 weken werken aan een grote release, en daarna 2 weken aan een kleinere?

[ Voor 18% gewijzigd door Alex) op 01-08-2017 19:01 ]

[Merethil]

Alex) schreef op dinsdag 1 augustus 2017 @ 18:59:
[...]

Maar waarom zou je dan in vaste iteraties werken? Waarom niet de lengte van de tijd tussen releases laten afhangen van wat erin zit?

Omdat je je klant ook niet constant variërende wachttijden wil geven. Je kan dan aangeven: "dit is af over twee weken, de sprints daarna kan je functie 1, 2, 3, X, Y verwachten, in die volgorde"

Natuurlijk werkt dat nooit helemaal maar het maakt het makkelijker voor de testers (die hebben elke sprint wat te doen ipv 6 weken development afwachten en dan twee dagen kunnen testen), makkelijker voor de developers (je kan dan zeggen: "functie A is nog niet af, maar die zit in sprint X, momenteel doen we functie V") en het plant makkelijker voor zowel projectmanager als de klant.

Edit: dit is iig wat ik ervan gemerkt heb sinds we werken op deze manier, sprints zijn twee weken en bij ons merken we dat de velocity verhoogd is met pakweg 30% t.o.v. vóór we met sprints werkten. Ook omdat iedereen nu beter kan zien wat er nog te doen is en wat iedereen doet (we gebruiken Jira met z'n backlog/sprint views)

[ Voor 16% gewijzigd door Merethil op 01-08-2017 19:04 ]

[Jan_V]

Alex) schreef op dinsdag 1 augustus 2017 @ 18:59:
[...]

Maar waarom zou je dan in vaste iteraties werken? Waarom niet de lengte van de tijd tussen releases laten afhangen van wat erin zit?

6 maanden tussen twee releases is misschien wat veel, maar waarom zouden het steeds vaste tijdsperiodes moeten zijn? Waarom niet bijvoorbeeld 5 weken werken aan een grote release, en daarna 2 weken aan een kleinere?

Als dat goed/beter uit komt in het project lijkt me dat geen probleem. Er staat nergens dat het niet 'mag'. Alleen maar dat er met korte iteration wordt gewerkt.

Natuurlijk zijn er puristen die iets anders zeggen, maar we moeten natuurlijk wel pragmatisch blijven.
"People over process!" of natuurlijk "Projects over process!" 😉

[F.West98]

Wij werken meer met een soort rolling release systeem, omdat iets als scrum hier nooit zou werken. Het komt vaak (= bijna dagelijks) voor dat er van de één op de andere dag ineens iets moet veranderen wegens veranderende API's/wensen/eisen. Is vrij onvermijdelijk, we zijn van veel partijen afhankelijk.
Bevalt op zich wel goed, meerdere releases per dag. Als er iets breekt is de oorzaak snel gevonden, je eigen werk zit sneller in productie, etc. Nadeel is wel dat 'grotere' features lastiger te managen zijn. MR's moeten nu ook weer niet té groot worden, dus in de praktijk zit je dan wel vaak met een half-werkend systeem (wat we dan nog gewoon niet publiekelijk beschikbaar maken), dus alleen een back-end zonder bijbehorende front-end bijvoorbeeld.

Ik ben wel benieuwd of er meer mensen met zoiets werken?

[Caelorum]

F.West98 schreef op dinsdag 1 augustus 2017 @ 20:25:
[...] Ik ben wel benieuwd of er meer mensen met zoiets werken?

Ja, en met de kanttekening dat releases hier vrijwel niet geautomatiseerd zijn. We releasen min of meer elke dag ons hoofdproduct en van de pakweg 100 sites ligt het ergens tussen de maand en elke dag. Soms meerdere keren op 1 dag.
Grote projecten hier van meerdere weken komen hier steeds vaker voor als ondersteuning van de andere websites. (het meer modulair maken met bijv. microservices) Meestal betekent dat het gefaseerd wordt uitgerold in de producten en dat we beginnen met een 'klein' deel van de features van maar ~2 weken werk en worden de rest van de features ontwikkeld tijdens migratie, wanneer nodig.

*In de basis zijn we een dataverwerker en hebben we een groot aantal koppelingen met externe partijen en zij met ons. Daar verandert ook regelmatig iets in waardoor er van het ene op het andere moment iets stuk kan gaan. Vandaar dat we zo ad-hoc werken. Al werken we wel steeds verder toe naar het beheersbaar maken van deze uren.

[ Voor 17% gewijzigd door Caelorum op 01-08-2017 20:44 ]

[Hydra]

F.West98 schreef op dinsdag 1 augustus 2017 @ 20:25:
Wij werken meer met een soort rolling release systeem, omdat iets als scrum hier nooit zou werken. Het komt vaak (= bijna dagelijks) voor dat er van de één op de andere dag ineens iets moet veranderen wegens veranderende API's/wensen/eisen. Is vrij onvermijdelijk

Nee hoor. Gewoon slecht management. Het hele idee van agile is dat je in korte iteraties werkt zodat je snel kan reageren op veranderingen. Dat jullie geen proces hebben en dus volledig ad-hoc werken maakt het niet beter; dat is gewoon management dat geld aan 't weggooien is. Context switches zijn duur.

[RagingPenguin]

F.West98 schreef op dinsdag 1 augustus 2017 @ 20:25:
Wij werken meer met een soort rolling release systeem, omdat iets als scrum hier nooit zou werken. Het komt vaak (= bijna dagelijks) voor dat er van de één op de andere dag ineens iets moet veranderen wegens veranderende API's/wensen/eisen.

Maar stellen jullie partners jullie pas op de hoogte van een API wijziging als de de oude offline gaat? Meestal verzin je die dingen niet op de dag dat het live gaat en gaat de oude versie ook niet de deur uit op het moment dat de nieuwe live gaat. Voor mij klinkt dit alsof er nog best veel te halen valt op het gebied van communicatie met de opdrachtgevers/klanten.

[F.West98]

Hydra schreef op dinsdag 1 augustus 2017 @ 20:56:
[...]


Nee hoor. Gewoon slecht management. Het hele idee van agile is dat je in korte iteraties werkt zodat je snel kan reageren op veranderingen. Dat jullie geen proces hebben en dus volledig ad-hoc werken maakt het niet beter; dat is gewoon management dat geld aan 't weggooien is. Context switches zijn duur.

Het is wel onvermijdelijk in ons geval/onze markt. 3rd party APIs veranderen soms gewoon onaangekondigd van dag op dag. Hoe agile je dan ook bent, daar moet je binnen 1-2 dagen op reageren, anders kost het meer dan wij nu eventueel kwijt zijn aan minder efficiënt werken. En het gaat niet alleen om APIs maar ook andere dingen waar er out of the blue ineens iets veranderd wordt wat ook op onze code effect heeft.

RagingPenguin schreef op dinsdag 1 augustus 2017 @ 21:41:
[...]


Maar stellen jullie partners jullie pas op de hoogte van een API wijziging als de de oude offline gaat? Meestal verzin je die dingen niet op de dag dat het live gaat en gaat de oude versie ook niet de deur uit op het moment dat de nieuwe live gaat. Voor mij klinkt dit alsof er nog best veel te halen valt op het gebied van communicatie met de opdrachtgevers/klanten.

Ik ken het grote plaatje niet, maar ik heb vaak genoeg collega's horen klagen over communicatiegebrek vanuit de andere kant. Maargoed, details hierover ga/kan ik natuurlijk niet op een publiek forum zetten.

[Caelorum]

Hydra schreef op dinsdag 1 augustus 2017 @ 20:56:
[...]
Nee hoor. Gewoon slecht management. Het hele idee van agile is dat je in korte iteraties werkt zodat je snel kan reageren op veranderingen. Dat jullie geen proces hebben en dus volledig ad-hoc werken maakt het niet beter; dat is gewoon management dat geld aan 't weggooien is. Context switches zijn duur.

Vraag me af of context switches echt zo duur zijn. Het ligt denk ik heel erg aan de ontwikkelaar. Zo hebben wij hier minstens twee ontwikkelaars zitten die daar niet zo goed mee overweg kunnen. Die krijgen dan dus ook iets voorspelbare planningen met minder 'context switches'.

Overigens is agile werken natuurlijk ook maar een ding. Ze werken behoorlijk agile, alleen waarschijnlijk niet heel erg procesmatig. Wij werken iig toe naar een per week planning, waarbij zo'n 80% is ingepland. De andere 20% is gewoon beschikbaar voor het soort onnozele dingen die gewoon ineens gebeuren, maar gewoonweg teveel geld zouden kosten om te negeren. Dat zijn vaak, net zoals bij @F.West98 vermoed ik, zaken als API's die ineens veranderen zonder aankondiging (snelle bugfix aan de andere kant die zooi stuk maakt), slecht programmeerwerk uit het verleden die ineens stuk gaat in een nieuwe situatie (input verandert iets), werk dat uit sales komt zetten (jeweetwel.. dingen beloven die er nog niet zijn ^^)

Hoe dan ook @F.West98 ik herken het wel een beetje. Zaak is om een proces in kaart te brengen die er op gericht is zoveel mogelijk grip op het werk te krijgen. Dan kan je namelijk middellange termijnplanningen maken en kan je gaan denken aan productwijzigingen die ervoor zorgen dat je nog meer grip krijgt. Wellicht kom je dan ooit wel in de situatie dat nog maar 1 iemand in het bedrijf moet gaan springen om snelle codewijzingen door te voeren omdat er weer iets stuk is en kan de rest daadwerkelijk aan de langetermijnsvisie werken, want het klinkt nu alsof jullie weinig vooruit kunnen denken, laat staan er aan werken.

[F.West98]

Oh dan is dat verkeerd overgekomen
We werken zeker wel aan langere termijn dingen, de snelle bugfixes worden eigenlijk ook alleen maar door 2-3 programmeurs gedaan die het systeem goed kennen (van de inmiddels 12 programmeurs). Qua langere projecten wordt ook wel heel goed werk geleverd, laatst een compleet nieuw zoeksysteem opgeleverd en nu bezig met het opnieuw opbouwen van de admin interface. Alleen gaat dat wel in stappen: steeds MRs die het werk van een paar dagen representeren, en zo zorgen dat code langzamerhand wordt geïntroduceerd. Wat dat betreft net agile-achtig, maar dan kleiner. Het is meer dat die grotere projecten niet compleet losstaan van de rest van de code, de kleinere bugfixes en verbeteringen. Ze gaan gewoon direct mee in dezelfde code, dezelfde releases. Als iets af is kan het dus direct gebruikt worden.

Het kan zijn dat het niet optimaal is, maar er zijn genoeg mensen die nauwelijks wisselen tussen projecten en alleen focussen op één groter project.

[ShitHappens]

Om dan nog niets te zeggen over hoe er gecommuniceerd wordt, met externe veranderingen. Wij lezen XML files in van een andere partij, op verzoek van hen en gemeenschappelijke klanten, en aan die lay-out verandert wel eens wat. Hoe dat wordt gecommuniceerd? Een "deprecated per datum x" attribuut toevoegen aan velden Tuurlijk nog geheel geldig dus de parser gaat niet over de zeik ervan. Daar kom je dus ook alleen maar achter als er bij een klant iets misgaat bij 't uitlezen van dat bestand.
En zelfs niet communiceren dat van hetzelfde bestand een uitgebreidere versie beschikbaar komt, waar zij en wij per gebruiker meer geld aan kunnen verdienen.

[Hydra]

ShitHappens schreef op woensdag 2 augustus 2017 @ 00:53:
Om dan nog niets te zeggen over hoe er gecommuniceerd wordt, met externe veranderingen. Wij lezen XML files in van een andere partij, op verzoek van hen en gemeenschappelijke klanten, en aan die lay-out verandert wel eens wat. Hoe dat wordt gecommuniceerd? Een "deprecated per datum x" attribuut toevoegen aan velden

En die attributen kun je dan toch gewoon uitlezen in je software?

[Voutloos]

Ik denk dat die manier van notificeren niet afgesproken was. Dus dat het alleen werkt als je Glazen Bol Module correct voorspeld heeft dat op woensdag met oostenwind een verandering mogelijk op die manier aangekondigd wordt.

Enkel in de api zelf mededelen is een belabberd protocol, want je mixt t doel van de api met de processen er om heen. Surprise surprise, de clientcode om data te gebruiken mist de perfecte complete AI welke je developers op de hoogte brengt van aanstaande wijzigingen.

[ Voor 37% gewijzigd door Voutloos op 02-08-2017 07:52 ]

[Verwijderd]

orf schreef op maandag 31 juli 2017 @ 23:12:
hoeveel tijd mag een deploy kosten.

5 seconden ofzo, want wij hebben hier dus een CI server draaien die automatisch deployt bij een tag die gesignd is door mij.

[alienfruit]

Deploy duurt hier een halve dag

[Crazy D]

Merethil schreef op dinsdag 1 augustus 2017 @ 19:02:
Omdat je je klant ook niet constant variërende wachttijden wil geven. Je kan dan aangeven: "dit is af over twee weken, de sprints daarna kan je functie 1, 2, 3, X, Y verwachten, in die volgorde"

Maar met SCRUM weet je alleen dat over 2 weken iets af is, maar we weten nog niet precies wat... of maar een deel. De aansturing met concrete taken vind ik fijner dan een dik FO over de schutting krijgen en "over 4 maanden moet het af zijn", maar waar ik moeite mee heb is dat je niet een feature afbouwt in een sprint, maar dat je blokken functionaliteit (die uiteindelijk bij elkaar een feature maken) ontwikkeld. Het gaat er bij mij slecht in dat ik bv technisch wel kan factureren maar nog nergens die facturen kan zien. Of, wel factureren kan zien, maar alleen als ik ze hard in de db schiet want die factureren functie zelf gingen we niet halen deze sprint dus dat wordt de volgende sprint.

Ik zit nu op een traject waarbij we een bestaand systeem herbouwen, en tegelijkertijd a la scrum veranderingen n.a.v. gebruikerssessies mee moeten nemen. Tegelijkertijd is er wel een harde deadline gepasseerd op politieke keuzes ipv een fatsoenlijke planning.. En dan schat je in "halfnovember moet haalbaar zijn als er niks tegenzit", is de 1e vraag "verwacht je nog onvoorziene issues" en de 2e vraag (eigenlijk mededeling) "dus 10 november is do-able?" ...

[Mercatres]

alienfruit schreef op woensdag 2 augustus 2017 @ 12:12:
Deploy duurt hier een halve dag

Drietal minuten hier.
Build is meestal minuut of 7 à 9.

[Hydra]

Mercatres schreef op woensdag 2 augustus 2017 @ 13:10:
Drietal minuten hier.
Build is meestal minuut of 7 à 9.

Build is bij ons ook zo iets, maar die builds worden al gedaan op het moment dat een feature gemerged wordt. Een deploy van een service is een jenkins build starten. Paar seconden per service dus, en dan duurt het een minuut of 2 voordat ze in 't cluster staan.

[Mercatres]

Hydra schreef op woensdag 2 augustus 2017 @ 13:49:
[...]


Build is bij ons ook zo iets, maar die builds worden al gedaan op het moment dat een feature gemerged wordt. Een deploy van een service is een jenkins build starten. Paar seconden per service dus, en dan duurt het een minuut of 2 voordat ze in 't cluster staan.

Yea, hier ook. CI builds, en nightly builds voor develop branch.

[orf]

Verwijderd schreef op woensdag 2 augustus 2017 @ 11:59:
[...]


5 seconden ofzo, want wij hebben hier dus een CI server draaien die automatisch deployt bij een tag die gesignd is door mij.

Het was maar één van de onderdelen hè.
Bij ons is een deploy ook geautomatiseerd. In het project waar ik hier over mijn rant had, moet er een data-import gedaan worden na/tijdens deployment die de data ombouwt van een bak zooi tot een genormaliseerde database. Ook dat is geautomatiseerd, maar doet er wel meer dan 10 minuten over om volledig te runnen.

Ik heb over mijn probleem met de (in mijn ogen) veel te hoge inschatting inmiddels met het team een retrospective gehad. De stijl en toon van die bespreking was niet goed, maar inmiddels is wel boven water dat het team een lage velocity heeft omdat ze telkens punten oppakken waar geen stories voor zijn. Punten die naar boven zijn gekomen omdat de kwaliteit van eerdere opleveringen te laag was, technical dept en omdat de data van het vorige systeem zo verschrikkelijk is. Die punten oppakken zonder dat daar administratie voor is, zorgt ervoor dat het lijkt alsof de stories in de sprint veel te lang duren. Daar hebben we nu wat voorzorgsmaatregelen voor en het team schat de stories nu alsnog scherper in.

Wat vinden jullie van committen tot sprintgoal? Kunnen er tijdens de sprint gewoon stories afvallen omdat iets tegen zat, of zorg je er voor dat je je afgesproken sprint oplevert?

[Alex)]

Als je niet alles kunt opleveren is dat maar zo, dan verhuist het verhaal naar de volgende sprint.

Na een paar sprints zou je als team wel een gevoel moeten hebben hoeveel je nou echt kunt opleveren, en kun je de sprintinhoud daarop aanpassen.

Dan moet wel alles netjes in stories staan, ad-hoc dingen moeten tot een minimum worden beperkt.

[Hydra]

orf schreef op woensdag 2 augustus 2017 @ 18:09:
Wat vinden jullie van committen tot sprintgoal? Kunnen er tijdens de sprint gewoon stories afvallen omdat iets tegen zat, of zorg je er voor dat je je afgesproken sprint oplevert?

Een commitment betekent dat je denkt dat het haalbaar is, niet dat je over gaat werken om alles toch af te leveren ongeacht wat er gebeurd. Ik werd vandaag ook in een architectuurmeeting van 3 uur getrokken die vanochtend pas ingeschoten was. Heel nuttig, was blij dat ik erbij gehaald werd, maar 3 uur van je dag missen is best veel natuurlijk.

Dus ja; als ik een story niet afkrijg vanwege omstandigheden dan verhuist 'ie in principe door naar de volgende sprint. Ik heb er geen probleem mee af en toe ff flink door te knallen (zoals voor m'n vakantie, nog ff de dingen netjes achterlaten) maar ik ga niet structureel overwerken.

[Mercatres]

Alex) schreef op woensdag 2 augustus 2017 @ 19:29:
Als je niet alles kunt opleveren is dat maar zo, dan verhuist het verhaal naar de volgende sprint.

Na een paar sprints zou je als team wel een gevoel moeten hebben hoeveel je nou echt kunt opleveren, en kun je de sprintinhoud daarop aanpassen.

Dan moet wel alles netjes in stories staan, ad-hoc dingen moeten tot een minimum worden beperkt.

Woa, agile zegt wel dat de scope zonder al te veel problemen mag wijzigen. Als product owner bepaal je dan uiteraard hoe belangrijk dat nieuwe ticket/ die nieuwe story is, en welk ticket eruit moet. De velocity heb je meestal na een aantal sprints goed onder de knie (al kan het nooit kwaad om af en toe het inschatten van story points wat bij te sturen). Dan weet je als team wat je aan kan, en als je dan nog eens een goede sprint planning doet, weet business ook meteen wat ze wanneer kunnen verwachten.
^ Ideale situatie.

[cracking cloud]

Crazy D schreef op woensdag 2 augustus 2017 @ 13:02:
[...]

Ik zit nu op een traject waarbij we een bestaand systeem herbouwen, en tegelijkertijd a la scrum veranderingen n.a.v. gebruikerssessies mee moeten nemen. Tegelijkertijd is er wel een harde deadline gepasseerd op politieke keuzes ipv een fatsoenlijke planning.. En dan schat je in "halfnovember moet haalbaar zijn als er niks tegenzit", is de 1e vraag "verwacht je nog onvoorziene issues" en de 2e vraag (eigenlijk mededeling) "dus 10 november is do-able?" ...

Welkom in de echte wereld

[Alex)]

Mercatres schreef op woensdag 2 augustus 2017 @ 20:00:
[...]

Woa, agile zegt wel dat de scope zonder al te veel problemen mag wijzigen.

Ja uiteraard, maar dat gaat wel ten koste van andere dingen.

Als er tijdens een sprint voortdurend dingen blijven komen waardoor de scope steeds wijzigt ga je het niet voor elkaar krijgen om alles af te ronden. Dat kan prima zijn, maar dan moet het team daar vooraf beter op plannen door zich aan minder dingen te committeren.

[Antrax]

Crazy D schreef:
[...] En dan schat je in "halfnovember moet haalbaar zijn als er niks tegenzit", is de 1e vraag "verwacht je nog onvoorziene issues" en de 2e vraag (eigenlijk mededeling) "dus 10 november is do-able?" ...

Ahhhh de product owner/stake holder/cto zonder it ervaring (doorhalen wat niet van toepassing is) die totaal geen ervaring hebben met scrum planningen.

Brings back memories!

[Jegorex]

Het project waar ik in het verleden met SCRUM heb gewerkt had ook regelmatig release deadlines, maar dan werd er wel afgesproken dat dingen die niet af kwamen mee konden in een volgende release.
Soms kwamen er de laatste dagen nog een aantal bugs bij die niet voorzien waren, maar dat viel meestal ook wel op te lossen.

De echte harde releases werden altijd erg ruim ingepland, als in we planden een paar weken voor de release klaar te zijn met alle onderdelen die mee moesten en gingen vervolgens alvast werken aan een toekomstige release.

De meest stressvolle momenten voor mij waren de demo's waar we af en toe een minuut voor de demo nog een bug oplosten en vervolgens de demo gaven zonder te testen of het ook echt werkt.

[alienfruit]

Drietal minuten hier.
Build is meestal minuut of 7 à 9.

Haha, build duurt een paar minuten. Upload naar SAP Gateway 7-8 minuten (WebDAV is trage meuk). Vervolgens moet er vaak nog een manuele stap worden gedaan door support in Indië... Vooral bij deployments van DEV naar TEST etc.

[ Voor 8% gewijzigd door alienfruit op 03-08-2017 03:12 ]

[Crazy D]

Antrax schreef op woensdag 2 augustus 2017 @ 23:33:
Ahhhh de product owner/stake holder/cto zonder it ervaring (doorhalen wat niet van toepassing is) die totaal geen ervaring hebben met scrum planningen.

Brings back memories!

Nou ik ben er allang klaar mee. Doe mij maar weer gewoon ouderwets bouwen, we weten wat er moet komen dus rot op met je scrum. Laten we eerst bouwen wat er moet komen, en daarna features toevoegen. Zie de meerwaarde van scrum in dit traject niet.

Deployen? Ligt aan de grote van de dll's Ik ontwikkel vooral op Exact Synergy, compileren is zo gepiept plaatsen is kwestie van copy-paste. Alleen als je Synergy daarna start duurt het afhankelijk van de grote van je dll's, tussen de 10 en 1000 seconden voordat Synergy weer een beetje reageert....

Hoewel het traject waar ik nu mee bezig ben gebruiken we een tool om entiteiten te genereren, de deploy daarvan duurt probleemloos 5 minuten. Gelukkig is de koffie best lekker...

[Mercatres]

Ach, zolang dat deployment automatisch gebeurt is het allemaal niet zo erg

Wel jammer dat je zo een slechte ervaring hebt met SCRUM, als het goed toegepast wordt krijgt je team genoeg ademruimte om lekker te devven.

[Verwijderd]

orf schreef op woensdag 2 augustus 2017 @ 18:09:
[...]


Het was maar één van de onderdelen hè.
Bij ons is een deploy ook geautomatiseerd. In het project waar ik hier over mijn rant had, moet er een data-import gedaan worden na/tijdens deployment die de data ombouwt van een bak zooi tot een genormaliseerde database. Ook dat is geautomatiseerd, maar doet er wel meer dan 10 minuten over om volledig te runnen.

Ik heb over mijn probleem met de (in mijn ogen) veel te hoge inschatting inmiddels met het team een retrospective gehad. De stijl en toon van die bespreking was niet goed, maar inmiddels is wel boven water dat het team een lage velocity heeft omdat ze telkens punten oppakken waar geen stories voor zijn. Punten die naar boven zijn gekomen omdat de kwaliteit van eerdere opleveringen te laag was, technical dept en omdat de data van het vorige systeem zo verschrikkelijk is. Die punten oppakken zonder dat daar administratie voor is, zorgt ervoor dat het lijkt alsof de stories in de sprint veel te lang duren. Daar hebben we nu wat voorzorgsmaatregelen voor en het team schat de stories nu alsnog scherper in.

Wat vinden jullie van committen tot sprintgoal? Kunnen er tijdens de sprint gewoon stories afvallen omdat iets tegen zat, of zorg je er voor dat je je afgesproken sprint oplevert?

Dat weet ik. Met die 5 seconde had ik het alleen over de tijd dat een mens iets moet doen. Wij doen hier ook niet echt aan SCRUM.

[Crazy D]

orf schreef op woensdag 2 augustus 2017 @ 18:09:
Wat vinden jullie van committen tot sprintgoal? Kunnen er tijdens de sprint gewoon stories afvallen omdat iets tegen zat, of zorg je er voor dat je je afgesproken sprint oplevert?

Dat is toch juist wat scrum is? Je spreekt af welke punten er opgepakt worden in die sprint en een volgorde, en een deel kan opgelost worden, hopelijk alles, maar het kan zijn dat er dingen over blijven. Belangrijkste is dat datgeen wat er opgeleverd is, ook werkt...

[Tarkin]

Crazy D schreef op donderdag 3 augustus 2017 @ 08:30:
[...]

we weten wat er moet komen dus rot op met je scrum

Well there's your problem

Dat is de juist de hele reden waarom het scrum gebeuren veel gebruikt wordt. Over het algemeen weten ze niet wat ze willen.

En een jaar preanalyse om er dan achter te komen dat je product al verouderd is en je al je analyse overboord kan smijten.


op de vraag om zaken uit de sprint te halen. Soms kan het niet anders maar het is niet de bedoeling. Er kan natuurlijk altijd een productiebrand uitbreken die je moet oplossen. Maar dit zijn uitzonderlijke gevallen.
Als de business/PO/PM elke sprint komt vragen om toch zaken eruit te halen en andere erin te duwen, dan ben je verkeerd bezig. Kheb ook nog in zo'n omgeving gewerkt. De sprint was ingevuld de dag dat de release naar PRD ging. Dus je had nooit zekerheid wat er allemaal moest gedaan worden. geen werkbare situatie

Mercatres schreef op woensdag 2 augustus 2017 @ 20:00:
[...]

Woa, agile zegt wel dat de scope zonder al te veel problemen mag wijzigen. Als product owner bepaal je dan uiteraard hoe belangrijk dat nieuwe ticket/ die nieuwe story is, en welk ticket eruit moet. De velocity heb je meestal na een aantal sprints goed onder de knie (al kan het nooit kwaad om af en toe het inschatten van story points wat bij te sturen). Dan weet je als team wat je aan kan, en als je dan nog eens een goede sprint planning doet, weet business ook meteen wat ze wanneer kunnen verwachten.
^ Ideale situatie.

Agile wel, Scrum niet. Bij Scrum commit je om in tijd x (max 1 maand) features y-z op te leveren. Eenmaal die commitment gemaakt is wordt er "normaal gezien" niet meer afgeweken van de sprintplanning. Je kan wel x aantal stories achter de hand houden voor mocht het sneller als normaal gedaan zijn maar mits een goede velocity en gerodeerd team ga je dat niet zovele hebben.

Het kan wel voorvallen dat bepaalde stories/epic niet meer relevant zijn in het grotere geheel (business context van het bedrijf veranderd bv) maar dan is het beter om de huidige sprint te stoppen, retro en sprint review te houden en dan een nieuwe commitment voor een sprint te maken (misschien een sprint die de resterende tijd van de vorige sprint overneemt, of een heel nieuwe maakt niet uit). Op die manier is het ook heel zichtbaar naar de buitenwereld dat jullie abrupt zijn moeten stoppen.

Let wel, dit zijn zeer uitzonderlijke acties, die misschien eens om de zoveel jaar zouden voorvallen. Het hele doel van Scrum is om rust en voorspelbaarheid in het developen te krijgen. Niet de cowboytaferelen zoals je die overal ziet en waar F.West hierover bericht. Als je in increments van 2 weken werkt met op het einde van die 2 weken een release dan ben je in 99% van de tijd snel zat.

[ Voor 49% gewijzigd door Tarkin op 03-08-2017 12:43 ]

[Hydra]

Crazy D schreef op donderdag 3 augustus 2017 @ 08:30:
Nou ik ben er allang klaar mee.

Logisch. Maar dat heeft niks met Scrum te maken maar met je management. Scrum komt als het goed is in plaats van bestaande processen en je zou dus minder micro management moeten hebben. Het probleem is dat veel managers denken dat ze niet hoeven te veranderen, en dan krijg je dus nare hybrides waar Scrum bovenop bestaande processes geplakt worden. Voeg daaraan toe mensen die eigenlijk niks van Scrum en software ontwikkelen snappen en je verzandt in sprints die gelden als deadlines, standups van een uur, meer meetings en pissige mensen omdat ze niks afkrijgen en daarom op hun donder krijgen.

Het zijn genoeg bedrijven die aan kunnen tonen dat Scrum heus wel werkt. Maar die hebben goed management en goeie mensen.

[Crazy D]

Tarkin schreef op donderdag 3 augustus 2017 @ 12:32:
Well there's your problem

Dat is de juist de hele reden waarom het scrum gebeuren veel gebruikt wordt. Over het algemeen weten ze niet wat ze willen.

En een jaar preanalyse om er dan achter te komen dat je product al verouderd is en je al je analyse overboord kan smijten.

Dat laatste ben ik het mee eens, maar als je een bestaand systeem moet verbouwen weet je precies wat er moet komen. Dan is de gedachte van scrum in die zin zinloos, want eerder dan live gaan wanneer alles erin zit lukt niet want anders kunnen ze hun werk niet doen.

Bij nieuwbouw of bij aanvulling van bestaande systemen zie ik het nut er wel van in, al zie ik in mijn ervaring dan ook dat dat niet via scrum gebeurt, omdat ook dan de klant toch pas live wil met die feature wanneer die in zijn geheel gereed is.

Overigens heb ik de afgelopen jaren wel veel tussenvormen gebruikt: wel de hoofdpunten benoemen wat er allemaal moet gaan komen, maar op kortere termijn pas de details uitwerken van een aantal onderdelen, en daarmee aan de slag gaan.

[Tarkin]

Hydra schreef op donderdag 3 augustus 2017 @ 13:05:
[...]


Logisch. Maar dat heeft niks met Scrum te maken maar met je management. Scrum komt als het goed is in plaats van bestaande processen en je zou dus minder micro management moeten hebben. Het probleem is dat veel managers denken dat ze niet hoeven te veranderen, en dan krijg je dus nare hybrides waar Scrum bovenop bestaande processes geplakt worden. Voeg daaraan toe mensen die eigenlijk niks van Scrum en software ontwikkelen snappen en je verzandt in sprints die gelden als deadlines, standups van een uur, meer meetings en pissige mensen omdat ze niks afkrijgen en daarom op hun donder krijgen.

Het zijn genoeg bedrijven die aan kunnen tonen dat Scrum heus wel werkt. Maar die hebben goed management en goeie mensen.

Meta-cast heeft hier een interessante episode over: http://www.meta-cast.com/...sponsible-leadership.html Daarin gaat het dat een bedrijf agile wilt doorvoeren, betaalt gedurende een paar jaar miljoenen aan consultants om dat te bewerkstelligen en op het einde blijkt het een bust te zijn. Je moet niet alleen je volk coachen om naar een agile omgeving te gaan. Ook de top moet mee en daar wouden/konden de consultants hun niet aan wagen (don't bite the hand that feeds you)

Crazy D schreef op donderdag 3 augustus 2017 @ 13:21:
[...]

Dat laatste ben ik het mee eens, maar als je een bestaand systeem moet verbouwen weet je precies wat er moet komen. Dan is de gedachte van scrum in die zin zinloos, want eerder dan live gaan wanneer alles erin zit lukt niet want anders kunnen ze hun werk niet doen.

Bij nieuwbouw of bij aanvulling van bestaande systemen zie ik het nut er wel van in, al zie ik in mijn ervaring dan ook dat dat niet via scrum gebeurt, omdat ook dan de klant toch pas live wil met die feature wanneer die in zijn geheel gereed is.

Overigens heb ik de afgelopen jaren wel veel tussenvormen gebruikt: wel de hoofdpunten benoemen wat er allemaal moet gaan komen, maar op kortere termijn pas de details uitwerken van een aantal onderdelen, en daarmee aan de slag gaan.

Eens en niet eens. Soms kun je dat ook in blokken opdelen zodat ze sneller de change zien en er sneller voordeel van halen. Langs de andere kant zijn we hier nu ook een stuk aan het herschrijven waar je niet anders kan als het in 1 blok opleveren. Dus het ik weet dat het niet zo zwart wit is. Maar zoals hierboven beschreven, jouw ervaringen zijn er meer door gebrekkig management, niet door de methodologie die zwak is

[ Voor 32% gewijzigd door Tarkin op 03-08-2017 13:25 ]

[DevWouter]

Crazy D schreef op donderdag 3 augustus 2017 @ 13:21:
[...]

Dat laatste ben ik het mee eens, maar als je een bestaand systeem moet verbouwen weet je precies wat er moet komen. Dan is de gedachte van scrum in die zin zinloos, want eerder dan live gaan wanneer alles erin zit lukt niet want anders kunnen ze hun werk niet doen.

Bij nieuwbouw of bij aanvulling van bestaande systemen zie ik het nut er wel van in, al zie ik in mijn ervaring dan ook dat dat niet via scrum gebeurt, omdat ook dan de klant toch pas live wil met die feature wanneer die in zijn geheel gereed is.

Overigens heb ik de afgelopen jaren wel veel tussenvormen gebruikt: wel de hoofdpunten benoemen wat er allemaal moet gaan komen, maar op kortere termijn pas de details uitwerken van een aantal onderdelen, en daarmee aan de slag gaan.

Scrum/Sprint/Kanban/Agile/waterfall/ExtermeProgramming/smaak-van-de-dag zijn of bevatten methodieken om te plannen en om de planning te bewaken. Als jij een keer ziek ben of pech heb (stroomuitval) dan moet de planning en de bezetting van het team gecorrigeerd worden.

Deze methodieken (en vele anderen) zijn dan ook eerder hulp methodes om je werk proces te optimaliseren en verwachtingen van de klant te beheren op een gestructureerde manier.

Overigens hebben alle methodieken vaak als regel dat aan elke stap niet meer tijd besteed hoeft te worden dan nodig is. Ben je de enige ontwikkelaar dan kan je een standup in twee tellen afronden.

Overigens doen de meeste bedrijven de meeste stappen in Scrum/Sprint/ben-te-lui-om-de-rest-uit-te-schrijven wel, maar niet gestructureerd. Dit werkt, maar is vaak (maar ook niet altijd) niet zo effectief als volledige gestructureerd werken.

Overigens kan het ook heel goed dat een bedrijf zijn eigen systeem ontwikkelt. Het sleutelwoord blijft echter structuur.

[alienfruit]

Mag allemaal schermen over doen omdat mijn collega's willen dat ik geen externe library gebruik. Ze hebben liever dat ik de wiel opnieuw uitvind. De externe library zou zo maar niet meer worden ondersteunt door de ontwikkelaars. Alleen maar omdat één collega een custom operator niet snapte. Sigh.

[Jan_V]

alienfruit schreef op vrijdag 4 augustus 2017 @ 10:59:
Mag allemaal schermen over doen omdat mijn collega's willen dat ik geen externe library gebruik. Ze hebben liever dat ik de wiel opnieuw uitvind. De externe library zou zo maar niet meer worden ondersteunt door de ontwikkelaars. Alleen maar omdat één collega een custom operator niet snapte. Sigh.

Decompilen van library en die sources inchecken. Solved!

[alienfruit]

Het is een CocoaPod en het is gewoon op Github met MIT licentie. Ik zie niet wat het verschil is tussen een externe library gebruiken of zelf één in elkaar prutsen. Als ik weg ga bij dit bedrijf of van dit project dat hebben ze in theorie toch hetzelfde probleem?

[Merethil]

alienfruit schreef op vrijdag 4 augustus 2017 @ 12:10:
Het is een CocoaPod en het is gewoon op Github met MIT licentie. Ik zie niet wat het verschil is tussen een externe library gebruiken of zelf één in elkaar prutsen. Als ik weg ga bij dit bedrijf of van dit project dat hebben ze in theorie toch hetzelfde probleem?

Juist nu hebben ze dat probleem als je weg zou gaan idd. Wij hadden één SAP-developer die heel veel kennis van het deel van SAP waar wij mee interfacen had. Die is nu weg en nu hebben we dus gewoon een dik probleem.

Als je die library op Github gebruikt heb je naast de oorspronkelijke developers altijd nog de kans dat anderen er aan meewerken, dus is dat juist veiliger maar tja... Opensource == crap volgens management (iig bij ons; we mogen alleen gebruikmaken van software en leveranciers die beursgenoteerd zijn )

[Crazy D]

Merethil schreef op vrijdag 4 augustus 2017 @ 12:50:
Als je die library op Github gebruikt heb je naast de oorspronkelijke developers altijd nog de kans dat anderen er aan meewerken, dus is dat juist veiliger maar tja... Opensource == crap volgens management (iig bij ons; we mogen alleen gebruikmaken van software en leveranciers die beursgenoteerd zijn )

Ik heb ooit een cursus over product management gevolgd. 1 van de aspecten daarbij/daarin is het gebruik van libraries van externe partijen.

1 van de verhalen die we te horen kregen, was het verhaal waarbij een bedrijf overgenomen zou gaan worden door een Amerikaans bedrijf. Kwam een check van de sources, en het bleek dat er bepaalde code gebruikt werd waarvoor het bedrijf de rechten niet had... Bedrijf had de keuze om in 24 u tijd de code aan te passen zodat die libs niet meer gebruikt werden en anders was de deal voorbij.

Ik bedoel maar te zeggen dat er soms andere belangen achter zitten dan dat je op de werkvloer mee krijgt (even los van het potentieel issue dat als je de licentie niet goed controleert je opeens sowieso onjuist gebruik zou kunnen maken met leuke claims als gevolg ongeacht of je wel of geen overname kandidaat bent). Als ontwikkelaar ben je soms snel geneigd even een Library te gebruiken zonder licenties te controleren. En dat kan verstrekkende gevolgen hebben.

(al is "alleen beursgenoteerde bedrijven" als criterium dan wel weer een extreem ander uiterste)

[alienfruit]

Ja, dat snap ik wel. Maar het ging hier om een library die actief beheerd wordt en de `master`-branch door één van de Top 5 iOS social apps wordt gebruikt. Deze library leeft waarschijnlijk langer dan het product waar we zelf aan werken en ik ben zelf ook een (beginnende) contributor van de library op Github.

[Merethil]

Crazy D schreef op vrijdag 4 augustus 2017 @ 13:04:
[...]

Ik heb ooit een cursus over product management gevolgd. 1 van de aspecten daarbij/daarin is het gebruik van libraries van externe partijen.

1 van de verhalen die we te horen kregen, was het verhaal waarbij een bedrijf overgenomen zou gaan worden door een Amerikaans bedrijf. Kwam een check van de sources, en het bleek dat er bepaalde code gebruikt werd waarvoor het bedrijf de rechten niet had... Bedrijf had de keuze om in 24 u tijd de code aan te passen zodat die libs niet meer gebruikt werden en anders was de deal voorbij.

Ik bedoel maar te zeggen dat er soms andere belangen achter zitten dan dat je op de werkvloer mee krijgt (even los van het potentieel issue dat als je de licentie niet goed controleert je opeens sowieso onjuist gebruik zou kunnen maken met leuke claims als gevolg ongeacht of je wel of geen overname kandidaat bent). Als ontwikkelaar ben je soms snel geneigd even een Library te gebruiken zonder licenties te controleren. En dat kan verstrekkende gevolgen hebben.

(al is "alleen beursgenoteerde bedrijven" als criterium dan wel weer een extreem ander uiterste)

Ik kan je verzekeren dat dat niet de reden is, het gaat echt om het aanzien. Het bedrijf waar ik voor werk heeft genoeg management dat totaal niets weet van technologie, maar omdat het zelf een beursgenoteerd bedrijf is willen ze ook kunnen zeggen dat alles wat we gebruiken ook beursgenoteerd (dus gewoon duur) is.
Zo gebruiken we SAP en JDE als CRM/voorraadbeheer/inkoop etc, maar voor onze webshops gebruiken we Sitecore, want duur en dus goed. En voor tussen die twee (aangezien SAP niet kan communiceren met Sitecore en vice versa) hadden we ooit Javacaps, want SUN/Oracle, maar toen support ophield en we zelf wat wilden bouwen werd uiteindelijk besloten Software AG's webMethods te gebruiken, want beursgenoteerd. En reteduur.

Soms een beetje jammer, maar aan de andere kant; ik leer een hoop systemen te gebruiken

[Verwijderd]

Merethil schreef op vrijdag 4 augustus 2017 @ 14:37:
[...]


Ik kan je verzekeren dat dat niet de reden is, het gaat echt om het aanzien. Het bedrijf waar ik voor werk heeft genoeg management dat totaal niets weet van technologie, maar omdat het zelf een beursgenoteerd bedrijf is willen ze ook kunnen zeggen dat alles wat we gebruiken ook beursgenoteerd (dus gewoon duur) is.
Zo gebruiken we SAP en JDE als CRM/voorraadbeheer/inkoop etc, maar voor onze webshops gebruiken we Sitecore, want duur en dus goed. En voor tussen die twee (aangezien SAP niet kan communiceren met Sitecore en vice versa) hadden we ooit Javacaps, want SUN/Oracle, maar toen support ophield en we zelf wat wilden bouwen werd uiteindelijk besloten Software AG's webMethods te gebruiken, want beursgenoteerd. En reteduur.

Soms een beetje jammer, maar aan de andere kant; ik leer een hoop systemen te gebruiken

Wil je die systemen wel leren gebruiken?

[Merethil]

Verwijderd schreef op vrijdag 4 augustus 2017 @ 15:18:
[...]


Wil je die systemen wel leren gebruiken?

...

[Verwijderd]

Merethil schreef op vrijdag 4 augustus 2017 @ 15:25:
[...]


...

Hebben ze geen Unicode support? …

[Hydra]

Crazy D schreef op vrijdag 4 augustus 2017 @ 13:04:
1 van de verhalen die we te horen kregen, was het verhaal waarbij een bedrijf overgenomen zou gaan worden door een Amerikaans bedrijf. Kwam een check van de sources, en het bleek dat er bepaalde code gebruikt werd waarvoor het bedrijf de rechten niet had... Bedrijf had de keuze om in 24 u tijd de code aan te passen zodat die libs niet meer gebruikt werden en anders was de deal voorbij.

En da's natuurlijk gewoon onzin. Als je op let op de licenties (eigenlijk alles behalve GPL) heb je nooit problemen met code waarvan je de rechten niet hebt. Dus hier ging het eigenlijk per definitie niet over open source. Dat verhaal is gewoon verzonnen.

Daarnaast; ik heb in de 15 ofzo jaar dat ik als dev werk veel meer problemen met closed source producten gehad dan met open source. In het geval van OS kun je altijd zien wat er echt aan de hand is en eventueel het zelf patchen. Open source is daarnaast eerlijke software; de meeste OS projecten zitten helemaal niet op vendor lock-in te wachten. Veel closed source meuk is met opzet lastig te gebruiken zodat de desbetreffende bedrijven ook nog eens consulting kunnen verkopen.

Merethil schreef op vrijdag 4 augustus 2017 @ 14:37:
Ik kan je verzekeren dat dat niet de reden is, het gaat echt om het aanzien.

Bwise in Rosmalen toevallig?

[ Voor 8% gewijzigd door Hydra op 04-08-2017 16:12 ]

[Merethil]

Hydra schreef op vrijdag 4 augustus 2017 @ 16:11:
[...]


En da's natuurlijk gewoon onzin. Als je op let op de licenties (eigenlijk alles behalve GPL) heb je nooit problemen met code waarvan je de rechten niet hebt. Dus hier ging het eigenlijk per definitie niet over open source. Dat verhaal is gewoon verzonnen.

Daarnaast; ik heb in de 15 ofzo jaar dat ik als dev werk veel meer problemen met closed source producten gehad dan met open source. In het geval van OS kun je altijd zien wat er echt aan de hand is en eventueel het zelf patchen. Open source is daarnaast eerlijke software; de meeste OS projecten zitten helemaal niet op vendor lock-in te wachten. Veel closed source meuk is met opzet lastig te gebruiken zodat de desbetreffende bedrijven ook nog eens consulting kunnen verkopen.


[...]


Bwise in Rosmalen toevallig?

Nope, ander bedrijf. Maar er zullen een hoop "Enterprise-niveau" bedrijven zijn die deze denkwijze aanhouden gok ik...

[Crazy D]

Hydra schreef op vrijdag 4 augustus 2017 @ 16:11:
En da's natuurlijk gewoon onzin. Als je op let op de licenties (eigenlijk alles behalve GPL) heb je nooit problemen met code waarvan je de rechten niet hebt. Dus hier ging het eigenlijk per definitie niet over open source. Dat verhaal is gewoon verzonnen.

Je zet daar 1 zin in: als je let op de licenties. Dat is precies de kern van waar het om ging. Hoeveel dev's lezen de licenties door als ze even iets nodig hebben? Met name in die gevallen dat er tijdsdruk is, en men niet het idee heeft dat dat stukje software ook echt lang gebruikt zal worden (klusje dat vaak begint als een spoedje wat uiteindelijk een belangrijke feature is geworden). Ook met open source kun je een valkuil hebben (bv 1 van de licenties dat als je die code mee-compiled in jouw applicatie, jouw applicatie ook open source moet zijn). Het was dan ook vooral een waarschuwing dat je niet zomaar van alles en nog wat moet gaan gebruiken in je applicaties als je de impact niet kunt inschatten, en 1 van die dingen is dus het lezen van de licenties.

Daarnaast; ik heb in de 15 ofzo jaar dat ik als dev werk veel meer problemen met closed source producten gehad dan met open source. In het geval van OS kun je altijd zien wat er echt aan de hand is en eventueel het zelf patchen. Open source is daarnaast eerlijke software; de meeste OS projecten zitten helemaal niet op vendor lock-in te wachten. Veel closed source meuk is met opzet lastig te gebruiken zodat de desbetreffende bedrijven ook nog eens consulting kunnen verkopen.

Ik begin verder nergens over open of closed source.

[Hydra]

Crazy D schreef op vrijdag 4 augustus 2017 @ 21:10:
Je zet daar 1 zin in: als je let op de licenties. Dat is precies de kern van waar het om ging. Hoeveel dev's lezen de licenties door als ze even iets nodig hebben?

Als je dat niet doet ben je knap stom bezig. Da's gewoon een onderdeel van je werk.

[SideSplitter]

[Shameless plug]Vandaag maar even games van Ludum Dare 39 raten. Onze game, voor de belangstellenden O-)[/Shameless plug]

[Ryur]

Hydra schreef op zaterdag 5 augustus 2017 @ 00:59:
[...]


Als je dat niet doet ben je knap stom bezig. Da's gewoon een onderdeel van je werk.

Eens!
Ik heb er wel eens ruzie met ex-collega's om gekregen. Wilde ik dus de code niet goedkeuren qua review omdat de licenties niet klopte.
Zij zo "wat maakt het uit?".

Ik wil niet mijn baan verliezen omdat een collega niet wilt/kan lezen.
(Een van de vele reden dat ik daar weg ben, maar toch)

[Jantje2000]

Na ongeveer 2 uur puzzelen met de Maps API kom ik er achter dat de variable geen variable is, maar een functie is. Dus een () erachter lost het probleem op.

[WernerL]

Jantje2000 schreef op zaterdag 5 augustus 2017 @ 21:38:
Na ongeveer 2 uur puzzelen met de Maps API kom ik er achter dat de variable geen variable is, maar een functie is. Dus een () erachter lost het probleem op.

Typescript
* WernerL schrijft geen plain javascript meer sinds hij typescript heeft ontdekt. Een typesystem is gewoon erg fijn om te hebben. Dan kun je in je IDE (vscode in mijn geval) al zien wat voor type een property is.

[Verwijderd]

WernerL schreef op zaterdag 5 augustus 2017 @ 21:54:
[...]


Typescript
* WernerL schrijft geen plain javascript meer sinds hij typescript heeft ontdekt. Een typesystem is gewoon erg fijn om te hebben. Dan kun je in je IDE (vscode in mijn geval) al zien wat voor type een property is.

TypeScript is wel fijn inderdaad.

/me heeft de hele code base omgegooid naar TypeScript toen ik het ontdekte. Daardoor heb ik ook een paar bugs gevonden en gefixt in de parser van ons binair formaat.

Btw VSCode is geen IDE, maar een editor.

[Firesphere]

Ooooh, TypeScript! Momenteel met een Java app bezig die ik moet porten naar iOS. TypeScript conversion was best awesome en scheelt me zo veel tijd.

[Scott]

alienfruit schreef op vrijdag 4 augustus 2017 @ 13:20:
Ja, dat snap ik wel. Maar het ging hier om een library die actief beheerd wordt en de `master`-branch door één van de Top 5 iOS social apps wordt gebruikt. Deze library leeft waarschijnlijk langer dan het product waar we zelf aan werken en ik ben zelf ook een (beginnende) contributor van de library op Github.

Wij hebben ook een heel strict "geen libraries" beleid waar ik persoonlijk 100% achter sta. Dat wil niet zeggen dat we helemaal geen libraries gebruiken, maar de lat ligt heel hoog. Het komt uiteindelijk neer op code importeren die niet door ons nagekeken is, van iemand die niet voor ons werkt en wiens kwaliteiten dus onbekend zijn.

De paar libraries die wij hebben (90% geforceerd door management) crashen om de haverklap, hebben geen enkel idee hoe threading werkt en in het algemeen doen ze veel meer dan wat je daadwerkelijk nodig hebt.

Onze omstandigheden zijn hoogstwaarschijnlijk anders dan bij jullie (20 iOS-ontwikkelaars, miljoenen gebruikers, 100% Swift, zat geld om zelf wat te schrijven, weinig externe druk), maar toch iets om over na te denken.

[alienfruit]

Nou ja, ik gebruik liever een externe library die met automated tests, unit tests komt dan een library die door een collega is geschreven. Zonder dit alles. Om nou zo'n library weg te smijten die in toekomst op veel meer plekken kan worden gebruikt en de code stukken leesbaarder maakt omdat het niet binnenhuis geschreven is? En waarom zou ik een week willen besteden aan het schrijven van zo'n library als dit alles in twee weken af moet zijn?

Maar ik moet toegeven dat ik geïrriteerd ben. Niemand zei dat je geen externe libraries mocht gebruiken, verder is het bij de eerste PR aangenomen. Toen was het geen probleem en nu mag het plotseling niet en nu kan ik dus een helemaal dingen opnieuw implementeren. Zonde van de tijd. Zelfs als ik zelf contributor ben van de library mag het niet.

[ Voor 28% gewijzigd door alienfruit op 07-08-2017 06:11 ]

[DevWouter]

gm1999 schreef op zaterdag 5 augustus 2017 @ 15:39:
[Shameless plug]Vandaag maar even games van Ludum Dare 39 raten. Onze game, voor de belangstellenden O-)\[/Shameless plug]

Mooi gebruik van het thema
Waarschijnlijk doe ik de volgende keer ook weer mee (heb alleen een hekel aan het raten, kost mij te veel tijd).

alienfruit schreef op maandag 7 augustus 2017 @ 06:06:
Nou ja, ik gebruik liever een externe library die met automated tests, unit tests komt dan een library die door een collega is geschreven. Zonder dit alles. Om nou zo'n library weg te smijten die in toekomst op veel meer plekken kan worden gebruikt en de code stukken leesbaarder maakt omdat het niet binnenhuis geschreven is? En waarom zou ik een week willen besteden aan het schrijven van zo'n library als dit alles in twee weken af moet zijn?

Maar ik moet toegeven dat ik geïrriteerd ben. Niemand zei dat je geen externe libraries mocht gebruiken, verder is het bij de eerste PR aangenomen. Toen was het geen probleem en nu mag het plotseling niet en nu kan ik dus een helemaal dingen opnieuw implementeren. Zonde van de tijd. Zelfs als ik zelf contributor ben van de library mag het niet.

Dat het de eerste keer doorheen is gekomen geeft je natuurlijk geen vrijbrief om het nog één keer te doen. Maar curieus is het dat het weg vallen van support een reden is. Dit heb je met elk onderdeel, zelfs intern. Als een expert binnen jullie team vertrekt heb je exact hetzelfde probleem.

Nu vind ik het zelf altijd leuk om te kijken of ik een populaire library zelf kan implementeren, maar alleen als het een keuze is (want vaak weten de ontwikkelaars van de lib het beter ).

Misschien dat er iets meer is (ze willen geen library explosie?), maar persoonlijk zou ik toch op onderzoek uit gaan.

[Styxxy]

Upgrade naar Visual Studio 2017 .

Solution openen en target platform wijziging om te builden:

[DevWouter]

Styxxy schreef op maandag 7 augustus 2017 @ 11:19:
Upgrade naar Visual Studio 2017 .

Solution openen en target platform wijziging om te builden:
[afbeelding]

Misschien de virusscanner? Tijdens de installatie moest ik Trend Micro Security verschillende folders laten excluden omdat hij anders de bestanden gijzelde terwijl hij ze ging checken. (We hebben een MSDN subscriptie).

Maar die "Unknown errors" zie ik ook regelmatig voorbij komen (vaak bij TFS projecten). Vind dat wel een grote faal wanneer een product bedoeld voor ontwikkelaars dit doet.

[alienfruit]

Dat het de eerste keer doorheen is gekomen geeft je natuurlijk geen vrijbrief om het nog één keer te doen. Maar curieus is het dat het weg vallen van support een reden is. Dit heb je met elk onderdeel, zelfs intern. Als een expert binnen jullie team vertrekt heb je exact hetzelfde probleem.

Was het maar dat ik een nieuwe library toevoegde. Het zat er al vanaf mijn eerst PR in voor dit onderdeel. Drie verschillende externe Autolayout libraries vinden ze dan weer geen probleem

Nu vind ik het zelf altijd leuk om te kijken of ik een populaire library zelf kan implementeren, maar alleen als het een keuze is (want vaak weten de ontwikkelaars van de lib het beter ).

Misschien dat er iets meer is (ze willen geen library explosie?), maar persoonlijk zou ik toch op onderzoek uit gaan.

Ja, en de library heeft meer gebruikers zowel als eindgebruikers en ook meer programmeurs dus gezamenlijk halen die ook meerdere problem uit de library. Terwijl als je het zelf

[SideSplitter]

DevWouter schreef op maandag 7 augustus 2017 @ 11:19:
[...]


Mooi gebruik van het thema
Waarschijnlijk doe ik de volgende keer ook weer mee (heb alleen een hekel aan het raten, kost mij te veel tijd).

Het raten kost inderdaad veel tijd. Sowieso is het beetje een dilemma: De meeste games die nog ratings nodig hebben zijn vrij matig, en de daadwerkelijk leuke spellen hebben al 100+ ratings

[Sebazzz]

Styxxy schreef op maandag 7 augustus 2017 @ 11:19:
Solution openen en target platform wijziging om te builden:
[afbeelding]

Meestal betekent dat een geheugenallocatie niet gelukt is.

[RayNbow]

Kan geen command (of PowerShell) venster openen op deze thin client... Win+R werkt ook niet...

...kan wel via Word/VBA ping -t ... starten om te kijken of een bepaalde host al up is om naar te RDPen.

[Jan_V]

RayNbow schreef op maandag 7 augustus 2017 @ 14:33:
Kan geen command (of PowerShell) venster openen op deze thin client... Win+R werkt ook niet...

...kan wel via Word/VBA ping -t ... starten om te kijken of een bepaalde host al up is om naar te RDPen.

Al geprobeerd om via Paint toegang te krijgen?

https://infamoussyn.com/2...rompt-access-via-mspaint/

[RayNbow]

Jan_V schreef op maandag 7 augustus 2017 @ 15:04:
[...]

Al geprobeerd om via Paint toegang te krijgen?

https://infamoussyn.com/2...rompt-access-via-mspaint/

"This user (<user>) is blocked from executing unknown or restricted content (CMD.BAT). If you feel you should be allowed to execute this program, please contact the helpdesk on <tel>."

[Hipska]

Ik snap het speciale aan die msPaint "hack" niet. Je moet dan nog de file renamen via explorer en van daaruit runnen. Je kan toch evengoed een .bat file maken met notepad?

[Damic]

Hipska schreef op maandag 7 augustus 2017 @ 16:49:
Ik snap het speciale aan die msPaint "hack" niet. Je moet dan nog de file renamen via explorer en van daaruit runnen. Je kan toch evengoed een .bat file maken met notepad?

Je doet toch save as en vult zelf een extensie in, of is dat al opgelost in paint

[Styxxy]

DevWouter schreef op maandag 7 augustus 2017 @ 11:27:
[...]

Misschien de virusscanner? Tijdens de installatie moest ik Trend Micro Security verschillende folders laten excluden omdat hij anders de bestanden gijzelde terwijl hij ze ging checken. (We hebben een MSDN subscriptie).

Maar die "Unknown errors" zie ik ook regelmatig voorbij komen (vaak bij TFS projecten). Vind dat wel een grote faal wanneer een product bedoeld voor ontwikkelaars dit doet.

Sebazzz schreef op maandag 7 augustus 2017 @ 13:54:
[...]

Meestal betekent dat een geheugenallocatie niet gelukt is.

Heb in de event viewer een exception terug gevonden. Blijkbaar bij het bepalen van output pad van een project. Stacktrace zegt iets van "ParseLegacyProject". Zit 'em dus ergens in een CSPROJ of VBPROJ. Maar nog geen idee hetwelk, is een grote solution van 170 projects... En in VS 2013 werkt het wel.

Ach ja, het is mijn taak ook om het op te lossen (ik doe grotendeels van ons Visual Studio en TFS 2013 -> 2017 project) .

Ondertussen ook al een bugreport bij Microsoft binnen geschoten.

[Vaan Banaan]

RayNbow schreef op maandag 7 augustus 2017 @ 14:33:
Kan geen command (of PowerShell) venster openen op deze thin client... Win+R werkt ook niet...

...kan wel via Word/VBA ping -t ... starten om te kijken of een bepaalde host al up is om naar te RDPen.

Willekeurige shortcut op je desktop kopieren en dan C:\Windows\System32\cmd.exe bij target invullen?

[RayNbow]

Vaan Banaan schreef op dinsdag 8 augustus 2017 @ 16:10:
[...]

Willekeurige shortcut op je desktop kopieren en dan C:\Windows\System32\cmd.exe bij target invullen?

Lijkt me niet dat 't gaat werken als ik cmd.exe ook niet vanuit VBA kan starten.

[Verwijderd]

@RayNbow: Kan je geen ConEmu gebruiken?

[Alex)]

Ik had vanochtend een mailtje... van m'n auto. Het diagnosesysteem had iets opgepikt waar ik beter even naar kon laten kijken.

What a time to be alive.