Urenregistratie met koppeling met Jira

[passantr]

Hallo allemaal,

Ik ben op zoek naar een urenregistratie applicatie die gegevens uit Jira haalt, waarna de medewerker uren kan registreren op basis van een ticketnummer.

Het idee is dat als de medewerker het ticketnummer intypt, dat daarnaast dan tickettitel, dashboard en eventuele aanvullende informatie verschijnt die uit Jira wordt gehaald met een actieve koppeling.

In de urenapplicatie wil ik alle soorten uren bijhouden (dus ook vakantie, ziekte, cursus etc.) en liefst ook een eenvoudige projectadministratie bijhouden (schatting uren, zoveel uren totaal).

Wat ik al gevonden of geprobeerd heb: er zijn applicaties met plugins in Jira (bijvoorbeeld Timechimp), er zijn applicaties als add-on op Jira (bijvoorbeeld Tempo Timesheets) maar ik kan dus niks vinden dat ticketnummers, labels, titels en dashboards uit Jira haalt en dan aan de hand van het ticketnummer medewerkers uren laat invoeren.

Kent iemand dit?

Aanvullend: als iemand andere ideeën heeft, hoor ik het ook graag. Op zich vind ik Tempo Timesheets er heel mooi uitzien.

[Hydra]

passantr schreef op zondag 28 juni 2020 @ 11:27:
Aanvullend: als iemand andere ideeën heeft, hoor ik het ook graag.

Als developer zou echt no way uren willen schrijven met zo veel detail. Ik zou ergens anders gaan werken. Sorry.

[passantr]

@Hydra Bedankt voor je reactie.

Het idee is dat je aan het einde van de dag het ticketnummer intypt en dat die andere gegevens (titel, dashboard etc.) dan vanzelf daarnaast verschijnen zodat je kunt checken of het ticketnummer correct is. Daarna hoef je zelf alleen de uren en eventueel de datum in te voeren.

Of bedoelde je dat niet?

[KoudeAardbei]

Hydra schreef op zondag 28 juni 2020 @ 11:30:
[...]


Als developer zou echt no way uren willen schrijven met zo veel detail. Ik zou ergens anders gaan werken. Sorry.

Bij een intern project is dit haalbaar, maar zodra je met externe klanten moet gaan werken die uren verantwoording willen..


---
Wij gebruiken Simplicate bij mijn werkgever en zaten lange tijd bij Timechimp.
Beide API's zijn dusdanig goed dat je dit eenvoudig zou moeten kunnen maken, desnoods met iets als Integromat of Zapier.

[Hydra]

KoudeAardbei schreef op zondag 28 juni 2020 @ 11:34:
Bij een intern project is dit haalbaar, maar zodra je met externe klanten moet gaan werken die uren verantwoording willen..

I know. Ik heb voor dat soort bedrijven gewerkt. Never again.

Development is geen dom productiewerk. Soms ga je sneller. Soms een stuk langzamer. Dan krijg je dus iedere keer domme discussies over of dat loginischerm nu 8 of 16 heeft moeten kosten, alleen maar omdat je een keer een 'off day' had.

Ik werk nu als ZZPer voor een flink tarief en hoef echt alleen maar het aantal gewerkte uren te registreten gewoon omdat op basis daarvan de facturen gemaakt worden.

@passantr ik zal hier verder over ophouden, aangezien 't offtopic is

[passantr]

@KoudeAardbei Jij ook bedankt voor je reactie en de tips! Ik ken 3 van de 4 applicaties die je noemt nog niet (er is ook wel heel veel, waardoor je de bomen door het bos niet meer ziet)

[passantr]

Hydra schreef op zondag 28 juni 2020 @ 11:37:
[...]
ik zal hier verder over ophouden, aangezien 't offtopic is

Als business analyst vind ik de mening van gebruikers altijd interessant

[MAX3400]

@passantr je topicstart heeft het zeer kort (en niet beargumenteerd) over urenschatting. Dat is een hele andere tak van sport in "uren registratie systemen" en eigenlijk (mijn mening) moet je dat splitsen van je actieve registratie-systeem.

Allicht dat de data van vorige maand (ingevulde uren etc) wel de basis kan zijn voor forecasting maar ik zou dat zeker niet 1 pakket gefrommeld willen hebben. Forecasting zit vaak meer aan de project/HR kan terwijl facturatie aan de HR/debiteuren zit. Intern kan dat een ENORME clash opleveren als je in elkaars resources zit te roeren.


Verder heb ik enige moeite met wat @Hydra ook al benoemt; de manier die nu beschreven wordt hoe "ik" bij jou uren moet invullen. Vermoedelijk ben ik effectiever door het zelf bij te houden op een Post-IT dan (achteraf) een week lang te moeten controleren of elke pulldown wel de goede data ophaalt die ik dan weer moet controleren of ik daar wel die tijd op heb gemaakt?

[ Voor 10% gewijzigd door MAX3400 op 28-06-2020 11:42 ]

[rvrbtcpt]

Daarvoor kun je de Jira plug-in Tempo gebruiken. Dan kun je op ticket de geschatte en gebruikte uren bijhouden.

@Hydra dat je geen uren op detail bij gaat houden kan ik me voorstellen maar je krijgt ook geen carte blanche van een bedrijf om maar bezig te zijn. Iets van een inschatting of verwacht aantal features dat je in een sprint oplevert zal er altijd zijn. Het ligt ook aan jezelf hoe je deze tools gebruikt.

[ Voor 58% gewijzigd door rvrbtcpt op 28-06-2020 11:51 ]

[Hydra]

Frijns.Net schreef op zondag 28 juni 2020 @ 11:48:
@Hydra dat je geen uren op detail bij gaat houden kan ik me voorstellen

Daar gaat het me dus om. Ik ga geen uren boeken op individuele taken. En ik hoef ook niet het aantal uren dat ik per sprint besteed te verantwoorden. Dat kan ook helemaal niet; er zijn gewoon te veel 'unknowns'. Als team lead zit ik veel in meetings, een groot deel daarvan worden tijdens de sprint gepland.

Ik snap ook echt wel dat een projectbureau uren moet kunnen verantwoorden. Ik heb dat soort projecten ook gedaan, ook als projectmanager, en de urenverantwoording die naar de klant gecommuniceerd werd, was gewoon een door mij gemaakte verdeling van de besteedde uren. Er moet gewoon ruimte gegeven worden aan developers gewoon hun werk te doen.

Zoals ik al zei; developers sturen op besteding van uren op individuele taken leidt er vooral toe dat de developers die goed in de markt liggen snel weg zijn.

Ik werk al zo'n 18 jaar als developer en heb in veel projecten meegedraaid (vrijwel altijd als 'consultant' gewerkt) en je ziet dit soort micromanagement vooral bij kleine projectbedrijven. Dat komt omdat deze vooral concurreren op prijs en dus nauwelijks marge hebben. En daar wil ik dus niet voor werken, omdat dat soort productielijnwerk voor mij weinig met 'software engineering' te maken heeft.

[nooberke]

Frijns.Net schreef op zondag 28 juni 2020 @ 11:48:
Daarvoor kun je de Jira plug-in Tempo gebruiken. Dan kun je op ticket de geschatte en gebruikte uren bijhouden.

Wij maken op kantoor ook gebruik van Tempo, dit is inderdaad prima mogelijk.

