Agenda Opening words Janne Kalliola Summary of agile methodologies Kalle Varisvirta

Transkriptio

1

2 Agenda Opening words Janne Kalliola Summary of agile methodologies Kalle Varisvirta What kind of projects does agile fit in? Break Janne Alho What agile project means to the client? Laura Halenius, Sitra Trust in agile projects Janne Kalliola How to buy agile projects? Mikko Hämäläinen Discussion

3 WHY AGILE?

4 Typically, you need to Achieve more with less resources. Be among the first ones to launch your service. Constantly upgrade your offerings. Satisfy your business needs and keep your bottom line in shape.

5 User satisfaction Time to market Return on investment

6 Agile focuses on flow of information and embraces changes instead of trying to control them. Lean focuses on results and strives to reduce all redundant work.

7 About us

8 Exove is a leading Northern European company specialising in open source web services design and development.

9 We enable companies to conduct better business on the Internet through best-of-breed personnel and solutions

10 Our Approach Understanding your business

11 Our Approach Understanding your business Our expertise

12 Our Approach Understanding your business Our expertise Power of open source

13 Results Beautiful, functional & businessdriven services

14 Over 60 people, over 150 customers, over 3.5 MEUR revenue 2012, profitable, offices in Helsinki, London & Tallinn

16 YHTEENVETO KETTERISTÄ MENETELMISTÄ Kalle Varisvirta Technology Director

17 Historiaa Ohjelmistokehitysprosessien historia on melko pitkä Alunperin projektit olivat pieniä, eikä erityisiä prosesseja tarvittu, myöhemmin kuitenkin projektit alkoivat kasvaa ja prosessille tule tarve Ensimmäinen tunnistettu (ei-ketterä) menetelmä oli vesiputous (waterfall)

18 WATERFALL / VESIPUTOUS

19 Vesiputous / Waterfall Vesiputous-malli katsotaan syntyneen1970 Winston Roycen artikkelissa Nykyisin tunnettu seitsenportainen putous syntyi kuitenkin väärinkäsityksen tuloksena Varsinaisessa vesiputousmallin esittelevässä artikkelissa Royce esitteli mallin viallisena, eitoimivana mallina Artikkelissaan Royce siis esitteli vuonna 1970 käytössä olevan mallin ja kritisoi sitä

20 Royce artikkelissaan: Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.

21 Vesiputous käyttöön Roycen artikkelin jälkeen vesiputous-malli kuitenkin otettiin käyttöön virallisten suositusten kautta Vuonna 1995 Yhdysvaltain puolustusministeriö tutki tuloksia vuosilta ja totesi, että 46% toteutetuista järjestelmistä oli niin epäsopivia aitoihin tarpeisiin, että niitä ei ikinä käytetty

22 Agile Manifesto 2001 Ketteriä menetelmiä alkoi ilmestyä tieteellisiin papereihin ja yleiseen tietoisuuteen jo luvulla Vuonna ketterän kehityksen puolestapuhujaa kirjoitti ja julkaisi Agile Manifeston

23 Agile manifesto Me etsimme parempia keinoja ohjelmistojen kehittämiseen tekemällä sitä itse ja auttamalla siinä muita. Tässä työssämme olemme päätyneet arvostamaan Yksilöitä ja vuorovaikutusta enemmän kuin prosesseja ja työkaluja Toimivaa sovellusta enemmän kuin kokonaisvaltaista dokumentaatiota Asiakasyhteistyötä enemmän kuin sopimusneuvotteluita Muutokseen reagoimista enemmän kuin suunnitelman noudattamista. Vaikka oikeallakin puolella on arvoa, me arvostamme vasemmalla olevia asioita enemmän.

24 SCRUM

25 Scrum Scrum on ehdottomasti suosituin ketteristä menetelmistä Scrumin iteraatiot ovat sprinttejä ja ne kestävät yleensä 2-3 viikkoa Scrum perustuu backlogiin, joka on priorisoitu lista tehtävistä Backlogia voidaan ja yleensä pitääkin päivittää jatkuvasti, mutta sprintin sisältöä ei voi muuttaa sprintin aikana (sprinttirauha)

