29. toukokuuta 2018

SSL-sertifikaatit muutoksen kourissa


Yksi digitalisaation sekä IoT:n teknisistä mahdollistajista on luotettava tapa tunnistaa verkossa oleva laite, sekä välittää tämän kanssa tietoa turvallisesti. Tässä SSL-sertifikaateilla on merkittävä rooli.

Vaikka SSL-sertifikaatteja on käytetty jo vuosikymmeniä, ovat viimeiset vuodet tarjonneet SSL-sertifikaattien parissa vauhtia ja vaarallisia tilanteita. Mukaan on mahtunut paitsi tietoturvahaavoittuvuuksia, myös monelle yllättäen tulleita päivitystarpeita johtuen teknologioiden kehittymisestä, tai sertifikaatteja myöntävien yritysten töppäilyistä.

Itselleni uusin uutinen SSL-sertifikaattien rintamalla oli Googlen päätös poistaa tulevaisuudessa Chrome-selaimen osoitepalkista salauksesta kertova lukon kuva. Jatkossa Google Chrome ilmoittaa käyttäjälle jos sivusto ei ole turvallinen, mutta muuten salauksesta tai kohteen luottamustason tasosta ei siis erikseen kerrota. Tämä käyttäjälle tutuksi tulleen lukon katoaminen selaimesta aiheuttaa käyttäjässä jos ei nyt epätietoisuutta, niin ainakin päivitystarpeita tietoturvakoulutuksissa. Tämä muutos sopii hyvin Googlen tavoitteeseen turvata kaikki internetin verkkosivut SSL-sertifikaateilla.

Vaikka nykyisin SSL-sertifikaattien osalta on jo paljon automaatiota, niiden hallinta on silti haastavaa. Prosessissa on mukana IT-ylläpitäjä, sertifikaattien myöntäjä, palvelinohjelmistot, selainvalmistajat, loppukäyttäjät sekä tietoturvatutkijat. Vaikka henkilö tuntisi SSL-sertifikaattien perusteet, ovat monet yksityiskohdat epäselviä. Esimerkiksi sertifikaattien myöntäjien juuri- ja välivarmenteiden oikea käsittely on epäselvää, tietoturvan tai tehokkuuden optimoinnista puhumattakaan. Huonosti hoidettu SSL-sertifikaatti ja palvelimen konfigurointi voivat olla turvattomia, ja hidastavat sivuston nopeutta ja siten käyttökokemusta.

Tieturin uudella SSL/TSL-varmenteet käytännössä -koulutuksessa käymme lävitse SSL-sertifikaattien taustat sekä opettelemme käytännön harjoitusten kautta SSL/TLS-varmenteiden hallintaan liittyvät työvaiheet ja tietoturvalliset tavat hallita SSL/TLS-varmenteita ja SSL/TLS-protokollaan liittyviä asetuksia.

Tervetuloa oppimaan!

Timo Vehviläinen
Information Security Manager
Kesko

16. toukokuuta 2018

Koodaajia kouluttamassa

Jokaisen it-alan asiantuntijan kannattaa pitää perusosaamisensa kunnossa ja tarkkailla, mihin suuntaan kovaa vauhtia kehittyvä ala on menossa. Ei pidä rakastua tiettyyn ohjelmointikehykseen tai ohjelmointikieleen, vaan ymmärtää, että hyvin usein eri tekniikoilla on oma elämänkaarensa. Se tekniikka, mikä tänään saattaa olla suosittu, voi muutaman vuoden kuluttua olla korvattu jollain toisella.

Koulutuskin siirtyy yhä enemmän nettiin: järjestetään etäluentoja ja oppimateriaalit tehdään sekä jaetaan digitaalisina. Kurssilla on tavallisesti 10-20 osallistujaa, ja joskus heidän esitiedoissaan voi olla valtava tasoero, koodaamisnopeudessa jopa kymmenkertainen ero. Kokenut kouluttaja pystyy kuitenkin ottamaan erilaiset oppijat huomioon.