[Falcon]

@Hydra Ook als interne medewerker kan het soms nodig zijn om dit met zoveel detail te moeten doen, zoals in aanmerking te komen voor bijv. WSBO-subsidie in aanmerking te komen.

Ik begrijp je houding er tegenover, die heb ik ook.. maar toch zijn er uitzonderingen.

[Hydra]

Falcon schreef op zondag 28 juni 2020 @ 12:17:
@Hydra Ook als interne medewerker kan het soms nodig zijn om dit met zoveel detail te moeten doen, zoals in aanmerking te komen voor bijv. om voor WSBO-subsidie in aanmerking te komen.

I know. Ik heb als ZZPer zelf ook WBSO registratie te doen.

Ik begrijp je houding er tegenover, die heb ik ook.. maar toch zijn er uitzonderingen.

Tuurlijk. Overal zijn uitzonderingen voor Maar volgens mij was ik vrij duidelijk over de situatie die ik beschrijf

[passantr]

@MAX3400 Bedankt voor je waardevolle toevoeging!

@Frijns.Net Bedankt! Tempo is een kandidaat (hoewel anders qua opzet dan mijn eerste gedachte)

[arvidbeheerder]

Harvest kan alles wat je wilt denk ik, maar ook veel meer. Wij gebruiken het als uren systeem voor zowel onze consultants als de programmeurs.

[passantr]

@Falcon Per issue willen we weten hoeveel uur er is besteed, om goed te kunnen factureren en verantwoorden naar de externe klanten. Uit de reacties blijkt voor mij wel heel duidelijk, dat we goed moeten nadenken over wat we de medewerkers precies laten registreren en op welk detailniveau. Overigens is het geen scrum, maar wat grotere issues meestal (meer epics dan user stories zeg maar).

Ik ben overigens blij met alle reacties en ook bizar snel! Dank aan allen.

[Erapaz]

passantr schreef op zondag 28 juni 2020 @ 11:34:
@Hydra Bedankt voor je reactie.

Het idee is dat je aan het einde van de dag het ticketnummer intypt en dat die andere gegevens (titel, dashboard etc.) dan vanzelf daarnaast verschijnen zodat je kunt checken of het ticketnummer correct is. Daarna hoef je zelf alleen de uren en eventueel de datum in te voeren.

Of bedoelde je dat niet?

Gewoon per team/sprint factureren. Niet developers individueel op ticket niveau laten boeken. Project schattingen in uren wil je ook niet maken.

Aan TS, niet dit soort werkwijzen faciliteren! Urenschattingen en op tijd worden afgerekend moeten we echt zo snel mogelijk van af. Anti-agile micromanagement uit het stenen tijdperk voor mensen die het gevoel willen hebben controle te hebben en een mechanisme voor het aanwijzen van schuld.

[GarBaGe]

Jira heeft een goede api.
Zoek een tijdschrijf app met een goede api en bouw zelf een koppeling

[Montaner]

passantr schreef op zondag 28 juni 2020 @ 12:34:
@Falcon Per issue willen we weten hoeveel uur er is besteed, om goed te kunnen factureren en verantwoorden naar de externe klanten. Uit de reacties blijkt voor mij wel heel duidelijk, dat we goed moeten nadenken over wat we de medewerkers precies laten registreren en op welk detailniveau. Overigens is het geen scrum, maar wat grotere issues meestal (meer epics dan user stories zeg maar).

Ik ben overigens blij met alle reacties en ook bizar snel! Dank aan allen.

Je gooit er wat scrum termen in.. dus jullie zullen er ook wel een enigszins agile filosofie op nahouden? Je pokert al je story's dan toch? Dat kan je daarna weer oprollen naar Epic niveau. Het idee is dat met verloop van tijd je pokerpunten overeenkomen met de hoeveelheid besteed werk.. waar zoals Hydra meermaals aangeeft dat het aantal uren besteed aan een issue weinig zegt, behalve dat je micromanagement krijgt.

Daarbij.. agile werken is op basis van capaciteit.. dus de uren welke je kan besteden weet je als het goed is al.

Wat betreft tooling.. als tools welke vrij veel gebruikt worden zoals Tempo niet voldoen aan jouw idee.. misschien ligt het dan niet aan de tool . Dat bedoel ik niet verkeerd; maar je zoekt mogelijk naar een niet bestaand probleem.

[ Voor 3% gewijzigd door Montaner op 28-06-2020 12:40 ]

[Falcon]

passantr schreef op zondag 28 juni 2020 @ 12:34:
@Falcon Per issue willen we weten hoeveel uur er is besteed, om goed te kunnen factureren en verantwoorden naar de externe klanten. Uit de reacties blijkt voor mij wel heel duidelijk, dat we goed moeten nadenken over wat we de medewerkers precies laten registreren en op welk detailniveau. Overigens is het geen scrum, maar wat grotere issues meestal (meer epics dan user stories zeg maar).

Ik ben overigens blij met alle reacties en ook bizar snel! Dank aan allen.

Als je het op Epic niveau gaat doen, dan kan je volgens mij een berekening loslaten met gemiddelden en hoef je geen registratiesysteem voor de engineer toe te passen.

Zolang het maar duidelijk is dat je een engineer niet ongelukkiger kan maken dan zijn uren te moeten registreren

[The Eagle]

Jira en de hele devops gedachte staan haaks op Business as usual / beheer en urenverantwoording. Ga je even in ascum / agile / devops inlezen en je zult snappen waarom.

Ik snap dat je uren aan externe klanten wilt verantwoorden. Hou die in de ticketing applicatie of in je eigen urenadministratie, maar niet in Jira.

Als jij een business analyst bent dan zou je als geen ander moeten weten dat je bedrijfslogica in de applicatie moet houden die er voor bedoeld is. Urenverantwoording doe je primair in je HR systeem. Secundair heb je systeem waarin klantproblemen staan en de resources die aan de oplossing besteed zijn. Daar zou je uren in op kunnen nemen als dat echt nodig is. Maar niet in de ondersteunende applicatie voor het operationeel / uitvoerende proces.

[Marco1994]

Wellicht is Tmetric iets voor je

[TheDane]

Ik werk voor een club die voor de urenregistratie gebruikmaakt van https://everhour.com/. Daar kun je ook "los" uren in boeken, maar ook per individueel Jira ticket. Er zijn extensies/koppelingen om 'realtime' uren bij te houden, maar ook achteraf, met of zonder toelichting.

[Kalentum]

The Eagle schreef op zondag 28 juni 2020 @ 13:49:
Jira en de hele devops gedachte staan haaks op Business as usual / beheer en urenverantwoording. Ga je even in ascum / agile / devops inlezen en je zult snappen waarom.

Ik snap dat je uren aan externe klanten wilt verantwoorden. Hou die in de ticketing applicatie of in je eigen urenadministratie, maar niet in Jira.

Als jij een business analyst bent dan zou je als geen ander moeten weten dat je bedrijfslogica in de applicatie moet houden die er voor bedoeld is. Urenverantwoording doe je primair in je HR systeem. Secundair heb je systeem waarin klantproblemen staan en de resources die aan de oplossing besteed zijn. Daar zou je uren in op kunnen nemen als dat echt nodig is. Maar niet in de ondersteunende applicatie voor het operationeel / uitvoerende proces.

