Agile eksperter vs agile manifest

Tror du din "lokale agile ekspert" har læst Agile Manifesto? Har du? Det er ikke et problem… hvis du ikke bruger ordet "Agile" til daglig! Men hvis du gør (eller det gør din lokale ekspert) ... ja - det er noget som folk, der taler for religion for meget, men ikke har åbnet Bibelen (alarm om politisk korrekthed) eller den hellige bog efter eget valg, siden deres litteraturklasser For 10 år siden ... Vi kan ikke lide dem. Af en grund.

Ok ok, lad os ikke kommentere andre mennesker og deres meninger. Lad os i stedet gå gennem ”Agile bibelen” trin for trin.

Citater fra Agile Manifesto vil blive givet i

denne type tekstblok

og vores kommentarer gives i regelmæssigt led som dette. Lad os gå!

Manifestet, det eneste!

Vores højeste prioritet er at tilfredsstille kunden
gennem tidlig og kontinuerlig levering
af værdifuld software.

Dette er sådan en god idé! Det var virkelig revolutionerende på det tidspunkt, det blev lavet! Men gennemførelsen af ​​denne idé er noget meget hårdere, end disse få linjer kunne have opfattet.

Hovedproblem: Alle, der har haft en direkte kontakt med kunden, ved, at dette manifestets punkt i det mindste er noget vanskeligt.

Desværre er kunden ikke altid sikker på, hvad han / hun ønsker, eller han / hun ønsker for mange ting på samme tid, og kan ikke prioritere dem ordentligt! Derudover kan det være, at nogle af de ting, som kunden troede, han ønskede, senere ikke ønskede ...

Hvis vi lægger det til side - viser Manifestets pointe dets værdi for produktets succes! Men disse undtagelser bør IKKE overses, da de kan være dødelige!

Næste punkt dækker noget lignende. Lad os fortsætte dette emne der.

Velkommen til at ændre krav, selv sent på
udvikling. Agile processer sele ændring for
kundens konkurrencefordel.

Dette er godt. Men konstant drejning og pres på udviklingsteamet gør produktet skrøbeligt. Kodning hurtigt med masser af projektomdirigeringer gør produktets kodekvalitet lav, så ændringer bliver sværere. Mere rationel og rolig udvikling forbedrer effektiviteten ved at foretage ændringer i de senere stadier af produktudvikling. Vi er enige om, at ændringer bør hilses velkommen, men andre kontrakt / aftaleklausuler bør også ændres forholdsmæssigt! I mange tilfælde forventes produktet at blive implementeret på samme tid, som det ville have været i tilfælde af, at der ikke er behov for yderligere ændringer. Ikke sejt.

Agility handler om at være klar til de forventede ændringer og ikke om at ændre alt og altid. Dem, der er akkrediteret til at kommunikere med potentiel kunde / kunde, skal forhandle om realistisk aftale helt fra starten. Ofte sparer 10 minutter med pen og papir i det rigtige tidspunkt (projektstart) dage, uger og endda måneder med udvikling (omdirigering, drejning, ændring) i senere faser! Denne slacking i produktstart bør betragtes som uprofessionel, fordi det meget er! ”Lad os bare få klienten, senere vil vi tænke på noget for at afslutte jobbet” mentalitet er uetisk, og alt for ofte kommer det udviklere til at ”redde dagen” (arbejde overarbejde, arbejde weekender, arbejde hjemmefra, arbejde i stressende omgivelser)… Ikke cool. Og virkelig - ikke engang smidig.

Lever arbejdssoftware
ofte fra a
et par uger til et par måneder, med en
foretrækker den kortere tidsplan.

Jeg har kun gode oplevelser med denne. Det giver muligheder for tidlig trækkraft-test-læringsforbedrende feedback. Fantastiske ting, hvis Agile-konceptet er anvendeligt i softwareudvikling af den nødvendige type produkt. (Ikke altid tilfældet, tro det eller ej.)

Forretningsfolk og udviklere skal arbejde
sammen dagligt gennem hele projektet.

OK, måske ikke dagligt, men også - tommelfingeren op! Vi (mennesker) har ikke formået at ødelægge denne i de sidste 15 år ... Giv os tid.

Byg projekter omkring motiverede individer.
Giv dem det miljø og den støtte, de har brug for,
og stole på dem for at få jobbet gjort.

Det er her de fleste af de såkaldte agilister undlader at handle af Agile Manifesto. De mangler ofte respekt for de personer, der, hvis ikke eksperter, stadig bedre fagfolk, der overvejer deres ekspertise, end den ”agile” projektleder. Det får manageren til at involvere for meget i andre menneskers arbejde, der bryder de vigtige “maskindrev” én ad gangen. Gør yderligere "maskine" smidighed og pålidelighed til ændring lavere. Hvilket er imod smidigt.

Den mest effektive og effektive metode til
formidle information til og inden for en udvikling
holdet er ansigt til ansigt samtale.

Vi kan ikke sige noget imod denne. I modsætning hertil hør for det!

Arbejdssoftware er det primære mål for fremskridt.

Ja. Problemet er, at mange af de såkaldte agilister heller ikke respekterer denne klausul.

Agile processer fremmer bæredygtig udvikling.
Sponsorer, udviklere og brugere skal kunne
at opretholde et konstant tempo på ubestemt tid.

Svært at opnå, men selvfølgelig - god retningslinje.

Kontinuerlig opmærksomhed på teknisk ekspertise
og godt design forbedrer smidighed.

Igen, desværre, glemmer såkaldte agile projektledere ofte denne, hvilket får alvorlige, hvis ikke fatale, konsekvenser.

Enkelhed - kunsten at maksimere beløbet
af ikke-udført arbejde - er vigtigt.

Hilsen, enkelhed!

De bedste arkitekturer, krav og design
dukker op fra selvorganiserende teams.

Ave!

Med jævne mellemrum reflekterer teamet hvordan
for at blive mere effektive, derefter justeres og justeres
dens opførsel i overensstemmelse hermed.

Amen!