Agenda 14.00 Opening words Janne Kalliola 14.10 Summary of agile methodologies Kalle Varisvirta 14.30 What kind of projects does agile fit in? 14.50 Break Janne Alho 15.00 What agile project means to the client? Laura Halenius, Sitra 15.20 Trust in agile projects Janne Kalliola 15.40 How to buy agile projects? Mikko Hämäläinen 16.00 Discussion
WHY AGILE?
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.
User satisfaction Time to market Return on investment
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.
About us
Exove is a leading Northern European company specialising in open source web services design and development.
We enable companies to conduct better business on the Internet through best-of-breed personnel and solutions
Our Approach Understanding your business
Our Approach Understanding your business Our expertise
Our Approach Understanding your business Our expertise Power of open source
Results Beautiful, functional & businessdriven services
Over 60 people, over 150 customers, over 3.5 MEUR revenue 2012, profitable, offices in Helsinki, London & Tallinn
Agenda 14.00 Opening words Janne Kalliola 14.10 Summary of agile methodologies Kalle Varisvirta 14.30 What kind of projects does agile fit in? 14.50 Break Janne Alho 15.00 What agile project means to the client? Laura Halenius, Sitra 15.20 Trust in agile projects Janne Kalliola 15.40 How to buy agile projects? Mikko Hämäläinen 16.00 Discussion
YHTEENVETO KETTERISTÄ MENETELMISTÄ Kalle Varisvirta Technology Director
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)
WATERFALL / VESIPUTOUS
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ä
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.
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 1988 1995 ja totesi, että 46% toteutetuista järjestelmistä oli niin epäsopivia aitoihin tarpeisiin, että niitä ei ikinä käytetty
Agile Manifesto 2001 Ketteriä menetelmiä alkoi ilmestyä tieteellisiin papereihin ja yleiseen tietoisuuteen jo 1990- luvulla Vuonna 2001 17 ketterän kehityksen puolestapuhujaa kirjoitti ja julkaisi Agile Manifeston
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.
SCRUM
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)
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
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ä
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
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
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
EXTREME PROGRAMMING
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
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)
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
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
LEAN JA KANBAN
Lean Lean on vanha periaate joka pyrkii poistamaan kaiken turhan (waste) Sen perustana pidetään Toyotan tuotantojärjestelmää (TPS), jota kehitettiin vuosina 1948 1975 Lean on vasta 2000-luvulla saapunut omalla nimellään ohjelmistokehitykseen
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
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
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
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ä
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ä
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
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
Lean Think big, act small, fail fast; learn rapidly
Agenda 14.00 Opening words Janne Kalliola 14.10 Summary of agile methodologies Kalle Varisvirta 14.30 What kind of projects does agile fit in? 14.50 Break Janne Alho 15.00 What agile project means to the client? Laura Halenius, Sitra 15.20 Trust in agile projects Janne Kalliola 15.40 How to buy agile projects? Mikko Hämäläinen 16.00 Discussion
PROJEKTIN SOVELTUVUUS KETTERÄÄN KEHITYKSEEN Janne Alho Project Director
Projektin perusmuuttujat Projektin budjetti Projektin aikataulu Projektin sisältö ja tavoite Tekijät
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
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
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
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
Kokemuksia Janne Alho 1989-2013 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
Agenda 14.00 Opening words Janne Kalliola 14.10 Summary of agile methodologies Kalle Varisvirta 14.30 What kind of projects does agile fit in? 14.50 Break Janne Alho 15.00 What agile project means to the client? Laura Halenius, Sitra 15.20 Trust in agile projects Janne Kalliola 15.40 How to buy agile projects? Mikko Hämäläinen 16.00 Discussion
Sitran ketterä verkkoprojekti 15.8.2013 Laura Halenius
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ä Twitter: @laurahalenius Sitran ketterä verkkoprojekti 15.8.2013 56 Sitra
Sitra.fi Julkaistu alkuvuodesta 2012 - 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. 30 000 Sitran ketterä verkkoprojekti 15.8.2013 57 Sitra
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
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 15.8.2013 59 Sitra
Product owner keskiössä Vastuu laadusta ja tekemisen järjestyksestä Vaatii diplomaatin taitoa ja vahvaa näkemystä Organisaation tuhansien toiveiden priorisointi Sitran ketterä verkkoprojekti 15.8.2013 60 Sitra
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 15.8.2013 61 Sitra
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 15.8.2013 62 Sitra
Kiitos! Laura.halenius@sitra.fi, p. 040 716 7885 Twitter: @laurahalenius Sitran ketterä verkkoprojekti 15.8.2013 63 Sitra
Agenda 14.00 Opening words Janne Kalliola 14.10 Summary of agile methodologies Kalle Varisvirta 14.30 What kind of projects does agile fit in? 14.50 Break Janne Alho 15.00 What agile project means to the client? Laura Halenius, Sitra 15.20 Trust in agile projects Janne Kalliola 15.40 How to buy agile projects? Mikko Hämäläinen 16.00 Discussion
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
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
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
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
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
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
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
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
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
Agenda 14.00 Opening words Janne Kalliola 14.10 Summary of agile methodologies Kalle Varisvirta 14.30 What kind of projects does agile fit in? 14.50 Break Janne Alho 15.00 What agile project means to the client? Laura Halenius, Sitra 15.20 Trust in agile projects Janne Kalliola 15.40 How to buy agile projects? Mikko Hämäläinen 16.00 Discussion
KETTERÄ OSTAMINEN 15.8.2013 Mikko Hämäläinen
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 Markkinointiautomaatio mikko@exove.fi @mthamala
Mitä on ketterä ostaminen? Tavoitteena aidosti ketterä projekti Huomio toimittajan osaamisessa ja kokemuksessa Joustava sopimusmalli Enintään kaksi kolmesta voidaan kiinnittää: Budjetti Aikataulu Laajuus
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
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
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
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 1 2 3 4 5 6 7 8 9 10 11 12
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
Ketterä verkkoprojekti sopii kaikille, joilla on halu tehdä parempaa tehokkaammin
KIITOS Seminaarin materiaalit www.exove.com Nähdään seuraavan kerran: DrupalCamp Baltics 23.8. Tallinna WordPress Café 10.9. 16-18 Exove DrupalCon Prague 23.-27.9.