26 Scrum Sprintti alkaa kaksiosaisella sprint planningilla Ensimmäisessä osassa asiakkaan edustajat valitsevat seuraavassa sprintissä saavutettavat tavoitteet ja tehtävät Toisessa osassa asiakas (product owner) on tiimin tai scrum masterin kanssa ja valitsee seuraavan sprintin aikana suoritettavat tehtävät backlogilta Sprintti päättyy spirnt reviewhun Tiimi tai scrum master esittelee saavutetut tavoitteet ja näyttää demoamalla toteutetut tehtävät Myös tekemättä jääneet tehtävät käydään läpi ja priorisoidaan takaisin backlogille Tiimillä on päivittäin statuspalaveri, daily scrum

27 Scrum - roolit Asiakas Product owner Yksi henkilö (1!), joka on vastuussa backlogin luonnista ja priorisoinnista Valitsee tehtävät seuraavaan sprinttiin Yhdessä muiden asiakkaan edustajien kanssa, katselmoi järjestelmän joka sprintin päättyessä sprint review:ssä

28 Scrum - roolit Kehitys Scrum tiimi Kehitystiimi Prosessin ohjaaja Scrum master Yleensä suurimmalta osaltaan kehittäjä, rooli vain sivutoiminen Hoitaa Scrumin seremoniat, eli sprintin alkamisen, päättymisen ja päivittäiset daily scrumit

29 Scrum Usein Scrumissa tehtävät luokitellaan eri kokoisiin kokonaisuuksiin Epic liian suuri tehtäväksi yhdessä sprintissä, ei voida arvioida kestoa, pitää paloitella pienempiin osiin User story epicin osa, yksittäinen feature tai business tavoite Task Yksittäinen tehtävä, joita tarvitaan yksi tai useampi yhden user storyn toteuttamiseksi

30 Miten epäonnistua Scrumissa Sprinttien määrä on määrätty etukäteen, tai sprinttien sisältöä on suunniteltu etukäteen Uusia tehtäviä lisätään sprinttiin kun sprintti on kesken Product owner ei osallistu tai ei osaa / saa päättää asioista

31 EXTREME PROGRAMMING

32 Extreme programming (XP) XP on vanhempi kuin Scrum ja vähemmän tunnettu Kuitenkin useat siihen kuuluvista menetelmistä ovat nykypäivänä todellisuutta ja tärkeitä XP on myös uranuurtaja ketterissä menetelmissä, se on ensimmäinen menetelmä, joka sai jonkin verran tuulta purjeisiinsa

33 Extreme programming (XP) XP:ssä on 12 ydinperiaatetta Niihin kuuluu myös se kuuluisin, pariohjelmointi, jonka perusteella XP:ssä aina ohjelmoidaan pareittain Hyvin harva käyttää kaikkia XP:n periaatteita, mutta osa niistä on hyvin suosittuja Jatkuva integrointi (Continuous integration) Tiuha refaktorointi (Frequent refactoring)

34 Extreme programming (XP) XP:ssä koko tiimi on samassa huonessa ja huoneessa on aina paikalla asiakas, yksi tai useampi asiakkaan edustaja Kaikki taskit kirjoitetaan post-it lapuille, tai jollekin muulle vastaavalle (yksi sana riittää) ja toteutusvaiheessa taski käydään läpi asiakkaan kanssa Yksi testaaja omistautuu tuottamaan yhdessä asiakkaan kanssa hyväksymistestejä kaikille toteutetuille ominaisuuksille ja taskeille

35 XP Johtuen vaatimuksesta asiakkaasta huoneessa sekä pariohjelmoinnista, XP on hyvin kallis ja hankala toteuttaa täysin Useimmiten XP:n periaatteita lainataan enimmäkseen Scrumilla toteutettuun prosessiin

36 LEAN JA KANBAN

