Project - voorbereidingen

[Verwijderd]

Hoi allemaal,

Ik heb een goed idee voor een stukje software dat ik graag wil ontwikkelen, iets wat ik in mijn portfolio kan stoppen en waarmee ik mijn Javaskills wat kan verbeteren. Ook hoop ik hiermee mijn volleybalvereniging te kunnen helpen. Nu heb ik niet zozeer een vraag over het technische gedeelte, maar meer over de voorbereiding. Wat is belangrijk om te maken/onderzoeken in de voorbereidende fase? Is het een goed idee om documenten als een Plan van Aanpak en Requirementsanalyse op te stellen als je aan de slag gaat met (kleine) privéprojecten?
Misschien is dit een beetje een stomme vraag maar ik heb nog nooit zoiets groots voor mezelf gemaakt, alleen wat kleinere dingetjes voor school en werk moeten doen. Tips zijn ontzettend welkom!

Groeten Marjolein

[Verwijderd]

Wanneer het project niet alleen door jou wordt onderhouden is documentatie altijd goed. Ook wanneer je er na een jaar van afwezigheid weer eens naar moet kijken is het vervelend om je code in te duiken.
Ik zou een ontwikkelmethodiek kiezen, dis komt je later ook ten goede namelijk, hier is genoeg te vinden op het internet. Het voordeel daarvan is dat je bij je scope blijft en vaak een goede planning hebt, en het dus geen eindeloos pruts-project wordt

[CodeCaster]

Verwijderd schreef op zaterdag 07 april 2012 @ 11:23:
Plan van Aanpak en Requirementsanalyse

Ik zou niet weten waarom je deze niet zou maken.

In je plan van aanpak schrijf je voor jezelf en je klant op hoe je het project gaat doen. Essentieel zijn een tijdsschatting en het wat en wanneer van opleveren.

Requirements zijn nog onmisbaarder, omdat je daarin afspreekt in welke staat het project moet zijn om 'klaar' te zijn. Zo blijf je niet eeuwig features toevoegen à la "Oh ja, als ik X doe moet het programma ook Y doen".

[Verwijderd]

CodeCaster schreef op zaterdag 07 april 2012 @ 11:50:
[...]

Ik zou niet weten waarom je deze niet zou maken.

De belangrijkste reden waarom ik erover twijfelde of ik deze moest maken is dat dit project naast mijn (school)werk komt en ik een druk blok in ga. Dit project heeft een lagere prioriteit, en dus is het lastig om dan een planning te maken.

Requirementsanalyse was ik inderdaad wel vrij zeker van, maar heb ook al wel een redelijk duidelijk beeld van hoe de database eruit moet komen te zien en hoe het geheel moet werken, dus dat moet niet zo'n probleem zijn.

[Verwijderd]

Verwijderd schreef op zaterdag 07 april 2012 @ 11:54:
[...]


De belangrijkste reden waarom ik erover twijfelde of ik deze moest maken is dat dit project naast mijn (school)werk komt en ik een druk blok in ga. Dit project heeft een lagere prioriteit, en dus is het lastig om dan een planning te maken.

Requirementsanalyse was ik inderdaad wel vrij zeker van, maar heb ook al wel een redelijk duidelijk beeld van hoe de database eruit moet komen te zien en hoe het geheel moet werken, dus dat moet niet zo'n probleem zijn.

Juist wanneer je het druk hebt is een planning essentieel

[Freeaqingme]

Ik zou geen langetermijns planning maken: keer op keer blijkt dat dat niet werkt met software ontwikkeling. Waarom? omdat je al na 10 % van je project kan zien dat bepaalde dingen toch niet zo handig werkte als je verwacht had, en dat je daarom toch beter dingen aan kan passen.

Dat is een van de redenen waarom scrum zo populair is. Wat ik zou doen is een lijst opstellen met 'userstories'. Regels in de vorm: Als <persoon/rol> wil ik <actie> kunnen doen, zodat <businessvalue uitleg>
Bijvoorbeeld: Als boekhouder wil ik een overzicht hebben van alle verlopen facturen zodat hier tijdig actie op ondernomen kan worden.
of: Als gebruiker die de applicatie afsluit wil ik gevraagd worden of ik mijn wijzigingen wil opslaan zodat er niet zomaar wijzigingen verloren gaan.

Door user stories te hanteren in plaats van features voorkom je dat je over een jaar niet meer weet waarom feature XYZ nou zo belangrijk was. Daarnaast helpt het als je met anderen wil brainstormen over je applicatie.

Vervolgens kan je dan die userstories prioriteren: zorgen dat de belangrijkste bovenaan staan. Hierna kan je bijvoorbeeld per 3 weken een planning maken: de meest belangrijke user stories pak je op, en je zorgt dat je na die 3 weken een werkend product hebt - waar de user stories die je hebt geimplementeerd /volledig/ in verwerkt zitten. Dit zorgt er dan voor dat anderen het product kunnen testen, en je ook zelf goed kan ervaren wat wel/niet werkt. Ook zorgt dit ervoor dat mensen geen jaren hoeven te wachten tot jij vindt dat je product klaar is.

