Agil, Scrum - R*vknulla programmerare?

Stället jag jobbar på funderar på att börja med det här.

Rätt skeptisk. Känns mest som det är ett sätt att göra programmerare till robotar. Ingen frihet. Idag skall jag göra just det här. Blir jag sen med just det måste jag berätta det för alla i morgon.

Känns inte som nåt för en högt kvalificerat, intelligent profession. Dessutom så lär man skapa en skaplig stress, teamets medlemmar övervakar varandras framsteg, chefen eller projektledaren behöver inte.

Reaktioner på detta från er som jobbar med detta. Bara ett sätt att trycka ner oss? Bara för att de kan, då man kan köpa Kineser och Indier för en spottstyver?

Du orkar inte förklara kortfattat för oss andra vad "Agil, Scrum" är ?

läs, http://sv.wikipedia.org/wiki/Agil_systemutveckling http://sv.wikipedia.org/wiki/Scrum

jag har inte jobbat speciellt mycket agilt så jag borde nog inte uttala mig, men jag är väl inte frälst precis.. men samtidigt.. är vi hantverkare/fabriksarbetare eller konstnärer?

Det är en modell för företag som gett upp det här med god design och bara vill få saker gjorda. Slutresultatet är att folk bara vill lösa sina work items och gå hem. Koden blir fruktansvärd efter ett tag och äter upp tid, men det kan ju ofta vara en fördel för konsultbolag.

det handlar om att skapa kortare feedbackloopar, jobba närmre kunden och jobba med rätt saker. jag skulle vilja påstå att det ger mer frihet än någon gammal vattenfallsstruktur eller vad nu alternativet skulle vara där man försöker gissa sig till hur allt ser ut om 18 månader.

det finns inget som säger att man ska slänga ut design eller skriva dålig kod, däremot så sätter man sig inte och planerar hur varje komponent kommer att se ut in i minsta detalj, för om produktägaren vill ändra något efter ett demomöte så har man slösat tid på att designa en komponent som kanske inte kommer att finnas med i den slutgiltliga produkten.

Om du jobbar med skitstövlar antar jag att det blir stressigt och jobbigt. Då rekommenderar jag dig att byta jobb.

Om du jobbar med bra människor funkar det bra (imo bättre än alternativa former). Daglig rapportering är inte en börda, det är ett tillfälle att diskutera igenom problem, få ideer och hjälp, och lyfta svåra problem. Jag tycker personligen att det handlar mer om kunskapsspridning än om övervakning, och f.ö. anser jag inte ens att övervakning i det här sammanhanget ens är något dåligt. Om inte hela utvecklingsteamet är på samma noter m.a.p. hur programmet bör utformas lär man ändå stöta på problem när tankesätt som ligger i konflikt med varandra krockar.

Projektledarens roll kvarstår tycker jag, den är att se till att utvecklarna har allt de behöver (krav, information, icke utvecklingsresurser såsom pixeltrixare, copys, domänspecialister, testare &c), och hålla reda på projektets övergripande status. Om PL har ägnat sig åt att detaljgranska folk innan har något varit fel.

F.ö. blir scrum-möten o.dyl. mycket mindre spända om man jobbar i par. Det är mindre chans att folk börjar se på en som en slacker eller ett pucko om det faktiskt var ett par som "misslyckades" med en uppgift. Då är det mer ett tecken på att uppgiftens svårighetsgrad missbedömdes, och att det är dags att omvärdera den. Det kanske inte eliminerar, men mildrar iaf kraftigt det eventuella stressmomentet som man annars skulle känna om en uppgift inte är klar i tid. (Detta utöver alla andra fördelar som kommer med parprogrammering.)

Agil systemutveckling med Scrum är något som utnyttjas flitigt på min arbetsplats och hittills har jag inte hört någon säga ett negativt ord om det. fördelen som nån redan sagt är ju at man kojmmer närmare kunden och att det snabbt går att byta inriktning på utvecklingen om det skulle visa sej att kraven ändras under utvecklingens gång. Dessutom är det ett sätt att lära sej hur lång tid saker tar att göra så att det med tiden blir enlare att planera framtida "sprintar" med.