Ja maar bv Tempo integreert lekker met Jira dus de gebruikersinterface zit in Jira maar de uurtjes zelf worden niet 'in Jira' opgeslagen. Overzichten komen uit Tempo en uurtjes zijn gelinkt aan Jira tickets maar staan los van Jira processen. Dus de 'ondersteunende applicatie' is niet meer dan een extra user interface.

[The Eagle]

Dat het kan wil niet zeggen dat het ook een goed idee is

[Kalentum]

The Eagle schreef op zondag 28 juni 2020 @ 17:57:
Dat het kan wil niet zeggen dat het ook een goed idee is

Hoezo? Het zijn twee verschillende systemen.

[alienfruit]

Echt nooit meer, ik heb voor een bedrijf waar je urenregistratie moest doen in units van vijf minuten waar je zelfs je toiletgebruik niet mee mocht tellen etc. Als je vervolgens niet genoeg uren had gemaakt werd het van je vakantiedagen afgetrokken. Urenregistratie gewoon mooi per dagdeel of dag is gedetailleerd genoeg.

[ShitHappens]

Hier ook, Tempo ingebouwen in Jira. In principe is 't zo dat we tijd loggen op het ticket waar we aan werken (voor 't gemak afgerond omhoog naar 5-minuten intervallen). Daarnaast hebben we nog een apart project met een handvol tickets om "overige" tijd op te loggen: meetings, vakantiedagen, mailverkeer, interne documentatie zonder eigen ticket, studie, werkreizen etc.

In Tempo kun je ook nog weer projecten of teams configureren specifiek voor de rapportage aldaar - deze staan dan los van degene in Jira zelf. Op de tickets kun je trouwens ook nog een estimate invoeren en vervolgens weer op rapporteren.
En uiteraard valt dat allemaal weer samen te trekken in dashboards en rapportages. Als trouwens een medewerker in Tempo zit, of eigenlijk overal in Jira, kan 'ie op "W" drukken om een work log op te slaan: ticketnummer invullen + uren en klaar.

Door de combinatie van Jira en Tempo slim genoeg in te zetten, kun je wat je zoek precies bereiken, via een nét iets andere route.

[The Eagle]

Kalentum schreef op zondag 28 juni 2020 @ 18:58:
[...]


Hoezo? Het zijn twee verschillende systemen.

Klopt. Ga maar eens aan een medewerker uitleggen dat ie al zijn ziekte, afwezigheid en uren in zowel het HR systeem als een ander systeem vast moet leggen. En omdat dat moet, moet je ineens ook uren afstemmen tussen beide systemen. Wat als het niet klopt, wat is leidend? En hoe ga je dat met je afstemmen doen dan? Excel rapportjes naast elkaar leggen? Want ja, dat moet, want het is leidend voor je facturatie.
Bovendien zit je met een afhankelijkheid van een plugin voor tijdsregistratie die ongetwijfeld niet alles dekt wat je als bedrijf op dat gebied (HR) nodig hebt.
Trust me, als IT'er wil je niet op de stoel van een HR man zitten. voor ons IT'ers is 1 en 1 samen 2, terwijl dat in HR land best wel eens 3, 5 of -10 kan zijn. Voorbeeld: Kan die Tempo pluging omgaan met iemand die voor 20% langdurig ziek is, een halve dag vakantie opneemt en de rest werkt? En nee, da's geen 4 uur vakantie en 4 uur gewerkt dan Iets zegt me dat Tempo dat niet kan.

Daarnaast vraagt TS ook nog om projectadministratie. Dat betekent dat over langere tijd niet alleen het HR deel, maar ook de financiele planning en -componenten in de gaten gehouden moeten worden. No way dat je dat met een plugin redt.

Nogmaals, dat het kan betekent niet dat het ook een goed idee is
Als ik TS was ging ik met mijn HR en financiele afdeling en een enterprise achitect (indien aanwezig) zitten over hoe dit te doen. Er is een behoefte, die snap ik. Maar die behoefte wordt nu gebracht als een oplossing, en dat gaat de verkeerde kant in

[Kalentum]

@The Eagle ok duidelijk! Persoonlijk heb ik een schurfthekel aan urenregistratie en ben dus blij met alles wat dit makkelijker maakt en als je work unit 'een JIRA ticket' is dan is het fijn om daarop te kunnen schrijven.

Heb ook wel eens een compleet niet geïntegreerd systeem gehad waarbij dus je soms nog niet eens uren kon schrijven omdat je werkte aan een project wat nog niet door de financiële administratie was aangemaakt terwijl we al wel bezig waren voor die klant. Dus dat was dan een week later nog prutsen om die uren weer goed te zetten.

[Croga]

Montaner schreef op zondag 28 juni 2020 @ 12:39:
Je gooit er wat scrum termen in.. dus jullie zullen er ook wel een enigszins agile filosofie op nahouden? Je pokert al je story's dan toch? Dat kan je daarna weer oprollen naar Epic niveau. Het idee is dat met verloop van tijd je pokerpunten overeenkomen met de hoeveelheid besteed werk.. waar zoals Hydra meermaals aangeeft dat het aantal uren besteed aan een issue weinig zegt, behalve dat je micromanagement krijgt.

Nee, dat is helemaal niet het idee! Het idee van pokeren is dat het een planningstool is; een sanitycheck voor het team om te kijken of een sprint doel enigszins realistisch gesteld is. Zodra je het voor iets anders gaat gebruiken (zoals oprollen of relateren aan bestede tijd) is het volledig zinloos geworden. Planning poker voor iets anders gebruiken dan planning is planning-poker-zelfmoord.

Agile gaat uit van product ontwikkeling. Dat betekend dat het onzinnig en onnodig is om uren te registreren omdat je een product aan het realiseren bent waarvoor de klant betaald wat de markt er voor over heeft. Dat dit nu misbruikt wordt om "uurtje factuurtje" werk te leveren betekend dat alles wat in de basis van Scrum en Agile zit overboord gegooid kan worden. TS is niet bezig met Scrum, noch met Agile en dus enige relativering aan de principes daarvan zijn zinloos in deze discussie.

Wat je wilt, TS, is dit in de workflow van de ontwikkelaar inbouwen. Registreer de checkout tijd, registreer de checkin tijd, reken de verwerkingstijd uit. Zorg vervolgens dat de ontwikkelaars in staat zijn op deze manier te werken (bijvoorbeeld door te zorgen dat ze niet onderbroken worden in hun werk) en je bent klaar. Geen overbodige last op de ontwikkelaar, wel de juiste gegevens uit het systeem en een stapje dichter richting echt agile werken.

[The Eagle]

Kalentum schreef op maandag 29 juni 2020 @ 10:30:
@The Eagle ok duidelijk! Persoonlijk heb ik een schurfthekel aan urenregistratie en ben dus blij met alles wat dit makkelijker maakt en als je work unit 'een JIRA ticket' is dan is het fijn om daarop te kunnen schrijven.

Heb ook wel eens een compleet niet geïntegreerd systeem gehad waarbij dus je soms nog niet eens uren kon schrijven omdat je werkte aan een project wat nog niet door de financiële administratie was aangemaakt terwijl we al wel bezig waren voor die klant. Dus dat was dan een week later nog prutsen om die uren weer goed te zetten.

