# data[].attributes.body
Kritikk:
- fatal feil å kutte/minimere planleggingsfasen
- pair programming er overflødig
- brukerhistorier kan være i konflikt

Argumenter:
- planlegging har vist seg å være hensiktsmessig
- pair programming fungerer kun i noen situasjoner

Enig i:
- planlegging er lurt/nødvendig
- for mye hype om pair programming

Uenig i:
- at det er umulig å omgjøre et dårlig utgangspunk til et godt resultat ved iterativ prosess

# data[].attributes.body
Smidighet kan brukes som en unnskyldning til å planlegge dårlig

# data[].attributes.body
Går for langt i å unngå "analysis-paralysis". Planlegging er nødvendig

Overanvendelse av agile metoder. treng feks ikkje bruke parprogramering heile tida, men nyttig i noen tilfeller.

User stories != komplett systemspesifikasjon

Kan bli veldig mykje refactorering når ein ikkje planlegger

# data[].attributes.body
* Hva er hovedkritikken mot smidige prinsipper / metoder?

Hovedkritikken går på hvordan enkelte som bruker Agile bruker rammeverket som en unnskyldning for å droppe en planleggingsprosess på forhånd

Den andre delen er at brukerhistoriene brukes som en magisk løsning på alt av Agile. "Vi bruker agile, så la oss skrive noen brukerhistorier, så vil alt magisk funke"

* Hva er argumentene for hovedkritikken?

At selv om det er lurt å starte med programmering tidlig, kan ikke dette brukes på bekostning av en planleggingsfase i starten; dette påvirker prosjektet negativt. Dette føles generelt ut som et problem som er forårsaket av dårlig kjenskap til Agile.

* Hvilke deler av hovedkritkken er du enig i?

Er enig i det meste, men er spesielt enig i kritikken mot parprogrammering. I prosjektet i forrige semester, opplevde jeg parprogrammering som helt meningsløst. Gruppa mi var enig, men her er mine grunner:
1. Kunnskapsforskjell gjør at jeg var den eneste som funket som en kritisk reviewer av kode.
2. Bortkastet tid av resurser; hvis alle kan programmere, går det mye fortere frem. Code review kan heller gjøres senere, gjerne som en del av en pull request.

Er også sterkt enig i kritikken mot brukerhistoriene; de er forferdelig dårlige for å formulere krav som kan implementeres av en programmerer. Det kunne funket hvis noen hadde ansvar for å bryte brukerhistorier ned i konkrete issues, men dette medfører mye ekstraarbeid.

Poenget med å hjelpe programmerere å implementere ting skjer egentlig ikke sånn brukerhistoriene er satt opp per i dag. Ja, fint for ledelsen og alle de, men vi er her for å lære programmering, ikke administrasjon og økonomi, og å holde aksjeholdere i godlunet.

* Hvilke motargumenter har du på det du ikke er enig i?

Ingen; synes formaliseringen av Agile fører til alt for mye idioti og dårlig organisering -- problemer den egentlig skal unngå. Synes også det er fremstilt på en så overkomplisert måte at det i seg selv er årsaken til at Agile blir brukt feil rundt i industrien.

# data[].attributes.body
Skal ikke user stories brukes som abstrakte ønsker for å lage konkrete tickets?

# data[].attributes.body
User stories er et nyttig verktøy for ledelsen, og burde brukes hyppig. Det som heller burde være budskapet, er å ikke vektlegge de så mye. De gir heller et bilde av hensikten med oppgaven fra ledelsen sitt perspektiv, men burde ikke brukes som noe mer enn ett støtte vedlegg til oppgaven/ticketen.

# data[].attributes.body
Feil. Dette er hele poenget med refactoring. Man kan også ta utgangspunkt i nåværende implementasjon for å lage en som er bedre.

# data[].attributes.body
Teksten handler om ulike aspekter av software utvikling som er ulike nyttige og effektive. Eksempelvis finnes det konsepter som er overhypede: Pairprogramming. The ugly: konspeter som er bra med kan bli overgjorde, excessive planning iwth no actual code early on. The good: Prinsipper som er bra og fungerer, eksempelvis å bare ta de oppgaver some r viktige nå og fokusere på disse, si nei til de som kan gjøres i fremtiden. The brilliant: Branching is evil, sprints cant grow,

# data[].attributes.body
- Manglende planlegging
- Overhyped

# data[].attributes.body
Hva er hovedkritikken mot smidige prinsipper / metoder?
- Smidige metoder er ikke en defacto løsning på alle problemene.
-Det er ikke en revolusjon, men en naturlig byggestein på development prosessen.
- Mye er "hyped", det er da ikke bedre enn andre metoder.
Hva er argumentene for hovedkritikken?
- Det er et verktøy som skal læres og kan tilpasses.
- Prøve forskjellige metoder innenfor smidige prinsipper, finne når de fungerer.

# data[].attributes.body
Hovedkritikken går ut på at smidige prinsipper blir sett på som en åpenbaring, og at alle bør følge alle prinsippene slavisk. Artikkelforfatter bryter ned smidige metoder etter hvor hensiktsmessig han føler hver av dem er.

Jeg er enig i kritikken mot parprogrammering. Jeg har alltid opplevd dette som noe redudant, i alle fall i en situasjon der begge utviklerne er på et jevnt ferdighetsnivå. For meg virker parprogrammering som en bedre egnet metode i en situasjon der den ene utvikleren er under opplæring.

# data[].attributes.body
Hva er hovedkritikken mot smidige prinsipper/metoder?

Artikkelen presenterer at det er ikke enten smidig utvikling eller fossefallsmetoden som gjelder, og mange utviklere har benyttet seg av konsepter innenfor smidig utvikling før. Smidig utvikling presenter seg som en revolusjon, men artikkelen mener at dette ikke er riktig.

Artikkelen kritiserer også hvordan agile underlegger det å planlegge ordentlig. Det er ikke alltid det er lurt å bare begynne å kode. Noen prosjekter trenger en nøye planleggingsfase før man kaster seg inn i det.

Artikkelen retter også kritikk mot brukerhistorier og at de er for spesifikk og simpel i natur. En brukerhistorie vil kun gi utvikleren et veldig spesifikt problem å løse, som ikke nødvendigvis kan anvendes på alle type brukere.

Hva er argumentene for hovedkritikken?

Argumentet bak mye av kritikken er rettet mot smidig utviklings litt sporadiske og nesten anarkiske natur og også mot brukerhistoriers manglede evne til å gi et fullt bilde av use-cases for prosjektet.

Hvilke deler av hovedkritikken er du enig i?

Er enig i kritikken mot brukerhistorier, da de i noen tilfeller kan være for enkle. I IT1901 glemte vi en ganske “stor” funksjon, fordi brukerhistoriene våre ikke dekte dem

Hvilke motargumenter har du på det du ikke er enig i?

Er ikke helt enig i kritikken mot det å ikke planlegge ordenltig. Smidig utvikling skal ikke anvendes i alle situasjoner og det er viktig å vite når man skal bruke det og når man skal modifisere metodene. Argumentet til artikkelen faller fullstendig sammen når man kommer på at smidig utvikling ikke er en streng oppskrift til hvordan man skal utvikle, og at man kan modifisere dem til å passe sitt prosjekt.

# data[].attributes.body
Lag et notat:
Hva er hovedkritikken mot smidige prinsipper / metoder?
Hva er argumentene for hovedkritikken?
Hvilke deler av hovedkritkken er du enig i?
Hvilke motargumenter har du på det du ikke er enig i?