Tieturissa koulutan ohjelmistosuunnittelua erilaisista it-tehtävistä tulleille ohjelmistokehittäjille ja -suunnittelijoille – sekä asiakkaalle räätälöidyillä että kaikille avoimilla kursseilla. Jotkut opiskelevat nimenomaan tiettyä aihepiiriä, lisäksi on rekrytointi- ja muuntokoulutusta eri alojen työttömille. On myös paljon esimerkiksi Nokialta tulleita, jotka siellä keskittyivät tiettyyn tekniikkaan ja jotka haluavat päivittää osaamistaan niille aloille, joilla nyt on kysyntää.

Tällä hetkellä frontend-kehittäjän kurssit ovat kovasti kysyttyjä. Työpaikkailmoituksissa huhuillaan Angular- ja React -osaajia. Jotta nämä tekniikat pystyy kokonaisvaltaisesti ottamaan haltuun, on äärimmäisen tärkeää osata näissä käytetyt kielet, JavaScript ja TypeScript hyvin. JavaScript kielenä on erittäin vaativa dynaamisen luonteensa vuoksi, ja vaikka alkuun kielessä pääseekin helpolla, sen hallitseminen hyvin on haastavaa.

It-alan työnantajat ovat kyllä oivaltaneet jatkuvan opiskelun merkityksen. Jotkut kouluttavat työntekijöitään itse, mutta se vie yrityksen resursseja. Jos vanhemmat ja osaavammat asiantuntijat käyttävät aikansa muiden kouluttamiseen, he eivät itse tee sitä työtä, josta heille maksetaan.  Kustannustehokkaampaa on keskittää kurssit kouluttajille, jotka osaavat koulutettavan asian lisäksi nopeuttaa oppimisprosessia pedagogisin keinoin.

Henkilökohtaisesti palkitsevinta kouluttamisessa on se, kun pystyy vaikuttamaan positiivisesti ihmisiin niin suoraan. On upea tunne, kun joku tulee kiittämään, että tämän pitämäsi koulutusohjelman ansiosta olen saanut vakituisen työpaikan.

Entä mitä rekrytoija odottaa it-alan ammattilaiselta? Hyvällä ohjelmistokehittäjällä on looginen päättelykyky, keskittymisen taito ja halu opiskella jatkuvasti uutta. On oltava aidosti innostunut työstään – silloin jaksaa sisulla tahkoa myös eteen tulevia ongelmia. Olisi myös hyvä seurata aikaansa, mitä uusia tekniikoita tulee – sosiaalinen media, Twitter, YouTube ja alan blogit ovat hyviä tietolähteitä.

Vahva substanssiosaaminen on tärkeä, mutta mistään ei tule mitään, jollei ihminen voi kokonaisvaltaisesti hyvin. Esimerkiksi rekrykoulutuksissa olen huomannut, että kurssilaisilla on valtava innostus ja motivaatio tehdä asioita, mutta jos on koodattu kaiket yöt, terveys saattaa yhtäkkiä pettää. On tärkeää pitää balanssia. Pitää olla muutakin elämää.

Jussi Pohjolainen
-----------------------------
Jussi Pohjolainen on Tieturin suosittu kouluttaja, Tampereen ammattikorkeakoulun lehtori ja oman yrityksensä vetäjä, jolla on yli 15 vuoden kokemus ohjelmistoteknologian koulutuksesta ja konsultoinnista. Uuden oppimisen, lenkkeilyn ja matkailun lisäksi hänet pitävät liikkeessä vaimo, lapsi ja itsepäinen snautseri.

#ohjelmistokehitys #ohjelmistosuunnittelu #ITala #kouluttaja #elinikäinenoppiminen #etäkoulutus #muuntokoulutus #rekry #työmarkkinat #digitalisaatio

8. toukokuuta 2018

Haluatko prinssin ja puoli valtakuntaa - jopa ketterästi?

Maailmalla on prinssejä ja prinsessoja eli Prince2-sertifioituneita projektiammattilaisia jo melkoinen määrä. Tarinat eivät kerro, onko kylkiäisenä tullut myös puolet valtakuntaa, mutta projektipäällikön työkalupakissa ja CV:ssä Prince2-osaaminen ja -sertifikaatti kyllä huomataan. Se voi olla se pieni ero.