+1 herkenbaar
Zoals je bij financien een administratie en een subadministratie hebt (grootboek vs crediteuren) heb je dat in HR en uregregistratieland ook. Het grote spul doe je in het HR systeem, evt kleine dingen zoals besteede uren schrijf je in een subadministratie. Maar that's it. Niet al die grote dinge ook nog in je subadministratie bij willen houden, want dan moet je ineens twee hoofdadministraties af gaan stemmen in systemen die elkaar niet snappen

[Montaner]

Croga schreef op maandag 29 juni 2020 @ 10:41:
[...]

Nee, dat is helemaal niet het idee! Het idee van pokeren is dat het een planningstool is; een sanitycheck voor het team om te kijken of een sprint doel enigszins realistisch gesteld is. Zodra je het voor iets anders gaat gebruiken (zoals oprollen of relateren aan bestede tijd) is het volledig zinloos geworden. Planning poker voor iets anders gebruiken dan planning is planning-poker-zelfmoord.

...

Ok, en stap nu even uit de theoretische bubbel... als je een realistische planning maakt weet je toch precies hoeveel tijd er mee gemoeid is? Aantal mensen * beschikbare uren (capaciteit) / aantal pokerpunten van een sprint. Ook kwantificeer je ergens wat een pokerpunt nu echt is.. en ook daar neem je weer tijd in mee.

De enige realistische check aan een sprintdoel is kijken of je met tijd beschikbaar je werk afgerond kan krijgen. En tijd drukken we nog steeds uit in uren. Dat een pokerpunt niet op 1 op 1 aan een aantal uur gekoppeld kan worden hoor je mij ook niet zeggen; maar je kan dit beter gebruiken dan te gaan micromanagen op issue niveau en daarop uren te laten boeken.

Door de tijd leert het team om beter een sprint te plannen. Oftewel, de inschatting capaciteit vs. pokerpunten wordt nauwkeuriger oftewel... vul zelf maar in.

[Hydra]

Montaner schreef op maandag 29 juni 2020 @ 11:31:
[...]

Ok, en stap nu even uit de theoretische bubbel... als je een realistische planning maakt weet je toch precies hoeveel tijd er mee gemoeid is? Aantal mensen * beschikbare uren (capaciteit) / aantal pokerpunten van een sprint. Ook kwantificeer je ergens wat een pokerpunt nu echt is.. en ook daar neem je weer tijd in mee.

Als je pokerpunten = tijd gebruikt doe je de planning echt verkeerd. Het is een abstract getal dat vooral complexiteit aangeeft. Dit is de reden dat veel teams T-shirt sizes gebruiken om te voorkomen dat mensen toch stieken punten om gaan rekenen naar tijd.

Verder eens; micromanagement op issues is ook niet wat je wil. Er is meer dan genoeg bewijs dat exact inschatten van software gewoon niet kan. Dus laten we ook niet doen alsof.

[ Voor 11% gewijzigd door Hydra op 29-06-2020 11:42 ]

[Hydra]

passantr schreef op zondag 28 juni 2020 @ 12:34:
@Falcon Per issue willen we weten hoeveel uur er is besteed, om goed te kunnen factureren en verantwoorden naar de externe klanten. Uit de reacties blijkt voor mij wel heel duidelijk, dat we goed moeten nadenken over wat we de medewerkers precies laten registreren en op welk detailniveau. Overigens is het geen scrum, maar wat grotere issues meestal (meer epics dan user stories zeg maar).

Als het grotere dingen zijn dan een story (die in 2-4 dagen max moet kunnen doen), dan is enigzins accuraat schatten volledig onmogelijk.

Wat er nu gebeurt is heel simpel. Je straft developers voor overschrijdingen van tijd. Er is een hele grote 'stick' maar eigenlijk geen wortel. Dus wat ze gaan doen is inschattingen opblazen: iets wat in gedachten een dag kost, schatten ze officieel in op 3 dagen. Dan weten ze zeker dat ze het af gaan krijgen. Maar ze kunnen het ook niet consequent sneller doen, want dan krijgen ze weer gezeur dat ze het te hard opblazen. Dus wat gebeurt het; worst case duurt het inderdaad 3 dagen. Best case duurt het ook drie dagen, maar zitten ze 2 dagen uit hun neus te vreten, want je geeft ze niet de ruimte sneller te gaan.

Massa's developers houden op deze manier hun management voor de gek omdat ze niet anders kunnen. Dit is waarom veel bedrijven gewoon gestopt zijn met dit soort micro-management: je verliest er alleen maar productiviteit mee.

Agile werken en dit soort micromanagement zijn volledig tegenstrijdig met elkaar.

Je schat als bedrijf gewoon vooraf in wat een feature kost. Dat is wat je factureert. Hoeveel je er daadwerkelijk aan kwijt bent is niet relevant. Is het meer dan is dat voor jouw rekening. Is het minder dan is het mooi meegenomen.

[Croga]

Montaner schreef op maandag 29 juni 2020 @ 11:31:
Ok, en stap nu even uit de theoretische bubbel...

Nee. Dit is geen theoretische bubbel, dit is praktijk ervaring van mijn vijftien jaar plus de honderden jaren van de bedenkers van het concept. Dat heeft niks met bubbels te maken.
Feit: Zodra je planning poker gaat gebruiken voor andere dingen dan planning (en punten relateren aan uren is iets anders dan plannen) kun je ze net zo goed helemaal overboord gooien.

als je een realistische planning maakt weet je toch precies hoeveel tijd er mee gemoeid is? Aantal mensen * beschikbare uren (capaciteit) / aantal pokerpunten van een sprint. Ook kwantificeer je ergens wat een pokerpunt nu echt is.. en ook daar neem je weer tijd in mee.

Again: nee. Een uur van Jan is geen uur van Piet. Denk je dat dat wel zo is dan gooi gerust punten overboord, pak je excel sheet, of nog liever je GANT chart en ga terug naar Microsoft Project

De enige realistische check aan een sprintdoel is kijken of je met tijd beschikbaar je werk afgerond kan krijgen. En tijd drukken we nog steeds uit in uren. Dat een pokerpunt niet op 1 op 1 aan een aantal uur gekoppeld kan worden hoor je mij ook niet zeggen; maar je kan dit beter gebruiken dan te gaan micromanagen op issue niveau en daarop uren te laten boeken.

Nogmaals: Zodra je punten gaat gebruiken voor iets anders dan planning vergeet dan alles maar gewoon. Je stelt nu opnieuw dat 1 uur Piet gelijk is aan 1 uur Jan, dat 1 uur Java gelijk is aan 1 uur Test en dat 1 uur Sprint Planning gelijk is aan 1 uur koffie zetten. Planning poker omvat dit alles en onzekerheid en energie niveau en een keer naar de doctor gaan en...... alles.

Laat ik voorop stellen dat ik het met je eens ben dat micomanagement op taak niveau op iedere manier onwenselijk is. Maar laten we het alsjeblieft niet vervangen door sabotage van het plannings proces. Want dat is wat je doet zodra je punten en uren in dezelfde zin zet.

[Erapaz]

Croga schreef op maandag 29 juni 2020 @ 10:41:
[...]

Nee, dat is helemaal niet het idee! Het idee van pokeren is dat het een planningstool is; een sanitycheck voor het team om te kijken of een sprint doel enigszins realistisch gesteld is. Zodra je het voor iets anders gaat gebruiken (zoals oprollen of relateren aan bestede tijd) is het volledig zinloos geworden. Planning poker voor iets anders gebruiken dan planning is planning-poker-zelfmoord.