37 Lean Lean on vanha periaate joka pyrkii poistamaan kaiken turhan (waste) Sen perustana pidetään Toyotan tuotantojärjestelmää (TPS), jota kehitettiin vuosina Lean on vasta 2000-luvulla saapunut omalla nimellään ohjelmistokehitykseen

38 Lean - periaatteet Poista turha Poista turha koodi ja ominaisuudet Poista viiveet kehitysprosessissa Poista epäselvät vaatimukset Poista byrokratia Voimista oppimista Dokumentaation tai suunnittelun sijaan kokeile erilaisia ratkaisuja Käytä lyhyitä syklejä (sprinttejä) Päätä niin myöhään kuin mahdollista Älä suunnittele etukäteen Päätä kun tietoa on mahdollisimman paljon Kokeile ennemmin eri vaihtoehtoja kuin perusta päätös oletuksiin

39 Lean - periaatteet Toimita niin aikaisin kuin mahdollista Rakenna palaute-looppi niin pian kuin mahdollista Julkaise aina kun se on mahdollista, jotta uuden julkaisun palaute saadaan mukaan toteutukseen Voimaannuta tiimi Itseohjautuva tiimi Rakenna eheys sisään Refaktoroi arkkitehtuuria säännöllisesti Näe kokonaisuus Jokaisen tiimissä pitää tietää tuotteen tavoitteet, nähdä koko kokonaisuus

40 Lean Kuten periaatteista nähdään, lean ei anna tarkkoja sääntöjä vaan perustuu periaatteisiin Siten lean sopii yhteen muiden, tarkempien ketterien menetelmien kanssa Sen tärkein ajatus on kaiken asiakkaalle arvoa tuottamattoman poistaminen

41 Kanban Kanban on yksi Leanin toteuttamiseen käytetty työkalu Kanban on taulu, jossa näkyy tehtävien asioiden tilat Tilat liikkuvat vasemmalta oikealle, kun tehtävä tulee tehdyksi Olennaista taululla on se, että yhtä aikaa toteutuksessa voi olla vain rajallinen määrä tehtäviä

42 Kanban Kanban on yksi Leanin toteuttamiseen käytetty ohjelmistoprosessi Kanbanin keskiössä on taulu, jossa näkyy tehtävien asioiden tilat Tilat liikkuvat vasemmalta oikealle, kun tehtävä tulee tehdyksi Olennaista taululla on se, että yhtä aikaa toteutuksessa voi olla vain rajallinen määrä tehtäviä

43 Kanban - periaatteet Visalisoi Rajoita toteutuksessa olevien tehtävien määrää Hallitse työvirtaa (flow) Tee säännöistä täsmällisiä Luo palautekanava Paranna yhteisesti, kehitä kokeellisesti

44 Yhdistelmät Usein käytössä saattaa olla jokin prosessien yhdistelmä Ne saattavat toimia, mikäli aliprosessien säännöistä pidetään kiinni Usein kuitenkin yhdistelemällä kierretään juuri ne olennaiset säännöt Scrumwaterban

45 Lean Think big, act small, fail fast; learn rapidly

47 PROJEKTIN SOVELTUVUUS KETTERÄÄN KEHITYKSEEN Janne Alho Project Director

48 Projektin perusmuuttujat Projektin budjetti Projektin aikataulu Projektin sisältö ja tavoite Tekijät

49 Projektin budjetti Agile vs. Vesiputous Vesiputous Kiinteä etukäteinen sitoumus toimittajalta à riski hinnoiteltu mukaan tarjoukseen Tilaajan muutosennakointi Budjetointi (tyypillisesti 10%- 20%) Muutosvara osapuolien pelaamisen kohde Mikä on muutoksista neuvotteluun ja hyväksyntään käytettävä työmäärä Osaaminen muutoksia aiheuttavien teknisten yksityiskohtien hallintaan Agile Koko budjetti näkyvissä molemmille osapuolille Riskin jakaminen tehtävä sopimusvaiheessa Muutostarve mukana yhteisissä arvioissa, eli osana tavoitteiden epävarmuusarviota ja tärkeysjärjestystä Muutosten hyväksyntä osa Agileprojektin ohjaamista ei erillistä hyväksyntää Budjettiseuranta yhteinen asia