Prince2 tuli Suomeen voimakkaasti muutama vuosi sitten osittain kansainvälisten organisaatioiden kautta, mutta suureksi osaksi myös siksi, että erilaisten viitekehysten ja mallien suosio on kasvanut verrattuna ns. in house -kehitettyihin malleihin ja käytäntöihin. Organisaatiot ovat kansainvälistyneet, verkottuneet ja toimivat monitoimittajaympäristössä. Sen sijaan, että jokaisella osapuolella on oma projektimallinsa, on huomattavasti tehokkaampaa ja taloudellisempaa käyttää de facto –tyyppistä yleistä viitekehystä, joka ei vie liikaa omia kehittämisresursseja, käyttää ymmärrettävää ja yhteistä terminologiaa ja on kaiken lisäksi malli, jota menestyksekkäät organisaatiot ympäri maailmaa ovat käyttäneet ja edelleen kehittäneet.

Yksi yleinen väärinkäsitys on, että Prince2 olisi vain IT-projektimalli. Näin oli laita Princen aikaisempien versioiden osalta, mutta vuonna 1996 Prince sai numeron 2 peräänsä, ja on siitä asti ollut yleinen malli, joka sopii vaikka talonrakennukseen. Prince2 ei puutukaan siihen, miten itse tuotos (product) aikaansaadaan, sillä jokaisella toimialalla ja käyttöalueella on ihan omat menetelmänsä ja standardinsa; vertaa esimerkiksi talonrakennusmääräyksiä tai systeemityömenetelmiä. Käynnistyvät projektit ovat kuin pieniä, herkkiä taimia, joiden elinkelpoisuus riippuu siitä, miten niitä ’hoidetaan’. Prince2 keskittyykin määrittelemään, miten projekti viedään hallinnollisena kokonaisuutena läpi mahdollisimman tehokkaasti ja onnistuneesti.

Prince2:een voit tutustua tarkemmin MIFin koulutuksissa, lukemalla kirjoja kuten Managing Successful Projects with PRINCE2 – 2009 Edition tai tutustumalla virallisiin sivuihin. Tässä blogissani poimin esille joitakin asioita, joita itse pidän Prince2:n ehdottomina plussina ja eroina muihin menetelmiin verrattuna.


Business case – liiketoimintaperuste


Joidenkin tutkimusten mukaan projektien epäonnistumisen suurin yksittäinen tekijä on, että käynnistetään projekteja, joilla ei ole edes onnistumisen edellytyksiä – ei ole tehty business casea. Business case -käsite onkin yksi Prince2:n 7 teemasta (themes) eli projektinhallinnan näkökulmista, joihin on kiinnitettävä jatkuvasti huomiota.

Vaikka projektia käynnistettäessä meillä olisikin selkeät ja kannattavat lähtökohdat, niin silti moni asia voi mennä ns. pieleen, ympäristössä tapahtuu muutoksia tai riskit
realisoituvat. Projektilta voi mennä pohja pois vaikka yritysfuusion seurauksena, tai teknologian kehitys ajaa edelle. Prince2:n vastaus on, että huolehditaan jatkuvasti siitä, että business case, joka luotiin projektia käynnistettäessä, on edelleen validi, toteuttamiskelpoinen ja saavutettavissa oleva. Business case on siis jokaisen ohjausryhmän kokouksen agendalla. Liiketoiminta / hankejohdon, ohjausryhmän ja projektipäällikön saumaton tiedonkulku takaa myös, etteivät asiat tule miltään osin yllätyksinä, ja niihin voidaan tarvittaessa puuttua.

Selkeät roolit ja vastuut


Olen koulutustilaisuuksissa sanonut, ettei projektilla ole aitoja onnistumisen mahdollisuuksia, jos ohjausryhmä ei ole tehtäviensä tasolla. Ohjausryhmän tehtävänä on varmistaa, että projektille asetetut tavoitteet saavutetaan (direct). Sen sijaan projektipäällikön tehtävänä on päivittäinen ’manageeraus’ eli hän vastaa siitä, että tavoitteiden saavuttamiseksi tarpeelliset tehtävät suoritetaan. Hän voi toimia vapaasti ns. toleranssien puitteista, mutta kaikki poikkeamat on vietävä ohjausryhmän päätettäviksi. Projektipäällikön työrukkasina on tiimejä ja tiimimanagereja, joiden vastuulla on varsinaisen työn tekeminen (deliver).