Agile gaat uit van product ontwikkeling. Dat betekend dat het onzinnig en onnodig is om uren te registreren omdat je een product aan het realiseren bent waarvoor de klant betaald wat de markt er voor over heeft. Dat dit nu misbruikt wordt om "uurtje factuurtje" werk te leveren betekend dat alles wat in de basis van Scrum en Agile zit overboord gegooid kan worden. TS is niet bezig met Scrum, noch met Agile en dus enige relativering aan de principes daarvan zijn zinloos in deze discussie.

Wat je wilt, TS, is dit in de workflow van de ontwikkelaar inbouwen. Registreer de checkout tijd, registreer de checkin tijd, reken de verwerkingstijd uit. Zorg vervolgens dat de ontwikkelaars in staat zijn op deze manier te werken (bijvoorbeeld door te zorgen dat ze niet onderbroken worden in hun werk) en je bent klaar. Geen overbodige last op de ontwikkelaar, wel de juiste gegevens uit het systeem en een stapje dichter richting echt agile werken.

toon volledige bericht

Eens met je eerste alinea. De laatste zin van je tweede alinea geeft het probleem aan. Hij is bezig met software ontwikkeling, dus zou hij met Agile bezig moeten zijn.
Waarom de tijd besteed aan issues meten door middel van checkin/checkout? Welke actie ga je ondernemen op basis van die informatie? Hoe meet je het werk buiten het programmeren an sich? Hoe ga je om met mob-programming? Waarom mogen ontwikkelaars hun werk niet onderbreken? Een uurtje wandelen lost soms meer problemen op dan naar je scherm staren. Dit soort praktijken zijn echt killing voor je software shop. Meten van tijd op dit niveau moet je echt niet doen en moeten we met zijn allen tegen vechten.

Zoek alsjeblieft een andere manier van facturen en maak dit niet het probleem van de ontwikkelaar!

[Hydra]

Erapaz schreef op maandag 29 juni 2020 @ 12:28:
Een uurtje wandelen lost soms meer problemen op dan naar je scherm staren.

Ik ga gewoon de uren boeken die ik slaap. De helft van het oplossen van complexe problemen gebeurt daar.

[Erapaz]

@Hydra Dat is helemaal waar, net als dat je op de toilet of even sparren bij de koffie automaat op de beste ideeën komt. Het is een creatief proces.

Het hele component tijd moet je uit software ontwikkeling houden. Helaas worden schattingen misbruikt en omgeturnd tot deadlines, die maak ik dus ook niet meer. Ik ben erg fan van #noestimates:
https://medium.com/@neil2...ut-estimates-b42c4a453dc6

Toestemming nodig voor bekijken van YouTube

Op deze plek staat ingesloten content die van YouTube afkomstig is. Het tonen van deze inhoud kan ertoe leiden dat YouTube persoonlijke gegevens zoals je IP-adres verwerkt en/of cookies op jouw computer of ander apparaat zet. Hiervoor moet je eerst expliciet toestemming geven voor Sociale media.

Open cookievoorkeurenBekijk op YouTube

#NoEstimates (Allen Holub)

Deadlines (even end of Sprint) are an anti-pattern. With only a few legitimate exceptions (e.g. regulatory), they are nothing but a tool of manipulation used to exploit people into “working harder,” and they invariably lower quality. If you can’t finish “in time,” reduce scope.

— Allen Holub @allenholub.bsky.social (@allenholub) 28 juni 2020

[Immutable]

Toestemming nodig voor bekijken van YouTube

Op deze plek staat ingesloten content die van YouTube afkomstig is. Het tonen van deze inhoud kan ertoe leiden dat YouTube persoonlijke gegevens zoals je IP-adres verwerkt en/of cookies op jouw computer of ander apparaat zet. Hiervoor moet je eerst expliciet toestemming geven voor Sociale media.

Open cookievoorkeurenBekijk op YouTube

How to Estimate in Software Development with Gerard Beckerleg | #NoEstimates

[TweakMDS]

Hoewel ik het op veel punten inhoudelijk met @Hydra eens ben herken ik in de verwoording ook een developer houding waar ik inmiddels een klein beetje moe van kan worden.

Ik werk nu zo'n 20 jaar in de IT, waarvan de laatste 5 jaar in een management functie. Ik kan dus vrijuit zeggen dat ik beide kanten van het spectrum ken. De weerstand van developers om ook maar iets aan urenregistratie te willen doen, en de onzekerheid van totaal geen beeld hebben waar alle uren aan verstookt worden.

Elk bedrijf is anders. Het is volstrekte onzin om standpunten in te nemen die gebaseerd zijn op de aanname dat je developers gaat afrekenen of onderling vergelijken op basis van de geboekte uren. Er zullen vast organisaties zijn die dit gaan doen, maar dat is een wantrouwens-cultuur waar ik me niet achter kan scharen.
Wat je hier als organisatie wel mee kan doen is scherp op je kostprijs zitten, en bijsturen op de inhoud van je diensten aan klanten of in projecten.

Om wat context te schetsen. Wij zijn een software bedrijf die voor zo'n 20% van onze tijd projecten doen, 5% - 10% van onze tijd exploitatie, en de rest is R&D, roadmap development of "overige zaken".
We maken software voor grote klanten, en hebben dus relatief weinig, maar wel heel grote klanten.

Wij boeken met zo'n 50 man allemaal onze uren, in principe in een voorgedefinieerde set aan categoriën, projecten (denk EPIC niveau) of klanten voor exploitatie; dus niet op individueel PBI niveau.
We hebben ook een aantal externe teams die enkel sommige uren rechtstreeks in Jira boeken bij het afronden van PBI's. Dat doen we om onze project calculaties weer kloppend te krijgen, en doen we alleen voor de PBI's die daadwerkelijk op een klant project horen (een heel klein deel - meestal implementatie werk of customization).

Estimaten doen we in story points. Op basis van velocity kunnen estimations worden omgerekend naar uren, maar niet op individueel niveau.

Wat doen je dan wel met die urenregistratie?
In ieder geval niet afstraffen. Geen enkele developer wordt hier ooit aangesproken of afgerekend op basis van verschillen tussen urenregistratie, of omgerekende estimations. Dat geeft overigens ook geen vrijbrief om alle accountability van de developer over productiviteit meteen op te geven, maar de urenregistratie gebruik ik er niet voor.
Wel kan ik eruit halen dat onze "duurste klant" een factor 10 meer exploitatie-last geeft dan de anderen. Daar zou mogelijk de onderhouds fee omhoog moeten, of bijvoorbeeld eens een goed gesprek over de kwaliteit van de hosting of data kwaliteit van de aanlevering.
Het geeft me ook aanleiding om te onderzoeken waarom een project zoveel scope changes heeft gehad, dat iets wat in één sprint gepland stond (grofweg 2 - 3 man-weken) uit kwam op 700+ uur, eens rond te gaan vragen hoe en wanneer men aan de bel zou moeten trekken.
En misschien nog wel het belangrijkste: ik kan beter voorspellen wat een klant me gaat kosten, omdat ik meer informatie heb om dit uit te analyseren, zoals een verdeling van de roadmap uren om een licentie-minimum in te kunnen schatten, maar ook wat ik zou kunnen verwachten aan ondersteuning.