50 Projektin aikataulu Agile vs. Vesiputous Vesiputous Projektin vaiheistaminen Osien sisällöt etukäteen hinnoiteltuja, muutokset erillisesti sovittavia Myöhästymissanktiot tyypillisesti riippumaton myöhästyneiden osien merkityksestä Toimittajan ensisijainen intressi välttää myöhästyminen Agile Projektin vaiheistaminen Osien tavoitteiden asettaminen projektin aikana Liiketoimintalähtöisyys (MVP Most Valuable Product) Myöhästyminen yhteisesti hallittava riski Toimittajan ensisijainen intressi tuottaa liiketoiminnan kannalta merkittävimmät asiat aikataulussa

51 Projektin sisältö ja tavoite Agile vs. Vesiputous Vesiputous Vaatii tarkan sisällön määrittelyn etukäteen Projektin tavoite ei voi oleellisesti muuttua Kaikki muutokset vaativat erillisen käsittelyn Ongelmaprojekteissa muutosten hyväksyminen erittäin vaikeaa Projektia voidaan tehdä paljolti irrallaan tilaajasta, lopputulos nähdään projektin lopussa Agile Projektin sisältö tarvitaan alussa vain suuntaa antavana Projektin tavoite voi muuttua tilaajan tarpeiden mukaan Työskentelyn tehokkuus edellyttää tilaajan tarpeiden ymmärtävän tahon voimakasta ohjausta Projektin tuotoksia validoidaan koko projektin ajan

52 Projektin tekijät Agile vs. Vesiputous Vesiputous Vaatimusmäärittelijä avainasemassa Projektimanageri valvoo määrittelyiden mukaista toteutusta ja raportoi molempien organisaatioiden suuntaan Toteuttajat usen kaukana vaatimusmäärittelystä Agile Product Owner Projektin aikainen vaatimusten hallitsija Avainasemassa varmistamassa tavoitteiden selkeys Toteuttajat (Tech Lead etunenässä) Voimakkaasti mukana tavoitteiden ymmärtämisessä ja vaatimusmäärittelyssä Rooli ja sitoutuminen lopputulokseen vesiputousmallia suurempi Projektimanageri Tuottaa projektin seurantaa tarvittavaa materiaalia, kuten tuntiraportteja etenemäarvioita ja -yhteenvetoja, valvoo ja suunnittelee resursseja ja reagoi poikkeustilanteisiin Normaalisti pienempi kuorma kuin vesiputousmallissa

53 Kokemuksia Janne Alho Nokia Yritysviestintä, Comverse, First Hop, Airwide, Mavenir, Exove Telecom tele, Telecom Web, Web ratkaisut Kokemukset Aika vaatimusmäärittelystä ratkaisun julkistukseen on koko ajan lyhentynyt Vesiputousmallin pohjalta toimivat projektit tuottavat tänä päivänä ratkaisuja markkinoille liian myöhään Ratkaisuja hiotaan eteenpäin tuotantovaiheessa Agile toimintatapa antaa toimijoille selkeät pelisäännöt ja mahdollisuuden käyttää projektin aikana tapahtuvaa oppimista osana projektin tavoitteiden syvempää ymmärtämistä ja niihin pääsemistä Asiakkaan PO, ja hänelle toimittajan antama tuki on keskeistä projektin onnistumiselle

55 Sitran ketterä verkkoprojekti Laura Halenius

56 Puhujasta Laura Halenius, KTM 8 vuoden kokemus viestinnän kehittämisestä ja johtamisesta Sitrassa alkaen 10/2012 Vastaa Sitran digitaalisesta viestinnästä ja sen kehittämisestä Sitran ketterä verkkoprojekti Sitra