Prince2 korostaa projektitiimin eri osapuolten selkeitä rooleja ja vastuita. Se korostaa myös osapuolten välistä aktiivista vuorovaikutusta ja tiedonkulkua, jolloin ohjausryhmällä, projektipäälliköllä ja tiimeillä on kaikki tarpeellinen tieto käytettävissään oman roolinsa hoitamiseksi. Prince2 määrittelee mm. erilaisia hallinnollisia tuotoksia kuten raportteja, joilla kaikki osapuolet pysyvät ajan tasalla ja osaavat reagoida ajoissa. Ja huomaa: Raportti voi olla sähköpostiviesti, ei välttämättä päivien työtä vaativa monisivuinen dokumentti – luonnollisesti projektista ja tilanteesta riippuen.


Tarkentuva suunnittelu – management by stages


Prince2-projekti ei käynnisty suoraan projektisuunnitelman laadinnalla. Ensin on varmistettava, onko tästä ideasta edes projektiksi, eli tehdään project brief – projektiesitys. Vasta sitten, kun ohjausryhmä on sen hyväksynyt, projekti ja myös varsinainen projektisuunnittelu käynnistyy. Tällä varmistetaan, että karsitaan pois ne ’elinkelvottomat taimet’ eli projektiaihiot, joilla ei sittenkään ole riittävää business casea.

Prince2 kutsuu projektin suunnitteluvaiheessa tehtävää ns. kokonaisprojektisuunnitelmaa termillä ’project initiation documentation eli PID’. Mutta tämäkään suunnittelutaso ei vielä riitä. Ajatellaanpa projektia, jonka kesto on 1-2 vuotta: Onko meillä PID:iä tehtäessä riittävän tarkkaa tietoa tulevista resurssitarpeista, kaikista tehtäväkokonaisuuksista tai edes kumppaneista, joiden kanssa joitakin projektin osioita tullaan tulevaisuudessa toteuttamaan? Tämän vuoksi Prince2:n keskeisiä periaatteita (7 principles) on ’management by stages’ eli vaihe kerrallaan johtaminen. Suunnitteluvaiheessa projekti vaiheistetaan ja jokaiselle vaiheelle laaditaan ennen sen käynnistämistä oma vaihesuunnitelmansa, joka tarkentaa mm. ko. jaksona tehtävät työkokonaisuudet. Projektipäällikkö saa ohjusryhmältä luvan johtaa projektia vaihe kerrallaan. Jokaisen vaiheen lopussa ja ennen seuraavan vaiheen aloittamista projekti on ns. ’katkolla’: Onko tästä edelleenkin projektiksi?


Niin, vielä se ketteryys…


Prince2-mallia on syytetty siitä, että se näyttäisi sopivan paremmin ns. vesiputousmallisen projektin menetelmäksi. Tarkasti ottaen tämä ei pidä paikkaansa, koska Prince2:n direct-, manage- and deliver-prosesseja voidaan käyttää hyvinkin ketterästi projektin niin vaatiessa.

Tervetuloa tutustumaan ketterään prinssiin Prince2 Foundation ja Practitioner -kursseille! Kysy myös organisaatiokohtaisia toteutuksia tai perehdytyspäivää.


Liisa Torkkeli, Consultant and trainer

Blogi on julkaistu aikaisemmin MIFin verkkosivuilla.

7. toukokuuta 2018

Teams kasvattaa projektin viestinnän määrää, mutta vähentää viestikaaosta


Oletko tuskaillut sähköpostin määrän kanssa, kun meneillään on iso ja kiivas projekti? Minä olen. Hallinnan tunne katoaa nopeasti, kun yhteen sähköpostiin kasataan monta kysymystä, ja vastauksia on mahdoton seurata, kun eri ihmiset vastaavat eri asioihin. Nykyään projektin viestintä tuppaa myös hajautumaan liian moneen kanavaan, joista yleisimmät ovat Whatsapp, Skype ja sähköposti.


