Luku 12 Nopean sovelluskehityksen hallinta Johdanto Joustavuudesta, nopeudesta ja muutoksesta on tulossa menestyvien organisaatioiden tavallisia ominaisuuksia uudella vuosituhannella. Joustavuuden ja muutoksen tarve ulottuu kaikkiin organisaatioihin, sekä paikallisiin että globaaleihin, ja niiden tietohallinto-osastoihin, ja edellyttää niiltä lyhyempiä kehitysaikoja, pienempiä projektitiimejä ja kehityskustannusten valvontaa. Nopea sovelluskehitys (RAD, rapid application development) on lähestymistapa, joka tarjoaa edellä mainittuihin vaatimuksiin vastaavan ja toistettavan prosessin. Nopea sovelluskehitys yhdistää projektinhallintamenetelmien parhaat käytännöt, kehitystekniikat, käyttäjät ja työkalut rakentamaan laadukkaita sovellusjärjestelmiä etukäteen sovitun aikataulun mukaisesti tuottaakseen liikearvoa. Nopea sovelluskehitys yhdistää myös tiimit työskentelemään erittäin järjestelmällisessä ja motivoituneessa ympäristössä. RAD-tiimi koostuu 3-7 henkilöstä, jotka keskittyvät luomaan tietyn sovelluksen priorisoitujen ja ennalta sovittujen vaatimusten pohjalta.
148 12. Nopean sovelluskehityksen hallinta Nopeus on uuden vuosituhannen tunnussana. Yritysjohto ja loppukäyttäjät haluavat tietää vain sen, miten nopeasti asiat edistyvät: Milloin seuraava julkistus tapahtuu? Milloin pyytämäni muutokset ovat valmiit? Milloin saan uudet raportit? Hitaasti reagoivat yritykset jäävät kilpailijoidensa jalkoihin. Eräs tietohallintojohtaja on todennut, että vauhti tappaa kilpailun. Tätä taustaa vasten on helppo ymmärtää, miksi RAD-menetelmä on kehitetty. Nopean sovelluskehityksen kuvaus Nopea sovelluskehitys eli RAD on erittäin tiivistahtinen prosessi tai metodologia, jossa projektien vaatimukset syötetään nopean kehityksen prosessiin ja kehityksessä käytetään iteroivaa menetelmää. Sovellus kehitetään ennalta sovitussa ajassa, yleensä 30, 60 tai korkeintaan 90 päivässä. Yli 90 päivää kestävää projekti ei enää täytä nopean kehityksen kriteerejä. Iteroivan kehityksen tuloksena syntyy järjestelmä, joka voidaan heti ottaa tuotantokäyttöön ja julkistaa loppukäyttäjille. Aivan kaikkiin projekteihin RAD ei sovellu, joten projektipäälliköiden on harkittava huolellisesti, missä projekteissa sitä käytetään. RAD-projektien valintaa käsitellään tarkemmin jäljempänä tässä luvussa. Nopea sovelluskehitys on verrattain uusi menetelmä, joka on kehittynyt kymmenen viime vuoden aikana. Sen alkuperää ei tarkkaan tunneta, mutta yleensä sen keksijäksi mainitaan amerikkalainen kemian alan yritys DuPont. James Martin kirjoitti vuonna 1990 merkittävän, McGraw Hill -kustantamon julkaiseman teoksensa Rapid Application Development. Monet it-ammattilaiset väittävät nopean sovelluskehityksen olevan vain nopeampi versio osallistuvasta sovelluskehityksestä (JAD, joint application development), joka on ollut yleisesti käytössä jo vuosien ajan. Väitteessä voi hyvinkin olla perää.
12. Nopean sovelluskehityksen hallinta 149 Nopean sovelluskehityksen tavoitteet ja hyödyt Tavoitteet Nopean sovelluskehityksen tavoitteet ovat seuraavat: Kehitetään laadukkaita sovelluksia tarkkaan rajatun ja nopean aikataulun mukaan: kehitys kestää päiviä tai viikkoja, kun se tavanomaisia tekniikoita käyttämällä vie yleensä kuukausia tai vuosia. Luodaan ympäristö, jossa loppukäyttäjien osallistuminen on ensisijaisen tärkeää. RAD ei toimi, jos loppukäyttäjät eivät ole mukana kehityksessä täydellä teholla. Käytetään sovelluskehityksessä korkeasti koulutettua ja motivoitunutta henkilökuntaa, joka tekee järjestelmällistä tiimityötä. Hyödyt Nopean sovelluskehityksen omaksuneet it-organisaatiot ja sillä luotujen järjestelmien loppukäyttäjät hyötyvät siitä merkittävästi. Hyötyjen tuottamiseksi RAD hyödyntää olemassaolevaa tekniikkaa, asennettuja ja käytössä olevia arkkitehtuureja, integroitua kehitysympäristöä ja käyttäjien intensiivistä osallistumista kehitysprosessiin. RAD-tekniikan käyttö tarjoaa seuraavia etuja: Sovelluskehityksen elinkaari lyhenee huomattavasti, kuten edellä mainittiin: on täysin realistista odottaa projektin kestävän vain päiviä tai viikkoja. Sovelluskehityksen kustannukset laskevat merkittävästi. Ohjelmistojen laatu paranee: nopeus ei merkitse huonoja tuloksia. Henkilöstön tuottavuus kasvaa: it-henkilöstö saa enemmän aikaan lyhyemmässä ajassa. Sovelluksia on helpompi ylläpitää.
150 12. Nopean sovelluskehityksen hallinta Nopean sovelluskehityksen elinkaari Yleensä nopean sovelluskehityksen elinkaari koostuu neljästä perusvaiheesta: 1. Projektinhallinta on jatkuva prosessi. Vaatimusten tai laajuuden hallitseminen on tärkeä tekijä RAD-projektin hallinnassa, sovelluskehityksessä ja toteuttamisessa. Siihen sisältyy ongelmien ratkaisua, päätöksentekoa ja yhteistyötä loppukäyttäjien kanssa. RAD on ainoastaan projektitekniikka, ja sitä täytyy hallita tässä kirjassa kuvailtuja menetelmiä käyttäen. 2. Vaatimukset: järjestelmä määritellään ja sen toteuttamisesta sovitaan ennen kehitystä. Jotkut projektipäälliköt käyttävät nopeaksi vaatimusmäärittelyksi (RRD, rapid requirements definition) kutsuttua tekniikkaa vaatimuskehityksen ja suostumuksen saamisen nopeuttamiseksi. Toiset käyttävät mieluummin perinteisiä osallistuvan sovelluskehityksen menetelmiä. 3. Sovelluskehitys: tuote rakennetaan useiden iteraatioiden kautta tai toimitetaan osissa. Voidaan myös rakentaa prototyyppejä, joiden avulla kehittäjät voivat esittää jotain konkreettista asiakkaalle. Tähän vaiheeseen yhdistetään testaaminen, joka on prosessin elintärkeä osa. 4. Toteutus ja käyttöönotto: valmis järjestelmä otetaan käyttöön ja luovutetaan loppukäyttäjille. Tähän vaiheeseen sisältyy myös koulutuksen ja tukitoimintojen toteutus, jolla varmistetaan toimitetun järjestelmän laadukkuus. Jos vaatimuksena on jatkuva sovelluskehitys, niin joskus RAD-elinkaareen lisätään viidenneksi vaiheeksi ylläpito.yleensä ylläpito kuitenkin toteutetaan sovitun aikataulun ulkopuolella, joten siihen ei sovelleta samoja aikarajoituksia kuin itse sovelluskehitykseen. Kuva 12-1 havainnollistaa RAD-projektin kulkua. Nopea sovelluskehitys ja projektinhallinta Projektipäälliköiden täytyy projektisuunnitteluvaiheessa perehtyä tarkasti eri tekijöihin harkitessaan, pitäisikö sovellus kehittää RAD-tekniikan avulla. Seuraavaksi tarkastellaan näitä päätökseen vaikuttavia tekijöitä ja etuja.
12. Nopean sovelluskehityksen hallinta 151 Project Projektinhallinta Management Requirements Vaatimukset Application Sovelluskehitys Development Kayttöönotto Rollout Kuva 12-1 Nopean sovelluskehityksen elinkaari Lyhyempi kesto RAD-menetelmän pääasiallinen tavoite on kehittää sovelluksia huomattavasti lyhyemmässä ajassa kuin perinteiset sovelluskehityksen menetelmät. Yleensä RAD-projektien kesto määritellään projektisuunnitteluvaiheessa. Projektipäälliköt sopivat ylimmän johdon, projektin tukijan ja loppukäyttäjien kanssa, että projektin on valmistuttava 30, 60 tai 90 päivässä. Aikataulun valinta määrää projektin luonteen ja luo kiireyden tunnun projektitiimille. Päättämättömyyteen tai erimielisyyksiin ei ole varaa. Projektipäälliköitä vaaditaan usein tekemään nopeita päätöksiä. Valtuutetut loppukäyttäjät RAD on erittäin suosittu menetelmä loppukäyttäjien keskuudessa. Kun RADprojekti toteutetaan hyvin, loppukäyttäjät näkevät tulokset nopeammin kuin perinteisissä projekteissa ja ovat paljon tyytyväisempiä. Osa RAD-tekniikan menestyksestä on kuitenkin riippuvainen loppukäyttäjien täydellisestä sitoutumisesta projektiin. Loppukäyttäjät määrittelevät projektin vaatimukset. He ohjaavat myös sovelluksen suunnittelua ja ratkaisevat sovelluksen käyttöönoton toteutettavuuden. Loppukäyttäjien rooli projektissa saattaa muuttua projektin aikana: sovelluksen suunnittelun ja kehittämisen lisäksi heidät voidaan ottaa mukaan myös sen testaamiseen ja toteuttamiseen. RAD-projekti tarvitsee tukijan, joka puolustaa projektia ja valtuuttaa loppukäyttäjät asettamaan prioriteetteja ja ratkaisemaan suunnitteluun liittyviä pulmia omassa keskuudessaan, parantamaan viestintää ja tekemään päätöksiä.
152 12. Nopean sovelluskehityksen hallinta Itsevarmat ja aggressiiviset loppukäyttäjät menestyvät usein RAD-ympäristössä. Nopea sovelluskehitys ei sovi aroille ihmisille tai ihmisille, jotka eivät pysty tekemään nopeita päätöksiä. Loppukäyttäjien täytyy osallistua kehitykseen täysipäiväisesti (40 tuntia viikossa) koko projektin ajan, muuten projektin onnistuminen on vaarassa. Olemassaolevien arkkitehtuurien ja tekniikoiden käyttö RAD ei sovellu projekteihin, jotka edellyttävät uutta tai nousevaa tekniikkaa, kuten uusia ohjelmointikieliä, uusia arkkitehtuureja tai muuta innovatiivista tekniikkaa. Tekninen innovaatio määritellään sellaisten uusien alustojen, kuten laitteistojen, varusohjelmistojen, tietokantojen hallintajärjestelmien tai verkkojen, käyttöönottamiseksi, jotka ovat alalla uusia tai joiden ei ole vielä osoitettu toimivan kyseisessä yrityksessä. Projektipäälliköt ovat tietoisia tämän lähestymistavan riskeistä. RAD hyödyntääkin sellaisia olemassaolevia alustoja, jotka ovat käytännössä osoittautuneet toimiviksi, vakaiksi ja luotettaviksi. Nopeassa sovelluskehityksessä käytetään siis jo käytössä olevia laitteistoja sekä toimiviksi todettuja ohjelmistoja ja tietokantojen hallintajärjestelmiä. Nopea sovelluskehitys ei salli kokeilua, siihen ei yksinkertaisesti ole aikaa. Kannattaa myös käyttää uudelleen koodia, malleja ja suunnittelumalleja aina sopivan tilaisuuden tullen. Nopeus on kaikki kaikessa - laadukkaita tuloksia on saatava aikaan nopeasti. Toimiva metodologia Metodologia on erittäin hyödyllinen työkalu nopeassa sovelluskehityksessä, koska se määrittää ne prosessit ja toimenpiteet, joita tiimi noudattaa sovellusjärjestelmän luomisessa. Kehitysympäristö sisältää metodologian sen varmistamiseksi, että kehitysympäristö integroituu RAD-ympäristön muihin komponentteihin. Metodologiatuotteita ovat esimerkiksi Platinumin Process Engineer, Andersen Consultingin (nykyisin Accenture) METHOD/1, Ernst & Youngin Navigator, tai PriceWaterhouseCoopersin SUMMIT-tuotteet. Metodologian valinnassa on tärkeää varmistaa, että tuotteessa on RAD-polku tai -malli. Metodologioiden etuja käsiteltiin luvussa 11.
12. Nopean sovelluskehityksen hallinta 153 Äärimmäisen motivoitunut tiimi Nopea sovelluskehitys vaatii äärimmäisen motivoituneen ja energisen projektitiimin taitoja. Projektipäälliköiden tulee valita tiimin jäsenet erittäin huolellisesti. Projektin aikataulussa ei ole tilaa ylisuurille egoille, teoreettisille pohdiskelijoille tai laiskureille. Tiimin jäsenten täytyy pystyä kestämään painetta ja aikarajoja sekä saamaan aikaan tuloksia. Kokeneet ja loppukäyttäjien kunnioittamat projektitiimin jäsenet ovat parhaita valintoja myös RAD-projekteihin. Niissä ei ole aikaa opiskella, sillä tiimin jäsenten täytyy ryhtyä välittömästi toteuttamaan sovittua projektisuunnitelmaa. Projektipäälliköiden pitäisi maksaa kannustepalkkioita tai bonuksia projektin laadukkaasta toteuttamisesta. Projektiin tulisi luoda sopiva kannustepalkkiojärjestelmä, joka sisältää esimerkiksi bonuksia, palkintoja, päivällisiä tai muita tunnustuksia onnistuneesta työstä. RAD-projektin onnistuminen on riippuvainen ihmisistä. Menestyksekkään RAD-tiimin jäsenten ominaisuuksia ja henkilökohtaisia taitoja käsitellään yksityiskohtaisesti jäljempänä tässä luvussa. Sovelluksen monimutkaisuus RAD ei sovi sellaisten sovellusten kehittämiseen, jotka ovat toiminnallisesti erittäin monimutkaisia tai jotka käsittelevät suuria tapahtumamääriä. Tällaisten järjestelmien kehittäminen vaatii paljon enemmän aikaa, joten niitä tulisi välttää. Nopean sovelluskehityksen mahdollisuudet käsitellä suorituskykyä ovat minimaaliset. Vakiintuneiden ja luotettavien arkkitehtuurien pitäisi kyllä tarjota riittävästi suorituskykyä. Suorituskykyä edellyttävien järjestelmien kehittämisessä kannattaa käyttää perinteisiä kehitysmetodologioita. Myös eräajojärjestelmiä on syytä välttää, koska RAD ei ole sopiva tekniikka niiden kehittämiseen. RAD-projektin tiukat aikarajoitukset eivät salli monimutkaisten teknisten ongelmien ratkaisemista. Internet Internet on tuonut uuden ulottuvuuden nopeaan sovelluskehitykseen. Eri paikoissa työskentelevät tiimit voivat kommunikoida keskenään fyysisestä välimatkasta huolimatta, ja loppukäyttäjät voivat hakea sieltä tietoa, määrittelyjä, tutkimustuloksia, malleja, käyttöstandardeja ja paljon muuta.
154 12. Nopean sovelluskehityksen hallinta Internetin välityksellä asiointi on nopeaa, ja siellä on runsaasti tietoa hyödynnettäväksi. RAD-tiimin jäsenten roolit RAD-tiimi on koko RAD-prosessin ydin, joten sen jäsenten valinta vaikuttaa ratkaisevasti RAD-projektin onnistumiseen. Tiimi sisältää monenlaisia taitoja, ja siihen kuuluu RAD-tiimin vetäjä projektin tukija tietoasiantuntijoita loppukäyttäjiä kirjuri erikoisasiantuntijoita tarkkailijoita. RAD-tiimin vetäjä RAD-tiimin vetäjä on tiimin tärkein jäsen ja vastuussa projektin suunnittelusta, toteutuksesta ja hallinnasta. Tiiminvetäjän valinta on prosessin ensimmäinen tärkeä vaihe: hänen tulisi olla arvostettu ja taitava johtaja, jolla on hyvä maine organisaatiossa. RAD-tiimin vetäjän taidot eivät synny sattumalta, ja niitä täytyy ehkä opetella. Myös kokemus nopeasta sovelluskehityksestä on välttämätöntä. Tiiminvetäjää ei valita köykäisin perustein, eikä asema sovi arkajaloille. Vääränlaisen tiiminvetäjän valinta saattaa johtaa projektin epäonnistumiseen. Tiiminvetäjälle on ehdottomasti annettava riittävästi valtuuksia ja vastuuta tiimin johtamisessa. Hän tekee tiivistä yhteistyötä projektin tukijan kanssa RADprojektin tavoitteiden saavuttamiseksi. Tiiminvetäjä osaa toimia alaistensa kanssa niin, että jokainen tuottaa omien kykyjensä mukaisia tuloksia. Seuraavaksi tehdään yhteenveto tiiminvetäjän profiilista.
12. Nopean sovelluskehityksen hallinta 155 RAD-ROOLIN PROFIILI ASEMA: ROOLI: OMINAISUUDET: RAD-TIIMIN VETÄJÄ RAD-projektin hallinta ja ohjaus Johtajuus Johtamistaidot Arvostettu johtaja organisaatiossa Hyvät ihmissuhdetaidot Neuvokkuus Kyky saada tuloksia aikaan MÄÄRÄ: 1 ESIMERKKEJÄ: Projektipäällikkö Atk-johtaja Loppukäyttäjiä edustava johtaja Projektin tukija Kaikki tietotekniikkaprojektit tarvitsevat onnistuakseen yritysjohdon tukea. On erittäin tärkeää, että RAD-tiimillä on tukija yrityksen johtoportaassa. Tukija voi kuulua RAD-projektissa käsiteltävän liiketoiminta-alan ylempään tai alempaan johtoon. Tukijan ei tarvitse osallistua jokaiseen RAD-istuntoon. On kuitenkin suositeltavaa, että tukija osallistuu ainakin ensimmäiseen ja ehkä viimeiseen kokoukseen, jotta hän voi tarkastaa tulokset ja kommentoida niitä. Tukijan tulisi olla käytettävissä koko projektin ajan mahdollisten vakavien ongelmien tai muiden kysymysten ratkaisemista varten. RAD-tiimin vetäjä työskentelee tiiviisti projektin tukijan kanssa ja pitää tämän ajan tasalla projektin edistymisen suhteen. Tukija voi kuulua loppukäyttäjäorganisaation johtoon, mutta todennäköisesti hän on kehittäjäorganisaation atk-päällikkö. Seuraavaksi tehdään yhteenveto projektin tukija -roolista.
156 12. Nopean sovelluskehityksen hallinta RAD-ROOLIN PROFIILI ASEMA: ROOLI: OMINAISUUDET: PROJEKTIN TUKIJA Projektin tukeminen yritysjohdossa Arvostettu johtaja organisaatiossa MÄÄRÄ: 1 ESIMERKKEJÄ: Divisioonan johtaja Varatoimitusjohtaja Atk-päällikkö Liiketoiminta-alan johtaja Tietoasiantuntijat Tietoasiantuntijat auttavat loppukäyttäjiä ja suunnittelevat sovellusta loppukäyttäjien tarpeiden mukaan. Keskusteltuaan vaatimuksista loppukäyttäjien kanssa tietoasiantuntijat luovat RAD-tiimin vetäjän valvonnassa prototyyppejä, joten heiltä edellytetään prototyyppien rakentamiseen tarkoitettujen ohjelmistojen tuntemusta. Tietoasiantuntijat voivat myös neuvoa loppukäyttäjiä sellaisten uusien tekniikoiden tai laitteiden valinnassa, joista voi olla apua sovelluksen teknisessä toteutuksessa. Tietoasiantuntijoiden täytyy tuntea hyvin asiakasorganisaatio ja kyseessäoleva liiketoiminta-ala. Heidän pitää olla hyviä kuuntelijoita ja eläytyä loppukäyttäjien asemaan. Kokeneet ja ohjelmistot hallitsevat järjestelmäsuunnittelijat ovat onnistuneet erinomaisesti tässä roolissa. Seuraavaksi tehdään yhteenveto tietoasiantuntija-roolista. RAD-ROOLIN PROFIILI ASEMA: ROOLI: TIETOASIANTUNTIJA Sovelluksen suunnittelu loppuasiakkaiden tarpeiden mukaan
12. Nopean sovelluskehityksen hallinta 157 OMINAISUUDET: Hyvät tekniset taidot Kyky rakentaa prototyyppejä Kyky työskennellä loppukäyttäjien kanssa Empatia ja kärsivällisyys MÄÄRÄ: Vähintään 2, enintään 4 ESIMERKKEJÄ: Järjestelmäsuunnittelijat Suunnittelija-ohjelmoijat Kirjuri Kirjurilla on erityisen tärkeä rooli RAD-tiimissä. Hän vastaa RAD-kokousten dokumentoinnista. Kokousten dokumentointi on vuorovaikutteista toimintaa, ja kirjurin täytyy tehdä tiivistä yhteistyötä RAD-tiimin vetäjän kanssa. Kokousten aikana käsitellään monia ideoita ja ehdotuksia. Kirjurin täytyy oppia poimimaan keskusteluista tärkeät päätökset, kuka ne teki ja miksi ne tehtiin. Lisäksi kirjurin täytyy dokumentoida myös muut kokouksen aikana käsitellyt asiat. Kannettavat tietokoneet ovat siirreltävyytensä ansiosta erityisen käteviä kokouksista kertyvän aineiston käsittelyssä. On tärkeää, että loppukäyttäjiä kannustetaan RAD-kokousten aikana pyytämään kirjuria dokumentoimaan heidän mielestään tärkeät asiat. Kirjurin ei tarvitse olla it-alan ihminen, mutta häneltä vaaditaan loogista otetta dokumentointiin. Kirjurin tehtäviin kuuluu myös RAD-kokouksen aikana dokumentoidun materiaalin jako osallistujille kokouksen päätteeksi. Kirjurin tehtävä on vaikea, eikä sitä pidä aliarvioida. Seuraavaksi tehdään yhteenveto kirjuri-roolista. RAD-ROOLIN PROFIILI ASEMA: ROOLI: KIRJURI RAD-kokousten dokumentointi
158 12. Nopean sovelluskehityksen hallinta OMINAISUUDET: Looginen ajattelutapa Tekstinkäsittelyohjelmien tuntemus Hyvä organisointikyky Hyvät hallinnolliset taidot MÄÄRÄ: 1 ESIMERKKEJÄ: Osastosihteeri Järjestelmäsuunnittelija Erikoisasiantuntijat RAD-tiimin täytyy lähes poikkeuksetta, RAD-kokouksen tyypin mukaan, pyytää erikoisasiantuntijoilta neuvoja jonkin ongelman ratkaisemiseksi. Erikoisasiantuntijoiden ei tarvitse yleensä osallistua jokaiseen kokoukseen, koska heitä tarvitaan ehkä vain hetken aikaa tai osan päivästä. Erikoisasiantuntijoiden työtä helpottaa, jos RAD-tiimin vetäjä pystyy jo ennen kokousta kertomaan, mitä heiltä odotetaan. Näin varmistetaan, että asiantuntija-avusta saadaan maksimaalinen hyöty eikä kenenkään aikaa tuhlata. Erikoisasiantuntijoita voivat olla esimerkiksi tietokantasuunnittelijat, -arkkitehdit, -valvojat tai -mallintajat verkkoasiantuntijat ja -suunnittelijat järjestelmäohjelmoijat, -valvojat tai -asiantuntijat loppukäyttäjien erikoisasiantuntijat, asiantuntijat tai liiketoimintaprosessien suunnittelijat. Erikoisalojen tietämyksellä on usein tärkeä asema RAD-ympäristössä, joten erikoisasiantuntijoiden lyhytaikainenkin panos projektissa tuottaa hyödyllisiä ratkaisuja. Tarkkailijat Kun nopea sovelluskehitys on otettu onnistuneesti käyttöön organisaatiossa, sana siitä leviää nopeasti ja herättää muiden projektien ja tiimien kiinnostuksen. Tarkkailijat pyytävät RAD-tiimin vetäjältä lupaa osallistua kokouksiin nähdäk
12. Nopean sovelluskehityksen hallinta 159 seen itse, miten ne toimivat, ja päättääkseen, olisiko nopeasta sovelluskehityksestä hyötyä heidän toiminnassaan. Yleisesti ottaen RAD-tiimin vetäjän ja koko tiimin tulisi suosia tällaista toimintaa. On kuitenkin huolehdittava siitä, että tarkkailijat eivät vaikeuta tai estä RADkokousten kulkua. Usein tarkkailijat osallistuvat keskusteluun tai tarjoavat neuvojaan eri kysymyksiin, koska he pääsevät nopeasti sisälle ryhmän toimintatapoihin. RAD-tiimin vetäjän tulee kokouksen aluksi esitellä kaikki tarkkailijat tiimille. Johtopäätökset Nopealla sovelluskehityksellä on selvästikin monia houkuttelevia ominaisuuksia, joiden ansiosta monet erityyppiset yritykset voivat hyödyntää sitä. Internetin tarjoaman nopeuden ja kilpailuetujen aikakaudella nopea sovelluskehitys tuo monille tietohallinto-osastoille niiden kipeästi kaipaamaa menestystä. Nopean sovelluskehityksen menetelmien onnistuneen omaksumisen ja käyttöönoton tiellä on kuitenkin monia vaaroja ja esteitä. Nopea sovelluskehitys ei ole aluksi helppoa, mutta se voi osoittautua menestykseksi, jos sitä johtamaan saadaan kokeneita projektipäälliköitä, jotka omaksuvat tässä luvussa kuvaillut menetelmät. Kun projektipäällikön ansioluetteloon alkaa kertyä onnistuneita RAD-projekteja, niin sovelluskehityksen tuottavuus ja nopeus paranee merkittävästi esimerkiksi seuraavilla alueilla: Menestys: Projektin onnistuminen on kyvykkään ja kokeneen RAD-tiimin vetäjän/projektipäällikön ansiota, joka osaa ratkaista ongelmia, pysyy aikatauluissa, saa ihmiset tekemään tulosta ja kommunikoi. Tiimityö: Koko tiimin täytyy puhaltaa yhteen hiileen, ja kaikkien jäsenten täytyy tuoda merkittävä työpanos projektiin ja ratkaisuun. Työkalut: Työkalujen huolellinen valinta on menestyksen kannalta olennaista. Kaikkien ohjelmistoa käyttävien RAD-tiimin jäsenten täytyy olla kokeneita ja kyvykkäitä sekä halukkaita saamaan tuloksia aikaan nopeasti. Viestintä: Koska nopea sovelluskehitys tuo mukanaan myös ongelmia, RAD-tiimin vetäjän on ehdottomasti oltava hyvä viestijä,
160 12. Nopean sovelluskehityksen hallinta joka suhtautuu ongelmiin realistisesti ja joka on luonteeltaan suora ja avoin. Hänen on osattava kommunikoida sekä toimitusjohtajien että ohjelmoijien kanssa. Laajuus: Kuten aiemmin tässä luvussa todettiin, sovelluksen laajuus täytyy lyödä lukkoon etukäteen,eikä sovitusta laajuudesta ole varaa lipsua edes loppukäyttäjien pyynnöstä. Toimivan sovelluksen aikaansaaminen 30, 60 tai 90 päivässä vaatii kurinalaisuutta, taitoa ja kovaa työtä. Ihmiset: Ihmiset tekevät nopeasta sovelluskehityksestä menestyksen. Kirjallisuutta Gane, Chris. Rapid System Development: Using Structured Techniques and Relational Technology. Prentice Hall, 1989. Martin, James. Rapid Application Development. McGraw Hill, 1991. McConnell, Steve C. Rapid Development: Taming Wild Software Schedules. Microsoft Press, 1996.