57 Sitra.fi Julkaistu alkuvuodesta Ensimmäisiä suomalaisia responsiivisia verkkosivuja - Ketterä kilpailutus koesprintin avulla Verkkomaailma muuttuu nopeasti -> sivustoa kehitetään jatkuvasti 2 viikon sprinteillä Exove kumppaniksi 2/2013 Kuukausittaisia kävijöitä n Sitran ketterä verkkoprojekti Sitra

58 Miksi ketterä projekti Haluttiin tehdä paras mahdollinen verkkosivusto Sitran tarpeisiin Pyrittiin estämään se, että sitra.fi ei ole vanhentunut heti julkaisun jälkeen Haluttiin hyödyntää projektin aikana syntyvä oppiminen Ketterä tekeminen sopii erityisen hyvin projekteihin, joissa verkkosivustoa kehitetään jatkuvasti eteenpäin 58 Sitra

59 Ketteryyden edellytykset Riittävät resurssit Riittävän kevyet sopimukset Luottamus toimittajaan - Tiivis yhteistyö - Suora keskustelu Muunkin organisaation oltava ketterä Riiittävän iso ja monimutkainen projekti Tekemisen tapa on hyvin erilainen kuin vesiputousprojekteissa - Iso muutos ja oppimiskokemus ensikertalaiselle Sitran ketterä verkkoprojekti Sitra

60 Product owner keskiössä Vastuu laadusta ja tekemisen järjestyksestä Vaatii diplomaatin taitoa ja vahvaa näkemystä Organisaation tuhansien toiveiden priorisointi Sitran ketterä verkkoprojekti Sitra

61 Organisaation sitoutuminen Sprinttien aikana työtä on helposti todella paljon - Riittävä resursointi erityisen tärkeää, ettei PO muodostu pullonkaulaksi - Sitralla itse kehitysprojektin aikana mm. erillinen tekninen projektipäällikkö - Testaus on jatkuva osa projektia - Sprinttien aikana testausta tekee 2-3 hlö Kannattaa testata ja kokeilemalla löytää omalle organisaatiolle sopiva ketterän tekemisen malli Sitran ketterä verkkoprojekti Sitra

62 Yhteenveto Kannattaa tutustua ketteriin menetelmiin avoimin mielin - Keskustele niiden kanssa joilla on kokemusta Ketterät menetelmät eivät ole silver bullet Varaa tavallista enemmän resursseja Luota toimittajaan Sitoudu itse projektiin Sitran ketterä verkkoprojekti Sitra

63 Kiitos! p Sitran ketterä verkkoprojekti Sitra

65 Trust Agile practices place great emphasis on the team Encourages autonomy Leadership is shared Team has substantially more control Trust is required from managers and clients to avoid micromanagement or falling back to nonagile methodologies

66 Definition of Trust When you trust to someone, you are willing to be vulnerable to the actions of another party Based on the expectation that the other party will perform an important action Irrespective of the ability to monitor or control the other party

67 Definition of Trust, cont d Trust is not a behaviour or a choice But a psychological state that cause or result from aforementioned actions That is related to both rational and emotional skills of the people involved

68 And? This means that trust must be built, not purchased or ordered Building is a long and fragile process Requires participation from each party Blunders are ok when they are not repetitive or malicious

69 The Basic Needs In order to create and grow trust, the basics need to be in a good shape: The goals are well-defined and reachable The client loosens the control at least somewhat to allow vendor to perform on its own The vendor is able to run with the ball

70 How to Build Trust? Trust is created with small actions that stay constant Everyone respects the others Communication is open, honest and immediate Expectations are managed by all parties People are not punished for making mistakes

71 Threats to Trust Not enough external visibility to the project Team need to keep everyone on the same page about the progress Demos and shared environments Tensions between developers and the product owner / customer Everyone needs to agree on the shared goals and means to reach them Underestimations Team need to assess its capability to estimate and make changes as required

72 What You Gain from Trust? Trust reduces extra work Focuses everyone s attention to things that matter Less controls and meetings The project generates more customer value with the same investment Trust allows people to talk about difficult or painful matters openly No issues are swept under the carpet Trust makes the project team happier -> improves productivity and work meaningfulness