Projektista voi selvitä ilman yhtäkään sähköpostia


Ison projektin viestinnästä ei saa ikinä taiottua helppoa, koska asioita on niin paljon. Vaatii paljon määrämuotoisuutta ja käytäntöjen sopimista, että se sujuu. Office 365 -alustassa on tiimien viestintäkanavaksi tarkoitettu Teams-sovellus, jonka avulla projektiviestinnän käytäntöjä on helppo sopia, kun työkalu tulee puolitiehen vastaan.

Olen itse useammassa projektissa ottanut Teamsin käyttöön projektiviestintään, ja koko ryhmän kanssa todennut moneen kertaan, miten paljon se on lisännyt tiedon kulkua verrattuna sähköpostiviestintään, mutta silti pysynyt hallinnassa. Teams on organisaation omassa O365-alustassa oleva keskustelukanava, mutta ryhmiin voi kutsua myös ulkopuolisia eli asiakkaita, toimittajia ja kumppaneita.

Kuten kaikissa Teamsin kaltaista somekanavaa hyödyntävissä projekteissa, uusien ihmisten on helppo hypätä mukaan projektiin, kun tieto on tallessa yhteisessä kanavassa eikä hajallaan sähköposteissa.

Teamsin onnistunut käyttö vaatii käytäntöjen sopimista


Teams mahdollistaa määrämuotoisuutta viestintään, kun yksittäinen projektiryhmä voi luoda eri asioille omat keskustelukanavat. Esimerkiksi seminaarin suunnittelussa keskustelukanavat voisivat olla: Projektinhallinta, Sponsorit, Tilat, Ilmoittautumisten hallinta, Tarjoilut, Esiintyjät. Suurimmat edut Teamsin kanavista ovat:

  • Käyttäjät voivat seurata vain niitä kanavia, jotka liittyvät omaan työhön (ei turhia cc-sähköposteja)
  • Vaikka käyttäjät seuraisivat vain tiettyjä kanavia, heillä on aina pääsy kaikkeen ryhmän viestintään
  • Hyvin mietitystä rakenteesta keskustelut löytyvät jälkikäteenkin (toisin kuin sähköpostin uumenista)

Selkeiden keskustelukanavien lisäksi ainakin nämä käytännöt pitää sopia tiimiläisten kesken:

  • Ihmisiä kannattaa mainita nimeltä (@heidi), kun heidän halutaan osallistuvan keskusteluun tai ainakin lukevan viestin. Jos tätä tehdään säännönmukaisesti, tiimiläisten ei tarvitse lukea muita kuin ne viestit, joissa heidät mainitaan. Työpäivä kevenee, kun ei tarvitse kahlata turhia viestejä.
  • Tiimiläiset voivat antaa lukukuittauksen tykkäämällä viestistä
  • Bookmark-toiminnolla voi merkitä itselleen muistiin viestejä, joihin on palattava

Matalan viestintäkynnyksen vuoksi asiat eivät jää selvittämättä


Parasta on, että Teamsissa keskustelun aloittamisen kynnys on matala, ja vastaamisen kynnys on matala toisin kuin sähköpostiviestissä, jossa on 15 vastaanottajaa. Tämän vuoksi mikään asia ei jää selvittämättä tai unohdu, kun keskustelua on lupa käydä ilman huonoa omatuntoa. Vaikka viestinnän määrä kasvaa, se ei häiritse, kun se tehdään hallitusti!

Opi lisää projektityön helpottamisesta kurssilla


Projektityön määrämuotoistamisessa on viestinnän ohessa yhtä tärkeää sopia myös selkeät paikat dokumenteille ja tehtäville ja avoimille asioille. Myös näihin löytyy ratkaisu Office 365 -työkalupakista. Opetan tarkemmin projektien viestintää, tehtävien hallintaa ja dokumenttienhallintaa Tieturin kurssilla ”Office 365 tiimityössä” seuraavan kerran jo ensi viikolla 17.5. Vielä ehdit mukaan!

Heidi Selkäinaho, työyhteisöviestinnän konsulti, Somepoint Oy


