Agile Experts versus Agile Manifesto

Denkt u dat uw "lokale agile-expert" Agile Manifesto heeft gelezen? Heb jij? Nou, het is geen probleem ... als je het woord 'Agile' niet dagelijks gebruikt! Maar als je het doet (of je lokale expert doet) ... nou - dat is zoiets als mensen die te veel over religie praten, maar de Bijbel (waarschuwing voor politieke correctheid) of het heilige boek van hun keuze niet hebben geopend, omdat hun literatuurlessen 10 jaar geleden ... We vinden ze niet leuk. Voor een reden.

Ok ok, laten we geen commentaar geven op andere mensen en hun meningen. Laten we in plaats daarvan stap voor stap de 'Agile bijbel' doornemen.

Citaten uit Agile Manifesto worden gegeven in

dit soort tekstblok

en onze opmerkingen worden als volgt regelmatig weergegeven. Laten we gaan!

Het Manifest, de enige echte!

Onze hoogste prioriteit is om de klant tevreden te stellen
door vroege en continue levering
van waardevolle software.

Dit is zo'n geweldig idee! Het was echt revolutionair toen het werd gemaakt! Maar de uitvoering van dit idee is iets veel moeilijker dan deze paar regels hadden kunnen waarnemen.

Hoofdprobleem: iedereen die een direct contact met de klant heeft gehad, weet dat het punt van dit Manifest op zijn minst enigszins lastig is.

Helaas is de klant niet altijd zeker wat hij wil, of dat hij teveel dingen tegelijkertijd wil en kan hij ze niet goed prioriteren! Bovendien kan het zijn dat sommige van die dingen die klanten dachten dat hij wilde, later niet wilden ...

Als we dat buiten beschouwing laten, bewijst het punt van het Manifest zijn waarde voor het succes van het product! Maar deze uitzonderingen mogen NIET worden verwaarloosd, omdat ze fataal kunnen zijn!

Het volgende punt behandelt iets soortgelijks, laten we hier verder gaan.

Welkom bij veranderende vereisten, zelfs laat in
ontwikkeling. Agile processen benutten verandering
het concurrentievoordeel van de klant.

Dit is geweldig. Maar constant draaien en druk op het ontwikkelingsteam maakt het product kwetsbaar. Snel coderen met veel projectomleidingen, maakt de codekwaliteit van het product laag, waardoor wijzigingen moeilijker worden. Meer rationele en rustige ontwikkeling verbetert de efficiëntie bij het aanbrengen van wijzigingen in de latere stadia van productontwikkeling. Wij zijn het ermee eens dat wijzigingen moeten worden toegejuicht, maar andere contract / overeenkomstclausules moeten ook proportioneel worden gewijzigd! In veel gevallen wordt verwacht dat het product op dezelfde tijd wordt geïmplementeerd als wanneer er geen aanvullende wijzigingen vereist waren. Niet cool.

Agility gaat over klaar zijn voor de verwachte veranderingen, en niet over alles en altijd veranderen. Degenen die geaccrediteerd zijn om met potentiële klant / klant te communiceren, moeten vanaf het begin over een realistische overeenkomst onderhandelen. Vaak bespaart 10 minuten met pen en papier op het juiste moment (projectbegin) dagen, weken en zelfs maanden ontwikkeling (omleiden, draaien, veranderen) in latere stadia! Dit verslappende begin van producten moet als onprofessioneel worden beschouwd, want dat is het zeer! De "laten we gewoon de klant halen, later zullen we iets bedenken om de klus te klaren" mentaliteit is onethisch, en te vaak komen ontwikkelaars om "de dag te redden" (werk overuren, werkweekends, werk vanuit huis, werk in stressvolle omgeving) ... Niet cool. En echt - zelfs niet behendig.

Lever werkende software
vaak, van een
paar weken tot een paar maanden, met een
voorkeur voor de kortere tijdschaal.

Ik heb alleen goede ervaringen met deze. Het biedt mogelijkheden voor vroege tractie-testen-leren-verbeteren van feedback. Geweldige dingen als Agile-concept van toepassing is bij softwareontwikkeling van het benodigde type product. (Niet altijd het geval, geloof het of niet.)

Mensen uit het bedrijfsleven en ontwikkelaars moeten werken
dagelijks samen gedurende het project.

Ok, misschien niet dagelijks, maar ook - duimen omhoog! Het is ons (mensen) niet gelukt deze in de afgelopen 15 jaar te verpesten ... Geef ons de tijd.

Bouw projecten rond gemotiveerde individuen.
Geef ze de omgeving en ondersteuning die ze nodig hebben,
en vertrouw erop dat ze de klus klaren.

Dit is waar de meeste van de zogenaamde agilisten niet handelen door Agile Manifesto. Ze hebben vaak geen respect voor de personen die, zo niet experts, nog steeds betere professionals zijn, gezien hun vakgebied, dan de 'agile' projectmanager. Dat maakt dat de manager te veel bij het werk van anderen betrekt, waardoor de belangrijke 'machinetandwielen' een voor een worden verbroken. Verdere flexibiliteit en betrouwbaarheid van de "machine" voor verandering verlagen. Welke tegengesteld is.

De meest efficiënte en effectieve methode van
informatie overbrengen naar en binnen een ontwikkeling
team is een persoonlijk gesprek.

Nou, we kunnen hier niets tegen zeggen. In tegendeel, hoera daarvoor!

Werkende software is de primaire maatstaf voor vooruitgang.

Ja. Het probleem is dat veel van de zogenaamde agilisten deze clausule ook niet respecteren.

Agile processen bevorderen duurzame ontwikkeling.
De sponsors, ontwikkelaars en gebruikers moeten in staat zijn
voor onbepaalde tijd een constant tempo aanhouden.

Moeilijk te bereiken, maar natuurlijk - goede richtlijn.

Continue aandacht voor technische uitmuntendheid
en een goed ontwerp verbetert de behendigheid.

Nogmaals, helaas vergeten zogenaamde agile projectmanagers deze vaak, waardoor ze ernstige, zo niet fatale gevolgen hebben.

Eenvoud - de kunst van het maximaliseren van het bedrag
van het werk niet gedaan - is essentieel.

Gegroet, eenvoud!

De beste architecturen, vereisten en ontwerpen
voortkomen uit zelforganiserende teams.

Ave!

Het team denkt regelmatig na over hoe
om effectiever te worden, stem dan af en pas aan
zijn gedrag dienovereenkomstig.

Amen!