På det hela taget är det här ett betydligt bättre sätt att jobba än nån vattenfallsmodell som nån redan nämnt. Har du haft en projektledare som övervakat dej har han missuppfattat sin roll som projektleda<re, eller så är det du själv som gjort skäl för att bli övervakad?

Jag har mest akademisk erfarenhet, men mina två cent... Vad gäller agil utveckling ser jag det som en självklar del i utvecklingsprocessen. Som ordet just antyder, du blir mer flexibel och kan bättre möta ändrade förutsättningar av de olika slag.

Vad gäller scrum så tycker jag (enligt min egen praktiska erfarenhet) att det är en mycket skönare utvecklingsprocess än unified process, som annars verkar vara väldigt vanlig.

Sen kan man naturligtvis implementera processerna olika på olika arbetsplatser, men jag tycker att om du är en seriös programmerare så är du naturligtvis intresserad av att effektivisera arbetet. Det kanske kan innebära att du inte kan slacka lika mycket och att du måste säga till andra att du är sen med en uppgift, men för fan det är ditt jobb, inte din hobby.

Edit: Det jag däremot inte gillar är testdriven utveckling som ofta verkar med i paketet, alltså att man specifierar ett visst problem som man försöker lösa så effektivt ocn enkelt som möjligt så att det funkar enligt ett testfall, som skrivs först av allt, för att gå vidare till nästa uppgift i projektet, ofta utan tanke på någon övergripande systemarkitektur. För vissa specifika saker kan det säkert vara bra, men ska man bygga ett helt sysstem så är jag betydligt mer intresserad av att modellera och strukturera. Då känns TDD faktiskt lite motbjudande. Men det kanske bara är min erfarenhet?

Håller inte med alls. Men min tolkning av TDD (och så den har använts på min arbetsplats) stämmer inte heller överens med din. Det är inte så att man hoppar över modellering och strukturering, eller struntar i systemarkitektur. Det är helt enkelt att innan det faktiskt börjar skrivas kod så ser man till att ha producerat testfall för koden först.
Planering och testskrivande utesluter inte varandra.Snarare tvärt om, testskrivande kräver planering, för utan att ha planerat någorlunda väl vad koden skall göra är det näst intill omöjligt att först skriva ett relevant test.

Sant sant, TDD bör ju naturligtvis kunna ta många olika former. Den delen jag har sett har dock inte varit speciellt tilltalande, men sen har jag ju inte heller så mycket erfarenhet inom det området. Har du några bra videos eller tutorials som förevisar den typen av TDD som du gillar?

Jag kan rekommendera boken http://www.amazon.com/Test-Driven-De.../dp/0321146530 - den går igenom bra scenarion och hur TDD bäst appliceras.

Tyvärr inte. Införandet av TDD på vår arbetsplats hanterades till stor del av två personer, vår extremt agile/TDD-entusiastiske projektledare samt en av utvecklarna med rätt gedigen TDD-erfarenhet i ett distribuerat open source-projekt. Inga böcker eller tutorials, bara de två som styrde upp när resten av oss flummade iväg.
Och jag får nog erkänna att det inte var lätt. Första gången nån sa till mig "skriv nu ett test först", så satt jag bara och stirrade på skärmen och undrade "vad fan gör jag nu?" Att skriva bra och relevanta tester är en färdighet som kräver träning, precis som allt annat.

Däremot är ju boken blueCommand länkade är klassad som lite av en auktoritet inom området (även om jag pinsamt nog då inte läst den), så den är säkert en bra start. Men det bästa sättet är nog garanterat om man kan se till att få tillgång till en person med TDD-erfarenhet (gärna inom en miljö som åtminstone påminner om ens egna) som kan lära en via parprogrammering.