Nogmaals, iedereen is anders, en je kan een hoop vinden van uren boeken op PBI-niveau, maar ik wilde toch even een andere kant van het spectrum geven.

@passantr - als je het zelf in de hand hebt... ik adviseer je om uren te registreren op epic / project niveau.

[Dido]

@SndBastard Je weet wat je team per sprint kost. Je weet welke PBI's ze in een sprint hebben gedaan. Je weet de relatieve grootte van die PBI's ten opzichte van elkaar en het totaal wat die sprint is gedaan.
Dan kun je toch de "kostprijs" per PBI berekenen, zonder dat je developers nog een keer een aparte urenregistratie moeten bijhouden voor die PBIs?

Natuurlijk, een PBI kan meer of minder tijd kosten dan gepland. Maar een beetje scrum-team wordt vanzelf snel beter in het accuraat inschatten van de effort van PBIs zodat eventuele verschillen vanzelf uitmiddelen.

Het betekent dat je naar een (eventueel met een klant te verrekenen) kostprijs voro een team gaat in plaats van individuele developers die je in rekening brengt, en (en dat is misschien nog wel het lastigst) dat je je team vertrouwt.

Dat laatste lijkt in veel organisaties lastig, zodra individuele accountability lijkt te verdwijnen, verdwijnt ook nog wel eens het vertrouwen in die individuen. Eigenlijk is dat gek, want die inidividuele accountability verdwijnt helemaal niet, maar ligt binnen het team.
En als je je developers niet vertrouwt in het accuraat inschatten van de PBIs in punten is het vreemd als je ze wel vertrouwt bij het invullen van een urenstaat. Ik kan je uit ervaring vertellen dat in een dubbel;e administratie maximaal 1 registratie op waarheid gebaseerd is, de rest is gebaseerd op "het moet overeenkomen met de eerste". Het enige wat je developer dan doet is wat jij ook kunt doen: zijn uren per sprint pro rato verdelen over de PBIs in die sprint gebaseerd op de puntenschattingen.

Persoonlijk zou ik waarschijnlijk binnen 1 sprint het urenschrijven geautomatiseerd hebben :+_

[BertS]

Erapaz schreef op maandag 29 juni 2020 @ 12:28:
[...]

Zoek alsjeblieft een andere manier van facturen en maak dit niet het probleem van de ontwikkelaar!

Dat is niet altijd even makkelijk in de praktijk. Het zit best diep in ons om geld en tijd aan elkaar te relateren. Dat werkt zo tussen leveranciers en klanten, maar ook tussen werkgever en werknemer. Want ontwikkelaars kunnen wel roepen 'het is niet in tijd uit te drukken' (waar het een beetje op neer komt), maar ze willen zelf in de meeste gevallen toch ook wel betaald worden naar rato van gewerkte uren. Arbeidscontracten zijn nog vrijwel allemaal gebaseerd op 'voor x uur/week krijg je beloning y'.
En uiteindelijk is dat ook niet zo heel gek als je bedenkt dat tijd het meest schaars is, en daarmee het meest kostbaar.

In dit topic vind ik eerlijk gezegd ook dat er wel wat veel wordt aangegeven (expliciet of impliciet) dat je ontwikkelaars niet moet limiteren in / afrekenen op tijd. Maar waarom zou dat (nagenoeg) geen rol mogen spelen? Voor mij bepaalt in mijn ontwikkelwerk de hoeveelheid beschikbare tijd + wensen van de klant vaak toch wel mede hoe ver ik dingen uitwerk, hoe ver ik ga in tests schrijven bijvoorbeeld. Als basis wil je graag veel code onder test hebben staan, dat is als het goed is een soort intrinsieke behoefte van de ontwikkelaar. En in een greenfield project een prachtige ontkoppelde architectuur neerzetten doet ook elke ontwikkelaar graag (toch?). Maar als de ontwikkelaar wat verder van de klant af staat, gewoon omdat daar andere mensen tussen zitten, mag daar best wat in gestuurd worden. Zowel in inschattingen als in werkelijk bestede tijd. Soms hebben dingen de potentie om te groeien en moet je daar meer in investeren. Soms bespreek ik met de klant dat ik het nu wel 'even snel' neer kan zetten maar dat het wel betekent dat doorontwikkeling duur(der) wordt, en is dat part of the deal.

Ja natuurlijk, softwareontwikkeling is een creatief proces. En ik ken zelf ook de verschillen dat soms iets dat vooraf complex lijkt in een halve dag klaar is, terwijl iets dat triviaal leek uiteindelijk drie dagen werk kost. En ja, als zelfstandige moet ik dat soms ook aan klanten uitleggen. Maar dat het geen serieproductie is, maakt het direct ook lastig om op een andere manier met pricing om te gaan dan gebaseerd op tijd. Want effectief stel je 'kennis en kunde beschikbaar voor een X periode', en daar hangt de prijs aan. De waarde is in heel veel gevallen echt niet zomaar (eenvoudig) op een andere manier te bepalen. Je kunt niet voor elke maatwerk-feature een commerciële waarde bepalen vanuit 'wat brengt het de klant op / wat is de waarde voor de klant zonder naar mijn kostprijs te kijken', dat is gewoon niet realistisch in veel gevallen.

Vervolgens kan het dan nog gaan over de tijdseenheid waarin je dan rekent (uren/dagen/sprints). Maar dat is naar mijn mening ook afhankelijk van wat er gebeurt: als je hele sprints aan één klant besteedt kun je in sprints rekenen, uiteraard. Maar wat hier (naar het schijnt) wat over het hoofd gezien wordt is dat er ook talloze kleine omgevingen zijn. Er is meer op de wereld dan corporates. Zelf heb ik bijna elke week wel een RFC te verwerken voor oplossingen (bij verschillende klanten), die minder dan een dag werk zijn. Gisteren kwam er nog zoiets tussendoor, was drie uur werk en de klant is weer geholpen.
Laten we die kant van de medaille niet vergeten, waarbij het m.i. niet meer dan normaal is dat een developer z'n tijd registreert.

En natuurlijk (maar dat vind ik een andere discussie) moet dat niet doorslaan in micromanagement. Toiletbezoek en een rondje wandelen is gewoon productieve tijd.

[TweakMDS]

@Dido Je hebt helemaal gelijk, als het puur en alleen om developers zou gaan. Ik heb er ook wel vaker aan gedacht en intern over gesproken om de urenregistratie voor developers anders te doen. Zonder heel diep op de inhoud in te gaan; in de urenregistratie zit ook de verlofadministratie, en het is ook wel prettig om van de niet-develop uren een beeld te hebben.
Voor de goede orde, urenregistratie duurt maximaal 10-15 minuten per week.

[Erapaz]

BertS schreef op dinsdag 30 juni 2020 @ 09:24:
[...]

Dat is niet altijd even makkelijk in de praktijk. Het zit best diep in ons om geld en tijd aan elkaar te relateren.

En dat is precies de reden waarom software projecten nog niet vlekkeloos verlopen. Het vast willen houden aan wat men doet, drogredenen als “dat is niet altijd even makkelijk in de praktijk”. Los het op, maak het een probleem van de manager/c-level, dan doen die ook nog wat nuttigs.
Willen wij vooruitgang van ons vak dan zullen we dit soort dingen moeten los laten.

[Ed Vertijsment]

