Inom agile utveckling pratar man mycket om att man ska fokusera på det som skapar värde. Men vad innebär detta egentligen? Vad är värde?

Värde för beställaren. Dvs det viktigaste av allt är att det man skriver är ett stöd för verksamheten. Det här gäller /all/ kod du skriver.

Som filosof så vill jag sträva efter djupare förståelse för ordet :) Men om vi fortsätter att gräva vidare på det du skrev.

Skulle du säga att allt som stödjer verksamheten är lika med värde? Dvs:
Värde = Stödjer verksamheten
Icke-Värde = Stödjer inte verksamheten

Eller finns det något mer i ordet värde?

Vad innebär förresten att ett system stödjer verksamheten? Vad är det mer specifikt som gör att ett system stödjer respektive icke-stödjer verksamheten?

En annan intressant aspekt man kan göra är om man ser på din första mening, dvs "Värde för beställaren". En beställare kan tex vara fullt övertygad om att en feature i systemet skapar stort värde men samtidigt ha fel. Detta är nog inte ovanligt. Så jag skulle nog stryka den meningen och eventuellt koncentrera mig på din andra mening som en eventuell början på en definition på ordet värde. Men det känns dock som att även den meningen har en del luckor som måste täppas igen för att definitionen ska bli tillfredställande.

det är inget djupt filosofiskt i agiles beskrivning av värde. Om verksamheten upplever värde så är det så, även om de är ute och cycklar.

Det här är en annan del av agile, att leverera det kunden frågar efter, inte förutsätta att han har fel och försöka "rätta" till det. Om kunden sen inte längre anser sig behöva funktionen eller inser att den är fel, då ändrar vi, inte förr. Det är en krass tolkning av "responding to change". Men hela agile rörelsen handlar om att matcha fram bra beställningar, beställningar som ger ett verkligt värde och det är det vi skriver kod för, varken mer eller mindre.

Jag håller med om att det troligtvis inte är något djupt filosofiskt i agiles beskrivning av ordet värde. Men ordet värde är filosofiskt kopplat, det kommer man inte ifrån, och det hindrar oss inte att försöka undersöka vad ordet kan tänkas betyda i agile sammanhang.

Jag håller dock inte med om att om kunden upplever ett värde så är det ett värde för verksamheten. Om du håller fast vid den definitionen så faller din förra definition om att allt som stödjer verksamheten är värde. Det blir kontradiktatoriskt. Det som stödjer verksamheten kan sägas vara med objektivt och det som upplevs är mer subjektivt. Jag tror inte man bör blanda ihop dessa två "inriktningar".

vad e agile utveckling e det nåt speciellt språk
fattar ej
mvh Tobben

ja e lite ny här har inte vart så aktiv
skulle vilja veta hur ja startar en tråd?


mvh tobben


har ett projekt på g i visualbasic där ja önskar få ett kommando från 1 formulär till ett andra formulär

tack på förhand

som sagt, agile är inte filosofi det är ett förhållnignsätt till utveckling. Att försöka applicera filosofi på det kommer inte vara speciellt lyckosamt eftersom kunden / beställaren inte kommer vara speciellt road av filosofiska disskusioner om vad han menar med värde när han beställer.

Värde är alltid subjektivt och subjektet är den som beställer. Han / hon är den som bestämmer om det vi byggt är av värde för hans / hennes verksamhet. Det är varken djupare eller mer komplicerat än så och skall inte vara djupare eller mer komplicerat än så för då faller hela ideén med enkeltheten i kommunkationen med den som beställer.

Jag menar inte att vi ska börja filosofera med kunden om vad värde är. Det jag ville var att vi i detta inlägg skulle reflektera över vad värde är. Samtidigt är det nog inte alls dumt att ta upp en filosofisk diskussion med kunden om vad värde är. För det är inte alls ovanligt att vi människor använder en massa ord som vi inte har en djupare förståelse i.

Sen håller jag inte med om att upplevt värde är det som vi utvecklare och/eller projektledare enbart ska fokusera på. När jag arbetar för en kund så ser jag att en av mina uppgifter är att hjälpa kunden och hennes verksamhet. Om jag tycker att kunden värderar helt galet då ligger det i mitt ansvar att säga ifrån och inte bara göra det som kunden vill. Detta är något som kunden, verksamheten och utvecklarteamet tjänar på i slutändan.

När man pratar om värde i agile utveckling pratar man oftast om affärsvärde och att man ska fokusera på att leverera affärsvärde tidigt och ofta. Så för mig handlar värde om att ge kunden något som hon/han kan använda för att tjäna pengar.

Kunden är den som ska prioritera och dessa prioriteringar ska göras efter vad som levererar högst affärsvärde tillbaka. Självklart är det så att vi som utvecklare ska hjälpa produktägaren (kunden) att göra sina prioriteringar men det är ändå produktägaren som till slut bestämmer.

När jag föreläser eller utbildar i agile och Scrum brukar jag ta upp ett exempel med att man ska utveckla en internetbank. Om man frågar RUP vad man ska börja med så blir svaret att man ska börja med transaktionshanteraren, dvs att kunna flytta pengar mellan konton på ett säkert sätt. Säg att det tar två månader. Scrum svarar istället att man ska börja med en registreringssida för kunder så att man kan börja knyta kunder till sig. I nästa iteration levererar Scrum funktionen att man kan visa saldo på egna konton (RUP jobbar fortfarande med transaktionshanteraren)...