73 Onward Trust helps everyone to get things done in a pleasant way It should be one of the primary goals in a successful IT relationship Sell the idea of trust to your team Guide their steps when they try to build and maintain it If possible, participate actively If you have trustworthy teams, vendors or project, remember to praise them from time to time

75 KETTERÄ OSTAMINEN Mikko Hämäläinen

76 Kuka? Mikko Hämäläinen, DI Vastaa Exovella konsultoinnista Yli 15 vuotta alalla Tuotehallinta, projektinhallinta, softankehitys Pinnalla: Liiketoiminta verkossa, miten tuottaa arvoa Miten edetä verkkoprojekteissa Tuoteomistajuus

77 Mitä on ketterä ostaminen? Tavoitteena aidosti ketterä projekti Huomio toimittajan osaamisessa ja kokemuksessa Joustava sopimusmalli Enintään kaksi kolmesta voidaan kiinnittää: Budjetti Aikataulu Laajuus

78 Ketterän verkkoprojektin kulku Suunnittelu ja tekniikka tiiviissä yhteistyössä Alustava määrittely ja toimittajien valinta Luova suunnittelu Konsepti à Käyttöliittymät / visuaalisuus Tekninen toteutus Iteratiivisesti Sisällön luonti ja syöttäminen Deployment Julkaisu! Tekninen toimittaja mukana alusta alkaen

79 Kaksi mallia verkkoprojektin ketterään ostamiseen 1. Ostetaan henkilöresursseja Ketterä tiimi tai sen osa sovituksi ajaksi Asiakas vastaa tiimin ohjauksesta Erittäin joustava ja tehokas kun ohjaus on kunnossa Osaaminen, referenssit ja hinta ratkaisevat Ostajan tulee määritellä tarvittava osaaminen, jonka avulla päästään tavoitteeseen Huomioi mahdollisuus erityisosaamisen joustavaan käyttöön

80 Kaksi mallia verkkoprojektin ketterään ostamiseen 2. Ketterä projektitoimitus Tietyn ylätasolla määritellyn kokonaisuuden toteutus Asiakas vastaa vaatimuksista ja prioriteeteistä, toimittaja organisoi toteutustyön Usein budjetti ja aikataulu kiinnitetty, kokonaisuus elää Backlogia tarkennetaan jatkuvasti yhdessä Palvelu voidaan julkaista, kun keskeiset arvoa tuottavat asiat on toteutettu Referenssit, osaaminen, toimintamalli ja hinta

81 Budjetti, laajuus & aikataulu Jaetaan projektin työt 2-3 kategoriaan Max. 50% pakollisia ominaisuuksia Arvioidaan työmäärät ja laaditaan budjetti kaikkien töiden perusteella Projektin kuluessa työ ja työmäärät elävät Tavoitteena toimivan palvelun julkaisu budjetissa ja aikataulussa Pakolliset työt kasvavat / pienenevät projektin aikana Loppu budjetista ja ajasta käytetään täällä Aikataulu ja budjettiraja Toteutus: Prioriteetti 1 Prioriteetti 2-3 Design Projektinhallinta Ylläpito / jatkokehitys Tuotanto Vk

82 Ostajan muistilista 1. Aseta selkeät isot päämäärät ja valmistaudu muutoksiin matkalla 2. Valitse kumppaneiksi tunnettuja ja luotettavia verkkoalan toimijoita 3. Panosta tuoteomistajuuteen tarvittaessa osta apua 4. Pyri julkaisemaan mahdollisimman aikaisin ja anna asiakaspalautteen ohjata jatkokehitystä Konsultointi ennen projektia ja sen aikana voi säästää pitkän pennin toteutuksessa

83 Ketterä verkkoprojekti sopii kaikille, joilla on halu tehdä parempaa tehokkaammin

84 KIITOS Seminaarin materiaalit Nähdään seuraavan kerran: DrupalCamp Baltics Tallinna WordPress Café Exove DrupalCon Prague