Agile programming är inspirerat från Lean Production och TPS (Toyota Production System). En av grundstommarna i Lean är att reducera slöseri (Muda på japanska).
Att fokusera på att skapa värde syftar till att enbart göra sådant som kommer kunden till gagns. Dvs. kunden kan definiera värde. Du kan skapa värde genom att eliminera slöseri i din utvecklingsprocess.
Jag jobbar för tillfället i ett forskningsprojekt - Lean Robotik - på Volvo CE Components där en Leantransformation pågår. Så man ältar dessa termer en hel del. :)
Oftasts det som är värt mest för beställaren / kunden / produktägaren. Är funktion A värt 10 och funktion B värt 11, samt att båda kan göras med samma resurser, gör funktion B (först).
-> Phorpher
Tack för tipset om sidan! Ska försöka läsa igenom artikeln idag eller imorgon. En sak som man kanske bör förtydliga är att det egentligen inte behöver vara gagn för kunden (direkt) utan systemet man tar fram ska vara gagn för de som den är avsedd för. Eller hur ser du på det? För kunden skulle kunna vara en ansvarig person som inte använder sig av systemet.
Det är intressant att du tar upp detta med att reducera slöseri och jag håller helt med. Syftet med att reducera slöseri är att skapa värde. Det håller jag med om. Men vad är det mer specifikt för värde som uppstår? Det blir en form av kostnadsbesparing för kunden. Något som i slutändan leder till att verksamheten erhåller en större vinst på sitt investerade kapital. Är det detta som i slutändan anger om en sak har ett värde eller inte? Eller finns det något ytterligare steg efter "return on investment" (ROI)?
-> Cyprys
Men vad är det som gör att A är värt 10? Vad är det som bygger upp A:s värde? Det är dessa komponenter som jag söker efter. Utifrån dessa komponenter kan man kanske sedan finna någon gemensam nämnare som kan ligga till grund för en definition av ordet värde.
Men vad är det som gör att A är värt 10? Vad är det som bygger upp A:s värde? Det är dessa komponenter som jag söker efter.
En bra kundförståelse är A.O.
Dessa värden är ofta rätt mjuka och baseras på vad just denna kund värderar. Det är alltså i mina ögon rätt svårt att formalisera. Även om det nu finns olika formaliseringsmetoder och regler, är det inget jag kan svara på. Är tyvärr inte tillräckligt insatt i detta men är även jag intresserad av att lära mig. :)
Min lekmannametod som brukar räcka rätt långt är att helt enkelt lista upp allting som ska göras, samt prioritera den listan. Stämma av med kunden att prioriteringen stämmer och sen börja uppifrån. Likheter med ex. scrums backlog är inte svårt att dra.
Det är bara kunden som vet ROI och det är därför kunden som ska ta fram prioriteringenen, dock måste detta ske i samråd med utvecklarteamet då det endast är de som kan estimera hur lång tid någonting tar, och för det krävs djup förståelse för det som ska tas fram.
Men vad är det mer specifikt för värde som uppstår? *** snip
Men vad är det som gör att A är värt 10? Vad är det som bygger upp A:s värde? Det är dessa komponenter som jag söker efter.
Jag säger som mitt ex, "måste du fråga kommer du inte förstå svaret" ;)
I vissa projekt är det viktigt att man får en fungerande lösning så snabbt som möjligt. I andra projekt är en fungerande lösning helt värdelös om den inte är dokumenterad. Och så vidare. Hela poängen med "fokusera på värdet" är att det inte finns någon generell definition av värde. Det handlar om att man identifierar vad som är viktigt för just det projektet du sitter i - eftersom alla projekt är olika kommer "värde" betyda olika saker i alla projekt! Man anpassar sig alltså efter situationen istället för att följa dogmer.
-> cyprys
Jag har läst en hel del moralfilosofi och där handlar det till stor del om värderingar. Subjektiva, intersubjektiva, objektiva m.m. Det som jag kom fram till vad värde i dessa sammanhang innebar var att en handling bör sättas i relation till det måltillstånd som personen i fråga strävar efter att uppnå.
Kanske skulle man kunna dra vissa paralleller till ordet värde inom agile, dvs ju närmare en feature/handling/process kommer det eftersträvade måltillståndet desto högre värde har det samt vice versa. Vad tror du om det?
-> erka
Jag vet inte om jag förstår dig rätt men menar du att ROI är det som är grunden till vad som är värde respektive icke-värde i en verksamhet? Eller är ROI mer ett indirekt värde som uppnås via att andra värden som agile ska fokuserar på uppnås? Förstår du hur jag menar? :)
-> Spango
Hehe, det var ett ex det. Om jag varit tillsammans med henne så skulle nog hon varit mitt ex också. Hon skulle aldrig stått ut med mina eviga filosofiska frågor :)
Men när du säger "att man ska identifiera det som är viktigt för just det projektet du sitter i" då är du inne på en generell definition av vad värde står för. Jag håller med om att olika projekt kan värdesätta olika saker men själva värdesättandet borde enda ha en del gemensamma nämnare. I annat fall skulle det vara ganska svårt att göra jämförelser mellan två saker som man värderat.
Jag menade att det är bara kunden som vet prioriteringarna, och hur mycket något är värt för honom/henne, i förhållande till utvecklingstid och de resurser kunden investerat. Agile strävar ju efter ge maximal och snabb ROI för kunden.
Värde är ju som sagt något som kunden definierar genom kravspecar och prioriteringar. En billigare produkt är ett typiskt värde och för att du ska kunna skapa en billigare produkt måste du t.ex. optimera ditt utvecklingsflöde.
T.ex. genom att...
...undvika att utveckla extrafunktioner som kunden inte ber om (programmerare har en tendes att göra det ;) )
...arbeta tätt tillsammans med kund, säljare, och övriga involverade partner (och därmed undvika väntetider på beslut)
...direkt designa för testning (TDD)
...osv.
Jag är definitivt ingen expert på ämnet men det är väldigt intressant. Kul med lite sånahär diskussioner! :)
I agile existerar inte kravspecar direkt på samma sätt, XP tex har sina mycket kortfattade user stories som det sedan skrivs acceptanstest för (när det är dags för implementering), för att kunden ska kunna säkerställa att målen har nåtts med implementationen. XPs planning game är rätt roligt för att prioritera efter business value om ni vill testa. Kunden kan inte få fram värdet innan utvecklargruppen har gjort ett estimat.
Med TDD som bland annat är en XP-practice kommer ju automatiskt att man inte utvecklar extrafunktioner som inte kunden behöver.
129 ms totalt · 3 externa anrop · v20260731065814-full.4bcf49fe