Jag känner till flertalet projekt som har lagts ner efter år av utveckling just på grund av att det inte kommer ut nått vettigt från projektet, dvs nått som kunden kan använda i sin organistion för att tjäna pengar. För huvudsyftet med all utveckling är ju ändå att kunden ska tjäna mer pengar, på ett eller annat sätt.

Agile och Scrum hjälper till med att skapa en leverans som ger mer affärsvärde för kunderna eftersom att det som utvecklas är prioriterat efter affärsvärde och eftersom att man levererar detta värde så pass snabbt i projektets livscykel.

Mvh Björn Eriksen
Scrum Practitioner, MCT & Software Architect på Connecta
http://bjorneriksen.blogspot.com

Björn:

Är själv scrum master och kört en del RUP innan men håller inte allt med om din liknelse.

"När jag föreläser eller utbildar i agile och Scrum brukar jag ta upp ett exempel med att man ska utveckla en internetbank. Om man frågar RUP vad man ska börja med så blir svaret att man ska börja med transaktionshanteraren,"

För att tyvärr försvara RUP så kan man precis som SCRUM börja med registreringsdelen. RUP i sig är ju bara ett annat sätt att hantera krav på och då sjävla flödet för att nå sitt mål. Där dokumentation är A och O.

Jag skulle mer säga att SCRUM fokuserar mer på leverans av kod och funktioner än leverans av dokumentation för att sen ta fram sin kod och funktioner.

Mvh Johan

Kan man inte referera värde i Agile till pengar som allt handlar om i slutändan ändå?

Gick en kurs i kravhantering för ett tag sedan och det borde man väl kunna använda i värderingen av krav som det egentligen är?

Vad kostar det att utveckla detta kravet?
Vad finns det för risker att utveckla kravet vad kan dom kosta?
Hur mycket tjänar verksameheten på detta kravet över en överskådlig tid?

Sedan lägger man ihop dessa och får det som verksamheten tjänar mest på?

Johan:

Men RUP säger väl att man ska börja med det som är tekniskt mest komplext och göra en smal men djup implementation av den funktionen och skulle jag tolka det till mitt exempel ovan med en internetbank så skulle det bli att börja med transaktionshantering.

Jag håller inte med på att Scrum fokuserar på leverans av kod men däremot funktioner. När det gäller dokumentation så är det bara den dokumentation som teamet behöver eller som produktägaren kräver som ska tas fram. Om man t ex jobbar i en organisation som är vana att jobba med RUP och de vill ha en SAD så är det bara att lägga in det på produktbackloggen och leverera. Men då är det något som produktägaren har beställt och som hon/han anser levererar någon form av värde.

Mvh Björn

Björn,

Leverans av funktioner är ju kod ;-) I jämförelse med dokumentation. Men ja leverans med funktioner är ju det egentligen. Ville hitta något som motsvara skriva uppsatser med dokument och då är det kod man skriver. My bad.

Ang RUP

Jag har fått den uppfattning att RUP inte säger vart man skall börja utan bara vad man skall börja med och det är analys i massor, dokumentation i evigheter. Sen vilket usa case man börjar med är väl i den prioriteringsordning man själv vill ha, eller som kunden vill ha ungefär som i SCRUM.

Nu var det så längesedan jag satt med RUP, men de gånger jag gjorde det så prioriterade vi kärndelar först, och sen sånt som växte fram programmet utan att man var tvungen att öppna för mkt av det man redan typ stängt för leverans. Låter underligt det du säger men vi kan ha gjort fel. I vilket fall är jag glad att jag fått lägga RUP bakom mig och hoppas det förblir så :)


Men jag skulle nog mer använda mig av den jämförelse jag skrev i förra posten att SCRUM fokuserar på leverans av funktioner och självbeskrivande kod och mindre dokumentation samt kortare iterationer med dagliga möten. Medans i RUP fokuserar mer på dokumentation av funktioner och större iterationer vilket ökar svårigheten att gå tillbaka om en funktion blivit felaktig och ökar dokumentationsarbetet avsevärt.

Niclas

Det är dessa punkter som tar fram värdet i det man skall göra i ex SCRUM. Det är mer eller mindre kunden som avgör värdet och prioriteringen av dem. Sen är det SCRUM Master med sina teammembers som skall leverera det som har mest värde.

Så alla dina punkter ingår indirekt i val av värde.

Mvh Johan

Niclas, det låter precis som PENG-metoden du är ute efter. För er som inte vet så är vi på Sweco certifierade på peng så hör av er till mig om ni behöver hjälp med att ta reda på vad saker kostar kontra inte kostar om man gör det ena eller det andra. Peng-metoden är enormt kraftfull och kostar inte speciellt mycket mer än en halv arbetsdag men ger så många svar på hur företaget skall tänka strategiskt att det är dumt att inte göra den, speciellt inte om vi pratar investeringar på några hundra tusen och uppåt några hundra miljoner.

Peng visar om det är bortkastade pengar eller inte och då slipper ledningsgruppen skämmas sen ;)

Jag var inte ute efter något speciellt, utan det var mer ett bidrag och fråga till diskussionen. :).

Agile var för man ville inte ha nåt så strikt som RuP eller U.P men agile tar delar av dom i alla fall så varför kritiserar agile rup om dom ändå använder delar av rup och up

Så agile är bara en typ av systemutveckling såsom vattenfallsmetoden eller rational unified process (RUP)