Heidi kouluttaa Tieturilla Office 365 tiimityössä -kurssiamme.  Heidi opastaa yrityksensä Somepoint Oy:n kautta  työpaikkoja uudenlaisen työn tekemisen ja työyhteisöviestinnän tapoihin. Hänellä on pitkä kokemus SharePointista ja Office 365:stä työskenneltyään edelliset 7 vuotta SharePoint-intranet-konsulttina.

3. toukokuuta 2018

Risk-First Development, part 1/2

Some history: risk-based testing


At “EuroSTAR 1999” in Barcelona, Ståle Amland’s presentation and paper entitled “Risk Based Testing and Metrics” was awarded the prestigious “Best Paper Award”. Three years later, I had the pleasure to deliver “Risk Based Test Management” tutorial at EuroSTAR 2002. “Risk based” was a very popular notion then, and Hans Schaefer frequently left his windy island near Bergen in Norway and travelled the world with his high-quality presentations on this subject.

However, the roots of considerable confusion were already visible then as well. Risk based testing is only a part of more general risk based development, and of risk management, and cannot sensibly be treated as a totally separate domain.

This confusion was, and still is, strikingly visible in ISTQB syllabi. In chapter 5.5 of ISTQB Foundation Level syllabus (version 2011), the subjects of general risk management and risk based testing are thoroughly mixed up. Instead of entering into what risk-based testing (or more generally, risk based development) really is, as we do here in “Risk is essential, but sadly neglected”, the syllabus concentrates on the difference between… product and project risk. I wonder what the latter has to do with testing, perhaps testing project members for the presence of flu viruses.

Sarcasm aside, in my opinion, the huge potential of risk based approach had petered away before it became really widespread. No wonder: the world was then too preoccupied with what officially started on 13 February 2001: the agile movement.

Another history: agile-driven reversal of waterfall sequence


Agile-like approach is far older than most 25-years old enthusiasts of lean startup and continuous integration realize: it was first defined in Tom Gilb’s “Evolutionary Project Management” (EVO) already in 70’s, and re-appeared to some extent in every iterative methodology since then.

However, two factors gave XP, TDD and agile real kick forward. They were the Internet-based process re-engineering revolution of late 90’s and early 2000’s, and the spread of mobile technologies and smartphones. The need to create working applications very fast, without really knowing in advance the business process they were supposed to support, resulted in full-blown, comprehensive agile revolution.

However, the essence of TDD / XP / agile is not “working without requirements”, which should be treated more like necessary evil rather than a goal, but the reversal of the traditional plan → design → code → test sequence into test-first approach, superior in most respects, even if the requirements are well-known in advance.

















Figure 1. Test-first approach

Tests, or test cases are essential part of requirements – in agile terminology, they are called acceptance criteria, or acceptance scenarios, or examples [1]. They come first, helping specify precisely imprecise user stories in product backlog [2]. If TDD is used as well, unit level test cases are then created [3], before coding starts [4]. If architecture is wrong, ad hoc, or non-existent, it can be improved using refactoring [5]. What if the implemented requirements are wrong? Well, they can be changed and then re-defined [6] and re-implemented in the next loop of agile development process.

This picture is of course an oversimplification, but it shows clearly the benefits, and superiority, of “test-first” approached, compared to traditional, sequential model.


Risk is essential, but sadly neglected


Sadly, this great leap in process quality, offered by test-first, agile approach, was followed by a relative decline in the realization of the real importance of risk-based development and testing.

The most blatant example of this, is the total lack of any reference to risk (neither consequence nor probability of failures) in agile scrum backlog items and in the agenda for sprint planning meetings. It looks like agile practitioners and scrum team members are expected somehow to absorb risk knowledge from thin air, without really learning it nor taking it into consideration.

In both agile and traditional projects, the notorious difficulties of deciding requirements’ priorities are convincing symptoms of the lack of any risk reverie before. Traditional methods try to achieve prioritizing by coercion, like imposing MoSCoW, and agile framework, by repeatedly asking what product owner really wants, if there is not enough time for both. But this may cure the symptoms only, not the underlying cause, which is the lack of risk analysis at the beginning.


However, an interesting and ambitious attempt to amend this, has already appeared: this is risk-based testing for agile projects, including risk poker, by Erik van Veenendaal. Google it!


Being a freelancer, I am often expected to answer absurd questions, like “how many testers should there be in a scrum team?”, or “how much testing do we need?” My automatic answer is “twenty percent”, which is popular and sometimes even right. However, in reality it depends on the risk. For nuclear plant control software, or some other safety-critical software, testing (or, more exactly, quality assurance) may well exceed 100% of all other costs. For a mobile game, where user may sometimes even expect and enjoy finding some bugs, less than 5% of QA cost may be quite rational.

So, risk-based testing is always there, even if its name is no longer popular; it is behind every decision concerning how thorough, controlled, and detailed the actual development process (including testing) must be.

On the figure below, I try to illustrate this simple yet basic idea.
















Figure 2 Risk and QA

Beginning with risk: the rationale


How is risk used in real IT projects? Typically, after some haggling about needs and requirements, development – agile and test-driven, or traditional – starts. No one asks the question, what process to use? – the process is simply there already. The decision, how much testing, or how thorough requirements verification, is needed, is taken ad hoc, and not based on risk analysis. I have participated in hundreds of agile scrum sprint planning meetings and - with few (too few) notable exceptions – never ever has the issue of risk been discussed. Definition of Done has typically been the same, regardless of feature criticality. During the second half of the planning meeting, planning test tasks was 100% focused on technicalities, not on HOW MUCH TESTING WAS NEEDED. Quality criteria for product backlog items sadly lack “risk level”.

In sequential projects, or on the highest, sequential level of project management for agile development, the same sad picture appears: methods, processes, the relative amount of requirements analysis or modelling, change management process (how much time to spend on impact analysis?), how much testing, what test design techniques – all that is decided before any risk analysis has started. Which is of course totally wrong – you cannot decide such issues correctly, unless you take potential failure consequences, and mistake → bug → failure probability, into the account.

How come so many projects have been quite successful? Well, we are smart intuitive creatures, and besides, poor quality and embarrassing failures have become a socially accepted norm: IT people feel no longer ashamed of them.

There is little room here to present a full list of arguments and steps (1), so I’ll leapfrog directly to my final vision, how it should be done in a far better way: risk-first development.


 













Figure 3. Risk-first development

You start with risks, which are identified and analysed for your business goals. Well, yes, that means your business goals must be clear – hard, isn’t it?

At the beginning, you have a fair chance of identifying correctly risk consequences, but less so risk probabilities, because they depend to a large extent on technical issues, which are not known yet.

Only knowing more or less your risks, and your business goals, you can decide on the risk strategy you choose. Should it be aggressive, maximizing possible profit, at the cost of accepting higher failure probability, or should it rather be cautious, minimizing failure probability, but renouncing impressive potential profits?

Risk strategy is the basis for deciding QA strategy – how carefully, how thoroughly you choose to work, how much to document, analyse, check and double-check? Knowing this, you can distribute the QA effort among requirements engineering (“RE strategy” on the figure above), testing (“Test strategy”), configuration and change management, etc.

Then, and only then, does it make sense to start building product backlog (or requirements specification, or whatever you call this in your process). Based on already defined business risks, you’re better equipped to define risk levels for individual backlog items / requirements.

No, this approach does not mean you need to spend months before being allowed to start actual work. You choose the time you spend on performing the six steps preceding backlog building yourself. Depending on the risk (sure enough), you may choose any time box, from one day to half a year, but, by all means, do it. Using a pre-defined process, disregarding actual project needs and specific product-related risks, is wrong. Starting a project without knowing your business goals, is the most common reason for project failures (“The Standish Group Chaos Report”).


(1) There is some more detailed stuff in my presentation at http://qualitology.blogspot.com/2015/09/risk-driven-development_15.html.

------------------------------------------


Author Bogdan Bereza is an international multitalent. He speaks six languages and is a true expert of e.g. Requirements Engineering and Testing.
You can find his IREB CPRE certification courses here: IREB CPRE Courses >>
You find also large selection of testing training courses at Tieturi

Suositut tekstit