|
Agile-methodologie, “harde” methodologie, “iteratief model” – wat is het beste voor het ontwikkelen van uw site? Voor elk geval is er een oplossingsalgoritme. Scrum – waarom moet een klant zulke onbegrijpelijke woorden kennen? (2011) Scrum moet een vaste prijs hebben (2013) In de afgelopen twee jaar lijken de voorstanders van agile versus ‘rigide’ methoden vanuit verschillende invalshoeken het meest acceptabele ontwikkelingsmodel voor de markt te hebben benaderd. “Scrum tegen een vaste prijs” wordt simpelweg een “iteratief model” genoemd. Ik hoop dat dit bericht twee problemen zal helpen oplossen:
Samenvatting van artikelen voor klanten Als het project klein is, doet de methodologie er niet toe. Iedereen kan worden gebruikt. Als het project groot is, kies dan voor een Agile methodologie. Als het project groot is en je het wantrouwen van Agile of een specifieke aannemer niet hebt overwonnen, kies dan voor iteratieve ontwikkeling. Kenmerken van webprojecten Drie hoofdkenmerken van elk webontwikkelingsproject vanuit het oogpunt van de klant: Hoge omgevingsvariabiliteit. Het internet verandert zo snel dat de verwachtingen of plannen van gisteren misschien niet relevant zijn voor de realiteit van vandaag (zowel ten goede als ten kwade). Hoge mate van onzekerheid. Als u een volledig nieuw project ontwikkelt en start, heeft u alleen hypothesen. Hypothesen over uw doelgroep en zijn gedrag, over de competitieve omgeving, over de effectiviteit van een of ander kanaal om bezoekers aan te trekken. In het ergste geval zijn er geen hypothesen, alleen ‘ik heb een website nodig’. Beperkte middelen. Bij het bestellen van een website zijn klanten bijna altijd beperkt in geld, of in de tijd vóór de lancering, of in beide. Er zijn andere opties die al lang bekend zijn in andere bedrijfstakken. Laten we hun voor- en nadelen begrijpen. WATERVAL Voor een klein project werkt “waterval”. Voor een groot project is een “waterval” een sneeuwbal van problemen. Het watervalmodel is over het algemeen ongevoelig voor variabiliteit. De risico’s van het helemaal niet starten van een project of het doen van iets ondoelmatigs nemen exponentieel toe met de complexiteit en de duur van het project. Een klein project (landingspagina, mini-site, promo-site) is goed gedaan “bij de waterval”. Zodra een project wordt geschat op 6 maanden ontwikkeling of meer, sneeuwt de risico’s die samenhangen met variabiliteit. Uw bedrijf kan gedurende deze tijd veranderen en de vereisten voor het project fundamenteel veranderen. Dit is de belangrijkste reden waarom lange projecten helemaal niet starten. Concurrenten kunnen een soortgelijk project voor u lanceren. Een grote speler kan een product of functionaliteit uitrollen die uw project onbruikbaar maakt. Het consumentengedrag kan aanzienlijk veranderen (ze schakelen bijvoorbeeld over van laptops naar tablets). Dit model is weinig gevoelig voor hoge onzekerheid. Webstudio’s en bureaus werken professionele vaardigheden bij en maken het ontwikkelingsproces ijverig ingewikkeld en splitsen het op in steeds meer fasen. Dit wordt gedaan om de risico’s verbonden aan onzekerheid te verkleinen. Hoe groter het project, hoe slechter het werkt. Laten we ons een ontwikkeld watervalproces voorstellen van een goede webstudio. Het omvat bijvoorbeeld:
In eerste instantie lijkt het een goed proces om met onzekerheid om te gaan:
En in het echt ziet het er zo uit:
als resultaat van een lange en sombere strijd en het proces van goedkeuringen, lost de artiest in het ontwerp een aantal van zijn eigen niet-geverifieerde hypothesen en ‘wensen’ op die de klant heeft doorgevoerd, bij ontwikkeling en inbedrijfstelling wordt een project gelanceerd op basis van niet-geverifieerde hypothesen over de doelgroep en de levenservaring van de aannemer en de klant. Als het een groot project betreft, zijn de belangrijkste risico’s die samenhangen met onzekerheid: U mag niet wachten op de foto’s als u niet actief betrokken bent bij het ontwerpproces. Samen met de performer kun je onjuiste hypothesen over de doelgroep te diep in je wereldbeeld inbedden. Hypothesen zullen vroeg of laat moeten worden getest. In het watervalmodel zal het tot dit moment erg lang duren – het hele project moet worden ontwikkeld en gelanceerd. Ten slotte gaat het watervalmodel goed om met resourcebeperkingen. Maar alleen op voorwaarde van goed beheer. Het betekent: Vereisten voor het project moeten aan het begin van het project worden vastgesteld en blijven ongewijzigd voordat de site in gebruik wordt genomen. Middelen moeten op tijd worden toegewezen. De beoordeling van de benodigde middelen door de aannemer dient voldoende nauwkeurig te zijn. In het leven pakt het in alle opzichten anders uit: de klant verandert de eisen, de artiesten missen hun cijfers (vooral bij langlopende projecten!), Goedkeuringen en betalingen lopen vertraging op. Dit alles wordt nog verergerd door de vluchtigheid en onzekerheid die deze problemen veroorzaken. FLEXIBELE METHODOLOGIEËN Bij agile ontwikkelmethoden weet je precies hoeveel je gaat uitgeven, je zult zeker op tijd zijn, maar je kunt er niet 100% zeker van zijn hoeveel je uiteindelijk krijgt. Agile-praktijken zijn geëvolueerd in de ontwikkeling van desktopsoftware en webdiensten. De populaire namen die veel worden gehoord zijn Agile, Scrum en Fix time, Fix budget, Flex scope. De belangrijkste ideeën van het Agile-manifest:
Bij al deze technieken gebeurt de ontwikkeling in snelle iteraties. Om Wikipedia te citeren: “elke iteratie zelf ziet eruit als een miniatuursoftwareproject en omvat alle taken die nodig zijn om kleine verbeteringen in functionaliteit te produceren: planning, vereistenanalyse, ontwerp, programmering, testen en documentatie.” Agile-methodologieën zijn vriendelijk met variabiliteit. U krijgt een constant “groeiende” site, die bij elke iteratie kan worden “omgeleid”, afhankelijk van de verkregen statistieken, bewezen verkeerde hypothesen, enzovoort. U kunt sitevereisten rangschikken en deze implementeren, te beginnen met de belangrijkste. Agile-methodologieën gaan om met onzekerheid wanneer prestatiestatistieken van tevoren duidelijk worden beschreven en u die meetwaarden continu meet. Met snelle iteraties kunt u elke hypothese over de doelgroep testen en ineffectieve tools weggooien zonder te investeren in een groot ontwikkelingsblok. U kunt bijvoorbeeld zien dat uw publiek geen online calculator nodig heeft voor de kosten van de dienst, maar de gebruikelijke vorm van terugbelverzoek werkt goed. Agile-methodologieën zijn vriendelijk met beperkte middelen. U hoeft zich geen zorgen te maken over het halen van de deadline. U hoeft zich geen zorgen te maken dat u het budget overschrijdt. Agile-methoden hebben maar één addertje onder het gras: als de omstandigheden van het project zijn veranderd of de uitvoerder een fout heeft gemaakt bij het inschatten van het tijdsbestek (hij slaagde er niet in om alle functionaliteit in één iteratie te ontwikkelen), dan krijgt de klant minder functionaliteit voor hetzelfde geld. SCHEIDING VAN VERANTWOORDELIJKHEID EN RISICO’S IN HET PROJECT Agile-praktijken delen risico’s eerlijk tussen klant en uitvoerder. De waterval dwingt de aannemer om de risico’s opnieuw in de prijs te introduceren. Leg de kaarten op tafel. Wanneer u een site bestelt met de gebruikelijke watervalontwikkeling, kunt u er niet 100% zeker van zijn dat de site op tijd met volledige functionaliteit wordt opgeleverd. De praktijk leert dat minimaal twee derde van de projecten op de markt met vertraging wordt opgeleverd. Daarom zijn strikte contracten, boetes, straffen en bedreigingen psychologische bescherming van de klant. Het geeft geen garanties, want elk project heeft inherente risico’s. Het beste wat een klant en artiest kan doen, is er geen nieuwe aan toevoegen. Zoals we hierboven hebben besproken, houden de belangrijkste ‘natuurlijke risico’s’ van het project verband met het feit dat:
De overige risico’s worden door de deelnemers toegevoegd door de ruwheid van het proces, gebrek aan professionaliteit en wantrouwen jegens elkaar. Bij het vaststellen van de timing, kosten en omvang van functionaliteit zijn alle risico’s voor rekening van de aannemer. Het is logisch dat de aannemer de timing of kosten van een uur overschat om de risico’s te neutraliseren. In wezen fungeert het als een verzekeringsmaatschappij voor zichzelf. Als de artiest goed is, de deadline en het budget heeft gehaald, betaalt de klant in wezen extra geld. Hoe langer het project, hoe groter de risico’s, hoe meer de aannemer is herverzekerd, hoe meer de opdrachtgever betaalt. Dus met de watervalbenadering: de klant:
Bij agile methoden worden risico’s gedeeld tussen de aannemer en de klant. De aannemer draagt reputatierisico’s met consistent foutieve timingschattingen. De klant draagt financiële risico’s in geval van per ongeluk foutieve timingschattingen. Maar de risico’s van variabiliteit en onzekerheid worden genivelleerd door het proces zelf. Dat wil zeggen, met agile methoden, de klant:
ITERATIEVE ONTWIKKELING Het iteratieve model (ontwikkeling door snelle iteraties, waarbij de deadlines, kosten en omvang van het werk strikt zijn vastgelegd) is een alternatief voor flexibele methoden wanneer het project groot is en het vertrouwen tussen de aannemer en de opdrachtgever nog niet is gevestigd. Bij iteratieve ontwikkeling wordt de eerste klassieke ontwerpfase uitgelicht (zelfs in een apart contract). Het is belangrijk dat het duidelijk beperkt is in de tijd en nodig is om de onzekerheid in een beperkte tijd (bijvoorbeeld een maand) zoveel mogelijk te verminderen. Na het ontwerp bepalen de opdrachtgever en de aannemer samen de belangrijkste functionaliteit die in de eerste iteratie gelanceerd moet worden, leggen de kosten en het tijdschema vast. De looptijd van elke iteratie (ontwerp – lay-out – ontwikkeling – testen en lanceren) is van een maand tot drie. De reikwijdte van de functionaliteit in de eerste iteratie ligt strikt vast. De aannemer en de opdrachtgever komen overeen dat als er nieuwe “wensen” verschijnen tijdens de eerste iteratie, deze worden overgedragen naar de tweede iteratie. Vervolgens wordt de eerste iteratie ontwikkeld en gelanceerd met behulp van het watervalmodel. De aannemer draagt alle verantwoordelijkheid en alle risico’s voor het feit dat een vaste hoeveelheid werk wordt uitgevoerd in een vaste tijd en een vast budget (de nuances van de goedkeuringen van de klant laten we buiten de haakjes). De vereisten voor de tweede iteratie worden parallel verzameld. Aan het einde van de eerste iteratie definiëren de klant en de aannemer samen de functionaliteit voor ontwikkeling in de tweede iteratie, stellen de parameters ervan vast, enzovoort. Iteratieve website-ontwikkeling is vriendelijk met vluchtigheid, onzekerheid en beperkte middelen, net als in het geval van agile methoden. Iteratieve ontwikkeling is winstgevender dan een waterval op grote projecten, omdat de uitvoerder minder wordt opgelegd aan risico’s en ook de cashflow wordt genivelleerd. Er wordt steeds vaker betaald op precies dezelfde manier als bij flexibele methoden. Iteratieve ontwikkeling is voor sommige klanten psychologisch comfortabeler. Laten we de samenvatting herhalen
https://www.webdeveloper.today/2021/01/django-custom-template-tags-en-filters.html |
| https://webdevelopmentapp.com/nl/prices.html |