Geen idee of dit helemaal relevant is maar wat ik zelf doe is het ticket/issue nummer in mijn git commits zetten, dit is sowieso belangrijk om uit te zoeken waarom iets gedaan is, maar is ook voor voor een script die dat gebruik om op basis van die commit messages een urenregistratie te maken.

Het is nog wat barbaars en is niet helemaal automatisch (wil ik ook niet) maar helpt al een hele hoop. Let wel: dit is niet vanuit mijn werkgever opgezet, puur mijn eigen manier om dit te doen. Ik vraag mij af of veel ontwikkelaars zitten te wachten op ene werkgevers die hier een manier voor afdwingen.

[Hydra]

SndBastard schreef op maandag 29 juni 2020 @ 22:29:
Hoewel ik het op veel punten inhoudelijk met @Hydra eens ben herken ik in de verwoording ook een developer houding waar ik inmiddels een klein beetje moe van kan worden.

Ik werk nu zo'n 20 jaar in de IT, waarvan de laatste 5 jaar in een management functie. Ik kan dus vrijuit zeggen dat ik beide kanten van het spectrum ken. De weerstand van developers om ook maar iets aan urenregistratie te willen doen, en de onzekerheid van totaal geen beeld hebben waar alle uren aan verstookt worden.

Ik ken ook prima die frustratie. Ik heb nota bene onlangs een conflict gehad met een leverancier van ons die veel te veel uren besteed heeft. Simpele functionaliteit die drie keer zoveel tijd kostte dan aanvankelijk geschat. Dus dat was een pittige discussie met dat bedrijf waar we later wel uitgekomen zijn.

Maar dan nog is dat geen reden om alle developers te 'straffen' omdat 1 iemand een keer heeft lopen lanterfanten.

Wij boeken met zo'n 50 man allemaal onze uren, in principe in een voorgedefinieerde set aan categoriën, projecten (denk EPIC niveau) of klanten voor exploitatie; dus niet op individueel PBI niveau.

Okay. Dus hoe spreekt dat wat ik zeg dan tegen? Want dat je het op een projectonderdeel boekt is natuurlijk logisch. Maar dat is compleet wat anders dan op story niveau.

@passantr - als je het zelf in de hand hebt... ik adviseer je om uren te registreren op epic / project niveau.

Euh ja. Dat dus.

[Hydra]

BertS schreef op dinsdag 30 juni 2020 @ 09:24:
In dit topic vind ik eerlijk gezegd ook dat er wel wat veel wordt aangegeven (expliciet of impliciet) dat je ontwikkelaars niet moet limiteren in / afrekenen op tijd.

Dat zeg ik niet. Ik reageer in mijn eerste reactie tegen 1 uiterste (tijd boeken op story niveau) en dan is doen alsof ik of anderen voor het andere uiterste pleiten (geen enkele vorm van registratie) nogal een drogredenatie.

Als iemand een taak heeft die X tijd zou moeten kosten, en daar dan X * 4 tijd over doet, dan moet je absoluut eens in gesprek met die persoon. Maar dat staat echt volledig los van de facturatie van die uren. Als iemand 4 keer zo lang over die functionaliteit doet, kun je dat als bedrijf sowieso niet factureren. Dat valt no way goed te praten.

[Hydra]

Erapaz schreef op dinsdag 30 juni 2020 @ 10:19:
En dat is precies de reden waarom software projecten nog niet vlekkeloos verlopen. Het vast willen houden aan wat men doet, drogredenen als “dat is niet altijd even makkelijk in de praktijk”. Los het op, maak het een probleem van de manager/c-level, dan doen die ook nog wat nuttigs.
Willen wij vooruitgang van ons vak dan zullen we dit soort dingen moeten los laten.

Het is helemaal niet zo moeilijk als men voordoet. Je maakt vooraf een inschatting voor een project of projectonderdeel. Als manager heb je als het goed is wel een beeld bij hoe accuraat die schattingen zijn, en die vermenigvuldig je dan met een factor 2-3. Dat is wat er naar de klant gecommuniceerd wordt en waar je als manager ook gewoon voor blijft staan. Je moet vooraf zorgen voor een gedegen inschatting op basis van een betaald design en discovery traject.

Je developers houden bij per onderdeel hoe ver ze er mee zijn (bijvoorbeeld in Jira epics, whatever) en dan kun je ook gewoon zien hoeveel procent van het project gedaan is, t.o.v. de gespendeerde tijd. Als je dan meer tijd aan het verbranden bent dan verwacht, ga je vroegtijdig bijsturen voordat de klant uberhaupt reden krijgt tot klagen.

Ik deed dit zo al 10 jaar geleden en dat werkt nu nog steeds prima. Managers die denken meer grip te hebben door te vragen mensen op 5 minuten nauwkeurigheid te gaan boeken, komen bedrogen uit. Het probleem is gewoon managers die geen grip hebben en de reden dat ze geen grip hebben is gewoon omdat ze geen hol van development snappen.

Wil je goed lopende projecten? Zoek dan een lead developer die deze rol aankan. Die zijn alleen schaars en dus duur. En daar zit gewoon de kern van het probleem: de meeste van dit soort projectbureau's hebben, omdat ze alleen maar concurreren op prijs, geen geld voor echt goeie developers.

[BertS]

Erapaz schreef op dinsdag 30 juni 2020 @ 10:19:
[...]


En dat is precies de reden waarom software projecten nog niet vlekkeloos verlopen. Het vast willen houden aan wat men doet, drogredenen als “dat is niet altijd even makkelijk in de praktijk”. Los het op, maak het een probleem van de manager/c-level, dan doen die ook nog wat nuttigs.
Willen wij vooruitgang van ons vak dan zullen we dit soort dingen moeten los laten.

Misschien wil je ook inhoudelijk reageren ipv alleen maar 'drogreden' roepen? Ik geef er voorbeelden bij waarvoor het wel degelijk relevant is / kan zijn, en de enige reactie is 'drogreden, val mij niet lastig'.
Je moet zo gedetailleerd registreren als nodig is, en niet gedetailleerder dan nodig is.
En wat nodig is verschilt per bedrijf/project/situatie.

Hoe houdt dit de vooruitgang van ons vak tegen volgens jou?

Voorbeeldje:
Opdracht is een bericht versturen (uit ERP van de klant) naar een externe API (ERP van klant-van-de-klant). Documentatie is beschikbaar, op basis daarvan geef je een prijs.
Dan gaat de ontwikkelaar aan de slag, en blijkt de documentatie toch niet volledig genoeg, of er zit een fout in en het werkt in werkelijkheid anders. We kennen de voorbeelden allemaal waarschijnlijk.
Daar wil men commercieel wat mee. Maar op basis waarvan? Omdat het 'stuk' was? Verantwoordelijkheid kan niet bij het softwarehuis liggen, maar ligt feitelijk bij de klant-van-de-klant. Vanuit het softwarehuis gezien bij de klant. De discussie erover gaat dan toch over 'hoeveel tijd het (extra) kostte'. Als je zegt 'documentatie was niet correct, dus we gaan uit van de prijs zonder documentatie en dat is prijs A*10', ga je het niet eens worden ben ik bang.
Voor zulke opdrachten (ook als het wel helemaal volgens plan gaat) is er toch niets mis mee om op het niveau van die opdracht de bestede tijd te registreren?

[BertS]

