Miksi ohjelmistoprojektien viivästyksiä ei pitäisi jättää huomioimatta

( 23. lokakuuta 2020)

Katsaus merkittävimpiin haasteisiin, joita tiimit kohtaavat ohjelmistotoimituksessa – ja ehdotuksia siitä, miten he voivat hallita näitä asioita pitääkseen projektit tiellä.

Kun nykyiset yritykset kilpailevat digitalisoinnista, ohjelmistokehitystiimeillä on yhä suurempi paine toimittaa uusia ominaisuuksia suurella nopeudella . Tämän seurauksena ohjelmistoprojektien viivästymiset ovat väistämättömiä. Siitä tulee ongelma, kun näitä viivästyksiä pidetään ”normaalina” osana ohjelmistokehityksen elinkaarta. Vaikka yksittäinen viive ei välttämättä aiheuta suurempaa huolta, toistuviin viivästyksiin on suhtauduttava vakavasti, koska ne ovat usein oire suuremmasta ja vaarallisemmasta perussyystä.

Ohjelmistotuote kehitys on monimutkainen, dynaaminen järjestelmä. Tasapainotetussa järjestelmässä, kun uusia pyyntöjä lisätään tuotekantaan, samassa tahdissa nykyiset pyynnöt muutetaan asiakkaan käytettävissä oleviksi ominaisuuksiksi. Kun saapuvien pyyntöjen tahti on korkeampi kuin lähtevien ominaisuuksien tahti, järjestelmä menee epätasapainoon. Jos jätämme sen huomiotta, tämä epätasapaino etenee edelleen ja johtaa lopulta järjestelmän vikaantumiseen.

Tässä on joitain yleisiä syitä, joita näen usein käytännössä:

Liian optimistinen suunnittelu

Olemme yleensä luonteeltaan liian optimistisia ja yliarvioimme, kuinka paljon voimme tehdä tietyllä ajanjaksolla. Tämä ei ole välttämättä huono asia. Jos sitä kuitenkin tapahtuu usein, se osoittaa, että määräaikojen noudattamista ei oteta vakavasti. Tärkeä ketterä periaate on, että vain ohjelmistokehittäjät ovat vastuussa ja vastuussa vaivojen arvioinnista. Vielä enemmän, jokaiselle ketterälle joukkueelle on hyvä seurata sprintissä tehtävän työn ja sprintin jälkeen suoritetun työn välistä eroa. Tavoitteena on tarkkailla edistymistä siinä, kuinka tarkasti tiimi tekee ennusteita ajan myötä.

Toteutuksen monimutkaisuuden huomioiminen

Uusia sprinttiominaisuuksia suunniteltaessa on helppo unohtaa toteutuksen aikana syntyvät monimutkaisuudet. Melko usein unohdettu monimutkaisuus on kuitenkin suoraan seurausta monimutkaisesta ohjelmistosuunnittelusta. Kun ohjelmistolla on monimutkainen rakenne ja ohjelmistomoduulien riippuvuudesta toisistaan ​​ei ole selkeitä malleja, on mahdotonta ymmärtää, miten ohjelmisto toimii. Tämän vuoksi on mahdotonta suunnitella realistisesti. Valitettavasti tätä ei ole usein helppo ratkaista; se edellyttää kuitenkin varmasti ohjelmistojen kunnostamisen ja toteuttamiskelpoisten tapojen tutkimista.

Odottamattomat, tärkeät viat

Tuotantovirhe (ominaisuusvirhe, suorituskyky tai tietoturvaongelma) on varmasti tärkeä prioriteetti ja se on korjattava välittömästi. Mutta kun tällaiset ongelmat liian usein estävät uusien ominaisuuksien rakentamista, se on hälyttävä merkki siitä, että jotain on parannettava. Tämä on oire ajan myötä kertyneestä merkittävästä teknisestä velasta (ts. Koodin laatuongelmista). Tämän teknisen velan vähentämisellä olisi oltava etusija; muuten on erittäin todennäköistä, että järjestelmän käyttäytyminen ja kehityksen tuottavuus heikkenevät edelleen vakavasti.

Toisen tiimin panoksen odottaminen

Ohjelmistotuotteita rakentavat yleensä useat tiimit, joista toinen tuottaa toisen vaatimat syötteet. Työ tulisi jakaa ryhmien kesken tavalla, joka mahdollistaa tasaisen tiedonkulun järjestelmässä. Muiden joukkueiden odotusten aiheuttamat viivästykset osoittavat, että tiimien välisen riippuvuuden minimoimiseksi tarvitaan parempaa tiimiorganisaatiota. Hyvän tuotejohtajan omistaminen on tässä keskeistä. Joku, joka valvoo koko tuotteen kehitystä ja asettaa prioriteetit tehokkaasti.

Tämä luettelo ei todellakaan ole tyhjentävä, ja ohjelmistotoimitusten viivästymisille voi olla monia muita syitä. Kuitenkin usein viivästykset ovat merkki siitä, että hidastat hieman, etsit ongelman perimmäisen syyn ja saat järjestelmän takaisin tasapainoon.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *