Barry Boehm, Richard Turner: Balancing agility and discipline

“In the last few years, two ostensibly conflicting approaches to software development have competed for hegemony. Agile method supporters released a manifesto that shifts the focus from traditional plan-driven, process-based methods to lighter, more adaptive paradigms. Traditional methods have reasserted the need for strong process discipline and rigorous practises. True believers on both sides have raised strident, often antagonistic, voices”.

Näillä sanoilla alkaa Boehmin & Turnerin “hämmentyneiden opaskirja”, jossa kirjoittajat yrittävät selvittää, mikä sovelluskehitysmalli toimii minkäkinlaisissa tilanteissa ja toisaalta tarjoavat työkaluja harkittujen prosessuaalisten valintojen tekemiseen.

Maailmalla on yleisesti hyväksytty ja tiedostettu tosiasia, että ketterät menetelmät toimivat pienissä ja keskisuurissa projekteissa, joissa ei ole kovin montaa toimittajaosapuolta. Toisaalta on selvää, että massiiviset, kriittiset projektit vaativat huomattavasti tiukempaa prosessivalvontaa.

Lyhyesti sanottuna, kirja yrittää antaa eväitä, jotta projektiryhmä osaisi vastata kysymykseen ”kuinka paljon suunnittelua on tarpeeksi”. Pidemmin sanottuna, lue eteenpäin.

Kirjassa otetaan lähtökohdaksi se, että suunnitteluun menee tietty prosenttiosuus kokonaisprojektiin käytetystä ajasta ja toisaalta, jos suunnitellaan liian paljon, menee suuri osa projektiin käytettävästi ajasta hukkaan muuttuneiden vaatimusten myötä. Joskus on myös hyödyllisempää saada toimitettua nopeammin kevyempi versio, kuin hitaammin toimintorikkaampi versio. Jokaiselle projektille on määriteltävissä ”sweet spot”, missä suunnittelua on tehty juuri riittävä määrä.

Projektin tyypin valintaa

Mutta millä keinoin voidaan päätellä, millaista suunnitelmallisuutta juuri minun projektini tarvitsee?

Ensin on tietysti tiedostettava, mitä tarkoittaa suunnitelmallisuus, mitä puolestaan ketteryys ja millaisia keskeisiä konsepteja kumpaankin ”ääripäähän” liittyy.

Kattavien tutkimusten valossa on todettu, että jotkut ketterien menetelmien käytännöistä ovat vaikeasti skaalattavissa suurempiin projekteihin. Silti, jotkin käytännöt täydentävät mainiosti byrokraattisintakin menetelmää.

Seuraavaksi kirjassa esitellään tapa, jolla voidaan määrittää, onko projektin luonne ketterä, vai suunnitelmavetoinen. Prosessin valintaan vaikuttaa seuraavat viisi tekijää:

  • Henkilöstön määrä
  • Erittäin pätevien henkilöiden osuus tiimistä
  • Kriittisyys (Ihmishenkiä, merkittäviä taloudellisia menetyksiä, kosmetiikkaa)
  • Dynaamisuus (Vaatimusten muutosten määrä)
  • Kulttuuri (ovatko kehittäjät luonteeltaan ketteriä vai tarkkaa suunnittelua edellyttäviä)

Näitä tekijöitä painottamalla saadaan selville projektin ensisijainen tyyppi, minkä jälkeen voidaan alkaa tasapainottamaan, millaisia riskejä ketterien käytäntöjen käyttöön liittyy ja toisaalta millaisia riskejä liiallisella suunnittelulla on.

Riskitietoisuus

Kirjoittajat esittelevät seuraavan viisivaiheisen menetelmän sopivan tasapainon löytämiseen:

  1. Arvioi projektin ympäristölliset, ketterät ja suunnitteluvetoiset riskit
  2. Valitse lähtökohta projektin balansoimiselle
    • Jos suunnitteluun liittyvät riskit dominoivat, valitse ketterä lähtökohta
    • Jos ketteryyteen liittyvät riskit dominoivat, valitse suunnitteluvetoinen malli
  3. Mikäli osa kokonaissovelluksesta menee kategoriaan 2a ja osa 2b, kannattaa muodostaa ”aliprojekteja”, joista osa etenee ketterästi, osa suunnitelmallisesti
  4. Muodosta projektistrategia yhdistämällä kaikki riskit ja niiden hallintakeinot.
  5. Seuraa jatkuvasti projektin kulkua ja muuta balanssia tarvittaessa.

Vaiheessa yksi arvioitavat riskit ovat seuraavat:

  • Ympäristölliset riskit, jotka johtuvat ympäristöstä, missä projektia ryhdytän tekemään
  • Epävarmuus teknologiasta
  • Useita osapuolia
  • Monimutkainen järjestelmä, tai useita järjestelmiä
  • Riskit, jotka liittyvät ketterien menetelmien käyttämiseen:
  • Skaalautuvuus ja kriittisyys
  • Yksinkertaisen suunnittelun ja jatkuvan refaktoroinnin käyttäminen
  • Henkilöstön vaihtuvuus
  • Kokemattomien henkilöiden puute
  • Riskit, jotka liittyvät plan-driven menetelmien käyttämiseen:
  • Tarve tehdä nopeita muutoksia
  • Tarvitaan tuloksia nopeasti
  • Lisääntyvät / muuttuvat vaatimukset
  • Kokemattomien henkilöiden puute

Näiden riskien arviointi muodostaa perustan, jonka varassa prosessia voidaan hallita. Mikäli jotain näistä riskeistä ei osata arvioida, kannattaa tietous hankkia tavalla tai toisella, vaikkapa protoilemalla tai suurten projektien tapauksessa, tekemällä varsinainen tutkimusprojekti.

Johtopäätökset:

  1. Etukäteissuunnitteluun perustuvat (plan-driven) menetelmät eivät tarjoa silver bulletia (kts. Fred Brooks, Mythical Man-month) sen enempää kuin ketterät menetelmätkään.
  2. Sekä plan-driven että ketterillä menetelmillä on omat alueensa, missä ne ovat ylivertaisia toisentyyppisiin menetelmiin verrattuna.
  3. Tulevaisuuden trendit vievät kohti sovelluskehitystä, missä tarvitaan sekä ketteryyttä, että suunnitelmallisuutta.
  4. Joitain hybridi-menetelmiä on jo kehitteillä.
  5. On parempi muodostaa oma menetelmä kasaamalla riittävät palikat yhteen, kuin räätälöidä joku raskas prosessi poistamalla siitä turhat osat.
  6. Menetelmät ovat tärkeitä, mutta mahdolliset hopealuodit löytyvät todennäköisimmin ihmisläheisiltä alueilta, kuten arvot, kommunikointi ja odotusten hallinta.

Seuraavassa lyhyt lainaus aiheesta, miksi arvokeskustelu on tärkeää myös projektin sisällä:

“Unfortunately, software engineering is caught in a value-neutral time warp, where every requirement, use case, object, test case, and defect is considered to be equally important. Most process improvement initiatives and debates, including silver bullet debate, are inwardly focused on improving software productivity rather than outwardly focused on delivering higher value per unit cost to stakeholders. “.

Kirjoittajien mukaan yksi suurimmista projektin epäonnistumiseen johtavista syistä on kelvoton odotusten hallinta. Miellyttämisen halu ja luottamuksen puute estimaatteihin ovat monien ongelmien syitä. Prosessituntemus, valmistelu ja rohkeus ovat kriittisiä tekijöitä, kun asiakas on saatava suostumaan vähentämään vaatimuksia tai pidentämään aikataulua, jotta uusi, tärkeä muutos saadaan ajoissa toteutettua. On oleellista saada asiakas ymmärtämään, että epärealististen odotusten asettaminen ei ole lopulta kenenkään etu.

Kirjassa myös oikaistiin joitakin yleisiä harhaluuloja, kuten että eri tyyppisten menetelmien balansointi olisi yksiulotteinen toiminto: kultaisen keskitien löytäminen vaatii teknologisten, hallinnollisten ja henkilökohtaisten seikkojen tarkkaa läpikäyntiä. Mikään yksittäinen prosessimalli ei voi olla vastaus kaikkiin ongelmiin.

Kirja loppuu tuttuun teemaan: todella suuria muutoksia tuottavuuteen – ja projektien onnistumisprosentin kasvattamiseen – on saavutettavissa vain kyvykkäämpien ihmisten, ja jatkuvan kehittymisen, voimin.

“Improve your people, values, communication and expectations management.”