Hydra schreef op dinsdag 30 juni 2020 @ 11:14:
[...]


Dat zeg ik niet. Ik reageer in mijn eerste reactie tegen 1 uiterste (tijd boeken op story niveau) en dan is doen alsof ik of anderen voor het andere uiterste pleiten (geen enkele vorm van registratie) nogal een drogredenatie.

Als iemand een taak heeft die X tijd zou moeten kosten, en daar dan X * 4 tijd over doet, dan moet je absoluut eens in gesprek met die persoon. Maar dat staat echt volledig los van de facturatie van die uren. Als iemand 4 keer zo lang over die functionaliteit doet, kun je dat als bedrijf sowieso niet factureren. Dat valt no way goed te praten.

Had ik het over jou specifiek dan? Het was meer mijn beeld bij het verloop van dit topic als geheel.

Maar goed, je eerste reactie is al behoorlijk fel met 'no way'. En de tweede 'never again'. Dat begrijp ik best, als er door bedrijven inderdaad misbruik van wordt gemaakt door te gaan micromanagen. Maar dat betekent niet dat het daarmee nooit nuttig/nodig kan zijn om wel op ticket-niveau te registeren. TS had in eerste instantie ook niets gezegd over het detailniveau van die tickets, maar geeft later aan dat het meer epics is dan stories. Dat kan prima valide zijn naar mijn mening (en ja, daar mogen anderen anders over denken). Zie mijn voorbeeld hierboven.

Bij het voorbeeld dat je zelf geeft: dat staat voor mij dan weer niet persé los van de facturatie. Maar dat heeft vooral te maken met de afspraken die er met de betalende partij zijn. Het lekkerst werkt natuurlijk als tijd niet relevant is voor de facturatie. Maar uiteindelijk wil jij als ZZP-er ook per maand Y omzet hebben, en is het indirect weer relevant. Dat vertaalt zich terug naar de opdrachten.
In het voorbeeld: X*4 wellicht niet. Maar als je een vaste relatie hebt met die klant die je 'kennis en kunde' inkoopt en daar opdrachten voor verstrekt, is die X niet altijd besproken met de klant. En dan kun je zelf vooraf wel X bedacht hebben, maar kan best achteraf blijken dat het vraagstuk ingewikkelder was dan verwacht - of een externe partij niet meewerkte waar de klant je van afhankelijk heeft gemaakt - en kun je die X*4 (of *3) misschien wel factureren.

[Hydra]

BertS schreef op dinsdag 30 juni 2020 @ 12:08:
Maar goed, je eerste reactie is al behoorlijk fel met 'no way'. En de tweede 'never again'. Dat begrijp ik best, als er door bedrijven inderdaad misbruik van wordt gemaakt door te gaan micromanagen.

Ik zei letterlijk "in zo veel detail". Dat is volgens mij heel duidelijk en expliciet dat ik het hier heb over een registratie van uren per story. Dat is waar ik falikant op tegen ben. En je gaat mij ook echt niet overtuigen dat dat ook maar enigzins nut gaat hebben, ongeacht je organisatie.

Maar dat betekent niet dat het daarmee nooit nuttig/nodig kan zijn om wel op ticket-niveau te registeren. TS had in eerste instantie ook niets gezegd over het detailniveau van die tickets, maar geeft later aan dat het meer epics is dan stories.

Zoals ik al aangaf: als het meer is dan een story kwa scope heeft het geen zin om uberhaupt in detail uren te gaan schatten. Maar hij noemde het specifiek een 'story'; ik kan ook niet ruiken dat ze termen door elkaar halen.

Ik weet best dat je in een projectorganisatie iets moet registreren.

Maar normaliter doe je dat door gewoon taken in een sprint te hangen en als die sprint dan niet af is, kijk je waarom. Als er dan weinig uren geschreven zijn op het project die week; is het omdat er veel meetings e.d. tussendoor kwamen. Als er wel veel uren op het project geschreven is, maar toch zijn er veel dingen niet af, ga je gewoon vragen aan de devs hoe dat komt. Niks van dat alles vereist een detailniveau meer dan op projectoonoderdeel. Niet op 'taken' dus. En daar is waar de OP het wel over had.

[passantr]

@SndBastard Bedankt voor je tip. De registratie gebeurt inderdaad al op projectniveau met vrij grote tickets meestal die echt niet per minuut bijgehouden hoeven worden. Betreffende je uitgebreide reactie boven de tip: zo sta ik er ook ongeveer in. Echter, ik ben wel heel blij met alle reacties, ook de wat rigide standpunten. Dat zijn standpunten (misschien "emoties") die ook bij ons kunnen leven en daar moeten we zeker rekening mee houden als we iets nieuws/aangepast urenschrijven introduceren.

Edit: vrij grote tickets

[ Voor 11% gewijzigd door passantr op 01-07-2020 08:24 ]

[DaanBiesterbos]

Het is idd het micromanagen wat een probleem is. Ik vind het niet erg om uren bij te houden. Maar ik moet geen discussies hebben over waarom dit of dat zolang duurde. Ik ben zelf ook een "opruimer". Dingen die iemand anders al mee had moet/kunnen meenemen, maar om de verkeerde redenen de taak zo snel mogelijk wilde afronden, die neem ik vaak wel mee. Dit om te voorkomen dat dingen in een later stadium veel meer tijd gaan kosten.
En denk ook aan instructies in de README. Het aanpassen bijwerken van gerelateerde commando's etc.

Ik lever goed en volledig werk af. In ieder geval is dat altijd mijn intenties.

Als je gaat zitten micromanagen en ontwikkelaars credits geeft die zich drukker maken om kwantiteit dan lopen jongens als ik inderdaad snel weg. Ondertussen loopt je backlog vol met kleine dingetjes die weer een hoop tijd kosten om te refinen, op te leveren, testen enzovoorts. Alleen zie je dat niet terug in je overzicht.

[RobIII]

DaanBiesterbos schreef op vrijdag 22 september 2023 @ 14:39:
Het is idd het micromanagen wat een probleem is. Ik vind het niet erg om uren bij te houden. Maar ik moet geen discussies hebben over waarom dit of dat zolang duurde. Ik ben zelf ook een "opruimer". Dingen die iemand anders al mee had moet/kunnen meenemen, maar om de verkeerde redenen de taak zo snel mogelijk wilde afronden, die neem ik vaak wel mee. Dit om te voorkomen dat dingen in een later stadium veel meer tijd gaan kosten.
En denk ook aan instructies in de README. Het aanpassen bijwerken van gerelateerde commando's etc.

Ik lever goed en volledig werk af. In ieder geval is dat altijd mijn intenties.

Als je gaat zitten micromanagen en ontwikkelaars credits geeft die zich drukker maken om kwantiteit dan lopen jongens als ik inderdaad snel weg. Ondertussen loopt je backlog vol met kleine dingetjes die weer een hoop tijd kosten om te refinen, op te leveren, testen enzovoorts. Alleen zie je dat niet terug in je overzicht.

Zullen we ouwe koeien (een ruim 3 jaar oud topic) laten voor wat het is? Die waarschuwing stond er niet voor niets:

Let op! De laatste reactie in deze discussie is meer dan 2 weken oud!

Als je nou echt iets heel nuttigs hebt toe te voegen waar TS iets aan heeft - allee. Maar dit was geen schop van een topic van 3 jaar oud waard