Hierna kan je opnieuw naar je user stories kijken, eventueel weer herprioriteren, en dan weer 3 weken de belangrijkste implementeren.

Uiteraard zijn er heel veel methodes om software te implementeren, maar deze heeft mijn absolute voorkeur

[NMe]

Freeaqingme schreef op zaterdag 07 april 2012 @ 13:55:
Ik zou geen langetermijns planning maken: keer op keer blijkt dat dat niet werkt met software ontwikkeling. Waarom? omdat je al na 10 % van je project kan zien dat bepaalde dingen toch niet zo handig werkte als je verwacht had, en dat je daarom toch beter dingen aan kan passen.

In dat geval heb je je planning niet goed gemaakt en moet je daarvan leren en het de volgende keer beter doen.

Ik moet eerlijk bekennen dat ik meestal geen planning maak maar een tijdsindicatie: "als ik dit, dit en dat doe, dan zo ik daar zo lang over." Vervolgens doe ik die twee maal anderhalf (of maal twee, afhankelijk van hoe vaak een klant gebruikelijk zijn specs wijzigt en leg ik dat over mijn verwachte beschikbare tijd heen en dan heb ik een grove planning van wanneer het af is.

Requirements zijn wel ronduit onmisbaar, juist als je geen tijd hebt om foute interpretaties te fixen en als je geen tijd hebt om extra onvoorziene features toe te gaan voegen. In mijn ervaring zijn juist de mensen/bedrijven die je matst door een vriendenprijs te vragen of het zelfs voor niks te doen de grootste zeikerds.

[Verwijderd]

Ik vind het erg lastig om voor dit project een conrete planning te maken, gezien er geen deadline is en het ook alleen iets is waarmee ik kennis op kan doen. Als het dan later in gebruik genomen wordt zou mooi meegenomen zijn, maar dat is niet het belangrijkste.

@ Freeaqingme: Ik moet zeggen dat die methode wel prettig klinkt. Is dit hetzelfde als use cases? Wij leren op school wel hiermee te werken, en deze use cases/requirements te prioriteren met MoSCoW. Daarna is het gewoon kijken wat je met de gegeven tijd kan doen.

[NMe]

Verwijderd schreef op zaterdag 07 april 2012 @ 15:40:
Ik vind het erg lastig om voor dit project een conrete planning te maken, gezien er geen deadline is en het ook alleen iets is waarmee ik kennis op kan doen. Als het dan later in gebruik genomen wordt zou mooi meegenomen zijn, maar dat is niet het belangrijkste.

Misschien niet, maar andersom is het kunnen inschatten hoeveel werk iets is en hoe lang je er dus over doet een erg belangrijke kwaliteit waar lang niet iedereen even goed in is. Je doet er goed aan om je aan te leren die inschatting tóch altijd te maken. Zeker als je er geld voor krijgt, want je wil geen verlies gaan maken.

@ Freeaqingme: Ik moet zeggen dat die methode wel prettig klinkt. Is dit hetzelfde als use cases? Wij leren op school wel hiermee te werken, en deze use cases/requirements te prioriteren met MoSCoW. Daarna is het gewoon kijken wat je met de gegeven tijd kan doen.

Ik ken de term userstories zelf niet maar als ik het zo lees is een usecase meer het "hoe" en een userstory meer de "waarom". Uit zo'n story kun je wel een usecase schrijven.

[Freeaqingme]

NMe schreef op zaterdag 07 april 2012 @ 15:18:
[...]

In dat geval heb je je planning niet goed gemaakt en moet je daarvan leren en het de volgende keer beter doen.

Die vind ik iets te makkelijk

Het is belangrijk om uren in te (kunnen) schatten, en dit constant te verbeteren. Ik heb FO's gezien van 500 bladzijden, en planningen van 18+ maanden. Toch blijkt iedere keer dat een klant - hoe goed je hem ook begeleidt, hoeveel presales, business en technisch consultants je ook bij je klant neer zet - bij een eerste (deel)oplevering een klant toch nieuwe inzichten opdoet.

Door dan het ontwikkelproces op te delen in behapbaardere brokken kan de klant nog 'tijdens' het proces zijn ideeen bijstellen. Zo hebben we klanten (nationale uitgever, een luchtvaartmaatschappij, verzekeraars, etc) die samen met ons iedere twee weken bepalen welke functionaliteiten zij willen hebben, om vervolgens ook per twee weken gefactureerd te worden.

Het schatten? Dat doen we zeker. Een klant levert ons dus iedere 2 weken een lijst aan met tientallen user stories, geprioriteerd en wel. Een developmentteam kijkt vervolgens hoeveel uur ze beschikbaar hebben, om vervolgens iedere userstory in te schatten (beginnende bij de belangrijkste), totdat hun twee weken vol zitten. Vervolgens zorgt zo'n team er dan dus ook voor dat na 2 weken dit daadwerkelijk 100% af is en geimplementeerd is. Het product wordt vervolgens door het team gedemo-ed, en kan op dat moment in principe live.